akaro / persoapp Goto Github PK

What steps will reproduce the problem?
1. german perso id not regionised
2.
3.

What is the expected output? What do you see instead?
it shoudt work pcsc-scan does identifi the card on reinersct basic

What version of the product are you using? On what operating system?
prerelese

Please provide any additional information below.

im on ubuntu 10.04(needed for work 16Pc on that system here)
running java8

Thanks,
Christian

Problem:
Nach dem SVN Checkout befindet sich unter /libs/build_repackaged.jar eine 
deutlich ältere Version der PersoApp-Core als unter  
/mvn-repo/de/persoapp/persoapp-core/persoapp-core-1.0.1.jar.

Obwohl die Version persoapp-core-1.0.1.jar im Gradle-Build-Script verarbeitet 
wird, wird sie nicht berücksichtigt. Die APK wird immer mit der älteren 
Core-Version aus /libs/build_repackaged.jar gebaut.


What steps will reproduce the problem?
- SVN Checkout und Build.


What version of the product are you using? On what operating system?
- SVN Versionen 140-146

Please provide any additional information below.

Um mit unserem eID-Testserver der mtg zu kommunizieren, mussten wir Änderungen 
am Core der PersoApp vornehmen. Dieser veränderte Core sollte anschließend 
neben der PersoApp-Desktop auch in der Android Version verwendet werden.

Das Gradle-Build Script der Android Version hat unsere Version des Cores auch 
ohne Probleme verarbeitet. Wir konnten anschließend allerdings nicht 
feststellen, dass die von uns vorgenommenen Änderungen auch in der fertigen 
.apk vorhanden sind.

Der Ordner /libs enthält nur die "build_repackaged.jar". Diese haben wir uns 
genauer angeschaut und festgestellt, dass die verwendeten .class Dateien des 
Cores vom 01.04.14 sind. 
Das hieße, dass die PersoApp-Android seitdem kein Updates des Cores erfahren 
hat. Jegliche Änderung der persoapp-core-x.x.x.jar im lokalen Maven-Repo 
bringen keine Änderung.

Anschließend haben wir versucht die "build_repackaged.jar" händisch zu 
ändern. Das einfache Austauschen der Core .class Dateien ist aber nicht 
möglich, das die PersoApp-Android teilweise noch auf älteren Core-Methoden 
basiert.


Haben wir diesbezüglich etwas falsch gemacht, oder handelt es sich um einen 
bisher nicht entdeckten Fehler?

What steps will reproduce the problem?
1. try to use ePA in free software applications 
2. consider the fact that you want to give the code everything needed to run it 
to end-users
3. consider that you cannot certify each end user separately as trusted to 
extract his private data from his nPA, and that you don't want to do this as a 
test but for a real-world application.

What is the expected output? What do you see instead?

Successful free software deployment without SaaSS (no typo).  This requires an 
ePA function that has no bad privacy implications when used by "anybody".  
Creating a pseudonym to defeat Sybil attacks in overlay networks fits this 
category nicely. What I would like to see is an API/example to do exactly this, 
and a business process to freely generate the necessary certificates to allow 
_anyone_ to create pseudonyms for "any" application free of charge (while 
strictly limiting the number of pseudonyms created per individual per 
application to one).


What version of the product are you using? On what operating system?

n/a. GNU operating systems.


Please provide any additional information below.


For free software to be able to use PersoApp in realistic 'libre' deployments 
(where it is not just used as part of a service), the certification process is 
a major roadblock, not just because of the expense but because there is no 
organization to be certified or to hold the private key.  I understand that the 
process is supposed to safeguard private information. Still, there is possibly 
one exception to this: the pseudonym function.


