Diskussion der Sicherheitseigenschaften

Die folgenden Abschnitte diskutieren und analysieren die grundlegenden Sicherheitseigenschaften des Movi-Konzepts. (A) indiziert Android-spezifische Mechanismen, (iOS) Apple/iOS spezifische Mechanismen.

Inhalt

1 Grundlagen
1.1 Schutzziele
1.2 Externer vs. interner Angreifer

2 Allgemein
2.1 Die elektronische Gesundheitskarte (eGK)
2.1.1 Auszug der im Authentifizierungszertifikat (C.CH.AUT) gespeicherten Daten
2.1.2 Authentifizierung
2.1.3 Ausgabeprozess

2.2 Die virtuelle elektronische Gesundheitskarte (veGK)
2.2.1 Gespeicherte Daten
2.2.2 Definition
2.2.3 Authentifizierung

3 Grundlegende Anforderungen
3.1 Definition der kryptographischen Algorithmen
3.2 Erzeugung und Speicherung von Systemschlüssel
3.3 Erzeugung und Speicherung von Nutzerschlüssel
3.4 Erzeugung und Speicherung von kryptografischen Nonces

4 Lebenszyklus eines Patientenkontos
4.1 Grundlagen der Registrierung
4.2 Registrierung per eGK
4.3 Registrierung per Post
4.4 Deaktivierung/Löschung

5 Nutzerauthentifizierung

6 Sicherheit mobiler Endgeräte
6.1 Android Sicherheitsmechanismen
6.2 Bewertung und Vergleich der Entsperrmechanismen
6.3 Authentifizierung mit FIDO2
6.4 Vergleich der Mechanismen zur Absicherung des Zugriffs auf kryptografischer Schlüssel (A, iOS)

7 Diskussion des Sicherheitsniveaus nach eIDAS

8 Ausblick: Mögliche Steigerungen des Sicherheitsniveaus

9 Quellen

1 Grundlagen

1.1 Schutzziele

Die Sicherheitsbetrachtung der Komponenten sowie Abläufe erfolgen immer im Kontext zuvor definierter Sicherheitsziele, welche nachfolgen kurz eingeführt werden [4]:

Vertraulichkeit (Confidentiality)

Die Vertraulichkeit ist gewährleistet, wenn keine unautorisierte Informationsgewinnung möglich ist. Informationen dürfen also nur ausschließlich Subjekten in der zulässigen Weise zugänglich sein.

Personenbezogene medizinische Daten gelten als besonders schützenswert (§3 Abs. 9 BDSG -> DSGVO???). Sie dürfen nicht unberechtigt zur Kenntnis genommen, eingesehen, weitergegeben oder veröffentlicht werden. Nur authentifizierte und vom Bürger autorisierte Zugriffsberechtigte dürfen Einblick in identifizierende medizinische Daten erlangen. Nur dem Bürger obliegt es, Zugriffsberechtigungen auf seine Daten an weitere Nutzer zu vergeben, die er auch jederzeit wieder zurücknehmen kann. Der Betreiber einer AsK-Architektur oder seine Administratoren sind keine berechtigten Nutzer und dürfen daher auch keinen Einblick in personenbezogene medizinische Daten erlangen. Aus dem Vertraulichkeitsanspruch ergibt sich das Erfordernis der Identifizierung und Authentifizierung aller handelnden Subjekte (Personen, Einrichtungen und technische Komponenten) und ihrer Autorisierung, um den Kreis derer eindeutig bestimmen zu können, die eine vertrauliche Information zur Kenntnis nehmen dürfen, dieser Aspekt bezieht auch die Vertraulichkeit der Kommunikation mit ein.

Integrität (Integrity)

Die Datenintegrität ist gewährleistet, wenn es Subjekten nicht möglich ist, die zu schützenden Daten unautorisiert und unbemerkt zu manipulieren.

Ziel der Integrität ist es, die Korrektheit (Unversehrtheit) der gespeicherten beziehungsweise übermittelten Daten gemäß dem Schutzbedarf sicherzustellen. Daten sind korrekt, wenn sie während der Erstellung, Übermittlung und dem Vorhalten auf einem Speichermedium nicht ungewollt beschädigt oder unautorisiert verändert werden können. Manipulationen müssen erkannt werden können, sodass eine unbemerkte Datenfälschung beziehungsweise -verfälschung praktisch ausgeschlossen werden kann.

