Alle paar Monate stellt uns jemand dieselbe Frage: Können wir Nutzer mit dem Bürgerausweis in unserer eigenen Anwendung authentifizieren? Die Antwort lautet ja, und der Weg dorthin ist offener, als die meisten Teams erwarten. Die offizielle Middleware wird von der AMA als Open Source veröffentlichtund deckt den Bürgerausweis, die Chave Móvel Digital sowie das System zur Zertifizierung beruflicher Attribute ab.
Was Teams überrascht, ist nicht die Kryptografie. Es ist die Leseschicht, die Entscheidung zwischen Authentifizierung und qualifizierter Signatur, die Zertifikatskette, und was passiert, wenn die Karte vor Ihnen eine Version ist, die Ihr Code noch nie gesehen hat.
Das maßgebliche Datum ist Juni 2024. Damals begann Portugal mit der Ausgabe des Bürgerausweises v2, neu gestaltet nach den Sicherheits- und Formatvorgaben der Verordnung (EU) 2019/1157, die seit dem 2. August 2021 anwendbar war und am 9. Juli 2025 durch die Verordnung (EU) 2025/1208 ersetzt wurde. Die v2-Karte verwendet ECDSA-Schlüssel, wo v1 RSA nutzte, und unterstützt kontaktloses Lesen. Version 3.12.0 der Middleware war die erste mit Unterstützung dafür. Wenn Ihre Integration vor Mitte 2024 entstanden ist und seither niemand sie angefasst hat, arbeitet sie mit Annahmen, die die Karte nicht mehr erfüllt.
Ist die Middleware für private Anwendungen offen, oder nur für den Staat?
Offen für alle. Der Quellcode, das SDK und die technische Dokumentation sind vollständig öffentlich. Es gibt keine Lizenzverhandlung und keine Genehmigungshürde, um Identitätsattribute zu lesen oder eine Authentifizierung durchzuführen.
Reglementiert ist etwas anderes. Die Ausgabe von Nachweisen ist eine staatliche Aufgabe. Autenticação.gov ist der staatliche Dienst dahinter. Die Nutzung beruflicher Attribute betrifft die ausgebenden Stellen. Das Lesen der Karte und die Prüfung einer Signatur nicht.
Was ist der Unterschied zwischen Authentifizierung und qualifizierter Signatur?
Die Karte trägt zwei getrennte Zertifikate mit zwei getrennten PINs und zwei sehr unterschiedlichen Rechtswirkungen. Die falsche Wahl ist der teuerste Fehler, der zu Projektbeginn möglich ist, denn sie verändert Architektur, Aufbewahrungspflichten und Umfang.
Zur Vollständigkeit: Die Karte hat drei PINs, für Authentifizierung, Signatur und Adresse, dazu einen längeren Sperrcode, mit dem die digitalen Funktionen bei Verlust oder Diebstahl deaktiviert werden. Alle werden mit dem PIN-Brief an den Bürger versandt.
Warum bremst das Lesegerät mehr Projekte als die Kryptografie?
Weil die Kryptografie standardisiert ist und die Leseschicht nicht. Ein Browser kommuniziert nicht selbst mit einer Chipkarte. Die Middleware muss auf dem Rechner des Nutzers installiert sein, und daran haben Sie nichts in der Hand.
Kontaktloses Lesen ändert das teilweise. Die v2-Karte unterstützt kontaktloses Lesen, was den Leser bei mobilen Szenarien aus der Gleichung nimmt. Es führt die CAN ein, eine sechsstellige Nummer auf der Karte, erforderlich für kontaktlose Vorgänge und verschieden von den drei PINs. Beim Aufruf von C_Login über PKCS#11 im kontaktlosen Modus mit einer v2-Karte wird die CAN als PIN-Parameter übergeben.
Was ändert sich zwischen Bürgerausweis v1 und v2 für Ihren Code?
Genug, dass Code, der nur gegen v1 geschrieben wurde, sich gegenüber v2 nicht korrekt verhält. Und die Middleware bietet keine direkte Möglichkeit, die Version im Leser abzufragen.
Was fügt jeder Umfang der Umsetzung tatsächlich hinzu?
Die Variable, die den Aufwand bestimmt, ist nicht die Kryptografie, die feststeht. Es ist, wie viele der folgenden Punkte Sie brauchen, und jeder bringt eigene Abhängigkeiten und Fehlerquellen mit.
Wir veröffentlichen hier keine Preisspannen, weil die ehrliche Antwort davon abhängt, welche dieser Punkte zutreffen, wie viele Plattformen Sie unterstützen und welche Prüfanforderungen bestehen. Beschreiben Sie den Umfang, und wir liefern eine Zahl, keine Spanne.
Was müssen Sie aufbewahren, und wie lange?
Bei der Authentifizierung weisen Sie nach, dass eine Prüfung stattgefunden hat: dass sie erfolgte, wann, mit welchem Zertifikat, und mit welchem Ergebnis der Ketten- und Sperrprüfungen. Nicht eine Kopie aller Kartendaten. Unter dem Grundsatz der Datenminimierung ist es eine Haftung und kein Nachweis, den vollständigen Identitätsdatensatz zu speichern, nur weil er verfügbar war.
Bei der qualifizierten Signatur weisen Sie etwas Schwierigeres nach: dass die Signatur zum Zeitpunkt ihrer Erstellung gültig war, Jahre später prüfbar, nach Ablauf des Zertifikats. Das erfordert das signierte Dokument, einen vertrauenswürdigen Zeitstempel und das zum Signaturzeitpunkt erfasste Validierungsmaterial.
Zwei Entscheidungen sind ausdrücklich zu treffen. Speichern Sie die Bürgernummer oder eine abgeleitete Kennung, wobei eine pseudonyme interne Kennung die meisten Anwendungsfälle abdeckt und das Risiko deutlich senkt. Und prüfen Sie in jeder Sitzung erneut oder vertrauen Sie nach der ersten Prüfung einem Sitzungstoken, eine Antwort, die vom Risiko des Vorgangs abhängt und schriftlich festgehalten werden sollte, statt von der Wahl des Entwicklers zu stammen.
Wie verhält sich das zur EUDI-Wallet, die im Dezember 2026 kommt?
Alle EU-Mitgliedstaaten müssen bis zum 24. Dezember 2026 eine Europäische Brieftasche für die digitale Identität bereitstellen, und verpflichtete private Organisationen müssen sie rund ein Jahr später akzeptieren. Das macht den Bürgerausweis nicht überflüssig, und beide sind kurzfristig keine Alternativen. Die praktische Lage der nächsten zwei bis drei Jahre ist, dass beide vorgelegt werden.
Das spricht für eine Architekturentscheidung jetzt. Halten Sie die Prüflogik hinter einer Schnittstelle, die nicht weiß, welcher Mechanismus das Ergebnis erzeugt hat. Wenn Ihr Anwendungscode fragt, ob diese Person geprüft wurde und auf welchem Niveau, statt zu fragen, was die Karte zurückgegeben hat, ist das späte Hinzufügen der Wallet-Akzeptanz eine Umsetzung und keine Neuentwicklung. Unsere Leitfäden zur eIDAS-2.0-Umsetzung und zur Relying-Party-Integration behandeln diese Seite.


