Logo
Zugriffsschutz auf Funktionen der Bürgerkarten-Umgebung

Konvention

1.2.1
Empfehlung
Kurzbeschreibung

Dieses Dokument beschreibt die Art und Weise wie Funktionen der Bürgerkarten-Umgebung vor unbefugtem Zugriff geschützt werden können:

  • Schutzfunktionen beim Zugriff durch Aufruf der Bindungen TCP und TLS

  • Schutzfunktionen beim Zugriff durch Aufruf der Bindungen HTTP und HTTPS

  • Schutzfunktionen beim Zugriff über die Befehlskaskadierung der Bindungen HTTP und HTTPS

Autoren:

Arno Hollosi

Gregor Karlinger

Thomas Rössler

Martin Centner

et al.
Projektteam/Arbeitsgruppe
AG Bürgerkarte
Datum: 1.3.2005

Inhaltsverzeichnis

1. Allgemeines
1.1. Namenskonventionen
1.2. Schlüsselwörter
2. Klassifizierung des Zugriffs
2.1. Authentisierungsklassen
2.2. Bedingungen an Zertifikate
2.3. Einstufung der Befehle
3. Zugriffsschutz
3.1. Regeln
3.2. Chains
3.3. Voreinstellungen für eine lokale Bürgerkarten-Umgebung
3.4. Voreinstellungen für eine serverbasierte Bürgerkarten-Umgebung
4. Sicherheits- und Bedrohungsanalyse
4.1. Schutzbedürfnis der Signaturerstellungsbefehle
4.2. Cross-Site-Scripting Attacken
Glossar
Referenzen
5. 6 Historie

Dieses Dokument beschreibt die Art und Weise wie Funktionen der Bürgerkarten-Umgebung vor unbefugtem Zugriff geschützt werden können:

  • Schutzfunktionen beim Zugriff durch Aufruf der Bindungen TCP und TLS

  • Schutzfunktionen beim Zugriff durch Aufruf der Bindungen HTTP und HTTPS

  • Schutzfunktionen beim Zugriff über die Befehlskaskadierung der Bindungen HTTP und HTTPS

Ein Zugriff auf einen Befehl der Bürgerkarte kann hinsichtlich der Authentisierung in eine der vier Klassen anonym, pseudoanonym, certified und certifiedGovAgency eingeteilt werden. Zur Vornahme der Einteilung in diese Klassen sind folgende Fragen zu beantworten:

Kann der Ursprung der Befehlsanfrage festgestellt werden?

Zur Beantwortung dieser Frage werden Parameter aus den Bindungsprotokollen wie z.B. die Quell-IP-Adresse, der HTTP-Header Referer, der Parameter DataURL der HTTP-Bindung, oder Informationen aus verwendeten Client- oder Serverzertifikaten verwendet.

Kann das Ziel der Befehlsantwort festgestellt werden?

Zur Beantwortung dieser Frage werden ebenfalls Parameter aus den Bindungsprotokollen wie z.B. Quell-IP-Adresse, der Parameter DataURL der HTTP-Bindung, oder Informationen aus verwendeten Client- oder Serverzertifikaten verwendet.

Die vier Authentisierungsklassen lassen sich vereinfacht wie folgt charakterisieren:

anonym

Die Bürgerkarten-Umgebung hat weder Informationen über den Ursprung der Befehlsanfrage noch über das Ziel der Befehlsantwort.

pseudoanonym

Die Bürgerkarten-Umgebung besitzt zwar Informationen über den Ursprung der Befehlsanfrage und/oder über das Ziel der Befehlsantwort, diese Informationen basieren jedoch auf nicht gesicherten Parametern der Bindungen.

certified

Die Bürgerkarten-Umgebung hat gesicherte (zertifikatsbasierende) Informationen über den Ursprung der Befehlsanfrage und/oder das Ziel der Befehlsantwort.

certifiedGovAgency

