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.0.3
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

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:

Konzeptuelles Modell

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:

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:

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:

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)