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:

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.

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:

Die vier Authentisierungsklassen lassen sich vereinfacht wie folgt charakterisieren:

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.

Abbildung 1. Authentisierungsklassen

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

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.

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.

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.

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.

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.

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.