Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Spezifikation
KTR-AdV

 

   

   

Version	1.34.0
Revision	548770
Stand	26.1018.12.2018
Status	in Bearbeitung
Klassifizierung	öffentlich
Referenzierung	gemSpec_KTR-AdV

Dokumentinformationen

Änderungen zur Vorversion

Die Einarbeitungen gemäß der Änderungsliste P15.10.Der Anhang B wurde in ein extra Dokument ausgelagert. 

Dokumentenhistorie

 

Inhaltsverzeichnis

DokumentinformationenDokumentinformationen

InhaltsverzeichnisInhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

2 Systemüberblick

2.1 Einordnung des Produkttyps in die Telematikinfrastruktur

2.2 Leistungen der TI-Plattform

3 Systemkontext

3.1 Akteure und Rollen

3.2 Nachbarsysteme

3.3 Ablaufumgebung

4 Zerlegung des Produkttyps

5 Übergreifende Festlegungen

5.1 Datenschutz und Sicherheit

5.1.1 Verarbeitung personenbezogener Daten

5.1.2 Absicherung der AdV-Komponenten

5.1.3 Verbindungsaufbau und Freischaltung eGK

5.1.4 Filterung von Kartenkommandos an die eGK

5.2 Logging

5.3 Nicht-funktionale Anforderungen

6 Funktionsmerkmale

6.1 Implementation der AdV Anwendungsfälle

6.1.1 AdV-Sitzung des Versicherten

6.1.1.1 AdV-Sitzung initialisieren

6.1.1.2 AdV-Sitzung beenden

6.1.2 Übergreifende Vorbedingungen

6.1.3 Hinweistext zu Fachanwendung

6.1.4 Generische Anwendungsfälle

6.1.4.1 Anwendung auf eGK deaktivieren

6.1.4.2 Anwendung auf eGK reaktivieren

6.1.4.3 PIN-Verwaltung

6.1.4.3.1 PIN ändern

6.1.4.3.2 PIN auf eGK entsperren

6.1.4.3.3 PIN für Fachanwendung einschalten

6.1.4.3.4 PIN für Fachanwendung ausschalten

6.1.5 Verwaltung der eGK

6.1.5.1 VSD von eGK anzeigen

6.1.5.2 Zugriffsprotokoll anzeigen

6.1.5.3 Versicherten-PIN ändern

6.1.5.4 Versicherten-PIN entsperren

6.1.5.5 Datenübertragung bei Kartentausch

6.1.6 Verwaltung der NFD

6.1.6.1 NFD auf eGK verbergen

6.1.6.2 Verborgenen NFD auf eGK sichtbar machen

6.1.6.3 PIN für NFD einschalten

6.1.6.4 PIN für NFD ausschalten

6.1.7 Verwaltung des DPE

6.1.7.1 Persönliche Erklärung (DPE) von eGK anzeigen

6.1.7.2 Persönliche Erklärung (DPE) auf eGK ändern

6.1.7.3 Persönliche Erklärung (DPE) auf eGK löschen

6.1.7.4 PIN für DPE einschalten

6.1.7.5 PIN für DPE ausschalten

6.1.7.6 Persönliche Erklärung (DPE) auf eGK verbergen

6.1.7.7 Verborgene DPE auf eGK sichtbar machen

6.1.8 Verwaltung eMP/AMTS

6.1.8.1 AMTS-Vertreter-PIN ändern

6.1.8.2 AMTS-Vertreter-PIN entsperren

6.1.8.3 eMP/AMTS Datensatz verbergen

6.1.8.4 Verborgenen eMP/AMTS Datensatz sichtbar machen

6.1.8.5 PIN für AMTS einschalten

6.1.8.6 PIN für AMTS ausschalten

6.1.9 Fachanwendungsunabhängige Anwendungsfälle

6.1.9.1 Mit eGK verschlüsseln

6.1.9.2 Mit eGK entschlüsseln

6.1.9.3 Authentisierungsrequest mit eGK signieren

6.1.9.4 Zertifikat von eGK lesen

6.2 Realisierung der Leistungen der TI-Plattform

6.2.1 Transportschnittstelle für Kartenkommandos

6.2.1.1 Kartenterminals der Sicherheitsklasse 1

6.2.1.2 Kartenterminals der Sicherheitsklasse 2

6.2.1.3 Kartenterminals der Sicherheitsklasse 3

6.2.2 Schnittstelle für PIN-Operationen und Anbindung der Karten der TI

6.2.3 Schnittstelle zur Freischaltung der eGK

6.2.4 Schnittstelle zu Diensten der zentralen TI-Plattform

6.3 Schnittstelle zwischen AdV-App und AdV-Server

6.4 Identitäten der KTR-AdV

7 Informationsmodell

8 Verteilungssicht

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.5.1 Dokumente der gematik

9.5.2 Weitere Dokumente

9.6 Hinweistexte der Fachanwendungen

10 Anhang B – Leistungen der dezentralen TI-Plattform

10.1 Systemprozesse für den Zugriff auf Smartcards der TI

10.1.1 Die Realisierungsumgebung des CardProxy

10.1.1.1 ENV_TUC_CARD_SECRET_INPUT – Realisierung Eingabe PIN-Geheimnis

10.1.1.2 ENV_TUC_CARD_TO_CARD – Realisierung Card-2-Card

10.1.1.3 ENV_TUC_CARD_APDU_TRANSPORT – Realisierung APDU-Transport

10.1.2 Konfiguration und Statusinformationen

10.1.2.1 Konfiguration des CardProxy

10.1.2.2 Initialisierung CardProxy für eGK

10.1.2.3 Initialisierung CardProxy für SM-B

10.1.2.4 PL_TUC_CARD_INFORMATION – Gesammelte Statusinformationen zu einer Karte

10.1.2.5 PL_TUC_EGK_STATUS – Gültigkeit der eGK prüfen

10.1.2.6 PL_TUC_CARD_RESET – Rücksetzen einer Karte

10.1.3 Zugriff auf Smartcards der TI

10.1.3.1 PL_TUC_CARD_CHANGE_PIN – PIN Ändern

10.1.3.2 PL_TUC_CARD_ENABLE_PIN – PIN-Schutz einschalten

10.1.3.3 PL_TUC_CARD_DISABLE_PIN – PIN-Schutz abschalten

10.1.3.4 PL_TUC_CARD_UNBLOCK_PIN – PIN mit PUK entsperren

10.1.3.5 PL_TUC_CARD_VERIFY_PIN – Benutzer verifizieren

10.1.3.6 PL_TUC_CARD_ACTIVATE_APPLICATION – Anwendung aktivieren

10.1.3.7 PL_TUC_CARD_DEACTIVATE_APPLICATION – Anwendung deaktivieren

10.1.3.8 PL_TUC_CARD_GET_CHALLENGE – Auslesen einer Zufallszahl

10.1.3.9 PL_TUC_CARD_READ_FILE – Lesen von Daten aus einer SmartCard

10.1.3.10 PL_TUC_CARD_WRITE_FILE – Schreiben von Daten auf eine SmartCard

10.1.3.11 PL_TUC_CARD_UPDATE_FILE – Aktualisieren von Daten in einer transparenten Datei einer SmartCard

10.1.3.12 PL_TUC_CARD_DELETE_FILE – Löschen von Daten auf einer SmartCard

10.1.3.13 PL_TUC_CARD_ERASE_FILE – Rücksetzen des Inhalts einer transparenten Datei

10.1.3.14 PL_TUC_CARD_READ_RECORD – Lesen von Daten aus einer strukturierten Datei

10.1.3.15 PL_TUC_EGK_READ_PROTOCOL – Auslesen des Zugriffprotokolls der eGK

10.1.3.16 PL_TUC_CARD_WRITE_RECORD – Schreiben von Daten in eine strukturierte Datei

10.1.3.17 PL_TUC_CARD_APPEND_RECORD – Anfügen von Daten an eine strukturierte Datei

10.1.3.18 PL_TUC_EGK_APPEND_PROTOCOL – Zugriff auf der eGK protokollieren

10.1.3.19 PL_TUC_CARD_DELETE_RECORD – Löschen von Daten in einer strukturierten Datei

10.1.3.20 PL_TUC_CARD_ERASE_RECORD – Rücksetzen eines Datensatzes in einer strukturierten Datei

10.1.4 Transparenter Zugriff auf eine SmartCard

10.1.4.1 PL_TUC_CARD_TC_OPEN

10.1.4.2 PL_TUC_CARD_TC_SEND

10.1.4.3 PL_TUC_CARD_TC_CLOSE

10.2 Kommunikation und Vernetzung

10.2.1 PL_TUC_TLS_SECURE_CHANNEL – Kartenbasierte TLS-Verbindung

10.2.2 PL_TUC_NET_NAME_RESOLUTION

10.2.3 PL_TUC_NET_SYNC_TIME

10.3 Vertraulichkeit, Authentizität, Integrität

10.3.1 PL_TUC_SIGN_HASH_nonQES – mit Karten-Identität signieren

10.3.2 PL_TUC_HYBRID_ENCIPHER – Hybrid verschlüsseln

10.3.3 PL_TUC_HYBRID_DECIPHER – Hybrid entschlüsseln

10.3.4 PL_TUC_SIGN_DOCUMENT_nonQES – Dokument signieren

10.4 Leistungen der PKI

