Rahmenbedingungen und Herausforderungen

Die folgenden Abschnitte geben einen Überblick über grundsätzliche Rahmenbedingungen und Herausforderungen, die es im Zusammenhang mit der Nutzung einer elektronischen Gesundheitskarte mit kontaktloser Schnittstelle zu berücksichtigen gilt.

Hard- und softwarebezogene Anforderungen

Tablets und Smartphones werden zunehmend genutzt, um zeitgemäße und ressourcenschonende Versorgungsangebote im Gesundheitswesen zu unterstützen. Der größte Teil der deutschen Bevölkerung verfügt bereits heute über entsprechende Endgeräte (vgl. [CHARISMHA] ). Um die elektronische Gesundheitskarte bzw. deren kontaktlose Schnittstelle nutzen zu können, sind jedoch besondere Anforderungen zu berücksichtigen, die an die entsprechende Hard- und Software der Mobilgeräte gestellt werden.

Vorhandensein eines NFC-Controllers

Um eine kontaktlose Kommunikation mit der elektronischen Gesundheitskarte zu ermöglichen, wird spezielle Hardware benötigt, die die Kommunikation gemäß [ISO/IEC 14443] (Identification cards – Contactless integrated circuit cards) unterstützt. Grundsätzlich kann diese Hardware als (1) Peripheriegerät an das mobile Endgerät des versicherten angeschlossen oder (2) in dieses fest integriert sein:

(1) Externe Kartenleser als Peripheriegerät

Mittlerweile existieren Smartcard Reader, die über Bluetooth an mobile Endgeräte angeschlossen werden können.

Mobiles Kartenlesegerät (Beispiel) [ReinerSCT]

Der Einsatz externer Hardware besitzt jedoch zwei entscheidende Nachteile:

Erfahrungen im Umfeld des Personalausweises zeigen, dass von den 61 % der Bürger, die einen Personalausweis mit kontaktloser Schnittstelle besitzen, nur 5 % über einen Kartenleser verfügen und nur 2 % diesen auch schon einmal genutzt haben (vgl. [FDPBT_DM]). Der Anteil derer, die einen Kartenleser besitzen, der sich in mobilen Szenarien nutzen lässt, wird noch einmal deutlich geringer sein. Zusammenfassend lässt sich feststellen, dass dieser Weg der Kartenkommunikation nur in besonderen Ausnahmefällen in Betracht kommt, z. B. wenn bestimmte Endgeräte genutzt werden müssen, diese jedoch über keinen fest verbauten NFC-Controller verfügen bzw. der vorhandene NFC-Controller oder die ihn ansteuernde Software die erforderlichen Standards und Protokolle nicht oder nur teilweise unterstützen.

(2) Fest verbauter NFC-Controller

Ein deutlich vielversprechenderer Weg für die Realisierung der eGK-Ansteuerung ist die Nutzung von fest verbauten NFC-Controllern. Viele Smartphones verfügen bereits heute über entsprechende Hardware, da diese in verschiedensten Szenarien zum Einsatz kommt.

Im Smartphone verbauter NFC-Controller [ifixit]

Den derzeit wohl populärsten Anwendungsfall stellt das Mobile Payment dar: Hier wird der NFC-Controller im Card Emulation Mode genutzt, um sich gegenüber Bezahlterminals als kontaktlose Smartcard auszugeben. Vornehmlich durch die zunehmende Verbreitung und Nutzung entsprechender Payment-Angebote (z. B. Android Pay, Apple Pay, Samsung Pay) ist auch mit einer zunehmenden Unterstützung von NFC in mobilen Endgeräten zu rechnen. Ältere Schätzungen (2015) gehen davon aus, dass bis 2020 rund 90 % aller Smartphones mit NFC Controllern ausgestattet sein werden (vgl. [statista_nfc]).

Prognostizierte NFC-Unterstützung durch Smartphones [statista_nfc]

Aktuelle Zahlen, die einen Gesamtüberblick bieten, liegen derzeit leider nicht vor. Im Rahmen der Studie wurde daher anhand des von Amazon veröffentlichten Verkaufsrangs (Top 100) für alle Geräte in der Rubrik „Handy und Smartphones“geprüft, ob diese einen NFC-Controller besitzen. Dabei wurden Geräte/Modelle zusammengefasst, die mehrfach vorkamen und sich lediglich bezüglich der Farbe oder des vorhandenen Speicherplatzes unterschieden. Apple Geräte wurden ebenfalls nicht mit in die Analyse einbezogen.

