Anforderungen Bürgerkarten-Umgebung

Bundesministerium für öffentliche Leistung und Sport Chief Information Office Austria IKT-Stabsstelle des Bundes 1 2 Anforderungen Bürgerkarten-Umgebung 3 4 5 Anforderungen an die Bürgerkarten-Umgebung nach dem Konzept Bürgerkarte 6 Dokumenteninformation Bezeichnung Kurzbezeichnung Anforderungen an die Bürgerkarten-Umgebung nach dem Konzept Bürgerkarte Anforderungen Bürgerkarten-Umgebung Version 1.0.0 Datum 12. 04. 2002 Dokumentenklasse Konvention Dokumentenstadium Öffentlicher Entwurf Kurzbeschreibung Autoren Arbeitsgruppe Dieses Dokument beschreibt die Anforderungen an die Bürgerkarten- Umgebung, also jene konzeptuelle Einheit, die über die Schnittstelle des Security-Layer angesprochen wird. Gregor Karlinger (gregor.karlinger@cio.gv.at) CIO des Bundes, Operative Unit 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 1/8

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Inhalt Dokumenteninformation...1 Inhalt...2 1 Einleitung...3 1.1 Begriffsbildung...3 1.2 Aufbau dieses Dokuments...3 1.3 Schlüsselwörter...4 2 Anforderungen...4 2.1 Sichere elektronische Signatur...4 2.2 Elektronische Signatur und Authentifikation...4 2.3 Weitere Schlüsselpaare...4 2.4 Datenspeicher...5 2.4.1 Logische Sicht...5 2.4.2 Zugriffsmanagement...5 2.4.3 Daten...6 2.5 Symmetrisches Geheimnis...7 Referenzen...8 24 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 2/8

25 26 27 28 29 30 31 32 33 34 1 Einleitung Dieses Dokument beschreibt die Anforderungen an die Bürgerkarten-Umgebung, also jene konzeptuelle Einheit, die über die Schnittstelle des Security-Layer angesprochen wird. 1.1 Begriffsbildung Den Kern des Konzepts Bürgerkarte bildet der Bürgerkarten-Token. Er ist ein abgeschlossenes System, das die Berechnung kryptografischer Funktionen erlaubt und einen Datenspeicher zur Verfügung stellt. Nach heutigem Stand der Technik kann das beispielsweise eine Chipkarte oder ein USB-Token sein. Die konkreten Anforderungen an einen Bürgerkarten-Token werden aus den Anforderungen an die Bürgerkarten-Umgebung in Abschnitt 2 abgeleitet und beschrieben. 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 Diesen Kern des Konzepts umschließt die Bürgerkarten-Umgebung. Sie kapselt in Ergänzung zum Bürgerkarten-Token jene Komponenten, die notwendig sind, um die über die Schnittstelle des Security-Layer festgeschriebene Funktionalität einer Applikation zur Verfügung stellen zu können. Welche zusätzliche Komponenten sich in der Bürgerkarten- Umgebung befinden, ergibt sich aus der Funktionalität des Security-Layer sowie den daraus abgeleiteten Anforderungen an die Bürgerkarten-Umgebung, die in Abschnitt 2 beschrieben werden. Die Schnittstelle zur Bürgerkarten-Umgebung heißt Security-Layer. Über diese Schnittstelle greift eine Applikation auf die Funktionalität des Konzepts Bürgerkarte zu, um beispielsweise eine sichere elektronische Signatur zu erzeugen oder vom Datenspeicher der Bürgerkarten- Umgebung zu lesen. Für eine detaillierte Beschreibung dieser Schnittstelle siehe [SecLayer]. 1.2 Aufbau dieses Dokuments Kapitel 2 beschreibt die einzelnen Anforderungen an die Bürgerkarten-Umgebung, die sich aus der Funktionalität der Schnittstelle Security-Layer ergeben. Für jede einzelne Anforderung werden falls notwendig zusätzlich die sich daraus ergebenden Anforderungen an den Bürgerkarten-Token beschrieben. 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 3/8

