Können Sie Nutzer mit dem portugiesischen Bürgerausweis in Ihrer eigenen Anwendung authentifizieren?

Avatar
Autor

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.

Die Hürde für den Einsatz des Bürgerausweises in einem kommerziellen Produkt ist Entwicklungsaufwand, nicht eine Genehmigung.

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.

Drei Integrationswege, und wann jeder passt
PKCS#11
Plattformübergreifende Token-API. Das Modul pteid-pkcs11 ist Teil der Middleware. Am besten für Java und für alles, was PKCS#11 bereits spricht.
Native Betriebssystem-Kryptografie
Kryptografische Unterstützung von Windows, CryptoTokenKit über PteidToken unter macOS. Am besten für Desktop-Anwendungen.
SDK
C, C++, Java und C#, dazu ein .NET-8/9-Modul ab 3.13.0. Zwingend erforderlich für kontaktloses Lesen bei v2.
Die meisten kommerziellen Projekte nutzen zwei der drei Wege: das SDK zum Lesen von Daten und PKCS#11 zum Signieren. Kontaktloses Lesen bei v2 erfordert ausdrücklich die neueren SDK-Methoden, weshalb ein reines PKCS#11-Design diese Funktion nicht erreicht.

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.

Authentifizierung
Diese Person ist jetzt anwesend
Verwendet die Authentifizierungs-PIN. Eine Identitätsaussage, stark, aber keine Signatur. Sie bewahren einen Nachweis auf, dass die Prüfung stattgefunden hat. Typischer Einsatz: Login, Onboarding, Alters- oder Wohnsitzprüfung.
Qualifizierte Signatur
Diese Person hat diesem Dokument zugestimmt
Verwendet die Signatur-PIN. Gleiche Rechtswirkung wie eine handschriftliche Unterschrift nach Artikel 25 Absatz 2 der Verordnung (EU) 910/2014. Sie bewahren das signierte Dokument samt der Daten auf, die eine Prüfung Jahre später ermöglichen.
Die Falle ist ein Umfangszuwachs in die falsche Richtung. Ein als Login definiertes Projekt stellt drei Monate später fest, dass das Geschäft signierte Vollmachten benötigt. Die qualifizierte Signatur bringt Langzeitvalidierung, Zeitstempel, eine Entscheidung zum Archivformat und eine Aufbewahrungsrichtlinie mit sich. Entscheiden Sie das in der ersten Woche.

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.

Die Middleware ist nicht installiert. Ihre Anwendung kann das von einer Webseite aus nicht zuverlässig erkennen, weshalb der Fehler als unerklärliche Störung erscheint. Sie brauchen eine Erkennungsstrategie und einen Installationsweg, dem eine nicht technische Person folgen kann.
Lesertreiber unterscheiden sich nach Plattform und Modell. Das Benutzerhandbuch veröffentlicht Kompatibilitätstests von Lesegeräten für beide Kartenversionen. Was auf einem Entwicklerlaptop mit einem Leser funktioniert, scheitert auf einem Kundenrechner mit einem anderen.
Versionskonflikte bei pcsc-lite unter Linux. Bei Distributionen mit pcsc-lite 2.3.0, etwa Ubuntu 24.10 und Fedora 41, ist ein bestimmtes Flatpak-Paket erforderlich.
Die Karte wird während des Vorgangs entfernt. Das kommt häufig vor, und Ihre Fehlerbehandlung muss das von einem echten Fehler unterscheiden.
Die PIN ist unbekannt oder schon gesperrt. Drei Fehlversuche sperren genau diesen Code. Die anderen funktionieren weiter, eine gesperrte Authentifizierungs-PIN verhindert also kein Signieren, doch die Entsperrung erfordert einen persönlichen Besuch bei einer IRN-Stelle mit Karte und PIN-Brief. Ihr Support-Prozess braucht dafür eine Antwort vor dem Launch.

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.

Sie integrieren den Bürgerausweis und wissen nicht, welcher der drei Wege zu Ihrem Stack passt?
Sprechen Sie mit unserem Team

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.