NFC-Unterstützung von Android-Smartphones nach Amazon Verkaufsrang (TOP100) – Prozentuale Verteilung

Von den verbleibenden 52 Gerätetypen waren in rund 61 % der Fälle NFC-Controller verbaut, in rund 8 % nur in einzelnen Modellen. Die übrigen Gerätetypen (31 %) verfügten über keine NFC-Unterstützung. Sehr deutliche Unterschiede in der Verteilung waren bei der Gruppierung nach Preissegmenten zu sehen:

: NFC-Unterstützung von Android-Smartphones nach Amazon Verkaufsrang (TOP100) - Verteilung nach Preissegmenten

Die Mehrzahl der Gerätetypen in den unteren beiden Preissegmenten verfügt über keinen NFC-Controller. Anders sieht es im mittleren und den beiden oberen Segmenten aus. Hier verfügen weit mehr als 80 % aller Gerätetypen über die für das Ansteuern der eGK erforderlichen NFC-Controller.

Zusammenfassung
Unterstützter NFC-Funktionsumfang

Das Vorhandensein eines NFC-Controllers impliziert lediglich, dass ausgewählte Teile der vom NFC-Forums beschriebenen Einsatzszenarien bzw. Operationsmodi durch das mobile Endgerät unterstützt werden. Es ist jedoch kein Garant dafür, dass eine vollständige Unterstützung durch den Hersteller des jeweiligen Endgerätes bzw. des darauf laufenden Betriebssystems erfolgt.

Eine besondere Rolle spielen in dieser Diskussion die mobilen Endgeräte der Firma Apple (Betriebssystem: iOS). Seit dem iPhone 6 verbaut Apple zwar entsprechende NFC-Hardware in ihren Smartphones, softwareseitig unterstützt wird jedoch primär Funktionalität, die auf Mobile Payment ausgerichtet ist (Card Emulation Mode). Eine rudimentäre Implementierung für den Reader/Writer-Mode findet sich zwar ebenfalls (vgl. [Apple Core NFC]), allerdings wird hier lediglich das Auslesen von NDEF-Tags (NFC Data Exchange Format) unterstützt. Eine Ansteuerung der elektronischen Gesundheitskarte ist bisher nicht möglich. Anders sieht es auf der Android Plattform aus, hier sind entsprechenden Einschränkungen seitens des Betriebssystems nicht vorgesehen. Eine Nutzung der eGK sollte grundsätzlich möglich sein. Dennoch ergeben sich auch hier unter Umständen bestimmte andere Einschränkungen.

Marktanteile Apple/Android (Deutschland) [statista_markt]

Der Marktanteil für iOS-basierte Endgeräte (Apple) beträgt derzeit ca. 20%. Diese Nutzer könnten – zumindest derzeit - die elektronische Gesundheitskarte nicht ohne zusätzliche Peripheriegeräte nutzen.

Zusammenfassung
Feldstärkenproblematik

Erfahrungen im Umfeld des Einsatzes des deutschen Personalausweises haben gezeigt, dass neben einem Betriebssystem-seitig eingeschränkten NFC-Funktionsumfang weitere Faktoren die Ansteuerung [ISO/IEC 14443] konformer Smartcards behindern können.

Bei ausgewählten Android-Endgeräten gelang es nicht, eine stabile Kommunikation zwischen Karte und Mobilgerät aufzubauen. In einzelnen Quellen (vgl. [AusweisApp2 FAQ]) wird als Ursache eine hersteller-seitig reduzierte Stärke des vom NFC-Controllers erzeugten elektromagnetischen Feldes als Ursache des Problems angeführt. Diese scheint in Einzelfällen nicht ausreichend zu sein, um den im Personalausweis verbauten Smartcard-Chip mit ausreichend Energie zu versorgen. Frei verfügbare Quellen mit entsprechenden Messwerten, die diese Vermutung belegen, konnten jedoch nicht gefunden werden.