51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 1.3 Schlüsselwörter Dieses Dokument verwendet die Schlüsselwörter MUSS, DARF NICHT, ERFORDERLICH, SOLLTE, SOLLTE NICHT, EMPFOHLEN, DARF, und OPTIONAL zur Kategorisierung der Anforderungen. Diese Schlüsselwörter sind analog zu ihren englischsprachigen Entsprechungen MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, und OPTIONAL zu handhaben, deren Interpretation in [Keywords] festgelegt ist. 2 Anforderungen 2.1 Sichere elektronische Signatur Die Bürgerkarten-Umgebung MUSS die Erstellung einer sicheren elektronischen Signatur ermöglichen. Die Rahmenbedingungen zur Erstellung einer sicheren elektronischen Signatur sind im Signaturgesetz [SigG] sowie in der Signaturverordung [SigV] festgeschrieben. Für die Bürgerkarten-Umgebung bedeutet diese Anforderung unter anderem, dass der Zertifizierungsdiensteanbieter für die korrekte Funktion der empfohlenen Komponenten für PIN-Eingabe, Hash-Berechnung und sichere Anzeige verantwortlich ist. An das zugrunde liegende kryptografische Signaturverfahren werden keine über die Festlegungen der Signaturverordnung (Anhang 2) hinausgehenden Anforderungen gestellt. Es wird jedoch EMPFOHLEN, aufgrund der erhöhten Zukunftssicherheit das Verfahren DSA basierend auf elliptischen Kurven zu verwenden. Wichtigste sich daraus ergebende Konsequenz für den Bürgerkarten-Token ist die ERFORDERLICHE Eignung als sichere Signaturerstellungseinheit. 2.2 Elektronische Signatur und Authentifikation Neben der sicheren elektronischen Signatur MUSS die Bürgerkarten-Umgebung ein weiteres Schlüsselpaar verwalten, mit dessen Hilfe eine gewöhnliche elektronische Signatur erstellt sowie Authentifikation betrieben werden kann. Als zugrunde liegendes kryptografisches Signaturverfahren MUSS eines der in Anhang 2 der Signaturverordung aufgezählten Verfahren verwendet werden. Es wird EMPFOHLEN, aufgrund der erhöhten Zukunftssicherheit das Verfahren DSA basierend auf elliptischen Kurven zu verwenden. Es wird EMPFOHLEN, die Signaturerstellungsdaten des weiteren Schlüsselpaares auf dem Bürgerkarten-Token zu halten; dies bedeutet, dass sie bei zur Ausführung von kryptografischen Befehlen den Bürgerkarten-Token nie verlassen dürfen. Werden die Signaturerstellungsdaten andernorts verwahrt, MÜSSEN sie dem Stand der Technik entsprechend verschlüsselt werden, wobei die Entschlüsselung nur dem Anwender der Bürgerkarten-Umgebung möglich sein darf (vergleiche etwa [PKCS12] unter Verwendung eines qualitativ hochwertigen Passwortes). Für das zugehörige Zertifikat gilt die Anforderung, dass die Registrierung des Bürgers entsprechend den in [ETSIQCP], Abschnitt 7.3.1 für die Policy QCP public festgelegten Regeln erfolgen MUSS. 2.3 Weitere Schlüsselpaare Optional DARF die Bürgerkarten-Umgebung weitere Schlüsselpaare verwalten, die für elektronische Signatur, Authentifikation oder Verschlüsselung verwendet werden können. 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 4/8

