Logo BMÖLS Open Interfaces
für das eGovernment
Logo A-SIT

Security-Layer für das Konzept Bürgerkarte

Einführung


Dokumenteninformation

Bezeichnung Einführung zum Security-Layer für das Konzept Bürgerkarte
Kurzbezeichnung Einführung Security-Layer
Version 1.1.0
Datum 31. 08. 2002
Dokumentklasse Erläuterung
Dokumentstadium Öffentlicher Entwurf
Kurzbeschreibung Das vorliegende Dokument gibt eine Einführung in das Konzept des Security-Layers der Bürgerkarte.
Autoren Arno Hollosi (arno.hollosi@cio.gv.at)
Gregor Karlinger (gregor.karlinger@cio.gv.at)
Arbeitsgruppe BMÖLS, CIO des Bundes, Operative Unit
© Diese Spezifikation wird von A-SIT und dem BMÖLS zur Verfügung gestellt. Die Verwendung ohne Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. Eine Erweiterung der Spezifikation ist erlaubt, jedoch muss dies eindeutig gekennzeichnet sein, und es muss die erweiterte Spezifikation frei zur Verfügung gestellt werden.

Inhalt

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

1 Einführung

Das Konzept Bürgerkarte beschreibt verschiedene Funktionalitäten, 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:

Konzeptuelles Modell

Das Bild zeigt wo die Schnittstelle angesiedelt ist. Die Applikation läuft am Rechner des/der BenutzerIn. Sie kommuniziert über den Security-Layer mit der Bürgerkarten-Umgebung, welche als abgeschlossene Einheit alle Bürgerkartenfunktionen kapselt. Applikationen kommunizieren nur über den Security-Layer mit der Bürgerkarte. In diesem Sinne ist die Bürgerkarten-Umgebung 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 Bürgerkarten-Umgebung kann daher z.B. auch in einer externen Einheit, wie einem Mobiltelefon oder einem Palmtop implementiert sein.

Anmerkung zur Terminologie:

Im Folgenden soll kurz die Funktionalität der Bürgerkarten-Umgebung 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 Bürgerkarten-Umgebung selbst angesiedelt (z.B. Verifikation von Signaturen).

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:

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 Bürgerkarten-Umgebung 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 Umgebung 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 Bürgerkarten-Umgebung (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:

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 Bürgerkarten-Umgebung bietet zusätzlich noch eine Reihe von Nutzfunktionen, die das Arbeiten bzw. gängige Aufgaben erleichtern.

Aushandeln von symmetrischen Geheimnissen
Die Bürgerkarten-Umgebung 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 Umgebungseigenschaften
Um mit unterschiedlichen Bürgerkarten-Umgebungen bzw. unterschiedlich parametrisierten Umgebungen kommunizieren zu können, können Applikationen wichtige Eigenschaften der Bürgerkarten-Umgebung 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)

3 Historie

Version 1.1.0 vom 31.08.2002: Veränderungen zu Version 1.0.3