v1
RSA-Schlüssel, nur Kontakt
Die ursprüngliche Version. Kontaktschnittstelle, RSA-Schlüssel und -Zertifikate, Zwischenzertifizierungsstellen werden über PKCS#11 wie erwartet zurückgegeben.
v2, seit Juni 2024
ECDSA, kontaktlos, CAN
ECDSA-Schlüssel. Kontaktlos über ISO/IEC 14443. Der Kontaktmodus funktioniert nach einem Software-Update ohne wesentliche Integrationsänderung. Kontaktlos erfordert die neueren SDK-Methoden. Zwischenzertifizierungsstellen werden über PKCS#11 möglicherweise nicht zurückgegeben.
Zwei Folgen. Wenn irgendein Teil Ihres Stacks RSA voraussetzt, scheitert er bei v2 auf eine Weise, die wie eine defekte Karte aussieht. Und die offizielle Dokumentation stellt ausdrücklich fest, dass es keine dedizierte PKCS#11-API zur Abfrage von Kartentyp oder kontaktlosem Modus gibt, weshalb Entwickler eine eigene Strategie umsetzen müssen. Ein dokumentierter Ansatz: Initialisierung ohne PIN oder CAN versuchen und bei Fehlschlag mit der CAN wiederholen. Die Migration behandeln wir im Detail in Bürgerausweis v1 und v2.

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.

Authentifizierung. Lesererkennung, Prüfung auf vorhandene Middleware, PIN-Behandlung, Validierung von Zertifikatskette und Sperrstatus, ein Nachweis der Prüfung. Aufwandstreiber sind die Anzahl der Betriebssysteme und die Frage, ob ein bestehendes Login-System parallel weiterlaufen muss.
Lesen von Identitätsattributen. SDK-Integration, Feldzuordnung, eine Datenminimierungsentscheidung darüber, was Sie speichern. Aufwandstreiber ist, ob die Adress-PIN benötigt wird, denn das ist eine eigene PIN und eine eigene Nutzerabfrage.
Qualifizierte Signatur. Dokumentenbehandlung, vertrauenswürdige Zeitstempel, Material zur Langzeitvalidierung, Entscheidung zum Archivformat, Aufbewahrungsrichtlinie. Treiber ist, ob Signaturen nach Ablauf des Zertifikats prüfbar bleiben müssen, was die meisten regulierten Anwendungsfälle verlangen.
Kontaktlos bei v2. Die neueren SDK-Methoden, CAN-Erfassung in der Oberfläche und eine selbst umgesetzte Strategie zur Erkennung von Version und Modus.
Laufende Wartung. Middleware-Releases verfolgen, gegen neue Kartengenerationen testen, Abhängigkeitsänderungen auf Distributionsebene. Der Release-Rhythmus liegt nicht in Ihrer Hand, und Juni 2024 hat Annahmen älterer Integrationen gebrochen.

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.

Weiterführende Beiträge

Bürgerausweis v1 und v2: was sich für Entwickler geändert hat Die Migrationsliste, wenn Ihre Integration vor Juni 2024 entstanden ist. ECDSA, PACE, die CAN und der Aufbau der Zertifikatskette.
Leitfaden zur eIDAS-2.0-Umsetzung Was Organisationen vor Dezember 2026 entscheiden, bauen und registrieren müssen, von einem Team, das seit 2011 nationale eID-Middleware pflegt.
Leitfaden zur Relying-Party-Integration der EUDI-Wallet Die technische Seite der Wallet-Akzeptanz, und wie sie sich von der kartenbasierten Prüfung unterscheidet.
eID Box Unser Middleware-Produkt für Organisationen, die nationale eID in ihre eigenen Anwendungen aufnehmen.
Open Source oder proprietär: was ist sicherer? Warum der Wartungsrhythmus mehr zählt als die Lizenzierung, wenn der Code unter einem Identitätsfluss liegt.

Häufige Fragen

Zugang und Lizenzierung