Ausgehend von den vorliegenden Erkenntnissen, wurde im Rahmen der Studie entschieden, stichprobenartig zu testen, ob ähnliche Beobachtungen auch im Kontext der Ansteuerung der elektronischen Gesundheitskarte gemacht werden können. Mit Abschluss der Studie im Februar 2018 konnte bei einem der untersuchten Android-Endgeräte (Nokia 5) ein entsprechendes Verhalten diagnostiziert werden. Von den drei vorhandenen Testkartentypen ließen sich lediglich zwei Karten ansteuern. Die andere Karte wurde vom Smartphone nicht erkannt. Die zum Einsatz kommenden Karten unterschieden sich sowohl bezüglich des genutzten ICs als auch des gewählten Antennendesigns.

Antennendesign Test-Gesundheitskarten

Eng verbunden mit der Diskussion, ob ein Endgerät eine ausreichend große Feldstärke erzeugt, um die kontaktlose Schnittstelle der Gesundheitskarte anzusteuern, ist die Frage, in welche Entfernung und in welcher Position eine stabile Verbindung zur Karte etabliert werden kann. Diese Frage lässt sich jedoch nur schwer pauschal beantworten, da eine Vielzahl von Faktoren das zu beobachtende Verhalten beeinflusst. Dazu gehören u.a.:

Grundsätzlich lässt sich jedoch feststellen, dass die Verbindung zur Karte nur in einem sehr eng begrenzten Bereich auf der Rückseite der mobilen Endgeräte möglich ist. Die Position dieses Bereichs unterscheidet sich von Modell zu Modell und ist primär von der Positionierung der NFC-Antenne innerhalb des Smartphones abhängig. Die anzusteuernde Karte sollte möglichst eng am Gerät anliegen. Schutzhüllen können die Kommunikation unter Umständen negativ beeinflussen. Während der gesamten Kommunikationsdauer sollte die Karte nicht bewegt werden.

Zusammenfassung
Unterstützung von Extended Length APDUs

Eine weitere Erfahrung, die im Rahmen des Einsatzes des Personalausweises gesammelt werden konnte, betrifft die Tatsache, dass sehr viele Android-Endgeräte derzeit nicht in der Lage sind, lange (extended length) Kommando-APDUs zu unterstützen (vgl. [AusweisApp FAQ]). Diese sind für die Authentisierungsfunktion (eID-Funktion) des Personalausweises jedoch zwingend erforderlich (vgl. [Open eCard EL])). Die fehlende Unterstützung hat folgende Ursachen:

Im Rahmen der Studie wurde untersucht, ob die für die Nutzung der Authentisierungsfunktionalität der eGK notwendigen Kartenkommandos ebenfalls Extended Length Kommando-APDUs enthalten. Dies ist nicht der Fall (vgl. Anhang A). Endgeräte die derzeit nicht in der Lage sind, die eID-Funktion des Personalausweises zu nutzen, sollten somit jedoch grundsätzlich mit der elektronischen Gesundheitskarte zusammenarbeiten. Diese Annahme konnte im Rahmen der Studie anhand von Praxistests bestätigt werden. Dazu wurden ausgewählte, als nicht Personalausweis-kompatibel gekennzeichnete Endgeräte (vgl. [AusweisApp Devices]) erfolgreich zum Auslösen einer Signaturoperation mit dem Authentisierungszertifikat (EF.C.CH.AUT) bzw. dem zugehörigen privaten Schlüssel genutzt.

Ab Android 9 bietet google die Möglichkeit, die vormals fest im Quelltext hinterlegte Längenbeschränkung für APDUs durch Hersteller frei zu konfigurieren (vgl. [google EL]). Somit sollte sich die Extended Length Problematik in den kommenden Jahren voraussichtlich auch für den Personalausweis auflösen.

Zusammenfassung
Android API-Level

Android unterstützt Teile der NFC-Standardfamilie seit mittlerweile fast 8 Jahren. Die für den Reader/Writer Mode notwendige Funktionalität wurde mit Android 2.3.3 (API Level 10) vollständig eingeführt.

Verteilung verschiedener Android Versionen ([statista_AndroidVersions])