Authentizität (Authenticity)

Unter Authentizität wird die Echtheit und Glaubwürdigkeit eines Subjekts oder Objekts verstanden, die anhand einer eindeutigen Identität und charakteristischen Eigenschaften überprüfbar ist.

Daten und Information sind authentisch, wenn sie dem Autor, Ersteller und/oder Sender eindeutig zugeordnet werden können und die behauptete Identität nachprüfbar ist. Hierbei kann es sich um eine Person, eine bestimmte Personengruppe, eine Institution oder technische Komponente handeln. Eine Kommunikation ist authentisch, wenn überprüfbar ist, dass der Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein.

Nicht-Abstreitbarkeit (Non-Repudiation)

Die Nicht-Abstreitbarkeit ist gewährleistet, wenn es einem Subjekt nicht möglich ist, die Durchführung von Aktionen im Nachhinein abzustreiten. Das Schutzziel zielt darauf ab, dass der Versand oder der Empfang von Daten und Informationen gegenüber Dritten nicht abgestritten werden kann. Die Nicht-Abstreitbarkeit erfordert Maßnahmen zur eindeutigenIdentifikation des Subjekts und zur Protokollierung.

Verfügbarkeit (Availability)

Die Verfügbarkeit beschreibt die Zeit, in welcher das System funktionsfähig und erreichbar ist. Aus der Definition der virtuellen elektronischen Gesundheitskarte (veGK) geht hervor, dass sie sich aus …, wodurch die Verfügbarkeit ein wichtiges Schutzziel ist und bei der Realisierung eines möglichen Produktivsystems berücksichtigt werden muss. Im Rahmen der Sicherheitsdiskussion spielt sie jedoch eine untergeordnete Rolle, wodurch sie nicht weiter betrachtet wird.

1.2 Externer vs. interner Angreifer

Eine potentielle Gefährdung für die Schutzziele der Daten eines Versicherten oder des Gesamtsystems kann auf zwei Arten erfolgen: Durch einen Angreifer von außen (externer Angreifer) und durch einen Angreifer von innen (interner Angreifer). Externe Angreifer sind Angreifer, welche nicht mit entsprechenden Zugriffsrechten ausgestattet sind und versuchen Daten während der Übermittlungsphase zwischen Infrastruktur und Clientanwendung oder durch Einbruch in Komponenten der Infrastruktur zu beschaffen. Ein interner Angreifer hingegen hat die Möglichkeit das System innerhalb des Systemnetzwerks Anzugreifen und ist unter Umständen sogar mit entsprechenden Zugriffsberechtigungen ausgestattet. In diese Klasse der Angreifer fallen unter anderem auch System- oder Datenbank-Administratoren. Ein Angriff von innen bedeutet dabei jedoch nicht immer, dass ein Administrator direkt kompromittiert sein muss, sondern kann auch dadurch entstehen, dass sich ein externen Angreifer erfolgreich zugriff aus das System oder das interne Netzwerk verschafft hat oder ein Administrationskonto übernimmt und somit zum internen Angreifer wird.

2 Allgemein

2.1 Die elektronische Gesundheitskarte
2.1.1 Auszug der im Authentifizierungszertifikat (C.CH.AUT) gespeicherten Daten

Die Attribute des Authentifizierungszertifikats der Gesundheitskarte sind aus [1] entnommen. Ein Auszug wird nachfolgend Aufgelistet und verschiedenen Datenkategorien (DK) zugeordnet.

DK-1: Personen- und Versichertendaten

DK-2: Informationen der Identitätsquelle

DK-3: Sicherheitsrelevante Zertifikatsdaten

DK-4: Informationen der Infrastruktur

Des Weiteren sind folgende als nicht kritisch deklarierte Erweiterungen enthalten, welche den aktuellen Betrachtungsgegenstand als nicht relevant angesehen werden:

