gemSpec_KT_V3.17.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation
eHealth-Kartenterminal

    

     

      
Version
      
3.17.0
     
     

      
Revision
      
867138
     
     

      
Stand
      
12.02.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_KT
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert Anforderungen für eHealth-Kartenterminals, die bei der Realisierung (bzw. dem Betrieb) von Produkttypen der TI zu beachten sind. Diese Anforderungen sind als übergreifende Regelungen relevant für Interoperabilität und Verfahrenssicherheit.

Als Grundlage dieser Spezifikation gilt die SICCT-Spezifikation (Secure Interoperable ChipCard Terminal) [SICCT] der TeleTrusT. Darauf aufbauend werden die speziellen und abweichenden Anforderungen des Gesundheitswesens beschrieben.

Es beschreibt besondere funktionale Anforderungen an ein eHealth-Kartenterminal, gibt besondere sicherheitstechnische Anforderungen vor und beschreibt technisch notwendige Maßnahmen insbesondere für eine Nutzung von neuen Diensten der Telematikinfrastruktur für das Gesundheitswesen auf Basis der eGK.

1.2 Zielgruppe

Das Dokument ist maßgeblich für Hersteller von eHealth-Kartenterminals sowie Hersteller von Produkttypen, die hierzu eine Schnittstelle besitzen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzung

Für globale Anforderungen an multifunktionale Kartenterminals wird auf die Spezifikation „SICCT Secure Interoperable ChipCard Terminal“ [SICCT] verwiesen. Für spezielle Anforderungen gilt dieses Dokument.

Die SICCT-Spezifikation dient dabei als Basisdokument und

• orientiert sich an frei verfügbaren internationalen Standards,
• beschreibt technische Spezifikationen der Kommunikationsebene(n) und
• beschreibt grundlegende Sicherheitsanforderungen.

Festlegungen, welche im Schutzprofil (Protection Profile) des Kartenterminals gemäß Common Criteria getroffen werden, werden hier nur angeführt, soweit es für das Verständnis erforderlich ist.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche innerhalb Afo-ID und der Textmarke angeführten Inhalte.

In dieser Spezifikation wird der Begriff „Administrator“ verwendet. Hierunter ist keine Berufsbezeichnung zu verstehen, sondern die Rolle Administrator, welche zur Verwaltung der Komponente besondere Rechte und Aufgaben hat. Darüber, welche Person diese Rolle ausfüllt, werden keine Vorgaben gemacht.

2 Architektur

Ein eHealth-Kartenterminal für den Einsatz im deutschen Gesundheitswesen basiert auf der Spezifikation SICCT [SICCT], welche durch Profilierungen für den Betrieb als eHealth-Kartenterminal mit dieser Spezifikation angepasst wird.