Mit wenigen Ausnahmen sollten somit fast alle in Deutschland genutzten Android-Endgeräte bezüglich ihres API-Levels die benötigte NFC-Funktionalität unterstützen. Die entsprechende API kann natürlich nur bei vorhandenem NFC-Controller genutzt werden.

Zusammenfassung

Anforderungen an den Versicherten

Im Umfeld der Nutzung der Authentisierungsfunktionalität der elektronischen Gesundheitskarte ergibt sich neben hardware- und softwareseitigen Anforderungen eine Reihe von Anforderungen mit denen der Versicherte direkt konfrontiert ist. Die folgenden Abschnitte problematisieren diese Anforderungen. Auf Lösungsoptionen wird gesondert eingegangen.

Positionieren und Halten der Karte

[ACHTUNG: Die bisherigen Ausführungen beziehen sich lediglich auf objektiv messbare Parameter. Erst die für Ende November geplanten Nutzertests werden einen subjektiven Beitrag zur Diskussion liefern]

Die für die Realisierung des Authentisierungsvorgangs benötigte Dauer der Kommunikation zwischen Karte und mobilem Endgerät variiert zwischen 4 und 9 Sekunden. Während dieser Zeit muss der Versicherte die Karte „still halten“.

Zusammenfassung
Eingeben der Card Access Number (CAN)

Anders als beim Personalausweis muss für die Nutzung der Authentisierungsfunktionalität über die kontaktlose Schnittstelle der eGK zwingend die Card Access Number (CAN) für den Aufbau einer sicheren Verbindung zwischen Anwendung und Karte genutzt werden (vgl. auch Abschnitt 2.5). Die CAN muss als 6-stellige Ziffernfolge in der Schriftart Verdana True Type in der Größe 6 pt fett in Schwarz auf die Gesundheitskarte aufgedruckt werden (vgl. [gemSpec_eGK_Opt]).

Card Access Number (CAN)

Der Deutsche Blinden und Sehbehindertenverband empfiehlt für Senioren und sehbehinderte Menschen (Visus 0,45) bei einem Abstand von 30 cm für Bücher und Zeitschriften jedoch eine Mindestschriftgröße von 10,6 pt (vgl. [DBSV_Schrift]). Somit ist absehbar, dass das Eingeben der CAN für diese Personengruppen - ohne die Nutzung zusätzlicher Hilfsmittel – ein Problem darstellen könnte.

Zusammenfassung
Eingeben der PIN

Wie bereits in den Grundlagen dargestellt, ist für die Realisierung der Authentifizierungsfunktionalität die Eingabe der 6-stelligen PIN des Versicherten erforderlich. Diese können die Versicherten selbst bestimmen. Zur Freischaltung der entsprechenden Funktionalität benötigen sie initial die vom Kartenherausgeber bereitgestellte Transport-PIN. Alle nachfolgenden PIN-Änderungen können mit der jeweils aktuellen PIN autorisiert werden. Die Karte wird nach drei falschen PIN-Eingaben „gesperrt“, eine Authentisierung ist dann bis zur Freischaltung durch einen 8-stelligen PIN unlock key (PUK) nicht mehr möglich.

Verschiedene Studien (vgl. [human_memory]) legen nahe, dass mit zunehmendem Alter die Erinnerungsfähigkeit abnimmt. Dies trifft auch auf PINs zu: Ältere Menschen sind durchschnittlich schlechter in der Lage, sich an PINs zu erinnern. Dieser Effekt verstärkt sich zunehmend mit der Anzahl der zu merkenden PIN (vgl. [Age_PIN]).

Obwohl durch das Festlegen einer selbst gewählten PIN die Gefahr des Vergessens im Vergleich zu zufällig vergebenen PINs reduziert wird, besteht dennoch die Möglichkeit einer „PIN Code Amnesie“. Um diesem Problem entgegenzuwirken, entscheiden sich viele Nutzer ihre PINs oder Passwörter zu notieren. Eine in den USA durchgeführte Studie (vgl. [Password_Management]) kommt zu dem Ergebnis, dass rund die Hälfte aller Nutzer Passwörter auf Papier notiert.

Sollten die Versicherten zu häufig zur Eingabe ihrer PIN aufgefordert werden, besteht die realistische Möglichkeit, dass entweder die Usability oder die Sicherheit des Systems leidet:

Zusammenfassung