Das Feld Schlüsselverwendung (KeyUsage) ist zwar als kritisch deklariert, in einem reinen Authentifizierungsszenario der veGK jedoch nicht relevant.

2.1.2 Authentifizierung

Durch Besitz der Karte und Wissen des PINs ist der Zugriff auf den zum Authentifizierungszertifikat korrespondierenden privaten Schlüssel möglich (PACE-Protokoll), welcher im Rahmen der Authentifizierung notwendig ist.

2.1.3 Ausgabeprozess

Die Karte wird dem Versicherten postalisch an die bei der Kasse hinterlegten Adresse überstellt. Es erfolgt keine Identitätsüberprüfung bei der Zustellung. Jeder, mit Zugriff auf den Zugstellweg, kann die eGK unbemerkt abfangen. Auch, wenn für die Zustellung der korrespondierenden PIN noch keine Prozesse definiert sind, wird diese vermutlich auf eine ähnliche Art und Weise erfolgen. Es kann Kassen-spezifische Unterschiede im Prozess geben. Durch den Prozess der postalischen Auslieferung kann nicht sichergestellt werden, dass eine eGK auch immer der korrespondierenden, die Identität innehabende, natürlichen Person überstellt wird.

2.2 Die virtuelle elektronische Gesundheitskarte (veGK)
2.2.1 Gespeicherte Daten

DK-1: Personen- und Versichertendaten (im IdP)

DK-2: Informationen der Identitätsquelle (im IdP)

DK-3: Sicherheitsrelevante Zertifikatsdaten (auf dem Mobilgerät des Versicherten)

DK-3: Sicherheitsrelevante Zertifikatsdaten (im IdP)

DK-4: Informationen der Infrastruktur

2.2.2 Definition

Entgegen dem physischen Äquivalent der virtuellen elektronischen Gesundheitskarte (veGK) werden nicht alle personenbeziehbare und innerhalb eines Authentifizierungsszenarios benötigten Daten an einem Speicherort vorgehalten (siehe Gespeicherte Daten), wodurch die veGK logisch als verteilte Identität über das Mobilgerät des Versicherten und die Komponenten der Movi-Infrastruktur zu betrachten ist.

Architektur der veGK

Die illustrierten Prozesse sind:

  1. Registrierung eines Versicherten per NFC-Schnittstelle: Die personenbeziehbaren Daten werden aus dem Authentifizierungszertifikat (C.CH.AUT) der eGK übernommen. Das Erzeugen des Authentifizierungsmittels der veGK (des Attestierungsschlüsselpaars) setzt die Signatur durch den korrespondierenden privaten Schlüssel des Authentifizierungszertifikats der eGK voraus, wofür die Eingabe des PINs durch den Versicherten notwendig ist. Das erzeugte Attesttierungsschlüsselpaar wird per Key Attestation an die sichere Hardware des Mobilgeräts gebunden. Der Zustand des Mobilgeräts wird über den SafetyNet-Mechanismus evaluiert. Der Account Management Service verifiziert die übermittelten JWT-Transkripte und erzeugt bei Erfolg ein Nutzerkonto auf dem Identitätsprovider, welcher neben dem Hash-Wert des Attestierungszertifikats auch die personenbeziehbaren Daten des Versicherten aus dem Authentifizierungszertifikat der eGK speichert.

  2. Registrierung eines Versicherten per postalisch zugestellten Aktivierungscode: Die externe Quelle und die Übermittlungsart der Versichertenstammdaten ist nicht genauer spezifiziert.

  3. Authentifizierung am Identitätsprovider zum Bezug des Authentifizierungstokens:

  4. Löschen oder Sperren/Deaktivieren eines Benutzerkontextes:

Wie in Abb. xyz illustriert, sind die involvierten Komponenten im Detail:

Nach erfolgreicher Verifikation des Authentifizierungsmittels bezieht das Mobilgerät/die Client-Anwendung ein Authentifizierungstoken zum Zugriff auf Dienste mit limitierter Gültigkeit, welches durch den IdP ausgestellt und durch den AMS übermittelt wird.

2.2.3 Authentifizierung