Die Bürgerkarten-Umgebung hat gesicherte (zertifikatsbasierende) Informationen über den Ursprung der Befehlsanfrage und/oder das Ziel der Befehlsantwort. Aus diesen Informationen geht hervor, dass es sich bei Ursprung bzw. Ziel um eine Behörde oder einen Dienstleister der Behörde handelt, d.h. der Domainname, auf den das Zertifikat ausgestellt ist, matched das Pattern *.gv.at, oder das Zertifikat enthält entweder die Zertifikatserweiterung Verwaltungseigenschaft oder die Zertifikatserweiterung Dienstleistereigenschaft [VerwEig].

Die nachfolgende Grafik enthält den Entscheidungsbaum zur Zuordnung eines Zugriffs auf einen Befehl der Bürgerkarten-Umgebung in eine dieser vier Authentisierungsklassen. Aus Gründen der Übersichtlichkeit wurde in in der Grafik auf die weitere Unterscheidung zwischen certified und certifiedGovAgency verzichtet.


Zunächst ist nach der Herkunft der Befehlsanfrage zu unterscheiden. Eine Befehlsanfrage kann aus einer der vier Bindungen TCP, TLS, HTTP und HTTPS oder vom DataURL-Server (Server, der mit dem Parameter DataURL der HTTP-Bindung bezeichnet wird, und von dem im Zuge der Befehlskaskadierung weitere Befehlsanfragen an die Bürgerkarten-Umgebung übermittelt werden können) eintreffen.

Kommt eine Befehlsanfrage aus der Bindung TCP, fällt der Zugriff in die Klasse pseudoanonym, als Identifikations-URL wird die Source-IP-Adresse der TCP-Verbindung vermerkt.

Entspringt eine Befehlsanfrage aus der Bindung TLS, ist in einem weiteren Schritt zu prüfen, ob sich in der TLS-Verbindung zur Bürgerkarten-Umgebung der Anfrager mittels Client-Zertifikat identifiziert hat. Falls ja, fällt der Zugriff in die Klasse certified, falls nein, fällt er (analog zur Bindung TCP) in die Klasse pseudoanonym. In beiden Fällen wird als Identifikations-URL die Source-IP-Adresse der TLS-Verbindung vermerkt.

Stammt eine Befehlsanfrage aus der Bindung HTTP, ist in einem weiteren Schritt zu prüfen, ob bereits die Ausführung des Befehls schützenswert ist oder lediglich die Befehlsantwort (vergleiche dazu Abschnitt 2.3, „Einstufung der Befehle“). Ist bereits die Befehlsausführung schützenswert, ist der Zugriff der Klasse anonym zuzuordnen, da diesfalls für die Zuordnung des Zugriffs der Ursprung der Befehlsanfrage maßgeblich ist. Die IP-Adresse der Befehlsanfrage ist zwar bekannt, jedoch muss in den allermeisten Fällen davon ausgegangen werden, dass die Befehlsanfrage über die Bindung HTTP vom Browser des Bürgers kommt, und dadurch der Browser sozusagen als Proxy agiert und die tatsächliche Herkunft der Befehlsanfrage überdeckt. Als Identifikations-URL wird die Source-IP-Adresse der HTTP-Verbindung vermerkt. Ist hingegen die Befehlsantwort schützenswert, ist das Ziel der Befehlsantwort maßgeblich für die Zuordnung des Zugriffs. Es ist daher in einem nächsten Schritt zu prüfen, ob der Parameter DataURL dieser Bindung verwendet wird. Falls nein, liegt keine Information über das Ziel der Befehlsantwort vor; der Zugriff fällt in die Klasse anonym, als Identifikations-URL wird die Source-IP-Adresse der HTTP-Verbindung vermerkt. Falls ja, ist in einem abschließenden Schritt das Protokoll des Parameters DataURL zu analysieren. Handelt es sich dabei um http, fällt der Zugriff in die Klasse pseudoanonym, handelt es sich hingegen um https, ist der Zugriff der Klasse certified zuzuordnen, da die Information über das Ziel der Befehlsantwort über das Zertifikat des Servers hinter der DataURL gesichert ist. In beiden Fällen wird als Identifikations-URL die DataURL vermerkt.