92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 2.4 Datenspeicher Neben der Erstellung von elektronischen Signaturen ist die zweite wesentliche Funktion der Bürgerkarten-Umgebung die Verwaltung eines Datenspeichers, auf den die Applikation über die Schnittstelle Security-Layer zugreifen kann. 2.4.1 Logische Sicht Der Datenspeicher, den die Bürgerkarten-Umgebung der Applikation anbietet, kann sich aus einer Reihe von physikalischen Datenspeichern zusammensetzen, die sich an unterschiedlichen Orten befinden. Zum einen existiert Datenspeicher auf dem Bürgerkarten-Token selbst. Bestimmte Daten müssen auf dem Bürgerkarten-Token verwaltet werden, für die meisten Daten ist ein bestimmter Ort der Daten jedoch nicht vorgeschrieben (vergleiche Abschnitt 2.4.3). Weitere mögliche Datenspeicher, welche die Bürgerkarten-Umgebung verwaltet, können etwa ein Speicherbereich auf der Festplatte jenes Rechners sein, auf dem die Bürgerkarten- Umgebung betrieben wird, oder aber auch ein Datenspeicher, der von der Bürgerkarten- Umgebung über ein Webservice angesprochen werden kann. Für die Applikation, die über den Security-Layer auf den Datenspeicher zugreift, ist die Partitionierung des logischen Speichers in mehrere physikalische Speicher transparent. 2.4.2 Zugriffsmanagement Der Datenspeicher, auf den die Applikation über den Security-Layer Zugriff hat, untergliedert sich in logische Einheiten, die so genannten Infoboxen. Eine solche logische Einheit muss von der Bürgerkarten-Umgebung jedoch nicht ausschließlich auf einem physikalischen Speicher verwaltet werden; vielmehr können die Daten für eine Infobox auch über mehrere physikalische Speicher verteilt sein. Die Bürgerkarten-Umgebung MUSS die Vergabe und Verwaltung von Zugriffsrechten auf Basis dieser Infoboxen ermöglichen. Damit kann der Bürger den Zugriff auf eine Infobox ohne sein Wissen durch eine Applikation ausschließen. Das Zugriffsmanagement MUSS folgende Eigenschaften aufweisen: Die Zugriffsrechte MÜSSEN für jede Infobox getrennt vergeben werden können. Es MÜSSEN unterschiedliche Zugriffsrechte für Lese- und Schreibzugriff vergeben werden können. Als Zugriffsrechte MÜSSEN jedenfalls freier Zugriff, Zugriff nach Bestätigung sowie Zugriff nach Identifikation vergeben werden können: Freier Zugriff bedeutet, dass die Applikation auf die Infobox ohne ein Zutun des Bürgers zugreifen kann. Bei Zugriff nach Bestätigung kann erst auf die Infobox zugegriffen werden, nachdem der Bürger einen entsprechenden Hinweis der Bürgerkarten-Umgebung quittiert. Wird Zugriff nach Identifikation verwendet, muss sich der Bürger identifizieren, bevor die Bürgerkarten-Umgebung der Applikation den Zugriff auf die Infobox erlaubt. Dazu ist etwa die Eingabe eines PINs oder die Verwendung von biometrischen Verfahren vorstellbar. Für jene Daten, die nach den Anforderungen des Abschnitts 2.4.3 direkt auf dem Bürgerkarten-Token gespeichert werden müssen, gelten über das Zugriffsmanagement durch die Bürgerkarten-Umgebung noch die dort festgelegten Vorschriften bezüglich Zugriffsrechteverwaltung durch den Bürgerkarten-Token selbst. 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 5/8