Durch den Besitz des Mobilgeräts sowie dem Besitz des biometrischen Faktors oder dem Wissen der PIN zum Zugriff auf den privaten Attestierungsschlüssel, welcher im Rahmen der Authentifizierung notwendig ist.

3. Grundlegende Anforderungen

3.1 Definition der kryptographischen Algorithmen

Definiert für Gesamtkontext -> Krypto-Agilität (kommutative Algorithmen, Abwärtskompatibilität)
Eingesetzte Hashfunktion: Definition von H() -> SHA256
Eingesetzte Kryptoalgorithmen: ES256

3.2 Erzeugung und Speicherung von Systemschlüssel
3.3 Erzeugung und Speicherung von Nutzerschlüssel
3.4 Erzeugung und Speicherung von kryptografischen Nonces

Nonces bezeichnen in der Kryptografie nummerische oder alphanumerische Zeichenketten die zur einmaligen und zeitlich limitierten Nutzung innerhalb eines Protokolls zu dessen Absicherung gegen Replay-Attacken eingesetzt werden. Wird einen Nonce innerhalb einer SafetyNet-Anfrage verwendet, empfiehlt Google eine Mindestlänge von 16 Bytes. Es ist sicherzustellen, dass eine Nonce niemals mehrfach verwendet wird [1]. Die Anforderungen an die Größe und die Exklusivität der Nonces decken sich mit denen des BSI in [2] und der IETF in [3] für das IKEv2-Protokoll, wobei hier zusätzlich eine Obergrenze von 256 Bytes angegeben wird.

Die Exklusivität einer Nonce kann innerhalb eines Systemkontextes auf zwei Art und Weisen erreicht werden:

  1. Durch den Erzeugungsmechanismus und einer server-seitigen Zustandstabelle: Serverseitig wird die Nonce und ihre korrespondierende Gültigkeitsdauer (TTL = Time to live) in einer Datenstruktur gespeichert. Wird eine neue Nonce benötigt/erzeugt kann über die Historie sichergestellt werden, dass keine Nonce Mehrfach ausgegeben wird. Geht eine Anfrage basierend auf einer expliziten Nonce an dem Server ein, kann über die korrespondierende TTL in der Zustandstabelle die Gültigkeit der Nonce verifiziert werden.

  2. Durch den Erzeugungsmechanismus und kryptografische Signaturen: Serverseitig wird die Nonce und ihre korrespondierende Gültigkeitsdauer (TTL = Time to live) in einer Datenstruktur eingebettet. Der Server ist im Besitzt eines asymmetrischen kryptografischen Schlüsselpaars, dessen privater Teil zur Signatur der Datenstruktur verwendet wird. Das Schlüsselpaar ist als sicherheitskritisch zu betrachten, wodurch im die gleichen Anforderungen zuteil wird wie den anderen Schlüssel des Systems (siehe Abschnitt xyz -> Erzeugung und Speicherung sicherheitsrelevanter Systemschlüssel) Wird die Nonce-Datenstruktur an einen Client ausgeliefert, kann diese mittels dem korrespondierenden öffentlichen Schlüssel des Servers die Nonce und ihre Gültigkeit verifizieren. Da der Server zum Erzeugungszeitpunkt einer Nonce keinen globalen Überblick über alle bisher ausgestellten Nonces hat, muss die Exklusivität durch den Erzeugungsmechanismus sichergestellt werden. Dies wird über zusätzliche in die Nonce eingearbeitete Parameter erreicht (Nutzer-spezifische an den Server übermittelte Parameter, Anfragezeitpunkt).

Es muss durch die eingebetteten Parameter sichergestellt werden, dass die Nonce EINDEUTIG einem Client zugeordnet ist! Die Zuordnung muss jederzeit verifizierbar sein. Um dies sicherzustellen ist es notwendig einen Teil der Nonce von den an den Server übermittelten Client/Anwender-Daten abzuleiten [1]. Desto mehr Anwenderspezifische Daten in eine Nonce eingearbeitet werden, desto schwerer ist für einen etwaigen Angreifer die Durchführung von Replay-Attacken. Wird das signierte Ergebnis einer Api-Anfrage zurückgegeben, muss die eingebettete Nonce no stets mit der auf Basis der Anfrageparameter rekonstruierten Nonce no’ verglichen werden (no =? no’). Die Überprüfung stellt sicher, dass ein Angreifer signierte Attestierungen, die von validen Geräten stammen, nicht für andere, in böswilliger Absicht erstellte, Api-Anfragen wiederverwenden kann.