Erreicht die Befehlsanfrage die Bürgerkarten-Umgebung über die Bindung HTTPS, ist in einem weiteren Schritt zu prüfen, ob sich in der darunterliegenden TLS-Verbindung der Anfrager mittels Client-Zertifikat identifiziert hat. Falls nein, sind beginnend mit der Prüfung, ob die Befehlsausführung oder die Befehlsantwort schützenswert sind, die selben weiteren Prüfungen wie bei der Bindung HTTP anzuwenden. Wurde hingegen das Client-Zertifikat verwendet, ist der HTTP-Header Referer zur Feststellung des eigentlichen Ursprungs der Befehlsanfrage auszuwerten. Ist dieser Header vorhanden, ist der Zugriff der Klasse pseudoanonym zuzuordnen, wobei als Identifikations-URL der Wert des Headers festgehalten wird. Fehlt der Header, ist der Zugriff der Klasse certified zuzuordnen, wobei dann als Identifikations-URL die Source-IP-Adresse der HTTPS-Verbindung vermerkt wird.

Wird die Befehlsanfrage über die Befehlskaskadierung der Bindungen HTTP bzw. HTTPS vom DataURL-Server an die Bürgerkarten-Umgebung gerichtet, ist in einem weiteren Schritt das Protokoll jener URL zu analysieren, über welche die Bürgerkarten-Umgebung den DataURL-Server zuvor kontaktiert hat. Handelt es sich dabei um https, fällt der Zugriff in die Klasse certified, da dann über das Zertifikat des DataURL-Servers gesichert der Ursprung der Befehlsanfrage sichergestellt werden kann. Als Identifikations-URL wird die DataURL vermerkt. Handelt es sich hingegen um http, ist in einem weiteren Schritt zu prüfen, ob bereits die Ausführung des Befehls schützenswert ist oder lediglich die Befehlsantwort (vergleiche dazu Abschnitt 2.3, „Einstufung der Befehle“). Ist bereits die Befehlsausführung schützenswert, ist der Zugriff der Klasse pseudoanonym zuzuordnen, da diesfalls für die Zuordnung des Zugriffs der Ursprung der Befehlsanfrage maßgeblich ist. Auch in diesem Fall wird als Identifikations-URL die DataURL vermerkt. Ansonsten verlaufen die weiteren Prüfungen wie im Falle der Bindung HTTP, beginnend mit der Prüfung, ob der Parameter DataURL der Bindung verwendet wird.

Die TLS- und HTTPS-Bindung sowie die Verbindung der Bürgerkarten-Umgebung zum DataURL-Server, falls eine DataURL mit Protokoll https verwendet wird, basieren auf dem Protokoll TLS, welches zum Zwecke der Authentisierung von Client und Server Zertifikate nach X.509 [X509] verwendet.

Ein verwendetes Zertifikat ist in allen drei Fällen für die Zuordnung des Zugriffs zu einer der Authentisierungsklassen nur dann relevant, wenn es von einem Zertifizierungsdiensteanbieter stammt, der von der Bürgerkarten-Umgebung als vertrauenswürdig eingestuft wird.

Die nachfolgende Tabelle gibt für jeden der Befehle der Schnittstelle Security-Layer an, ob die Befehlsausführung oder die Befehlsantwort schützenswert ist (vergleiche dazu den Entscheidungsbaum zur Einteilung eines Zugriffs in Abschnitt 2.1, „Authentisierungsklassen“).

