Open Interfaces für das eGovernment

Security-Layer für das Konzept Bürgerkarte

Einführung

Dokumenteninformation

Inhalt

1. Einführung
   1. Elektronische Signatur
   2. Zugriff auf Datenspeicher
   3. Nutzfunktionen
2. Referenzen

1. Einführung

Die Bürgerkarte stellt verschiedene Funktionen zu Verfügung, vor allem die Signaturfunktion, gibt dabei aber nicht genau vor um welche Hardware es sich handeln muss. Aus diesem Grund ist es notwendig, eine Schnittstelle zwischen Bürgerkarte und Applikationen zu definieren, die folgenden Ansprüchen genügt:

• Unabhängigkeit von der tatsächlich eingesetzten Hardware und Technologie. Wie z.B. die Signaturfunktion ausgeführt wird, ob über Smartcard, USB-Token, über eigenes Terminal, das z.B. mit IrDA (oder Bluetooth) kommuniziert, soll für die Applikationen transparent sein.
• Unabhängigkeit von den verwendeten Algorithmen. Die Applikationen sollen sich nicht näher mit den verwendeten kryptographischen Algorithmen (z.B. zur Signatur) auseinandersetzen müssen. Ob z.B. RSA, DSA oder ECDSA zum Einsatz kommen soll für die Applikationen nicht relevant sein. Zusammen mit obiger Eigenschaft ergibt sich eine größtmögliche Technologieunabhängigkeit und Zukunftskompatibiltät der Schnittstelle.
• Trennung der Verantwortlichkeiten nach Signaturgesetz. Die Schnittstelle trennt klar die Aufgaben und Verantwortungen des Zertifizierungsdiensteanbieters (ZDA) vom Applikationsanbieter. Dazu gehört unter anderem, dass alle Komponenten, für die der ZDA Haftung übernimmt unterhalb der Schnittstelle liegen.
• Die Schnittstelle soll eine logische Sicht der Daten und Funktionen nach außen bieten. Wie die konkrete Implementierung aussieht bzw. wo bestimmte Aufgaben erledigt werden (Software auf Rechner, Krypto-Token oder Remote-Service) soll nach außen transparent sein.

Das Bild zeigt wo die Schnittstelle angesiedelt ist. Die Applikation läuft am Rechner des Users. Sie kommuniziert über den Security-Layer mit der Security-Kapsel, welche als abgeschlossene Einheit alle Bürgerkartenfunktionen kapselt. Applikationen kommunizieren nur über den Security-Layer mit der Bürgerkarte. In diesem Sinne ist die Security-Kapsel als Service des lokalen Hosts zu verstehen. Durch die Kapselung und Ansprache über eine definierte Schnittstelle wird inhaltlich und technisch ein Maximum zur langfristigen Kompatibilität beigetragen. Die Security-Kapsel kann daher z.B. auch in einer externen Einheit, wie einem Mobiltelefon oder einem Palmtop implementiert sein.

Anmerkung zur Terminologie:

• Security Schnittstelle bzw. Security-Layer ist die Bezeichnung der Schnittstelle selbst. Sie stellt das Interface der Kapsel zu Anwendungen dar und ist als XML-Schnittstelle ausgeführt.
• Security-Kapsel ist das eigentliche Programm (Service), welches unter anderem die Kommunikation mit der Karte übernimmt, eine vertrauenswürdige Anzeige (Trusted Viewer) im Sinne des Signaturgesetzes enthält, Signaturverifikationsfunktionen enthält, etc.
• Bürgerkarte ist das Konzept/das Modell das die notwendige Funktionalität im Sinne eines universal verwendbaren Tokens (z.B. Smartcard) definiert. Dabei ist zu beachten, dass die Sozialversicherungskarte ("elektronischer Krankenschein") bloß eine von mehreren Smartcards ist, die als Bürgerkarte verwendet werden könne. Die zusätzlichen Funktionen der Sozialversicherungskarte finden in dieser Spezifikation keinen Niederschlag.

Im Folgenden soll kurz die Funktionalität der Security-Kapsel erläutert werden. Wie bereits erwähnt ist dies eine logische Sicht nach außen. Es müssen also nicht notwendigerweise alle Funktionen auf dem Hardware-Token (z.B. Smartcard) implementiert sein, sondern Teile davon sind als Software-Module in der Security-Kapsel selbst angesiedelt.

1.1 Elektronische Signatur