Nonces nach Variante 2 werden in folgenden (Teil-)Abläufen eingesetzt:
Grundlagen der Registrierung - (A) -> getRegistrationChallenge()
Registrierung (eGK) - Vollständiger Ablauf (A) -> Schritt 10 - 16
Registrierung (postalisch) - Vollständiger Ablauf (A) -> Schritt 12 - 18

4 Lebenszyklus eines Patientenkontos

Das Nutzen der Dienste der AsK2/Movi-Infrastruktur setzt die eindeutige Identifikation und Erfassung ihrer Anwender voraus. Ein Nutzerkonto kann innerhalb seines Lebenszyklus drei Zustände annehmen: Nicht-existent, aktiv und inaktiv:

Lebenszyklus eines Patientenkontos

Die Zustandsübergänge sind durch die jeweiligen Protokolle zur Registrierung eines Versicherten bzw. zur Deaktivierung/Löschung seines Movi-Nutzerkontextes definiert.

4.1 Grundlagen der Registrierung

Unabhängig der Variante der Registrierung eines Nutzerkontos (per eGK oder per Post) basieren die jeweiligen Registrierungsabläufe auf den gleichen Sicherheitsmechanismen, welche zusammenfassend in Grundlagen der Registrierung - (A) analysiert werden.

4.2 Registrierung per eGK

Registrierung (eGK) - Vollständiger Ablauf (A)
Registrierung (eGK) - Teilablauf (A)
Datenflussanalyse der JWT-Transkripte (A)

4.3 Registrierung per Post

Registrierung (postalisch) - Vollständiger Ablauf (A)
Registrierung (postalisch) - Teilablauf (A)
Datenflussanalyse der JWT-Transkripte (A)

4.4 Deaktivierung/Löschung

Kontodeaktivierung/-löschung - Vollständiger Ablauf (A)
Datenflussanalyse der JWT-Transkripte (A)

5 Nutzerauthentifizierung

Authentifizierung auf Basis attestierter kryptographischer Schlüssel - Vollständiger Ablauf (A)
Datenflussanalyse der JWT-Transkripte (A)
Authentifizierung auf Basis attestierter kryptographischer Schlüssel - Sicherheitsüberlegungen (A)

6 Sicherheit mobiler Endgeräte

6.1 Android Sicherheitsmechanismen

Eine grundlegende Skizze und Bewertung der Sicherheitsmechanismen und -architektur der Android-Plattform (A) ist hier zu finden.

6.1 Attestierungsmechanismen

Ein grundlegender Vergleich der Mechanismen zur Gewährleistung der Geräteintegrität (A, iOS) ist hier zu finden.

6.2 Bewertung und Vergleich der Endsperrmechanismen

Eine grundlegende Betrachtung der Endsperrmechanismen mobiler Endgeräte ist hier zu finden.

6.3 Authentifizierung mit FIDO2

Eine kurze Diskussion der Authentifizierung per FIDO 2 im Kontext mobiler Endgeräte ist hier zu finden.

6.4 Vergleich der Mechanismen zur Absicherung des Zugriffs auf kryptografischer Schlüssel

Der Vergleich der Absicherungsmechanismen kryptografischer Schlüssel auf mobilen Endgeräten (A, iOS) ist hier zu finden.

7 Diskussion des Sicherheitsniveaus nach eIDAS

Die Bewertung des Konzepts nach eIDAS ist hier zu finden.

8 Quellen

[1] https://developer.android.com/training/safetynet/attestation
[2] BSI Technische Richtlinie TR-02102 Teil 3
[3] RFC 7296 Abschnitt 3.9
[4] Claudia Eckert. IT-Sicherheit: Konzepte-Verfahren-Protokolle. Walter de Gruyter, 2013.