Befehl schützenswert
Signatur nach CMS erstellen (sl:CreateCMSSignatureRequest) Befehlsantwort
Signatur nach XMLDSIG erstellen (sl:CreateXMLSignatureRequest) Befehlsantwort
Signatur nach CMS prüfen (sl:VerifyCMSSignatureRequest) Befehlsantwort
Signatur nach XMLDSIG prüfen (sl:VerifyXMLSignatureRequest) Befehlsantwort
Abfrage verfügbarer Infoboxen (sl:InfoboxAvailableRequest) Befehlsantwort
Lesen von Infobox-Daten (sl:InfoboxReadRequest) Befehlsantwort
Verändern von Infoboxdaten (sl:InfoboxUpdateRequest) Befehlsausführung
Anlegen einer Infobox (sl:InfoboxCreateRequest) Befehlsausführung
Löschen einer Infobox (sl:InfoboxDeleteRequest) Befehlsausführung
Abfrage der Kapseleigenschaften (sl:GetPropertiesRequest) Befehlsantwort
Abfrage des Kartenstatus (sl:GetStatusRequest) Befehlsantwort
NOP (sl:NullOperationRequest) Befehlsantwort
Hashwert-Berechnung (sl:CreateHashRequest) Befehlsantwort
Hashwert-Verifikation (sl:VerifyHashRequest) Befehlsantwort
Verschlüsselung als CMS-Nachricht (sl:EncryptCMSRequest) Befehlsantwort
Verschlüsselung als XML-Nachricht (sl:EncryptXMLRequest) Befehlsantwort
Entschlüsselung einer CMS-Nachricht (sl:DecryptCMSRequest) Befehlsantwort
Entschlüsselung einer XML-Nachricht (sl:DecryptXMLRequest) Befehlsantwort

Implementoren steht es frei, welches Regelwerk in welcher Granularität sie basierend auf der vorgestellten Klassifizierung implementieren. Der Schutz des im Folgenden vorgestellten Regelwerks MUSS jedoch jedenfalls erfüllt sein.

Regeln beschreiben eine Verknüpfung von Eingangsdaten und einer daraus resultierende Aktion bzw. Benutzerinteraktion. Regeln werden in Chains organisiert und ihrer Reihenfolge nach abgearbeitet. Die erste Regel, die zutrifft wird ausgeführt. Diese einfache Priorisierung von Regeln ist für die Zwecke des Zugriffsschutzes ausreichend.

Authentisierungsklasse

Die Authentisierungsklasse, welche für ein Zutreffen der Regel mindestens erfüllt sein muss. Gültige Werte sind: anonym, pseudoanonym, certified, certifiedGovAgency (vergleiche Abschnitt 2.1, „Authentisierungsklassen“).

Identifikationsbegriff