10.4.1 PL_TUC_PKI_VERIFY_CERTIFICATE – Prüfung eines Zertifikats der TI

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps KTR-AdV.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter einer KTR-AdV sowie Hersteller und Anbieter von Produkttypen der TI, 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 Zulassungs- oder Abnahmeverfahren 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 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 9.5).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps KTR-AdV verzeichnet.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [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 der Textmarkenzwischen Afo-ID und Textmarke angeführten Inhalte.

2 Systemüberblick

2.1 Einordnung des Produkttyps in die Telematikinfrastruktur

Für die eigenständige Verwaltung der Anwendungen des Versicherten auf der elektronischen Gesundheitskarte steht dem Versicherten in einer Umgebung im Auftrag der Kostenträger und @home die KTR-AdV zur Verfügung.

Mit dieser wird der Versicherte in die Lage versetzt, eigenständig seine persönlichen Daten auf der eGK einzusehen, seine freiwilligen Anwendungen zu verwalten, sowie administrative Anwendungsfälle der PIN-Verwaltung auszuführen. Die Abbildung ABB_ADV_300 zeigt die Einordnung des Produkttyps in die Telematikinfrastruktur.

Abbildung 1: ABB_ADV_300 – Überblick AdV in einer Umgebung im Auftrag der Kostenträger

Die KTR-AdV gliedert sich in die beiden blau dargestellten Komponenten AdV-App und AdV-Server sowie eine Komponente zur sicheren Speicherung der Kostenträgeridentitäten und des dazugehörigen kryptografischen Schlüsselmaterials (z.B. in einem HSM). Auf einem Gerät für die Benutzung durch den Versicherten wird die AdV-App zur Anbindung der eGK bereitgestellt. Diese AdV-App baut über eine produkttyp-interne Schnittstelle eine Verbindung zum zugehörigen AdV-Server auf, der im Auftrag einer Krankenkasse in einem Rechenzentrum betrieben wird.

Zur Freischaltung der eGK des Versicherten für die Umgebung der Kostenträger wird ein CV-Zertifikat des Kostenträgers mit einem Profil „KTR-AdV“ mit entsprechendem Schlüsselmaterial verwendet, das über ein Card-to-Card-Verfahren den Zugriff für die Anwendungsfälle auf der eGK gewährt.

AdV-A_2532 - Freischaltung der eGK

Die KTR-AdV MUSS für die Freischaltung der eGK ein CV-Zertifikat mit dem Profil „KTR-AdV“ verwenden. [<=]

Daraus folgt, dass kein anderes Zugriffsprofil für die Freischaltung der eGK verwendet werden darf .

2.2 Leistungen der TI-Plattform

Dem Produkttyp KTR-AdV stehen keine dedizierten, benachbarten Produkttypen zur Realisierung der Leistung der TI-Plattform (z.B. Konnektor) zur Verfügung. Die KTR-AdV muss die Verfahren und Systemprozesse der TI-Plattform, wie den Zugriff auf Smartcards und Zugriffe auf zentrale Dienste, implementieren.

Über die logische Komponente TIP-Consumer-Adapter stehen die Schnittstellen und Dienste der zentralen TI-Plattform zur Verfügung. Die Anbindung der eGK des Versicherten an die AdV-App und die kryptografische Verwendung der Identitäten der Kostenträger im AdV-Server erfolgen über eine logische Zugriffsschicht zur Kapselung plattformspezifischer Aspekte in Systemprozessen der TI-Plattform (vgl. Abbildung ABB_ADV_304).

Zur Anbindung der eGK an die AdV-App soll auf Geräten des Versicherten ein einfaches kontaktbehaftetes oder kontaktloses Kartenterminal angenommen werden, das seinerseits nicht notwendigerweise über Sicherheitsmerkmale verfügt. Wird die AdV-App in einem KTR-AdV-Terminal betrieben, dann erfolgt die Anbindung der eGK über ein Kartenterminal mit Sicherheitsmerkmalen (Display und PIN-Pad).

Zur Bildung eines Vertrauensraumes steht der KTR-AdV die PKI der TI zur Verfügung. Sie setzt die Mechanismen der PKI zum Aufspannen eines Vertrauensraums um. Die zertifikatsbasierte Authentisierung in Verbindung mit den kryptografischen Verfahren der TI dient der Sicherstellung des Datenschutzes, der Integrität und der Vertraulichkeit der Daten des Versicherten.

In einer Leistungserbringerumgebung stellt der Konnektor den Fachmodulen der Fachanwendungen Schnittstellen und Dienste der TI-Plattform bereit, welche diese zur Abbildung fachlicher Anwendungsfälle nutzen. Der Konnektor kapselt zusätzlich den Zugriff auf Smartcards und steuert die Kommunikation mit den entsprechenden Kartenterminals. Im Gegensatz dazu wird die Fachlogik der Fachanwendungen in der KTR-AdV mit der für die Umsetzung notwendigen Logik der dezentralen TI-Plattform in einem einzigen Produkttyp realisiert. Die Umsetzung der Fachlogik der Fachanwendungen kann sich auf AdV-App und AdV-Server verteilen.

Die von den Fachanwendungen benötigte Logik der dezentralen TI-Plattform wird in Form von Systemprozessen beschrieben. Diese stellen eine Leistungsbeschreibung dar, ohne Vorgaben an konkrete Realisierungsdetails zu machen. Sie setzen sich aus Logik-Bausteinen der verschiedenen Domänen der TI-Plattform (Karten, PKI, Kryptografie, etc.) zusammen und beschreiben fachliche Zusammenhänge. Die Fachmodule der Fachanwendungen setzen ihre fachanwendungsspezifischen Operationen in der KTR-AdV um, in dem sie auf die entsprechenden Systemprozesse verweisen. Die folgende Abbildung ABB_ADV_304 zeigt diesen Zusammenhang, ohne eine Vorgabe an die Modularisierung einer KTR-AdV-Software zu machen.

Abbildung 2: ABB_ADV_304 – Zusammenhang Systemprozesse und Fachanwendung

In Abhängigkeit von der Ablaufumgebung, z.B. dem verwendeten Kartenterminal, sind für das Funktionieren der Systemprozesse zusätzliche Umgebungsparameter oder umgebungsspezifische Operationen erforderlich. Diese werden als Eingabe- bzw. Ausgabeschnittstellen in den Systemprozessen aufgerufen und führen zu einem Tayloring (Zuschnitt) der Leistung der TI-Plattform auf eine an die Umgebung der Kostenträger angepasste „AdV-Plattform.“ Die KTR-AdV muss diese Schnittstellen als Umgebung zur Realisierung der Leistungen der TI-Plattform implementieren (Realisierungsumgebung).

Die Spezifikation der Systemprozesse findet sich in diesem Dokument in Anhang B[gemSpec_Systemprozesse_dezTI]. Es werden Anforderungen an die zu erbringende Leistung gestellt, ohne Vorgaben zu den zu verwendenden Technologien zu machen. Die Ausgestaltung und Modularisierung zwischen logischer Plattformebene, Kapselung von Fachlogik der weiteren Fachanwendungen sowie der gesicherten Schnittstelle zwischen AdV-App und AdV-Server obliegt dem Hersteller einer Lösung der KTR-AdV.

3 Systemkontext

3.1 Akteure und Rollen

Im Systemkontext der KTR-AdV interagieren verschiedene Akteure (aktive Komponenten) in unterschiedlichen Rollen mit der KTR-AdV. Die folgenden Akteure interagieren mit der KTR-AdV:

• Nutzer
  Ein Nutzer ist eine natürliche Person, die Anwendungsfälle in der KTR-AdV startet
• Ausführungsumgebung
  wird durch ein Gerät mit einem Betriebssystem gebildet, das die Teilkomponente AdV-App auf Seiten des Versicherten ausführt
• Kartenterminals
  ist eine technische Komponente zur Anbindung der eGK des Versicherten, um mit dieser die KTR-Anwendungsfälle auszuführen
• Smartcards
  Smartcards der TI sind Teil der dezentralen TI-Plattform und sind an die KTR-AdV zur Unterstützung der KTR-AdV-Anwendungsfälle angeschlossen
• Zentrale TI-Plattform
  Die Dienste der zentralen TI-Plattform unterstützen die KTR-AdV in der Ausführung der KTR-AdV-Anwendungsfälle.
• Fachdienste
  sind technische Komponenten, die im Rahmen fachanwendungsspezifischer Anwendungsfälle des Versicherten aufgerufen werden

Die folgende Tabelle TAB_ADV_300 listet diejenigen Akteure auf, die in verschiedenen Rollen mit der KTR-AdV interagieren.

Tabelle 1: TAB_ADV_300 – Akteure und ihre Rollen

Der Nutzer kann in verschiedenen Rollen aktiv werden. Als Versicherter nimmt der Nutzer seine Datenschutzrechte auf informationelle Selbstbestimmung wahr, indem er fachliche Anwendungsfälle zum Anzeigen und ggfs. Bearbeiten der mittels seiner eGK gespeicherten Daten startet. Die Nutzer mit den Rollen Administration und Betrieb stellen die technische Betriebsbereitschaft der KTR-AdV her, d. h. sie konfigurieren das System für die Inbetriebnahme und stellen während des Betriebs die Betriebsbereitschaft sicher.

AdV-A_2571 - Rollen- und Berechtigungskonzept der KTR-AdV

Der Anbieter einer KTR-AdV MUSS – als Teil des Sicherheitskonzepts – ein Rollen- und Berechtigungskonzept erstellen, welches die Administrations- und Betriebsaufgaben der KTR-AdV abdeckt.  [<=]

AdV-A_2533 - Kartenbezogene Benutzerrollen der KTR-AdV

Die KTR-AdV MUSS für die Benutzerverifikation für den Zugriff auf eine Karte der TI ein entsprechendes PIN-Objekt der passenden Rolle der folgenden Benutzer verwenden:

• Versicherter, für den Zugriff auf Objekte einer eGK
• Berechtigte Nutzer für Administrations- und Betriebsaufgaben, für den Zugriff auf privates Schlüsselmaterial der SM-B-Identitäten

Andere, nicht zu diesen Rollen passende PIN-Objekte, DÜRFEN NICHT verwendet werden. [<=]

Gemäß den Festlegungen in [gemSpec_eGK_ObjSys#5.3.10] darf die MRPIN.home nur außerhalb der TI verwendet werden. Im Produkttyp KTR-AdV als Teil der TI findet sie somit keine Verwendung.

Für die Benutzerverifikation der Rolle des Versicherten wird die PIN.CH verwendet.

Die Ausführungsumgebung kann zwei verschiedene Ausprägungen haben und bezieht sich auf die Ausführung der Teilkomponente AdV-App. Als KTR-AdV-Terminal wird sie von einem Betreiber verantwortet und muss eine bestimmte Sicherheitsleistung erbringen, um die mittels der eGK gespeicherten Daten des Versicherten zu schützen. Das KTR-AdV-Terminal wird als separater Produkttyp der TI spezifiziert. Im Gegensatz dazu ist ein Gerät des Versicherten ein beliebiges Gerät im Zugriff des Versicherten. Hier obliegt es dem Versicherten, die mittels seiner eGK gespeicherten Daten durch geeignete Maßnahmen zu schützen, da die hier spezifizierten Sicherheitsaspekte nur bis in die beim Versicherten ausgeführte Softwarekomponente AdV-App durchgesetzt werden können.

3.2 Nachbarsysteme

Die von der KTR-AdV erreichbaren Produkttypen der TI sind

• SM-B-Identitäten der KTR-AdV,
• eGK (G2 und höher),
• SZZP,
• Dienste der zentralen TI-Plattform und
• Fachdienste.

Die SM-B-Identitäten werden in der KTR-AdV benötigt, um auf der eGK des Versicherten erweiterte Zugriffsrechte freizuschalten und Verbindungen zu Fachdiensten und zu Diensten der zentralen TI-Plattform aufzubauen. Die Dienste der zentralen TI-Plattform und Fachdienste sind beispielsweise an den Anwendungsfällen zur Gültigkeitsprüfung und Aktualisierung der eGK des Versicherten beteiligt. Die Einbeziehung der SM-B-Identitäten der KTR-AdV muss unter Verwendung eines sicheren Speichers des kryptografischen Schlüsselmaterials der verwendeten Identitäten erfolgen.

Die Außenschnittstellen des Produkttyps KTR-AdV sind in der Abbildung ABB_ADV_301 dargestellt und im Folgenden aufgelistet:

• Die Schnittstelle zu einem Kartenterminal, wie in Abschnitt 6.2.1 beschrieben.
• Die Schnittstellen des Consumer Adapters zu den zentralen Diensten der TI, wie in Abschnitt 6.2.4 beschrieben.
• Eine grafische Benutzeroberfläche, deren Aspekte in den jeweiligen Anwendungsfällen in Abschnitt 6.1 beschrieben sind.

 

Abbildung 3: ABB_ADV_301 – Kontextdiagramm

3.3 Ablaufumgebung

Die Komponenten der KTR-AdV werden in verschiedenen Umgebungen betrieben, die in ABB_ADV_303 dargestellt sind.

 

 

Abbildung 4: ABB_ADV_303 – Verteilungsdiagramm

Die Komponente „AdV-Server“ wird in einem Rechenzentrum betrieben:

AdV-A_2403 - AdV-Server: Betrieb in Rechenzentrum im Auftrag der Krankenkassen

Der Anbieter einer AdV in einer Umgebung im Auftrag der Kostenträger MUSS den AdV-Server in einem Rechenzentrum im Auftrag der Krankenkassen betreiben. [<=]

Der Komponente „AdV-App“ stehen zwei verschiedene Ablaufumgebungen zur Verfügung.

Im nicht-öffentlichen zugänglichen Bereich (@home) wird die AdV-App auf einem Gerät des Versicherten betrieben. An diese Umgebung können keine Sicherheitsanforderungen gestellt werden. Der Schutz des eingesetzten Gerätes liegt in der Verantwortung des Versicherten. Durch geeignete Hinweise und Empfehlungen soll der Versicherte aufgeklärt werden, wie die AdV-App sicher genutzt werden kann und dass auch der Versicherte selbst hierzu beitragen kann. Im Rahmen dieser Informationen sollen insbesondere die Vorteile eines Kartenterminals mit Sicherheitsmerkmalen (bspw. Display, PIN-Pad) beschrieben und entsprechende Empfehlungen ausgesprochen werden.

AdV-A_2404 - AdV-App: Information zum sicheren Betrieb

Der Anbieter einer KTR-AdV MUSS den Versicherten informieren, welche Maßnahmen zum sicheren Betrieb der AdV-App auf dem Gerät eines Versicherten beitragen. [<=]

Im öffentlichen zugänglichen Bereich wird die AdV-App in einem KTR-AdV-Terminal betrieben.

AdV-A_2405 - AdV-App: Betrieb in KTR-AdV-Terminal

Der Betreiber einer KTR-AdV MUSS die AdV-App, falls sie innerhalb eines öffentlich zugänglichen Bereichs zur Verfügung gestellt wird, in einem KTR-AdV-Terminal betreiben. [<=]

Das KTR-AdV-Terminal ist ein Produkttyp der TI. Anforderungen an den Produkttyp sind in [gemSpec_KTR-AdV-Terminal] spezifiziert.

4 Zerlegung des Produkttyps

Der Produkttyp KTR-AdV besteht aus den Teilsystemen AdV-Server und AdV-App.

Im Folgenden wird die Zerlegung des Produkttyps KTR-AdV dargestellt, welche für die Übersicht der funktionalen Leistungsmerkmale in vorliegender Spezifikation nötig ist.

Abbildung 5: ABB_ADV_329 – Komponentendiagramm der KTR-AdV

In Tabelle TAB_ADV_329 werden die Komponenten, ihre Verantwortlichkeit und spezifische Funktionalitäten dargestellt.

Tabelle 2: TAB_ADV_329 – Komponenten, Verantwortung und Funktionalitäten

5 Übergreifende Festlegungen

5.1 Datenschutz und Sicherheit

In diesem Kapitel werden übergreifende Anforderungen beschrieben, die sich aus den Themenfeldern Datenschutz und Sicherheit ergeben.

5.1.1 Verarbeitung personenbezogener Daten

Um den Datenschutz des Versicherten zu gewährleisten, werden folgende Anforderungen gestellt:

AdV-A_2407 - Keine persistente Speicherung von Daten des Versicherten

Die KTR-AdV DARF personenbezogene Daten von Versicherten, mit Ausnahme der ICCSN der betroffenen eGK bei eGK-bezogenen Fehlern, NICHT persistent speichern. [<=]

AdV-A_2409 - Löschen der Daten nach Abmeldung

Die KTR-AdV MUSS alle Daten des Versicherten, mit Ausnahme der ICCSN der betroffenen eGK bei eGK-bezogenen Fehlern, aus seinem Speicher löschen, sobald die AdV-Sitzung des Versicherten beendet wird. [<=]

AdV-A_2410 - Abmeldung des Nutzers nach 5 Minuten Inaktivität

Die AdV-App MUSS den Versicherten nach spätestens fünf Minuten Inaktivität von der AdV-App automatisch abmelden und die Sitzung beenden. Eine Aktivität binnen der maximalen Inaktivitätsdauer MUSS die Ablaufzeit für die Inaktivitätsdauer erneut starten. [<=]

AdV-A_2568 - Warnung des Nutzers vor Abmeldung nach Inaktivität

Die AdV-App KANN dem Versicherten vor der Abmeldung wegen Inaktivität einen Hinweis einblenden, der es dem Nutzer ermöglicht die Sitzung fortzuführen. [<=]

Es kann vor der Abmeldung des Versicherten ein Hinweis eingeblendet werden, der es dem Nutzer ermöglicht die Session fortzuführen.

AdV-A_2534 - Ausführung von Anwendungsfällen mit lokalen Mitteln

Die AdV-App DARF NICHT Daten des Versicherten an den AdV-Server übertragen, wenn sich der Anwendungsfall auch mit lokalen Mitteln ausführen lässt. Dies betrifft alle medizinischen Daten nach § 291a Abs.2 und Abs.3 SGB V, eGK-Protokolldaten, die Information über genutzte Fachanwendungen, den DPE, die VSD (ausgenommen die KVNR), die PIN und Zertifikate der eGK außer C.CH.AUTN und C.eGK.AUT_CVC.  [<=]

Hiermit soll erreicht werden, dass die AdV-App nur dann mit dem AdV-Server kommuniziert, wenn dies für den Anwendungsfall unbedingt notwendig ist. Beispiele hierfür sind die Gültigkeitsprüfung beim Sitzungsstart oder die Kommunikation zu den Fachdiensten VSDM für die Onlineprüfung und -aktualisierung der Versichertenstammdaten. Die Änderung einer PIN oder das Anzeigen von Protokolldaten der eGK hingegen lässt sich mit lokalen Mitteln durchführen und darf nicht über den AdV-Server umgesetzt werden.

Die AdV-App kann unter Wahrung der gesetzlichen Rahmenbedingungen die KVNR an den AdV-Server übertragen.

AdV-A_2411 - Keine Protokollierung medizinischer Daten

Die KTR-AdV DARF NICHT medizinische Daten protokollieren. [<=]

AdV-A_2412 - Keine Protokollierung personenbezogener Daten

Die KTR-AdV DARF NICHT personenbezogene Daten von Versicherten, mit Ausnahme der ICCSN der betroffenen eGK bei kartenbezogenen Fehlern, protokollieren. [<=]

5.1.2 Absicherung der AdV-Komponenten

Um die verarbeiteten Daten zu schützen, werden folgende Anforderungen zur Absicherung der AdV-Komponenten erhoben:

AdV-A_2413 - AdV-Server: Keine unberechtigten Zugriffe

Der AdV-Server MUSS unberechtigte Zugriffe auf die dort gespeicherten und verarbeiteten Daten und das zentrale Netz der TI verhindern. [<=]

Hierzu zählen bspw. der Zugriff über externe Schnittstellen zum Internet oder der TI, das Ausnutzen von Schwachstellen der installierten Software bzw. des Betriebssystems / der Firmware oder das Einbringen von Schadsoftware. Je nach Ausgestaltung und Funktionsumfang können geeignete Maßnahmen bspw. sein:

• Härtung des Betriebssystems (nur notwendige Software / Dienste)
• Schließen nicht verwendeter Ports
• Einsatz einer Statefull Packetinspection / Firewall
• Einsatz von Intrusion Detection/Prevention Systemen
• Validierung von eingehenden Anfragen
• Einsatz einer Antiviren-Software inklusive regelmäßiger Aktualisierung dieser Software
• ggf. logische Trennung von anderen Anwendungen (Virtualisierung).

AdV-A_2546 - AdV-App: Sichere Verteilung

Der Anbieter der KTR-AdV MUSS die AdV-App so an die Nutzer verteilen und diese darüber informieren, dass sie in der Lage sind, die Quelle und damit auch die Integrität und Authentizität der AdV-App zu prüfen. [<=]

Mit dieser Anforderung soll erreicht werden, dass die AdV-App über den offiziellen Weg des Herstellers bzw. die technologischen Standardmechanismen einer Plattform verteilt wird. Bspw. sollte der Play-Store für die Verteilung einer Android-Variante der AdV-App verwendet werden und für PC-Installationen sollte die Anwendung von der offiziellen Website des Anbieters herunterladbar sein. Nutzer müssen ausreichend informiert werden. Zum Beispiel könnte auf der Website des Anbieters der Name und der Hersteller der AdV-App genannt werden, damit diese im jeweiligen App-Store leicht zu identifizieren ist. Ziel ist es, dem Nutzer der AdV-App Sicherheit zu geben, dass er die richtige AdV-App nutzt.

AdV-A_2414 - AdV-App: Bereitstellen von Softwareaktualisierungen

Der Anbieter der AdV-App MUSS zeitnah Softwareaktualisierungen zur Beseitigung von Schwachstellen der AdV-App bereitstellen.

[<=]

Die Reaktionszeiten auf Schwachstellen sind vom Hersteller für die einzelnen Softwarekomponenten anzugeben und werden im Rahmen der Sicherheitsprüfung bewertet.

AdV-A_2415 - AdV-App: Vertrauliche PIN-Eingabe erlauben

Die AdV-App MUSS die vertrauliche PIN-Eingabe des Versicherten erlauben. [<=]

Für die Umsetzung sind bspw. folgende Maßnahmen sinnvoll:

• Die AdV-App implementiert ein virtuelles PIN-Pad um eine externe Softwaretastatur zu umgehen, falls das Kartenterminal kein PIN-Pad besitzt.
• Die PIN wird nicht im Klartext angezeigt.

Die Verbindung zwischen AdV-Server und AdV-App wird mittels TLS gemäß den Vorgaben aus [gemSpec_Krypt] abgesichert.

AdV-A_2416 - TLS-Verbindung zwischen AdV-Server und AdV-App

Die AdV-App MUSS mit dem AdV-Server ausschliesslich über TLS kommunizieren. [<=]

A_16395 - Kein TLS Session-Resumtion und Renegotiation

Die KTR-AdV DARF im Rahmen der TLS-Verbindung zwischen AdV-App und AdV-Server die Renegotiation und Session-Resumption NICHT unterstützen. [<=]

Die AdV-App muss dabei in der Lage sein, auch ohne Verwaltung einer aktuellen TSL einen AdV-Server zu authentisieren. Daher benötigt sie einen Truststore, in dem sich bereits vor dem Verbindungsaufbau die TLS-Zertifikate der AdV-Server befinden, mit denen sie sich verbinden kann. Die TLS-Zertifikate müssen den Vorgaben von [gemSpec_Krypt] entsprechen.

AdV-A_2417 - AdV-App: lokaler Truststore

Die AdV-App MUSS Zugriff auf einen lokalen integer geschützten Truststore besitzen, der die TLS-Zertifikate der AdV-Server enthält, mit denen die AdV-App sich verbinden kann. [<=]

AdV-A_2572 - AdV-App: interner Truststore

Die AdV-App SOLL den lokalen Truststore enthalten.  [<=]

Ein möglicher Grund, die Anforderung AdV-A_2572 nicht umzusetzen, ist die Verwendung einer Plattform für die Ausführung der AdV-App, die einen eigenen Truststore anbietet und dessen Verwendung verlangt.

AdV-A_2573 - AdV-App: Initialisierung und Aktualisierung des TLS-Vertrauensankers

Der Anbieter der KTR-AdV MUSS für die AdV-App ein Verfahren zur initialen Auslieferung sowie Aktualisierung des Vertrauensankers für die AdV-Server-TLS-Zertifikate implementieren, das die Integrität und Authentizität des Vertrauensankers wahrt.  [<=]

Damit die AdV-App stets aktuelle Zertifikate der AdV-Server erhält, ist ein Verfahren notwendig, den lokalen Truststore der AdV-App initial zu befüllen und zu aktualisieren. Dies kann zum Beispiel durch neue Versionen der AdV-App – welche einen aktualisierten Truststore enthalten – realisiert werden. Es sind aber auch andere Verfahren denkbar.

 

AdV-A_2421 - AdV-Server: Schnittstelle Internet - Ablehnung unzulässiger Verbindungen

Der AdV-Server MUSS Verbindungen an der Schnittstelle zum Internet ablehnen, wenn keine TLS-Verbindung aufgebaut werden kann oder die nachgelagerte Authentifizierung gemäß ABB_ADV_333 fehlschlägt. [<=]

5.1.3 Verbindungsaufbau und Freischaltung eGK

In diesem Kapitel ist der Verbindungsaufbau von der AdV-App zum AdV-Server und die anschließende Freischaltung der eGK durch ein Card-to-Card (C2C) beschrieben, welche im Rahmen des Anwendungsfalls „Starten einer Sitzung“ durchgeführt werden.

Abbildung 6 : ABB_ADV_333 Verbindungsaufbau und Freischaltung eGK

A_15110 - AdV-App: TLS-Verbindung zum AdV-Server initiieren

Die AdV-App MUSS während des Sitzungsstarts eine TLS-Verbindung zum AdV-Server aufbauen. [<=]

AdV-A_2418 - AdV-App: unzulässige TLS-Verbindungen ablehnen

Die AdV-App MUSS bei jedem Verbindungsaufbau den AdV-Server anhand seines TLS-Zertifikats mittels des lokalen Truststores authentifizieren und MUSS die Verbindungen ablehnen, falls die Authentifizierung fehlschlägt. [<=]

A_15111 - AdV-App: Institutskennzeichen an AdV-Server senden

Die AdV-App MUSS für die Freischaltung der eGK die IK-Nummer aus dem C.CH.AUT Zertifikat der eGK an den AdV-Server senden. [<=]

Das Institutskennzeichen entspricht der 9-stelligen Nummer aus dem Organizational Unit Name im Subject Distinguished Name des C.CH.AUT-Zertifikates des Versicherten.

A_15112 - AdV-Server, AdV-App: Beidseitiges Card-to-Card mit Flagliste Null

Der AdV-Server und AdV-App MÜSSEN ein beidseitiges Card-to-Card durchführen, wobei der AdV-Server ein CV Zertifikat mit Zugriffsprofil CHA.0 verwendet, und einen Trusted Channel etablieren. [<=]

Ein CVC Zertifikat mit dem Zugriffsprofil CHA.0 besitzt keine Rechte zum Freischalten der eGK.

AdV-A_2570 - SM-B des Herausgebers der eGK verwenden

Der AdV-Server MUSS für das Card-to-Card eine SM-B des Herausgebers der eGK verwenden und die Verbindung abbrechen, wenn diese SM-B nicht verfügbar ist. [<=]

Die Zuordnung zwischen der eGK und der SM-B des Herausgebers kann anhand der von der AdV-App übermittelten IK-Nummer erfolgen.

A_15113 - AdV-App: Flaglist prüfen

Die AdV-App MUSS während des beidseitigen Card-to-Card prüfen, dass das zu importierende CV-EE-Zertifikat das Zugriffsprofil CHA.0 besitzt. [<=]

A_15114 - AdV-Server: Prüfung Status PIN.CH der eGK

Der AdV-Server MUSS in dem Trusted Channel den Status der PIN.CH der eGK abfragen und die Verbindung abbrechen, wenn der Sicherheitszustand des Passwortobjektes nicht gesetzt ist. [<=]

Die erwartete Antwort der eGK auf das Kartenkommando Get PIN Status ist NoError (‚90 00‘).

A_15115 - AdV-Server, AdV-App: Einseitiges Card-to-Card mit CVC „KTR-AdV“

Der AdV-Server und die AdV-App MÜSSEN nach erfolgreicher Prüfung des Status der PIN.CH der eGK ein einseitiges Card-to-Card durchführen, wobei der AdV-Server ein CV Zertifikat mit Zugriffsprofil CHA.1 verwendet. [<=]

Dieses einseitige Card-to-Card schaltet die eGK frei. Der für die Statusabfrage aufgebaute Trusted Channel kann abgebaut werden.

A_15116 - AdV-App: Abbruch bei Fehler im Verbindungsaufbau und Freischaltung eGK

Die AdV-App MUSS bei Fehlern in den Operationen zum Verbindungsaufbau und der Freischaltung der eGK während des Sitzungsstarts die Sitzung beenden. [<=]

Für Erläuterungen zum Card-2-Card und der Prüfung des Status einer PIN siehe auch [gemSpec_CardProxy].

5.1.4 Filterung von Kartenkommandos an die eGK

Während der Freischaltung der eGK durch ein Card-to-Card und der Onlineaktualisierung der VSD findet eine direkte Kommunikation zwischen der eGK und dem AdV-Server bzw. den Fachdiensten VSDM über den AdV-Server statt. Damit eine freigeschaltete eGK nicht durch einen manipulierten AdV-Server ausgelesen werden kann, muss die AdV-App alle Kartenkommandos, welche über den AdV-Server an die eGK gesendet werden, prüfen.

A_15117 - AdV-App: Ablehnen von Kartenkommandos

Die AdV-App MUSS alle vom AdV-Server gesendeten Kartenkommandos ablehnen, welche nicht gemäß [TR AdV-App#Anhang C] zulässig sind, und die AdV-Sitzung beenden. [<=]

5.2 Logging

Der AdV-Server und die AdV-App auf dem KTR-AdV-Terminal sollen Protokolldateien schreiben, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren, die Performance zu analysieren und interne Abläufe zu beobachten. Bei der Erstellung von Einträgen in ein Protokoll bzw. Log sind die Anforderungen aus Kapitel 5.1.1 Verarbeitung personenbezogener Daten umzusetzen.

Ein Logging der AdV-App auf Geräten des Versicherten ist nicht vorgesehen.

AdV-A_2437 - AdV-App: Kein Logging auf Geräten des Versicherten

Die AdV-App MUSS als Standardkonfiguration das Logging deaktiviert haben und auf dem KTR-AdV-Terminal die Aktivierung dieser Option durch einen berechtigten Nutzer ermöglichen. [<=]

Es gelten die übergreifenden Anforderungen zum Logging aus [gemSpec_OM].

AdV-A_2422 - AdV-Server: Erzeugung von FehlerLog-Einträgen

Der AdV-Server MUSS bei lokal erkannten Fehlern und Remote-Fehlern ein Fehlerprotokoll schreiben, welches dem berechtigten Nutzer für Administrations- und Betriebsaufgaben Rückschlüsse auf die aufgetretenen Fehler ermöglicht. [<=]

AdV-A_2423 - AdV-App: Erzeugen von FehlerLog-Einträgen

Die AdV-App MUSS, wenn sie auf einem KTR-AdV-Terminal betrieben wird, bei lokal erkannten Fehlern und Remote-Fehlern ein Fehlerprotokoll schreiben, welches dem berechtigten Nutzer für Administrations- und Betriebsaufgaben Rückschlüsse auf die aufgetretenen Fehler ermöglicht. [<=]

AdV-A_2424 - Speichern der ICCSN zur Fehleranalyse

Die KTR-AdV MUSS die ICCSN der eGK im Protokoll speichern, wenn ein eGK-bezogener Fehler aufgetreten ist. [<=]

AdV-A_2426 - Löschen der ICCSN aus Fehlerprotokoll

Die KTR-AdV MUSS jede ICCSN nach maximal 180 Tagen aus dem Fehlerprotokoll löschen. [<=]

AdV-A_2428 - AdV-Server: Ablaufprotokoll

Der AdV-Server MUSS ein Ablaufprotokoll schreiben, das geeignet ist, die ausgeführten Abläufe nachzuvollziehen. Das Ablaufprotokoll erfasst für jeden ausgeführten Vorgang: Vorgangsbezeichner, Datum mit Uhrzeit von Beginn und Ende, vollständiger Name des Vorgangs, Beschreibung des Vorgangs inkl. des Ergebnisses: Erfolg oder Fehlermeldung (Returnwert/Fehlercode). [<=]

AdV-A_2429 - AdV-App: Ablaufprotokoll

Die AdV-App MUSS, wenn sie auf einem KTR-AdV-Terminal betrieben wird, ein Ablaufprotokoll schreiben, das geeignet ist, die ausgeführten Abläufe nachzuvollziehen. Das Ablaufprotokoll erfasst für jeden ausgeführten Vorgang: Vorgangsbezeichner, Datum mit Uhrzeit von Beginn und Ende, vollständiger Name des Vorgangs, Beschreibung des Vorgangs inkl. des Ergebnisses: Erfolg oder Fehlermeldung (Returnwert/Fehlercode). [<=]

AdV-A_2430 - AdV-Server: PerformanceLog

Der AdV-Server SOLL ein Performanceprotokoll schreiben, welches geeignet ist, die Ausführungszeit von Operationen auf dem AdV-Server zu überprüfen. [<=]

AdV-A_2431 - AdV-App: PerformanceLog

Die AdV-App SOLL, wenn sie auf einem KTR-AdV-Terminal betrieben wird, ein Performanceprotokoll schreiben, welches geeignet ist, die Ausführungszeit der Operationen der AdV-App zu überprüfen. [<=]

AdV-A_2432 - AdV-Server: DebugLog

Der AdV-Server KANN im Testbetrieb unter Verwendung des Severity Codes "Debug" ein DebugLog schreiben, welches eine erweiterte Protokollierung für Testzwecke ermöglicht. [<=]

AdV-A_2433 - AdV-App: DebugLog

Die AdV-App KANN, wenn sie auf einem KTR-AdV-Terminal betrieben wird, im Testbetrieb unter Verwendung des Severity Codes "Debug" ein DebugLog schreiben, welches eine erweiterte Protokollierung für Testzwecke ermöglicht. [<=]

AdV-A_2434 - AdV-Server: SecurityLog

Der AdV-Server KANN ein SecurityLog zur Protokollierung sicherheitsrelevanter Ereignisse implementieren. [<=]

AdV-A_2435 - AdV-App: SecurityLog

Die AdV-App KANN, wenn sie auf einem KTR-AdV-Terminal betrieben wird, ein SecurityLog zur Protokollierung sicherheitsrelevanter Ereignisse implementieren. [<=]

AdV-A_2436 - Verfügbarkeit interner Logdaten

Der Betreiber der KTR-AdV MUSS im Rahmen von Testmaßnahmen dem Testbetriebsverantwortlichen auf Anforderung die Log-Dateien übermitteln. [<=]

Die Rolle des Testbetriebsverantwortlichen ist im Testkonzept [gemKPT_Test] beschrieben.

AdV-A_2438 - AdV-Server: Erweiterte Loglevel zur Bezeichnung der Granularität des FehlerLog

Der AdV-Server SOLL die Fehleranalyse durch eine mit Logleveln konfigurierbare Speicherung der aufgetretenen Fehlerfälle unterstützen. [<=]

AdV-A_2439 - AdV-App: Erweiterte Loglevel zur Bezeichnung der Granularität des FehlerLog

Die AdV-App SOLL, wenn sie auf einem KTR-AdV-Terminal betrieben wird, die Fehleranalyse durch eine mit Logleveln konfigurierbare Speicherung der aufgetretenen Fehlerfälle unterstützen. [<=]

AdV-A_2440 - AdV-Server: Art der Protokollierung

Der AdV-Server MUSS Protokolleinträge so anlegen, dass eine Analyse der Einträge unterstützt wird:

• Protokolleinträge zum selben Vorgang (der ausgelöst werden kann z.B. durch eine Außenoperation, eine Administrations- oder Betriebsinteraktion, ein Ereignis, …) MÜSSEN entlang der Aufrufkette über Protokollgrenzen hinweg dem Vorgang zugeordnet werden können (gleiche Vorgangsbezeichner).
• Die Protokolleinträge MÜSSEN eine patternbasierte Filterung unterstützen. Protokollwert/-texte sowie Attribute MÜSSEN in ihren Namensstrukturen hierauf abgestimmt sein.

[<=]

AdV-A_2441 - AdV-App: Art der Protokollierung

Die AdV-App MUSS, wenn sie auf einem KTR-AdV-Terminal betrieben wird, Protokolleinträge so anlegen, dass eine Analyse der Einträge unterstützt wird:

• Protokolleinträge zum selben Vorgang (der ausgelöst werden kann z.B. durch eine Außenoperation, eine Administrations- oder Betriebsinteraktion, ein Ereignis, …) MÜSSEN entlang der Aufrufkette über Protokollgrenzen hinweg dem Vorgang zugeordnet werden können (gleiche Vorgangsbezeichner).
• Die Protokolleinträge MÜSSEN eine patternbasierte Filterung unterstützen. Protokollwert/-texte sowie Attribute MÜSSEN in ihren Namensstrukturen hierauf abgestimmt sein.

[<=]

AdV-A_2442 - AdV-Server: Zugriff auf Protokolldateien

Der AdV-Server MUSS den Zugriff auf Protokolldateien auf berechtigte Nutzer für Administrations- und Betriebsaufgaben beschränken. [<=]

AdV-A_2443 - AdV-App: Zugriff auf Protokolldateien

Die AdV-App MUSS, wenn sie auf einem KTR-AdV-Terminal betrieben wird, den Zugriff auf Protokolldateien auf berechtigte Nutzer für Administrations- und Betriebsaufgaben beschränken. [<=]

5.3 Nicht-funktionale Anforderungen

Die KTR-AdV ist ein dezentraler Produkttyp der TI, welcher nicht direkt in den Versorgungsprozess beim Leistungserbringer eingebunden ist. Die Beauftragung zur Umsetzung erfolgt durch die Kostenträger. Diese haben durch eine Integration der AdV-Lösung in ihre Onlinestrategie eine Möglichkeit, Mehrwert für ihre Versicherten zu schaffen. Aus diesem Grund werden Anforderungen zur Verfügbarkeit und Performance der KTR-AdV nicht durch die gematik, sondern durch den beauftragenden Kostenträger gestellt.

6 Funktionsmerkmale

6.1 Implementation der AdV Anwendungsfälle

Die folgenden Anwendungsfälle beschreiben das Außenverhalten des Systems anhand der Implementierung von AdV-Anwendungsfällen. Diese sind für den Versicherten zur Verwaltung seiner elektronischen Gesundheitskarte ausgelegt. Jeder Anwendungsfall wird durch den Versicherten eigenständig initiiert.

Dieses Kapitel beschreibt die übergreifenden Funktionalitäten der AdV Anwendungsfälle. Zur Realisierung dieser Funktionalitäten werden

• Leistungen der TI-Plattform (Plattformleistungen „PL_TUC_*“) aus Anhang B[gemSpec_Systemprozesse_dezTI] und
• spezifische Fachlogik aus den entsprechenden (Fach-)Modulen NFDM [gemSpec_FLA_NFDM] und VSDM [gemSpec_FM_VSDM]

eingesetzt.

Falls während der Ausführung eines Plattformbausteins ein Fehler auftritt, liefert dieser einen Fehlercode zurück. Falls diese Fehler im lokalen Kontext des Anwendungsfalls lösbar sind, wird diese Behandlung des Fehlers dort beschrieben. Alle weiteren Fehler werden wie folgt behandelt:

AdV-A_2444 - AdV-App Fehlerverarbeitung

Die AdV-App MUSS

• In allen Fehlerfällen dem Versicherten eine Fehlermeldung anzeigen und verständliche Hinweise zur Lösung des Problems geben.
• Die in TAB_ADV_318 aufgeführten Fehlercodes der Plattformbausteine gemäß dieser Tabelle verarbeiten, falls im Anwendungsfall keine abweichende Behandlung definiert ist.

 

Tabelle 3: TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine

[<=]

6.1.1 AdV-Sitzung des Versicherten

Nach der erfolgreichen Initialisierung der AdV-Sitzung kann der Versicherte Anwendungsfälle zur Verwaltung seiner Gesundheitskarte ausführen, bspw. PINs auf seiner Karte verwalten und Anwendungsfälle weiterer Fachanwendungen ausführen.

6.1.1.1 AdV-Sitzung initialisieren

Mit diesem Anwendungsfall wird die AdV-Sitzung des Versicherten gestartet, der Start des Anwendungsfalls erfolgt implizit durch Stecken der eGK und Starten der AdV-App durch den Versicherten.

Hinweis: Unter "Stecken der eGK" kann auch der Aufbau einer Verbindung zur eGK über die kontaktlose Schnittstelle der eGK verstanden werden.

AdV-A_2445 - AdV-App: Starten einer Sitzung

Die AdV-App MUSS den Anwendungsfall „Starten einer Sitzung“ gemäß TAB_ADV_303 umsetzen.

 

Tabelle 4: TAB_ADV_303 – Starten einer AdV-Sitzung

Name	Starten einer AdV-Sitzung
Auslöser	Der Versicherte startet die AdV-App und steckt seine eGK in ein Kartenterminal.
Akteure	Versicherter
Vorbedingung	Die AdV-App kann auf die eGK des Versicherten zugreifen und den AdV-Server erreichen. Eine SM-B des Herausgebers der eGK ist vorhanden.
Nachbedingung	Die AdV-App hat für die AdV-Sitzung eine TLS-Verbindung zum AdV-Server aufgebaut. Die Benutzerverifikation mit der PIN.CH wurde erfolgreich durchgeführt. Die eGK wurde durch ein Card-2-Card mit einer korresponsierenden SM-B freigeschaltet und auf Gültigkeit geprüft. Die eGK wurde auf Gültigkeit geprüft. Für die eGK werden durch Plattformbaustein PL_TUC_CARD_INFORMATION die dort spezifizierten Informationen bereitgestellt. Die Sitzung des Versicherten wurde gestartet. Der Gültigkeitsstatus der eGK wird angezeigt. Es werden die mit der eGK des Versicherten verfügbaren Fachanwendungen aufgelistet. In allen - nicht behebbaren – Fehlerfällen wird die AdV-Sitzung beendet (Kap. 6.1.1.2 AdV-Sitzung beenden).
Aktivitäten	Die Umsetzung ist in Tabelle TAB_ADV_304 beschrieben. Falls eine Aktivität für die eGK bereits durchgeführt wurde (z.B. eine PIN-Prüfung), muss sie nicht wiederholt werden. Einlesen der Karte Einverständnis des Versicherten einholen (Benutzerverifikation) Versicherten-PIN entsperren (optional) Verbindungsaufbau zum AdV-Server und Freischaltung eGK Protokollieren des eGK-Zugriffs (für eGK G2) Online-Gültigkeitsprüfung der eGK Verfügbare Anwendungen anzeigen

 

Tabelle 5: TAB_ADV_304 – Ablaufaktivitäten - Starten einer AdV-Sitzung

Einlesen der Karte
Plattformbaustein	PL_TUC_CARD_INFORMATION
Eingangsdaten
eGK	Nach Stecken der eGK werden durch den Plattformbaustein PL_TUC_CARD_INFORMATION Statusinformationen bereitgestellt.
Beschreibung	Die AdV-App MUSS nach Stecken der eGK und vor dem Ausführen eines anderen Anwendungsfalls die Karteninformationen in PL_TUC_CARD_INFORMATION auswerten hinsichtlich Kartentyp, MUSS vom Typ eGK sein Produkttypversion des Objektsystems, MUSS G2 oder höher sein Echtheit der Karte, die Karte MUSS für echt befunden sein und bei unpassenden Kartendaten die Sitzung beenden. Falls entsprechend PL_TUC_CARD_INFORMATION der Status der PIN.CH "PIN gesperrt" ist, wird mit Aktivität "Versicherten-PIN entsperren" fortgefahren.
Einverständnis des Versicherten einholen (Benutzerverifikation)
Plattformbaustein	PL_TUC_CARD_VERIFY_PIN
Eingangsdaten
Identifikator	PIN.CH
Benutzerhinweis am Kartenterminaldisplay (Sicherheitsklasse 3) bzw. im AdV-App-Benutzerinterface bei Aufruf der Umgebungsoperation ENV_TUC_SECRET_INPUT	„Eingabe Versicherten-PIN: “
Rückgabedaten
Rückgabe - Beschreibung	Aktion durch AdV-App
OK - PIN erfolgreich verifiziert	Verarbeitung mit Aktivität "Verbindungsaufbau zum AdV-Server und Freischaltung eGK" fortsetzen.
WrongSecretWarning.X - PIN falsch, noch X Versuche	Wird durch den Versicherten ein falsches PIN-Geheimnis eingegeben, wird die verbleibende Anzahl der Eingabeversuche bis zur Sperrung des PINs zurückgemeldet. Der Versicherte hat die Wahl die PIN erneut einzugeben oder die Sitzung zu beenden.
PasswordBlocked - PIN ist durch Fehleingaben blockiert	Verarbeitung mit Aktivität "Versicherten-PIN entsperren" fortsetzen.
Weitere Fehlerfälle	Siehe Beschreibung PL_TUC_CARD_VERIFY_PIN und "TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine" für die Behandlung in der AdV-App. In all diesen Fehlerfällen muss nach Information des Versicherten die Sitzung beendet werden.
Beschreibung	Der Versicherte muss den Zugriff auf seine eGK mittels PIN-Verifikation autorisieren. Falls der Versicherte die PIN.CH der eGK bereits eingegeben hat, kann diese Aktivität entfallen. Es ist möglich, dass die PIN blockiert ist, der Versicherte seine Versicherten-PIN falsch eingibt oder ein technischer Fehler auftritt. Der Start der AdV-Sitzung ist in diesen Fällen nicht erfolgreich. Im Folgenden sind keine weiteren Anwendungsfälle außer dem Beenden der Sitzung (6.1.1.2 AdV-Sitzung beenden) bzw. dem Entsperren der Versicherten-PIN zulässig.
Versicherten-PIN entsperren (optional)
Anwendungsfall	Versicherten-PIN entsperren (Kap 6.1.5.4)
Beschreibung	Der Versicherte kann seine Versicherten-PIN (PIN.CH) in diesem Anwendungsfall entsperren. Nach erfolgreichem Entsperren der Versicherten-PIN ist die Aktivität "Einverständnis des Versicherten einholen" zu wiederholen. Es ist möglich, dass die PIN nicht entsperrt wurde oder ein technischer Fehler auftritt. Der Start der AdV-Sitzung ist in diesen Fällen nicht erfolgreich. Die Sitzung wird beendet (6.1.1.2 AdV-Sitzung beenden).
Verbindungsaufbau zum AdV-Server und Freischaltung eGK
Beschreibung	Siehe Kap. 5.1.3 Verarbeitung mit Aktivität "Protokollieren des eGK-Zugriffs" fortsetzen.
Protokollieren des eGK-Zugriffs (für eGK G2)
Plattformbaustein	PL_TUC_EGK_APPEND_PROTOCOL
Eingangsdaten
DATATYPE	„v“   (Anwendungen des Versicherten in der KTR-AdV Umgebung)
ACCESSTYPE	„Z“   (allgemeiner Zugriff; Lesen und bearbeiten).
Rückgabedaten
Rückgabe - Beschreibung	Aktion durch AdV-App
OK - Protokolleintrag erfolgreich hinzugefügt	Verarbeitung mit Aktivität "Online-Gültigkeitsprüfung der eGK" fortsetzen.
Fehlerfälle	Siehe Beschreibung PL_TUC_EGK_APPEND_PROTOCOL und "TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine" für die Behandlung in der AdV-App. In all diesen Fehlerfällen muss nach Information des Versicherten die Sitzung beendet werden (Kap. 6.1.1.2 AdV-Sitzung beenden).
Beschreibung	Nach erfolgreicher Freischaltung der eGK erfolgt die Protokollierung des Datenzugriffs für eine eGK der Version G2. Für eine eGK G2 wird genau ein Eintrag am Beginn einer AdV-Sitzung in das Zugriffsprotokoll EF.Logging der Karte geschrieben. Für alle höheren Versionen der eGK wird dieser Logeintrag nicht benötigt, da das Logging innerhalb der ausgeführten Anwendungsfälle erfolgt. Der Aufbau der Eingangsdaten wird in PL_TUC_EGK_APPEND_PROTOCOL beschrieben.
Online-Gültigkeitsprüfung der eGK
Plattformbaustein	PL_TUC_EGK_STATUS
Rückgabedaten
Rückgabe	Aktion durch AdV-App
Status der Gesundheitsanwendung auf der eGK: Gesundheitsanwendung aktiv	Fortfahren und Aufbereitung der Menüstruktur
Status der Gesundheitsanwendung auf der eGK: Gesundheitsanwendung nicht-aktiv	Beschränkung der Anwendungsfälle entsprechend Tabelle TAB_ADV_384. Hinweis: In dem Fall wird der Anwendungsfall dem Versicherten mit der Bezeichnung „Entsperren der Gesundheitsanwendung prüfen“ angezeigt.
Status der Gesundheitsanwendung auf der eGK: Gesundheitsanwendung Prüffehler	Eine verständliche Fehlermeldung anzeigen und die eGK Sitzung beenden (Kap. 6.1.1.2 AdV-Sitzung beenden).
Mathematische Prüfung des Karteninhaberzertifikats: Zertifikat mathematisch  gültig	Fortfahren und Aufbereitung der Menüstruktur
Mathematische Prüfung des Karteninhaberzertifikats: Zertifikat mathematisch  ungültig oder Prüffehler	Fortfahren und Aufbereitung der Menüstruktur und den Versicherten informieren.
Prüfung auf zeitliche Gültigkeit des Karteninhaberzertifikats: Zertifikat zeitlich gültig	Fortfahren und Aufbereitung der Menüstruktur
Prüfung auf zeitliche Gültigkeit des Karteninhaberzertifikats: Zertifikat zeitlich ungültig oder Prüffehler	Fortfahren und Aufbereitung der Menüstruktur und den Versicherten informieren.
Beschreibung	Plattformbaustein PL_TUC_EGK_STATUS führt die Gültigkeitsprüfung der eGK durch. Zum einen werden Prüfschritte direkt auf der Karte durchführt und andererseits die Legitimität der Karte mittels Onlineabfrage beim Trust Service Provider geprüft.
Verfügbare Anwendungen anzeigen
Beschreibung	Die AdV-App MUSS am Ende des Anwendungsfalls die Menüstruktur der verfügbaren Anwendungsfälle entsprechend dem Status der Fachanwendung und PIN ergänzen. Ist der Ordner DF.HCA gesperrt, sind nur Anwendungsfälle der PIN-Verwaltung für die PIN.CH (Kap. 6.1.5.3, 6.1.5.4) und das Lesen und Aktualisieren der VSD (Kap.6.1.5.1) möglich. Fachanwendungen im Status ABSENT bzw. TERMINATED sind auf der eGK nicht vorhanden bzw. nicht mehr zu verwenden, deren fachspezifische Anwendungsfälle sollten in der AdV-App nicht auswählbar sein. Fachanwendungen im Status AVAILABLE oder HIDDEN sind auf der eGK verfügbar, deren fachspezifische Anwendungsfälle sind je nach vorangegangener Operation logisch sinnvoll (Daten lesen, Anwendung verbergen nur im Zustand AVAILABLE, Anwendung sichtbar machen nur im Zustand HIDDEN) und sollten entsprechend angeboten bzw. temporär nicht auswählbar sein. Wenn die Fachanwendung über eine PIN verfügt: PINs im Zustand DISABLED können über einen Anwendungsfall eingeschaltet werden, PINs im Zustand OK und VERIFIABLE können abhängig von den Zugriffsrechten im Objektsystem der eGK ausgeschaltet werden, PINs im Zustand BLOCKED müssen vor der Verwendung und den Zugriff auf die Fachanwendung entsperrt werden. Fachanwendungsunabhängige Anwendungsfälle dürfen durch den Status der Fachanwendungen nicht eingeschränkt werden und müssen immer verfügbar sein.
Hinweis zur Umsetzung	Je nach Generation der vom Versicherten gesteckten eGK sind verschiedene Fachanwendungscontainer auf der eGK vorhanden. Zusätzlich kann sich der Status der Fachanwendungscontainer vom Zustand „aktiv“ unterscheiden, wodurch die im Folgenden beschriebenen Anwendungsfälle erst zulässig werden oder nicht mehr zulässig sind.

[<=]

AdV-A_2446 - AdV-App: Warnung eGK nicht ziehen

Die AdV-App MUSS den Nutzer warnen, wenn er seine eGK nicht aus dem Kartenterminal entfernen darf (z.B. während Schreibzugriffen/VSD Update) zur Vermeidung von inkonsistenten Zuständen auf der eGK. [<=]

6.1.1.2 AdV-Sitzung beenden

Mit der Umsetzung dieses Anwendungsfalls wird die Sitzung des Versicherten beendet. Der Versicherte kann keine fachlichen Anwendungsfälle bis zum Start einer neuen Sitzung aufrufen. In der AdV-App und dem AdV-Server liegen keine persistent oder temporär gespeicherten, personenbezogenen oder medizinischen Daten des Versicherten vor. Auf dem Display wird eine neutrale Anzeige dargestellt.

AdV-A_2447 - AdV-App: Menüpunkt zum Beenden einer Sitzung

Die AdV-App MUSS dem Nutzer eine Menüoption anbieten, mit der er seine aktuelle Sitzung beenden kann. [<=]

AdV-A_2448 - AdV-App: Ziehen der eGK des Versicherten

Die AdV-App MUSS bei dem Ziehen der eGK des Versicherten die Sitzung des Versicherten sofort beenden. [<=]

AdV-A_2449 - AdV-App: Beenden einer Sitzung in AdV-App

Die AdV-App MUSS das Beenden der Sitzung des angemeldeten Versicherten derart umsetzen, dass ein ggfs. in der Ausführung befindlicher Anwendungsfall – welcher inkonsistente Daten auf der eGK hinterlassen könnte – vor dem Ende der Sitzung abgeschlossen wird. Die AdV-App MUSS zum Beenden der Sitzung

• mit PL_TUC_CARD_RESET ein Reset der gesteckten Karte anfordern,
• die TLS Verbindung zum AdV-Server beenden
• und den Versicherten zum Ziehen der eGK auffordern.

[<=]

AdV-A_2450 - AdV-App: Darstellung einer neutralen Anzeige

Die AdV-App MUSS nach dem Beenden einer Sitzung auf dem Bildschirm eine neutrale Anzeige, insbesondere ohne Daten des Versicherten, darstellen. [<=]

6.1.2 Übergreifende Vorbedingungen

Die ab Kapitel 6.1.5 beschriebenen fachlichen Anwendungsfälle werden durch den Versicherten eigenständig ausgeführt, die AdV-App ruft die dort benannten Operationen nur bei explizitem Wunsch des Versicherten auf. Folgende Vorbedingungen müssen beim Start jedes Anwendungsfalls erfüllt sein.

AdV-A_2451 - AdV-App: Übergreifende Vorbedingung

Die AdV-App MUSS die Zulässigkeit aller Anwendungsfälle in Abhängigkeit von folgenden Kriterien sicherstellen:
 

Tabelle 6: TAB_ADV_320 – Übergreifende Vorbedingungen

[<=]

AdV-A_2452 - AdV-App: Zulässigkeit der Anwendungsfälle

Die AdV-App MUSS die Zulässigkeit des Anwendungsfalls in Abhängigkeit von folgenden Kriterien sicherstellen:
VerificationResult

• K1: Echtheit eGK: Authentic und X.509 (Karteninhaberzertifikat) mathematisch gültig [ja / nein / Prüffehler]
• K2: Status des DF.HCA (Gesundheitsanwendung): [aktiv / nicht aktiv / Prüffehler]
• K3: X.509 (Karteninhaberzertifikat) Gültigkeit: Valid

[TRUE (zeitlich gültig),

FALSE (zeitlich ungültig bzw. Prüffehler)]

• K4: X.509 (Karteninhaberzertifikat) Status: CertificateResult

[OK (Online gültig),

REVOKED (Online gesperrt),

UNKOWN(Onlinestatus unbekannt|Prüffehler)]

Application

• K5: Status der Anwendungen auf der eGK je Anwendung [AVAILABLE, HIDDEN, ABSENT, TERMINATED]
• K6: Status der PINs der eGK je Anwendung

[OK (PasswordEnabledVerified),

BLOCKED (PasswordBlocked),

DISABLED (PasswordDisabled),

VERIFYABLE (PasswordEnabledNotVerified.X)]

 

Tabelle 7: TAB_ADV_384 – Zulässige Anwendungsfälle nach Status von Karte, Anwendung und PIN

[<=]

Definiert eine Fachanwendung in ihrer Fachmodulspezifikation abweichende Kriterien oder von den in TAB_ADV_384 definierten Bedingungen abweichende Vorbedingung zur Zulässigkeit ihrer Anwendungsfälle, so sind jene der Fachanwendung bindend.

6.1.3 Hinweistext zu Fachanwendung

Nach dem Start der AdV-App und Stecken der eGK wird dem Versicherten eine Startoberfläche angezeigt, auf der klar erkennbar ist, welche Art von Daten verwaltet werden können. Hier sollen alle Anwendungen, die aktuell bereitstehen, in übersichtlicher Form angezeigt werden, auch wenn der Versicherte nicht alle Anwendungen nutzt bzw. in bestimmte Anwendungen nicht oder noch nicht eingewilligt hat.

AdV-A_2547 - Empfehlung: Hinweistext zu Fachanwendung

Die AdV-App SOLL im Kontext jeder Fachanwendung einen Hinweistext gemäß TAB_ADV_461 anzeigen, der den Zweck der Fachanwendung beschreibt.
 

Tabelle 8: TAB_ADV_461 – Benennung der Anwendungen und Hinweise am Terminal

[<=]

6.1.4 Generische Anwendungsfälle

Dieses Kapitel beschreibt die generischen Anwendungsfälle, welche durch Anwendungsfälle verschiedener Fachanwendungen genutzt werden. Unter anderem wird die Möglichkeit geboten PIN-Objekte, die im Kontext einer Fachanwendung stehen, ein- oder auszuschalten.

6.1.4.1 Anwendung auf eGK deaktivieren

Der Versicherte kann die Daten einer freiwilligen Anwendung verbergen. Durch das Verbergen ist nur noch für den Versicherten selbst erkennbar, dass die freiwillige Anwendung eingerichtet ist. Die Daten der Fachanwendung sind weiterhin auf der eGK vorhanden, können aber weder angezeigt noch verändert werden.

Die folgende Abbildung ABB_ADV_305 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_14 „Anwendung auf eGK deaktivieren“ ausgeführt werden müssen.

 

Abbildung 7: ABB_ADV_305 – Ablauf „Anwendung auf eGK deaktivieren“

AdV-A_2453 - AdV-UC_14: Anwendung auf eGK deaktivieren

Die AdV-App MUSS den Anwendungsfall AdV-UC_14 „Anwendung auf eGK deaktivieren“ gemäß TAB_ADV_305 umsetzen.

Tabelle 9: TAB_ADV_305 – AdV-UC_14 „Anwendung auf eGK deaktivieren“

Tabelle 10: TAB_ADV_306 – Ablaufaktivitäten – AdV-UC_14

[<=]

6.1.4.2 Anwendung auf eGK reaktivieren

Der Versicherte kann nach vorherigem Verbergen die Daten einer freiwilligen Anwendung wieder sichtbar machen.

Die folgende Abbildung ABB_ADV_383 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_15 „Anwendung auf eGK reaktivieren“ ausgeführt werden müssen.

 

Abbildung 8: ABB_ADV_383 – Ablauf „Anwendung auf eGK reaktivieren“

AdV-A_2454 - AdV-UC_15: Anwendung auf eGK reaktivieren

Die AdV-App MUSS den Anwendungsfall AdV-UC_15 „Anwendung auf eGK reaktivieren“ gemäß TAB_ADV_383 umsetzen.

Tabelle 11: TAB_ADV_383 – AdV-UC_15 „Anwendung auf eGK reaktivieren“

Tabelle 12: TAB_ADV_307 – Ablaufaktivitäten – AdV-UC_15

[<=]

6.1.4.3 PIN-Verwaltung

Auf der eGK des Versicherten sind mehrere PIN-Objekte gespeichert. Wird im Aufruf der PIN-Operationen Ändern und Entsperren der Identifier einer Multireferenz-PIN (MRPIN) übergeben, so wirkt diese Operation auf die referenzierte PIN und betrifft auch alle übrigen Multireferenz-PINs, die auf diese PIN verweisen. Aktuell sind folgende PIN-Referenzen vorgesehen:

• Versicherten-PIN (PIN.CH)
  (auch verwendet als MRPIN.NFD, MRPIN.NFD_READ, MRPIN.DPE, MRPIN.DPE_READ, MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS)
• Vertreter-PIN für eMP/AMTS (PIN.AMTS_REP)

Die oben genannten Multireferenz-PINs können genutzt werden, um die Versicherten-PIN PIN.CH im Kontext der aktuellen Anwendung zu ändern, ohne auf der eGK zunächst in ein anderes Verzeichnis zu navigieren. Das heißt der Anwendungsfall zum Ändern oder Entsperren der Versicherten-PIN darf vom Versicherten im Kontext der jeweils aktiven Fachanwendung erfolgen, wenn der MRPIN der Fachanwendung als PIN-Referenz angegeben wird. Das Einschalten/Ausschalten einer MRPIN wirkt sich jeweils nur auf den MRPIN der referenzierten Fachanwendung aus. Die Benutzeroberfläche muss es dem Versicherten ermöglichen, den Status eines PIN-Objektes zu erfahren. Dies kann über eine Übersicht über alle PIN-Objekte oder in den Anwendungen erfolgen.

AdV-A_2535 - Anzeige des Status eines PIN-Objekts

Die AdV-App MUSS dem Versicherten über die Benutzeroberfläche den aktuellen Status eines ausschaltbaren PIN-Objekts darstellen. [<=]

Die AMTS-Vertreter-PIN darf in den PIN-Operationen nur im Kontext der Fachanwendung AMTS referenziert werden.

6.1.4.3.1 PIN ändern

Mit der Umsetzung dieses Anwendungsfalls ändert der Versicherte eine im Parameter der Operation benannte PIN auf der eGK.

Die folgende Abbildung ABB_ADV_312 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_01: „PIN ändern“ ausgeführt werden müssen.

AdV-A_2458 - AdV-UC_01: PIN ändern

Die AdV-App MUSS den Anwendungsfall AdV-UC_01: „PIN ändern“ gemäß TAB_ADV_312 umsetzen.

Tabelle 13: TAB_ADV_312 – PIN der eGK ändern

Name des Anwendungsfalls	„PIN ändern“
Hinweistext für den Versicherten	Siehe aufrufenden Anwendungsfall der Fachanwendung.
Auslöser	Dieser Anwendungsfall wird nicht direkt vom Versicherten aufgerufen, sondern im Rahmen eines übergeordneten Anwendungsfalls, welche die benötigten Eingangsdaten (den Identifikator des Passwortobjektes) bereitstellt.
Akteure	Versicherter
Vorbedingung	Siehe übergreifende Vorbedingungen.
Nachbedingung	PIN wurde geändert.
Standardablauf	Die Umsetzung ist in „TAB_ADV_313 – Ablaufaktivitäten – PIN ändern“ beschrieben. PL_TUC_CARD_CHANGE_PIN nutzen PL_TUC_CARD_CHANGE_PIN Ergebnis verarbeiten Ergebnis anzeigen
Diagramm	Abbildung ABB_ADV_312 – Ablauf des AdV-UC_01: „PIN ändern“

 

Tabelle 14: TAB_ADV_313 – Ablaufaktivitäten – PIN der eGK ändern

1. PL_TUC_CARD_CHANGE_PIN nutzen
Plattformoperation	PL_TUC_CARD_CHANGE_PIN
Eingangsdaten
Identifikator	Zulässige PIN-Referenzen gemäß PL_TUC_CARD_INFORMATION.<Pin_der_eGK> (z.B. PIN.CH, PIN. AMTS_REP und ggf. weitere, je nach Release der eGK)
Benutzerhinweis am Kartenterminaldisplay (Sicherheitsklasse 3) bzw. im AdV-App-Benutzerinterface bei Aufruf der Umgebungsoperation ENV_TUC_SECRET_INPUT	Für Identifikator in (PIN.CH, MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS)     Alte PIN: „Eingabe alte Versicherten-PIN: “ bzw. Neue PIN: „Eingabe neue Versicherten-PIN: “ Für Identifikator = PIN.AMTS_REP     Alte PIN: „Eingabe Versicherten-PIN: “ bzw. Neue PIN: „Eingabe neue Vertreter-PIN: “
Beschreibung	Der Plattformbaustein wird zur Änderung den PIN genutzt.
2. Rückgabewert von PL_TUC_CARD_CHANGE_PIN verarbeiten
Rückgabedaten
OK	PIN erfolgreich geändert
Fehlerfälle	Siehe Beschreibung PL_TUC_CARD_CHANGE_PIN und „TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine“ für die Behandlung in der AdV-App.
Beschreibung	Das Ändern einer PIN auf der eGK basiert auf der parametrierten Plattformbaustein PL_TUC_CARD_CHANGE_PIN. Diese liefert ein Ergebnis zurück. Zur Änderung muss zwingend die Eingabe der alten PIN (bzw. bei Änderung der PIN.AMTS_REP Eingabe der Versicherten-PIN) erfolgen. Wird durch den Versicherten ein falsches altes PIN-Geheimnis eingegeben, wird die verbleibende Anzahl der Eingabeversuche bis zur Sperrung des PINs zurückgemeldet. Im Fehlerfall wird eine Fehlermeldung entsprechenden Details zurückgegeben.
3. Ergebnis anzeigen
Hinweis an den Versicherten	Die Rückgabedaten des Plattformbausteins enthalten Informationen über den Erfolg der Operation auf der eGK des Versicherten. Im Fehlerfall wird der Versicherte in verständlicher Form über den Fehler informiert. Im Erfolgsfall ist dem Versicherten eine Bestätigung zur Anzeige zu bringen. Falls eine Warnung aufgetreten ist, wird diese dem Versicherten in verständlicher Form angezeigt. Bei einer Fehleingabe der Pin des Versicherten wird dem Versicherten die verbleibende Anzahl der Eingabeversuche bis zur Sperrung der PIN zurückgemeldet.

[<=]

6.1.4.3.2 PIN auf eGK entsperren

Mit der Umsetzung dieses Anwendungsfalls entsperrt der Versicherte eine im Parameter der Operation benannte PIN auf der eGK.

Die folgende Abbildung ABB_ADV_316 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_02: „PIN auf eGK entsperren“ ausgeführt werden müssen.

AdV-A_2459 - AdV-UC_02: PIN der eGK entsperren

Die AdV-App MUSS den Anwendungsfall AdV-UC_02: „PIN der eGK entsperren“ gemäß TAB_ADV_316 umsetzen.

Tabelle 15: TAB_ADV_316 – PIN der eGK entsperren

Benennung des Anwendungsfalls	„PIN der eGK entsperren“
Hinweistext für den Versicherten	Siehe aufrufenden Anwendungsfall der Fachanwendung.
Auslöser	Der Versicherte möchte eine PIN auf seiner eGK entsperren. Dazu wählt er eine Aktion in der AdV-App aus, die das Entsperren startet.
Akteure	Versicherter
Vorbedingung	Siehe übergreifende Vorbedingungen.
Nach-bedingung	PIN des Versicherten wurde entsperrt.
Standardablauf	Die Umsetzung ist in „TAB_ADV_317 – Ablaufaktivitäten – PIN der eGK entsperren“ beschrieben. PL_TUC_CARD_UNBLOCK_PIN aufrufen PL_TUC_CARD_UNBLOCK_PIN Ergebnis verarbeiten Ergebnis anzeigen
Diagramm	Abbildung ABB_ADV_316 – Ablauf des AdV-UC_02: „PIN auf eGK entsperren“

 

Tabelle 16: TAB_ADV_317 – Ablaufaktivitäten – PIN der eGK entsperren

1. PL_TUC_CARD_UNBLOCK_PIN aufrufen
Plattformbaustein	PL_TUC_CARD_UNBLOCK_PIN
Eingangsdaten
Identifikator	Zulässige PIN-Referenzen gemäß PL_TUC_CARD_INFORMATION.<Pin_der_eGK> (z.B. PIN.CH, PIN.AMTS_REP und ggf. weitere, je nach Release der eGK)
Benutzerhinweis am Kartenterminaldisplay (Sicherheitsklasse 3) bzw. im AdV-App-Benutzerinterface bei Aufruf der Umgebungsoperation ENV_TUC_SECRET_INPUT	Für Identifikator in (PIN.CH, MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS)     PUK: „Eingabe PUK: “ bzw. Neue PIN: „Eingabe neue Versicherten-PIN: “ Für Identifikator = PIN.AMTS_REP     PIN.CH: „Eingabe Versicherten-PIN: “ bzw. Neue PIN: „Eingabe neue Vertreter-PIN: “
Beschreibung	Für das Entsperren der PIN wird ein Plattformbaustein genutzt.
2. PL_TUC_CARD_UNBLOCK_PIN Ergebnis verarbeiten
Rückgabedaten
OK	PIN wurde entsperrt.
PasswordBlocked	Die PUK wurde wegen zu häufiger Nutzung gesperrt. Der Versicherte muss darüber in verständlicher Form informiert und auf die Notwendigkeit einer neuen eGK hingewiesen werden.
Weitere Fehlerfälle	Siehe Beschreibung PL_TUC_CARD_UNBLOCK_PIN und „TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine“ für die Behandlung in der AdV-App.
Beschreibung	Das Entsperren einer PIN auf der eGK basiert auf dem parametrierten Plattformbaustein PL_TUC_CARD_UNBLOCK_PIN. Zum Entsperren muss zwingend die Eingabe einer PUK bzw. im Fall des Entsperren der PIN.AMTS_REP die Eingabe der Versicherten-PIN erfolgen. Wird durch den Versicherten ein falsches PIN- bzw. PUK-Geheimnis eingegeben, wird die verbleibende Anzahl der Eingabeversuche bis zur Sperrung des PUKs bzw. PINs zurückgemeldet. Im Fehlerfall wird eine Fehlermeldung mit entsprechenden Details zurückgegeben.
3. Ergebnis anzeigen
Hinweis an den Versicherten	Die Rückgabedaten des Plattformbausteins enthalten Informationen über den Erfolg der Operation auf der eGK des Versicherten. Im Fehlerfall wird der Versicherte in verständlicher Form über den Fehler informiert. Im Erfolgsfall ist dem Versicherten eine Bestätigung zur Anzeige zu bringen. Falls eine Warnung aufgetreten ist, wird diese dem Versicherten in verständlicher Form angezeigt.

[<=]

6.1.4.3.3 PIN für Fachanwendung einschalten

Wenn die Multireferenz-PIN einer Fachanwendung deaktiviert ist, dann kann der Versicherte diese PIN mit diesem Anwendungsfall aktivieren.

Die folgende Abbildung ABB_ADV_308 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_03 „PIN für Fachanwendung einschalten“ ausgeführt werden müssen.

 

Abbildung 9: ABB_ADV_308 – Ablauf AdV-UC_03 „PIN für Fachanwendung einschalten“

AdV-A_2455 - AdV-UC_03 „PIN für Fachanwendung einschalten“

Die AdV-App MUSS den Anwendungsfall AdV-UC_03 „PIN für Fachanwendung einschalten“ gemäß TAB_ADV_308 umsetzen.

Tabelle 17: TAB_ADV_308 – AdV-UC_03 „PIN für Fachanwendung einschalten“

Benennung des Anwendungsfalls	„PIN für Fachanwendung einschalten“
Hinweistext für den Versicherten	Ein konkreter Hinweistext für den Versicherten wird für jede Fachanwendung im aufrufenden Anwendungsfall festgelegt.
Auslöser	Der Anwendungsfall wird ausgelöst, wenn der Versicherte auf seiner eGK die Benutzerverifikation einer Fachanwendung einschalten will. Dazu nutzt die Fachanwendung vorliegenden generischen Anwendungsfall.
Akteure	Dieser Anwendungsfall wird nicht direkt vom Versicherten aufgerufen sondern im Rahmen eines übergeordneten Anwendungsfalls einer Fachanwendung, welche die benötigten Eingangsdaten (bspw. den Identifikator des PIN-Objektes) bereitstellt.
Vorbedingung	Die Fachanwendung übergibt den Identifikator des Passwortobjektes. Siehe auch übergreifende Vorbedingungen.
Nachbedingung	Benutzerverifikation ist aktiviert.
Standardablauf	Die Umsetzung ist in „TAB_ADV_309 – Ablaufaktivitäten – AdV-UC_03“ beschrieben. PL_TUC_CARD_ENABLE_PIN aufrufen PL_TUC_CARD_ENABLE_PIN Ergebnis verarbeiten Ergebnis anzeigen
Diagramm	Abbildung ABB_ADV_308 – Ablauf AdV-UC_03 „PIN für Fachanwendung einschalten“

Tabelle 18: TAB_ADV_309 – Ablaufaktivitäten – AdV-UC_03

1. PL_TUC_CARD_ENABLE_PIN aufrufen
Plattformbaustein	PL_TUC_CARD_ENABLE_PIN
Eingangsdaten
Identifikator	Zulässige PIN-Referenzen gemäß PL_TUC_CARD_INFORMATION.<Pin_der_eGK> (z.B. MRPIN.NFD, MRPIN.DPE, MRPIN.GDD, MRPIN.AMTS und ggf. weitere, je nach Release der eGK)
Benutzerhinweis am Kartenterminaldisplay (Sicherheitsklasse 3) bzw. im AdV-App-Benutzerinterface bei Aufruf der Umgebungsoperation ENV_TUC_SECRET_INPUT	Für Identifikator in (MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS)     MRPIN.NFD: „PIN-Schutz für Notfalldaten einschalten - Versicherten-PIN: “     MRPIN.DPE: „PIN-Schutz für Pers. Erklärungen einschalten - Versicherten-PIN: “     MRPIN.AMTS: „PIN-Schutz für Medikationsplan einschalten - Versicherten-PIN: “
Beschreibung	Für die Aktivierung der Benutzerverifikation wird der Plattformbaustein genutzt.
2. PL_TUC_CARD_ENABLE_PIN Ergebnis verarbeiten
Rückgabedaten
OK	PIN erfolgreich eingeschaltet
Fehlerfälle	Siehe Beschreibung PL_TUC_CARD_ENABLE_PIN und „TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine“ für die Behandlung in der AdV-App.
Beschreibung	Das Aktivieren der Benutzerverifikation basiert auf dem parametrierten Plattformbaustein PL_TUC_CARD_ENABLE_PIN. Dieser liefert eine Statusmeldung zurück. Im Fehlerfall wird eine Fehlermeldung mit entsprechenden Details zurückgegeben. Wird durch den Versicherten ein falsches PIN-Geheimnis eingegeben, wird die verbleibende Anzahl der Eingabeversuche bis zur Sperrung des PINs zurückgemeldet. Im Fehlerfall wird eine Fehlermeldung mit entsprechenden Details zurückgegeben.
3. Ergebnis anzeigen
Hinweis an den Versicherten	Die Rückgabedaten des Plattformbausteins enthalten Informationen über den Erfolg der Operation auf der eGK des Versicherten. Im Fehlerfall wird der Versicherte in verständlicher Form über den Fehler informiert. Im Erfolgsfall ist dem Versicherten eine Bestätigung zur Anzeige zu bringen. Falls eine Warnung aufgetreten ist, wird diese dem Versicherten in verständlicher Form angezeigt. Bei einer Fehleingabe der Pin des Versicherten wird dem Versicherten die verbleibende Anzahl der Eingabeversuche bis zur Sperrung der PIN zurückgemeldet.

[<=]

6.1.4.3.4 PIN für Fachanwendung ausschalten

Um die Anzahl der beim Leistungserbringer notwendigen PIN-Eingaben pro Kartensteckzyklus zu minimieren, kann der Versicherte für bestimmte Fachanwendungen die Multireferenz-PIN für diese Fachanwendung deaktivieren.

Die folgende Abbildung ABB_ADV_310 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_04 „PIN für Fachanwendung ausschalten“ ausgeführt werden müssen.

 

Abbildung 10: ABB_ADV_310 – Ablauf AdV-UC_04 „PIN für Fachanwendung ausschalten“

AdV-A_2456 - AdV-UC_04 Hinweis bei ausgeschaltetem PIN

Die AdV-App MUSS, wenn der Versicherte den PIN einer Anwendung ausschalten möchte, dem Versicherten einen Hinweis anzeigen, dass bei ausgeschalteter PIN ein Arzt oder Apotheker auf die Daten dieser Anwendung ohne die Eingabe einer PIN zugreifen kann. [<=]

AdV-A_2457 - AdV-UC_04 „PIN für Fachanwendung ausschalten“

Die AdV-App MUSS den Anwendungsfall AdV-UC_04 „PIN für Fachanwendung ausschalten“ gemäß TAB_ADV_310 umsetzen.

Tabelle 19: TAB_ADV_310 – AdV-UC_04 „PIN für Fachanwendung ausschalten“

Name des Anwendungsfalls	„PIN für Fachanwendung ausschalten“
Hinweistext für den Versicherten	Ein konkreter Hinweistext für den Versicherten wird für jede Fachanwendung im aufrufenden Anwendungsfall festgelegt.
Auslöser	Der Anwendungsfall wird ausgelöst, wenn der Versicherte auf seiner eGK die Benutzerverifikation einer Fachanwendung ausschalten will. Dazu nutzt die Fachanwendung vorliegenden generischen Anwendungsfall.
Akteure	Dieser Anwendungsfall wird nicht direkt vom Versicherten aufgerufen sondern im Rahmen eines übergeordneten Anwendungsfalls einer Fachanwendung, welche die benötigten Eingangsdaten (den Identifikator des PIN-Objektes) bereitstellt.
Vorbedingung	MRPIN der Fachanwendung auf der eGK ist ausschaltbar. Die Fachanwendung übergibt den Identifikator des Passwortobjektes. Siehe auch übergreifende Vorbedingungen.
Nachbedingung	Benutzerverifikation ist deaktiviert.
Standardablauf	Die Umsetzung ist in „TAB_ADV_311 – Ablaufaktivitäten – AdV-UC_04“ beschrieben. PL_TUC_CARD_DISABLE_PIN aufrufen PL_TUC_CARD_DISABLE_PIN Ergebnis verarbeiten Ergebnis anzeigen
Diagramm	Abbildung ABB_ADV_310 – Ablauf AdV-UC_04 „PIN für Fachanwendung ausschalten“

Tabelle 20: TAB_ADV_311 – Ablaufaktivitäten – AdV-UC_04

1. PL_TUC_CARD_DISABLE_PIN aufrufen
Plattformbaustein	PL_TUC_CARD_DISABLE_PIN
Eingangsdaten
Identifikator	Zulässige PIN-Referenzen sind MRPIN.NFD, MRPIN.DPE, MRPIN.GDD, MRPIN.AMTS und ggf. weitere, je nach Ausprägung der eGK.
Benutzerhinweis am Kartenterminaldisplay (Sicherheitsklasse 3) bzw. im AdV-App-Benutzerinterface bei Aufruf der Umgebungsoperation ENV_TUC_SECRET_INPUT	Für Identifikator in (MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS)     MRPIN.NFD: „PIN-Schutz für Notfalldaten ausschalten - Versicherten-PIN: “     MRPIN.DPE: „PIN-Schutz für Pers. Erklärungen ausschalten - Versicherten-PIN: “     MRPIN.AMTS: „PIN-Schutz für Medikationsplan ausschalten - Versicherten-PIN: “
Beschreibung	Für die Deaktivierung der Benutzerverifikation wird der Plattformbaustein genutzt.
2. PL_TUC_CARD_DISABLE_PIN Ergebnis verarbeiten
Rückgabedaten
OK	PIN erfolgreich abgeschaltet
Fehlerfälle	Siehe Beschreibung PL_TUC_CARD_DISABLE_PIN und „TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine“ für die Behandlung in der AdV-App.
Beschreibung	Das Deaktivieren der Benutzerverifikation basiert auf dem parametrierten Plattformbaustein PL_TUC_CARD_DISABLE_PIN. Dieser liefert eine Statusmeldung zurück. Im Fehlerfall wird eine Fehlermeldung mit entsprechenden Details zurückgegeben. Wird durch den Versicherten ein falsches PIN-Geheimnis eingegeben, wird die verbleibende Anzahl der Eingabeversuche bis zur Sperrung des PINs zurückgemeldet. Im Fehlerfall wird eine Fehlermeldung mit entsprechenden Details zurückgegeben.
3. Ergebnis anzeigen
Hinweis an den Versicherten	Die Rückgabedaten des Plattformbausteins enthalten Informationen über den Erfolg der Operation auf der eGK des Versicherten. Im Fehlerfall wird der Versicherte in verständlicher Form über den Fehler informiert. Im Erfolgsfall ist dem Versicherten eine Bestätigung zur Anzeige zu bringen. Falls eine Warnung aufgetreten ist, wird diese dem Versicherten in verständlicher Form angezeigt. Bei einer Fehleingabe der Pin des Versicherten wird dem Versicherten die verbleibende Anzahl der Eingabeversuche bis zur Sperrung der PIN zurückgemeldet.

[<=]

6.1.5 Verwaltung der eGK

6.1.5.1 VSD von eGK anzeigen

Mit der Umsetzung dieses Anwendungsfalls werden dem Versicherten die auf seiner eGK gespeicherten Versichertenstammdaten zur Anzeige gebracht.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_101: „VSD von eGK lesen“ ausgeführt werden müssen.

 

Abbildung 11: ABB_ADV_317 - Ablauf des „VSD von eGK lesen”

AdV-A_2460 - AdV-App: VSD von eGK anzeigen

Die AdV-App MUSS den Anwendungsfall „VSD von eGK anzeigen“ gemäß TAB_ADV_314 umsetzen.

Tabelle 21: TAB_ADV_314 – VSD von eGK anzeigen

 

Tabelle 22: TAB_ADV_315 – Ablaufaktivitäten – VSD von eGK anzeigen

[<=]

6.1.5.2 Zugriffsprotokoll anzeigen

Mit der Umsetzung dieses Anwendungsfalls sollen dem Versicherten das auf seiner eGK gespeicherte Zugriffsprotokoll zur Anzeige gebracht werden.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_21: „Zugriffprotokoll von eGK lesen“ ausgeführt werden müssen.

 

Abbildung 12: ABB_ADV_314 – Ablauf des AdV-UC_21: „Zugriffsprotokoll anzeigen“

AdV-A_2461 - AdV-App: Decodierung von Schlüsselwerten im Zugriffsprotokoll

Die AdV-App MUSS zur besseren Lesbarkeit die Schlüsselwerte in den Zugriffsprotokolleinträgen gemäß [gemSpec_Karten_Fach_TIP#Tab_Karten_Fach_TIP_010_StrukturEF.Logging] decodieren und in für den Versicherten verständlichen Text übersetzen. [<=]

AdV-A_2462 - AdV-App: Decodierung von Schlüsselwerten im Zugriffsprotokoll – Fachmodul

Die AdV-App MUSS zur besseren Lesbarkeit die Schlüsselwerte in den Zugriffsprotokolleinträgen gemäß der jeweiligen Festlegung der Fachmodule der Fachanwendungen (Fachmodulspezifikation) decodieren und in einen für den Versicherten verständlichen Text übersetzen. [<=]

AdV-A_2463 - AdV-App: Zugriffsprotokoll anzeigen

Die AdV-App MUSS den Anwendungsfall „Zugriffsprotokoll anzeigen“ gemäß TAB_ADV_350 umsetzen.

Tabelle 23: TAB_ADV_350 – Zugriffsprotokoll anzeigen

Benennung des Anwendungsfalls	„Zugriffsprotokoll anzeigen“
Hinweistext für den Versicherten	Anhang A6#TAB_ADV_473#ADV002
Auslöser	Der Versicherte möchte das Zugriffsprotokoll seiner eGK anzeigen lassen. Dazu wählt er eine Aktion in der AdV-App aus, die das Auslesen des Protokolls startet.
Akteure	Versicherter
Vorbedingung	Siehe übergreifende Vorbedingungen.
Nachbedingung	Das Zugriffsprotokoll wird dem Versicherten angezeigt.
Standardablauf	Die Umsetzung ist in „TAB_ADV_351 – Ablaufaktivitäten – Zugriffsprotokoll anzeigen“ beschrieben. LeseRequest erzeugen LeseResponse verarbeiten Protokoll anzeigen
Diagramm	Abbildung ABB_ADV_314 – Ablauf des AdV-UC_21: „Zugriffsprotokoll anzeigen“

 

Tabelle 24: TAB_ADV_351 – Ablaufaktivitäten – Zugriffsprotokoll anzeigen

1. LeseRequest erzeugen
Plattformbaustein	PL_TUC_EGK_READ_PROTOCOL
Eingangsdaten
-	-
Beschreibung	Es wird das gesamte Zugriffsprotokoll auf der elektronischen Gesundheitskarte ausgelesen.
2. LeseResponse verarbeiten
Rückgabedaten
OK + Liste	„Daten wurden erfolgreich gelesen“ Beinhaltet das Zugriffsprotokoll. Den Aufbau zeigt die folgende Abbildung und wird in [gemSpec_Karten_Fach_TIP] definiert.
CorruptDataWarning +Liste	„Daten gelesen, Speicher möglicherweise defekt ” Beinhaltet das Zugriffsprotokoll. Den Aufbau zeigt die Abbildung oben.
Beschreibung	Das Auslesen des Zugriffsprotokolls auf der eGK basiert auf dem Plattformbaustein PL_TUC_EGK_READ_PROTOCOL. Dieser liefert den Status der Leseoperation und im Erfolgsfall die Recordliste zurück. Im Fehlerfall wird eine Fehlermeldung mit einem Fehlercode zurückgegeben.
3. Protokoll anzeigen
Zugriffsprotokoll zur Anzeige bringen	Die aus der eGK des Versicherten gelesenen Protokolleinträge sollen dem Versicherten vollständig zur Anzeige gebracht werden. Dazu sind sämtliche Elemente vom Typ LogEntry in einer geeigneten Form anzuzeigen. Das Protokoll umfasst bis zu 50 Einträge. Die im Protokoll enthaltenen Felder haben dabei die folgende Bedeutung: Timestamp:        Zeitpunkt, zu dem der Protokolleintrag erzeugt wurde Data Type:        Identifikator der Anwendung auf der eGK, auf die zugegriffen wurde Type of Access:        Art des Zugriffs auf die Anwendung auf der eGK Actor-ID:        Identifikator des Akteurs, des Zugriffs auf die Anwendung auf der eGK Actor Name:        Klarname des Akteurs, des Zugriffs auf die Anwendung auf der eGK

[<=]

AdV-A_2464 - AdV-App: Filtern von Protokolleinträgen

Die AdV-App MUSS es dem Versicherten ermöglichen, die angezeigten Einträge des Zugriffsprotokolls nach Anwendung, Art des Zugriffs, Zeitraum und zugreifendem Akteur zu filtern. [<=]

6.1.5.3 Versicherten-PIN ändern

Mit diesem Anwendungsfall kann der Versicherte das Geheimnis der Versicherten-PIN ändern.

Für die Umsetzung wird der in Kap. 6.1.4.3.1 PIN ändern beschriebene generische Anwendungsfall genutzt.

AdV-A_2465 - AdV-App: Versicherten-PIN ändern

Die AdV-App MUSS den Anwendungsfall „Versicherten-PIN ändern“ gemäß TAB_ADV_352 umsetzen.

Tabelle 25: TAB_ADV_352 – Versicherten-PIN der eGK ändern

Benennung des Anwendungsfalls	„Versicherten-PIN ändern“
Hinweistext für den Versicherten	Anhang A6#TAB_ADV_473#ADV003
Auslöser	Der Versicherte möchte die Versicherten-PIN auf seiner eGK ändern. Dazu wählt er eine Aktion in der AdV-App aus, die das Ändern startet.
Akteure	Versicherter
Vorbedingung	Siehe übergreifende Vorbedingungen.
Nach-bedingungNachbedingung	PIN wurde geändert.
Umsetzung	Gemäß Beschreibung des Anwendungsfalls AdV-UC_01: „PIN ändern“ mit dem Parameter Identifikator = PIN.CH

[<=]

6.1.5.4 Versicherten-PIN entsperren

Mit der Umsetzung dieses Anwendungsfalls kann die gesperrte Versicherten-PIN entsperrt werden.

Für die Umsetzung wird der in Kap. 6.1.4.3.2 PIN auf eGK entsperren beschriebene generische Anwendungsfall genutzt.

AdV-A_2466 - AdV-App: Versicherten-PIN entsperren

Die AdV-App MUSS den Anwendungsfall „Versicherten-PIN entsperren“ gemäß TAB_ADV_353 umsetzen.

Tabelle 26 TAB_ADV_353 – Versicherten-PIN entsperren

Benennung des Anwendungsfalls	„Versicherten-PIN entsperren“
Hinweistext für den Versicherten	Anhang A6#TAB_ADV_473#ADV004
Auslöser	Der Versicherte möchte seine gesperrte Versicherten-PIN entsperren. Dazu wählt er eine Aktion in der AdV-App aus, die das Entsperren startet.
Akteure	Versicherter
Vorbedingung	Siehe übergreifende Vorbedingungen.
Nach-bedingungNachbedingung	Die Versicherten-PIN auf der eGK ist entsperrt.
Standardablauf	Die Umsetzung ist in der Tabelle TAB_ADV_354 – Ablaufaktivitäten – Versicherten-PIN entsperren beschrieben. Abfrage Kenntnis PUK Ergebnis Abfrage Kenntnis PUK verarbeiten Gemäß Beschreibung AdV-UC_02: „PIN auf eGK entsperren“

 

Tabelle 27: TAB_ADV_354 – Ablaufaktivitäten – Versicherten-PIN entsperren

1. Abfrage Kenntnis PUK
Beschreibung	Die AdV-App MUSS den Versicherten vor einem Versuch der Entsperrung fragen, ob der PUK bekannt ist
2. Ergebnis Abfrage Kenntnis PUK verarbeiten
Rückgabedaten
JA (Dem Versicherten ist der PUK bekannt.)	Aufruf des folgenden Schritts im Standardablauf.
NEIN (Dem Versicherten ist der PUK nicht bekannt.)	Den Versicherten darüber informieren, dass die eGK nur mit dem PUK entsperrt werden kann. Zusätzlich soll ein Hinweis gegeben werden, wie der der Versicherte den PUK erhalten hat und wie er ihn ggf. erneut erhalten kann. Falls eine AdV-Sitzung aktiv ist, muss anschließend der Anwendungsfall "AdV-Sitzung beenden" aufgerufen werden.
3. Umsetzung entsprechend AdV-UC_02: „PIN der eGK entsperren“
Beschreibung	Die weitere Umsetzung erfolgt gemäß der Beschreibung des Anwendungsfalls AdV-UC_02: „PIN der eGK entsperren“ mit dem Parameter Identifikator = PIN.CH

[<=]

AdV-A_2467 - AdV-App: AdV-UC_02: Abbruch der AdV-Sitzung

Die AdV-App MUSS, falls die PIN.CH nicht erfolgreich entsperrt wurde und eine AdV-Sitzung aktiv ist, den Anwendungsfall "AdV-Sitzung beenden" aufrufen. [<=]

6.1.5.5 Datenübertragung bei Kartentausch

Dieser Anwendungsfall erlaubt dem Versicherten, Daten von seiner eGK auf eine weitere, d.h. ihm neu ausgestellte eGK zu kopieren. Mit der Umsetzung dieses Anwendungsfalls kann der Versicherte seine Daten – welche in der KTR Umgebung zugreifbar sind – auf eine neue eGK übertragen, wenn der Versicherte von seiner Krankenversicherung eine neue Karte ausgestellt bekommt.

Der Versicherte kann die Datenbereiche auswählen, deren Daten er auf die Zielkarte übertragen will. Dafür muss der Datenbereich dieser Anwendung(en) auf der Zielkarte leer sein. In einer Datenübertragung können ein oder mehrere Datenbereiche übertragen werden. Der Versicherte kann die Datenübertragung erneut durchführen, solange noch nicht alle Datenbereiche übertragen wurden.

Zum Zeitpunkt der Erstellung dieser Spezifikation kann in der KTR-AdV nur der Datenbereich DPE ausgewählt werden.

Die unten beschriebene Lösung sieht vor, dass am KTR-AdV-Terminal für die eGK nur ein Slot zur Verfügung steht, so dass die beiden eGKs nacheinander gesteckt werden müssen. In diesem Ausnahmefall dürfen die medizinischen Daten des Versicherten über den Steckzyklus der Quellkarte hinaus in der AdV-App gespeichert werden. Nach dem Ende des Vorgangs müssen die Daten gelöscht werden.

Die AdV-App steuert den Ablauf der Datenübertragung vom Lesen der Daten von der Quellkarte über den Wechsel der Karten bis zum Schreiben auf die neue Karte und Löschen der zwischengespeicherten Daten. Für die anwendungsspezifischen Lese- und Schreiboperationen ruft es interne Methoden der entsprechenden Fachmodule auf.

Die Datenübertragung soll auch dann möglich sein, wenn das AUT-Zertifikat der Quellkarte zeitlich abgelaufen oder online ungültig ist. Daher muss die AdV-App eine eGK auch in diesem Fall akzeptieren.

Bei den folgenden Beschreibungen wird angenommen, dass zu Beginn die Quellkarte steckt. Dies kann die AdV-App jedoch erst prüfen, wenn die Zielkarte gesteckt wurde und ihr AUT-Zertifikat ein neueres Gültigkeitsbeginn-Datum aufweist als das der anderen eGK.

Falls das Gültigkeitsbeginn-Datum der Zielkarte kleiner als das Gültigkeitsbeginn-Datum der Quellkarte ist, wird die Kopieroperation abgebrochen. Weiterhin führt zum Abbruch, wenn die Zielkarte mathematisch oder zeitlich ungültig ist oder gesperrt wurde.

AdV-A_2548 - Auswahl der zu kopierenden Daten durch den Versicherten

Die AdV-App MUSS beim Start des Anwendungsfalls Datenübertragung bei Kartentausch und vor den Kopier-Operationen die Liste der zu kopierenden Anwendungen beim Versicherten abfragen. Dem Versicherten ist dafür die Liste der in der KTR Umgebung zugreifbaren und kopierbaren Anwendungen zur Auswahl anzubieten. [<=]

AdV-A_2549 - Reaktion auf Kartenevents während Anwendungsfall Datenübertragung bei Kartentausch

Die AdV-App MUSS, falls der Anwendungsfall "Datenübertragung bei Kartentausch durchführen“ umgesetzt wird, während der gesamten Datenübertragung sicherstellen, dass die KVNR (Unveränderbarer Teil) der Quell- und Ziel-Karte mit der zum Beginn der Sitzung temporär gespeicherten KVNR (Unveränderbarer Teil) der Quell-Karte übereinstimmt und bei Ungleichheit die Sitzung nach Hinweis abbrechen. [<=]

AdV-A_2550 - Aufrechterhaltung der Sitzung des Versicherten bei gezogener Karte während Anwendungsfall Datenübertragung bei Kartentausch

Die AdV-App MUSS, falls der Anwendungsfall "Datenübertragung bei Kartentausch durchführen“ umgesetzt wird und während des Anwendungsfalls die eGK des Versicherten aus dem Kartenterminal gezogen wird ohne dass der Versicherte die Operation explizit abbricht, die Sitzung des Versicherten für zwei Minuten aufrecht erhalten. [<=]

AdV-A_2551 - Keine Neuanmeldung des Versicherten bei Stecken der eGK während Anwendungsfall Datenübertragung bei Kartentausch

Die AdV-App MUSS, falls der Anwendungsfall "Datenübertragung bei Kartentausch durchführen“ umgesetzt wird und während des Anwendungsfalls eine neue eGK mit derselben KVNR (Unveränderbarer Teil) des angemeldeten Versicherten in das Kartenterminal gesteckt wird, die aktuelle Sitzung des Versicherten für diese Karte übernehmen. [<=]

AdV-A_2552 - Anzeige einer Aufforderung zum Kartenwechsel

Die AdV-App MUSS, falls der Anwendungsfall "Datenübertragung bei Kartentausch durchführen“ umgesetzt wird, dem Versicherten eine Aufforderung zum Kartenwechsel anzeigen, wenn während der Ausführung des Anwendungsfalls Datenübertragung ein Kartentausch von der Quell- zur Ziel-Karte nötig ist. [<=]

 

Abbildung 13: ABB_ADV_315 Standardablauf – Datenübertragung bei Kartentausch durchführen

AdV-A_2553 - AdV-App: Datenübertragung bei Kartentausch durchführen

Die AdV-App KANN den Anwendungsfall "Datenübertragung bei Kartentausch durchführen" gemäß TAB_ADV_324 umsetzen.

Tabelle 28: TAB_ADV_324 – Datenübertragung bei Kartentausch durchführen

Benennung des Anwendungsfalls	„Datenübertragung bei Kartentausch“
Hinweistext für den Versicherten	Anhang A6#TAB_ADV_473#ADV005
Auslöser	Der Versicherte möchte Daten von seiner alten eGK auf seine neue eGK übertragen. Dazu wählt er eine Aktion in der AdV-App aus, die das Kopieren startet.
Akteure	Versicherter
Vorbedingung	Siehe übergreifende Vorbedingungen und Quell- und Zielkarte (eGK) sind für den selben Versicherten personalisiert Die Zielkarte ist neuer als die Quellkarte. eGK Zielkarte: X.509 (Karteninhaberzertifikat) ist mathematisch und zeitlich gültig eGK Zielkarte: X.509 (Karteninhaberzertifikat) ist Online gültig oder Onlinestatus unbekannt Auf der Zielkarte sind die ausgewählten Datenbereiche leer (falls ein Datenbereich gefüllt ist, liefert putData einen Fehler).
Nachbedingung	Anwendungsdaten auf neue eGK übertragen. In EF.Logging der Zielkarte befindet sich je bearbeiteter Anwendung ein neuer Eintrag, der dokumentiert, dass die Daten dieser Anwendung aus der Übernahme von einer anderen eGK des Versicherten stammen. Auf der Quellkarte sind die bearbeiteten Anwendungen verborgen Auf der Zielkarte haben die erfolgreich bearbeiteten Anwendungen den Status (verbogen/sichtbar) der Quellkarte. Tritt ein Fehler beim Schreiben auf die Zielkarte auf, wird der Ausgangsstatus der betroffenen Anwendung auf der Zielkarte wiederhergestellt.
Standardablauf	Die Umsetzung ist in der Tabelle TAB_ADV_325 – Ablaufaktivitäten – Datenübertragung bei Kartentausch durchführen beschrieben. Liste der zu kopierenden Anwendungen abfragen Prüfdaten speichern Daten der Quell-eGK lesen Kartenwechsel AdV-Sitzung initialisieren Prüfdaten abgleichen Daten auf Ziel-eGK schreiben Abschluss der Kopieroperation AdV-Statusmeldung anzeigen
Diagramm	ABB_ADV_315 Standardablauf – Datenübertragung bei Kartentausch durchführen

 

Tabelle 29: TAB_ADV_325 – Ablaufaktivitäten – Datenübertragung bei Kartentausch durchführen

1. Liste der zu kopierenden Anwendungen abfragen
Anzeige einer Auswahlliste	Dem Versicherten ist eine Liste der auf der eGK vorhandenen und in der KTR-AdV zugreifbaren - medizinischen Anwendungen anzuzeigen. Durch Markieren der zu kopierenden Anwendungen wählt der Versicherte diejenigen aus, deren Daten von einer alten auf eine neue eGK kopiert werden sollen.
2. Prüfdaten speichern
Daten der Quell-eGK in der AdV-App speichern	ICCSN der Karte KVNR (Unveränderbarer Teil) des Versicherten Gültigkeitsdatum des AUT-Zertifikats Version des Objektsystems der eGK
Beschreibung	Die Daten der Quell-eGK werden für die spätere Prüfung der Ziel-eGK zwischengespeichert.
3. Daten der Quell-eGK lesen
Eingangsdaten
n*[Application]	Liste der Bezeichner der zu kopierenden Fachanwendungen Zulässige Bezeichner sind: DF.DPE
Beschreibung	Schleife über alle in den Eingangsparametern angegebenen Anwendungen: {     1. Anwendungstatus speichern und danach ggf. die Anwendung sichtbar machen durch Aufruf von         Anwendungsfall „Anwendung auf eGK reaktivieren“ mit dem Identifikator = Bezeichner der Anwendung     2. getData(             objsysVersion,             application         );     3. Daten der Anwendung im Arbeitsspeicher der AdV-App ablegen     4. Falls die Anwendungsdaten fehlerfrei gelesen und abgelegt wurden: Anwendung deaktivieren          Aufruf von Plattformbaustein PL_TUC_CARD_DEACTIVATE_APPLICATION mit dem Parameter Identifikator = Bezeichner der Anwendung     5. Falls ein Aufruf mit einem Fehler beendet wird (z.B. weil keine Daten auf der Quell-eGK vorhanden sind), so wird der Fehler, den AdV vom aufgerufenen Fachmodul erhalten hat, in verständlicher Form in die im letzten Schritt anzuzeigende AdV-Statusmeldung eingefügt.         Für dieses Element wird putData zum Schreiben der Daten auf die Ziel-eGK nicht aufgerufen. Wenn für alle zu kopierenden Elemente ein Fehler vom Fachmodul gemeldet wurde, wird der Anwendungsfall mit Punkt 9 Abschluss der Kopieroperation fortgesetzt. }
4. Kartenwechsel
Beschreibung	Quellkarte auswerfen: Der Versicherte wird zum Ziehen der Quellkarte aufgefordert. Wenn nach einem Timeout von 2 Minuten die Quellkarte nicht gezogen wurde, dann wird mit Punkt 9 Abschluss der Kopieroperation fortgesetzt. Neue eGK anfordern: Der Versicherte wird zum Stecken seiner neuen eGK aufgefordert.
5. AdV-Sitzung initialisieren
Beschreibung	Wenn neue Karte gesteckt wurde, dann werden alle Schritte zum Initialisieren der neuen Kartensitzung gemäß AdV-A_2445 – ohne Verlassen des aktuellen Anwendungsfalls - durchgeführt. Wenn nach einem Timeout von 2 Minuten keine neue Karte gesteckt wurde, dann wird die Operation mit Punkt 9 Abschluss der Kopieroperation fortgesetzt.
6. Prüfdaten abgleichen
Beschreibung	Prüfdaten der neuen eGK mit denen der alten eGK vergleichen: Wenn ICCSNalt = ICCSNneu, dann Abbruch der Operation mit der Fehlermeldung "Sie haben zweimal die selbe Karte verwendet, bitte wiederholen Sie den Vorgang mit der alten und der neuen Gesundheitskarte.". Wenn KVNRalt <> KVNRneu (Karteninhaber nicht identisch), dann Abbruch mit der Fehlermeldung "Die neue Gesundheitskarte ist für einen anderen Versicherten ausgestellt. Bitte wiederholen Sie den Vorgang mit Ihrer neuen Gesundheitskarte.".  Hinweis: Der unveränderbare Teil der KVNR wird verglichen. Sei validfrom das Gültigkeitsbeginn-Datum des X.509-AUT-Zertifikats. Wenn validfromneu < validfromalt, dann Abbruch mit der Fehlermeldung "Falsche Reihenfolge. Bitte wiederholen Sie den Vorgang mit Ihrer alten Gesundheitskarte und stecken Sie dann erst Ihre neue Gesundheitskarte.". Prüfung der Gültigkeit des Karteninhaberzertifikat der eGK Zielkarte (Falls die eGK nicht den Gültigkeitskriterien entspricht wird mit der Fehlermeldung "Die Zielkarte ist nicht gültig, bitte wenden Sie sich an Ihre Krankenkasse." abgebrochen): eGK Zielkarte: X.509 (Karteninhaberzertifikat) ist mathematisch und zeitlich gültig (PL_TUC_EGK_STATUS # Mathematische Gültigkeit & Gültigkeit zu Referenzzeitpunkt) eGK Zielkarte: X.509 (Karteninhaberzertifikat) ist Online gültig oder Onlinestatus unbekannt (PL_TUC_EGK_STATUS # OCSP-Prüfung) Bei Abbruch: gespeicherte Daten der Quellkarte verwerfen und eGK Sitzung beenden, falls der Karteninhaber nicht identisch ist.
7. Daten auf Ziel-eGK schreiben
Beschreibung	Schleife über alle Anwendungen, für die getData() Anwendungsdaten geliefert hat: {     1. Anwendungstatus der Ziel-eGK speichern und danach ggf. die Anwendung sichtbar machen          durch Aufruf von Anwendungsfall „6.1.4.2 Anwendung auf eGK reaktivieren“ mit dem              Identifikator = Bezeichner der Anwendung    2. putData(             objsysVersionSrc,             objsysVersionDest,             application,             applicationData     );     3. Falls ein Aufruf mit einem Fehler beendet wird (z.B. weil auf der Ziel-eGK schon Daten vorhanden waren), so wird der Fehler, den AdV vom aufgerufenen Fachmodul erhalten hat, in verständlicher Form in die im letzten Schritt anzuzeigende AdV-Statusmeldung eingefügt.         Im Fehlerfall wird der Anwendungstatus der Ziel-eGK wieder hergestellt:           Falls auf der Ziel-eGK die Anwendung verborgen war, wird sie wieder verborgen durch Aufruf von Plattformbaustein PL_TUC_CARD_DEACTIVATE_APPLICATION mit dem Parameter Identifikator = Bezeichner der Anwendung     4. Wenn die Anwendung auf der Quellkarte verborgen gewesen war und erfolgreich kopiert wurde, diese gemäß appStatus durch Aufruf des Anwendungsfalls in „Anwendung auf eGK deaktivieren“ mit dem Parameter Identifikator = Bezeichner der Anwendung wieder verbergen. }
8. Abschluss der Kopieroperation
	Alle zwischengespeicherten Anwendungsdaten aus dem Arbeitsspeicher entfernen
9. AdV-Statusmeldung anzeigen
Hinweis an den Versicherten	Die AppResult-Elemente enthalten Informationen über das erfolgreiche Kopieren der Datensätze von einer eGK auf eine andere eGK des Versicherten. Im Fehlerfall werden entsprechende Fehlerinformationen ausgegeben. Dem Versicherten ist das Ergebnis des Kopiervorgangs für jede ausgewählte Fachanwendung - in einer für ihn verständlichen Form - anzuzeigen.

[<=]

6.1.6 Verwaltung der NFD

In diesem Abschnitt sind die Anwendungsfälle für die Verwaltung des Notfalldatensatzes (NFD) beschrieben. Ein Zugriff auf medizinische Daten ist nicht möglich.

AdV-A_2468 - AdV-App: Hinweis bei verborgenem Notfalldatensatz

Die AdV-App MUSS, wenn die Anwendung NFD auf der eGK des Versicherten verborgen ist, einen Hinweis an den Versicherten ausgeben, dass der Notfalldatensatz verborgen ist und im Notfall nicht gelesen werden kann. [<=]

6.1.6.1 NFD auf eGK verbergen

Mit der Umsetzung dieses Anwendungsfalls soll der Notfalldatensatz des Versicherten auf seiner eGK verborgen werden.

AdV-A_2469 - AdV-App: NFD auf eGK verbergen

Die AdV-App MUSS den Anwendungsfall „NFD auf eGK verbergen“ gemäß TAB_ADV_355 umsetzen.

Tabelle 30: TAB_ADV_355 – NFD auf eGK verbergen

[<=]

6.1.6.2 Verborgenen NFD auf eGK sichtbar machen

Mit der Umsetzung dieses Anwendungsfalls soll der verborgene Notfalldatensatz des Versicherten auf seiner eGK sichtbar gemacht werden.

AdV-A_2470 - AdV-App: Verborgene NFD auf eGK sichtbar machen

Die AdV-App MUSS den Anwendungsfall „Verborgene NFD auf eGK sichtbar machen“ gemäß TAB_ADV_356 umsetzen.

Tabelle 31 TAB_ADV_356 – Verborgene NFD auf eGK sichtbar machen

[<=]

6.1.6.3 PIN für NFD einschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.NFD eingeschaltet werden.

AdV-A_2471 - AdV-App: PIN für NFD einschalten

Die AdV-App MUSS den Anwendungsfall „PIN für NFD einschalten“ gemäß TAB_ADV_357umsetzen.

Tabelle 32: TAB_ADV_357 – PIN für NFD einschalten

[<=]

6.1.6.4 PIN für NFD ausschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.NFD ausgeschaltet werden.

AdV-A_2472 - AdV-App: PIN für NFD ausschalten

Die AdV-App MUSS den Anwendungsfall „PIN für NFD ausschalten“ gemäß TAB_ADV_358 umsetzen.

Tabelle 33: TAB_ADV_358 – PIN für NFD ausschalten

[<=]

6.1.7 Verwaltung des DPE

In diesem Abschnitt sind die Anwendungsfälle für die Verwaltung der Anwendung Datensatz ‚Persönliche Erklärungen‘ (DPE) beschrieben.

AdV-A_2473 - AdV-App: Hinweis bei verborgenem DPE

Die AdV-App MUSS beim Aufruf des Bereiches mit den Anwendungsfälle zur Anwendung DPE, wenn der DPE auf der eGK des Versicherten verborgen ist, einen Hinweis an den Versicherten ausgeben, dass die Anwendung verborgen ist und die Daten im Notfall nicht gelesen werden können. [<=]

6.1.7.1 Persönliche Erklärung (DPE) von eGK anzeigen

Mit der Umsetzung dieses Anwendungsfalls soll dem Versicherten der auf seiner eGK gespeicherte Datensatz Persönliche Erklärungen (DPE) zur Anzeige gebracht werden.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_121: „DPE von eGK anzeigen“ ausgeführt werden müssen.

 

Abbildung 14: ABB_ADV_359 – Ablauf des AdV-UC_121: „DPE von eGK anzeigen“

AdV-A_2474 - AdV-App: DPE von eGK anzeigen

Die AdV-App MUSS den Anwendungsfall „DPE von eGK anzeigen“ gemäß TAB_ADV_359 umsetzen.

Tabelle 34: TAB_ADV_359 – DPE von eGK anzeigen

 

Tabelle 35: TAB_ADV_360 – Ablaufaktivitäten – DPE von eGK anzeigen

[<=]

6.1.7.2 Persönliche Erklärung (DPE) auf eGK ändern

Mit der Umsetzung dieses Anwendungsfalls ändert der Versicherte eine oder mehrere Hinweise auf persönliche Erklärungen des auf der eGK gespeicherten Datensatzes Persönliche Erklärungen (DPE). Dem Ändern eines oder mehrerer Erklärungen muss ein Lesen der DPE vorausgehen, da der DPE nur im Ganzen auf die Karte geschrieben werden kann.

Wenn noch kein DPE auf der eGK gespeichert ist, dann kann der Versicherte einen DPE anlegen.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_122: „DPE auf eGK ändern“ ausgeführt werden müssen.

 

Abbildung 15: ABB_ADV_361 – Ablauf des AdV-UC_122: „DPE auf eGK ändern“

AdV-A_2475 - AdV-App: Persönliche Erklärung (DPE) auf eGK ändern

Die AdV-App MUSS den Anwendungsfall „Persönliche Erklärung (DPE) auf eGK ändern“ gemäß TAB_ADV_361 umsetzen.

Tabelle 36: TAB_ADV_361 – DPE auf eGK ändern

 

Tabelle 37: TAB_ADV_362 – Ablaufaktivitäten – DPE auf eGK ändern

[<=]

6.1.7.3 Persönliche Erklärung (DPE) auf eGK löschen

Mit der Umsetzung dieses Anwendungsfalls löscht der Versicherte den gesamten Datensatz seiner persönlichen Erklärungen (DPE) auf der eGK.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_123: „DPE auf eGK löschen“ ausgeführt werden müssen.

 

Abbildung 16: ABB_ADV_363 – Ablauf des AdV-UC_123: „DPE auf eGK löschen“

AdV-A_2476 - AdV-App: Persönliche Erklärung (DPE) auf eGK löschen

Die AdV-App MUSS den Anwendungsfall „Datensatz Persönliche Erklärung (DPE) auf eGK löschen“ gemäß TAB_ADV_363 umsetzen.

Tabelle 38: TAB_ADV_363 – DPE auf eGK löschen

 

Tabelle 39: TAB_ADV_364 – Ablaufaktivitäten – DPE auf eGK löschen

[<=]

6.1.7.4 PIN für DPE einschalten

Mit diesem Anwendungsfall kann der Versicherte die technische Notwendigkeit der Verifikation der MRPIN.DPE einschalten.

AdV-A_2477 - AdV-App: PIN für DPE einschalten

Die AdV-App MUSS den Anwendungsfall „PIN für DPE einschalten“ gemäß TAB_ADV_365 umsetzen.

Tabelle 40: TAB_ADV_365 – PIN für DPE einschalten

[<=]

6.1.7.5 PIN für DPE ausschalten

Mit diesem Anwendungsfall kann der Versicherte die technische Notwendigkeit der Verifikation der MRPIN.DPE ausgeschalten.

AdV-A_2478 - AdV-App: PIN für DPE ausschalten

Die AdV-App MUSS den Anwendungsfall „PIN für DPE ausschalten“ gemäß TAB_ADV_366 umsetzen.

Tabelle 41: TAB_ADV_366 – PIN für DPE ausschalten

[<=]

6.1.7.6 Persönliche Erklärung (DPE) auf eGK verbergen

Mit diesem Anwendungsfall kann der Versicherte den Datensatz Persönliche Erklärungen auf seiner eGK verbergen.

AdV-A_2479 - AdV-App: Datensatz Persönliche Erklärungen (DPE) auf eGK verbergen

Die AdV-App MUSS den Anwendungsfall „Datensatz Persönliche Erklärungen (DPE) auf eGK verbergen“ gemäß TAB_ADV_367 umsetzen.

Tabelle 42: TAB_ADV_367 – DPE auf eGK verbergen

[<=]

6.1.7.7 Verborgene DPE auf eGK sichtbar machen

Mit diesem Anwendungsfall kann der Versicherte den verborgenen Datensatz Persönliche Erklärungen auf seiner eGK wieder sichtbar machen.

AdV-A_2480 - AdV-App: Verborgenen DPE auf eGK sichtbar machen

Die AdV-App MUSS den Anwendungsfall „Verborgenen DPE auf eGK sichtbar machen„ gemäß TAB_ADV_368 umsetzen.

Tabelle 43: TAB_ADV_368 – Verborgenen DPE auf eGK sichtbar machen

[<=]

6.1.8 Verwaltung eMP/AMTS

In diesem Abschnitt sind die Anwendungsfälle für die Verwaltung der Daten des elektronischen Medikationsplans und zur Prüfung der Arzneimitteltherapiesicherheit beschrieben. Ein Zugriff auf medizinische Daten ist nicht möglich.

6.1.8.1 AMTS-Vertreter-PIN ändern

Mit der Umsetzung dieses Anwendungsfalls kann die AMTS-Vertreter-PIN auf der eGK gesetzt oder geändert werden.

Für die Umsetzung wird der in Kap. 6.1.4.3.1 PIN ändern beschriebene generische Anwendungsfall genutzt.

AdV-A_2481 - AdV-App: AMTS-Vertreter-PIN ändern

Die AdV-App MUSS den Anwendungsfall „AMTS-Vertreter-PIN ändern“ gemäß TAB_ADV_369 umsetzen.

Tabelle 44 TAB_ADV_369 – AMTS-Vertreter-PIN ändern

[<=]

6.1.8.2 AMTS-Vertreter-PIN entsperren

Mit diesem Anwendungsfall kann der Versicherte die gesperrten AMTS-Vertreter-PIN entsperren.

Für die Umsetzung wird der 6.1.4.3.2 PIN auf eGK entsperren beschriebene generische Anwendungsfall genutzt.

AdV-A_2482 - AdV-App: AMTS-Vertreter-PIN entsperren

Die AdV-App MUSS den Anwendungsfall „AMTS-Vertreter-PIN entsperren“ gemäß TAB_ADV_370 umsetzen.

Tabelle 45 TAB_ADV_370 – AMTS-Vertreter-PIN entsperren

[<=]

6.1.8.3 eMP/AMTS Datensatz verbergen

Mit der Umsetzung dieses Anwendungsfalls soll der eMP/AMTS-Datensatz des Versicherten auf seiner eGK verborgen werden.

AdV-A_2483 - AdV-App: eMP/AMTS-Datensatz verbergen

Die AdV-App MUSS den Anwendungsfall „eMP/AMTS-Datensatz auf eGK verbergen“ gemäß TAB_ADV_371 umsetzen.

Tabelle 46: TAB_ADV_371 – eMP/AMTS-Datensatz auf eGK verbergen

[<=]

6.1.8.4 Verborgenen eMP/AMTS Datensatz sichtbar machen

Mit der Umsetzung dieses Anwendungsfalls soll der verborgene eMP/AMTS-Datensatz des Versicherten auf seiner eGK sichtbar gemacht werden.

AdV-A_2484 - AdV-App: Verborgenen eMP/AMTS-Datensatz sichtbar machen

Die AdV-App MUSS den Anwendungsfall „Verborgene eMP/AMTS-Datensatz auf eGK sichtbar machen„ gemäß TAB_ADV_372 umsetzen.

Tabelle 47: TAB_ADV_372 – Verborgene eMP/AMTS-Datensatz auf eGK sichtbar machen

[<=]

6.1.8.5 PIN für AMTS einschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.AMTS eingeschaltet werden.

AdV-A_2485 - AdV-App: PIN für AMTS einschalten

Die AdV-App MUSS den Anwendungsfall „PIN für AMTS einschalten“ gemäß TAB_ADV_373 umsetzen.

Tabelle 48: TAB_ADV_373 – PIN für AMTS einschalten

[<=]

6.1.8.6 PIN für AMTS ausschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.AMTS ausgeschaltet werden. Das Ausschalten der MRPIN.AMTS ist bei eGK ab der Generation G2.1 möglich.

AdV-A_2486 - AdV-App: PIN für AMTS ausschalten

Die AdV-App MUSS den Anwendungsfall „PIN für AMTS ausschalten“ gemäß TAB_ADV_374 umsetzen.

Tabelle 49: TAB_ADV_374 – PIN für AMTS ausschalten

[<=]

6.1.9 Fachanwendungsunabhängige Anwendungsfälle

Dieses Kapitel beschreibt Anwendungsfälle, die keiner spezifischen Fachanwendung zugeordnet sind.

6.1.9.1 Mit eGK verschlüsseln

Der Anwendungsfall ermöglicht es dem Versicherten, mit der AdV-App ein Dokument mit der eGK zu verschlüsseln.

Dieser Anwendungsfall zielt auf die @home-Umgebung, da der Versicherte dort auf einen Datenträger (z.B. USB-Stick oder lokale Festplatte) mit privaten Dokumenten zugreifen kann. In der @home-Umgebung kann in dem Anwendungsfall eine Datei auf einem lokalen Datenträger des Versicherten selektiert und der Ablageort für das Ergebnis definiert werden.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_25: „Mit eGK verschlüsseln“ ausgeführt werden müssen.

 

Abbildung 17: ABB_ADV_322 – Ablauf des AdV-UC_25: "Mit eGK verschlüsseln"

AdV-A_2487 - AdV-App: AdV-UC_25: „Mit eGK verschlüsseln“

Die AdV-App KANN den Anwendungsfall AdV-UC_25: „Mit eGK verschlüsseln“ gemäß TAB_ADV_375 umsetzen.

Tabelle 50: TAB_ADV_375 – AdV-UC_25: „Mit eGK verschlüsseln“

 

Tabelle 51: TAB_ADV_376 – Ablaufaktivitäten – Mit eGK verschlüsseln

[<=]

6.1.9.2 Mit eGK entschlüsseln

Der Anwendungsfall ermöglicht es dem Versicherten, mit der AdV-App ein Dokument mit der eGK zu entschlüsseln.

Analog zum Anwendungsfall „Mit eGK verschlüsseln“ zielt dieser Anwendungsfall auf die @home-Umgebung, da der Versicherte dort auf seine privaten Dokumente zugreifen kann.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_26: „Mit eGK entschlüsseln“ ausgeführt werden müssen.

 

Abbildung 18: ABB_ADV_324 – Ablauf des AdV-UC_26: „Mit eGK entschlüsseln“

AdV-A_2488 - AdV-App: AdV-UC_26: „Mit eGK entschlüsseln“

Die AdV-App KANN den Anwendungsfall AdV-UC_26: „Mit eGK entschlüsseln“ gemäß TAB_ADV_377 umsetzen.

Tabelle 52: TAB_ADV_377 – AdV-UC_26: „Mit eGK entschlüsseln“

 

Tabelle 53: TAB_ADV_378 – Ablaufaktivitäten – Mit eGK entschlüsseln

[<=]

6.1.9.3 Authentisierungsrequest mit eGK signieren

Die Operation versieht unter Verwendung des AUT-Zertifikates der eGK eine Message (Binärstring/Hashwert) mit einer nicht-qualifizierten elektronischen Signatur. Die Operation verhält sich konform zu [TR-03112-4#3.5.5] (Crypto Services/Sign).

Die folgende Abbildung zeigt informativ, welche Schritte für Operation „Authentisierungsrequest mit eGK signieren“ ausgeführt werden müssen.

 

Abbildung 19: ABB_ADV_379 – Ablauf des AdV-UC_27 „Authentisierungsrequest mit eGK signieren“

AdV-A_2489 - AdV-App: AdV-UC_27: „Authentisierungsrequest mit eGK signieren“

Die AdV-App KANN den Anwendungsfall AdV-UC_27: „Authentisierungsrequest mit eGK signieren“ gemäß TAB_ADV_379 umsetzen.

Tabelle 54: TAB_ADV_379 – Authentisierungsrequest mit eGK signieren

 

Tabelle 55: TAB_ADV_380 – Ablaufaktivitäten – Authentisierungsrequest mit eGK signieren

[<=]

6.1.9.4 Zertifikat von eGK lesen

Anwendungsfall AdV-UC_24: Zertifikat von eGK lesen wird ausgelöst, wenn ein externes Programm oder Clientsystem von der eGK des Versicherten ein Zertifikat lesen will.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_24: Zertifikat von eGK lesen ausgeführt werden müssen.

 

Abbildung 20: ABB_ADV_381 – Ablauf AdV-UC_24: Zertifikat von eGK lesen

AdV-A_2490 - AdV-App: AdV-UC_24: Zertifikat von eGK lesen

Die AdV-App KANN den Anwendungsfall AdV-UC_24: „Zertifikat von eGK lesen“ gemäß TAB_ADV_381 umsetzen.

Tabelle 56: TAB_ADV_381 – AdV-UC_24: Zertifikat von eGK lesen

 

Tabelle 57: TAB_ADV_382 – Ablaufaktivitäten – AdV-UC_24: Zertifikat von eGK lesen

[<=]

6.2 Realisierung der Leistungen der TI-Plattform

Der Produkttyp KTR-AdV realisiert die von den Fachanwendungen benötigten Leistungen der TI-Plattform, die in den fachlichen Anwendungsfällen der AdV genutzt werden. Die bereitgestellten Leistungen umfassen einen für die Fachanwendungen einheitlichen Zugriff auf die eGK des Versicherten, Leistungen der PKI der Telematikinfrastruktur, Kryptooperationen, etc. die in übergreifenden Spezifikationen der gematik festgelegt sind. Die Definition der Leistungen der TI-Plattform in der KTR-AdV finden sich in Anhang B[gemSpec_Systemprozesse_dezTI].

Zusätzlich muss in der Realisierung der Leistung der Plattform – wie in 2.2 beschrieben – festgelegt werden, wie umgebungsspezifische Operationen an der Schnittstelle zu den Leistungen der TI-Plattform umgesetzt werden sollen. Diese Festlegungen werden in den folgenden Abschnitten festgelegt.

6.2.1 Transportschnittstelle für Kartenkommandos

Der hier beschriebene Produkttyp KTR-AdV ist als reines Softwareprodukt konzipiert. Als solches muss die KTR-AdV eine Schnittstelle zu Karten der TI über ein Kartenterminal herstellen. Diese Schnittstelle muss die von den Plattformprozessen erzeugten, kartenverständlichen APDUs an die Karte übertragen und wird im Folgenden als ENV_TUC_CARD_APDU_TRANSPORT bezeichnet. Neben proprietären Schnittstellentreibern von Kartenterminalherstellern existieren eine Reihe standardisierter Schnittstellen, die auch von verschiedenen Betriebssystemen zur Anbindung handelsüblicher Kartenterminals unterstützt werden.

AdV-A_2492 - Transportschnittstelle für Kartenkommandos

Die KTR-AdV MUSS eine Transportschnittstelle für die Übertragung von SmartCard-APDUs gegen die Standards CT-API und PCSC implementieren. [<=]

AdV-A_2493 - Ergänzende Standards für Transportschnittstelle

Die KTR-AdV KANN eine Transportschnittstelle für die Übertragung von SmartCard-APDUs auf Basis des SICCT-Protokolls, gegen den Standard CCID und gegen proprietäre Hardwaretreiber eines Kartenterminalherstellers implementieren. [<=]

AdV-A_2494 - Handbuch: Liste unterstützter Kartenterminals

Der Hersteller der KTR-AdV MUSS im Handbuch ausweisen, welche Standards und Schnittstellen zu Kartenterminals die KTR-AdV unterstützt und MUSS eine Liste mit handelsüblichen Kartenterminals angeben, die nachweislich mit dieser Ausprägung der KTR-AdV funktionieren. [<=]

Auf Seiten des Versicherten können Kartenterminalvarianten der Sicherheitsklassen 1 (reine Kontaktiereinheit), 2 (Kartenterminal mit eigenem PIN-Pad) oder 3 (PIN-Pad plus Display) zum Einsatz kommen. Zusätzlich ist die Ausstattung des eingesetzten Kartenterminals (Klasse 1, 2 oder 3) mit einer NFC-Schnittstelle möglich. Der Hersteller der KTR-AdV muss die von den Varianten gebotenen Features geeignet nutzen.

AdV-A_2499 - PIN-Eingabe nicht speichern

Die KTR-AdV DARF ein eingegebenes PIN-Geheimnis NICHT temporär und NICHT persistent speichern. [<=]

AdV-A_2562 - PIN-Geheimnis ausschließlich an Karte übermitteln

Die KTR-AdV MUSS sicherstellen, dass das eingegebene PIN-Geheimnis ausschließlich an die Karte und nicht an andere Adressaten übermittelt wird. [<=]

Das temporäre Speichern bezieht sich bei der Verwendung eines Kartenterminals der Sicherheitsklasse 1 auf das Verwenden der PIN über den Anwendungsfall hinaus, für den die PIN-Eingabe erfolgt ist, z.B. Caching während einer Sitzung. Gelangt die KTR-AdV bei der Verwendung eines Kartenterminals der Sicherheitsklassen 2 und 3 ggfs. durch Fehlkonfiguration in Kenntnis der PIN, darf es diese ebenfalls nicht temporär und nicht persistent speichern.

Auf Seite der Komponente AdV-Server in einem Rechenzentrum sind zusätzliche Varianten der Einbeziehung der Identitäten der Kostenträger in die Kartenoperationen möglich, wie z.B. Nutzung einer Webservice-Schnittstelle zu einem HSM oder das SICCT-Protokoll zur Anbindung eines HSM-B.

6.2.1.1 Kartenterminals der Sicherheitsklasse 1

Kartenterminals der Sicherheitsklasse 1 verfügen über keine Sicherheitsmerkmale, sie sind eine reine Kontaktiereinheit einer SmartCard. Sämtliche Geheimnis-Eingaben und Hinweistext-Ausgaben müssen über die KTR-AdV mittels Bildschirm und Tastatur/Maus erfolgen.

AdV-A_2495 - Klasse 1: PIN-Eingabe

Die KTR-AdV MUSS die PIN-/PUK-Eingabe über ein angeschlossenes Eingabegerät entgegennehmen und in ein an die Karte adressiertes Kommando einbetten, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird. [<=]

AdV-A_2496 - Klasse 1: PIN-Eingabe Geheimnis

Die KTR-AdV DARF die eingegebene PIN/PUK Ziffernfolge NICHT auf dem Bildschirm darstellen, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird. [<=]

AdV-A_2497 - Klasse 1: PIN-Eingabe Eingabefeedback

Die KTR-AdV MUSS ein eingegebenes Zeichen einer Geheimniseingabe mit dem Zeichen „ * “ (Wildcard) quittieren, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird. [<=]

AdV-A_2498 - Klasse 1: PIN-Eingabe Eingabevalidierung

Die KTR-AdV MUSS ein eingegebenes, neues PIN-Geheimnis durch eine erneute Abfrage des neuen PIN-Geheimnisses verifizieren, wenn das Geheimnis durch einen Anwendungsfall geändert werden soll und wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird. [<=]

6.2.1.2 Kartenterminals der Sicherheitsklasse 2

Kartenterminals der Sicherheitsklasse 2 verfügen über eine Eingabeschnittstelle zur Eingabe eines Benutzergeheimnisses. Typischerweise werden Kartenterminals der Sicherheitsklasse 2 in Anwendungsfällen mit Eingabe einer PIN bzw. PUK so angesteuert, dass das vorbereitete Kartenkommando mit einem Platzhalter des PIN-Geheimnisses an das Kartenterminal geschickt wird. Das Kartenterminal nimmt die PIN über die Eingabeschnittstelle entgegen, ersetzt den Platzhalter durch das eingegebene Geheimnis und leitet das Kartenkommando anschließend weiter an die Karte.

AdV-A_2500 - Klasse 2: PIN-Eingabe

Die KTR-AdV MUSS ein angeschlossenes Kartenterminal der Sicherheitsklasse 2 so ansteuern, dass ein Kartenkommando, das eine PIN-/PUK-Eingabe erfordert, an einem Kartenterminal um die Benutzereingabe ergänzt und anschließend direkt an die adressierte Karte weitergeleitet wird. [<=]

AdV-A_2501 - Klasse 2: PIN-Eingabe Fehlkonfiguration

Die KTR-AdV MUSS alle Operationen mit einer eindeutigen Fehlermeldung abbrechen, in denen sie die Kenntnis eines PIN/PUK-Geheimnisses erlangt, das an einem PIN-Pad eines Klasse 2 Kartenterminals eingegeben wurde. [<=]

AdV-A_2502 - Klasse 2: PIN-Eingabe Eingabefeedback

Die KTR-AdV MUSS während der Abfrage einer PIN/PUK an einem Kartenterminal der Sicherheitsklasse 2 einen Benutzerhinweis zur PIN-Eingabe am Kartenterminal an der Bildschirmausgabe ausgeben. [<=]

6.2.1.3 Kartenterminals der Sicherheitsklasse 3

Kartenterminals der Sicherheitsklasse 3 verfügen über eine Eingabeschnittstelle zur Eingabe eines Benutzergeheimnisses und Ausgabeschnittstelle zur Anzeige kurzer Textmeldungen. Typischerweise werden Kartenterminals der Sicherheitsklasse 3 in Anwendungsfällen mit Eingabe einer PIN bzw. PUK so angesteuert, dass das vorbereitete Kartenkommando mit einem Platzhalter des PIN-Geheimnisses an das Kartenterminal geschickt wird. Das Kartenterminal nimmt die PIN über die Eingabeschnittstelle entgegen, ersetzt den Platzhalter durch das eingegebene Geheimnis und leitet das Kartenkommando anschließend weiter an die Karte.

Während des Wartens auf eine Benutzereingabe kann ein an das Kartenterminal übergebener Text angezeigt werden. Einzelne Eingaben durch einen Benutzer werden in der Regel durch „*“-Zeichen quittiert. Ebenso besitzen Kartenterminals der Sicherheitsklasse 3 meist zusätzliche Logik, z.B. Eingaben zu verifizieren (siehe Anforderungen zum Ändern einer PIN mittels Klasse 1-Kartenterminal). Auf diese Logik soll hier nicht weiter eingegangen werden.

AdV-A_2503 - Klasse 3: PIN-Eingabe

Die KTR-AdV MUSS ein angeschlossenes Kartenterminal der Sicherheitsklasse 3 so ansteuern, dass ein Kartenkommando, das eine PIN-/PUK-Eingabe erfordert, an einem Kartenterminal um die Benutzereingabe ergänzt und anschließend direkt an die adressierte Karte weitergeleitet wird. [<=]

AdV-A_2504 - Klasse 3: PIN-Eingabe Fehlkonfiguration

Die KTR-AdV MUSS alle Operationen mit einer eindeutigen Fehlermeldung abbrechen, in denen sie die Kenntnis eines PIN/PUK-Geheimnisses erlangt, das an einem PIN-Pad eines Klasse 3 Kartenterminals eingegeben wurde. [<=]

AdV-A_2505 - Klasse 3: PIN-Eingabe Eingabefeedback

Die KTR-AdV MUSS während der Abfrage einer PIN/PUK an einem Kartenterminal der Sicherheitsklasse 3 einen Benutzerhinweis zur PIN-Eingabe am Kartenterminaldisplay ausgeben. [<=]

Die Anzeige eines Benutzerhinweises soll den Benutzer informieren zu welchem Zweck er eine Eingabe tätigen soll (z.B. alte Pin, neue PIN im Anwendungsfall PIN ändern) und welches konkretes Geheimnis abgefragt werden soll (PIN, PUK, PIN einer konkreten Anwendung).

6.2.2 Schnittstelle für PIN-Operationen und Anbindung der Karten der TI

Anwendungsfälle zur PIN-Verwaltung, die Kartenfreischaltung und Anwendungsfälle weiterer Fachanwendungen können die Eingabe eines PIN- oder PUK-Geheimnisses durch den Versicherten erfordern. Der Zugriff auf Karten der TI erfolgt über die Systemprozesse PL_TUC_CARD_*. Die KTR-AdV als Realisierungsumgebung der Systemprozesse muss ihrerseits die von der Plattform geforderten Schnittstellen ENV_TUC_CARD_SECRET_INPUT implementieren, um die Kommunikation der Plattform mit dem Benutzer über die Außenschnittstelle der KTR-AdV zu ermöglichen. Die Außenschnittstelle ist in Kapitel 6.2.1 Transportschnittstelle für Kartenkommandos beschrieben und umfasst das Kartenterminal, Eingabemedium und Hinweistexte an den Benutzer. Diese kann je nach Konfiguration an einem Gerät als Kartenterminal der Sicherheitsklasse 3 oder auch eine Kombination aus Bildschirmausgabe, Kartenterminal-PIN-Pad und/oder Tastatureingabe erfolgen.

AdV-A_2506 - Übergabeschnittstelle PIN/PUK-Geheimnis

Die KTR-AdV MUSS eine Operation ENV_TUC_SECRET_INPUT zur Eingabe eines PIN/PUK-Geheimnisses und Weiterleitung an eine SmartCard mit den Parametern

• Eingabeparameter:
  • Identifikator
  • Aktion
  • minLength
  • maxLength
  • commandApduPart
• Rückgabewerte
  • responseApdu

implementieren. [<=]

AdV-A_2507 - Umsetzung ENV_TUC_SECRET_INPUT

Die KTR-AdV MUSS die Abbildung der Eingabeparameter auf die Rückgabewerte der Operation ENV_TUC_SECRET_INPUT derart umsetzen, dass

• die Eingabeparameter Identifikator und Aktion für einen Hinweistext an den Benutzer verwendet werden, welche Aktion auf welchem konkreten Kartenobjekt (z.B. Name einer PIN) durchgeführt wird
• wenn der Eingabeparameter Aktion die Eingabe eines Benutzerhinweises erfordert, der commandApduPart an der Eingabeschnittstelle um das Benutzergeheimnis ergänzt wird
• der commandApduPart über die Transportschnittstelle für Kartenkommandos an die Karte gesendet wird

und die Antwortnachricht der Karte als responseApdu an den Aufrufer zur Auswertung zurückgegeben wird. [<=]

AdV-A_2555 - Minimalprinzip Karteninteraktion

Die KTR-AdV DARF ein Kartenkommando NICHT an eine angebundene Karte weiterleiten, dass nicht explizit im Kontext eines Anwendungsfalls (intendierte Kartenoperationen und Erhöhen des Sicherheitszustands der Karte falls erforderlich) erforderlich ist. [<=]

6.2.3 Schnittstelle zur Freischaltung der eGK

Um dem Versicherten zur Verwaltung seiner eGK die notwendigen Zugriffsrechte einzuräumen, muss die eGK über ein Card-2-Card-Verfahren freigeschaltet werden. Die Systemprozesse der TI-Plattform benötigen dafür eine vertrauliche, integre und authentische Schnittstelle zum Austausch von eGK-Challenge und einer Signatur dieser Challenge durch die SM-B-Identität der Kostenträger, die die Echtheit des Zertifikats und den Besitz des privaten Schlüssels zu diesem Zertifikat bestätigt.

In der Realisierungsumgebung der KTR-AdV muss dazu ein gesicherter Kanal zwischen der AdV-App beim Versicherten und dem AdV-Server in einem Rechenzentrum hergestellt werden. Anforderungen an diese gesicherte Verbindung werden im Kapitel „5.1.2 Absicherung der AdV-Komponenten“ beschrieben.

AdV-A_2508 - Transportschnittstelle für Card-2-Card

Die KTR-AdV MUSS eine Transportschnittstelle ENV_TUC_CARD_TO_CARD mit einer Kommunikationsschnittstelle zweier Karten der TI im Card-2-Card-Verfahren realisieren.
Wird in einem Card-2-Card-Verfahren über ENV_TUC_CARD_TO_CARD die Signatur eines tokens verlangt, so MUSS dieses über den Plattformbaustein PL_TUC_SIGN_HASH_nonQES, in dessen Zugriff sich ein CardProxy mit einer passenden Freischaltkarte befindet, mit den folgenden Parametern erfolgen:

Der Rückgabewert von PL_TUC_SIGN_HASH_nonQES ist als Antwort an die Aufrufschnittstelle von ENV_TUC_CARD_TO_CARD zurückzugeben. [<=]

6.2.4 Schnittstelle zu Diensten der zentralen TI-Plattform

Über einen sicheren zentralen Zugangspunkt (SZZP) stehen dem AdV-Server Dienste der zentralen TI-Plattform zur Verfügung.

AdV-A_2509 - Kapselung der Zugriffe auf Dienste der zentralen TI-Plattform

Die KTR-AdV MUSS den Zugriff auf Dienste der zentralen TI-Plattform in einem ConsumerAdapterConsumer Adapter der Komponente AdV-Server kapseln. [<=]

AdV-A_2510 - Proxy-Funktion des ConsumerAdaptersConsumer Adapters für die AdV-App

Die Komponente AdV-App der KTR-AdV MUSS für die Nutzung der Dienste der zentralen TI-Plattform die kapselnden Operationen des Consumer Adapters nutzen. [<=]

AdV-A_2511 - Separierung der AdV-App von Diensten der TI

Die Komponente AdV-App der KTR-AdV DARF NICHT direkt auf die Dienste der zentralen TI-Plattform und Fachdienste der Fachanwendungen zugreifen. [<=]

AdV-A_2512 - Consumer Adapter verwendet SZZP

Der Anbieter einer KTR-AdV MUSS den Zugriff des Consumer Adapters auf die TI über einen SZZP realisieren. [<=]

Über den Consumer Adapter werden die in ABB_ADV_302 und in TAB_ADV_301 dargestellten Schnittstellen zu Diensten der zentralen TI-Plattform und zu Fachdiensten bereitgestellt.

Abbildung 21: ABB_ADV_302 - Schnittstellen des TIP Consumer Adapters

Tabelle 58: TAB_AdV_301 - Schnittstellen des Consumer Adapters

6.3 Schnittstelle zwischen AdV-App und AdV-Server

Die Schnittstelle zwischen der AdV-App und dem AdV-Server liegt innerhalb des Produkttyps KTR-AdV. Es handelt sich daher um eine Innenschnittstelle. An diese werden keine inhaltlichen Anforderungen gestellt. Es werden jedoch Sicherheitsanforderungen im Kapitel 5.1.2 hierzu erhoben.

6.4 Identitäten der KTR-AdV

In der Beschreibung der Leistungen der dezentralen TI-Plattform im Anhang sowie in der Plattformkomponente CardProxy erfolgt die Schnittstellendefinition für den Zugriff auf die SM-B-Identitäten und deren kryptografisches Schlüsselmaterial auf Basis einer SMC-B mit entsprechendem Objektsystem.

Mit der Verwendung eines HSM und einer herstellerspezifischen Schnittstelle für den HSM-Zugriff können sich sowohl die Schnittstellenoperationen als auch die Bezeichner der entsprechenden SM-B-Identitäten von denen in der Spezifikation der KTR-AdV unterscheiden. Diese Abweichung ist ausdrücklich zulässig, soweit die Realisierung protokollarische Vorgaben und das geforderte Sicherheitsniveau einhält.

Die KTR-AdV benötigt zwei Rollen mit entsprechenden Identitäten zur Abbildung der oben genannten Anwendungsfälle. Als Kostenträgerorganisation soll sie dem Versicherten Zugriffsrechte auf seiner eGK zur Durchführung der AdV-Anwendungsfälle freischalten. Die Angaben zu dieser Kostenträgerorganisation werden auch zur Vervollständigung des obligatorischen eGK-Protokolleintrags verwendet.

Des Weiteren muss sich die KTR-AdV mit fachanwendungsspezifischen Fachdiensten verbinden können. Hierzu muss sie als Rechenzentrums-Consumer in einer passenden Rolle authentisiert werden.

Diese zwei Aspekte müssen in der KTR-AdV über Zertifikate abgebildet werden, deren zugehöriges kryptografisches, privates Schlüsselmaterial in der Realisierung der KTR-AdV integritätsgeschützt und vertraulich gespeichert werden muss.

AdV-A_2513 - Privates Schlüsselmaterial in HSM speichern

Die KTR-AdV MUSS privates Schlüsselmaterial zu Zertifikaten der Rollenauthentisierung gegenüber einer eGK und des Verbindungsaufbaus zu Diensten der TI in einem HSM integritätsgeschützt und vertraulich speichern, dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde. Als Evaluierungsschema kommen dabei Common Criteria oder Federal Information Processing Standard (FIPS) in Frage. Die Prüftiefe MUSS mindestens (a) FIPS 140-2 Level 3, oder (b) Common Criteria EAL 4 entsprechen. [<=]

Die Anbindung an den AdV-Server in einem Rechenzentrum kann über eine herstellerspezifische Schnittstelle mit einem handelsüblichen HSM erfolgen, die die oben genannten Sicherheitsziele erfüllt. Eine Anbindung eines HSM-Bs via SICCT ist nicht zwingend erforderlich.

Zum Zeitpunkt der Fertigstellung dieser Spezifikation erfüllt eine zugelassene SMC-B die oben genannte Anforderung und kann als HSM eingesetzt werden.

Falls keine SMC-B als HSM zum Einsatz kommt, müssen die Zertifikate auf sichere Weise in das HSM eingebracht werden. An dieser Stelle werden keine konkreten Technologien oder Prozessschritte vorgegeben, damit der Betreiber der KTR-AdV mit einem TSP ein geeignetes Verfahren etablieren kann.

Tabelle 61: TAB_ADV_385 – Personalisierung eines HSM

Aspekt	Beschreibung
Schlüsselmaterial der KTR-AdV	Das Schlüsselmaterial wird sicher im HSM erzeugt. Das private Schlüsselmaterial verlässt das HSM nicht oder nur zum Zwecke eines Backups auf einem Backup-HSM, wobei die Übertragung hinsichtlich Vertraulichkeit geschützt sein muss.
Zertifikatsrequest	Die benötigten Zertifikatsrequests werden im HSM erzeugt und exportiert. Die Zertifikatsrequests werden unter Wahrung der Authentizität und Integrität dem TSP übermittelt.
Zertifikat	Das Zertifikat wird vom TSP zum Betreiber übermittelt.

AdV-A_2575 - Personalisierung des HSMs

Falls der Betreiber der KTR-AdV keine SMC-B als HSM einsetzt, MUSS er einen sicheren Prozess zur Personalisierung des HSMs definieren und etablieren, der die in TAB_ADV_385 genannten Aspekte beinhaltet.  [<=]

Falls für diesen Prozess nur eine geringe Anzahl an Instanzen erwartet wird, kann es sinnvoll sein, Teile dieses Prozesses rein organisatorisch umzusetzen. Anstelle einer technischen Schnittstelle kann dann ein papierbasiertes Verfahren eingesetzt werden.

A_15118 - CV-Zertifikat für PIN Status Prüfung

Die KTR-AdV MUSS über ein CV-Zertifikat C.SMC.NULL_CVC verfügen, mit dem in einem Authentisierungsverfahren ein Trusted Channel aufgebaut wird, jedoch keine Zugriffsrechte für KTR-AdV- Anwendungsfälle auf einer eGK freigeschaltet werden. [<=]

AdV-A_2514 - CV-Zertifikat für eGK-Freischaltung

Die KTR-AdV MUSS über ein CV-Zertifikat C.SMC.AUTR_CVC verfügen, mit dem auf einer eGK Zugriffsrechte für KTR-AdV-Anwendungsfälle in einem Authentisierungsverfahren freigeschaltet werden. [<=]

Abhängig von der Realisierung eines sicheren Zertifikatsspeichers in der KTR-AdV kann das Authentisierungsverfahren zur Freischaltung der eGK über ein Card-2-Card- oder auch Card-2-Server-Verfahren erfolgen.

AdV-A_2515 - X.509-Zertifikat für TLS-gesicherte Verbindung

Die KTR-AdV MUSS über ein X.509-Zertifikat zum Zweck des TLS-Verbindungsaufbaus mit der Rolle professionOID = OID <oid_adv_ktr> gemäß [gemSpec_OID] verfügen, um sich gegenüber einem Fachdienst zu authentisieren, welches als C.HCI.AUT identifiziert wird. [<=]

AdV-A_2516 - X.509-Zertifikat für eGK-Protokolleintrag

Die KTR-AdV MUSS über ein X.509-Zertifikat mit einem CommonName entsprechend den Vorgaben des verantwortlichen Zertifikat-Herausgebers verfügen, um einen für den Versicherten lesbaren, nachvollziehbaren Protokolleintrag auf der eGK über die Nutzung der KTR-AdV erzeugen zu können. [<=]

AdV-A_2556 - nachvollziehbarer eGK-Protokolleintrag mit Bezug zum Anbieter

Der Anbieter der KTR-AdV MUSS sicherstellen, dass auf der eGK des Versicherten ein lesbarer, nachvollziehbarer Protokolleintrag mit Bezug zum Anbieter der KTR-AdV erzeugt werden kann. [<=]

Der Anbieter ist in diesem Zusammenhang eine Krankenkasse, in deren Auftrag ein Betreiber die KTR-AdV eines spezifischen Herstellers den Versicherten zur Verfügung stellt. Da aus diesem Zertifikat lediglich der CommonName verwendet und kein privates Schlüsselmaterial zur Authentisierung verwendet wird, kann auf die Nutzung dieses Zertifikats verzichtet werden. Es muss jedoch sichergestellt werden, dass auf der eGK des Versicherten ein lesbarer, nachvollziehbarer Protokolleintrag mit Bezug zum Anbieter der KTR-AdV erzeugt wird.

7 Informationsmodell

Ein gesondertes Informationsmodell der durch den Produkttypen verarbeiteten Daten wird nicht benötigt.

8 Verteilungssicht

Eine zusätzliche Darstellung der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird nicht benötigt.

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

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

9.3 Abbildungsverzeichnis

Abbildung 1: ABB_ADV_300 – Überblick AdV in einer Umgebung im Auftrag der KostenträgerAbbildung 1: ABB_ADV_300 – Überblick AdV in einer Umgebung im Auftrag der Kostenträger

Abbildung 2: ABB_ADV_304 – Zusammenhang Systemprozesse und Fachanwendung

Abbildung 3: ABB_ADV_301 – Kontextdiagramm

Abbildung 4: ABB_ADV_303 – Verteilungsdiagramm

Abbildung 5: ABB_ADV_329 – Komponentendiagramm der KTR-AdV

Abbildung 6 : ABB_ADV_333 Verbindungsaufbau und Freischaltung eGK

Abbildung 7: ABB_ADV_305 – Ablauf „Anwendung auf eGK deaktivieren“

Abbildung 8: ABB_ADV_383 – Ablauf „Anwendung auf eGK reaktivieren“

Abbildung 9: ABB_ADV_308 – Ablauf AdV-UC_03 „PIN für Fachanwendung einschalten“

Abbildung 10: ABB_ADV_310 – Ablauf AdV-UC_04 „PIN für Fachanwendung ausschalten“

Abbildung 11: ABB_ADV_317 - Ablauf des „VSD von eGK lesen”

Abbildung 12: ABB_ADV_314 – Ablauf des AdV-UC_21: „Zugriffsprotokoll anzeigen“

Abbildung 13: ABB_ADV_315 Standardablauf – Datenübertragung bei Kartentausch durchführen

Abbildung 14: ABB_ADV_359 – Ablauf des AdV-UC_121: „DPE von eGK anzeigen“

Abbildung 15: ABB_ADV_361 – Ablauf des AdV-UC_122: „DPE auf eGK ändern“

Abbildung 16: ABB_ADV_363 – Ablauf des AdV-UC_123: „DPE auf eGK löschen“

Abbildung 17: ABB_ADV_322 – Ablauf des AdV-UC_25: "Mit eGK verschlüsseln"

Abbildung 18: ABB_ADV_324 – Ablauf des AdV-UC_26: „Mit eGK entschlüsseln“

Abbildung 19: ABB_ADV_379 – Ablauf des AdV-UC_27 „Authentisierungsrequest mit eGK signieren“

Abbildung 20: ABB_ADV_381 – Ablauf AdV-UC_24: Zertifikat von eGK lesen

Abbildung 21: ABB_ADV_302 - Schnittstellen des TIP Consumer Adapters

Abbildung 22: Systemprozesse der Basis-TI

Abbildung 23: Umgebungsspezifische Operationen

9.4 Tabellenverzeichnis

Tabelle 1: TAB_ADV_300 – Akteure und ihre Rollen

Tabelle 2: TAB_ADV_329 – Komponenten, Verantwortung und Funktionalitäten

Tabelle 3: TAB_ADV_318 – Behandlung von Fehlercodes der Plattformbausteine

Tabelle 4: TAB_ADV_303 – Starten einer AdV-Sitzung

Tabelle 5: TAB_ADV_304 – Ablaufaktivitäten - Starten einer AdV-Sitzung

Tabelle 6: TAB_ADV_320 – Übergreifende Vorbedingungen

Tabelle 7: TAB_ADV_384 – Zulässige Anwendungsfälle nach Status von Karte, Anwendung und PIN

Tabelle 8: TAB_ADV_461 – Benennung der Anwendungen und Hinweise am Terminal

Tabelle 9: TAB_ADV_305 – AdV-UC_14 „Anwendung auf eGK deaktivieren“

Tabelle 10: TAB_ADV_306 – Ablaufaktivitäten – AdV-UC_14

Tabelle 11: TAB_ADV_383 – AdV-UC_15 „Anwendung auf eGK reaktivieren“

Tabelle 12: TAB_ADV_307 – Ablaufaktivitäten – AdV-UC_15

Tabelle 13: TAB_ADV_312 – PIN der eGK ändern

Tabelle 14: TAB_ADV_313 – Ablaufaktivitäten – PIN der eGK ändern

Tabelle 15: TAB_ADV_316 – PIN der eGK entsperren

Tabelle 16: TAB_ADV_317 – Ablaufaktivitäten – PIN der eGK entsperren

Tabelle 17: TAB_ADV_308 – AdV-UC_03 „PIN für Fachanwendung einschalten“

Tabelle 18: TAB_ADV_309 – Ablaufaktivitäten – AdV-UC_03

Tabelle 19: TAB_ADV_310 – AdV-UC_04 „PIN für Fachanwendung ausschalten“

Tabelle 20: TAB_ADV_311 – Ablaufaktivitäten – AdV-UC_04

Tabelle 21: TAB_ADV_314 – VSD von eGK anzeigen

Tabelle 22: TAB_ADV_315 – Ablaufaktivitäten – VSD von eGK anzeigen

Tabelle 23: TAB_ADV_350 – Zugriffsprotokoll anzeigen

Tabelle 24: TAB_ADV_351 – Ablaufaktivitäten – Zugriffsprotokoll anzeigen

Tabelle 25: TAB_ADV_352 – Versicherten-PIN der eGK ändern

Tabelle 26 TAB_ADV_353 – Versicherten-PIN entsperren

Tabelle 27: TAB_ADV_354 – Ablaufaktivitäten – Versicherten-PIN entsperren

Tabelle 28: TAB_ADV_324 – Datenübertragung bei Kartentausch durchführen

Tabelle 29: TAB_ADV_325 – Ablaufaktivitäten – Datenübertragung bei Kartentausch durchführen

Tabelle 30: TAB_ADV_355 – NFD auf eGK verbergen

Tabelle 31 TAB_ADV_356 – Verborgene NFD auf eGK sichtbar machen

Tabelle 32: TAB_ADV_357 – PIN für NFD einschalten

Tabelle 33: TAB_ADV_358 – PIN für NFD ausschalten

Tabelle 34: TAB_ADV_359 – DPE von eGK anzeigen

Tabelle 35: TAB_ADV_360 – Ablaufaktivitäten – DPE von eGK anzeigen

Tabelle 36: TAB_ADV_361 – DPE auf eGK ändern

Tabelle 37: TAB_ADV_362 – Ablaufaktivitäten – DPE auf eGK ändern

Tabelle 38: TAB_ADV_363 – DPE auf eGK löschen

Tabelle 39: TAB_ADV_364 – Ablaufaktivitäten – DPE auf eGK löschen

Tabelle 40: TAB_ADV_365 – PIN für DPE einschalten

Tabelle 41: TAB_ADV_366 – PIN für DPE ausschalten

Tabelle 42: TAB_ADV_367 – DPE auf eGK verbergen

Tabelle 43: TAB_ADV_368 – Verborgenen DPE auf eGK sichtbar machen

Tabelle 44 TAB_ADV_369 – AMTS-Vertreter-PIN ändern

Tabelle 45 TAB_ADV_370 – AMTS-Vertreter-PIN entsperren

Tabelle 46: TAB_ADV_371 – eMP/AMTS-Datensatz auf eGK verbergen

Tabelle 47: TAB_ADV_372 – Verborgene eMP/AMTS-Datensatz auf eGK sichtbar machen

Tabelle 48: TAB_ADV_373 – PIN für AMTS einschalten

Tabelle 49: TAB_ADV_374 – PIN für AMTS ausschalten

Tabelle 50: TAB_ADV_375 – AdV-UC_25: „Mit eGK verschlüsseln“

Tabelle 51: TAB_ADV_376 – Ablaufaktivitäten – Mit eGK verschlüsseln

Tabelle 52: TAB_ADV_377 – AdV-UC_26: „Mit eGK entschlüsseln“

Tabelle 53: TAB_ADV_378 – Ablaufaktivitäten – Mit eGK entschlüsseln

Tabelle 54: TAB_ADV_379 – Authentisierungsrequest mit eGK signieren

Tabelle 55: TAB_ADV_380 – Ablaufaktivitäten – Authentisierungsrequest mit eGK signieren

Tabelle 56: TAB_ADV_381 – AdV-UC_24: Zertifikat von eGK lesen

Tabelle 57: TAB_ADV_382 – Ablaufaktivitäten – AdV-UC_24: Zertifikat von eGK lesen

Tabelle 58: TAB_AdV_301 - Schnittstellen des Consumer Adapters

Tabelle 59: TAB_ADV_473 – Hinweistexte für den Versicherten

9.5 Referenzierte Dokumente

9.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 sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

 

9.5.2 Weitere Dokumente

9.6 Hinweistexte der Fachanwendungen

Tabelle 59: TAB_ADV_473 – Hinweistexte für den Versicherten

10 Anhang B – Leistungen der dezentralen TI-Plattform

Im Folgenden werden Leistungen der TI-Plattform beschrieben und als Systemprozesse deklariert. Diese Systemprozesse beschreiben wie mit Produkttypen der TI zu verfahren ist, um eine Plattformleistung für Fachanwendungen der TI zu erbringen. Diese Lösung hat das Ziel, Basisleistungen der TI-Plattform einheitlich und produkttyp unabhängig zu definieren.

Durch das Zusammenschalten von Operationen und Bausteinen der verschiedenen Fachdomänen der TI-Plattform (Kartenzugriff, PKI, Kryptografische Verfahren) entstehen höherwertige Plattformbausteine mit einer vereinheitlichten Syntax für den Zugriff auf produkttypübergreifende Plattformleistungen („PL_TUC_*“). Den Zusammenhang der verschiedenen Domänen und den damit komponierten höherwertigen Systemprozessen verdeutlicht die folgende Abbildung als technische Dokumentenlandkarte (in der Darstellung grün markiert).

Abbildung 22: Systemprozesse der Basis-TI

Die Beschreibung dieser Systemprozesse der TI erfolgt normativ, es wird jedoch auf eine prozedurale Ablaufbeschreibung verzichtet. Es erfolgt eine Festlegung, was zu tun ist, um eine vorgegebene Plattformleistung zu erbringen. Die konkrete Realisierung dieser Leistung eines Systemprozesses ist abhängig von Umgebungsannahmen und muss unter bestimmten Bedingungen um umgebungsspezifische Operationen und Festlegungen ergänzt werden. Sie sorgen für einen umgebungsspezifischen Zuschnitt (tayloring) der Systemprozesse, um eine TI-übergreifend spezifizierte Leistung in einer konkreten Ablaufumgebung von einem konkreten Produkttypen oder Dienst einer Fachanwendung zu erbringen.

Die umgebungsspezifischen Operationen, Umgebungsannahmen oder -parameter müssen von der Realisierungsumgebung („ENV_TUC_*“) normativ festgelegt werden. Der Produkttyp, der die hier spezifizierten Plattformleistungen nutzt, muss Festlegungen treffen, wie diese umgebungsabhängigen Schnittstellen zu implementieren sind. Damit ergibt sich für die Realisierung der Systemprozesse in einer konkreten Fachanwendung für eine konkrete Realisierungsumgebung ein Spezifikationsanteil, der in der folgenden Abbildung orange gekennzeichnet ist.

Abbildung 23: Umgebungsspezifische Operationen

10.1 Systemprozesse für den Zugriff auf Smartcards der TI

Der Zugriff auf Smartcards der TI wird durch einen CardProxy gemäß [gemSpec_CardProxy] gekapselt. Dieser kommuniziert pro Instanz mit einer einzelnen eGK, SM-B, mit einem HBA oder einer anderen entsprechenden Karte. Der CardProxy stellt Anwendungen eine höherwertige Schnittstelle für den Zugriff auf eine Karte zur Verfügung und übersetzt die parametrisierbaren Operationen in kartenverständliche APDU-Sequenzen. Der CardProxy verwaltet intern den Freischaltstatus der Karte und organisiert bei technischer Notwendigkeit einer PIN-Eingabe oder Freischaltung durch eine weitere Karte auf Basis von Zugriffsregeln und dem aktuellen Freischaltzustand eines Artefakts auf der Karte.

Die Kommunikation mit dem CardProxy wird durch die hier beschriebenen Plattformbausteine gekapselt. Die Plattformbausteine leiten die Aufrufe an den CardProxy weiter der zum einen eine höherwertige Kartenoperationen als cardOperation bereitstellt und zum anderen eine direkte, bei Bedarf auf eine verschlüsselte, Kommunikation mit der Karte über APDU-Sequenzen erlaubt. In der Schnittstelle zur cardOperation sind sämtliche kartenspezifischen Aspekte gekapselt, jede Aktion auf und mit der Karte wird auf die jeweils angegebenen Rückgabewerte abgebildet. In der direkten Kommunikation über einen transparenten Kanal erfolgt keine Auswertung der zur und von der Karte übertragenen APDU-Kommandos.

10.1.1 Die Realisierungsumgebung des CardProxy

Der CardProxy benötigt einen Zugriff auf Umgebungsschnittstellen, die je nach Einsatzumgebung der Karten unterschiedlich ausgeprägt sind. Der CardProxy benötigt eine Transportschnittstelle der physischen Anbindung zur Karte, einen Kommunikationskanal zu einem Remote-CardProxy mit einer zweiten Karte für eine Freischaltung nach dem Zwei-Schlüssel-Prinzip (Card-2-Card) und eine Schnittstelle zur Eingabe eines PIN-Geheimnisses.

10.1.1.1 ENV_TUC_CARD_SECRET_INPUT – Realisierung Eingabe PIN-Geheimnis

Das System zur Umsetzung der Plattformleistungen zur Anbindung der Karte muss für seine konkrete Realisierungsumgebung festlegen, wie PIN- bzw. PUK-Geheimnisse von einem Benutzerinterface an die Karte gelangen.

TIP1-A_6889 - Eingabeschnittstelle für PIN

Das System zur Umsetzung der Plattformleistungen PL_TUC_CARD_* MUSS eine Eingabeschnittstelle definieren, mittels der die Eingabe eines PIN-Geheimnisses an der Schnittstelle CardProxy und Kartenterminal gemäß [gemSpec_CardProxy#Schnittstelle CardProxy und Kartenleser] übergeben wird. [<=]

TIP1-A_6890 - Eingabeschnittstelle für PUK

Das System zur Umsetzung der Plattformleistungen PL_TUC_CARD_* MUSS eine Eingabeschnittstelle definieren, mittels der die Eingabe eines PUK-Geheimnisses an der Schnittstelle CardProxy und Kartenterminal gemäß [gemSpec_CardProxy#Schnittstelle CardProxy und Kartenleser] übergeben wird. [<=]

TIP1-A_6891 - Eingabeschnittstelle für newPIN

Das System zur Umsetzung der Plattformleistungen PL_TUC_CARD_* MUSS eine Eingabeschnittstelle definieren, mittels der die Eingabe eines neuen PIN-Geheimnisses an der Schnittstelle CardProxy und Kartenterminal gemäß [gemSpec_CardProxy#Schnittstelle CardProxy und Kartenleser] übergeben wird. [<=]

TIP1-A_7017 - Statusinformationen im Rahmen der PIN-Verifikation

Produkttypen und Dienste der TI die eine PIN/PUK-Eingabe mittels ENV_TUC_CARD_SECRET_INPUT umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy#Sicherheitszustand] zurückmelden:

1.   ErrorUserVerification        „Fehler im Authentisierungsprotokoll“

2.   OK                    „Sicherheitszustand passend gesetzt“

[<=] 

10.1.1.2 ENV_TUC_CARD_TO_CARD – Realisierung Card-2-Card

Das System zur Umsetzung der Plattformleistungen zur Anbindung der Karte muss für seine konkrete Realisierungsumgebung festlegen, wie der Datentransport innerhalb einer Card-2-Card-Freischaltung zwischen zwei beteiligten Karten erfolgt.

TIP1-A_6892 - Umgebungsschnittstelle für Card-2-Card

Das System zur Umsetzung der Plattformleistungen PL_TUC_CARD_* MUSS eine Transportschnittstelle „Umgebung“ definieren, mittels welcher der Datenaustausch von Challenge und Response im Card-2-Card-Verfahren zwischen zwei CardProxy-Instanzen von CardProxy_A an CardProxy_B gemäß [gemSpec_CardProxy#Sicherheitszustand#Card-2-Card] realisiert wird. [<=]

TIP1-A_7018 - Statusinformationen im Rahmen von Card-2-Card

Produkttypen und Dienste der TI die eine Card-2-Card-Freischaltung mittels ENV_TUC_CARD_TO_CARD umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy#Sicherheitszustand] zurückmelden:

1.   ErrorAuthentication            „Fehler im Authentisierungsprotokoll“

2.   ErrorImportCVC            „Fehler im CV-Zertifikatimport“

3.   OK                    „Sicherheitszustand passend gesetzt“

4.   WrongEndEntityCVC        „Das End-Entity-CV-Zertifikat enthält nicht die Rechte, die nötig sind um die Aktion freizuschalten“

[<=] 

10.1.1.3 ENV_TUC_CARD_APDU_TRANSPORT – Realisierung APDU-Transport

Das System zur Umsetzung der Plattformleistungen zur Anbindung der Karte muss für seine konkrete Realisierungsumgebung festlegen, wie die elektrische Schnittstelle zwischen CardProxy und Karte als Kartenkontaktiereinheit IFD realisiert wird.

TIP1-A_6893 - Umgebungsschnittstelle für Kartenkommandos

Das System zur Umsetzung der Plattformleistungen PL_TUC_CARD_* MUSS eine Schnittstelle realisieren, mittels welcher der Transport der APDU-Kommandos zwischen CardProxy und Karte gemäß [gemSpec_CardProxy Konzept der Komponente Kartenterminal Proxy] über eine Kartenkontaktiereinheit gemäß [ISO7816-3] realisiert wird. [<=]

10.1.2 Konfiguration und Statusinformationen

Um die korrekte Funktionsweise einer CardProxy-Instanz in einer konkreten Realisierungsumgebung sicherzustellen, ist eine Konfiguration und Initialisierung des CardProxies erforderlich. Es muss festgelegt werden, welchen Kartentyp eine jeweilige CardProxy-Instanz unterstützen soll und welche Operation auf welchen Objekten der jeweiligen Karte in einer Anwendung zulässig sind.

10.1.2.1 Konfiguration des CardProxy

TIP1-A_6894 - Konfiguration des Kartenzugriffs

Das System zur Umsetzung der Kartenzugriffe mittels CardProxy MUSS für seine Realisierungsumgebung eine Konfigurationstabelle gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] für jeden unterstützten Kartentyp einer SmartCard der TI definieren. [<=]

Die Konfigurationstabelle legt die zulässigen Operationen für jeden unterstützten Kartentyp in einer konkreten Realisierungsumgebung fest. Um eine Eindeutigkeit in der Auswahl einer passenden Zugriffsregel eines Objektes auf der Karte zu erhalten, muss der Nutzer der Plattformleistung festlegen, in welchen Rollen ein Akteur in Anwendungsfällen mit Bezug zu einer Karte der TI interagieren kann.

TIP1-A_7019 - Konfiguration der Rollen des Benutzers einer Karte

Das System zur Umsetzung der Plattformleistungen für Systemprozesse der TI-Plattform MUSS für seine Realisierungsumgebung festlegen, welche Rollen ein Benutzer in Anwendungsfällen mit Bezug auf eine Karte der TI einnehmen darf. [<=]

TIP1-A_6895 - Festlegung des Zugriffsprofils zur Rollenauthentisierung gegenüber einer eGK

Das System zur Umsetzung der Plattformleistungen für Systemprozesse der TI-Plattform MUSS festlegen, welche Zugriffe eine SmartCard (HBA, SM-B) bei der Rollenauthentisierung gegenüber einer eGK in seiner konkreten Realisierungsumgebung freischalten darf. [<=]

Mit dieser Anforderung wird sichergestellt, dass die zum Einsatz kommenden Karten über die entsprechenden Zertifikate zur Rollenauthentisierung gegenüber einer eGK verfügen. Diese Rollen bilden Zugriffsrechte auf der eGK ab, die in der Konfigurationstabelle für den CardProxy verzeichnet sind.

10.1.2.2 Initialisierung CardProxy für eGK

Bei der Initialisierung des CardProxy in dessen Zugriff sich eine eGK befindet, soll die komplette CV-Zertifikatskette einer in der Realisierungsumgebung vorgehaltenen SM-B, die für die Freischaltung der eGK vorgesehen ist, übergeben werden. Daraus ergibt sich, dass die in der Realisierungsumgebung eingesetzte SM-B bereits über einen initialisierten CardProxy adressiert werden kann. Die Instanz des CardProxy mit eGK muss mit der Referenz der SM-B der übergebenen SM-B-CV-Zertifikatskette und dem bei der Initialisierung des SM-B-CardProxy ausgelesenen X.509-AUT-Zertifikats assoziiert werden.

TIP1-A_6896 - Initialisierung CardProxy für eGK

Das System zur Umsetzung der Plattformleistungen für Systemprozesse der TI-Plattform MUSS bei der Initialisierung des CardProxies mit Zugriff auf eine eGK

•   die gesamte CV-Zertifikatskette einer für die Freischaltung vorgesehenen SM-B-Identität der Realisierungsumgebung an den eGK-CardProxy übergeben

•   die vorgesehene SM-B mit diesem eGK-CardProxy für die Dauer des Zugriffs auf die eGK assoziieren und zu dieser Verbindung das C.HCI.AUT-Zertifikat der SM-B temporär speichern.

•   die in PL_TUC_CARD_INFORMATION gelisteten Informationen zu dieser Karte mittels CardProxy aus der Karte auslesen.

[<=] 

10.1.2.3 Initialisierung CardProxy für SM-B

Bei der Initialisierung des CardProxy in dessen Zugriff sich eine SM-B befindet, soll die SM-B mittels PIN-Eingabe freigeschaltet werden sowie das CV- und das X.509-AUT-Zertifikat ausgelesen werden.

TIP1-A_6897 - Initialisierung CardProxy für SM-B

Das System zur Umsetzung der Plattformleistungen für Systemprozesse der TI-Plattform MUSS bei der Initialisierung des CardProxies mit Zugriff auf eine SM-B

•   eine Benutzerverifikation durchführen mittels PL_TUC_CARD_VERIFY_PIN und dem IDENTIFIKATOR PIN.SMC gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy für SMC-B]

•   die in PL_TUC_CARD_INFORMATION gelisteten Informationen zu Karte mittels CardProxy aus der Karte auslesen

•   das CV-CA-Zertifikat zum C.SMC.AUTR_CVC-Zertifikat der im Zugriff befindlichen SM-B und sofern vorhanden alle dazugehörigen Cross-Zertifikate der CVC-Root aus der TSL auslesen.

[<=] 

10.1.2.4 PL_TUC_CARD_INFORMATION – Gesammelte Statusinformationen zu einer Karte

Der Systemprozess PL_TUC_CARD_INFORMATION sammelt Statusinformationen zu einer SmartCard, die über eine umgebungsspezifische Schnittstelle an das System angebundene wird und stellt diese zum Abruf durch andere Systemprozesse bereit. Die Informationen umfassen zum einen Auskünfte über Kartentyp und Kartengeneration bzw. –version und zum anderen Statusinformationen über auf der Karte vorhandene Anwendungen und PINs.

TIP1-A_6898 - Leistung zu Statusinformationen zu einer Karte

Produkttypen und Dienste der TI mit Zugriff auf Smartcards der TI MÜSSEN eine Plattformleistung PL_TUC_CARD_INFORMATION realisieren und mit Statusinformationen einer SmartCard befüllen, die über die Umgebungsschnittstelle ENV_TUC_CARD_APDU_TRANSPORT mit dem System verbunden wird. [<=]

TIP1-A_6899 - Liste verfügbarer Informationen zu einer SmartCard

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_INFORMATION umsetzen, MÜSSEN die folgenden Informationen zum Status einer angebundenen SmartCard sammeln, bei Änderung aktualisieren und für die Dauer der Verbindung zu dieser SmartCard zum Abruf bereitstellen.

[<=] 

10.1.2.5 PL_TUC_EGK_STATUS – Gültigkeit der eGK prüfen

Der Systemprozess PL_TUC_EGK_STATUS fasst Leistungen verschiedener Domänen unter Einbeziehung einer elektronischen Gesundheitskarte zu einer höherwertigen Plattformleistung zusammen. Mit dieser wird eine Gültigkeitsprüfung der eGK durchgeführt, die zum einen Prüfschritte direkt auf der Karte durchführt und andererseits die Legitimität der Karte mittels Onlineabfrage beim Kartenherausgeber prüft.

TIP1-A_6901 - Prüfkriterien der Gültigkeit der eGK

Produkttypen und Dienste der TI mit Zugriff auf eine elektronische Gesundheitskarte mittels CardProxy MÜSSEN eine Plattformleistung PL_TUC_EGK_STATUS zur Prüfung des Status einer eGK umsetzen, die die eGK den folgenden Prüfkriterien unterzieht:

[<=] 

TIP1-A_6902 - Prüfergebnis der Echtheit_und_Gültigkeit der eGK

Produkttypen und Dienste der TI MÜSSEN zur Realisierung von PL_EGK_STATUS über das Ergebnis jedes Prüfkriteriums der Echtheit- und Gültigkeitsprüfung der eGK informieren und mit einem Status die erfolgreiche Prüfung aller Kriterien mitteilen.

1.   Echtheit                => „ja / nein / Prüffehler“

2.   Gesundheitsanwendung         => „aktiv / nicht aktiv / Prüffehler“

3.   Karteninhaberzertifikat        => „zeitlich gültig / ungültig / Prüffehler“
                     „mathematisch gültig / ungültig / Prüffehler“
      „Online gültig / Online gesperrt / Onlinestatus unbekannt / Prüffehler“

[<=] 

10.1.2.6 PL_TUC_CARD_RESET – Rücksetzen einer Karte

Mit dem Systemprozess PL_TUC_CARD_RESET soll der logische Kanal einer im Zugriff eines CardProxy befindlichen SmartCard der TI auf den Initialisierungsstand zurückgesetzt werden.

TIP1-A_7020 - Leistung zum Rücksetzen einer Karte

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Rücksetzen des logischen Kanals einer SmartCard als Plattformleistung PL_TUC_CARD_RESET gemäß [gemSpec_CardProxy] cardOperation mit dem Aktionsparameter RESETCHANNEL und dem IDENTIFIKATOR „*“ (Wildcard) umsetzen und das Abschließen dieser Aktion mit dem Rückgabewert
OK
bestätigen. [<=]

10.1.3 Zugriff auf Smartcards der TI

Der folgende Abschnitt definiert Systemprozesse für den Zugriff auf Smartcards der TI als funktionale Abläufe. Voraussetzung für die korrekte Funktionsweise sind zum einen umgebungsspezifische Abläufe an den Außenschnittstellen, die von der jeweiligen Realisierungsumgebung festgelegt werden müssen. Zum anderen muss für die jeweils durch einen CardProxy adressierbaren Karten eine Konfigurationstabelle der zulässigen Kartenoperationen definiert werden.

10.1.3.1 PL_TUC_CARD_CHANGE_PIN – PIN Ändern

Durch den Systemprozess PL_TUC_CARD_CHANGE_PIN wird das PIN-Geheimnis einer referenzierten PIN auf einer SmartCard der TI geändert.

TIP1-A_6903 - Leistung zur Änderung einer PIN

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Ändern einer PIN auf einer SmartCard als Plattformleistung PL_TUC_CARD_CHANGE_PIN gemäß [gemSpec_CardProxy] cardOperation für Passwortobjekte mit dem Aktionsparameter CHANGE umsetzen. [<=]

TIP1-A_6904 - Aufrufparameter zum Ändern einer PIN

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_CHANGE_PIN umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR des Passwortobjektes gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6905 - Ergebnis der Änderung einer PIN

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_CHANGE_PIN umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                        „PIN erfolgreich geändert“

2.   CardTerminated                „Karte nicht mehr verwendbar“

3.   MemoryFailure                „Karte defekt“

4.   ObjectNotFound                „IDENTIFIKATOR ungültig“

5.   PasswordBlocked                „PIN gesperrt”

6.   PasswordProtected                „PIN mit Transportschutz”

7.   SecurityStatusNotSatisfied            „Aktion nicht erlaubt“

8.   WrongSecretWarning.X             „PIN falsch, noch X Versuche“

9.   WrongLength                „neue PIN hat die falsche Länge“

[<=] 

10.1.3.2 PL_TUC_CARD_ENABLE_PIN – PIN-Schutz einschalten

Mit dem Systemprozess PL_TUC_CARD_ENABLE_PIN wird die PIN-Verifikation der referenzierten PIN eingeschaltet.

TIP1-A_6906 - Leistung zum Einschalten einer PIN

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Einschalten einer PIN auf einer SmartCard als Plattformleistung PL_TUC_CARD_ENABLE_PIN gemäß [gemSpec_CardProxy] cardOperation für Passwortobjekte mit dem Aktionsparameter ENABLE umsetzen. [<=]

TIP1-A_6907 - Aufrufparameter zum Einschalten einer PIN

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_ENABLE_PIN umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR des Passwortobjektes gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6908 - Ergebnis des Einschaltens einer PIN

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_ENABLE_PIN umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                        „PIN erfolgreich eingeschaltet“

2.   CardTerminated                „Karte nicht mehr verwendbar“

3.   MemoryFailure                „Karte defekt“

4.   ObjectNotFound                „IDENTIFIKATOR ungültig“

5.   PasswordBlocked                „PIN gesperrt”

6.   PasswordProtected                „PIN mit Transportschutz”

7.   SecurityStatusNotSatisfied            „Aktion nicht erlaubt“

8.   WrongSecretWarning.X             „PIN falsch, noch X Versuche“

[<=] 

10.1.3.3 PL_TUC_CARD_DISABLE_PIN – PIN-Schutz abschalten

Mit dem Systemprozess PL_TUC_CARD_DISABLE_PIN wird die PIN-Verifikation einer referenzierten PIN abgeschaltet. Objekte auf einer SmartCard mit Zugriffsbedingungen, die die referenzierte PIN enthalten, sind bei abgeschalteter PIN weniger geschützt.

TIP1-A_6909 - Leistung zum Abschalten einer PIN

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Abschalten einer PIN auf einer SmartCard als Plattformleistung PL_TUC_CARD_DISABLE_PIN gemäß [gemSpec_CardProxy] cardOperation für Passwortobjekte mit dem Aktionsparameter DISABLE umsetzen. [<=]

TIP1-A_6910 - Aufrufparameter zum Abschalten einer PIN

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_DISABLE_PIN umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR des Passwortobjektes gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6911 - Ergebnis des Abschaltens einer PIN

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_DISABLE_PIN umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                        „PIN erfolgreich abgeschaltet“

2.   CardTerminated                „Karte nicht mehr verwendbar“

3.   MemoryFailure                „Karte defekt“

4.   ObjectNotFound                „IDENTIFIKATOR ungültig“

5.   PasswordBlocked                „PIN gesperrt”

6.   PasswordProtected                „PIN mit Transportschutz”

7.   SecurityStatusNotSatisfied            „Aktion nicht erlaubt“

8.   WrongSecretWarning.X             „PIN falsch, noch X Versuche“

[<=] 

10.1.3.4 PL_TUC_CARD_UNBLOCK_PIN – PIN mit PUK entsperren

Mit dem Systemprozess PL_TUC_CARD_UNBLOCK_PIN wird eine gesperrte PIN entsperrt. Das Entsperren kann mit gleichzeitigem Setzen einer neuen PIN oder ohne das setzen einer neuen PIN erfolgen. Der Modus der Entsperrung erfolgt auf Grundlage der Festlegungen in der Konfiguration des CardProxies für einen bestimmten Kartentypen.

TIP1-A_6912 - Leistung zum Entsperren einer PIN mittels PUK

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Entsperren einer PIN auf einer SmartCard als Plattformleistung PL_TUC_CARD_UNBLOCK_PIN gemäß [gemSpec_CardProxy] cardOperation für Passwortobjekte mit dem Aktionsparameter UNBLOCK umsetzen. [<=]

TIP1-A_6913 - Aufrufparameter zum Entsperren einer PIN mittels PUK

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_UNBLOCK_PIN umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR des Passwortobjektes gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6914 - Ergebnis der Entsperrung einer PIN mittels PUK

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_UNBLOCK_PIN umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                        „PIN erfolgreich entsperrt“

2.   CardTerminated                „Karte nicht mehr verwendbar“

3.   MemoryFailure                „Karte defekt“

4.   ObjectNotFound                „IDENTIFIKATOR ungültig“

5.   PasswordBlocked                „PUK gesperrt”

6.   PasswordProtected                „PIN mit Transportschutz”

7.   SecurityStatusNotSatisfied            „Aktion nicht erlaubt“

8.   WrongSecretWarning.X             „PUK falsch, noch X Versuche“

9.   WrongLength                „neue PIN hat die falsche Länge“

[<=] 

10.1.3.5 PL_TUC_CARD_VERIFY_PIN – Benutzer verifizieren

Der Systemprozess PL_TUC_CARD_VERIFY_PIN führt eine kartenbasierte Benutzerverifikation durch. Dazu wird auf einer SmartCard der TI eine PIN-Eingabe angestoßen, über die sich ein Benutzer als Besitzer des Kartengeheimnisses authentifiziert.

TIP1-A_6915 - Leistung zur Benutzerverifikation

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN eine Benutzerverifikation mittels PIN als Plattformleistung PL_TUC_CARD_VERIFY_PIN gemäß [gemSpec_CardProxy] cardOperation für Passwortobjekte mit dem Aktionsparameter VERIFY umsetzen. [<=]

TIP1-A_6916 - Aufrufparameter der Benutzerverifikation

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_VERIFY_PIN umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR des Passwortobjektes gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6917 - Ergebnis der Leistung zur Eingabe einer PIN

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_VERIFY_PIN umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „PIN erfolgreich verifiziert“

2.   PasswordBlocked            „PIN gesperrt”

3.   PasswordProtected            „PIN mit Transportschutz”

4.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

5.   WrongSecretWarning.X         „PIN falsch, noch X Versuche“

6.   ObjectNotFound            „IDENTIFIKATOR ungültig“

7.   CardTerminated            „Karte nicht mehr verwendbar“

8.   MemoryFailure            „Karte defekt“

[<=] 

10.1.3.6 PL_TUC_CARD_ACTIVATE_APPLICATION – Anwendung aktivieren

Der Systemprozess PL_TUC_CARD_ACTIVATE_APPLICATION schaltet eine verborgene Anwendung auf einer SmartCard sichtbar.

TIP1-A_6918 - Leistung zum Aktivieren einer Anwendung

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Sichtbarmachen einer Anwendung auf einer SmartCard als Plattformleistung PL_TUC_CARD_ACTIVATE_APPLICATION gemäß [gemSpec_CardProxy] cardOperation für Ordner mit dem Aktionsparameter ACTIVATE umsetzen. [<=]

TIP1-A_6919 - Aufrufparameter zum Aktivieren einer Anwendung

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_ACTIVATE_APPLICATION umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der Anwendung gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6920 - Ergebnis der Leistung zur Aktivieren einer Anwendung

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_ACTIVATE_APPLICATION umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Anwendung erfolgreich aktviert“

2.   ObjectNotFound            „IDENTIFIKATOR ungültig“

3.   CardTerminated            „Karte nicht mehr verwendbar“

4.   MemoryFailure            „Karte defekt“

5.   ObjectTerminated            „Objekt nicht mehr verwendbar“

6.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

7.   UpdateRetryWarning        „Aktion erfolgreich, Speicher mglw. defekt“

[<=] 

10.1.3.7 PL_TUC_CARD_DEACTIVATE_APPLICATION – Anwendung deaktivieren

Mit dem Systemprozess PL_CAR_DEACTIVATE_APPLICATION wird eine Anwendung auf einer SmartCard verborgen.

TIP1-A_6921 - Leistung zum Deaktivieren einer Anwendung

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Verbergen einer Anwendung auf einer SmartCard als Plattformleistung PL_TUC_CARD_DEACTIVATE_APPLICATION gemäß [gemSpec_CardProxy] cardOperation für Ordner mit dem Aktionsparameter DEACTIVATE umsetzen. [<=]

TIP1-A_6922 - Aufrufparameter zum Deaktivieren einer Anwendung

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_DEACTIVATE_APPLICATION umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der Anwendung gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6923 - Ergebnis der Leistung zur Deaktivieren einer Anwendung

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_DEACTIVATE_APPLICATION umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Anwendung erfolgreich deaktviert“

2.   ObjectNotFound            „IDENTIFIKATOR ungültig“

3.   CardTerminated            „Karte nicht mehr verwendbar“

4.   MemoryFailure            „Karte defekt“

5.   ObjectTerminated            „Objekt nicht mehr verwendbar“

6.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

7.   UpdateRetryWarning        „Aktion erfolgreich, Speicher mglw. defekt“

[<=] 

10.1.3.8 PL_TUC_CARD_GET_CHALLENGE – Auslesen einer Zufallszahl

Mit dem Systemprozess PL_TUC_CARD_GET_CHALLENGE kann eine Zufallszahl aus einer SmartCard ausgelesen werden. Ist die verwendete Karte eine elektronische Gesundheitskarte genügt die Qualität der Zufallszahl zur Ableitung ephemerer Schlüsselparameter.

TIP1-A_6924 - Leistung zum Auslesen einer Zufallszahl

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Auslesen einer Zufallszahl von einer SmartCard als Plattformleistung PL_TUC_CARD_GET_CHALLENGE gemäß [gemSpec_CardProxy] cardOperation für Ordner mit dem Aktionsparameter GETRANDOM und dem IDENTIFIKATOR „*“ (Wildcard) umsetzen. [<=]

TIP1-A_6925 - Aufrufparameter für das Auslesen einer Zufallszahl

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_GET_CHALLENGE umsetzen, MÜSSEN vom Nutzenden die Längenangabe LENGTH der auszulesenden Zufallszahl gemäß [gemSpec_CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6926 - Ergebnis des Auslesens einer Zufallszahl

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_GET_CHALLENGE umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK + Daten                „Aktion erfolgreich ausgeführt“

[<=] 

10.1.3.9 PL_TUC_CARD_READ_FILE – Lesen von Daten aus einer SmartCard

Mit dem Systemprozess PL_TUC_CARD_READ_FILE werden Daten aus einer transparenten Datei einer SmartCard gelesen. Über die Parameter Offset und Length kann gesteuert werden, ab welcher Position in der Datei eine festgelegte Anzahl Bytes gelesen werden. Fehlen diese Parameter, wird der komplette Dateiinhalt ausgelesen.

TIP1-A_6927 - Leistung zum Lesen einer Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Lesen des Inhalts einer Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_READ_FILE gemäß [gemSpec_CardProxy] cardOperation für transparente Elementary Files mit dem Aktionsparameter READ umsetzen. [<=]

TIP1-A_6928 - Aufrufparameter für das Lesen einer Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_READ_FILE umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu lesenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6929 - Optionale Parameter für das Lesen einer Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_READ_FILE umsetzen, MÜSSEN die vom Nutzenden optional bereitgestellten Parameter OFFSET und LENGTH bei Vorhandensein entgegennehmen und diese in der Umsetzung von [gemSpec_CardProxy] cardOperation verwenden, um die zu lesende Datenmenge zu beschränken. [<=]

TIP1-A_6930 - Ergebnis des Lesens des Inhalts einer Datei

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_READ_FILE umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK + Dateiinhalt            „Daten wurden erfolgreich gelesen“

2.   OffsetTooBig            „OFFSET ungültig“

3.   CorruptDataWarning + Dateiinhalt    „Daten gelesen, Speicher mglw. defekt ”

4.   ObjectNotFound            „IDENTIFIKATOR ungültig”

5.   CardTerminated            „Karte nicht mehr verwendbar”

6.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

[<=] 

10.1.3.10 PL_TUC_CARD_WRITE_FILE – Schreiben von Daten auf eine SmartCard

Mit dem Systemprozess PL_TUC_CARD_WRITE_FILE werden Binärdaten in eine transparente Datei einer SmartCard geschrieben. Die Schreiboperation fügt die neuen Daten an eventuell vorhandene Daten an.

TIP1-A_6931 - Leistung zum Schreiben von Daten in eine transparente Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Schreiben von Daten in eine transparente Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_WRITE_FILE gemäß [gemSpec_CardProxy] cardOperation für transparente Elementary Files mit dem Aktionsparameter UPDATE und dem OFFSET = 0 umsetzen. [<=]

TIP1-A_6932 - Aufrufparameter für das Schreiben einer transparenten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_WRITE_FILE umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu schreibenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] sowie NEWDATA entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6933 - Ergebnis des Schreibens von Datei in eine transparente Datei

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_WRITE_FILE umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Daten erfolgreich geschrieben“

2.   DataTooBig                „Länge von NEWDATA ungültig“

3.   MemoryFailure            „Karte defekt”

4.   ObjectNotFound            „IDENTIFIKATOR ungültig”

5.   CardTerminated            „Karte nicht mehr verwendbar”

6.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

7.   UpdateRetryWarning        „Daten geschrieben, Speicher mglw. defekt“

[<=] 

10.1.3.11 PL_TUC_CARD_UPDATE_FILE – Aktualisieren von Daten in einer transparenten Datei einer SmartCard

Mit dem Systemprozess PL_TUC_CARD_UPDATE_FILE werden Binärdaten in eine transparente Datei einer SmartCard geschrieben, so dass vorhandene Daten überschrieben werden. Über den Parameter Offset kann gesteuert werden, ab welcher Position in der Datei die neuen Daten geschrieben werden. Fehlt dieser Parameter, beginnt die Schreiboperation am Anfang der Datei.

TIP1-A_6934 - Leistung zum Aktualisieren von Daten in einer transparenten Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Aktualisieren von Daten in einer transparenten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_UPDATE_FILE gemäß [gemSpec_CardProxy] cardOperation für transparente Elementary Files mit dem Aktionsparameter UPDATE umsetzen. [<=]

TIP1-A_6935 - Aufrufparameter zum Aktualisieren von Daten in einer transparenten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_UPDATE_FILE umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu aktualisierenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] sowie NEWDATA entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6936 - Optionaler Parameter für das Aktualisieren von Datei in einer transparenten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_READ_FILE umsetzen, MÜSSEN den vom Nutzenden optional bereitgestellten Parameter OFFSET bei Vorhandensein entgegennehmen und diesen in der Umsetzung von [gemSpec_CardProxy] cardOperation verwenden, um die Startposition der Schreiboperation innerhalb der Datei festzulegen. [<=]

TIP1-A_6937 - Ergebnis der Aktualisierung von Daten einer transparenten Datei

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_UDPATE_FILE umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Daten erfolgreich geschrieben“

2.   DataTooBig                „Länge von NEWDATA ungültig“

3.   OffsetTooBig            „OFFSET ungültig“

4.   MemoryFailure            „Karte defekt”

5.   ObjectNotFound            „IDENTIFIKATOR ungültig”

6.   CardTerminated            „Karte nicht mehr verwendbar”

7.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

8.   UpdateRetryWarning        „Daten geschrieben, Speicher mglw. defekt“

[<=] 

10.1.3.12 PL_TUC_CARD_DELETE_FILE – Löschen von Daten auf einer SmartCard

Der Systemprozess PL_TUC_CARD_DELETE_FILE entfernt eine transparente Datei auf einer SmartCard samt Dateiinhalt. Die gelöschte Datei ist im Anschluss nicht mehr adressierbar.

TIP1-A_6938 - Leistung des Löschens einer transparenten Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Löschen einer transparenten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_DELETE_FILE gemäß [gemSpec_CardProxy] cardOperation für transparente Elementary Files mit dem Aktionsparameter DELETE umsetzen. [<=]

TIP1-A_6939 - Aufrufparameter zum Löschen einer transparenten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_DELETE_FILE umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu löschenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6940 - Ergebnis der Löschoperation einer transparenten Datei

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_DELETE_FILE umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Datei erfolgreich gelöscht“

2.   MemoryFailure            „Karte defekt”

3.   ObjectNotFound            „IDENTIFIKATOR ungültig”

4.   CardTerminated            „Karte nicht mehr verwendbar”

5.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

6.   UpdateRetryWarning        „Aktion erfolgreich, Speicher mglw. defekt“

[<=] 

10.1.3.13 PL_TUC_CARD_ERASE_FILE – Rücksetzen des Inhalts einer transparenten Datei

Der Systemprozess PL_TUC_CARD_ERASE_FILE entfernt den Inhalt einer transparenten Datei. Die adressierte Datei ist weiterhin verwendbar.

TIP1-A_6941 - Leistung zum Rücksetzen einer transparenten Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Rücksetzen des Dateiinhalts einer transparenten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_ERASE_FILE gemäß [gemSpec_CardProxy] cardOperation für transparente Elementary Files mit dem Aktionsparameter ERASE umsetzen. [<=]

TIP1-A_6942 - Aufrufparameter zum Rücksetzen einer transparenten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_ERASE_FILE umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zurückzusetzenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6943 - Optionaler Parameter für das Rücksetzen des Inhalts einer transparenten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_ERASE_FILE umsetzen, MÜSSEN den vom Nutzenden optional bereitgestellten Parameter OFFSET bei Vorhandensein entgegennehmen und dieses in der Umsetzung von [gemSpec_CardProxy] cardOperation verwenden, um die Startposition der Operation innerhalb der Datei festzulegen. [<=]

TIP1-A_6944 - Ergebnis des Rücksetzens einer transparenten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_ERASE_FILE umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Daten erfolgreich gelöscht“

2.   OffsetTooBig            „OFFSET ungültig“

3.   MemoryFailure            „Karte defekt”

4.   ObjectNotFound            „IDENTIFIKATOR ungültig”

5.   CardTerminated            „Karte nicht mehr verwendbar”

6.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

7.   UpdateRetryWarning        „Daten gelöscht, Speicher mglw. defekt“

[<=] 

10.1.3.14 PL_TUC_CARD_READ_RECORD – Lesen von Daten aus einer strukturierten Datei

Mit dem Systemprozess PL_TUC_CARD_READ_RECORD werden Daten aus einer strukturierten Datei auf einer SmartCard ausgelesen. Über die optionale Angabe der recordNumber wird gesteuert, ob nur ein einzelner Record oder alle Records der strukturierten Datei gelesen werden sollen.

TIP1-A_6945 - Leistung zum Lesen einer strukturierten Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Lesen einer strukturierten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_READ_RECORD gemäß [gemSpec_CardProxy] cardOperation für strukturierte Elementary Files mit dem Aktionsparameter READ umsetzen. [<=]

TIP1-A_6946 - Aufrufparameter für das Lesen einer strukturierten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_READ_RECORD umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu lesenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6947 - Optionale Parameter für das Lesen einer strukturierten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_READ_RECORD umsetzen, MÜSSEN den vom Nutzenden optional bereitgestellten Parameter RECORDNUMBER bei Vorhandensein entgegennehmen und diese in der Umsetzung von [gemSpec_CardProxy] cardOperation verwenden, um die zu lesende Datenmenge zu beschränken. [<=]

TIP1-A_6948 - Ergebnis des Lesens einer strukturierten Datei

Produkttypen und Dienste der TI die die Plattformleistung PL_TUC_CARD_READ_RECORD umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK +Recordliste            „Daten wurden erfolgreich gelesen“

2.   CorruptDataWarning +Recordliste    „Daten gelesen, Speicher mglw. defekt ”

3.   ObjectNotFound            „IDENTIFIKATOR ungültig”

4.   RecordNotFound            „RECORDNUMBER ungültig“

5.   RecordDeactivated            „Datensatz[RECORDNUMBER] deaktiviert“

6.   CardTerminated            „Karte nicht mehr verwendbar”

7.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

[<=] 

10.1.3.15 PL_TUC_EGK_READ_PROTOCOL – Auslesen des Zugriffprotokolls der eGK

Mit dem Systemprozess PL_TUC_EGK_READ_PROTOCOL wird das gesamte Zugriffsprotokoll auf der elektronischen Gesundheitskarte ausgelesen. Im Gegensatz zur generischen Leseoperation eines strukturierten Elementary Files wird in diesem Baustein der Zugriff auf die Karte durch die Kartenzugriffsschicht CardProxy optimiert und es werden alle Log-Einträge (maximal 50) in einer Liste zurückgegeben.

TIP1-A_6949 - Leistung zum Lesen des Zugriffprotokolls auf der eGK

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Auslesen des Zugriffprotokolls auf der eGK als Plattformleistung PL_TUC_EGK_READ_PROTOCOL gemäß [gemSpec_CardProxy] cardOperation für strukturiertes Elementary File mit dem Aktionsparameter READ und dem IDENTIFIKATOR EF.Logging gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy eGK G2] umsetzen. [<=]

TIP1-A_6996 - Aufbereitung Zugriffsprotokolleinträge

Produkttypen und Dienste der TI, die die Plattformleistung PL_TUC_EGK_READ_PROTOCOL umsetzen, MÜSSEN alle aus der Karte gelesenen, binär-codierten Zugriffsprotokolleinträge gemäß [gemSpec_Karten_Fach_TIP#Tab_Karten_Fach_TIP_010_StrukturEF.Logging] in ein strukturiertes Format überführen und die Werte entsprechend des angegeben Datentyps decodieren. [<=]

TIP1-A_6950 - Ergebnis des Auslesens des Zugriffprotokolls der eGK

Produkttypen und Dienste der TI, die die Plattformleistung PL_TUC_EGK_READ_PROTOCOL umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK + Liste/Zugriffsprotokoll    „Daten wurden erfolgreich gelesen“

2.   CorruptDataWarning + Liste    „Daten gelesen, Speicher mglw. defekt ”

3.   ObjectNotFound            „IDENTIFIKATOR ungültig”

4.   CardTerminated            „Karte nicht mehr verwendbar”

5.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

[<=] 

10.1.3.16 PL_TUC_CARD_WRITE_RECORD – Schreiben von Daten in eine strukturierte Datei

Der Systemprozess PL_TUC_CARD_WRITE_RECORD schreibt einen Datensatz in einen Record einer strukturierten Datei auf einer SmartCard. Enthält der zu schreibende Record bereits Daten, wird der alte Datensatz mit dem neuen Wert überschrieben.

TIP1-A_6951 - Leistung zum Schreiben von Daten in eine strukturierte Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Schreiben eines Records einer strukturierten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_WRITE_RECORD gemäß [gemSpec_CardProxy] cardOperation für strukturierte Elementary Files mit dem Aktionsparameter UPDATE umsetzen. [<=]

TIP1-A_6952 - Aufrufparameter zum Schreiben von Daten in eine strukturierte Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_WRITE_RECORD umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu aktualisierenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy], die RECORDNUMBER sowie NEWDATA entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6953 - Ergebnis der Schreiboperation in einer strukturierten Datei

Produkttypen und Dienste der TI die die Plattformleistung PL_TUC_CARD_WRITE_RECORD umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Datensatz erfolgreich geschrieben“

2.   UpdateRetryWarning        „Daten geschrieben, Speicher mglw. defekt ”

3.   WrongRecordLength        „Länge von NEWDATA ungültig”

4.   ObjectNotFound            „IDENTIFIKATOR ungültig”

5.   RecordNotFound            „RECORDNUMBER ungültig“

6.   RecordDeactivated            „Datensatz[RECORDNUMBER] deaktiviert“

7.   CardTerminated            „Karte nicht mehr verwendbar”

8.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

9.   OutOfMemoryError            „Speicherplatz in Zieldatei zu klein“

10.   MemoryFailure            „Karte defekt“

11.   BufferTooSmall            „Kartenkommando zu lang“

[<=] 

10.1.3.17 PL_TUC_CARD_APPEND_RECORD – Anfügen von Daten an eine strukturierte Datei

Mit dem Systemprozess PL_TUC_CARD_APPEND_RECORD wird ein Datensatz als neuer Record in einer strukturierten Datei an das Ende angefügt.

TIP1-A_6954 - Leistung zum Anfügen von Daten in einer strukturierten Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Anfügen eines Records in einer strukturierten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_APPEND_RECORD gemäß [gemSpec_CardProxy] cardOperation für strukturierte Elementary Files mit dem Aktionsparameter APPEND umsetzen. [<=]

TIP1-A_6955 - Aufrufparameter zum Anfügen von Daten in einer strukturierten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_APPEND_RECORD umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu aktualisierenden Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] sowie RECORDDATA entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6956 - Ergebnis der Anfügeoperation in einer strukturierten Datei

Produkttypen und Dienste der TI, die die Plattformleistung PL_TUC_CARD_APPEND_RECORD umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Datensatz erfolgreich angefügt“

2.   UpdateRetryWarning        „Daten angefügt, Speicher mglw. defekt ”

3.   WrongRecordLength        „Länge von RECORDDATA ungültig”

4.   ObjectNotFound            „IDENTIFIKATOR ungültig”

5.   FullRecordList                   „Kein zusätzlicher Record in Zieldatei zulässig“

6.   CardTerminated            „Karte nicht mehr verwendbar”

7.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

8.   OutOfMemoryError            „Speicherplatz in Zieldatei zu klein“

9.   MemoryFailure            „Karte defekt“

10.   BufferTooSmall            „Kartenkommando zu lang“

[<=] 

10.1.3.18 PL_TUC_EGK_APPEND_PROTOCOL – Zugriff auf der eGK protokollieren

Mit dem Systemprozess PL_TUC_EGK_APPEND_PROTOCOL wird ein höherwertiger Baustein für das Schreiben eines Zugriffsprotokoll-Eintrags auf die eGK definiert. Nutzern dieser Plattformleistung genügt es, beim Aufruf den Identifikator der zu protokollierenden Fachanwendung mit der Art des durch die Fachanwendung erfolgten Zugriffs mitzuteilen. Der Systemprozess erzeugt aus diesen Daten zusammen mit den Angaben des Karteninhabers der SM-B-AUT-Identität, der diese eGK in einem Card-2-Card-Verfahren mit einem CV-Zertifikat freigeschaltet hat, einen Protokolldatensatz. Für das Protokollieren auf der eGK nutzt der Systemprozess die Schreiboperation des CardProxy der eGK.

TIP1-A_6957 - Leistung zum Protokollieren des eGK-Zugriffs

Produkttypen und Dienste, welche Systemprozesse der TI mit Zugriff auf die eGK realisieren, MÜSSEN das Hinzufügen eines Protokolleintrags auf der eGK als Plattformleistung PL_TUC_EGK_APPEND_PROTOCOL umsetzen. [<=]

TIP1-A_6958 - Aufrufparameter der Zugriffsprotokollierung

Produkttypen und Dienste der TI, die die Plattformleistung PL_TUC_EGK_APPEND_PROTOCOL umsetzen, MÜSSEN vom Nutzenden die Protokollparameter

1.   DATATYPE            [1 Byte] „Identifikator der Fachanwendung“

2.   ACCESSTYPE        [1 Byte] „Identifikator der Zugriffsart“

entgegennehmen. [<=] 

TIP1-A_6959 - Hinzufügen eines Protokolleintrags auf die eGK

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_EGK_APPEND_PROTOCOL umsetzen, MÜSSEN die Schritte zum Hinzufügen eines Protokolleintrags auf der eGK in der angegebenen Reihenfolge durchführen:

[<=] 

10.1.3.19 PL_TUC_CARD_DELETE_RECORD – Löschen von Daten in einer strukturierten Datei

Mit dem Systemprozess PL_TUC_CARD_DELETE_RECORD wird ein einzelner Record einer strukturierten Datei oder werden alle Records einer strukturierten Datei auf einer SmartCard gelöscht. Beim Löschen eines einzelnen Records reduziert sich die Anzahl der Records in der strukturierten Datei um eins. Werden alle Records gelöscht, ist die Anzahl der Records nach erfolgreichem Abschluss der Operation null. Die strukturierte Datei ist weiterhin adressierbar.

TIP1-A_6960 - Leistung zum Löschen von Daten in einer strukturierten Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Löschen von Daten einer strukturierten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_DELETE_RECORD gemäß [gemSpec_CardProxy] cardOperation für strukturierte Elementary Files mit dem Aktionsparameter DELETERECORD umsetzen. [<=]

TIP1-A_6961 - Aufrufparameter zum Löschen von Daten in einer strukturierten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_DELETE_RECORD umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der betroffenen Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6962 - Optionale Parameter für das Löschen von Daten einer strukturierten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_DELETE_RECORD umsetzen, MÜSSEN den vom Nutzenden optional bereitgestellten Parameter RECORDNUMBER bei Vorhandensein entgegennehmen und diese in der Umsetzung von [gemSpec_CardProxy] cardOperation verwenden, um die zu löschende Datenmenge auf einen einzelnen Record zu beschränken. [<=]

TIP1-A_6963 - Ergebnis der Löschoperation in einer strukturierten Datei

Produkttypen und Dienste der TI, die die Plattformleistung PL_TUC_CARD_DELETE_RECORD umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Datensatz erfolgreich gelöscht“

2.   UpdateRetryWarning        „Daten gelöscht, Speicher mglw. defekt ”

3.   ObjectNotFound            „IDENTIFIKATOR ungültig”

4.   RecordNotFound            „RECORDNUMBER ungültig”

5.   RecordDeactivated            „Datensatz[RECORDNUMBER] deaktiviert“

6.   CardTerminated            „Karte nicht mehr verwendbar”

7.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

8.   MemoryFailure            „Karte defekt“

[<=] 

10.1.3.20 PL_TUC_CARD_ERASE_RECORD – Rücksetzen eines Datensatzes in einer strukturierten Datei

Der Systemprozess PL_TUC_CARD_ERASE_RECORD löscht den Inhalt eines einzelnen der strukturierten Datei auf einer SmartCard. Der Record sowie die gesamte strukturierte Datei bleiben dabei erhalten. Der zurückgesetzte Record sowie die strukturierte Datei sind weiterhin adressierbar.

TIP1-A_6964 - Leistung zum Rücksetzen eines Datensatzes in einer strukturierten Datei

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Rücksetzen eines Records einer strukturierten Datei auf einer SmartCard als Plattformleistung PL_TUC_CARD_ERASE_RECORD gemäß [gemSpec_CardProxy] cardOperation für strukturierte Elementary Files mit dem Aktionsparameter ERASE umsetzen. [<=]

TIP1-A_6965 - Aufrufparameter zum Rücksetzen eines Datensatzes in einer strukturierten Datei

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_ERASE_RECORD umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR der zu betroffenen strukturierten Datei gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy] sowie die RECORDNUMBER des zurückzusetzenden Datensatzes entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6966 - Ergebnis des Rücksetzens eines Datensatzes in einer strukturierten Datei

Produkttypen und Dienste der TI die die Plattformleistung PL_TUC_CARD_DELETE_RECORD umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK                    „Datensatz erfolgreich zurückgesetzt“

2.   UpdateRetryWarning        „Daten zurückgesetzt, Speicher mglw. defekt ”

3.   ObjectNotFound            „IDENTIFIKATOR ungültig”

4.   RecordNotFound            „RECORDNUMBER ungültig”

5.   RecordDeactivated            „Datensatz[RECORDNUMBER] deaktiviert“

6.   CardTerminated            „Karte nicht mehr verwendbar”

7.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

8.   MemoryFailure            „Karte defekt“

[<=] 

10.1.4 Transparenter Zugriff auf eine SmartCard

Mit dem Zugriff auf eine SmartCard über einen transparenten Kanal ist es möglich, von entfernter Stelle mit der Karte zu interagieren. Über den CardProxy werden Kartenkommandos direkt an die Karte weitergeleitet und deren Antwort-APDU zurückgegeben. Weder die kapselnden Systemprozesse noch CardProxy werten den Inhalt der an die Karte gesendeten und von dort empfangenen APDUs aus. Im speziellen Fall einer verschlüsselten Kommunikation (trusted channel) zwischen der Karte und einem Server in Card-to-Server-Kommunikation ist dies ohnehin nicht möglich.

10.1.4.1 PL_TUC_CARD_TC_OPEN

Der Systemprozess PL_TUC_CARD_TC_OPEN öffnet einen transparenten Kommunikationskanal zu einer SmartCard. Mit der Nutzung dieses Plattformbausteins findet kein direkter Zugriff auf die Karte statt, es aktiviert in der Kartenzugriffsschicht eine exklusive Nutzung der Karte für diesen transparenten Kanal. Während dieser geöffnet ist, sind ausschließlich Aktionen mit den Systemprozessen PL_TUC_CARD_TC_SEND und _CLOSE möglich.

TIP1-A_6967 - Leistung zum Öffnen eines transparenten Kanals

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Öffnen eines transparenten Kanals zu einer SmartCard als Plattformleistung PL_TUC_CARD_TC_OPEN gemäß [gemSpec_CardProxy] Funktion transparentChannel mit dem Aktionsparameter OPEN umsetzen. [<=]

TIP1-A_6968 - Ergebnis des Öffnens eines transparenten Kanals

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_TC_OPEN umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] Funktion transparentChannel zurückmelden:

1.   OK                    „Aktion erfolgreich ausgeführt“

2.   TransparentChannelAlreadyOpen    „Transparenter Kanal bereits offen“

[<=] 

10.1.4.2 PL_TUC_CARD_TC_SEND

Mittels des Systemprozesses PL_TUC_CARD_TC_SEND wird ein Kartenkommando zu einer Karte weitergeleitet, ohne den Inhalt auszuwerten. Gelangt das Kartenkommando erfolgreich zur Karte wird immer das Response-Kommando der Karte zurückgegeben.

TIP1-A_6969 - Leistung der transparenten Kommunikation zur Karte

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Senden von transparenten Kartenkommandos an eine SmartCard als Plattformleistung PL_TUC_CARD_TC_SEND gemäß [gemSpec_CardProxy] Funktion transparentChannel mit dem Aktionsparameter SENDAPDU umsetzen. [<=]

TIP1-A_6970 - Aufrufparameter zur transparenten Kommunikation zur Karte

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_CARD_TC_SEND umsetzen, MÜSSEN vom Nutzenden die COMMANDAPDU, welche an die Karte weitergeleitet werden soll, entgegennehmen und in der Umsetzung der Funktion transparentChannel verwenden. [<=]

TIP1-A_6971 - Ergebnis der transparenten Kommunikation zur Karte

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_TC_SEND umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] Funktion transparentChannel zurückmelden:

1.   OK plus responseAPDU        „Aktion erfolgreich ausgeführt“

2.   MissingAPDU            „Fehlendes Kartenkommando“

3.   TransparentChannelNotOpen    „Transparenter Kanal nicht offen“

[<=] 

10.1.4.3 PL_TUC_CARD_TC_CLOSE

Der Systemprozess PL_TUC_CARD_TC_CLOSE schließt einen transparenten Kommunikationskanal zu einer SmartCard und gibt diese als Ressource für andere Plattformleistungen wieder frei. Mit der Nutzung dieses Plattformbausteins findet kein direkter Zugriff auf die Karte statt, es deaktiviert in der Kartenzugriffsschicht die exklusive Nutzung der Karte für diesen transparenten Kanal.

TIP1-A_6972 - Leistung zum Schließen eines transparenten Kanals

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Schließen eines transparenten Kanals zu einer SmartCard als Plattformleistung PL_TUC_CARD_TC_CLOSE gemäß [gemSpec_CardProxy] Funktion transparentChannel mit dem Aktionsparameter CLOSE umsetzen. [<=]

TIP1-A_6973 - Ergebnis des Schließens eines transparenten Kanals

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_CARD_TC_CLOSE umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] Funktion transparentChannel zurückmelden:

1.   OK                    „Aktion erfolgreich, Karte zurückgesetzt“

2.   TransparentChannelNotOpen    „Transparenter Kanal nicht offen“

[<=] 

10.2 Kommunikation und Vernetzung

10.2.1 PL_TUC_TLS_SECURE_CHANNEL – Kartenbasierte TLS-Verbindung

Der Systemprozess PL_TUC_TLS_SECURE_CHANNEL baut eine verschlüsselte Verbindung von einem Clientsystem auf Basis einer Kartenidentität auf einer SmartCard der TI zu einem Zielsystem her. Dazu erfolgt eine gegenseitige Authentisierung zwischen dem Zielsystem und der verwendeten SmartCard und werden symmetrische Sitzungsschlüssel, für die verschlüsselte Kommunikation zwischen Client- und Zielsystem, ausgehandelt.

TIP1-A_6974 - Leistung zur kartenbasierten TLS-Verbindung

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN eine Plattformleistung PL_TUC_TLS_SECURE_CHANNEL für den Aufbau einer kartenidentitätsbasierten TLS-Verbindung umsetzen. [<=]

TIP1-A_6975 - Aufrufparameter zur kartenbasierten TLS-Verbindung

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_TLS_SECURE_CHANNEL umsetzen, MÜSSEN vom Nutzenden den URI des Zielsystems und den ROLLENBEZEICHNER der erwarteten Rolle des Zielsystems als Parameter entgegennehmen und diese im Verbindungsaufbau verwenden. [<=]

TIP1-A_6976 - Aufbau der kartenbasierten TLS-Verbindung

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_TLS_SECURE_CHANNEL umsetzen, MÜSSEN die Schritte zum Aufbau einer kartenbasierten TLS-Verbindung in der angegebenen Reihenfolge durchführen:

[<=] 

10.2.2 PL_TUC_NET_NAME_RESOLUTION

Mit dem Systemprozess PL_TUC_NET_NAME_RESOLUTION wird ein URI einer Netzwerkkomponente der TI mittels des Namensdienstes der zentralen TI-Plattform in eine IP-Adresse aufgelöst.

TIP1-A_6977 - Auflösen von URI in IP-Adresse

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, SOLLEN eine Auflösung von Netzwerk-URI in IP-Adresse als Plattformleistung PL_TUC_NET_NAME_RESOLUTION über die Schnittstelle I_DNS_Name_Resolution zum TI-Namensdienst gemäß [gemSpec_Net#Namensdienst] anbieten. [<=]

10.2.3 PL_TUC_NET_SYNC_TIME

Über den Systemprozess PL_TUC_NET_SYNC_TIME können sich Dienste und Komponenten der Telematikinfrastruktur mit dem Zeitserver der zentralen TI-Plattform synchronisieren.

TIP1-A_6978 - Synchronisierung mit Zeitdienst

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN eine Zeitsynchronisation als Plattformleistung PL_TUC_NET_SYNC_TIME über die Schnittstelle I_NTP_Time_Informationen zum Zeitdienst der Telematikinfrastruktur gemäß [gemSpec_Net#Zeitdienst] umsetzen und diese TI-Zeit als gültige, gesetzliche Zeit betrachten. [<=]

10.3 Vertraulichkeit, Authentizität, Integrität

10.3.1 PL_TUC_SIGN_HASH_nonQES – mit Karten-Identität signieren

Der Systemprozess PL_TUC_SIGN_HASH_nonQES versieht einen übergebenen Hash-Wert mit einer kartenbasierten digitalen nonQES Signatur. Dazu wird unter Verwendung der Karteninhaberidentität einer SmartCard der TI ein Binärwert von der entsprechenden Karte als Identitätsträger signiert.

TIP1-A_6979 - Leistung der kartenbasierten elektronischen Signatur

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN das Signieren eines Hashwertes mit einer Kartenidentität als Plattformleistung PL_TUC_SIGN_HASH_nonQES gemäß [gemSpec_CardProxy] cardOperation für private Schlüsselobjekte umsetzen. [<=]

TIP1-A_6980 - Aufrufparameter der kartenbasierten elektronischen Signatur

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_SIGN_HASH_nonQES umsetzen, MÜSSEN vom Nutzenden den IDENTIFIKATOR des privaten Schlüssels der Kartenidentität gemäß [gemSpec_CardProxy#Konfigurationstabelle CardProxy], das SIGNATURVERFAHREN gemäß [gemSpec_CardProxy] (RSASSA-PKCS1-v1_5 oder ECDSA für TLS-Authentisierung, RSASSA-PSS für SAML) als Aktionsparameter sowie den zu signierenden HASHWERT als Eingangsparameter entgegennehmen und in der Umsetzung von cardOperation verwenden. [<=]

TIP1-A_6981 - Ergebnis der kartenbasierten elektronischen Signatur

Produkttypen und Dienste der TI die eine Plattformleistung PL_TUC_SIGN_HASH_nonQES umsetzen, MÜSSEN das Ergebnis gemäß [gemSpec_CardProxy] cardOperation zurückmelden:

1.   OK + Hashsignatur            „Signatur erfolgreich erstellt“

2.   SecurityStatusNotSatisfied        „Aktion nicht erlaubt“

3.   ObjectNotFound            „IDENTIFIKATOR ungültig”

4.   KeyInvalid                „Schlüsselobjekt nicht verwendbar“

5.   CardTerminated            „Karte nicht mehr verwendbar”

6.   WrongToken            „Übergabeparameter fehlerhaft“

[<=] 

10.3.2 PL_TUC_HYBRID_ENCIPHER – Hybrid verschlüsseln

Der Systemprozess PL_TUC_HYBRID_ENCIPHER führt eine hybride Verschlüsselung eines Dokuments durch. Dazu muss zunächst ein symmetrischer Schlüssel erzeugt werden, mit dem das Eingabedokument verschlüsselt wird. Dieser symmetrische Schlüssel wird anschließend mit dem öffentlichen Schlüsselmaterial des Dokumentenempfängers (bereitgestellt über ein X.509v3-Zertifikat) verschlüsselt und an das Dokument angefügt.

TIP1-A_6982 - Leistung zum hybriden Verschlüsseln

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN eine Plattformleistung PL_TUC_HYBRID_ENCIPHER zum hybriden Verschlüsseln eines Dokuments umsetzen. [<=]

TIP1-A_6983 - Aufrufparameter zum hybriden Verschlüsseln

Produkttypen und Dienste der TI, die die Plattformleistung PL_TUC_HYBRID_ENCIPHER umsetzen, MÜSSEN vom Nutzenden die Aufrufparameter

1.   Doc        „das zu verschlüsselnde Dokument“

2.   Cert        „das Empfänger-/Ziel-Zertifikat“

entgegennehmen. [<=] 

TIP1-A_6984 - Ablauf der hybriden Verschlüsselung eines Dokuments

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_HYBRID_ENCYPHER umsetzen, MÜSSEN die Schritte zum Verschlüsseln eines gegebenen Dokuments in der angegebenen Reihenfolge durchführen:

[<=] 

10.3.3 PL_TUC_HYBRID_DECIPHER – Hybrid entschlüsseln

Der Systemprozess PL_TUC_HYBRID_DECIPHER entschlüsselt ein hybrid verschlüsseltes Dokument. Dazu wird zunächst der verschlüsselte Dokumentenschlüssel aus dem Eingabedokument extrahiert und mit einem privaten Schlüssel auf einer im Zugriff befindlichen SmartCard entschlüsselt. Mit diesem wiederhergestellten Dokumentenschlüssel wird anschließend das Dokument in einem symmetrischen Verfahren entschlüsselt.

TIP1-A_6985 - Leistung zum hybriden Entschlüsseln

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN eine Plattformleistung PL_TUC_HYBRID_DECIPHER zum hybriden Entschlüsseln eines Dokuments umsetzen. [<=]

TIP1-A_6986 - Aufrufparameter zum hybriden Entschlüsseln

Produkttypen und Dienste der TI, die die Plattformleistung PL_TUC_HYBRID_DECIPHER umsetzen, MÜSSEN vom Nutzenden den Aufrufparameter

1.   D        „das verschlüsselte Dokument“

entgegennehmen. [<=] 

TIP1-A_6987 - Ablauf der hybriden Entschlüsselung eines Dokuments

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_HYBRID_DECYPHER umsetzen, MÜSSEN die Schritte zum Entschlüsseln eines verschlüsselten Dokuments in der angegebenen Reihenfolge durchführen:

[<=] 

10.3.4 PL_TUC_SIGN_DOCUMENT_nonQES – Dokument signieren

Auf der eGK ist nach aktueller Spezifikationslage kein kryptografisches Schlüsselmaterial für eine Content-Signatur vorhanden.

10.4 Leistungen der PKI

10.4.1 PL_TUC_PKI_VERIFY_CERTIFICATE – Prüfung eines Zertifikats der TI

Der Systemprozess PL_TUC_PKI_VERIFY_CERTIFICATE kapselt die Prüfung eines X.509-Zertifikats der PKI der Telematikinfrastruktur. Es wird die zeitliche Gültigkeit zu einem Referenzzeitpunktes sowie die mathematische Gültigkeit geprüft. Zusätzlich kann via Parameter eine Online-Prüfung des Sperrstatus des Zertifikats verlangt werden.

TIP1-A_6991 - Leistung zur Prüfung eines Zertifikats in der TI

Produkttypen und Dienste, welche Systemprozesse der TI realisieren, MÜSSEN eine Zertifikatsprüfung als Plattformleistung PL_TUC_PKI_VERIFY_CERTIFICATE gemäß [gemSpec_PKI#TUC_PKI_018] umsetzen. [<=]

TIP1-A_6992 - Aufrufparameter der Zertifikatsprüfung in der TI

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_PKI_VERIFY_CRTIFICATE umsetzen, MÜSSEN vom Nutzenden die folgenden Parameter entgegennehmen und in der Zertifikatsprüfung in TUC_PKI_018 verwenden:

1.   Zu prüfendes Zertifikat        ein Zertifikat der PKI der TI

2.   Referenzzeitpunkt            Prüfung auf Gültigkeit zu Referenzzeitpunkt

3.   PolicyList                zulässige Zertifikatstyp-OIDs

4.   KeyUsage                Anwendungsfall für kryptografisches Material

5.   ExtendedKeyUsage        Anwendungsfall für kryptografisches Material

6.   OCSP-Graceperiod            default: 10 Min

7.   Offline-Modus            ja/nein (wenn nein, dann Prüfmodus: OCSP)

8.   OCSP-Response            optional

9.   Timeout:                default: 10 Sek.

10.   TOLERATE_OCSP_FAILURE:    ja/nein, default: „nein“

[<=] 

TIP1-A_6993 - Ergebnis der Zertifikatsprüfung in der TI

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_PKI_VERIFY_CERTIFICATE umsetzen, MÜSSEN das Ergebnis jedes Prüfkriteriums und Fehler in der Zertifikatsprüfung in TUC_PKI_018 zurückmelden:

Fehler in der Verarbeitung beeinflussen die Prüfergebnisse des TUC_PKI_018 wie folgt:

1.   CERT_READ_ERROR, das Zertifikat kann nicht geprüft werden

2.   CA_CERT_MISSING oder AUTHORITYKEYID_DIFFERENT, das Zertifikat darf nicht als gültig betrachtet werden, da kein gültiges Ausstellerzertifikat gefunden wurde.

3.   OCSP_CERT_MISSING oder OCSP_SIGNATURE_ERROR, die Legitimität einer OCSP-Response kann nicht verifiziert werden, die OCSP-Prüfung muss abgebrochen werden und das Zertifikat ist nicht online-gültig

4.   CERTHASH_EXTENSION_MISSING, CERTHASH_MISSMATCH, WARNING_CERT_UNKNOWN, die OCSP-Prüfung ist nicht erfolgreich und das Zertifikat ist nicht online-gültig

[<=]