135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 2.4.3 Daten Die nachfolgenden Unterabschnitte regeln, welche Daten des Datenspeichers für die Applikation von der Bürgerkarten-Umgebung in welchem physikalischen Speicher unter welchen Rahmenbedingungen zu verwalten sind. 2.4.3.1 Infobox Zertifikate Die im Security-Layer spezifizierte Infobox Certificates enthält Zertifikate, die im Zusammenhang mit den von der Bürgerkarten-Umgebung verwalteten Schlüsselpaaren stehen. Jedenfalls abrufbar sein MÜSSEN das qualifizierte Zertifikat für die Erstellung der sicheren elektronischen Signatur, als auch das zum weiteren Schlüsselpaar für gewöhnliche Signatur und Authentifikation zugehörige Zertifikat. Das qualifizierte Zertifikat MUSS im Datenspeicher des Bürgerkarten-Tokens abgelegt sein. Für die Speicherung des Zertifikats werden die Distinguished Encoding Rules (DER) für ASN.1 [ASN1DER] EMPFOHLEN. Wird ein anderes Format verwendet, MUSS es offengelegt werden, um auch Dritten den Umgang damit zu ermöglichen. Das Zertifikat MUSS durch Mittel des Bürgerkarten-Tokens selbst vor Schreibzugriffen geschützt werden können. Beispielsweise könnte der Bürgerkarten-Token die Authentifikation der zugreifenden Applikation anhand eines symmetrischen Schlüssels verlangen, oder der Bürger identifiziert sich mittels PIN oder eines biometrischen Merkmals. Ein Schutz vor Lesezugriffen ist grundsätzlich nicht erforderlich; es DARF aber die Identifikation des Bürgers verlangt werden, wenn dieser Mechanismus vom Bürger deaktivierbar ist. Das Zertifikat für das weitere Schlüsselpaar SOLLTE im Datenspeicher des Bürgerkarten- Tokens abgelegt sein, wenn auch die zugehörigen Signaturerstellungsdaten auf dem Bürgerkarten-Token verwahrt werden. Wird das Zertifikat auf dem Bürgerkarten-Token gespeichert, gelten hinsichtlich der Kodierung sowie des Zugriffsschutzes dieselben Anforderungen wie für das qualifizierte Zertifikat. Zusätzlich zu den beiden besprochenen Zertifikaten MUSS die Bürgerkarten-Umgebung die Zertifikate für die in Abschnitt 2.3 erwähnten weiteren Schlüsselpaare abrufbar machen und SOLLTE für jedes abrufbare Zertifikat auch sämtliche Zertifikate des jeweiligen Zertifizierungspfades bereithalten. 2.4.3.2 Infobox Personenbindung Die im Security-Layer spezifizierte Infobox IdentityLink enthält die Personenbindung (siehe [PersBin]) des Bürgers. Die über diese Schnittstelle abrufbare Personenbindung MUSS die öffentlichen Schlüssel der beiden von der Bürgerkarten-Umgebung jedenfalls zu verwahrenden Schlüsselpaare beinhalten. Stellt die Bürgerkarten-Umgebung noch weitere Schlüsselpaare zur Verfügung, DÜRFEN die entsprechenden öffentlichen Schlüssel ebenfalls in der Personenbindung aufscheinen. Im Datenspeicher des Bürgerkarten-Tokens MUSS eine Personenbindung gespeichert sein, welche die öffentlichen Schlüssel zumindest jener Schlüsselpaare beinhaltet, die auf dem Bürgerkarten-Token verwahrt werden. Zur Speicherung der Personenbindung auf dem Bürgerkarten-Token wird das in [PersBin] spezifizierte Format EMPFOHLEN. Wird ein anderes Format verwendet, MUSS es offengelegt werden, um auch Dritten den Umgang damit zu ermöglichen. Die Personenbindung auf dem Bürgerkarten-Token MUSS durch Mittel des Bürgerkarten- Tokens selbst vor Schreibzugriffen geschützt werden können, und zwar entweder mittels 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 6/8