Dieses Eingangsdatum muss die Identifikations-URL (vergleiche Abschnitt 2.1, „Authentisierungsklassen“) der Authentisierungsklasse (Ursprung der Befehlsanfrage bzw. Ziel der Befehlsantwort) matchen. Mögliche Werte sind Domänennamen, IP-Adressen und URLs. Ein Domänenname bzw. eine IP-Adresse muss den Server-Teil der Identifikations-URL matchen, eine URL die gesamte Identifikations-URL. Auch hier können Wildcards eingesetzt werden:

  • * matched jeden beliebigen Wert;

  • für Domänennamen ist die einmalige Angabe einer Wildcard * für ein oder mehrere Domänenteile am Beginn des Patterns (z.B. *.gv.at oder *.cio.gv.at, nicht aber *io.gv.at) erlaubt;

  • für IP-Adressen ist die einmalige Angabe einer Wildcard * für ein oder mehrere Bytes der IP-Adresse am Ende des Patterns (z.B. 193.170.* oder 193.170.251.*, nicht aber 193.170.25*) erlaubt;

  • Für URLs ist die einmalige Angabe einer Wildcard am Ende der URL erlaubt (z.B. https://finanzonline.bmf.gv.at/arbeitnehmerveranlagung/*).

Befehlsname

Der lokale Name der Befehlsanfrage der Schnittstelle Security-Layer (z.B. InfoboxReadRequest). Ein Teil des Namens mit abschließender Wildcard '*' (z.B. Infobox* für alle Infobox-Befehle), oder eine Wildcard '*' für alle Befehle ist zulässig.

Befehlsparameter

Abhängig vom jeweiligen Befehl der Schnittstelle Security-Layer sind ein oder mehrere Parameter anzugeben. Bei Infobox-Befehlen gibt der Parameter InfoboxIdentifier den Namen der behandelten Infobox an. Bei Befehlen, die auf private Schlüssel zugreifen, gibt der Parameter KeyboxIdentifier den Name der verwendeten Keybox an. Beim Auslesen der Infoboxen IdenitityLink und Mandates gibt der Parameter PersonIdentifier an, ob die enthaltenen Stammzahlen natürlicher Personen unverändert (base) übermittelt, oder durch die entsprechenden abgeleiteten bereichsspezifischen Personenkennzeichen (derived) ersetzt werden würden. Die Verwendung einer einfachen Wildcard '*' für die Parameter InfoboxIdentifier, KeyboxIdentifier und Identifier ist zulässig.

Mit Hilfe einer Cross-Site-Scripting (XSS)-Attacke (vergleiche [XSS-FAQ]) kann ein Angreifer der Bürgerkarten-Umgebung unter Verwendung der Bindung HTTPS mit Client-Authentisierung einen falschen Ursprung der Befehlsanfrage vortäuschen:

Der Angreifer verleitet den Bürger dazu, einen manipulierten Link auf eine Seite auszuführen, die im Regelwerk der Bürgerkarten-Umgebung als vertrauenswürdig eingestuft ist (z.B. die Seite einer Behörde). Dieser Link enthält als Parameter JavaScript-Elemente, die einen HTTPS-Post zur Bürgerkarten-Umgebung ausführen sollen. Ist die Behördenseite tatsächlich anfällig für eine XSS-Attacke, befinden sich diese Java-Script-Elemente dann in jener Seite, die der Bürger von der eigentlich vertrauenswürdigen Seite als Antwort auf die Verfolgung des Links erhält und werden nach dem Laden der Seite im Browser ausgeführt. Die Bürgerkarten-Umgebung erhält nun über die HTTPS-Bindung eine Befehlsanfrage. Entsprechend dem Entscheidungsbaum aus Abschnitt 2.1, „Authentisierungsklassen“ prüft die Bürgerkarten-Umgebung den HTTP Header Referer, falls sich der Browser des Bürgers mittels Client-Zertifikat identifiziert hat. Dieser Header verweist auf die als vertrauenswürdig eingestufte Seite, daher wird der Zugriff der Klasse pseudoanonym zugeordnet und als Identifikations-URL fälschlicherweise die vertrauenswürdige Seite vermerkt (obwohl der Befehl an die Bürgerkarten-Umgebung eigentlich aus dem eingeschmuggelten JavaScript des Angreifers stammt).

Nicht zuletzt aus diesem Grund sind die Standardeinstellungen für den Zugriffsschutz in den Abschnitten Abschnitt 3.3, „Voreinstellungen für eine lokale Bürgerkarten-Umgebung“ und Abschnitt 3.4, „Voreinstellungen für eine serverbasierte Bürgerkarten-Umgebung“ so gewählt, dass für alle sensiblen Befehle jedenfalls die Bestätigung des Bürgers einzuholen ist.

Glossar

Applikation

Jenes Programm, das Anfragen an die Bürgerkarten-Umgebung über den Security-Layer richtet und die entsprechenden Antworten entgegennimmt und auswertet.

Benutzer-Schnittstelle

Jene Schnittstelle, über die der Bürger mit der Bürgerkarten-Umgebung kommuniziert. Über diese Schnittstelle wird einerseits die Benutzerinteraktion abgewickelt, die gegebenenfalls zur Abwicklung eines Befehls des Security-Layers notwendig ist (z.B. die Anzeige eines zu signierenden Dokuments beim Befehl zur Erzeugung einer XML-Signatur); andererseits kann der Bürger über diese Schnittstelle seine Bürgerkarten-Umgebung nach seinen persönlichen Bedürfnissen konfigurieren (z.B. kann er Einstellungen zum Zugriffsschutz auf seine Infoboxen verändern). Die Vorgaben an die Benutzer-Schnittstelle sind in Minimale Umsetzung des Security-Layers geregelt.

Bürger

Jene Person, die die Funktionen der Bürgerkarten-Umgebung für die sichere Abwicklung von E-Government oder E-Commerce verwenden möchte. Die Ansteuerung der Bürgerkarten-Umgebung erfolgt in der Regel nicht durch den Bürger selbst, sondern durch die Applikation, welche die E-Government oder E-Commerce Anwendung repräsentiert.

Bürgerkarte

Laut [E-GovG], §10 ZI 10 ist die Bürgerkartedie unabhängig von der Umsetzung auf unterschiedlichen technischen Komponenten gebildete logische Einheit, die eine elektronische Signatur mit einer Personenbindung (§ 4 Abs. 2) und den zugehörigen Sicherheitsdaten und -funktionen sowie mit allenfalls vorhandenen Vollmachtsdaten verbindet“. Im Sinne der in den Spezifikationen zur österreichischen Bürgerkarte gebrauchten Terminologie ist die Bürgerkarten-Umgebung die Implementierung der logischen Einheit Bürgerkarte.

Bürgerkarten-Umgebung

Jenes Programm bzw. jener Dienst, der die Funktionalität der Bürgerkarte zur Verfügung stellt. Grundsätzlich vorstellbar ist die Ausführung als Programm, das lokal am Rechner des Bürgers läuft (lokale Bürgerkarten-Umgebung), oder als serverbasierter Dienst, der über das Internet angesprochen wird (serverbasierte Bürgerkarten-Umgebung). Die Interaktion mit diesem Programm bzw. Dienst wird über zwei Schnittstellen abgewickelt: Über die Benutzer-Schnittstelle sowie über den Security-Layer.

Hash-Eingangsdaten

Jene Daten, die für die Berechnung des Hash-Wertes für eine dsig:Reference verwendet werden. Sind für die dsig:Reference Transformationen angegeben, entsprechen diese Daten dem Ergebnis der letzten Transformation. Sind keine Transformationen spezifiziert, gleichen die Hash-Eingangsdaten den Referenz-Eingangsdaten.

Impliziter Transformationsparameter

Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“ in Die österreichische Bürgerkarte - Applikationsschnittstelle Security-Layer

Referenz-Eingangsdaten

Jene Daten, die sich aus der Auflösung der im Attribut URI der dsig:Reference angegebenen URI ergeben. Sind für die dsig:Reference Transformationen angegeben, werden diese Daten als Eingangsdaten zur Berechnung der ersten Transformation verwendet. Sind keine Transformationen spezifiziert, gleichen die Referenz-Eingangsdaten den Hash-Eingangsdaten.

Security-Layer

Jene Schnittstelle, über die die Applikation mit der Bürgerkarten-Umgebung kommuniziert. Das genaue Protokoll, das über diese Schnittstelle gesprochen werden kann, wird in Applikationsschnittstelle Security-Layer spezifiziert. Die möglichen Bindungen dieses Protokolls an Transportschichten wie HTTP oder TCP wird in Transportprotokolle Security-Layer geregelt.

Signaturmanifest

Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“ in Die österreichische Bürgerkarte - Applikationsschnittstelle Security-Layer .

[GIF] Graphics Interchange Format, Version 89a . CompuServe Incorporated, Juli 1990.

[HTTPS] E. Rescorla HTTP over TLS. IETF Request For Comment, Mai 2000

[PersBin] Hollosi, Arno und Karlinger, Gregor: XML-Definition der Personenbindung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.2.2, 14. Februar 2005.

[PersonData] Naber, Larissa: PersonData Struktur - XML Spezifikation . Konvention zum E-Government Austria erarbeitet von der Arbeitsgruppe Kommunikationsarchitekturen. Öffentlicher Entwurf, Version 2.0.0, 14. Oktober 2004.

[Stammzahl] Hollosi, Arno und Hörbe, Rainer: Bildung von Stammzahl und bereichsspezifischem Personenkennzeichen (bPK) . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards sowie vom Bundesminsterium für Inneres. Öffentlicher Entwurf, Version 1.0, 2. Februar 2004.

[TLS] T. Dierks und C. Allen: The TLS Protocol Version 1.0 . IETF Request For Comment, Januar 1999.

[Unicode] The Unicode Consortium. The Unicode Standard, Version 4.0.0 , defined by: The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1).

[VerwEig] Hollosi, Arno: X.509 Zertifikatserweiterungen für die Verwaltung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.0.3, 21. Februar 2005.

Datum Version Änderungen
01. 03. 2005 1.2.1
  • Erratum Erratum 28 in Die österreichische Bürgerkarte - Errata korrigiert.

14. 05. 2004 1.2.0
  • Erstellt.