NPA: Signaturfunktion: Difference between revisions
No edit summary |
|||
(21 intermediate revisions by the same user not shown) | |||
Line 69: | Line 69: | ||
Beim Nachladen des qualifizierten Zertifikats gab es schließlich eine Unstimmigkeit: Es wird einem mitgeteilt, dass es für das Erstellen des Zertifikats notwendig ist, Vornamen, Nachnamen, Titel und Gültigkeit vom Ausweis auszulesen. Für die spätere zuverlässige Identifikation über den eID-Service müssen jedoch alle Daten (Name, Geburtstag, Anschrift usw.) an den eID-Server gesendet werden. Hier fehlt zumindest ein Hinweis, dass dies zwei unterschiedlich Dinge sind, was zu Missverständnissen führen kann, sollte dies im späteren Echtbetrieb nicht noch geändert werden. <br /> |
Beim Nachladen des qualifizierten Zertifikats gab es schließlich eine Unstimmigkeit: Es wird einem mitgeteilt, dass es für das Erstellen des Zertifikats notwendig ist, Vornamen, Nachnamen, Titel und Gültigkeit vom Ausweis auszulesen. Für die spätere zuverlässige Identifikation über den eID-Service müssen jedoch alle Daten (Name, Geburtstag, Anschrift usw.) an den eID-Server gesendet werden. Hier fehlt zumindest ein Hinweis, dass dies zwei unterschiedlich Dinge sind, was zu Missverständnissen führen kann, sollte dies im späteren Echtbetrieb nicht noch geändert werden. <br /> |
||
Davon abgesehen kann man nach Eigabe eines Sperrkennwortes und der Bestätigung einer kurzen Rechtsbelehrung mit dem Nachladen beginnen. Für die Identifizierung wird die eID-PIN vom Lesegerät abgefragt, damit das Nachladen startet. Leider gab es beim Nachladen ein Problem, das Fenster der AusweisApp verschwand ohne Fehlermeldung, als ob alles funktionieren würde, auf der Internetseite des D-Trust gab es dann aber folgende Fehlermeldung: "<tt>Fehlercode 06. Ein unerwarteter Fehler ist im QES-Kontext bei der Kommunikation mit der internen ZDA aufgetreten. ReturnCode: -532152351</tt>" <br /> |
Davon abgesehen kann man nach Eigabe eines Sperrkennwortes und der Bestätigung einer kurzen Rechtsbelehrung mit dem Nachladen beginnen. Für die Identifizierung wird die eID-PIN vom Lesegerät abgefragt, damit das Nachladen startet. Leider gab es beim Nachladen ein Problem, das Fenster der AusweisApp verschwand ohne Fehlermeldung, als ob alles funktionieren würde, auf der Internetseite des D-Trust gab es dann aber folgende Fehlermeldung: "<tt>Fehlercode 06. Ein unerwarteter Fehler ist im QES-Kontext bei der Kommunikation mit der internen ZDA aufgetreten. ReturnCode: -532152351</tt>" <br /> |
||
Was genau wo nicht funktioniert hat konnte während des Workshops nicht herausgefunden werden, dadurch war aber etwas anderes zu bemerken, was aus den Technischen Richtlinien nicht klar hervorgeht: Wenn ein Versuch zum Nachladen fehlschlägt, scheint die eSign-PIN wieder gelöscht zu werden. Versucht man das Nachladen über die D-Trust-Seite gleich noch einmal, gibt es am Ende die Fehlermeldung auf der Internetseite, dass der nPA noch nicht für das Nachladen eines qualifizierten Zertifikats vorbereitet worden ist. Erst ein erneutes Setzen der eSign-PIN führte wieder zur ersten Fehlermeldung. |
Was genau wo nicht funktioniert hat konnte während des Workshops nicht herausgefunden werden, dadurch war aber etwas anderes zu bemerken, was aus den Technischen Richtlinien nicht klar hervorgeht: Wenn ein Versuch zum Nachladen fehlschlägt, scheint die eSign-PIN automatisch wieder gelöscht zu werden. Versucht man das Nachladen über die D-Trust-Seite gleich noch einmal, gibt es am Ende die Fehlermeldung auf der Internetseite, dass der nPA noch nicht für das Nachladen eines qualifizierten Zertifikats vorbereitet worden ist. Erst ein erneutes Setzen der eSign-PIN führte wieder zur ersten Fehlermeldung. |
||
Somit war das Testen der Signaturfunktion selber nicht möglich, was mit der zu der Zeit aktuellen Testversion AusweisApp unter Windows eigentlich möglich wäre. Einen leider sehr kurzen Bericht in einem Blog, wo das wohl funktioniert hat (leider ist nicht ganz klar ob alles vor Ort bei der Bundesdruckerei gemacht wurde) gibt es hier: [http://www.saperionblog.com/lang/de/die-ausweisapp-kann-auch-dokumente-signieren-und-signaturen-verifizieren/2664/ http://www.saperionblog.com/lang/de/die-ausweisapp-kann-auch-dokumente-signieren-und-signaturen-verifizieren/2664/] |
|||
''noch in Bearb...'' |
|||
==Fazit== |
|||
Das Aktivieren der Signaturfunktion auf dem nPA ist an sich medienbruchfrei - natürlich vorausgesetzt, dass es keine Probleme oder Fehler gibt, wie beim Workshop aufgetreten. Die Sicherheit scheint auch relativ hoch zu sein, da ein Komfort-Lesegerät nötig, und eine PIN-Eingabe über die Tastatur nicht möglich ist. Hier wäre noch zu genauer zu prüfen, ob eine AusweisApp so genutzt werden könnte, dass die PIN direkt übermittelt werden kann und wie leicht oder schwer es möglich wäre, an ein Berechtigungszertifikat eines Komfort-Lesers zu gelangen und man dem elektronischen Ausweis ein entsprechendes Lesegerät vortäuschen könnte, ohne es zu besitzen. |
|||
==Quellen, Links== |
|||
*Signaturgesetz und Signaturverordnung [http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Rechtsgrundlagen/Rechtsgrundlagen_node.html QES-Rechtsgrundlagen] |
|||
**SigG [http://www.bundesnetzagentur.de/cae/servlet/contentblob/37272/publicationFile/2434/SignaturGesetz16052001Id2247pdf.pdf] |
|||
**SigV [http://www.bundesnetzagentur.de/cae/servlet/contentblob/37662/publicationFile/2435/SignaturVerordnungId18198pdf.pdf] |
|||
*Gesetz über Personalausweise und den elektronischen Identitätsnachweis [http://www.bmi.bund.de/SharedDocs/Downloads/DE/Gesetzestexte/eperso.html] pdf: [http://www.bmi.bund.de/SharedDocs/Downloads/DE/Gesetzestexte/eperso.pdf?__blob=publicationFile] |
|||
*Veröffentlichungen der Bundesnetzagentur im Bereich der QES [http://www.bundesnetzagentur.de/cln_1931/DE/Sachgebiete/QES/Veroeffentlichungen/Veroeffentlichungen_node.html] |
|||
*TR-03105 Test Spezifikation für eCards [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr03105/index_htm.html] |
|||
**Abschnitt 3.4: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03105/TR-03105_Part3.4_V1_pdf.pdf?__blob=publicationFile] |
|||
**Abschnitt 5.2: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03105/TR-03105_Part5.2_V1.0_pdf.pdf?__blob=publicationFile] |
|||
*TR-03110 Downloadseite: [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr03110/index_htm.html] pdf: [https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03110/TR-03110_v204_pdf.pdf?__blob=publicationFile] |
|||
*TR-03112 eCard-API-Framework [https://www.bsi.bund.de/cln_165/ContentBSI/Publikationen/TechnischeRichtlinien/tr03112/index_htm.html] |
|||
*TR-03117 Richtlinie für die eCard [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03117/BSI-TR-03117_pdf.pdf?__blob=publicationFile] |
|||
*TR-03119 Richtlinie für das Lesegerät [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03119/BSI-TR-03119_V1_pdf.pdf?__blob=publicationFile] |
|||
*TR-03128 EAC-PKI'n für elektornischen Personalausweis [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03128/BSI_TR-03128.pdf?__blob=publicationFile] |
|||
*Downloadseite für die Technischen Richtlinien im Kontext für elektronische Ausweise [https://www.bsi.bund.de/ContentBSI/Themen/Elekausweise/TRundSchutzprofile/TR_Spez/TRnachArtRichtlinieSpez.html] |
|||
*Kompetenzzentrum für den neuen Personalausweis [http://www.ccepa.de/public/index.htm ccepa.de] |
Latest revision as of 08:02, 13 October 2010
Signaturfunktion des künftigen Personalausweises
Der neue Personalausweis enthält die Möglichkeit, ihn für eine qualifizierte elektronische Signatur (QES) zu verwenden, wofür er vor der Schlüsselerzeugung und der Speicherung eines Zertifikats eines entsprechenden Diensteanbieters (ZDA) dafür vorbereitet werden muss: es muss die sogenannte eSign-PIN gesetzt werden. Dies soll medienbruchfrei geschehen, also komplett online über einen PC möglich sein. Im Security Workshop sollten die rechtlichen und technischen Grundlagen bzw. Richtlinien hierfür betrachtet werden und im Rahmen des Anwendungstests der Vorgang des Aktivierens der Signaturfunktion ausprobiert werden.
Rechtliche Grundlagen
Als rechtliche Grundlagen sind vor allem das Signaturgesetz, die Signaturverordnung und das Personalausweisgesetz ausschlaggebend.
Das Signaturgesetz legt unter anderem fest, was unter qualifizierten elektronischen Signaturen zu verstehen ist, nämlich:
- Daten in elektronischer Form, die mit anderen elektronischen Daten so verknüpft sind, dass eine nachträgliche Änderung der Daten erkannt werden kann,
- die ausschließlich dem Signaturschlüsselinhaber zugeordnet sind und
- die Identifizierung desselben ermöglichen,
- die mit Mitteln erzeugt werden, die der Signaturschlüsselinhaber unter seiner alleinigen Kontrolle halten kann und
- auf einem zum Zeitpunkt ihrer Erzeugung gültigen qualifizierten Zertifikat beruhen,
- und mit einer sicheren Signaturerstellungseinheit (SSEE) erzeugt werden.
nach § 2 SigG
Der neue Personalausweis muss für eine QES also einen Signaturschlüssel gespeichert haben, als auch ein Zertifikat besitzen. Dieses wird von ZDAs angeboten, die eine entsprechende Möglichkeit für den nPA bereitstellen müssen. So muss ein ZDA nach § 5 des SigG Personen, die ein Zertifikat beantragen, zuverlässig zu identifizieren, und die Zuordnung eines Signaturprüfschlüssels zu einer identifizierten Person durch ein qualifiziertes Zertifikat zu bestätigen. Diese Zertifizierungsdiensteanbieter können sich von der zuständigen Behörde für diesen Dienst akkreditieren lassen, dies ist jedoch freiwillig.
Da das Signaturgesetz nur einen rechtlichen Rahmen für Signaturen allgemein bereitstellt, fehlen Angaben über das genaue Wie der einzelnen Vorgänge. So heißt es bspw. in Satz 4 von § 5 des Signaturgesetzes:
"Der Zertifizierungsdiensteanbieter hat Vorkehrungen zu treffen, damit Daten für
qualifizierte Zertifikate nicht unbemerkt gefälscht oder verfälscht werden können. Er hat weiter Vorkehrungen zu treffen, um die Geheimhaltung der Signaturschlüssel zu gewährleisten. Eine Speicherung von Signaturschlüsseln außerhalb der sicheren
Signaturerstellungseinheit ist unzulässig."
Die Signaturverordnung ist eine Ergänzung zum Signaturgesetz und führt Einzelregelungen und Anforderungen auf.
So wird auch § 5 des SigG ein wenig konkretisiert. In Satz 2 von § 5 des SigV heißt es:
"Der Zertifizierungsdiensteanbieter hat von ihm bereitgestellte Signaturschlüssel
und Identifikationsdaten dem Signaturschlüssel-Inhaber auf der sicheren Signaturerstellungseinheit persönlich zu übergeben und die Übergabe von diesem schriftlich oder als mit einer qualifizierten elektronischen Signatur nach dem Signaturgesetz versehenes elektronisches Dokument bestätigen zu lassen, es sei
denn, es wird eine andere Übergabe vereinbart."
Da der elektronische Personalausweis einerseits als SSEE genutzt werden können soll, andererseits auf Grund der Optionalität der Signaturschlüssel erst nachträglich erzeugt wird, wenn gewünscht, muss nach oben stehendem Satz eine andere Übergabe vereinbart werden. Dies läuft darauf hinaus, dass der elektronische Identitätsnachweis (eID) genutzt wird, um sich bei einem ZDA nachträglich ein qualifiziertes Zertifikat zu besorgen, damit der Vorgang medienbruchfrei abläuft und der Nutzer ihn bequemer durchführen kann.
Hierzu ergänzt das "Gesetz über Personalausweise und den elektronischen Identitätsnachweis sowie zur Änderung weiterer Vorschriften" vom 18. Juni 2009, also das Personalausweisgesetz, in Artikel 4 die Signaturverordnung folgendermaßen:
"Die Identifizierung des Antragstellers kann auch mithilfe des elektronischen Identitätsnachweises gemäß § 18 des Personalausweisgesetzes erfolgen."
Technische Richtlinien
Die technischen Richtlinien beschreiben unter anderem die Abläufe der einzelnen Anwendungsmöglichkeiten, als auch die Anforderungen an Hard- und Software. Hauptsächlich sind folgende Richtlinien für die Signaturfunktion von Belang:
- BSI-TR-03110 — Sicherheitsmechanismen für maschinenlesbare Reisedokumente
- BSI-TR-03112 — Das eCard-API Framework
- BSI-TR-03117 — Richtlinie für eCards mit kontaktloser Schnittstelle als sichere Signaturerstellungseinheit
- BSI-TR-03119 — Anforderungen an die Kartenleser für den elektronischen Personalausweis (ePA)
daneben gibt es noch weitere, die für das Thema von Interesse sein können, unter anderem:
- BSI-TR-03105 — Konformitätstests für elektronische ID-Dokumente
- BSI-TR-03127 — Richtlinie zur Architektur des elektronischen Personalausweises
Aus diesen Dokumenten geht folgendes für die Signaturfunktion hervor:
- Das Kartenlesegerät muss vom Typ komfort sein und sich mit seinem Berechtigungszertifikat beim nPA anmelden.
- Die eSign-PIN muss vom Nutzer gesetzt werden um den nPA für das Nachladen eines Signaturschlüssels und Zertifikats bereit zu machen.
- Die eSign-PIN besteht aus 6 Stellen.
- Zum setzen der eSign-PIN wird vorher die CAN abgefragt.
- Das abfragen auf Korrektheit der eSign-PIN erfolgt über ein VERIFY Kommando und nicht über das PACE-Protokoll - dieses muss bereits vorher für einen sicheren Kanal aufgebaut sein.
- Die Signaturschlüssel dürfen nur auf der SSEE selbst oder durch technische Komponenten der Zertifizierungsdienste erstellt werden.
- Die Signaturschlüssel dürfen nicht außerhalb der SSEE gespeichert werden können.
- Für das Nachladen eines qualifizierten Zertifikats oder erzeugen eines qualifizierten Schlüsselpaars muss sich das Kartenlesegerät als Authentisierungsterminal ausweisen können - also ein entsprechendes Berechtigungszertifikat besitzen.
- Sowohl die eSign-PIN als auch die Schlüssel können wieder gelöscht werden.
Wie der Ablauf und die Verwendung der einzelnen APDUs für die Signaturfunktion ist, kann man am besten anhand eines Graphen aus der TR-03105 überschauen: BSI-TR03105 Part3.4, Seite 5
Anwendungstest
Während des öffentlichen Anwendungstest ist das Nachladen eines Zertifikats nur über die entsprechende D-Trust Seite (ein Tochterunternehmen der Berliner Bundesdruckerei) möglich: Zertifikat nachladen, Anwendungstest.
Für das Setzen der eSign-PIN muss zunächst jedoch in der AusweisApp "QES-Vorbereiten" ausgewählt werden. Daraufhin fragt das Lesegerät nach, ob ein Signatur-Tunnel aufgebaut werden soll. Nach Bestätigung wird die CAN abgefragt, wonach man die eSign-PIN eingeben, und zur Bestätigung ein zweites Mal wiederholen muss. Hier fiel auf, dass das verwendete Lesegerät — Reiner SCT cyber Jack e-com plus RFID komfort — PIN-Eingaben von sechs bis zu acht Stellen zuließ, und dies anscheinend auch vom Testmuster des Personalausweises akzeptiert wurde. In der Technischen Richtlinie 03117 ist jedoch nur die Rede davon, dass die eSign-PIN sechs Stellen hat.
Beim Nachladen des qualifizierten Zertifikats gab es schließlich eine Unstimmigkeit: Es wird einem mitgeteilt, dass es für das Erstellen des Zertifikats notwendig ist, Vornamen, Nachnamen, Titel und Gültigkeit vom Ausweis auszulesen. Für die spätere zuverlässige Identifikation über den eID-Service müssen jedoch alle Daten (Name, Geburtstag, Anschrift usw.) an den eID-Server gesendet werden. Hier fehlt zumindest ein Hinweis, dass dies zwei unterschiedlich Dinge sind, was zu Missverständnissen führen kann, sollte dies im späteren Echtbetrieb nicht noch geändert werden.
Davon abgesehen kann man nach Eigabe eines Sperrkennwortes und der Bestätigung einer kurzen Rechtsbelehrung mit dem Nachladen beginnen. Für die Identifizierung wird die eID-PIN vom Lesegerät abgefragt, damit das Nachladen startet. Leider gab es beim Nachladen ein Problem, das Fenster der AusweisApp verschwand ohne Fehlermeldung, als ob alles funktionieren würde, auf der Internetseite des D-Trust gab es dann aber folgende Fehlermeldung: "Fehlercode 06. Ein unerwarteter Fehler ist im QES-Kontext bei der Kommunikation mit der internen ZDA aufgetreten. ReturnCode: -532152351"
Was genau wo nicht funktioniert hat konnte während des Workshops nicht herausgefunden werden, dadurch war aber etwas anderes zu bemerken, was aus den Technischen Richtlinien nicht klar hervorgeht: Wenn ein Versuch zum Nachladen fehlschlägt, scheint die eSign-PIN automatisch wieder gelöscht zu werden. Versucht man das Nachladen über die D-Trust-Seite gleich noch einmal, gibt es am Ende die Fehlermeldung auf der Internetseite, dass der nPA noch nicht für das Nachladen eines qualifizierten Zertifikats vorbereitet worden ist. Erst ein erneutes Setzen der eSign-PIN führte wieder zur ersten Fehlermeldung.
Somit war das Testen der Signaturfunktion selber nicht möglich, was mit der zu der Zeit aktuellen Testversion AusweisApp unter Windows eigentlich möglich wäre. Einen leider sehr kurzen Bericht in einem Blog, wo das wohl funktioniert hat (leider ist nicht ganz klar ob alles vor Ort bei der Bundesdruckerei gemacht wurde) gibt es hier: http://www.saperionblog.com/lang/de/die-ausweisapp-kann-auch-dokumente-signieren-und-signaturen-verifizieren/2664/
Fazit
Das Aktivieren der Signaturfunktion auf dem nPA ist an sich medienbruchfrei - natürlich vorausgesetzt, dass es keine Probleme oder Fehler gibt, wie beim Workshop aufgetreten. Die Sicherheit scheint auch relativ hoch zu sein, da ein Komfort-Lesegerät nötig, und eine PIN-Eingabe über die Tastatur nicht möglich ist. Hier wäre noch zu genauer zu prüfen, ob eine AusweisApp so genutzt werden könnte, dass die PIN direkt übermittelt werden kann und wie leicht oder schwer es möglich wäre, an ein Berechtigungszertifikat eines Komfort-Lesers zu gelangen und man dem elektronischen Ausweis ein entsprechendes Lesegerät vortäuschen könnte, ohne es zu besitzen.
Quellen, Links
- Signaturgesetz und Signaturverordnung QES-Rechtsgrundlagen
- Gesetz über Personalausweise und den elektronischen Identitätsnachweis [3] pdf: [4]
- Veröffentlichungen der Bundesnetzagentur im Bereich der QES [5]
- TR-03105 Test Spezifikation für eCards [6]
- TR-03110 Downloadseite: [9] pdf: [10]
- TR-03112 eCard-API-Framework [11]
- TR-03117 Richtlinie für die eCard [12]
- TR-03119 Richtlinie für das Lesegerät [13]
- TR-03128 EAC-PKI'n für elektornischen Personalausweis [14]
- Downloadseite für die Technischen Richtlinien im Kontext für elektronische Ausweise [15]
- Kompetenzzentrum für den neuen Personalausweis ccepa.de