In mehreren Beiträgen ist ein Problem mit der AusweisApp angesprochen worden. Etwas fiddelige Handhabung mit Personalausweisen und NFC-Smartphones ist zwar normal, aber ich habe mir das mal angeschaut und ich habe eine Vermutung wo das Problem liegen könnte.
Meine Beobachtung ist, dass das PIN-Ändern funktioniert, eine Onlineauthentisierung aber nicht. Ich habe dafür die Nutzerdatenauskunft direkt in der AusweisApp probiert. AusweisApp kommt aus F-Droid, dürfte aber nicht relevant sein.
Die Onlineauthentisierung scheiterte in einer Hand voll Versuche immer an der gleichen Stelle, nämlich der Zertifikatsprüfung für das Terminalzertifikat.
Das vorher an den Perso gesendete DV-Zertifikat wird erfolgreich übertragen und verifiziert:
Diese Command APDU ist ein verschlüsseltes PSO:Verify-Kommando mit einer Datenfeldlänge von 0xfe=254 Bytes. Damit ist sie mit 260 Bytes ziemlich nah an der maximalen Länge einer Short-APDU (4 Bytes Header, 1 Byte Länge, 255 Bytes Daten und 1 Byte erwartete Antwort = 261 Bytes). Die Antwort enthält ein 0x99029000 am Anfang, das kodiert den Statuscode 0x9000 und bedeutet eine erfolgreiche Zertifikatsprüfung im Ausweis.
Diese APDU ist die um das Terminalzertifikat zu übertragen. Dieses ist länger und braucht eine extended length-APDU mit insgesamt 360 Bytes. Ich vermute hier liegt das Problem. NFC-Hardware/Firmware/Treiber/Android haben vermutlich irgendwo ein Problem mit extended length-APDUs. Vielleicht ist irgendwo nur ein Buffer nicht korrekt allokiert oder einfach nicht groß genug.
@amartinz Das sieht mir nicht nach einem AusweisApp-spezifischen Problem aus, dafür funktioniert zu viel. PIN-Änderung mit PACE-Protokoll hat nur short-APDUs und die einzige vom Perso gelesene Datei EF.CardAccess ist mit 199 Byte auch kurz genug für eine short-response-APDU.
Meine Beobachtung ist, dass das PIN-Ändern funktioniert, eine Onlineauthentisierung aber nicht. Ich habe dafür die Nutzerdatenauskunft direkt in der AusweisApp probiert. AusweisApp kommt aus F-Droid, dürfte aber nicht relevant sein.
Die Onlineauthentisierung scheiterte in einer Hand voll Versuche immer an der gleichen Stelle, nämlich der Zertifikatsprüfung für das Terminalzertifikat.
Das vorher an den Perso gesendete DV-Zertifikat wird erfolgreich übertragen und verifiziert:
Code:
Transmit command APDU: "0c2a00befe~1800" (260)
Transmit response APDU: "990290008e~9000" (16)
Diese Command APDU ist ein verschlüsseltes PSO:Verify-Kommando mit einer Datenfeldlänge von 0xfe=254 Bytes. Damit ist sie mit 260 Bytes ziemlich nah an der maximalen Länge einer Short-APDU (4 Bytes Header, 1 Byte Länge, 255 Bytes Daten und 1 Byte erwartete Antwort = 261 Bytes). Die Antwort enthält ein 0x99029000 am Anfang, das kodiert den Statuscode 0x9000 und bedeutet eine erfolgreiche Zertifikatsprüfung im Ausweis.
Code:
Transmit command APDU: "0c2a00be00~0000" (360)
android.nfc.TagLostException: Tag was lost.
Diese APDU ist die um das Terminalzertifikat zu übertragen. Dieses ist länger und braucht eine extended length-APDU mit insgesamt 360 Bytes. Ich vermute hier liegt das Problem. NFC-Hardware/Firmware/Treiber/Android haben vermutlich irgendwo ein Problem mit extended length-APDUs. Vielleicht ist irgendwo nur ein Buffer nicht korrekt allokiert oder einfach nicht groß genug.
@amartinz Das sieht mir nicht nach einem AusweisApp-spezifischen Problem aus, dafür funktioniert zu viel. PIN-Änderung mit PACE-Protokoll hat nur short-APDUs und die einzige vom Perso gelesene Datei EF.CardAccess ist mit 199 Byte auch kurz genug für eine short-response-APDU.