181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 Schlüssel oder PIN. Ein Schutz vor Lesezugriffen ist grundsätzlich nicht erforderlich; es DARF aber die Identifikation des Bürgers verlangt werden, wenn dieser Mechanismus vom Bürger deaktivierbar ist. 2.4.3.3 Infobox Vollmachten Die im Security-Layer spezifizierte Infobox Mandates enthält Vollmachten des Bürgers, in denen er als Vollmachtnehmer aufscheint. Eine Spezifikation zum Format solcher Vollmachten wird von der Operativen Unit des CIO in naher Zukunft veröffentlicht werden. Vollmachten DÜRFEN auf dem Bürgerkarten-Token gespeichert werden. In Anbetracht der umfangreichen Datenstruktur einer Vollmacht sowie der hohen Wahrscheinlichkeit, dass ein Bürger mehrere Vollmachten verwahren möchte, scheint aber eine Speicherung von Vollmachten an einem anderen Ort innerhalb der Bürgerkarten-Umgebung sinnvoller. Insbesondere die Verwahrung durch ein Webservice in Verbindung mit den im nächsten Abschnitt behandelten Verweisen gestattet eine große Flexibilität bezüglich des Einsatzes eines Bürgerkarten-Tokens in unterschiedlichen Bürgerkarten-Umgebungen. 2.4.3.4 Verweise Damit ein Bürgerkarten-Token in unterschiedlichen Bürgerkarten-Umgebungen komfortabel verwendet werden kann (beispielsweise am PC des Bürgers und an einem öffentlichen Terminal), sollten möglichst viele der über die Schnittstelle Security-Layer abrufbaren Daten im Datenspeicher des Bürgerkarten-Token verwahrt werden. Dieser Forderung steht allerdings die eingeschränkte Größe des verfügbaren Datenspeichers auf einem typischen Bürgerkarten-Token entgegen. Zur Lösung dieses Problems wird EMPFOHLEN, auf dem Bürgerkarten-Token einen eigenen Datenbereich für Verweise zur Verfügung zu stellen. Ein Verweis ist dabei eine Datenstruktur geringen Umfangs, die der Bürgerkarten-Umgebung anzeigt, wo sich weitere Daten befinden. Möchte der Bürger beispielsweise eine umfangreiche Anzahl an Vollmachten in unterschiedlichen Bürgerkarten-Umgebungen einsetzen, deponiert er diese Vollmachten bei einem Webservice. Auf seinem Bürgerkarten-Token speichert er jedoch lediglich den Verweis auf die Abrufseite des Webservice. So kann er seine Vollmachten in jeder beliebigen Bürgerkarten-Umgebung komfortabel verwenden. Eine Spezifikation zum Format von Verweisen wird von der Operativen Unit des CIO in naher Zukunft veröffentlicht werden. 2.5 Symmetrisches Geheimnis Der Befehl CreateSymmetricKeyRequest der Schnittstelle Security-Layer erlaubt die Berechung eines symmetrischen Geheimnisses nach Diffie-Hellman (siehe [SecLayer], Schnittstellenspezifikation, Abschnitt 6.3). Damit für eine solche Berechnung ein auf dem Bürgerkarten-Token verwahrtes Schlüsselpaar verwendet werden kann, muss der Bürgerkarten-Token einen entsprechenden Befehl zur Verfügung stellen. Die Bereitstellung eines solchen Befehls ist bezüglich aller auf dem Bürgerkarten-Token verwahrten Schlüsselpaare OPTIONAL. 220 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 7/8

221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Referenzen ASN1DER Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). ITU-T Rec. X.690 (1997). Abgerufen aus dem World Wide Web am 12. April 2002 unter http://www.itu.int/itu-t/studygroups/com17/languages/x.690_1297.pdf ETSIQCP European Telecommunications Standards Institute: ETSI TS 101456: Policy requirements for certification authorities issuing qualified certificates, v1.2.1. Technical Specification, April 2002. Abgerufen aus dem World Wide Web am 12. April 2002 unter http://pda.etsi.org/pda/home.asp?wki_id=13387. Keywords Bradner, Scott: Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment, November 1996. Abgerufen aus dem World Wide Web am 12. April 2002 unter http://www.ietf.org/rfc/rfc2119.txt. PersBin Hollosi, Arno: XML-Spezifikation der Personenbindung. Konvention zum e- Government Austria erarbeitet vom CIO des Bundes, Opertive Unit. Öffentlicher Entwurf, Version 1.0.1, 11. April 2002. Abgerufen aus dem World Wide Web am 12. April 2002 unter http://www.buergerkarte.at/konzept/personenbindung/spezifikation/20020411/. PKCS12 PKCS 12 v1.0: Personal Information Exchange Syntax. RSA Laboratories, June 1999. Abgerufen aus dem World Wide Web am 12. April 2002 unter ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf. SecLayer Hollosi, Arno und Karlinger, Gregor: Security-Layer für das Konzept Bürgerkarte. Konvention zum e-government Austria erarbeitet vom CIO des Bundes, Operative Unit. Öffentlicher Entwurf, Version 1.0.0, 25. Februar 2002. Abgerufen aus dem World Wide Web am 12. April 2002 unter http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20020225/. SigG BGBl I Nr. 190/1999 idf BGBl I Nr. 152/2001. SigV BGBl II Nr. 30/2000. 12. 04. 2002 Anforderungen Bürgerkarten-Umgebung Seite 8/8