Die Ableitungen der physischen Ausprägungen der einzelnen Kartenterminaltypen sind informativ in Abbildung „Pic_KT_0004 Physische Ausprägung Kartenterminal“ basierend auf dem Architekturmodell der SICCT-Spezifikation [SICCT#3.2] dargestellt.

Abbildung 1: Pic_KT_0004 Physische Ausprägung Kartenterminal

Für die physische Ausprägung profiliert diese Spezifikation den SICCT-Standard dahingehend, dass das eHealth-Kartenterminal ein PIN-Pad und ein Display verbindlich aufweisen muss. Ebenso werden für das eHealth-Kartenterminal mindestens eine ID-1 und mindestens zwei ID-000-Kontaktiereinheiten gefordert.

Das eHealth-Kartenterminal muss u. a. zur Authentisierung, zur Integritätssicherung und zur Sicherstellung der Vertraulichkeit der über die LAN-Schnittstelle übertragenen Daten mit einem kryptographischen Schlüssel arbeiten. Für diesen Schlüssel ist aufgrund des teilweise sehr hohen Schutzbedarfes der über die LAN-Schnittstelle übertragenen Informationsobjekte ein sicherer Schlüsselspeicher, ein SM-KT, erforderlich. eHealth-Kartenterminals müssen als physische Ausprägungen der SM-KT die gSMC-KT unterstützen.

Für die Anbindung des eHealth-Kartenterminals an einen Konnektor über die LAN-Schnittstelle ist das SICCT-Protokoll mit den EHEALTH-Erweiterungen (siehe Kapitel 3.7) verpflichtend vorgeschrieben.

Die sich durch die Spezifikation des eHealth-Kartenterminals ergebenden Schnittstellen und die sie nutzenden Kommunikationspartner sind im Komponentendiagramm informativ zusammenfassend dargestellt (siehe Abbildung „Pic_KT_0006 Schnittstellen des Kartenterminals“).

Abbildung 2: Pic_KT_0006 Schnittstellen des Kartenterminals

2.1 Anschlussarten eines Terminals

Die konkrete Ausprägung eines Kartenterminals für den Einsatz im Rahmen der Telematikinfrastruktur im Gesundheitswesen wird durch diese Spezifikation nicht vorgegeben, sondern nur die funktionalen und nicht-funktionalen Anforderungen. Grundsätzlich kennt die Architektur der Telematikinfrastruktur im Gesundheitswesen nur netzwerkfähige Kartenterminals, jedoch sind auch Mischformen vorstellbar. Die jeweilige Ausprägung wird primär von den Anforderungen der Geschäftsprozesse und den Sicherheitsanforderungen vorgegeben.

Zur Erläuterung ist anzumerken, dass grundsätzlich zwei unterschiedliche Lösungsansätze zur Realisierung der Anforderungen dieser Spezifikation umgesetzt werden können:

• Netzwerkfähige Kartenterminals werden über eine TLS-Verbindung angesteuert. Die TLS-Verbindung terminiert im Kartenterminal und sichert die Kommunikation mit dem Kartenterminal ab. Die Ausprägung des Netzwerks zwischen Kartenterminal und Konnektor wird hier nicht betrachtet. Für die Zulassung durch die gematik muss ein netzwerkfähiges Kartenterminal mittelbar oder unmittelbar über eine Ethernet-Verbindung angesteuert werden können. Falls ein netzwerkfähiges Kartenterminal nur mittelbar über Ethernet angesteuert werden kann, muss der Hersteller der gematik gegebenenfalls technischen Support leisten. Die vorliegende Spezifikation ist in diesen Fällen direkt vom Kartenterminal zu erfüllen und nur das Kartenterminal stellt einen Prüf- und Evaluationsgegenstand (Prüf- und Evaluierungsgegenstand im Sinne einer Sicherheitszertifizierung und der Zulassung durch die gematik gemäß [gemZulKomp_KT]) dar.
• Virtuelle Kartenterminals entstehen durch die Kombination einer Software mit einem nicht-netzwerkfähigen Kartenterminal (z. B. mit einer seriellen Schnittstelle) oder einem netzwerkfähigen Kartenterminal, welches nicht die hier gestellten Schnittstellenanforderungen erfüllt. Die adaptierende Software kann dabei auf einem anderen Gerät ablaufen und „exportiert“ das Kartenterminal mit den Schnittstellen und Funktionalitäten wie in dieser Spezifikation beschrieben. Die Verbindung zwischen Kartenterminal und adaptierendem Gerät muss dabei entweder durch den Nutzer des Kartenterminals überschaubar (z. B. Kabel im Sichtbereich des Nutzers) oder der Datenfluss zwischen Kartenterminals und Adapter verschlüsselt sein. Bei diesem Vorgehen sind die Softwarekomponente, deren Ausführungsumgebung, die Verbindung zwischen dem Kartenterminal und der Ausführungsumgebung und der Schlüsselspeicher der Ausführungsumgebung Bestandteil des zu prüfenden und zu evaluierenden Gegenstands (Prüf- und Evaluierungsgegenstand im Sinne einer Sicherheitszertifizierung und der Zulassung durch die gematik gemäß [gemZulKomp_KT]).

2.2 Zulassungsverfahren, Zertifikat

Für eine Zulassung des eHealth-Kartenterminals sind sicherheitstechnische und funktionale Prüfungen erforderlich. Das Zulassungsverfahren unterliegt den Vorgaben und der Aufsicht der gematik. Die Erteilung einer Zulassung erfolgt durch die gematik oder von ihr bevollmächtigte Dritte, siehe auch [gemZul_KT].

2.3 Allgemeine Anforderungen

In den folgenden Kapiteln sind die zu erfüllenden funktionalen und nicht-funktionalen Anforderungen an das eHealth-Kartenterminal aufgelistet und gleichzeitig Voraussetzungen an die beteiligten dezentralen Systemkomponenten bei den Leistungserbringern bzw. bei den Organisationen des Gesundheitswesens (z.B. Leistungserbringerorganisationen und Kostenträgerorganisationen) beschrieben.

2.3.1 Unterstützung Prozessor- und Speicherkarten

Das eHealth-Kartenterminal muss die durch die Telematikinfrastruktur entstehenden Anwendungsfälle unter Nutzung von Prozessorkarten sowie Speicherkarten (KVK) unterstützen.

Das bedeutet, dass die technische Funktionalität den Betrieb von kontaktbehafteten Speicher- wie auch Prozessorkarten erlaubt, und die Geräte konzeptionell für folgende Einsatzszenarien verwendbar sein müssen:

• Verarbeitung Spezifikations- und Norm-konformer KVKs,
• Verarbeitung Spezifikations- und Norm-konformer eGKs,
• Verarbeitung Spezifikations- und Norm-konformer HBAs,
• Verarbeitung Spezifikations- und Norm-konformer SMCs,
• Verarbeitung Spezifikations- und Norm-konformer ZOD-Karten und
• Verarbeitung Spezifikations- und Norm-konformer HBA-qSig-Karten

2.3.2 Anforderungen an die Kartenterminals

eHealth-Kartenterminals müssen aus Gesamtsystemsicht einem Konnektor folgende Funktionen bereitstellen:

• einen Zugriff auf einen oder mehrere Kartensteckplätze und darin gesteckte Chipkarten,
• eine eindeutige Adressierbarkeit jedes Kartenslots,
• eine Koordination der Zugriffe auf die Karten bzw. Exklusivität des Zugriffs
• Information über bestimmte Ereignisse (z. B. »Karte wurde (in zeitlicher Nähe) gesteckt«) und einen Event-Mechanismus zur Meldung an den Konnektor (zur Vermeidung von Polling),
• eine authentisierte, verschlüsselte und integritätsgesicherte Kommunikation,
• eine eindeutige, kryptographische Identität in einem „sicheren“ Schlüsselspeicher bereitstellen, für den gilt, dass die Schlüssel nicht durch einen Angreifer aus dem Gerät auslesbar sein dürfen (siehe Kapitel 2.5).

2.3.3 Benutzerführung

Graphische Displays, die in der Lage sind zwei Zeilen anzuzeigen, sind zugelassen.

Bei einem „virtuellen Kartenterminal“ kann die Benutzerführung auch über eine externe Anzeigeeinheit realisiert sein; diese unterliegt denselben Anforderungen einer Sicherheitsprüfung und -zulassung.

2.3.4 Performance

Das eHealth-Kartenterminal soll in seiner Konstruktion und Programmierung derart ausgelegt sein, dass es die Übertragungsraten zum Hostsystem und zu den Chipkarten entsprechend den technischen Spezifikationen (im Sinne von [SICCT], [eGK], [HBA]) unterstützt.

Bzgl. der Geschwindigkeit für die Kommunikation zwischen Kartenterminal und Karte ist hier Kap. 3.2.2 zu beachten. Die weiteren Vorgaben zur Performance werden im Dokument [gemSpec_Perf] erhoben.

2.3.5 Zuverlässigkeit

2.3.6 Stromversorgung

Hinweis: Zur Testung der Anforderung bezüglich der Nutzungsdauer ist es nicht praktikabel den Prüfling drei Jahre zu testen. Üblich sind Prüfungen unter Bedingungen, die ein schnelleres Altern von Bauteilen bewirken.

Hinweis: Die Werte in der Spalte "Arrhenius" wurden wie folgt berechnet (vergleiche https://de.wikipedia.org/wiki/Beschleunigte_Alterung): Ausgehend von der nach dieser Formel errechneten Zeit wurde der Wert für die Mindesttestdauer in der letzten Spalte festgelegt, wobei gilt:

 nachgewiesene Nutzungsdauer für die Temperatur  ,

 Testdauer bei der Temperatur  ,

 Aktivierungsenergie, konservativ angenommen mit  ,

   Boltzmann Konstante

2.3.7 Fehlertoleranz

Konkret, aber nicht ausschließlich bezieht sich dies auf die Resynchronisation der Kartenkommunikation.

2.3.8 Wartbarkeit

Der Hersteller sei darauf hingewiesen, dass aufgrund der besonderen Sicherheitsanforderungen (Sicherheitssiegel), die keine Öffnung des Gerätes zu Wartungszwecken ermöglichen, der wartungsfreie Betrieb, bis auf das Einspielen von Firmware-Updates, sicherzustellen ist.

2.3.9 Gehäuse

2.3.9.1 Aufbringen der MAC-Adresse

2.3.9.2 Aufbringen eines Prüfzeichens

TIP1-A_3107-01 - Optische Gestaltung des Prüfzeichens

Der Hersteller des eHealth-Kartenterminals MUSS eine der abgebildeten Varianten als Prüfzeichen verwenden und sicherstellen, dass die optische Gestaltung des Prüfzeichens den folgenden Vorgaben entspricht:

• Die Mindesthöhe des Prüfzeichens (exklusiv Schutzbereich) beträgt 10 mm.
• Das Seitenverhältnis des Prüfzeichens ist Breite/Höhe = 2,7/1.
• Die Farbgebung des Prüfzeichens ist einfarbig auf transparentem oder kontrastfarbigem Grund.
• Der einfarbige Schriftzug muss in einer der folgenden Farben ausgeführt sein:
• schwarz (RGB: 0, 0, 0)
• dunkelblau (RGB: 0, 14, 82)
• weiß (RGB: 255, 255, 255)
• Der Hintergrund muss transparent oder mit einer Kontrastfarbe versehen sein:
• weiß (RGB: 255, 255, 255) für schwarzen und blauen Schriftzug
• schwarz (RGB: 0, 0, 0) für weißen Schriftzug
• dunkelblau (RGB; 0, 14, 82) für weißen Schriftzug
• An allen vier Seiten des Prüfzeichens ist ein Schutzbereich vorzusehen. Dieser Bereich ist grundsätzlich frei zu halten von Objekten oder Beschriftungen.
• Der Schutzbereich wird durch die Größe des Prüfzeichens definiert und entspricht umlaufend der Höhe des Buchstaben "Z" im Schriftzug "Zugelassen".
• Das Prüfzeichen muss bei vorgesehener Verwendung des Kartenterminals durch einen Benutzer waagerecht orientiert sein. 

           
     

zulässige Varianten des Prüfzeichens und Darstellung des Schutzbereichs

[<=]

Die Berechtigung und Verpflichtung zur Nutzung des Prüfzeichens durch den Hersteller erfolgt mit der Zulassung der Geräte durch die gematik. Im Rahmen des Zulassungsantrags werden dem Hersteller alle Versionen des gematik-Prüfzeichens als Bilddateien in geeigneter Auflösung zur Verfügung gestellt.

Das Prüfzeichen bietet einen Wiedererkennungswert für zugelassene Kartenterminals, es sind keine Sicherheitsfunktionen damit verbunden.

2.3.10 Kommunikationsprotokolle

Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren, kann eine Nichterfüllung der Anforderung akzeptiert werden.

2.3.11 Firmware Update

Hierunter ist sowohl der Wechsel auf eine neuere Firmware als auch ein Downgrade auf eine über das Konzept der Firmware-Gruppen (siehe Abschnitt 2.4.1.1) zugelassene Firmware zu verstehen.

Die sicherheitstechnischen Anforderungen an das Firmware-Update sind Kapitel 2.4.1.1 zu entnehmen.

Im Folgenden werden unter dem Begriff Update-Komponente jene Funktionalitäten im LAN zusammengefasst, welche das Firmware-Update entsprechend der Vorgaben dieser Spezifikation umsetzt, unabhängig davon, auf welchen Komponenten (Kartenterminal und/oder Drittsystem) diese umgesetzt wird.

Die Konfiguration der Update-Komponente ist ebenso wie deren Realisierung sowie die Details zum Mechanismus, mit dem ein Firmware-Update auf den Kartenterminals über das LAN eingespielt wird, herstellerspezifisch (beispielsweise kann das Firmware-Update über die SICCT-Schnittstelle eingespielt werden).

Zusätzlich zur herstellerspezifischen Update-Komponente unterstützt das Kartenterminal die Update-Funktionen der SICCT-Spezifikation, wodurch eine ansteuernde Komponente in die Lage versetzt wird, das Kartenterminal zu aktualisieren (z. B. der KSR-Dienst der Telematikinfrastruktur).

2.3.12 Terminal Managementverfahren

Diese Schnittstellen können sowohl vom Konnektor, von Administrationsprogrammen der Hersteller als auch über das Webinterface durch den Administrator bedient werden (siehe auch Kapitel 2.4.5). LAN-Schnittstellen zur Administrierung sind mittels TLS gesichert (siehe Kapitel 2.4.5.1).

Aus den Sicherheitsforderungen des PP kann es sich ergeben, dass einzelne Managementfunktionen als sicherheitsrelevant eingestuft werden und daher Interaktionen an der lokalen Managementschnittstelle des KTs erfordern. Näheres hierzu ergibt sich aus dem PP und ist herstellerspezifisch umzusetzen.

2.3.12.1 SICCT-Terminalname

Beispiele: Die folgende Tabelle listet Beispiele für zulässige SICCT-Terminalnamen und wie diese am Display und im Dienstbeschreibungspaket dargestellt werden:

2.3.12.2 Produkttypversion und Selbstauskunft

Die Anforderungen bezüglich der Produkttypversion und Selbstauskunft sind in [gemSpec_OM] festgelegt. Hierüber hinaus gilt:

2.3.12.3 Informationen über gSMC-KT

2.3.13 Mehrwertmodule

Die gleichzeitige Verwendung von eHealth-Applikationen und herstellerspezifischen Mehrwertmodulen kann ein Sicherheitsrisiko darstellen.

Um die Sicherheit bei gleichzeitiger Verwendung von MWM und eHealth-Applikationen sicher zu stellen, ist der Nachweis der informationstechnischen Trennung von Mehrwertmodulen Bestandteil der Zulassung bzw. deren Evaluierung. Mehrwertmodule werden von der gematik nicht zugelassen.

2.3.14 Zugriffsanzeige

Es ist weder erforderlich, Zugriffe für jede Karte separat noch die Art des Zugriffs anzuzeigen.

2.3.15 Desinfektion der Kartenterminals (informativ)

Hersteller seien darauf hingewiesen, dass eHealth-Kartenterminals auch in Einsatzumgebungen verwendet werden können, die einem erhöhten Übertragungsrisiko für Infektionen, z. B. durch häufigen Hand- und Hautkontakt, ausgesetzt sind. Die regelmäßige Desinfektion der eingesetzten Geräte beim Leistungserbringer, dazu gehören auch Kartenterminals, ist eine Maßnahme zur Verminderung des Übertragungsrisikos und zur Einhaltung entsprechender Vorgaben, z. B. denen des Arbeitsschutzgesetzes. Weiterführende Informationen sind unter anderem den folgenden Dokumenten zu entnehmen:

1. Anforderungen an die Hygiene bei der Reinigung und Desinfektion von Flächen des Robert-Koch-Institutes [RKI],
2. Technischen Regeln für biologische Arbeitsstoffe im Gesundheitswesen und in der Wohlfahrtspflege [TRBA 250],
3. Hygieneleitfaden des Deutschen Arbeitskreises für Hygiene in der Zahnmedizin [DAHZ].

2.3.16 Produktsicherheit (informativ)

Das Kartenterminal darf nur in den Verkehr gebracht werden, wenn Sicherheit und Gesundheit von Anwendern nicht gefährdet werden. Dazu muss der Anwender der Produkte über alle Sicherheitsinformationen zum Produkt informiert werden. Auch muss der Kartenterminalhersteller den Lebenszyklus seines Produktes beobachten und bei bekannt gewordenen Mängeln die zuständige Behörde informieren und gegebenenfalls einen Rückruf einleiten. Das Kartenterminal muss den Anforderungen aus dem Gesetz über die Bereitstellung von Produkten auf dem Markt, kurz genannt Produktsicherheitsgesetz (ProdSG) entsprechen [PRODSG].

2.3.17 Physikalische Sicherheit-Klima

Als normaler Einsatzort wird für das eHealth-Kartenterminal ein Büroraum / ein Behandlungsraum angenommen.

Tabelle 1: Tab_KT_003 Anforderungen Klima

2.3.18 Physikalische Sicherheit-Vibration

Die durch Vibrationen und mechanische Schockbelastungen auftretenden Belastungen müssen vom Kartenterminal schadensfrei gemäß IEC 60068-2 Methode nach den folgenden Anforderungen absolviert, geprüft und nachgewiesen werden.

Tabelle 2: Tab_KT_004 Anforderungen Vibration

2.3.19 Benutzerfreundlichkeit und weitere Kennwort-/PIN-Eingaben

In den relevanten Dokumenten zum eHealth-Kartenterminal sind verschiedene Credentials detailliert spezifiziert. Dabei handelt es sich z.B. um das Direktkennwort zur Sicherung der direkten Managementschnittstelle, Administratorkennwörter zur Sicherung weiterer Managementschnittstellen, das Passwort zur Sicherung der CT ADMIN Session ([SICCT]) sowie optional Kennwörter zur Authentifizierung von weiteren Nutzern.

Weitere herstellerspezifische Credentials (z.B. zum Schutz des Shared Secrets durch Verschlüsselung), die sich durch die Verwendung geeigneter Hardware-Sicherungs-Maßnahmen vermeiden lassen, dürfen unter dem Aspekt der Benutzerfreundlichkeit nicht notwendig sein. Jede weitere Abfrage von Credentials, insbesondere, wenn sie nicht zum Schutz von Managementschnittstellen bei Administration, sondern auch im Regelbetrieb notwendig ist, verringert die Benutzerfreundlichkeit und damit die Akzeptanz des Geräts erheblich.

Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren und bei denen die Umstellung vom eHealth-BCS-Spezifikationsstand auf den eHealth-Spezifikationsstand per Firmware Upgrade (Firmware Update) erfolgt, kann eine Nichterfüllung der Anforderung [TIP1-A_6541] akzeptiert werden.

2.3.20 Zubehör

Es ist möglich, ein eHealth-Kartenterminal mit Zubehör zu betreiben. Als Zubehör werden im Folgenden Geräte oder Vorrichtungen verstanden, welche die Funktionalität des eHealth-Kartenterminals ergänzen, erweitern oder – mit den in den folgenden Textpassagen genannten Einschränkungen – duplizieren. Dies geschieht vorwiegend, um den Nutzerkomfort zu verbessern. Zubehör wird stets im Zusammenspiel mit einem eHealth-Kartenterminal betrieben und nie als Stand-Alone-Gerät eingesetzt. In diesem Abschnitt werden nur solche Arten von Zubehör betrachtet, die zur Erfüllung ihrer Funktion eine Datenkommunikation mit einem eHealth-Kartenterminal benötigen und somit auch selbst bestimmte Schutzfunktionen umsetzen, die wiederum von der konkreten Ausprägung des Zubehörs abhängen. Andere Hilfsmittel, die nicht technisch mit einem eHealth-Kartenterminal interagieren werden hier nicht betrachtet. Unter Berücksichtigung dieser Definition wird im Folgenden ausschließlich von „Zubehör“ gesprochen.

Logisch betrachtet besteht ein eHealth-Kartenterminal, welches zusammen mit Zubehör betrieben wird, aus drei Komponenten:

• Basis-eH-KT, ein eHealth-Kartenterminal in seiner „klassischen“ Ausprägung und Funktion inklusive Hardware (identisch zu einem eHealth-Kartenterminal, welches ohne Zubehör betrieben wird),
• Zubehör bestehend aus Hard- und Software und
• KomZubehör, einer Software-Erweiterung des eHealth-Kartenterminals zum Datenaustausch mit Zubehör.

2.3.20.1 Zulassungsverfahren für eHealth-Kartenterminal und Zubehör zusammen

Der Betrieb von Zubehör erfordert eine Zulassung des Zubehörs durch die gematik. Dabei wird nie das Zubehör selbst zugelassen, sondern stets das Zubehör in Verbindung mit einem bestimmten Produkttypen für ein eHealth-Kartenterminal, welches das Zubehör nutzt. Falls eine Nutzung ein und desselben Zubehörs auch mit einer anderen Ausprägung von eHealth-Kartenterminals angestrebt ist, so ist hierfür eine weitere Zulassung erforderlich. Dies ist unabdingbar wegen der für die Kommunikation mit dem Zubehör notwendigen Anpassungen an der jeweiligen eHealth-Kartenterminal-Firmware (Software-Erweiterung KomZubehör).

2.3.20.2 Sicherheitsnachweise

Für die Zulassung eines eHealth-Kartenterminals mit einem Zubehör sind drei Sicherheitsnachweise notwendig, die im Anschluss näher betrachtet werden:

• CC-Zertifizierung nach PP-0032 für das Basis-eH-KT,
• Prüfung durch eine CC-Prüfstelle für das Zubehör und
• Prüfung durch eine CC-Prüfstelle für die KomZubehör Software-Erweiterung des eHealth-Kartenterminals.

Abbildung 3: Überblick zu Komponenten eines eHealth-Kartenterminals

Motivation für dieses Vorgehen ist, einen zielgerichteten, flexiblen Sicherheitsnachweis zu ermöglichen, der die notwendige Prüftiefe erreicht, um eine belastbare Aussage zur Sicherheit zu erhalten, aber jeweils schnell für unterschiedliche Zubehöre individuell anpassbar ist. Daher wird für das Zubehör und die KomZubehör Software-Erweiterung am eHealth-Kartenterminal das Prüfverfahren „Sich.techn. Eignung: Prüfung durch CC-Prüfstelle“ eingeführt.

Kern dieses Prüfverfahrens ist die Prüfung des Zubehörs und der KomZubehör Software-Erweiterung des eHealth-Kartenterminals durch die Common-Criteria-Prüfstelle, die bereits die Evaluation bei einer erfolgreichen CC-Zertifizierung des eHealth-Kartenterminal, welches mit dem Zubehör erweitert wird, durchgeführt hat. Konkret hat auch der CC-Evaluator, der bereits das eHealth-Kartenterminal evaluierte, als Prüfer zu agieren. Grundlage der Prüfung sind vom Hersteller erstellte und mit der gematik abgestimmte individuelle Prüfvorgaben ähnlich einem Security Target (ST). Die Prüfvorgaben decken die Anforderungen des Kapitels  ab und werden von der gematik erst nach fachlicher Prüfung auf Korrektheit und Vollständigkeit freigegeben. Nur von der gematik abgenommene Prüfvorgaben sind als Grundlage für die Sicherheitsprüfung zulässig.

Fokus der Prüfung sind die Aspekte ATE_IND und AVA_VAN eines CC-Verfahrens, wobei die für die Prüfstelle für die Ausführung dieser Aspekte notwendigen Artefakte ebenso vom Hersteller an die Prüfstelle zu liefern sind wie in einem CC-Verfahren (dies betrifft etwa die Dokumente, die bei einem CC-Verfahren in der Klasse ADV erstellt werden, wobei eben eine formale Evaluierung dieser Dokumente selbst nicht erforderlich ist). Die Prüftiefe der Tests und der Schwachstellenanalyse durch die Prüfstelle ist mit ATE_IND.2 und AVA_VAN.4 dabei identisch mit der des CC-Verfahrens des eHealth-Kartenterminals.

Hinsichtlich der KomZubehör-Software-Erweiterung des eHealth-Kartenterminals wird zusätzlich geprüft, dass diese Erweiterungen die in der CC-Zertifizierung nach PP-0032 betrachteten Sicherheitsfunktionen nicht negativ beeinflusst, diese also aufrecht erhalten bleiben.

Als Ergebnis der Prüfung wird der Prüfbericht (vergleichbar mit dem Bericht ETR eines CC-Verfahrens) von der Prüfstelle erwartet, der vom Hersteller bei der gematik zur Abnahme einzureichen ist. Die gematik wird bei Nachfragen direkt auf die Prüfstelle zugehen.

Der Prozess zu diesem Sicherheitsnachweis ist in der Verantwortung der gematik. Eine Zertifizierung durch das BSI findet nicht statt. Das BSI ist im Rahmen der bestehenden BSI-Zertifizierung an diesem beschriebenen Prozess nicht beteiligt und erteilt weder eine Aussage zur Sicherheit des Zubehörs noch der KomZubehör-Software-Erweiterung des eHealth-Kartenterminals.

Die CC-Zertifizierung des eHealth-Kartenterminals nach PP-0032 bleibt unverändert. Das PP-0032 wird weder bezüglich des Zubehörs noch der Kommunikation mit dem Zubehör angepasst. Das Zubehör ist nie Teil des TOE bei dieser CC-Zertifizierung. Es wird lediglich implizit im CC-Verfahren geprüft, dass die zusätzliche KomZubehör Software-Erweiterung im eHealth-Kartenterminal keinen negativen Einfluss auf die nach PP-0032 zu zertifizierenden Sicherheitsfunktionen hat.

Im Betrieb eines eHealth-Kartenterminals, welches prinzipiell Zubehör unterstützt, gibt es somit aus Sicht des Sicherheitsnachweises zwei Zustände: Bei Nutzung ohne Zubehör – also des reinen Basis-eH-KT – findet ein Betrieb unter dem Sicherheitsnachweis „CC-Zertifizierung unter Hoheit des BSI“ statt. Bei der Nutzung des eHealth-Kartenterminals mit Zubehör findet ein Betrieb unter dem Sicherheitsnachweis „Prüfung durch CC-Prüfstelle unter Hoheit der gematik“ statt. In beiden Fällen liegt somit ein sicherer und von der gematik zugelassener Betrieb vor.

2.3.20.3 Anforderungen

In diesem Kapitel sind die zu erfüllenden funktionalen und nicht-funktionalen Anforderungen an das Zubehör des eHealth-Kartenterminals aufgelistet und gleichzeitig Voraussetzungen an das eHealth-Kartenterminal beschrieben, mit dem das Zubehör zusammenarbeiten soll.

Kommunikationsschnittstellen des Zubehörs:

• Das Zubehör kommuniziert in jedem Fall mit dem ihm (durch Pairing) zugeordneten Basis-eH-KT. Dieser Kommunikationskanal ist hinsichtlich Vertraulichkeit und Integrität geschützt.
• Es ist möglich, dass Zubehör im Sinne einer Datenausgabe oder Dateneingabe mit einem Nutzer interagiert.
• Es ist möglich, dass Zubehör im Sinne eines Proximity Coupling Device (PCD) mit einer Smartcard interagiert. In diesem Fall werden Kommando-APDU stets im Basis-eH-KT erzeugt und vom Zubehör lediglich an die Smartcard durchgereicht. In gleichartiger Weise werden Antwort APDU einer Smartcard vom Zubehör an das Basis-eH-KT durchgereicht. Zubehör mit einer Kontaktiereinheit für die kontaktbehaftete Kommunikation mit Smartcards ist ausgeschlossen.

Weitere Verbindungen eines Zubehörs, etwa mit einem Konnektor, sind nicht gestattet.

Hinweis: Es ist zu berücksichtigen, dass die Nutzer des eHealth-Kartenterminals gewohnt sind, dass sich das eHealth-Kartenterminal für eine gewisse Zeit (10 min) selbst schützt bzw. ein Austausch des Geräts in dieser Zeitspanne nicht unbemerkt möglich ist. Dies ist beim Zubehör je nach Ausführung möglicherweise nicht gegeben. Deshalb ist der Nutzer darauf eindeutig hinzuweisen.

Hinweis: Aus den Anforderungen A_19435 und A_19436 folgt unmittelbar, dass bei einer kontaktlosen Anbindung einer Karte an ein Zubehör, etwa der sichere PACE-Kanal im Basis-eH-KT endet, nicht im Zubehör. Dadurch ist auch offensichtlich, dass die stets unverschlüsselte kontaktbehaftete Anbindung von Karten für das Zubehör nicht zulässig ist.

Hinweis: Es ist zulässig das Zubehör auf demselben Weg an die Kunden auszuliefern, wie das Basis-eH-KT (Nachnutzung der sicheren Lieferkette ab Werk).

2.4 Spezielle sicherheitstechnische Anforderungen

Basissicherheitsanforderungen sind im Kapitel 8 der SICCT-Spezifikation [SICCT] beschrieben. Des Weiteren sind die Anforderungen aus der Technischen Richtlinie TR-03120 [TR-03120] sowie dem Anhang zur TR-03120 [TR-03120-Anhang] (Versiegelung) verpflichtend umzusetzen.

2.4.1 Firmware Update

Das eHealth-Kartenterminal muss über eine gesicherte Update-Möglichkeit der KT-Firmware verfügen (siehe Kapitel 2.3.11).

Für das Verwaltungsverfahren gelten mindestens die Anforderungen, die in der Sicherheitsevaluierung und dem zugehörigen Protection Profile sowie den Sicherheitszielen zu Grunde gelegt werden.

Die Notwendigkeit des Wechsels auf eine Vorversion der installierten Firmware kann sich u. a. aus den folgenden Gründen ergeben:

• aus Betriebsgründen, z. B. zur kurzfristigen Behebung eines aufgetretenen Fehlverhaltens.
• im Rahmen der Migration, um Rollback-Szenarien bei der Einführung neuer Releases zu ermöglichen.

Dieser Wechsel der Firmware kann z. B. durch ein Firmware Downgrade (ein Wechsel auf eine Firmware mit kleinerer Versionsnummer) realisiert werden. Aus Sicherheitsgründen sind solche Firmware Downgrades allerdings nur eingeschränkt und unter Berücksichtigung der im „Konzept der Firmwaregruppen“ beschriebenen Anforderungen (Kapitel 2.4.1.1) erlaubt. Die Art der Versionierung ist unter der Einhaltung der Vorgaben aus [gemSpec_OM] herstellerspezifisch.

2.4.1.1 Konzept der Firmware-Gruppen

Das Konzept der Firmwaregruppen wird in [gemSpec_OM] beschrieben. Weitere Anforderungen in diesem Zusammenhang ergeben sich aus [gemSpec_KSR]. Über die dortigen Anforderungen hinaus gilt:

2.4.2 Anzeige des vertrauenswürdigen Zustands

Im vertrauenswürdigen Zustand befindet sich das eHealth-Kartenterminal in einem Modus, bei dem keine Beeinflussung und keine Informationsabschöpfung durch Komponenten (dazu zählt auch Software), welche nicht über eine Zulassung durch die gematik verfügen, möglich ist.

Das Kartenterminal muss sicherstellen, dass SICCT- bzw. EHEALTH-Kommandos ausschließlich im vertrauenswürdigen Zustand ausgeführt werden (siehe Kapitel 3.11) Daher braucht der vertrauenswürdige Zustand nicht zwingend angezeigt werden.

Der vertrauenswürdige Zustand bleibt auch während der Ausführung von Mehrwertmodulen erhalten (siehe Kapitel 2.3.13).

2.4.3 Sicherer PIN-Modus

Der sichere PIN-Modus besagt, dass PIN-Eingaben am Kartenterminal nicht in die unsichere Umgebung des Personalcomputers oder über offene Übertragungswege an den Client gelangen.

Da sich eine Remote-PIN Eingabe auch um eine PIN-Eingabe handelt, befindet sich das eHealth-Kartenterminal auch bei der Remote-PIN Eingabe in diesem sicheren PIN-Modus. Eine separate Anzeige, dass es sich um eine Remote-PIN-Eingabe handelt, ist nicht erforderlich.

2.4.4 Sicherheitsanforderungen LAN-gekoppelter Terminals

Die Sicherheitsanforderungen der eHealth-Kartenterminals orientieren sich entlang der Kommunikationskanäle und Funktionen:

• sichere Identifikation und Authentisierung des Kartenterminals durch den Konnektor mit Hilfe kryptographischer Verfahren,
• Schutz der Vertraulichkeit, Authentizität und Integrität der übertragenen Daten,
• Schutz des Zugangs zu administrativen Einstellungen am Kartenterminal mit einem Passwortmechanismus oder höherer Sicherheit (z. B. 2-Faktor-Authentifizierung, bei der es sich um eine Kombination von zwei Verfahren handelt, z. B. aus Wissen (PIN) und Besitz (Karte)).

Für die Sicherung der hierfür notwendigen Netzwerkkommunikation sind für alle Kartenterminals die in [gemSpec_Krypt] genannten Verfahren als einheitliche auf Zertifikaten basierende Verfahren vorgegeben. Dies deckt – im Zusammenspiel mit der hinter dem Zertifikat stehenden PKI sowie dem Pairing des Kartenterminals mit dem Konnektor – auch die Forderung nach der sicheren Identifikation und Authentisierung des Kartenterminals durch den Konnektor ab. Der zum Zertifikat (C.SMKT.AUT) gehörige geheime Schlüssel (PrK.SMKT.AUT) ist in einem manipulationsgeschützten Speicher (SM-KT) verwahrt, der einen unbefugten Zugriff auf das Schlüsselmaterial verhindert.

2.4.5 Terminal Managementverfahren

2.4.5.1 Sicherung netzwerkbasierter Managementschnittstellen

Hinweis 1: Eine SICCT-spezifische TLS-Verbindung basiert stets auf einer gegenseitigen Authentisierung.

Hinweis 2: Im Rahmen eines TLS-Handshakes für die netzwerkbasierte Managementschnittstelle ist es möglich, mittels beidseitiger Authentisierung die notwendige Rollenauthentisierung (für die Rolle Administrator oder SMC-B-Nutzer) zu erfüllen. In diesem Fall wäre keine zusätzliche Rollenauthentisierung (wie beispielsweise Username & Passwort) erforderlich.

Hinweis 3: In A_24065 Punkt 1 ist von "kryptographischen Verfahren" die Rede, die "so und in ihrer gesamten Kombination . . . von [gemSpec_Krpyt] als zulässig bewertet werden. Beispielsweise sind für die Authentisierung sowohl RSA als auch ECC Verfahren vorgesehen. Für die symmetrische Verschlüsselung ist AES in den Modi CBC und GCM vorgesehen. Die Verwendung von DES wird in [gemSpec_Krypt] ausgeschlossen. Zusätzlich schließt [gemSpec_Krypt] aber auch die Kombination ECC mit AES-CBC aus. [gemSpec_Krypt] sieht diesbezüglich nur die Kombinationen (RSA, AES-CBC) und (ECC, AES-GCM) vor.

Als Bestandteil der Authentisierung ist auch ein eventuell sicheres Einbringen eines Zertifikates in den Client anzusehen.

Es sei darauf hingewiesen, dass die Nutzung desselben Zertifikats für alle Kartenterminals einer Baureihe mit einem Risiko behaftet ist, da der zugehörige private Schlüssel auf allen Kartenterminals einer Baureihe verteilt ist. Details zu den Vorgaben an die Zertifikate sind Bestandteil der Sicherheitsevaluierung.

2.4.5.2 Anforderungen an Kennwörter zur Sicherung der Managementschnittstelle

Im Folgenden werden die Anforderungen an die Kennwörter zur Sicherung der Managementschnittstellen aufgeführt. Das Administratorkennwort, welches lokal direkt an der Tastatur des Kartenterminals (im Folgenden direkte Managementschnittstelle, siehe auch Kapitel 2.3.12) eingegeben wird, wird als Direktkennwort bezeichnet.

Für alle Kennwörter zur Sicherung einer Managementschnittstelle gelten folgende Anforderungen.

Zusätzliche, nicht normative Informationen zur Handhabung von Kennwörtern sind im vom BSI herausgegebenen Maßnahmenkatalog Organisation (M 2) Abschnitt 11 „Regelungen des Passwortgebrauchs“ [BSI-M2.11] beschrieben.

2.4.5.3 Anforderungen an die PUK für die Durchführung des Werksresets

Im Folgenden werden die Anforderungen an die PUK zur Sicherung des Werksresets aufgeführt, wenn dieser Mechanismus vom Hersteller umgesetzt ist.

Weiterhin müssen für die Sicherung des Werksresets durch ein PUK-Verfahren die folgenden Anforderungen aus Kap. 2.4.5.2 umgesetzt werden:

• einen Fehlerzähler für die PUK Eingabe implementieren und diesen im spannungslosen Zustand erhalten (siehe [TIP1-A_2995]).
• diese ab der dritten aufeinander folgenden ungültigen Eingabe der PUK sperren, wobei die Dauer der Sperrzeit von der Anzahl aufeinander folgender Fehlversuche abhängig ist (siehe [TIP1-A_2994]).
• sicherstellen, dass die PUK mindestens acht Zeichen lang ist und mindestens aus Ziffern (‚0’ bis ‚9’) besteht (siehe [TIP1-A_3000]). Die PUK kann auch aus einer Mischung aus Ziffern, Buchstaben und Sonderzeichen bestehen (siehe [TIP1-A_3001]) und darf eine zur Rollen-Authentisierung verwendete Benutzer-ID als Teilzeichenkette nicht enthalten (siehe [TIP1-A_3002]).
• sicherstellen, dass die PUK nicht auf programmierbaren Funktionstasten gespeichert werden kann (siehe [TIP1-A_3003]).
• sicherstellen, dass die PUK bei der Eingabe nicht im Klartext angezeigt wird (siehe [TIP1-A_3004]).
• sicherstellen, dass die PUK vollständig (und nicht nur ein Ausschnitt) geprüft wird (siehe [TIP1-A_3416]).

Zusätzliche, nicht normative Informationen zur Handhabung von Kennwörtern sind im vom BSI herausgegebenen Maßnahmenkatalog Organisation (M 2) Abschnitt 11 „Regelungen des Passwortgebrauchs“ [BSI-M2.11] beschrieben.

2.4.6 Übergreifende Sicherheitsanforderungen

Die übergreifenden Sicherheitsanforderungen resultieren aus dem Schutzbedarf der nachfolgenden Sicherheitsobjekte:

• Signatur-PIN und Qualifizierte Signatur des Leistungserbringers bzw. eines Mitarbeiters einer Organisation des Gesundheitswesens
• PINs
• Session Key oder Objektschlüssel

Die Maßnahmen zum Schutz von diesen Informationsobjekten mit hohem und sehr hohem Schutzbedarf (z. B. PINs, Schlüssel, medizinische Daten) drücken sich im PP des Kartenterminals in organisatorischen Anforderungen der Einsatzumgebungen und sicherheitstechnischen Maßnahmen des Kartenterminals aus.

Hierunter fällt auch ein eventuelles Logging.

2.4.7 Protection Profile (Schutzprofil)

Das Protection Profile für Kartenterminals [BSI-CC-PP-0032] legt die Mindestanforderungen im Sinne von Sicherheitszielen für ein eHealth-Kartenterminal fest und beschreibt Funktionalitätsklassen. Das Protection Profile dient als Basis zur Durchführung einer Evaluierung im Rahmen der Zertifizierung nach Common Criteria des umfassenden Produkts. Die Anforderungen aus dem Protection Profile sind umzusetzen.

Weitere Sicherheitsfunktionen von Kartenterminals, die über die Anforderungen an ein eHealth-Kartenterminal hinausgehen, werden in die anschließende Evaluierung eingebunden oder erfordern zusätzliche Sicherheitsgutachten oder Evaluierungen.

2.4.7.1 Umgebungsanforderungen für Kartenterminals

Die Anforderungen an die Einsatzumgebung der Kartenterminals werden im Kapitel der Annahmen des Schutzprofils [BSI-CC-PP-0032] des BSI festgelegt und müssen vom Hersteller bei der Evaluierung berücksichtigt werden.

2.4.8 Zufallszahlen und Schlüssel

Ein Zufallsgenerator erzeugt Zufallszahlen und Schlüssel im Rahmen bestimmter Kryptoverfahren, wie z. B. Challenge-Response-Authentifizierung bei TLS.

Die Länge der angeforderten Zufallszahlen bzw. Einmalschlüssel und die Qualität des Generators ist vom jeweiligen Einsatzzweck abhängig. Die entsprechenden Regelungen sind [gemSpec_Krypt#GS-A_4367] zu entnehmen.    

Da das SM-KT erst in das Kartenterminal eingebracht werden muss, steht der Zufallszahlengenerator des SM-KT nicht immer zur Verfügung.

Dieser Zufallszahlengenerator kann, selbst wenn er die Anforderungen an Qualität und Güte aus [gemSpec_Krypt#2.2] nicht erfüllt, zum Aufbau von nicht SICCT-spezifischen TLS-Verbindungen verwendet werden.

Es liegt in der Verantwortung der Hersteller im Rahmen der Sicherheitsevaluierung nachzuweisen, dass durch den Einsatz des Zufallszahlengenerators des Kartenterminals kein Schaden entstehen kann.

2.4.9 PIN-Eingabe via Managementschnittstelle (optional)

2.4.9.1 Überblick

Für Karten, die in einem eHealth-KT verarbeitet werden, sind derzeit zwei Möglichkeiten für die PIN-Eingabe spezifiziert (vergleiche dazu auch [TR-03114#2.2]:

Definition: Die "lokale PIN-Eingabe" ist dadurch gekennzeichnet, dass die PIN-Eingabe an dem eHealth-KT erfolgt, in welchem sich die Chipkarte befindet, welche die PIN prüft.

Bei der "lokalen PIN-Eingabe" sendet der Konnektor über die SICCT/EHEALTH-Schnittstelle ein SICCT PERFORM VERIFICATION Kommando an das eHealth-KT mit einem CMD DO gemäß [SICCT#5.5.10.23]. Das CMD DO enthält in diesem Fall ein VERIFY Kommando. Bei der Bearbeitung des SICCT PERFORM VERIFICATION Kommandos wird das eHealth-KT den Nutzer nach einem PIN-Wert fragen, diesen über eines seiner PIN-Pads entgegennehmen und das VERIFY Kommando an die adressierte Kartenschnittstelle senden. Im Erfolgsfall ist der PIN-Sicherheitszustand in der adressierten Karte gesetzt.

Die "lokale PIN-Eingabe" ist der Regelfall.

Definition: Die "entfernte PIN-Eingabe" (auch "remote PIN" genannt), ist dadurch gekennzeichnet, dass die PIN-Eingabe an einem ersten eHealth-KT erfolgt und die PIN von einer Chipkarte geprüft wird, die in einem zweiten eHealth-KT steckt.

Bei der "entfernten PIN-Eingabe" sendet der Konnektor über die SICCT/EHEALTH Schnittstelle ein SICCT PERFORM VERIFICATION Kommando an das erste eHealth-KT. Das SICCT PERFORM VERIFICATION Kommando adressiert in diesem Fall die gSMC-KT des ersten eHealth-KT und enthält im CMD DO ein PSO Encipher Kommando. Bei der Bearbeitung des SICCT PERFORM VERIFICATION Kommandos wird das erste eHealth-KT den Nutzer nach einem PIN-Wert fragen, diesen über eines seiner PIN-Pads entgegennehmen und das PSO Encipher Kommando an die adressierte gSMC-KT senden. Im Erfolgsfall wird der eingegebene PIN-Wert innerhalb der gSMC-KT so verschlüsselt, dass er von der Chipkarte im zweiten eHealth-KT, welche die PIN prüft, entschlüsselt werden kann. Der verschlüsselte PIN-Wert wird vom Konnektor über die SICCT/EHEALTH-Schnittstelle im Rahmen eines VERIFY Kommandos an das zweite eHealth-KT gesendet. Dabei wird die Kartenschnittstelle der Chipkarte adressiert, welche die PIN prüft. Im Erfolgsfall ist der PIN-Sicherheitszustand in der adressierten Karte gesetzt.

Die "entfernte PIN-Eingabe" wird in der [TR-03114] näher beschrieben und wurde für den Einsatz von Stapel- und Komfortsignatur spezifiziert.

Dieses Kapitel beschreibt eine weitere Möglichkeit der PIN-Eingabe, die optional von einem eHealth-KT angeboten wird und mit "PIN-Eingabe via Managementschnittstelle" (PEviM) bezeichnet wird. Zunächst wird ein Überblick über die neue Funktionalität gegeben:

1. Aus funktionaler Sicht stellt sich die neue Funktionalität wie folgt dar:
2. 1. Im Auslieferungszustand ist die "PIN-Eingabe via Managementschnittstelle" deaktiviert. In diesem Zustand lässt das eHealth-KT nur die Eingabemöglichkeiten "lokale PIN-Eingabe" und "entfernte PIN-Eingabe" zu.
   2. Nur die Rolle Administrator gemäß [TIP1-A_2981-*] ist in der Lage, die "PIN-Eingabe via Managementschnittstelle" für ein eHealth-KT zu aktivieren.
   3. Das Kartenterminal kennt die zusätzliche Rolle "SMC-B_Nutzer". Nur die Rolle SMC-B_Nutzer ist in der Lage den Use Case "PIN-Eingabe via Managementschnittstelle" durchzuführen.
   4. Die "PIN-Eingabe via Managementschnittstelle" lässt sich nur von den Rollen Administrator und SMC-B_Nutzer deaktivieren.
   5. Es ist möglich, dass ein eHealth-KT die Rollen SMC-B_Nutzer einerseits und Administrator andererseits nicht unterscheidet. In dem Fall ist jeder Administrator auch SMC-B_Nutzer im Sinne dieses Dokumentes.
   6. Das eHealth-KT erzwingt, dass die "PIN-Eingabe via Managementschnittstelle" nur mit einer SMC-B durchführbar ist. Mithin verhindert das eHealth-KT, dass die "PIN-Eingabe via Managementschnittstelle" etwa für eine eGK oder einen HBA nutzbar ist.
   7. Wenn die "PIN-Eingabe via Managementschnittstelle" aktiviert ist, dann gelangt der PIN-Wert für eine SMC-B (auch) über eine Managementschnittstelle in das eHealth-KT, statt über das PIN-Pad (siehe "lokale PIN-Eingabe") oder über die SICCT/EHEALTH-Schnittstelle (siehe "entfernte PIN-Eingabe").
3. Aus sicherheitstechnischer Sicht ist folgendes relevant:
4. 1. Der SMC-B_Nutzer gewährleistet, dass der Aufruf der Managementschnittstelle und die Eingabe der PIN der SMC-B ausschließlich an Clients geschieht, die er oder seine Organisation unter seiner Kontrolle hat und deren Sicherheit er oder seine Organisation durchsetzen kann (analog zu den Clients von denen aus der Konnektor genutzt wird)

Wenn die "PIN-Eingabe via Managementschnittstelle" aktiviert ist, dann ändert sich an der SICCT/EHEALTH-Schnittstelle das Verhalten des eHealth-KT bezüglich eines SICCT PERFORM VERIFICATION Kommandos nichts, nur die Bearbeitung des SICCT PERFORM VERIFICATION Kommandos innerhalb des eHealth-KT ändert sich wie folgt (wobei hier davon ausgegangen wird, dass das CMD DO ein VERIFY Kommando enthält):

Das eHealth-KT prüft, ob es sich bei der im SICCT PERFORM VERIFICATION Kommando adressierten Karte um eine SMC-B handelt:

1. Falls nein (also keine SMC-B), dann "lokale PIN-Eingabe".
2. Falls ja (also SMC-B), dann wird geprüft, ob die Rolle SMC-B_Nutzer über eine Managementschnittstelle verbunden ist,
3. 1. falls ja, dann wird der PIN-Wert über diese Managementschnittstelle entgegengenommen, sonst
   2. erfolgt eine "lokale PIN-Eingabe".

2.4.9.2 Anforderungen

Die Unterstützung der Funktionalität "PIN-Eingabe via Managementschnittstelle" (PEviM) ist ein optionales Feature.

Hinweis: Wenn PEviM deaktiviert ist, dann lassen sich PIN-Werte nur mittels "lokaler PIN-Eingabe" oder "entfernter PIN-Eingabe zu Karten im eHealth-KT übertragen.

Hinweis: Gemäß TIP1-A_3101 sind im Auslieferungszustand alle Managementschnittstellen deaktiviert. Nach Setzen entsprechender Kennwörter lassen sich gemäß TIP_2967 weitere Managementschnittstellen aktivieren. Gemäß TIP1-A_2968 ist das nur über die direkte Managementschnittstelle möglich. Gemäß TIP_2969 ist die Administration eines eHealth-KT über alle aktivierten Managementschnittstellen möglich.

2.4.9.3 Verhalten SICCT PERFORM VERIFICATION (Verify)

Hinweis: Sowohl diese Spezifikation als auch [SICCT] erheben eine Reihe von Anforderungen an das SICCT PERFORM VERIFICATION Kommando gemäß [SICCT#5.19]. Die Funktionalität PEviM stellt weitere Anforderungen, die sich allerdings nur auf die Quelle des PIN-Wertes beziehen. Die übrigen Anforderungen an das SICCT PERFORM VERIFICATION Kommando gelten weiterhin.

2.4.9.4 Verhalten SICCT MODIFY VERIFICATION DATA (Change RD)

Hinweis: Sowohl diese Spezifikation als auch [SICCT] erheben eine Reihe von Anforderungen an das SICCT MODIFY VERIFICATION DATA Kommando gemäß [SICCT#5.20]. Die Funktionalität PEviM stellt weitere Anforderungen, die sich allerdings nur auf die Quelle der PIN-Werte beziehen. Die übrigen Anforderungen an das SICCT MODIFY VERIFICATION DATA Kommando gelten weiterhin.

2.5 Festlegungen zu Kartenterminalidentität und Schlüsselmanagement

Ergänzend zum Abschnitt 8.6 der SICCT-Spezifikation werden die Mechanismen zur Erstellung, Einbringung und Sicherung der Kartenterminalidentität und der damit verbundenen geheimen Schlüssel beschrieben.

Die KT-Identität besteht aus der Kombination

• der Anforderung [TIP1-A_3227] und
• einem nachfolgend ausgehandelten gemeinsamen Geheimnis (ShS.KT.AUT) zwischen Kartenterminal und Konnektor (im Folgenden als Shared Secret bezeichnet, siehe auch 2.5.2).

Die SMKT-Identität wird u. a. zur Identifikation und Schlüsselaushandlung zwischen der Signaturanwendungskomponente (des Konnektors) und dem Kartenterminal genutzt. In einer LAN-Umgebung wird die „alleinige Kontrolle“ schwer darstellbar und kann nur über entsprechend sichere Identitäten und authentifizierte Verbindungen zu Kartenterminals wiederhergestellt werden.

Das SM-KT muss den privaten Schlüssel (PrK.SMKT.AUT) gegen ein Auslesen bzw. Vervielfachen sichern. Intention dieses Schutzmechanismus ist es nicht, die Integrität der Kartenterminal-Firmware gegen Angriffe zu schützen. Das SM-KT ist auf einer gSMC-KT in ID-000 Form aufgebracht.

Der Hersteller des eHealth-Kartenterminals ist der Herausgeber der Gerätekarte gSMC-KT.

Dem Administrator soll damit eine Handreichung gegeben werden, welche Prüfungen nach Empfang einer gSMC-KT und vor deren Verwendung durchzuführen sind. Der Administrator sollte beispielsweise nur eine gSMC-KT verwenden, die auch tatsächlich bestellt wurde und beim Empfang prüfen, ob die Verpackung und die Karte unversehrt sind und ob der Absender auch dem erwarteten Absender entspricht. Hierzu ist es notwendig, dass der Hersteller entsprechende Angaben zu Bezugsquellen und möglichen Versandadressen macht. Diese Angaben können im Handbuch und/oder auf der Webseite des Herstellers verfügbar gemacht werden. Dies muss für den Administrator aus dem Handbuch ersichtlich sein. Vor der Verwendung der gSMC-KT sollte der Administrator auch eine optische Prüfung der gSMC-KT vornehmen, um eventuelle Manipulationen der Karte auf dem Transportweg zu erkennen. Darin kann ihn beispielweise das Handbuch unterstützen, in welchem optische Merkmale der gSMC-KT beschrieben sind oder diese abgebildet ist. Diese im Handbuch zu beschreibenden grundlegenden Prüfungen, die ein Administrator vor Verwendung einer empfangenen gSMC-KT durchführen muss, sind hier nur allgemein und beispielhaft aufgeführt und müssen an die herstellerspezifischen Abläufe angepasst werden.

Die Reaktion auf die Unterbrechung obliegt dem Hersteller. Kommandos können sowohl mit einer Fehlermeldung beantwortet als auch intern gequeued werden.

Das SM-KT wird durch Stecken in einen entsprechenden ID-000 Slot oder mittels Adapter in einen Slot anderen Formats in das Kartenterminal eingebracht. Nach den Vorgaben des Protection Profiles [BSI-CC-PP-0032] und der Technischen Richtlinie [TR-03120] sowie dessen Anhangs ist die Karte so in das Terminal einzubringen, dass Manipulation verhindert bzw. erkannt werden können. Hierfür ist somit eine der in [TIP1-A_3059] geforderten Kontaktiereinheiten zu nutzen.

Das SM-KT enthält keine Informationen zur Bauart des Kartenterminals.

Um zu verhindern, dass das SM-KT aus einem eHealth-Kartenterminal entfernt wird und in ein anderes Kartenterminal gesteckt wird, das vom Administrator nicht für den Betrieb mit dem Konnektor vorgesehen ist, wird dem Kartenterminal eine 16 Byte große Kennung übergeben, die vom Konnektor erzeugt wurde. Diese Kennung ist ein Shared Secret zwischen Konnektor und Kartenterminal. Das Verfahren wird als Pairing bezeichnet und in Kapitel 2.5.2 beschrieben.

Eine Verschlüsselung des Shared Secrets ist nicht erforderlich.

Beispielsweise kann dies umgesetzt werden, indem das Kartenterminal bei Entnahme des SM-KT eventuell aktive TLS-Verbindungen, die die korrespondierende SMKT-Identität zum Betreiben des TLS-Kanals nutzen, aktiv beendet. Dies kann bei Entnahme des SM-KT durch folgende Maßnahmen erreicht werden:

• aktive Maßnahmen, wie direkte Erkennung der Kartenentnahme oder regelmäßigem Pollen der Karte mit anschließend gezieltem Kanalabbau bei fehlender Karte.
• passive Maßnahmen, bei denen das SM-KT nur in einem Zustand des Geräts gesteckt oder entfernt werden kann, während dem keine TLS-Verbindung unter Verwendung des SM-KT möglich ist (z. B. Zugang zum SM-KT Kartenschacht nur nach Entfernen der LAN- und Powerkabel möglich)

2.5.1 Anforderungen an die Kartenterminalidentität

2.5.1.1 Ausführung

Die SMKT-Identitäten werden durch asymmetrische Schlüssel und X.509-Zertifikate umgesetzt. Genauere kryptographische Festlegungen werden in [gemSpec_Krypt] getroffen. Festlegungen zu den zu diesen Identitäten gehörenden Zertifikaten und der verwendeten PKI sind in [gemSpec_PKI] beschrieben. Die zugehörigen Object Identifier (OID) sind im Dokument [gemSpec_OID] festgelegt. Das Zertifikat wird im DER-Format auf der Karte gespeichert.

Grundsätzlich müssen die Schlüssel der SMKT-Identitäten in einem sicheren Schlüsselspeicher hinterlegt sein. Dieser Schlüsselspeicher wird SM-KT genannt. Das SM-KT muss dabei:

1. den privaten Schlüssel sicher schützen, d. h., dass sie den privaten Schlüssel nicht herausgeben darf und dabei auch physikalischen Angriffen widerstehen muss (Tamper Resistance),
2. für den privaten Schlüssel Entschlüsselung und Verschlüsselung/Signatur für die Authentifizierung unterstützen, wobei für die Benutzung des privaten Schlüssels eine Benutzerverifikation nicht erforderlich sein darf,
3. dem Kartenterminal einen Zufallszahlengenerator mit einer Entropie von mind. 100 Bit bieten,
4. den öffentlichen Schlüssel frei auslesen lassen.

Das SM-KT muss den Fingerprint des enthaltenen X.509-Zertifikats für die SMKT-Identitäten lesbar aufgedruckt haben oder der Fingerprint muss dem SM-KT zuordenbar auf einer gesonderten Liste mitgeliefert werden.

Das Zertifikat der SMKT-Identität auf dem SM-KT entstammt einer PKI, sodass andere Komponenten prüfen können, ob es von einer Certificate Authority (CA) ausgestellt wurde, die berechtigt ist Komponentenzertifikate für SM-KTs auszustellen. Es kann zudem überprüft werden, ob das Zertifikat die technische Rolle „Kartenterminal“ enthält. Es ist keine Aufnahme einer Online-Verbindung zu jener PKI erforderlich, die das Zertifikat herausgegeben hat.

Eine PIN-Freischaltung dieser Chipkarte darf nicht notwendig sein.

Genaue Festlegungen zur Filestruktur und den Zugriffsrechten des SM-KT werden in [gSMC-KT] getroffen.

2.5.1.2 Bedeutung für das Kartenterminal

Die TLS-Verbindung auf Seiten des Kartenterminals terminiert aber nicht im SM-KT, sondern im Terminal selbst.

2.5.1.3 Produktion und Auslieferung

Produktion, Auslieferung und Inbetriebnahme müssen aufeinander abgestimmt sein und sicherstellen, dass nur integre Kartenterminals eine gültige KT-Identität erhalten und beim Leistungserbringer bzw. bei Organisationen des Gesundheitswesens zum Einsatz kommen

2.5.2 Pairing zwischen Konnektor und eHealth-Kartenterminal

Das Pairing zwischen Konnektor und eHealth-Kartenterminal versetzt den Konnektor in die Lage, Kartenterminals als vom Administrator für den Betrieb mit dem Konnektor vorgesehen, zu erkennen. Das Pairing ermöglicht es einem Kartenterminal und einem Konnektor sich nach dem TLS-Verbindungsaufbau gegenseitig zu authentifizieren. Um zu verhindern, dass der auf dem SM-KT gespeicherte Teil der kryptographischen Identität des Kartenterminals aus einem Kartenterminal entfernt und unbefugt in einem anderen Terminal genutzt werden kann, schafft das Pairing eine logische Verbindung von Kartenterminal und SM-KT. Die Gesamtheit aus logischer Verbindung sowie kryptographischer Identität des SM-KT bildet die Kartenterminalidentität.

Alle öffentlichen Schlüssel, die in demselben Pairing-Block gespeichert sind, korrespondieren zu dem ebenfalls in diesem Pairing-Block gespeicherten Shared Secret. In TIP1-A_3046-01 werden absichtlich die "öffentlichen Schlüssel" verwendet, statt die Zertifikate, mit denen die öffentlichen Schlüssel transportiert werden. Als Konsequenz ist es einem Konnektor möglich zu einem öffentlichen Schlüssel, für den ein gültiger Pairing-Block vorliegt, beliebig viele Zertifikate zu verwenden, ohne dass dies Auswirkungen auf das bestehende Pairing hätte.

Insbesondere darf es nicht möglich sein, die Shared Secrets über externe Schnittstellen zu lesen. Die genaue Ausprägung des auslesegeschützten Speicherns des Shared Secrets im Kartenterminal hängt von der Einsatzumgebung des Kartenterminals ab. In jedem Fall darf das Shared Secret nicht auf dem SM-KT im Terminal gespeichert werden (siehe [TIP1-A_3043]).

Im Rahmen des Pairings existieren drei Abläufe:

• Initiales Pairing: dient der logischen Verbindung von Kartenterminal und SM-KT aus Sicht des Konnektors mittels Shared Secret
• Überprüfung der Pairing-Informationen: Der Konnektor prüft nach Aufbau der TLS-Verbindung als zweiten Schritt der Authentisierung, ob das Kartenterminal im Besitz des Shared Secrets ist.
• Wartungs-Pairing: Bekanntmachung eines neuen Konnektorzertifikats am Kartenterminal unter Nutzung eines bekannten Shared Secret

Diese Abläufe und die Verfahrensweise bzgl. der Pairing-Informationen bei der Außerbetriebnahme eines Kartenterminals werden im Folgenden beschrieben.

2.5.2.1 Initiales Pairing

Das initiale Pairing zwischen Konnektor und eHealth-Kartenterminal läuft in zwei Schritten ab:

1. Einbringen eines eHealth-Kartenterminals im dezentralen Netzwerk.
2. Inbetriebnahme eines eHealth-Kartenterminals an einem Konnektor.

Schritt 1: Einbringen eines eHealth-Kartenterminals im dezentralen Netzwerk:

Im ersten Schritt des Pairing-Verfahrens bringt der Administrator das eHealth-Kartenterminal in das in der dezentralen Umgebung installierte LAN ein, wobei die Konfiguration des eHealth-Kartenterminals gemäß [SICCT#6.1.1] erfolgt. Um die Verwaltung zu vereinfachen, soll der SICCT-Terminalname auch bei Nichtnutzung von DHCP bei der Inbetriebnahme des Kartenterminals gesetzt werden. Dieser wird im Dienstbeschreibungspaket übertragen und kann in der Kartenterminalverwaltung des Konnektors im Sinne eines Friendly Name verwendet werden.

Der Administrator prüft die Unversehrtheit und Authentizität des eHealth-Kartenterminals, notiert sich dessen eindeutiges Identifikationsmerkmal (z. B. die MAC-Adresse oder den SICCT-Terminalnamen; die Eindeutigkeit eines SICCT-Terminalnamens während des initialen Pairings wird durch den Konnektor sichergestellt) zusammen mit dem Fingerprint eines noch nicht zugeordneten SM-KT zur späteren Überprüfung und bringt dieses SM-KT anschließend in das eHealth-Kartenterminal ein.

Nachdem der Administrator ein oder mehrere eHealth-Kartenterminals derart im dezentralen Netz installiert hat, nimmt er jedes neu eingebrachte eHealth-Kartenterminal einzeln in Betrieb, damit der Konnektor und das eHealth-Kartenterminal sich gegenseitig als sicher erkennen und authentifizieren können.

Schritt 2: Inbetriebnahme eines eHealth-Kartenterminals an einem Konnektor.

Im zweiten Schritt findet die logische Verbindung zwischen einem Kartenterminal und SM-KT statt. Der Gesamtablauf ist im Überblick in Abbildung „Pic_KT_0007 Initiales Pairing Schritt 2“ dargestellt.

Abbildung 4: Pic_KT_0007 Initiales Pairing Schritt 2

Der Administrator wählt an der Kartenterminalverwaltung des Konnektors anhand des eindeutigen Identifikationsmerkmals des Kartenterminals (z. B. dessen SICCT-Terminalnamen oder MAC-Adresse) ein eHealth-Kartenterminal aus, welches mit dem Konnektor gepairt werden soll.

Daraufhin baut der Konnektor eine TLS-Verbindung (siehe Kapitel 3.11) zum ausgewählten eHealth-Kartenterminal auf. Während dieses Verbindungsaufbaus erhält der Konnektor das X.509-Zertifikat des SM-KT (C.SMKT.AUT). Ist das Zertifikat ein gültiges SMKT-Komponentenzertifikat, zeigt der Konnektor dem Administrator den Fingerprint des SMKT-Komponentenzertifikats an, andernfalls bricht der Konnektor den Vorgang mit einer entsprechenden Fehlermeldung ab. Der Administrator überprüft, ob der vom Konnektor angezeigte Fingerprint mit dem in Schritt 1 für das zu pairende eHealth-Kartenterminal notierten SM-KT Fingerprint übereinstimmt. Stimmen beide Fingerprints überein, bestätigt der Administrator dies dem Konnektor und startet dadurch den Austausch eines Shared Secrets zwischen Konnektor und eHealth-Kartenterminal.

Der Konnektor generiert eine 16-Byte große Zufallszahl (eHealth-Kartenterminal-Kennung bzw. auch als Shared Secret (ShS.KT.AUT) bezeichnet) und sendet die Kennung zusammen mit einer Display-Meldung (die Display-Meldung wird im Konnektor festgelegt) mit Hilfe des Pairing-Befehls EHEALTH TERMINAL AUTHENTICATE (siehe Kapitel 3.7.2) über die TLS-Verbindung an das Kartenterminal. Das Kartenterminal zeigt die Display-Meldung an und wartet auf eine Bestätigung mittels Druck auf die Bestätigungs-Taste am PIN Pad. Wird die Bestätigungs-Taste nicht innerhalb einer herstellerspezifischen Zeitspanne, die maximal 10 Minuten betragen darf, gedrückt oder wird der Abbruch-Button gedrückt, so bricht das Kartenterminal den Vorgang mit einer entsprechenden Fehlermeldung ab. Die Überprüfung des Kartenterminals vor Abschluss des Pairings durch den Administrator dient dazu, die Integrität und Authentizität des eHealth-Kartenterminals zum Zeitpunkt der Inbetriebnahme sicherzustellen.

Nachdem der Administrator mittels Tastendruck die Integrität und Authentizität des Kartenterminals bestätigt hat, speichert es den öffentlichen Schlüssel des Konnektorzertifikats in einem neuen Pairing-Block. Schlägt die Prüfung fehl oder verfügt das Kartenterminal über keinen freien Pairing-Block, bricht das Kartenterminal den Vorgang ab und zeigt eine entsprechende Fehlermeldung am Display.

Zum Abschluss des Prozesses sendet das Kartenterminal die mittels des SM-KT erstellte Signatur des Shared Secrets als Antwort des EHEALTH TERMINAL AUTHENTICATE-Kommandos an den Konnektor. Der Konnektor prüft die Antwort. Kann er die Signatur erfolgreich prüfen, speichert der Konnektor das Shared Secret zusammen mit dem erhaltenen Kartenterminalzertifikat und dem eindeutigen Identifikationsmerkmal des Kartenterminals. Die Inbetriebnahme ist damit abgeschlossen.

2.5.2.2 Überprüfung der Pairing-Information durch einen Konnektor

Im Betrieb stellt der Konnektor über zwei Mechanismen sicher, dass ein eHealth-Kartenterminal ordnungsgemäß mit ihm gepairt wurde. Erstens, indem eine gegenseitige Authentisierung, zum Aufbau einer TLS-Verbindung erforderlich ist und zweitens, indem er die Pairing-Information in Form des Shared Secrets und des zugehörigen Zertifikats, welches beim TLS-Verbindungsaufbau verwendet wurde, prüft.

Diese Überprüfung eines eHealth-Kartenterminals durch einen Konnektor kann jederzeit nach dem TLS-Verbindungsaufbau zwischen Kartenterminal und Konnektor durch den Konnektor initiiert werden. Dafür schickt der Konnektor das EHEALTH-Kommando TERMINAL AUTHENTICATE (s. Kap. 3.7.2) an das Kartenterminal. Mit dem Kommando wird an das Terminal ein mindestens 16 Byte großes/r Zufallsdatum/-wert übertragen. Das Kartenterminal hängt an das Zufallsdatum das korrespondierende Shared Secret aus den Pairing-Informationen, und errechnet dann von dem kompletten Array den SHA-256-Hash-Wert. Diesen Hash-Wert schickt das Kartenterminal als Response zurück an den Konnektor.

Da der Konnektor ebenfalls das Shared Secret kennt, kann auch er den Hash-Wert errechnen. Das Kartenterminal hat nur dann die Überprüfung durch den Konnektor bestanden, wenn beide Hash-Werte, der vom Kartenterminal geschickte und der vom Konnektor errechnete, identisch sind.

2.5.2.3 Pairing-Informationen bei Außerbetriebnahme

2.5.2.4 Wartungs-Pairing

Eine Ausnahme, die zum Austausch des Konnektors z. B. zu Wartungszwecken oder zur Umsetzung eines Hot-Standby vorgesehen ist, stellt das im Folgenden beschriebene Verfahren dar. Um zu verhindern, dass bei Ausfall eines Konnektors alle Kartenterminals erneut eingesammelt (im Gegensatz zum initialen Pairing muss der Administrator beim Wartungs-Pairing nicht sicherstellen, dass sich alle Kartenterminals in seiner organisatorischen Hoheit befinden) und erneut dem initialen Pairing-Prozess zugeführt werden müssen, kann man eine Sicherungskopie der Pairing-Geheimnisse in den neuen Konnektor einspielen und mit deren Hilfe automatisiert ein neuerliches Pairing mit derselben Pairing-Information durchführen. Der Mechanismus zum Übertragen von Pairing-Informationen zwischen zwei Konnektoren ist in [gemSpec_Kon] beschrieben.

Der Gesamtablauf des Wartungs-Pairings ist im folgenden Sequenzdiagramm informativ dargestellt. Die zugehörigen Kommandos und technischen Abläufe im Kartenterminal sind im Kapitel 3.7.2 definiert.

Abbildung 5: Pic_KT_0008 Wartungs-Pairing

Das Bekanntmachen eines neuen Konnektors unter Verwendung bereits bestehender Pairing-Information läuft in zwei Phasen ab. Nach dem TLS-Verbindungsaufbau ruft der Konnektor in der ersten Phase vom Kartenterminal mittels des EHEALTH TERMINAL AUTENTICATE mit P2=03 Kommandos eine Challenge (eine vom Kartenterminal generierte Zufallszahl) ab. Der Konnektor bildet aus der Challenge und dem Shared Secret den SHA256-Hash-Wert. Diesen Hash-Wert sendet der Konnektor in der zweiten Phase mittels des EHEALTH TERMINAL AUTENTICATE mit P2=04 Kommandos als Response auf die Challenge. Das Kartenterminal bildet für jeden genutzten Pairing-Block ebenfalls den Hash-Wert aus Challenge und jeweiligem Shared Secret und vergleicht alle generierten Hash-Werte mit der Response des Konnektors. Falls das Kartenterminal die Response erfolgreich validieren und eindeutig einem Pairing-Block zuordnen kann, trägt das Kartenterminal den öffentlichen Schlüssel in den korrespondierenden Pairing-Block ein. Falls kein Platz für einen weiteren öffentlichen Schlüssel im korrespondierenden Pairing-Block vorhanden ist, überschreibt das Kartenterminal den ältesten öffentlichen Schlüssel des Pairing-Blocks.

Um eine logische Verbindung zwischen der Challenge und der Response am Kartenterminal herzustellen, nimmt das Kartenterminal im Kommando EHEALTH TERMINAL AUTHENTICATE mit P2=03 den Zustand „EHEALTH EXPECT CHALLENGE RESPONSE“ ein (siehe Kapitel 3.7.2.2). Eine Response kann vom Kartenterminal nur in diesem Zustand validiert werden. Ist das Kartenterminal nicht in diesem Zustand, wenn es eine Response auf eine Challenge erhält, schlägt der Befehl automatisch fehl. Sobald das Kartenterminal einen anderen Befehl als EHEALTH TERMINAL AUTHENTICATE mit P2=04 empfängt bzw. während der Validierung, verliert es den Zustand und löscht dabei auch die generierte Challenge.

3 Spezielle technische Anforderungen

3.1 Abgeleitete mechanische Anforderungen

Die nachfolgenden Kapitel beschreiben mechanische und elektromechanische Anforderungen für die Teilgebiete Kartentypen, Kontaktiereinheiten und Bauformen.

3.1.1 Kartentypen

Der Heilberufsausweis (HBA), die Gesundheitskarte (eGK) und die Krankenversichertenkarte (KVK) verlangen kontaktbehaftete Schnittstellen mit Kartenkontaktiereinheiten der Größe ID-1 (mit den Maßen 85,6mm x 54,0mm) entsprechend der Norm [7810].

Die Security Module Card (SMC) ist eine kontaktbehaftete Karte im Format ID-1 oder ID-000 (Plug-In-Karte) nach CEN ENV 1375-1 [CEN ENV]. Die Spezifikation der eingesetzten Secure Module Cards erfolgt in [gSMC-KT].

Die Lage und die Zuordnung der Kontakte ergibt sich aus [7816-2].

Tabelle 3: Tab_KT_005 Karten-Kompatibilität

Hinweis: Bei der KVK handelt es sich um eine Speicherkarte. Zum Einlesen der Daten von einer KVK ist [SICCT#5.5.8.1] relevant.

3.1.2 Kontaktiereinheiten

Generell sind alle Kontaktierungstypen zulässig, sofern die generellen mechanischen Anforderungen der folgenden Abschnitte eingehalten werden.

Allgemein gilt für das eHealth-Kartenterminal:

3.1.2.1 ID-1 Kartenkontaktierungen

Hier können als Hilfsmittel z. B. Büroklammern angesehen werden.

Es würde z. B. eine durch Drücken eines, im Gehäuse versenkten und nur durch z. B. eine Büroklammer erreichbaren Knopfes ausgelöste Notentnahme diese Anforderung erfüllen.

Darüber hinaus werden Mechanismen empfohlen, um eine Notentnahme im Normalbetrieb eines Terminals zu unterbinden.

3.1.2.2 ID-000-Kartenkontaktierungen

Sofern native ID-000-Kontaktierungen vorhanden sind, gilt Anforderung [TIP1-A_3249] und es ist kein Card-In-Kontakt erforderlich.

3.1.3 Bauformen

Die Bauform mit einem einzelnen ID-1-Slot eignet sich nur, wenn entweder die eGK oder der HBA gesteckt wird. Es sind aber auch Anwendungen geplant, welche die gleichzeitige Anwesenheit von HBA und eGK erforderlich machen. Dazu sind zwei ID-1-Steckplätze empfohlen.

Durch die gesicherte Aufnahme wird die Möglichkeit der Erkennung von Manipulationen der Karte gegeben. Die Art der Sicherung ist herstellerspezifisch.

3.2 Abgeleitete elektrische Anforderungen

Details zu den Anforderungen sind der SICCT-Spezifikation zu entnehmen.

3.2.1 Elektrische Anforderungen für kontaktbehaftete Karten

Die Anforderungen in der SICCT-Spezifikation ergeben sich aus Teilaspekten der [7816-3] und der EMV 2004 [EMV_41]. Das eHealth-Kartenterminal bedient in erster Linie ISO/IEC kompatible Chipkarten und daher ist der [7816-3] Standard maßgeblich.

Zur Vermeidung von Ausfällen und Blockaden in der Applikation sind beim Einsatz von EMV-Terminals ISO-Ergänzungen vorzunehmen, die möglicherweise eine Umschaltung gemäß SICCT-Spezifikation erforderlich machen. In einem solchen Fall ist der ISO-Betriebsmodus als Voreinstellung vorzusehen.

3.2.2 Reset-Verhalten und ATR-Bearbeitung

Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren, kann eine Nichterfüllung der Anforderung akzeptiert werden.

3.3 Transport von Zeichen

Die Kartenkommunikation und das Reset-Verhalten sind gemäß SICCT und [7816-3] und [7816-10] umzusetzen.

3.4 Chipkartenprotokolle

Die Protokolle sind nach den Vorgaben der jeweiligen internationalen Normen und der SICCT-Spezifikation zu implementieren. Es müssen im Rahmen der Chipkartenkommunikation alle Protokollfehler spezifikationskonform behandelt werden.

Das Erkennen und Verhindern von Deadlocks während der Kartenkommunikation ist im hohen Maße von der herstellerspezifischen Implementierung der Firmware abhängig. Von einem Deadlock ist beispielsweise auszugehen, wenn Kommando-Sequenzen, die nur im Block ausgeführt werden dürfen (z. B. im Zusammenhang mit einer Autorisierung), von Kommandos auf einem anderen logischen Kanal unterbrochen werden und die begonnene Sequenz nicht abgeschlossen werden kann.

Kontaktlose Chipkarten und Protokolle

Die Unterstützung von kontaktlosen Karten wird in Kapitel 6 beschrieben.

3.5 Isolation von Verbindungen zum Kartenterminal

3.6 Gleichzeitige Verbindungen zum Kartenterminal

Hosts können hierbei ein Konnektor und Konfigurationsprogramme der Terminal-Hersteller sein. Es darf nicht möglich sein, gleichzeitig Verbindungen zu mehr als einem Konnektor zu unterhalten (siehe [TIP1-A_3067]).

Grundsätzlich gelten die Bestimmungen für die gleichläufige Abarbeitung gemäß SICCT-Spezifikation [SICCT], Abschnitt 5.5.4 und 6.1.4.3.

Dies ist notwendig, um für LAN-Verbindungen zum Konnektor den vertrauenswürdigen Modus zu erhalten, da der lokale Anschluss als unsicher angesehen wird.

Hinweis: Als "Lokale Schnittstellen" im Sinne von TIP1-A_3072, TIP1-A_3073 und TIP1-A_3074 gelten nicht-netzwerkbasierte Schnittstellen zu ansteuernden Hosts, etwa USB-Anschlüsse, Bluetooth, Infrarot.

3.7 Kartenterminalkommandos

Alle eHealth-Kartenterminals müssen aus Gründen der Interoperabilität über den gleichen Kommandosatz zur Ansteuerung verfügen.

Details sind der SICCT-Spezifikation [SICCT] Kapitel 5 zu entnehmen. Es gelten die nachstehenden Abänderungen und Ergänzungen.

3.7.1 Verbindlichkeit des SICCT-Kommandos CONTROL COMMAND

Ein eHealth-Konnektor (oder ein anderes Client-System) darf nicht voraussetzen, dass an ein Terminal übermittelte Kommandos abgebrochen werden können. Da der Erfolg oder Misserfolg eines Abbruchs rein vom Zeitpunkt des Empfangs und der Verarbeitung des Abbruchkommandos abhängig ist, kann auch ein konsistenter Wegfall der Funktionalität akzeptiert werden.

3.7.2 Command EHEALTH TERMINAL AUTHENTICATE

Das Kommando EHEALTH TERMINAL AUTHENTICATE dient dem Pairing von Konnektor und Kartenterminal. Mit Hilfe dieses Kommandos

1. übergibt der Konnektor dem Kartenterminal das Shared Secret im Zuge des Pairing-Verfahrens
2. prüft der Konnektor, ob das Kartenterminal das mit dem Konnektor ausgehandelte Shared Secret kennt, welches zu dem im Kartenterminal steckenden SM-KT gehört.
3. kann ein Konnektor, der bereits über ein am Kartenterminal eingetragenes Pairing-Geheimnis verfügt, sein Konnektorzertifikat am Kartenterminal bekannt machen und sich dadurch mit dem KT pairen.

3.7.2.1 Funktion

Das Kommando hat drei Ausprägungen:    

1. CREATE (P2=’01’): Das Pairing des Kartenterminals erfolgt zu einem neuen Konnektor. Dies ist der Vorgang, der ausgeführt wird, wenn der betroffene Konnektor nicht über ein am KT hinterlegtes Shared Secret verfügt (z. B. beim initialen Pairing oder falls die Pairing-Information am Konnektor verloren gegangen ist).
2. VALIDATE (P2=’02’): Der Konnektor prüft mittels Shared Secret, ob das Pairing zu dem Kartenterminal ordnungsgemäß erfolgt ist.
3. ADD (Schritt1: P2=’03’, dann Schritt2 P2=’04’): Das Pairing des Kartenterminals erfolgt zu einem neuen Konnektor. Im Gegensatz zu CREATE ist dies der Vorgang, der ausgeführt wird, wenn der betroffene Konnektor bereits über ein am KT hinterlegtes Shared Secret verfügt (z. B. bei Austausch desjenigen Konnektors, bei dem eine Sicherungskopie der Pairing-Geheimnisse verfügbar ist). Damit der Konnektor nachweisen kann, dass er über das korrekte Shared Secret verfügt, wird ein Challenge-Response-Verfahren verwendet. Hierzu wird der Befehl in zwei Phasen aufgeteilt. In der ersten Phase (P=’03’) erbittet der Konnektor eine Challenge vom Kartenterminal und in der zweiten Phase (P=’04’) antwortet der Konnektor mit der Response. Wird die Antwort vom Kartenterminal erfolgreich validiert, nimmt das Kartenterminal den Konnektor als bekannten Konnektor auf. Diese Kommandoausprägung erlaubt ein automatisiertes Pairing und ist zu Wartungszwecken vorgesehen.

Details zu den Kommandoausprägungen sind der folgenden Kommandobeschreibung zu entnehmen.

Der Ablauf bei der Durchführung der „Kommandosequenz EHEALTH TERMINAL AUTHENTICATE CREATE ‘P2=01’ (SEQ_KT_0001-01)“ ist im folgenden Aktivitätsdiagramm dargestellt.

Abbildung 6: Pic_KT_0009 EHEALTH AUTHTENTICATE CREATE

Hinweis: Falls als SM-KT eine Smartcard vom Typ gSMC-KT eingesetzt wird, dann bedeuten die Ausführungen in Schritt 8 von TIP1-A_3125-03, dass der body der Response-APDU des EHEALTH TERMINAL AUTHENTICATE Kommandos identisch ist zum body der Antwort-APDU auf das PSO Compute Digital Signature Kommandos an die gSMC-KT, welches zur Berechnung der Signatur verwendet wurde.

Der Ablauf bei der Durchführung der EHEALTH TERMINAL AUTHENTICATE VALIDATE Kommandosequenz SEQ_KT_0002 ist im folgenden Aktivitätsdiagramm zusammenfassend dargestellt.

Abbildung 7: Pic_KT_0010 EHEALTH AUTHTENTICATE VALIDATE

Tabelle 5: Kommandosequenz EHEALTH TERMINAL AUTHENTICATE VALIDATE ‘P2=02’ (SEQ_KT_0002)

Falls das Kommando mit P2=’03’ oder P2=’04’ (ADD) ausgeführt wird so läuft die Verarbeitung des Kommandos im Kartenterminal in 2 Phasen ab (siehe Kapitel 2.5.2.4). In der ersten Phase fordert der Konnektor vom Kartenterminal eine Challenge ab, um in der zweiten Phase die Kenntnis des Shared Secrets nachweisen zu können.

Der Ablauf bei der Durchführung der EHEALTH TERMINAL AUTHENTICATE ADD Phase 1 Kommandosequenz aus Tabelle 6 „SEQ_KT_0003“ ist im folgenden Aktivitätsdiagramm zusammenfassend dargestellt.

Abbildung 8: Pic_KT_0011 EHEALTH AUTHENTICATE - ADD Phase 1

Tabelle 5: Kommandosequenz EHEALTH TERMINAL AUTHENTICATE ADD Phase 1 ‘P2=03’ (SEQ_KT_0003)

Der Ablauf bei der Durchführung der EHEALTH TERMINAL AUTHENTICATE ADD Phase 2 Kommandosequenz SEQ_KT_0004 ist im folgenden Aktivitätsdiagramm zusammenfassend dargestellt.

Abbildung 9: Pic_KT_0012 EHEALTH AUTHENTICATE - ADD Phase 2

Tabelle 6: Kommandosequenz EHEALTH TERMINAL AUTHENTICATE ADD Phase 2 ‘P2=04’ (SEQ_KT_0004)

3.7.2.2 Der Zustand EHEALTH EXPECT CHALLENGE RESPONSE

Dieser Zustand dient dazu, einen unmittelbaren Zusammenhang zwischen dem Kommando EHEALTH TERMINAL AUTHENTICATE mit (P2=’03’) und EHEALTH TERMINAL AUTHENTICATE mit (P2=’04’) herzustellen und ist in Abbildung „Pic_KT_0013 Zustandsdiagramm EHEALTH EXPECT CHALLENGE RESPONSE“ dargestellt.

Abbildung 10: Pic_KT_0013 Zustandsdiagramm EHEALTH EXPECT CHALLENGE RESPONSE

3.7.2.3 Anwendungsbedingungen

3.7.2.4 Command Structure

Tabelle 7: Command Definition EHEALTH TERMINAL AUTHENTICATE (CMD_KT_0001)

3.7.2.5 Response Structure

Tabelle 8: EHEALTH AUTHENTICATE Response Structure Definition (CMD_KT_0002)

3.7.2.6 Status-Codes SW1-SW2

Tabelle 9: EHEALTH AUTHENTICATE Status Code Definition (CMD_KT_0003)

3.7.2.7 Shared Secret Data Object

Das Shared Secret Data Object enthält das vom Konnektor während des Pairing-Vorgangs generierte Shared Secret.

Tabelle 10: Shared Secret Data Object Definition (DO_KT_0003)

3.7.2.8 Shared Secret Challenge Data Object

Das Shared Secret Challenge Data Object enthält die vom Konnektor zur Überprüfung der Pairing-Information des Kartenterminals gesendete Challenge.

Tabelle 11: Shared Secret Challenge Data Object Definition (DO_KT_0004)

3.7.2.9 Shared Secret Response Data Object

Das Shared Secret Response Data Object enthält die vom Konnektor zur Überprüfung der Pairing-Information des Konnektors gesendete Response.

Tabelle 12: Shared Secret Response Data Object Definition (DO_KT_0005)

3.7.3 Ergänzung der Commands SICCT OUTPUT und SICCT INPUT

3.7.4 Ergänzung der Commands SICCT REQUEST ICC und SICCT EJECT ICC

3.7.5 Ergänzung des Command SICCT PERFORM VERIFICATION

Hinweis: Nc gibt die Anzahl Oktette im (optionalen) Datenfeld einer Kommando-APDU (hier SICCT PERFORM VERIFICATION) an, vergleiche [gemSpec_COS#11.5.5].

Hinweis: Für die kryptographische Sicherung einer Kommando APDU sind folgende Use Cases relevant:

1. PSO Encipher gemäß [gemSpec_COS#(N091.446)] für die Verschlüsselung der PIN und
2. PSO Verify Cryptographic Checksum gemäß [gemSpec_COS#(Nß87.228)] für die MAC-Berechnung.

3.7.6 Ergänzung des Command SICCT MODIFY VERIFICATION DATA

Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren und bei denen die Umstellung vom eHealth-BCS-Spezifikationsstand auf den eHealth-Spezifikationsstand per Firmware Upgrade (Firmware Update) erfolgt, kann eine Nichterfüllung der Anforderung [TIP1-A_6483] akzeptiert werden.

3.7.7 Änderungen des Card Terminal Manufacturer Data Objects

Tabelle 13: Discretionary Data Data Object Definition (DO_KT_0001)

Tabelle 14: Discretionary Data Data Object Type Definition (DO_KT_0002)

Die für eine konkrete EHEALTH-Schnittstellenversion des Kartenterminals gültige Versionsnummer (VER) ist dem Produkttypsteckbrief zu entnehmen (siehe auch Kapitel 2.3.12.2). Die Versionsnummern werden nach den in [gemSpec_OM#2.2] spezifizierten Vorgaben vergeben.

3.7.8 Ergänzung zu Service Discovery/Announcement

Tabelle 15: Sicherheitsprotokolle (DO_KT_0006)

3.7.9 Ergänzung des Command SICCT INIT CT SESSION

3.7.10 Verbindlichkeit des SICCT-Kommandos SICCT SELECT CT MODE

Das eHealth-Kartenterminal antwortet bei nicht unterstützten Kommandos (dazu zählen neben SICCT SELECT CT MODE auch die optionalen Kommandos SICCT COMFORT ENROLL und SICCT COMFORT AUTH bei Nichtumsetzung) gemäß [SICCT#5.4.2] mit 6D00 (Wrong instruction). Einzige Ausnahme bildet das Kommando SICCT CONTROL, auf das gemäß [TIP1-A_3264] mit 6200 geantwortet werden muss.

3.7.11 Einschränkung des Command-To-Perform Data Objects

3.7.12 Verbindlichkeit der SICCT-Ereignisnachricht KEEP ALIVE

3.8 Verhalten bei der PIN-Eingabe

Dieses ergänzt die Funktionsbeschreibung von Abschnitt 5.19 der SICCT-Spezifikation [SICCT] wie auch andere Spezifikationsabschnitte, die eine PIN-Eingabe erfordern.

Abbildung 11: Pic_KT_0014 Verhalten bei PIN-Eingabe mit bekannter Länge

Die folgenden Anforderungen gelten insbesondere für solche Kartenterminals, deren Display lediglich die minimalen Anforderungen von zwei Zeilen zu je 16 Zeichen erfüllen.

Das bedeutet, wenn auch nur noch sechs Zeichen für eine Anzeige der PIN-Eingabe (16 Zeichen Maximalbreite – 10 Zeichen PIN-Prompt=6 Zeichen) zur Verfügung stehen, darf allein dadurch die maximale Länge einer PIN durch das Kartenterminal nicht auf diese sechs Zeichen begrenzt werden.

Als Lösung wäre denkbar, dass bereits angezeigte Ersatzzeichen nach links verschoben werden, auch wenn dadurch der PIN-Prompt sukzessive überschrieben wird. Es ist auch vorstellbar, dass im Display die jeweilige Stelle der PIN-Eingabe in Form einer Nummer angegeben wird. Die genauen Details zur Umsetzung sind herstellerspezifisch.

3.9 Festlegungen zur Sicherung der Firmware Updates

Konkret wird nur eine Sicherung der Authentizität und Integrität gewährleistet. Dies ist durch eine Signatur durch den Terminalhersteller zu gewährleisten. Die Signatur durch den Kartenterminalhersteller dient dazu, sicherzustellen, dass bei der Übermittlung und den anschließenden Prüf- und Verarbeitungsschritten innerhalb der prüfenden und zulassenden Stelle keine beabsichtigten oder unbeabsichtigten Verfälschungen der Firmware („Bitdreher“) auftreten können. Das Format der Firmware (d. h. des Binärfiles) bleibt herstellerspezifisch.

Ein Wechsel des Schlüsselmaterials ist damit über die Einbeziehung einer neuen Schlüsselgeneration in die Firmware möglich. Auch ist es zulässig (und sogar empfohlen), dass eine Firmware nur die öffentlichen Schlüssel einer übergeordneten CA enthält und das konkrete Zertifikat zur Signatur in das bzw. an das Signatur-Envelope ein- bzw. angefügt wird.

3.10 Aufbau der SICCT-spezifischen TLS-Verbindungen

Der Ablauf des TLS-Verbindungsaufbaus zwischen einem TLS-Client und dem eHealth-Kartenterminal ist im folgenden Diagramm „Pic_KT_0016 TLS-Verbindungsaufbau“ informativ dargestellt.

Abbildung 12: Pic_KT_0016 TLS-Verbindungsaufbau

Für den Aufbau einer TLS-Verbindung im Rahmen eines TLS-Handshakes existieren in den einschlägigen Industrie- und Internetstandards (etwa [RFC-5246#7.3]) eine Reihe von Optionen. Für einen interoperablen Betrieb zwischen Client (etwa Konnektor) und Server (hier eHealth-Kartenterminal) werden Festlegungen zum TLS-Handshake in [gemSpec_Krypt] getroffen.

Dort und weiter unten in diesem Dokument wird unter anderem festgelegt, dass ein eHealth-Kartenterminal nur dann fachlich nutzbar ist, wenn sich der TLS Client authentisiert. Dazu ist es erforderlich, dass der TLS Client im Rahmen einer Client Ceritifcate Nachricht (siehe [RFC5246#7.4.6]) ein End-Entity Zertifikat präsentiert. Es ist möglich, dass eine Client Certificate Nachricht eine komplette Zertifikatskette enthält. Es wird gefordert, dass ein darin enthaltenes End-Entity Zertifikat mit einem CA-Zertifikat geprüft wird, welches bereits vor dem TLS-Handshake im eHealth-Kartenterminal gespeichert war.

Die folgenden Kapitel legen Einzelheiten zur Zertifikatsprüfung fest.

3.10.1 Speicherung von CA-Zertifikaten

Hinweis: Die Dienste bzw. CA-Zertifikate in der TSL lassen über die TSL-Extension zuordnen: Im Extensioneintrag wird zu jedem CA-Zertifikat angegeben, welche Typen von Zertifikaten es ausstellen darf (siehe [gemSpec_TSL#7.3.2.1]). Ein Filtern nach relevanten TSPs ist damit einfach möglich, gemäß A_22889 aber nicht erforderlich.

Hinweis: Wenn zeitgleich mehrere verschiedene Vertrauensräume in der Firmware des eHealth-Kartenterminals hinterlegt sind, so ist die Anzahl entsprechend zu vervielfachen.

Hinweis: Die Sicherheit des TSP-Update-Mechanismus ist im Rahmen der Common Criteria Evaluierung nachzuweisen. Die Details zur Umsetzung sind herstellerspezifisch.

3.10.2 Prüfen eines Client-Zertifikates

Komponentenzertifikate für Konnektoren werden durch Trusted Service Provider für Komponentenzertifikate (TSP) ausgestellt. Jedes Komponentenzertifikat eines Konnektors lässt sich auf ein CA-Zertifikat innerhalb der Trust-Service Status List (TSL) zurückführen. Es ist dabei durch organisatorische Prozesse im Rahmen der Baureihenzulassung sichergestellt, dass nur betriebszugelassene Geräte mit solchen Komponentenzertifikaten für Konnektoren ausgestattet werden.

Zur Prüfung eines Client-Zertifikates wird der Use Case [gemSpec_PKI#TUC_PKI_018] verwendet, wobei einige Schritte an die Gegebenheiten des eHealth-Kartenterminals angepasst werden.

[gemSpec_PKI#TUC_PKI_018] definiert folgende Eingangsdaten für die "Zertifikatsprüfung in der TI":

1. Zertifikat
2. Referenzzeitpunkt
3. PolicyList
4. intendedKeyUsage
5. intendedExtendedKeyUsage
6. OCSP-Graceperiod (Default: 10 Minuten)
7. Offline-Modus aus der Menge {ja, nein}
8. Beigefügte OCSP-Response (optional)
9. Timeout-Parameter (Default: 10 Sekunden)
10. TOLERATE_OCSP_FAILURE aus der Menge {true, false}
11. Prüfmodus aus der Menge {OCSP, CRL}

[gemSpec_PKI#TUC_PKI_018] beschreibt folgenden Standardablauf für die "Zertifikatsprüfung in der TI":

1. [gemSpec_PKI#TUC_PKI_002], Gültigkeit prüfen
2. Prüfen der keyUsage aus dem Zertifikat gegen die Eingangsdaten "intendedKeyUsage" und "intendedExtendedKeyUsage"
3. [gemSpec_PKI#TUC_PKI_003], passendes CA-Zertifikat suchen
4. [gemSpec_PKI#TUC_PKI_004], mathematische Prüfung der Zertifikatssignatur
5. ServiceStatus des CA-Zertifikates prüfen
6. Falls "Offline-Modus == ja" ist, dann Schritt 7 überspringen
7. (nur relevant für "Prüfmodus == OCSP" und "Offline-Modus == nein"),
   [gemSpec_PKI#TUC_PKI_006], OCSP-Prüfung des Zertifikates
8. [gemSpec_PKI#TUC_PKI_009], Rollenermittlung
9. [gemSpec_PKI#TUC_PKI_007], Prüfung Zertifikatstyp

Hinweis zu Prüfschritt 1: Möglicherweise verfügt ein eHealth-Kartenterminal nicht über zuverlässige Informationen zu Datum und Uhrzeit. Dann ist es gemäß den unten stehenden Ausführungen zulässig, Zertifikate auch dann zu akzeptieren, wenn deren Gültigkeit abgelaufen ist.

Hinweis zu Prüfschritt 3: Gemäß A_22888 werden CA-Zertifikate ausschließlich im Speicher des eHealth-Kartenterminals gesucht und niemals einer Client Certificate Nachricht entnommen.

Hinweis zu Prüfschritt 6: Möglicherweise verfügt ein eHealth-Kartenterminal über keine Verbindung zu einem OCSP-Responder. Dann ist es gemäß den unten stehenden Ausführungen zulässig im Prüfmodus "CRL" gegen eine leere Certificate Revocation List zu prüfen. In diesem Fall akzeptiert das eHealth-Kartenterminal auch gesperrte oder revozierte End-Entity Zertifikate.

Definition: Ein Zertifikat wird im Folgenden als "perfekt" bezeichnet, wenn es alle Prüfungen gemäß [gemSpec_PKI#TUC_PKI_018] mit folgenden Eingangsdaten besteht:

1. Zertifikat = End-Entity Zertifikat aus der Client Certificate Nachricht
2. Referenzzeitpunkt = Systemzeit = aktuelles Datum und aktuelle Uhrzeit
3. PolicyList = {sak-aut} = {1.2.276.0.76.4.113}
4. intendedKeyusage = {digitalSignature}, (siehe RFC5280#4.2.1.3)
5. intendedExtendedKeyUsage = {tlsClientAuthentication} = {1.3.6.1.5.5.7.3.2}
6. OCSP-Graceperiod = 10 Minuten oder kleiner
7. Offline-Modus = nein
8. Beigefügte OCSP-Response = (leer)
9. Timeout-Parameter = 10 Sekunden oder kleiner
10. TOLERATE_OCSP_FAILURE = false
11. Prüfmodus = OCSP

Die gematik erlaubt es einem eHealth-Kartenterminal im Rahmen des Use Cases [gemSpec_PKI#TUC-PKI_018] jedes Zertifikat als gültig anzusehen, falls das eHealth-Kartenterminal über keine zuverlässige Information bezüglich Datum und Uhrzeit verfügt.

Definition: Ein Zertifikat wird im Folgenden als "fuzzyValidity" bezeichnet, wenn es alle Prüfungen gemäß [gemSpec_PKI#TUC_PKI_018] besteht, ohne dass ein zuverlässiger Referenzzeitpunkt vorliegt (weshalb hier eine Unterscheidung zwischen "perfekt" und "ungültig" nicht möglich ist). Das entspricht folgenden Eingangsdaten:

1. Zertifikat = End-Entity Zertifikat aus der Client Certificate Nachricht
2. Referenzzeitpunkt = beliebig aus dem Intervall [notBefore, notAfter]
3. PolicyList = {sak-aut} = {1.2.276.0.76.4.113}
4. intendedKeyusage = {digitalSignature}, (siehe RFC5280#4.2.1.3)
5. intendedExtendedKeyUsage = {tlsClientAuthentication} = {1.3.6.1.5.5.7.3.2}
6. OCSP-Graceperiod = 10 Minuten oder kleiner
7. Offline-Modus = nein
8. Beigefügte OCSP-Response = (leer)
9. Timeout-Parameter = 10 Sekunden oder kleiner
10. TOLERATE_OCSP_FAILURE = false
11. Prüfmodus = OCSP

Die gematik erlaubt es einem eHealth-Kartenterminal im Rahmen des Use Cases [gemSpec_PKI#TUC-PKI_018] den Prüfmodus "CRL" zu wählen und dabei offline gegen eine leere Certificate Revocation List zu prüfen, falls es weder über eine Verbindung zu einem OCSP-Responder noch über eine Certification Revocation List verfügt.

Definition: Ein Zertifikat wird im Folgenden als "fuzzyRevocation" bezeichnet, wenn es alle Prüfungen gemäß [gemSpec_PKI#TUC_PKI_018] im Offline-Modus gegen eine leere Certificate Revocation List besteht (weshalb hier eine Unterscheidung zwischen "perfekt" und "gesperrt oder revoziert" nicht möglich ist). Dies entspricht folgenden Eingangsdaten:

1. Zertifikat = End-Entity Zertifikat aus der Client Certificate Nachricht
2. Referenzzeitpunkt = Systemzeit = aktuelles Datum und aktuelle Uhrzeit
3. PolicyList = {sak-aut} = {1.2.276.0.76.4.113}
4. intendedKeyusage = {digitalSignature}, (siehe RFC5280#4.2.1.3)
5. intendedExtendedKeyUsage = {tlsClientAuthentication} = {1.3.6.1.5.5.7.3.2}
6. OCSP-Graceperiod = beliebig, da irrelevant
7. Offline-Modus = ja
8. Beigefügte OCSP-Response = (leer)
9. Timeout-Parameter = beliebig, da irrelevant
10. TOLERATE_OCSP_FAILURE = true
11. Prüfmodus = CRL mit leerer Certificate Revocation List

Die gematik erlaubt es einem eHealth-Kartenterminal im Rahmen des Use Cases [gemSpec_PKI#TUC-PKI_018]:

1. den Prüfmodus "CRL" zu wählen, dabei auch gegen eine leere Certificate Revocation List zu prüfen, falls es über keine Verbindung zu einem OCSP-Responder verfügt, und
2. jedes Zertifikat als gültig anzusehen, falls das eHealth-Kartenterminal über keine zuverlässige Information bezüglich Datum und Uhrzeit verfügt.

Definition: Ein Zertifikat wird im Folgenden als "fuzzyValidity + fuzzyRevocation" bezeichnet, wenn es alle Prüfungen gemäß [gemSpec_PKI#TUC_PKI_018] im Offline-Modus gegen eine leere Certificate Revocation List besteht, ohne das ein zuverlässiger Referenzzeitpunkt vorliegt (weshalb hier eine Unterscheidung zwischen "perfekt" einerseits und andererseits "ungültig" oder "gesperrt oder revoziert" nicht möglich ist). Dies entspricht folgenden Eingangsdaten:

1. Zertifikat = End-Entity Zertifikat aus der Client Certificate Nachricht
2. Referenzzeitpunkt = beliebig aus dem Intervall [notBefore, notAfter]
3. PolicyList = {sak-aut} = {1.2.276.0.76.4.113}
4. intendedKeyusage = {digitalSignature}, (siehe RFC5280#4.2.1.3)
5. intendedExtendedKeyUsage = {tlsClientAuthentication} = {1.3.6.1.5.5.7.3.2}
6. OCSP-Graceperiod = beliebig, da irrelevant
7. Offline-Modus = ja
8. Beigefügte OCSP-Response = (leer)
9. Timeout-Parameter = beliebig, da irrelevant
10. TOLERATE_OCSP_FAILURE = true
11. Prüfmodus = CRL mit leerer Certificate Revocation List

Definition: Ein Zertifikat wird im Folgenden als "aus Sicht des eHealth-Kartenterminals perfekt" bezeichnet, wenn es "perfekt" oder im Sinne von A_22882 "fuzzyValidity" oder im Sinne von A_22883 "fuzzyRevocation" ist (einschließendes ODER).

3.10.3 TLS-Handshake

Hinweis: Bei leerer Zertifikatsliste ist das eHealth-Kartenterminal nach dem TLS-Handshake im Zustand State_InvalidClient, siehe A_22456.

Hinweis: Enthält die Zertifikatsliste ein "aus Sicht des eHealth-Kartenterminals perfektes" End-Entity Zertifikat (vergleiche A_22887), dann liegt nach dem TLS-Handshake (je nach Pairing-Information) einer der Zustände State_ClientWithoutPairing oder State_ClientWithPairing vor, siehe A_22456.

Hinweis: Das eHealth-Kartenterminal präsentiert im Rahmen des TLS-Handshake sein SMKT-Zertifikat (C.SMKT.AUT). Wenn die Zertifikatsprüfung für das SMKT-Zertifikat im Konnektor scheitert, dann bricht der Konnektor die Verbindung ab.

Hinweis: Falls die Zertifikatsprüfung für das SMKT-Zertifikat im Konnektor erfolgreich verläuft, dann wird dieser prüfen, ob für das SMKT-Zertifikat Pairing-Informationen vorliegen. Liegen keine Pairing-Informationen im Konnektor vor, dann führt der Konnektor nur die in CMD_KT_005 gelisteten Kommandos aus. Mit diesem eingeschränkten Funktionsumfang lassen sich Pairing-Informationen etablieren. Liegen Pairing-Informationen im Konnektor vor, dann prüft er diese gemäß 2.5.2.2.

3.11 Zustandsautomat für den SICCT spezifischen TLS-Kanal

Hinweis: Der im Folgenden spezifizierte Status-Code SW1SW2 = '6982' = SecurityStatusNotSatisfied wird weder in [SICCT] noch in diesem Dokument als Antwort auf ein SICCT- oder EHEALTH-Kommando verwendet.

Tabelle 16: CMD_KT_0004, Liste ausführbarer Kommandos im Zustand State_InvalidClient

Tabelle 17: CMD_KT_005, Liste ausführbarer Kommandos im Zustand State_ClientWithoutPairing

Hinweis: Der Status-Code SW1SW2 = '6900' = CommandNotAllowed wird in [gemSpec_COS] nicht verwendet.

3.12 Abbau der SICCT-spezifischen TLS-Verbindung

3.13 Auslieferungszustand

Dies gilt ergänzend zu den Festlegungen zum Auslieferungszustand in Abschnitt 6.1.5 der SICCT-Spezifikation („Auslieferungszustand“).

Die sich hieraus ergebenden Konfigurationsschritte eines Kartenterminals sind im nachfolgenden Diagramm „Pic_KT_0015 Inbetriebnahme“ dargestellt.

Abbildung 13: Pic_KT_0015 Inbetriebnahme

Nach dem Setzen des Direktkennwortes ist eine Einbringung des Kartenterminals in das in der dezentralen Umgebung installierte Netz möglich.

Für den Fall, dass das Kartenterminal die Netzwerkskonfigurationsdaten nicht dynamisch erhält, muss eine statische Konfiguration über eine Managementschnittstelle erfolgen.

Im nächsten Schritt ist das initiale Pairing durchzuführen (siehe Kapitel 2.5.2.1).

Danach ist das Kartenterminal in der Lage, seinen Service mit einem Konnektor auszuführen.

In jedem Zustand ist die Konfiguration des Kartenterminals änderbar sowie ein Werksreset durchführbar (siehe Abschnitt 3.14).

3.14 Werksreset

Siehe Abbildung „Pic_KT_0015 Inbetriebnahme“. Die Firmware selbst ist in diesem Zusammenhang nicht zu betrachten.

Die minimale Unterbrechung ist wie folgt definiert: Ein eHealth-Kartenterminal muss dem Leistungserbringer bzw. dem Mitarbeiter der Organisation des Gesundheitswesens zur Verfügung stehen. Eine Konfiguration eines eHealth-Kartenterminals ist jedoch nicht vermeidbar.

Wenn der Werksreset-Mechanismus ohne vorherige Authentisierung implementiert und aktiviert ist, kann der Anwender im Einzelfall wählen, welchen der Werksreset-Mechanismen (autorisiert oder unautorisiert) er ausführen möchte.

Die Umsetzung des Werksreset-Mechanismus ist herstellerspezifisch.

4 ESD Festigkeit

Dieses Kapitel beinhaltet Anforderungen an die ESD Festigkeit von eHealth-Kartenterminals. Die Anforderungen lehnen sich an [EMVCo_ESD] an.

4.1 Prüfkörper, ESD-Pistolen Adapter und Extender

Dieses Kapitel behandelt informativ die relevanten Prüfkörper, ESD-Pistolen Adapter und Extender aus [EMVCo_ESD#4].

Das Dokument [EMVCo_ESD] beschreibt fünf Prüfkörper:

1.  Type I Probe, vergleiche [EMVCo_ESD#4.1]: Diese Probe simuliert Entladungen gemäß "Human Body Model" (HBM). Diese Probe ist für die folgenden Anforderungen relevant.
2. Type II Probe, vergleiche [EMVCo_ESD#4.2]: Diese Probe simuliert Entladungen gemäß "Charged Device Model" (CDM) für Karten mit metallisierter Oberfläche. Diese Probe ist für die folgenden Anforderungen irrelevant, da metallisierte Oberflächen für Karten der TI ausgeschlossen sind.
3. Type III Probe, vergleiche [EMVCo_ESD#4.3]: Diese Probe ist für die folgenden Anforderungen irrelevant, da sie Kartenlesegeräte mit Magnetstreifen betrifft.
4. Type IV Probe, vergleiche [EMVCo_ESD#4.4]: Diese Probe simuliert Entladungen gemäß CDM einer Dual Interface Karte. Diese Probe ist für die folgenden Anforderungen relevant.
5. Type V Probe, vergleiche [EMVCo_ESD#4.5]: Diese Probe simuliert Entladungen gemäß HBM einer Dual Interface Karte über kapazitive Kopplung. Diese Probe ist für die folgenden Anforderungen irrelevant, da korrespondierende Prüfungen für die Zulassung von eHealth-Kartenterminals nicht verwendet werden.

Das Dokument [EMVCo_ESD] beschreibt zwei ESD Pistolen Adapter, die beide für die folgenden Anforderungen relevant sind:

1. CAT A Adapter, vergleiche [EMVCo_ESD#4.6 und Anhang A] für HBM Entladungen,
2. CAT B Adapter, vergleiche [EMVCo_ESD#4.6 und Anhang A] für CDM Entladungen.

Das Dokument [EMVCo_ESD] beschreibt vier Extender. Keiner der Extender ist für die hier beschriebenen Anforderungen relevant.

Das Kapitel [EMVCo_ESD#4.12] beschreibt eine Testkonfiguration. Die Testkonfiguration besteht aus den ESD-Pistolen Adaptern, den Prüfkörpern und Extendern. Falls die physikalischen Abmessungen des Prüflings einen Einsatz der Prüfkörper oder Extender verhindern, dann wandelt das Prüflabor, basierend auf seiner Erfahrung, Prüfkörper und Extender passend so ab, dass ein äquivalentes Messergebnis erreicht wird. Derartige Anpassungen werden dokumentiert.

4.2 eHealth-Kartenterminal als Prüfling

Dieses Kapitel korrespondiert mit [EMVCo_ESD#5]. Es beschreibt für ein eHealth-Kartenterminal gemäß [gemSpec_KT] informativ die Testumgebung und den Testablauf.

Gemäß [gemSpec_KT#TIP1-A_3075] werden eHealth-Kartenterminals über eine (Ethernet) Netzwerkschnittstelle angesteuert. Eine Clientsoftware tauscht über diese (Ethernet) Netzwerkschnittstelle Nachrichten mit Smartcards in den Slots aus.

Gemäß [gemSpec_KT#TIP1-A_3058] besitzt ein eHealth-Kartenterminal mindestens einen ID-1-Slot. Jeder dieser ID-1-Slots wird auf seine ESD-Festigkeit hin untersucht, weil davon auszugehen ist, dass Karten in diesen Slots während des Betriebs des eHealth-Kartenterminals eingesteckt werden. Einer dieser ID-1-Slots wird als Prüfslot bezeichnet, an welchem aktuell die ESD-Festigkeit untersucht wird. Der Prüfslot wird mit einer eGK bestückt. Alle anderen ID-1-Slots werden mit HBA bestückt.

Gemäß [gemSpec_KT#TIP1-A_3059] besitzt ein eHealth-Kartenterminal mindestens zwei Slots für ID-000-Module. Kein Slot für ID-000-Module wird auf ESD-Festigkeit untersucht, weil davon ausgegangen wird, dass Slots für ID-000-Module nicht während des Betriebs des eHealth-Kartenterminals mit Smartcards bestückt werden. Alle Slots für ID-000-Module werden mit gSMC-KT bestückt.

Die Testdurchführung gliedert sich in die folgenden Phasen:

1.  Testvorbereitung:
2. 1. Der Prüfling wird mit Testkarten bestückt.
   2. Die Clientsoftware baut eine TLS Verbindung zum Prüfling auf.
   3. Die Clientsoftware baut zu jeder vorhandenen HBA-Testkarte einen Trusted Channel auf (elcSessionkeys4SM) und verifiziert die PIN.CH, wobei der Wert der PIN.CH nicht über das PIN-Pad des Terminals eingegeben wird, sondern von der Clientsoftware bereitgestellt wird.
   4. Die Clientsoftware baut zu jeder gSMC-KT-Testkarte einen Trusted Channel auf und liest darüber die Seriennummer der Karte aus.
   5. Die Clientsoftware verifiziert für die eGK-Testkarte im Prüfslot die PIN.CH, wobei der Wert der PIN.CH über das PIN-PAD des Kartenterminals eingegeben wird.
3. Testdurchführung.
4. Testnachbereitung:
5. 1. Die eGK wird in den Prüfslot eingesteckt.
   2. Die Clientsoftware verifiziert für die eGK im Prüfslot die PIN.CH, wobei der Wert der PIN.CH über das PIN-PAD des Kartenterminals eingegeben wird.
   3. Die Clientsoftware liest mittels des unter Punkt 1)d) etablierten Trusted Channels nochmals die Seriennummern aller gSMC-KT aus.
   4. Die Clientsoftware liest mittels des unter Punkt 1)c) etablierten Trusted Channels für alle vorhandenen HBA den Sicherheitszustand der PIN.CH aus.

Hinweis: Die vorgenannte Clientsoftware sowie sämtliche Testkarten werden von der gematik gestellt.

4.3 Nicht akzeptables Verhalten

Die folgende Liste enthält Beispiele für nicht akzeptables Verhalten, welches während einer ESD-Entladung möglicherweise auftritt. Die Liste ist nicht abschließend. Prüflabore werden ersucht ihre Erfahrung zu nutzen um zu erkennen, dass ein Prüfling durch die ESD-Entladung inakzeptabel gestört wurde:

1. Wechsel der Displayanzeige, außer dies ist zu erwarten, weil das Einstecken oder Entfernen einer Karte erkannt wurde.
2. Löschen der Displayanzeige.
3. Unerwartete akustische Signale.
4. Funktional gestörte Tastatur.
5. Fehler bei Karteninteraktionen in der Testnachbereitung.

4.4 Akzeptables Verhalten

Die folgende Liste enthält Beispiele für akzeptables Verhalten. Die Liste ist nicht abschließend. Prüflabore werden ersucht ihre Erfahrung zu nutzen um weiteres Verhalten zu erkennen, welches für die Bewertung der ESD-Festigkeit nicht relevant ist:

1. Flackern der Displayanzeige, ohne dass dabei der Inhalt des Displays verändert wird.
2. Kleinere Geräusche, hervorgerufen etwas durch Funkentladungen.

4.5 Testfälle

4.5.1 Testvor- und Nachbereitung eHealth-Kartenterminal

4.5.1.1 Testvorbereitung eHealth-Kartenterminal

4.5.1.2 Testnachbereitung eHealth-Kartenterminal

4.5.2 Testdurchführung analog zu ESD.001.00

Dieser Testfall korrespondiert mit [EMVCo_ESD#ESD.001.00].

Ziel: Dieser Test simuliert eine Entladung gemäß HBM durch einen aufgeladenen Karteninhaber. Während des Test wird der Prüfkörper in den Prüfslot eingesteckt. Es ist beabsichtigt eine Entladung mit dem ersten leitfähigen Gegenstand im Prüfslot herbeizuführen.

Konfiguration: ESD-Pistolen Adapter CAT A.g und Type I.g Probe.

Prüfung bestanden: Der Test gemäß ESD.001.00.g gilt als bestanden, wenn

1. alle Testvorbereitungen erfolgreich verliefen und
2. der Prüfling während der Test kein inakzeptables Verhalten zeigte und
3. alle Testnachbereitungen erfolgreich verliefen.

4.5.3 Testdurchführung angelehnt an ESD.004.00

Dieser Testfall korrespondiert mit [EMVCo_ESD#ESD.004.00].

Ziel: Dieser Test simuliert eine Entladung gemäß CDM durch ein geladenes Modul mit Antenne. Im Test gemäß [EMVCo_ESD#ESD.004.00] verbindet ein Extender die Kontakte des Prüflings über einen Auswahlschalter mit einer Entladespitze des Extenders. Diese Art des Tests führt zu direkten Entladungen auf der Kontaktiereinheit, was eine hohe Belastung für den Prüfling darstellte. Zudem wären konstruktive Maßnahmen zur Reduzierung der Belastung durch Entladen beim Karteneinschub wirkungslos. Deshalb wird hier bewusst von der Testkonfiguration und der Testdurchführung gemäß [EMVCo_ESD#ESD.004.00] abgewichen und eine Konfiguration gewählt, die als praxisnäher empfunden wird.

Konfiguration: ESD-Pistolen Adapter CAT B.g, Type IV.g Probe.

Prüfung bestanden: Der Test gemäß ESD.004.00.g gilt als bestanden, wenn

1. alle Testvorbereitungen erfolgreich verliefen und
2. der Prüfling während der Test kein inakzeptables Verhalten zeigte und
3. alle Testnachbereitungen erfolgreich verliefen.

4.6 Allgemeine Anforderungen zur ESD-Festigkeit

5 Kontaktlose Schnittstelle

Dieses Kapitel behandelt die Schnittstelle eines eHealth-Kartenterminals für die kontaktlose Kommunikation mit Smartcards gemäß der Normenreihe [14443].

Die Normenreihe [14443] gehört zum Stand der Technik für die kontaktlose Kommunikation mit Smartcards. Zudem wird dieser Standard auch für die NFC-Schnittstelle von Smartphones genutzt. Für die interoperable Umsetzung wird folgender Ansatz verfolgt: neue Kartenleser der TI werden bei der Erstzulassung mit einer Schnittstelle gemäß [14443] ausgestattet. Die diesbezüglichen Vorgaben zusammen mit den entsprechenden Vorgaben in [gemSpec_COS] ermöglichen einen interoperablen Betrieb.

Gemäß den relevanten Objektsystemspezifikationen (d.h. [eGK], [HBA] und [SMC-B]) sind Smartcards der TI im kontaktlosen Fall nur dann sinnvoll nutzbar, nachdem ein vertrauenswürdiger Kanal gemäß [gemSepc_COS#(N106.545)] zwischen der Smartcard (MRTD Chip (PICC)) und einem Kartenleser (Terminal PCD) aufgebaut wurde. Dieses Dokument spezifiziert, dass der vertrauenswürdige Kanal zwischen dem eHealth-KT und den Smartcards der TI aufgebaut wurde.

Ferner spezifiziert dieses Dokument, dass ein eHealth-KT das Feature "CL" an der SICCT-Schnittstelle verbirgt. Das bedeutet: An der SICCT-Schnittstelle ist es auf funktionaler Ebene nicht relevant, ob eine mit dem eHealth-KT verbundene Smartcard kontaktbehaftet oder kontaktlos angesprochen wird. Die vorstehenden Aussagen dieses Absatzes gelten mit folgender Ausnahme: Gemäß [SICCT#Tabelle 6] werden Slots für Smartcards anhand von Functional Unit Type und Functional Unit Index unterschieden und sind damit eindeutig adressierbar. Der Functional Unit Type für kontaktbehaftete Slots hat demnach den Wert 0x00, während dieser Wert für kontaktlose Slots den Wert 0x10 hat.

Die Spezifikation der Schnittstelle eines eHealth-Kartenterminals gliedert sich in zwei Abschnitte. Der erste Abschnitt behandelt den Aufbau eines Nachrichtenkanals zwischen PCD und PICC, sowie den generischen Austausch von Nachrichten. Dies entspricht den unteren Ebenen es ISO/OSI-Referenzmodells (Transportschicht). Der zweite Abschnitt behandelt die kryptographische Absicherung der Luftschnittstelle (PACE).

5.1 eHealth-KT als PCD

Die Unterstützung einer kontaktlosen Schnittstelle für eine Kommunikation mit Karten bleibt für bereits zugelassene Hardware  ein optionales Feature. Für neu zuzulassende eHealth-Kartenterminal Hardware ist die Umsetzung dieser kontatklosen Schnittstelle dagegen verpflichtend.

5.1.1 Anforderungshaushalt PCD, analog

Definition: Als "Landefläche" (englisch "landing plane") wird der Teil eines Kartenterminals bezeichnet, auf dem ein Nutzer eine Karte platziert, damit eine erfolgreiche, kontaktlose Kommunikation möglich wird.

Hinweis: Die gematik behält sich vor im Zulassungsbescheid fehlende Feldstärkemessungen zu vermerken, falls der Prüfbericht entsprechende Aussagen enthält.

Hinweis: A_21627 lässt sich gemäß [10373-6#Table O.9] testen.

Hinweis: In A_21629-* wurden die in [14443-1#Annex A] zusätzlich enthaltenen "Class 4", "Class 5" und "Class 6" absichtlich nicht genannt. A_21629-* lässt sich gemäß [10373-6#7.1.1] testen.

Hinweis: Für den Test der vorstehenden Anforderung sind [10373-6#7.1.4, 7.1.5, 7.1.6] relevant.

Hinweis: A_21633 konkretisiert [14443-2#8.1.1, 8.2.1, 9.1.1. 9.2.1]. [10373-6#7.1.4, 7.1.5, 7.1.6] enthalten zugehörige Testverfahren.

Hinweis: Für den Test von A_21635 ist [10373-6#7.2.2] relevant.

Hinweis: Für den Test von A_21637 ist [10373-6#7.1.8] relevant.

5.1.2 Anforderungshaushalt PCD, digital

Hinweis: Für den Test von A_21638 ist [10373-6#H.4.2] relevant.

Hinweis: Für den Test von A_21641 ist [10373-6#H.5] relevant.

Hinweis: Für den Test von A_21691 sind [10373-6#H.4.3, H.4.4, H.4.5, H.6] relevant.

5.1.2.1 Anforderungen Typ A PCD

Hinweis: Für den Test Von A_21643 sind [10373-6#H.1.7, H.2.1, H.2.2, H.2.3, H.2.4, H.2.5, H.2.7, H.2.8, H.2.9, H.2.10] relevant.

5.1.2.2 Anforderungen Typ B PCD

Hinweis: Für den Test von A_21653 sind [10373-6#H.3.2, H.3.3, H.3.4, H.3.5, H.3.6] relevant.

Hinweis: Zur Bedeutung der Werte:
a. '00' zeigt an, dass es allen Applikationsfamilien erlaubt ist zu antworten.
b. '50' zeigt an, dass es nur medizinischen Applikationsfamilien erlaubt ist zu antworten.

Hinweis: A_21673 ist analog zu EMVCo.

Hinweis: [14443-4#6] beinhaltet nur eine Referenz auf [14443-3].

5.2 eHealth-KT als PACE-Endpunkt

5.2.1 Technischer Hintergrund

Allgemein lässt sich ein Nachrichtenaustausch zwischen zwei Partnern (etwa Alice und Bob) wie in Abbildung KteA_cbc darstellen: Die Partner tauschen über einen Kanal Nachrichten aus. Falls es sich beispielsweise bei Bob um eine Smartcard handelt, dann nehmen alle Komponenten, welche mit einer Smartcard kommunizieren die Rolle von Alice ein: Konnektor, Kartenterminal, VSD-Update-Dienst etc.

Abbildung 14 : KteA_cbc, Kommunikation Klartext

Falls eine kryptographisch gesicherte Kommunikation erforderlich ist, dann ändert sich für Alice nichts, wenn die kryptographische Sicherung von einer Zusatzkomponente ("Krypto" in Abbildung KteA_9a7) übernommen wird. Der vertrauenswürdige Kanal (Trusted Channel) hat dann zwei Endpunkte: Ein Endpunkt ist in der Komponente "Krypto", der andere Endpunkt liegt in einer Unterkomponente von "Bob" (Smartcard).

Abbildung 15 : KteA_9a7, Kommunikation abgesichert

Dieser Abschnitt beschreibt die Absicherung der kontaktlosen Schnittstelle mittels PACE durch das eHealth-KT. Die Motivation für eine kryptographische Absicherung der kontaktlosen Schnittstelle wird hier nur kurz skizziert: Wegen der verwendeten Feldstärken und den physikalischen Möglichkeiten von PCD und PICC funktioniert die kontaktlose Schnittstelle zwar nur dann, wenn der Abstand von PCD und PICC nicht mehr als wenige Zentimeter beträgt. Allerdings ist es möglich, mit aufwendiger Antennentechnik die Kommunikation auch aus größerem Abstand abzuhören. Deshalb wird die Kommunikation mit der PICC kryptographisch abgesichert. Dem Stand der Technik entsprechend wird hierzu PACE eingesetzt, um einen Trusted Channel zu etablieren. Die Komponente "Krypto" wird dazu irgendwo zwischen PCD und der Stelle platziert, welche Kommandos an die Smartcard schickt. Dieses Dokumentes spezifiziert, dass die Komponente "Krypto" in Abbildung KteA_9a7 Teil des eHealth-KT wird. Dadurch wird es für alle anderen Komponenten, welche Smartcards über so ein eHealth-KT nutzen (etwa Konnektor, VSD-Update etc.), unerheblich, ob eine Smartcard kontaktbehaftet oder kontaktlos angesprochen wird.

5.2.2 PACE im eHealth-KT

Im Rahmen der kontaktbehafteten Kommunikation mit einer Smartcard in einem eHealth-KT wird typischerweise im Klartext (also ohne "Trusted Channel") zwischen dem Nutzer (Konnektor etc.) und einer Smartcard kommuniziert. Für gewisse Anwendungsfälle (etwa VSD-Update, Stapelsignatur etc.) ist eine gesicherte Kommunikation erforderlich. Es ist denkbar, dass im Rahmen einer Kartensession mehrfach zwischen "Klartext" einerseits und "Trusted Channel" andererseits gewechselt wird. Zudem ist es möglich, dass in einem logischen Kanal im "Klartext" und in einem anderen logischen Kanal per "Trusted Channel" kommuniziert wird.

Beispielsweise sei hier angenommen, dass ein Konnektor den Basiskanal eines HBA zur Freischaltung von eGKs verwendet und dabei kontaktbehaftet stets im "Klartext" mit dem HBA kommuniziere. Der logische Kanal 1 werde vom Konnektor im Wechsel für Einzelsignaturen (kontaktbehaftet stets "Klartext") oder Stapelsignaturen (stets "Trusted Channel") verwendet. Es ist beabsichtigt, dass diese Anwendungsfälle bei kontaktloser Kommunikation mit dem HBA auch dann funktionieren, wenn die CAN am eHealth-KT nur ein einziges Mal eingegeben wird. 

In diesem Absatz wird der Ablauf der Use Cases aus dem vorherigen Absatzes beschrieben. Hier allerdings für die kontaktlose Kommunikation zwischen dem eHealth-KT und dem HBA. Dazu merkt sich das eHealth-KT die CAN für die Dauer einer Kartensession. Wie zuvor im kontaktbehafteten Fall werde der Basiskanal wieder zur Freischaltung von eGKs verwendet. Das eHealth-KT baut dazu im Basiskanal des HBA mittels PACE einen "Trusted Channel" auf. Anschließend ist es möglich über diesen "Trusted Channel" im Basiskanal eGKs freizuschalten (nach Selektion und Freischaltung des passenden HBA-Schlüssels). Für Einzelsignaturen im logischen Kanal 1 ist ebenfalls ein mittels PACE aufgebauter "Trusted Channel" erforderlich. Für Stapelsignaturen im logischen Kanal 1 wird zunächst der mittels PACE aufgebaute "Trusted Channel" geschlossen und der für Stapelsignaturen erforderliche "Trusted Channel" (mit entsprechenden Mitteln) aufgebaut. Für weitere Einzelsignaturen im logischen Kanal 1 wird ein anderweitig vorhandener "Trusted Channel" geschlossen und ein neuer "Trusted Channel" mittels PACE geöffnet.

5.2.3 Zustandsautomat

5.2.3.1 Übersicht

Im weiteren Verlauf wird ein Zustandsautomat für die Komponente "Krypto" beschrieben. Diese Beschreibung ist unabhängig davon, wo die Komponente "Krypto" angesiedelt ist. Die Beschreibung ist so aufgebaut, dass der Zustandsautomat nur für genau einen Kartenslot mit einer PICC gilt. Falls die Komponente "Krypto" für mehr als eine Antenne zuständig ist, dann gibt es mehrere gleichartige Zustandsautomaten. Genauso gibt es mehrere gleichartige Zustandsautomaten, wenn die Komponente "Krypto" für nur eine Antenne zuständig ist, diese Antenne aber in der Lage ist, mehrere PICC zu bedienen.

Abbildung 16 : KteA_2bc, PICC Handling

Abbildung KteA_2bc beschreibt den Lebenszyklus des Zustandsautomaten sowie die Aktionen, wenn eine PICC in das Betriebsvolumen der Antenne eingeführt oder aus diesem entfernt wird.

Der Zustandsautomat startet, wenn die Komponente "Krypto" aktiviert wird (etwa, weil ein eHealth-KT bootet etc.). Es finden Initialisierungen statt (etwa Liste der verfügbaren PICC auf "leer" setzen, den Wert der CAN auf "unbekannt" setzen, alle logische Kanäle als "geschlossen" kennzeichnen, etc.). Anschließend wartet der Zustandsautomat auf eines von mehreren Ereignissen:

1. Eine PICC erscheint im Betriebsvolumen ohne das zuvor eine CAN eingegeben wurde. In diesem Fall wird die CAN erst später eingegeben. Dann ist es denkbar, dass Karte und / oder Landezone so positioniert sind, dass die CAN auf dem Kartenkörper nicht mehr lesbar ist.
2. Eine CAN wurde am eHealth-KT eingegeben und der der Komponente "Krypto" übergeben, bevor eine PICC im Betriebsvolumen erscheint. Dieser Fall ist relevant, wenn der Karteninhaber die Karte während des Eingabevorgangs in der Hand hält und dabei den Wert der CAN vom Kartenkörper abliest.

Egal in welchem Zustand sich der Automat befindet; er endet, wenn die Komponente "Krypto" deaktiviert wird (eHealth-KT wird heruntergefahren). Diese Transition wird hier nur der Vollständigkeit halber erwähnt.

In jedem beliebigen Zustand ist es möglich, dass der Zustandsautomat das Signal "deactivate PICC" empfängt. Damit ist eine gezielte, von einem Nutzer angestoßene Deaktivierung gemeint. Die zugehörige PICC wird dann deaktiviert, eine möglicherweise gespeicherte CAN wird gelöscht, alle logischen Kanäle werden als geschlossen markiert und die erfolgreiche Deaktivierung der PICC wird an den Nutzer zurückgemeldet. Das Signal "deactivate PICC" für kontaktlose Kartenslots ist äquivalent zu einem "card eject"-Befehl für Kartenslots mit Auswurfmechanismus.

In jedem beliebigen Zustand ist es möglich, dass dem Zustandsautomaten gemeldet wird, dass die PICC entfernt wurde: "PICC removed". Eine möglicherweise gespeicherte CAN wird gelöscht, alle logischen Kanäle werden als geschlossen markiert und die erfolgreiche Entfernung der PICC wird dem Nutzer zurückgemeldet: "PICC removed".

Der Unterschied zwischen den Eingangssignalen "deactivate PICC" einerseits und "PICC removed" andererseits ist wie folgt: Unter der Annahme, die Komponente "Krypto" (und damit auch dieser Zustandsautomat) ist Teil eines eHealth-KTs, wird das Eingangssignal "deactivate PICC" vom eHealth-KT über die SICCT-Schnittstelle (etwa vom Konnektor) empfangen. Das Eingangssignal "PICC removed" wird von einem Sensor ausgelöst, wenn das eHealth-KT erkennt, dass die PICC aus dem Betriebsvolumen entfernt wurde.

5.2.3.2 Zustand "wait"

Abbildung 17 : KteA_1b7, CAN bevor PICC

Das Zustandsdiagramm in Abbildung KteA_1b7 betrachtet den Fall, dass die Komponente "Krpyto" im Zustand "wait" eine CAN empfängt (beispielsweise vom PIN-Pad des eHealth-KT). Die CAN wird zur weiteren Verwendung gespeichert. Zudem wird ein Timer gestartet und der Zustandsautomat geht in den Zustand "wait for PICC" über.

Falls der zuvor gestartete Timer abläuft bevor eine PICC im Betriebsvolumen erscheint, dann wird die gespeicherte CAN gelöscht und der Zustandsautomat geht in den Zustand "wait" über.

5.2.3.3 Signal "PICC present"

Abbildung 18 : KteA_c45, Aktiviere PICC

Das Zustandsdiagramm in Abbildung KteA_c45, beschreibt den Übergang von den Zuständen "wait" und "wait for PICC", wenn das Signal "PICC present" empfangen wird. Es ist möglich, dass so ein Signal "PICC present" dann erzeugt wird, wenn ein Sensor eines eHealth-KTs erkennt, dass sich eine PICC im Betriebsvolumen der kontaktlosen Schnittstelle befindet:

1. Ein möglicherweise laufender Timer (siehe Abbildung KteA_1b7) wird gestoppt.
2. init channel (0): Der Zustandsautomat initialisiert (falls erforderlich) die im Zustandsautomaten möglicherweise gespeicherten Informationen zum Basiskanal der PICC (beispielsweise "keine Secure Messaging Parameter" etc.).
3. activate PICC: Der Zustandsautomat aktiviert die PICC.
4. read EF.CardAccess: Der Zustandsautomat liest die Datei EF.CardAccess der PICC aus und entnimmt den ausgelesenen Daten die PACE Parameter.
5. Falls es dabei zu irgendeinem Fehler kommt, dann handelt es sich bei der PICC um keine von der gematik spezifizierte Karte. Das weitere Verhalten des Zustandsautomaten ist dann herstellerspezifisch. Mögliche Optionen sind:
6. 1. Displayanzeige "unbekannte Karte, Karte wechseln".
   2. Nachricht über SICCT-Schnittstelle "Karte unbrauchbar".
   3. Das Terminal erkennt einen Kartentyp, der zwar nicht den gematik Spezifikationen entspricht, aber vom Terminal unterstützt wird (beispielsweise "neuer Personalausweis (nPA)") und arbeitet mit dieser Karte.
7. Falls die PACE-Parameter fehlerfrei ermittelt wurden, werden sie gespeichert.
8. Das Terminal meldet über das SICCT-Protokoll, dass eine Karte verfügbar ist: "PICC available".
9. Der Zustandsautomat geht in den Zustand "wait for CommandApdu" über.

5.2.3.4 Zustand "wait for CommandApdu"

Abbildung 19 : KteA_046, Bearbeiten einer Kommandonachricht

Dies ist bei verfügbarer PICC der Hauptzustand. Im Zustand "wait for CommandApdu" wird auf eine Kommandonachricht gewartet, die dann an die PICC weitergeleitet wird. Die PICC wird diese in der Regel mit einer korrespondierenden Antwortnachricht beantworten, die dann an den Sender der Kommandonachricht weitergeleitet wird. Der in Abbildung KteA_046 gezeigte Ablauf wird im Folgenden erläutert.

Im einfachsten Fall handelt es sich bei der empfangenen Kommandonachricht "CommandApduA" um ein Mitglied einer speziellen Klasse von Kommandonachrichten, die der Zustandsautomat unverändert an die PICC weiterleitet. In Abbildung KteA_046 korrespondiert dieser Fall mit dem geraden Durchlauf, also ohne Abweichung des Flusspfades, von oben nach unten:

1. Es wird eine Kommandonachricht "CommandApduA" empfangen.
2. Die Kommandonachricht "CommndApduA" gehört zu einer speziellen Klasse von Nachrichten (siehe Kapitel "Spezielle Klasse von Kommandonachrichten").
3. Falls Secure Messaging zuvor aktiv war, dann wird es deaktiviert.
4. Die Kommandonachricht "CommandApduA" wird unverändert als "CommandApduB" an die PICC gesendet.
5. Der Zustandsautomat wartet auf die korrespondierende Antwortnachricht.
6. Die Antwortnachricht "ResponseApduB" wird unverändert als "ResponseApduA" an den Sender von "CommandApduA" als zu dieser Kommandonachricht korrespondierende Antwort zurückgesendet.
7. Der Zustandsautomat wartet auf die nächste Kommandonachricht.

In der Regel wird die Kommandonachricht "CommandApduA" nicht zur speziellen Klasse gehören, also nicht als "special" eingestuft werden. Dann ist der Ablauf wie folgt:

1. Es wird eine Kommandonachricht "CommandApduA" empfangen.
2. Die Kommandonachricht "CommandApduA" gehört nicht zur Klasse der speziellen Nachrichten.
3. Falls Secure Messaging (via PACE) noch nicht aktiv ist, dann wird es aktiviert (siehe dazu Kapitel "Initialisiere PACE").
4. Die Kommandonachricht "CommandApduA" wird mittels der Regeln aus [gemSpec_COS#13.2] nach "CommandApduB" transformiert (per Secure Messaging gesichert).
5. Die Kommandonachricht "CommandApduB" wird an die PICC gesendet.
6. Der Zustandsautomat wartet auf die korrespondierende Antwortnachricht.
7. Die Antwortnachricht "ResponseApduB" wird, (weil Secure Messaging (via PACE) ja aktiv ist) dekodiert. Die Dekodierung ist die Umkehroperation zu [gemSpec_COS#13.3].
8. Falls "ResponseApduB" kein Datenfeld enthält oder bei der Dekodierung ein Fehler auftritt, dann wird Secure Messaging deaktiviert und "ResponseApduB" als "RepsonseApduA" zurückgemeldet.
9. Falls die Dekodierung erfolgreich verlief, dann
10. 1. werden (möglicherweise) Schritte zum Management logischer Kanäle ausgeführt (siehe Kapitel "Manage Channels") und
    2. es wird das Ergebnis der Dekodierung als "ResponseApduA" an den Sender von "CommandApduA" als zu dieser Kommandonachricht korrespondierende Antwort zurückgesendet.
11. Der Zustandsautomat wartet auf die nächste Kommandonachricht.
    

5.2.3.5 Spezielle Klasse von Kommandonachrichten

In diesem Unterkapitel werden Kommandonachrichten behandelt, die im Sinne von Abbildung KteA_046 "special" sind, so dass sie vom Zustandsautomaten nicht kryptographisch gesichert werden. Der Hintergrund für diese Sonderbehandlung ist folgender: Gemäß Abbildung KteA_9a7 ist es Alice möglich, Klartextnachrichten zu senden, die dann von einer Komponente "Krypto" kryptographisch gesichert werden. Es ist aber auch möglich, dass Alice selbst schon für eine kryptographische Sicherung sorgt (etwa im Rahmen eines VSD-Updates oder einer Stapelsignatur). Gemäß den Festlegungen in [gemSpec_COS] ist es dann der Komponente "Krypto" aus Abbildung KteA_9a7 verboten, die bereits von Alice kryptographisch gesicherten Kommandonachrichten nochmals zu sichern. Zudem legt [gemSepc_COS] für einige Kommandos oder Kommandosequenzen fest, dass ein COS diese erlaubterweise zurückweist, falls sie kryptographisch gesichert wären.

Im Einzelnen sind folgende Kommandos und Kommandosequenzen "special" im Sinne von Abbildung KteA_046 und werden deshalb vom Zustandsautomaten unverändert an die PICC weitergeleitet:

1. Alle Nachrichten, die bereits kryptographisch gesichert sind, also gemäß [gemSpec_COS] per Secure Messaging gesichert sind. Das trifft gemäß [gemSpec_COS#(N032.500] dann zu, falls im CLA-Byte:
2. 1. die Bits b7 und b6 nicht gesetzt sind und die Bits b4 und b3 gesetzt sind (d.h. Kanalnummer im Bereich [0, 3] und Secure Messaging angezeigt). Der Zustand der Bits b8, b5, b2 und b1 ist hier irrelevant.
   2. die Bits b7 und b6 gesetzt sind (d.h. Kanalnummer größer gleich 4 ist und Secure Messaging angezeigt wird). Der Zustand der Bits b8, b5, b4, b3, b2 und b1 ist hier irrelevant.
3. Symmetrische Aushandlung von Sessionkeys, siehe [gemSpec_COS#(N106.500)]: Das Kommando Mutual Authenticate, also INS='82' und Le-Feld vorhanden.
4. General Authenticate Kommando, also INS='86'.

Für folgende Kommandos wird vom Zustandsautomaten explizit nicht erwartet, dass er sie als "special" im Sinne von Abbildung KteA_046 einstuft. Mit anderen Worten: Dem Zustandsautomaten ist es erlaubt, sie als "special" einzustufen; es ist ihm aber auch erlaubt sie nicht als "special" einzustufen. Einerseits sind diese Kommandovarianten für den Zustandsautomaten nur schwer zu erkennen und andererseits sind diese Kommandovarianten für eine PICC als Empfänger und damit für den hier beschriebenen Zustandsautomaten irrelevant:

1. ungesichertes Internal Authenticate und ungesichertes External Authenticate im Rahmen von symSessionkey4TC (siehe [gemSpec_COS#(N106.500)]).
2. ungesicherte PSO-Kommandos, welche mit intern gespeicherten Sessionkey4TC arbeiten, siehe
3. 1. [gemSpec_COS#(N087.228)], PSO Compute Cryptographic Checksum,
   2. [gemSpec_COS#(N089.845)], PSO Decipher mit symmetrischen Schlüssel,
   3. [gemSpec_COS#(N091.446)], PSO Encipher mit symmetrischen Schlüssel,
   4. [gemSpec_COS#(N096.346)], PSO Verify Cryptographic Checksum.

5.2.3.6 Initialisiere PACE

Abbildung 20 : KteA_b2e, Initialisiere PACE

Der in Abbildung KteA_b2e gezeigte Ablauf ist eine Detaillierung zu Abbildung KteA_046. Der Einsprungspunkt "A" und der Endpunkt "B" in Abbildungen KteA_046 und KteA_b2e entsprechen einander. Abbildung KteA_b2e zeigt, wie Sessionkeys mittels PACE etabliert werden.

1. Falls der Zustandsautomat den Wert der CAN nicht kennt, so wird der Wert der CAN eingelesen. Beispielsweise ist es möglich, den Wert der CAN über ein PIN-Pad einzugeben oder per OCR oder QR-Code einzulesen.
2. Dann wird das PACE-Authentisierungsprotokoll durchlaufen, wie in [gemSpec_COS#15.4.2] beschrieben. Dabei nimmt der Zustandsautomat die Rolle "COSb, PCD" aus [gemSpec_COS#CosA_8da] ein.
3. Falls das PACE-Authentisierungsprotokoll nicht erfolgreich durchlaufen wird (etwa, weil der Wert der CAN falsch ist), dann wird der Wert der CAN erneut eingelesen.
4. Falls das PACE-Authentisierungsprotokoll mit einem (sonstigen) Fehler abbricht, dann wird die Kommandonachricht "CommandApduA" mit der ResponseApdu "6F00" ="NoPreciseDiagnostic"  beantwortet und der Zustandsautomat geht in den Zustand "PACE error" über. Gemäß Abbildung KteA_2bc ist es möglich den Zustand "PACE error" mittels der Signale "deactivate PICC" oder auch "PICC removed" zu verlassen.
5. Falls das PACE Authentisierungsprotokoll erfolgreich durchlaufen wird, dann
6. 1. wird der Wert der CAN zur späteren Nutzung gespeichert und
   2. werden die Informationen zum Betrieb des Trusted Channels gespeichert (Sessionkeys, SSCMac etc.).

5.2.3.7 Manage Channels

Es ist möglich, dass die empfangene und gerade bearbeitete Kommandonachricht "CommandApduA" logische Kanäle in der PICC verändert. In diesem Fall ist es erforderlich, dass analoge Aktionen auch im Zustandsautomaten erfolgen. Dazu zählen folgende Kommandos:

1. "Öffnen eines logischen Kanals" (siehe [gemSpec_COS#(N099.508)]):
   Mit diesem Kommando wird ein neuer logischer Kanal geöffnet. Im Erfolgsfall enthält die Antwortnachricht die Nummer des neu geöffneten Kanals. Im Erfolgsfall wird der Zustandsautomat für den neu in der PICC geöffneten Kanal einen Kontext anlegen, welcher angibt, ob in diesem logischen Kanal mittels PACE etabliertes Secure Messaging aktiv ist und falls ja, welches Material dort zum Einsatz kommt.
2. "Schließen eines logischen Kanals" (siehe [gemSpec_COS#(N099.514)]):
   Mit diesem Kommando wird ein logischer Kanal in der PICC geschlossen. Im Erfolgsfall wird der Zustandsautomat den Kontext des betroffenen logischen Kanals löschen.
3. "Zurücksetzen eines logischen Kanals" (siehe [gemSpec_COS#(N099.524)]):
   Mit diesem Kommando wird der Kontext eines logischen Kanals innerhalb der PICC in den Urzustand versetzt. Im Erfolgsfall wird der Zustandsautomat im PCD den Kontext dieses Kanals ebenfalls in den Urzustand versetzen.
4. "Logischer Reset der Applikationsebene" (siehe [gemSpec_COS#(N099.532)]):
   Mit diesem Kommando werden (bis auf den Basiskanal) alle logischen Kanäle der PICC geschlossen und der Basiskanal  der PICC in den Urzustand versetzt. Im Erfolgsfall wird der Zustandsautomat den Kontext des Basiskanals (mit der logischen Kanalnummer 0) in den Urzustand versetzen und alle anderen (möglicherweise) vorhandenen Kontexte zu logischen Kanälen löschen.

5.2.4 PACE Anforderungen

Hinweis: Im Prinzip fordert A_22863, dass sich das eHealth-KT bezüglich des PACE-Protokolls so verhält wie die Komponenten "Steuersoftware" und "COSb PCD" in [gemSpec_COS#CosA_8da].

5.2.5 Betriebliche Aspekte zu Deployment, Roll-Out und Interoperabilität mit den Konnektoren / Zugangs-Komponenten

Es ist wünschenswert, das Kartenterminal Feature "Option_CL" so früh wie möglich ins Feld zu bringen. Dafür ist eine Entkopplung von den Implementierungs- und Roll-Out Zyklen der Konnektor-Hersteller hilfreich.
Daher ist die Verwendung von kontaktloser Kommunikation konfigurierbar und so zu gestalten, dass "Option_CL" im Auslieferungszustand deaktiviert ist.
Für die Signalisierung der SlotID zum Konnektor ist abweichend von [SICCT] der Functional Unit (FU) Type = 0x00 und FU-Index (Anzahl kontaktbehafteter Slots + x) zu verwenden.

Hinweis: Gemäß [SICCT:2016] lassen sich mittels Direct-Coding in den Bits b4..b1 die Slotnummern '1'..'E' ansprechen, siehe beispielsweise [SICCT#5.13.3]. Die gematik erlaubt einem eHealth-Kartenterminal an der SICCT-Schnittstelle bis zu vierzehn kontaktbehafteten Slots anzuzeigen und zur Verfügung zu stellen.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Das Glossar wird als eigenständiges Dokument zur Verfügung gestellt [gemGlossar].

6.3 Tabellenverzeichnis

6.4 Abbildungsverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer entnehmen Sie bitte der aktuellsten, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

6.5.2 Weitere Dokumente