Zur Berechnung einer elektronischen Signatur sind auf der Bürgerkarte mindestens zwei Schlüsselpaare vorhanden. Eines dieser Schlüsselpaare muss die Sicherheit bieten, die für Anwendungen in der öffentlichen Verwaltung notwendig ist, um die handschriftliche Signatur auf Anträgen etc. zu ersetzen. D.h. unter anderem, dass zumindest ein Schlüsselpaar ein qualifiziertes Zertifikat nach Signaturgesetz besitzten muss.

Die relevanten Funktionen des Security-Layers sind:

• Erstellung der Signatur nach [CMS] und [XMLDSIG]
• Prüfung der Signatur nach CMS und XMLDSIG

Die Prüfung der Signatur wurde als Funktion aufgenommen, um Applikationen, die sich laut Modell nicht um die Details der Signatur kümmern müssen, ein Werkzeug zum Verifizieren und Validieren eben dieser Signaturen zur Verfügung zu stellen.

1.2 Zugriff auf Datenspeicher

Die Security-Kapsel enthält Datenspeicher (Infoboxen), in die Applikationen Daten ablegen bzw. aus denen Applikationen Daten abrufen können. Es ist dabei für die Applikation transparent, ob sich die Daten auf der Bürgerkarte oder an einem anderen Ort (auf den die Kapsel Zugriff hat) befinden.

Der Zugriffschutz auf Daten in diesen Infoboxen kann auf vielfältige Weise ausgeführt sein, wobei die Verantwortung für das Zugriffsschutzmanagement die Security-Kapsel (in Zusammenarbeit mit der Bürgerkarte) trägt. Vorstellbar wäre etwa, Daten erst durch Eingabe einer Pin durch den/die BürgerIn für Lese- bzw. Schreibzugriffe zugänglich zu machen.

Die relevanten Funktionen des Security-Layer sind:

• Abfrage von verfügbaren Infoboxen
• Lesen von Daten in einer Infobox
• Verändern von Daten in einer Infobox

Die Zugriffe auf diese Infoboxen können parametrisiert erfolgen. Im Besonderen werden zwei verschiedene Typen von Infoboxen unterschieden: den Datentyp (entspricht Dateien auf Datenträgern) und den Feldtyp (speichert mehrere Datensätze als Schlüssel-Wert Paar ab.)

1.3 Nutzfunktionen

Die Security-Kapsel bietet zusätzlich noch eine Reihe von Nutzfunktionen, die das Arbeiten bzw. gängige Aufgaben erleichtern.

Erzeugen von zertifizierten Sessionkeys.

Die Übertragung vertraulicher Daten ist nicht primäres Ziel der Bürgerkarte. Die Inhaltsverschlüsselung wird aber in vielen Anwendungen mit der Authentizität von Daten gekoppelt. Diese Funktionen erfüllt ein Session-Zertifikat. Die Generierung solcher Session-Zertifikate wird von der Security Schnittstelle unterstützt.

Aushandeln von symmetrischen Geheimnissen

Die Kapsel bietet Funktionen auf Basis asymmetrischer Kryptographie. Um die symmetrische Verschlüsselung von Daten zu unterstützen kann ein gemeinsames Geheimnis (ein symmetrischer Schlüssel) nach Diffie-Hellman [DH-DSA, DH-RSA]ausgehandelt werden.

Abfrage der Kapseleigenschaften

Um mit unterschiedlichen Security-Kapseln bzw. unterschiedlich parametrisierten Security-Kapseln kommunizieren zu können, können Applikationen wichtige Eigenschaften der Kapsel abfragen (z.B. Name der Signaturdaten, Formate des Trusted Viewer)

Abfragen des Status der Bürgerkarte

Applikationen wird die Möglichkeit geboten auf das Entfernen bzw. Einführen der Bürgerkarte zu warten.

2. Referenzen

CMS

Hously, R.: RFC 2630: Cryptographic Message Syntax (CMS). IETF Request For Comment, Juni 1999.
http://www.ietf.org/rfc/rfc2630.txt

XMLDSIG

Donald Eastlake, Joseph Reagle und David Solo: XML-Signature Syntax and Processing. W3C Recommendation, Februar 2001. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

DH-RSA

E. Rescorla: RFC 2631: Diffie-Hellman Key Agreement Method, Juni 1999.
http://www.ietf.org/rfc/rfc2631.txt

DH-DSA

IEEE: IEEE Standard P1363: Standard Specifications for Public Key Cryptography, 2000
Section 6.2.1: DLSVDP-DH (Discrete Logarithm Secret Value Derivation Primitive, Diffie-Hellman version - no cofactor exponentiation)