One big security issue in P2P networks is the so-called "Sybil" attack, where 
an adversary creates many identities (let's wildly assume the adversary does 
not control the Bundesdruckerrei this time). This could be prevented if each 
user had to show that he was 'real', by creating an unlinkable, 
application-specific pseudonym using the ePA.  As merely creating a pseudonym 
--- which should not be linkable to any 'real' identity or any personal data of 
the ePA, or any other pseudonym created for any other application --- is NOT 
private data (it's just a capability), this would be a useful way to defeat 
Sybil attacks (I would want this for my GNU project) AND I see no technical 
and/or privacy reasons why certificates that would allow applications to use 
this function could not be created cheaply (i.e. for free, as it can be done 
without any kind of audit), and without certifying a formal organization (which 
often does not exist for free software projects).


Ultimately, I would like to have a (simple) API to obtain a pseudonym for a 
given application identifier, i.e. I might specify "GNUnet" as the application 
identifier, and if there is a valid ePA in the device (and the user authorizes 
the operation, depending on reader, etc.) the API returns a pseudonym (ideally 
a private key that I can use for signatures, where the corresponding public key 
is certified to be a valid pseudonym that corresponds to a real human by 
"Germany"). Now, that's the ideal, but of course going to some website, typing 
in some application identifier ("GNUnet") and (automatically, without a fee) 
receiving a Berechtigungszertifikat first which would then be passed to the 
reader by the application later would also be acceptable.


Note that saying "but you can do everything in the Test-DV" without needing 
formal certification is not helpful at all --- eventually, a free software 
project wants to be used by real users in the real world, and at that point I 
must give the private key to obtain the information to each user, and I want it 
to work with real ePAs, not fake test crap.  So as long as real-world 
deployment is prevented, why would I bother to develop something for the 
Test-DV?  This is why this proposal is important: it could be deployed to the 
real world in free software without creating privacy issues.

What steps will reproduce the problem?
1. Verbindungsaufbau der mobilen PersoApp zu externen eID Server (nicht 
Ageto-eID-Server) 

What is the expected output? What do you see instead?
Ausgabe Android  Logcat:
1-26 11:40:25.648  32412-32445/de.persoapp.android.debug W/System.err﹕ 
java.io.IOException: Internal TLS error, this could be an attack
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.org.bouncycastle.crypto.tls.TlsProtocol.failWithError(Unknown 
Source)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown 
Source)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.org.bouncycastle.crypto.tls.TlsProtocol.completeHandshake(Unknown 
Source)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown 
Source)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.tls.BCTlsSocketImpl.<init>(BCTlsSocketImpl.java:90)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.tls.BCTlsSocketFactoryImpl.createSocket(BCTlsSocketFactoryImpl.
java:112)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.tls.BCTlsSocketFactoryImpl.createSocket(BCTlsSocketFactoryImpl.
java:129)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.paos.MiniHttpClient.getSocket(MiniHttpClient.java:142)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.paos.MiniHttpClient.getSSLSession(MiniHttpClient.java:119)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.paos.PAOSInitiator.<init>(PAOSInitiator.java:167)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.lib.paos.PAOSInitiatorExtension.<init>(PAOSInitiatorExtension.java:6
2)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.lib.paos.PAOSInitiatorExtension$1.createPAOSInitiator(PAOSInitiatorE
xtension.java:27)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.paos.PAOSInitiator.getInstance(PAOSInitiator.java:205)
11-26 11:40:25.668  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.ECardWorker.<init>(ECardWorker.java:422)
11-26 11:40:25.678  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.ECardWorker.<init>(ECardWorker.java:87)
11-26 11:40:25.678  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
de.persoapp.core.ECardWorker$1.run(ECardWorker.java:364)
11-26 11:40:25.678  32412-32445/de.persoapp.android.debug W/System.err﹕ at 
java.lang.Thread.run(Thread.java:841)i

What version of the product are you using? On what operating system?
A)  Mobile PersoApp: Revision 140 des SVN 
B)  Mobile PersoAPP: fertige APK 
http://eid.services.ageto.net/persoapp/PersoApp-Android.apk

Please provide any additional information below.
C)  Unser eService + externer eID Server funktionieren mit der aktuellen Version 
der offiziellen AusweisAPP unter Windows 8
D)  Unser eService + externer eID Server funktionieren mit einer älteren 
Version der Desktop-PersoApp unter Windows 8 (2014/09/05 11:16, V0.1b77-0022)
E)  Die aktuelle Version des Desktop Pre-Release (2014/09/26 17.53 
v1.5b20502-1251 http://eid.services.ageto.net/persoapp/AEC1.0_persoapp.jar ) 
wirft folgende Fehlermeldung: „Der eID Server versucht ein nicht zulässiges 
Protokoll auszuhandeln  (TLS1.0 statt TLS1.1+) Wollen Sie fortfahren“
Wenn man dies bestätigt, bricht die Verbindung mit folgender Meldung ab: 
"Fehler bei der Verbindung mit dem eID Server".
Der von uns angesprochene eID-Server unterstützt laut Betreiber sowohl TLS1.0 
als auch TLS1.1.

In der PersoApp Repository Revision 110 (05.09.14 11:19 Uhr) gab es ein Update 
auf BouncyCastle 1.51, wir tippen dass es damit zusammenhängen könnte, da die 
ältere Desktop-Variante vom 05.09.14 funktionierte und die neue 
Mobil-/Desktopversion nicht.  

Gruß Andreas