Open Interfaces für das E-Government

Die österreichische Bürgerkarte

Zugriffsschutz

Dokumenteninformation

Inhalt

1. Allgemeines
   1. Namenskonventionen
   2. Schlüsselwörter
2. Klassifizierung des Zugriffs
   1. Authentisierungsklassen
   2. Bedingungen an Zertifikate
   3. Einstufung der Befehle
3. Zugriffsschutz
   1. Regeln
      1. Eingangsdaten
      2. Aktionen
      3. Benutzerinteraktion
   2. Chains
   3. Voreinstellungen für eine lokale Bürgerkarten-Umgebung
      1. Chain Identification
      2. Chain Command
   4. Voreinstellungen für eine serverbasierte Bürgerkarten-Umgebung
      1. Chain Identification
      2. Chain Command
4. Sicherheits- und Bedrohungsanalyse
5. Referenzen
6. Historie

1 Allgemeines

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

1.1 Namenskonventionen

Zur besseren Lesbarkeit wurde in diesem Dokument auf geschlechtsneutrale Formulierungen verzichtet. Die verwendeten Formulierungen richten sich jedoch ausdrücklich an beide Geschlechter.

Folgende Namenraum-Präfixe werden in dieser Spezifikation zur Kennzeichnung der Namenräume von XML-Elementen verwendet:

1.2 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 Klassifizierung des Zugriffs

2.1 Authentisierungsklassen

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

2.2 Bedingungen an Zertifikate

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.

2.3 Einstufung der Befehle

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

3 Zugriffsschutz

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.

3.1 Regeln

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.

3.1.1 Eingangsdaten

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

Identifikationsbegriff

Dieses Eingangsdatum muss die Identifikations-URL (vergleiche Abschnitt 2.1) 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.

3.1.2 Aktionen

Gültige Aktionen für Regeln sind allow, deny, und Name einer weiteren Chain. Allow bedeutet, dass der Funktionsaufruf zugelassen und durchgeführt werden soll. Deny bedeutet, dass der Funktionsaufruf nicht zugelassen und nicht ausgeführt werden soll. Dar Name einer weiteren Chain bedeutet, dass die Regelabarbeitung mit der ersten Regel der bezeichneten Chain fortgesetzt werden soll.

Für die Aktionen allow und deny muss zusätzlich die Art der Interaktion über die Benutzer-Schnittstelle festgelegt werden.

3.1.3 Benutzerinteraktion

Die Art der Interaktion gibt an, wie der Benutzer in die Befehlsabarbeitung eingebunden werden soll. Im Kontext der Regeln wird damit nur die mindestens durchzuführende Interaktion festgelegt. Abhängig von der abzuarbeitenden Funktion können höherwertige Interaktionen notwendig sein. Es gibt vier Interaktionstypen: none, info, confirm, confirmWithSecret. none bedeutet, dass die auszuführende Funktion vom Bürger gar nicht bestätigt werden muss; info bedeutet, dass der Bürger über die auszuführende Aktion über die Benutzer-Schnittstelle informiert werden muss; confirm bedeutet, dass der Bürger über die Benutzer-Schnittstelle die Erlaubnis für die Ausführung bestätigen muss; bei confirmWithSecret muss der Bürger die Erlaubnis für die Ausführung durch die Eingabe eines Passworts über die Benutzer-Schnittstelle erteilen.

3.2 Chains

Mindestens zwei Chains müssen vorhanden sein: Identification und Command. Die Abarbeitung beginnt immer mit der Chain Identification. Die Aufteilung ermöglicht es, zuerst den Ursprung der Befehlsanfrage bzw. das Ziel der Befehlsantwort einzugrenzen, danach erfolgt eine weitere Eingrenzung auf Kommandobasis.

3.3 Voreinstellungen für eine lokale Bürgerkarten-Umgebung

Bei der Auslieferung einer lokalen Bürgerkarten-Umgebung an den Bürger muss ihr Regelwerk so konfiguiert sein, dass es den nachfolgenden Standardeinstellungen genügt. Die Bürgerkarten-Umgebung sollte dem Bürger die Möglichkeit bieten, die Standardeinstellungen nach seinen persönlichen Wünschen zu verändern.

3.3.1 Chain Identification

3.3.2 Chain Command

3.4 Voreinstellungen für eine serverbasierte Bürgerkarten-Umgebung

Bei der erstmaligen Benutzung einer serverbasierten Bürgerkarten-Umgebung durch den Bürger muss ihr Regelwerk so konfiguiert sein, dass es den nachfolgenden Standardeinstellungen genügt. Die Bürgerkarten-Umgebung sollte dem Bürger die Möglichkeit bieten, die Standardeinstellungen nach seinen persönlichen Wünschen zu verändern.

3.4.1 Chain Identification

3.4.2 Chain Command

Siehe Abschnitt 3.3.2.

4 Sicherheits- und Bedrohungsanalyse

4.1 Schutzbedürfnis der Signaturerstellungsbefehle

Die Einstufung, dass bei den Signaturerstellungsbefehlen nur das Resultat, nicht aber die Aktion schützenswert ist, erfolgt aus pragmatischen Gründen. Prinzipiell ist es also möglich, dass Signaturerstellungsbefehle von unbekannter Quelle abgesetzt werden und an eine bekanntes Zielübermittelt werden. Da allerdings ein potentieller Angreifer das Signaturresultat für eine sinnvolle Attacke benötigen würde, erscheint diese Einstufung gerechtfertigt.

4.2 Cross-Site-Scripting Attacken

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 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 3.3 und 3.4 so gewählt, dass für alle sensiblen Befehle jedenfalls die Bestätigung des Bürgers einzuholen ist.

5 Referenzen

Keywords

Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment, März 1997. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2119.txt.

RFC2396

Berners-Lee, T. , Fielding, R. und Masinter, L.: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. IETF Request For Comment, August 1998. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2396.txt.

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. Abgerufen aus dem World Wide Web am 01. 03. 2005 unter http://www.cio.gv.at/it-infrastructure/pki/X509ext-20030218.pdf.

X509

Polk, W., Ford, W., Solo, D.: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF Request For Comment, April 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc3280.txt.

XSS-FAQ

Cgisecurity.com: The Cross Site Scripting FAQ. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.cgisecurity.com/articles/xss-faq.txt.

6 Historie