Ist die Bürgerausweis-Middleware für die kommerzielle Nutzung kostenlos?
Ja. Die Middleware wird von der AMA als Open Source im Repository amagovpt/autenticacao.gov veröffentlicht, mit SDKs für C, C++, Java und C#. Für das Lesen der Karte oder die Prüfung einer Authentifizierung in einer privaten Anwendung ist weder eine Lizenzverhandlung noch eine staatliche Genehmigung erforderlich. Die Ausgabe von Nachweisen und die Tätigkeit als qualifizierter Vertrauensdiensteanbieter bleiben regulierte Tätigkeiten.
Kann eine Webanwendung den Bürgerausweis direkt lesen?
Nicht allein. Ein Browser kommuniziert nicht mit einer Chipkarte, daher muss die Middleware auf dem Gerät des Nutzers installiert sein und Ihre Anwendung interagiert lokal mit ihr. Deshalb umfasst eine Bürgerausweis-Integration immer eine clientseitige Komponente und einen Plan, um das Vorhandensein der Middleware zu erkennen.

Die neue Karte

Was ist die CAN und wann wird sie benötigt?
Die CAN ist eine sechsstellige Card Access Number, aufgedruckt auf dem Bürgerausweis v2. Sie wird nur für kontaktloses Lesen benötigt und unterscheidet sich von den PINs für Authentifizierung, Signatur und Adresse. Bei Nutzung von C_Login über PKCS#11 im kontaktlosen Modus mit einer v2-Karte wird die CAN als PIN-Parameter übergeben.
Funktioniert Code für den alten Bürgerausweis mit dem neuen?
Für Vorgänge im Kontaktmodus genügt in der Regel ein Middleware-Update ohne wesentliche Integrationsänderungen. Kontaktlos erfordert neue SDK-Methoden. Alles in Ihrem Stack, das RSA voraussetzt, braucht Aufmerksamkeit, denn v2 verwendet ECDSA, und Zwischenzertifizierungsstellen werden bei v2 über PKCS#11 möglicherweise nicht zurückgegeben.

Einführung und was als Nächstes kommt

Was muss auf dem Gerät des Nutzers installiert sein?
Die Autenticação.gov-Middleware, die das PKCS#11-Modul und die kryptografische Unterstützung des Betriebssystems bereitstellt. Ohne sie erreicht ein Browser keine Chipkarte. Ihre Anwendung braucht daher eine Möglichkeit zu erkennen, ob sie vorhanden ist, und einen Installationsweg, dem eine nicht technische Person folgen kann, dazu das pcsc-lite-Flatpak-Paket bei Linux-Distributionen mit pcsc-lite 2.3.0.
Ersetzt die EUDI-Wallet den Bürgerausweis?
Kurzfristig nicht. Die Mitgliedstaaten müssen bis zum 24. Dezember 2026 eine Wallet bereitstellen, und verpflichtete Sektoren müssen sie rund ein Jahr später akzeptieren, doch die Nutzung durch Bürger ist freiwillig und die Karte behält die größte installierte Basis in Portugal. Rechnen Sie damit, beide zu unterstützen, was dafür spricht, die Prüflogik hinter einer gemeinsamen Schnittstelle zu halten. Unsere Arbeit zur digitalen Identität für einen Archipel zeigt, was diese Abstraktion einbringt, wenn der Einsatzkontext ungewöhnlich ist.
Caixa Mágica Software
Team Caixa Mágica
Caixa Mágica Software ist ein portugiesisches Softwareunternehmen mit über 20 Jahren Erfahrung in maßgeschneiderter Softwareentwicklung, KI-Lösungen und Nearshore-Entwicklungsteams für europäische Unternehmen. Wir arbeiten seit über einem Jahrzehnt an nationaler eID-Middleware.
eID Box · Caixa Mágica Software
Sprechen Sie mit dem Team, das diese Middleware pflegt
Wir arbeiten seit über einem Jahrzehnt an nationaler eID-Middleware. Nennen Sie uns die Plattformen, die Sie unterstützen müssen, und die Vorgänge, die Sie durchführen müssen, und wir sagen Ihnen, welcher Integrationsweg passt und wo Ihr Zeitplan wahrscheinlich rutscht.