gemSpec_CardProxy_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Übergreifende Spezifikation

Card Proxy

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
02.08.17
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_CardProxy
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegende übergreifende Spezifikation definiert Anforderungen für den Themenbereich „Ansteuerung von Smartcards in der Telematikinfrastruktur“, die bei der Realisierung (bzw. dem Betrieb) von Produkttypen der TI zu beachten sind. Diese Anforderungen sind als übergreifende Regelungen relevant für Interoperabilität und Verfahrenssicherheit.

Die Telematikinfrastruktur im deutschen Gesundheitswesen setzt Smartcards an diversen Stellen ein. Als prominente Vertreter seien an dieser Stelle die elektronische Gesundheitskarte eGK und der Heilberufeausweis HBA genannt. Die gematik spezifiziert im Auftrag ihrer Gesellschafter sowohl die Smartcards, als auch die Fachanwendungen, welche diese Smartcards nutzen.

Im Rahmen der Spezifikation von Fachanwendungen werden Abläufe beschrieben, in die möglicherweise auch Smartcards eingebunden sind. Die in diesem Dokument spezifizierte Komponente „Card Proxy“ beschreibt die Nutzung der Smartcards so generisch, dass beispielsweise ein Wechsel der Kartengeneration typischerweise keine Auswirkung auf die Spezifikation von Fachanwendungen hat. Zusätzlich ist die Schnittstelle, die Card Proxy dabei bereitstellt, so einfach, dass ein detailliertes Wissen über Smartcards nicht erforderlich ist, um Fachanwendungen hinreichend genau zu spezifizieren.

Dieses Dokument impliziert nicht, dass es eine dedizierte Komponente „Card Proxy“ als eigenständigen Produkttypen gibt, oder dass so eine Komponente zwingend Bestandteil eines kartennutzenden Produkttypen wird (etwa des Konnektors). Es ist eher so, dass über einen solchen kartennutzenden Produkttypen Interaktionen mit Smartcards ausgelöst werden. Beispielsweise „Ändere PIN“ an einem AdV-Terminal. Dann liefert die Beschreibung der fachlichen Abläufe in Verbindung mit den dortigen Aufrufen von Card Proxy die Interaktionen, die an der Schnittstelle zur jeweiligen Smartcard sichtbar werden. In diesem Sinne hilft das vorliegende Dokument zu Card Proxy

1. bei der Beschreibung fachlicher Abläufe, da dort auch komplexe Kartenoperationen als einfache Funktionsaufrufe beschreibbar sind,
2. bei der Implementierung kartennaher Aktionen, da die Kapitel 6 und 9 so fein granular die Interaktionen mit einer Smartcard beschreiben, dass damit sofort Code erzeugbar ist und
3. bei der Beschreibung Testerwartungshaltung an der Kartenschnittstelle, da die detaillierte Beschreibung insbesondere in Kapitel 9 direkt zur Testerwartungshaltung führt.

1.2 Zielgruppe

Das Dokument ist hilfreich für die Spezifikation von Komponenten, welche Smartcards der Telematikinfrastruktur nutzen, weil der Zugriff und die Nutzung von Smartcards sich mit der hier beschriebenen Schnittstelle zum Card Proxy einfacher beschreiben lässt.

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 (zum Beispiel Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Die Festlegungen des Dokuments gelten derzeit ausschließlich im Zusammenhang mit den Anwendungen des Versichterten (AdV) – konkret für den Server–Anteil der Kostenträger-AdV.

Wichtiger 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

Es ist keine Abgrenzung gegenüber anderen Spezifikationen/Konzepten oder im Kontext derzeit nicht relevanten Themen erforderlich.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet. Abwandlungen von „MUSS“ zu „MÜSSEN“ etc. sind der Grammatik geschuldet.

Da im Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet.

Anforderungen werden im Dokument wie folgt dargestellt:

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

Dabei umfasst die Anforderung sämtliche innerhalb der Textmarken angeführten Inhalte.

1.6 Hinweis auf offene Punkte

Das Kapitel wird in einer späteren Version des Dokumentes ergänzt.

2 Konzept

2.1 Konzept der Komponente Card Proxy

Das Konzept zur Komponente Card Proxy basiert auf den folgenden Annahme: Fachanwendungen sind rein für die fachlichen Aspekte einer Anwendung zuständig. Fachanwendungen kennen zumindest den Namen und den Typ der Artefakte in denen ihre Daten auf einer Karte gespeichert sind. Fachanwendungen wissen, wie Daten in den ihnen zugeordneter Dateien gespeichert sind (XML, ASN.1, TLV, gezippt, …).

Für Fachanwendungen ist es irrelevant

1. wo die Artefakte auf einer Karte liegen,
2. welche Zugriffsrechte zum Ausführen von Aktionen erforderlich sind,
3. wie erforderliche Zugriffsrechte erworben werden können, oder
4. wie auf Daten zugegriffen oder gewisse Aktionen ausgeführt werden,

weil diese Informationen von Card Proxy gekapselt werden.

Card Proxy enthält pro unterstütztem Produkttyp (beispielsweise eGK G1, eGK G1+, eGK G2, …, SMC-B, …) eine Datenbank mit folgenden Informationen:

1. Eineindeutiger Identifikator eines Artefaktes: Dieser wird an der Schnittstelle zum Card Proxy verwendet um Artefakte zu adressieren.
2. Ort eines Artefaktes: Diese Information wird von Card Proxy verwendet um ein Artefakt innerhalb einer Karte zu adressieren.
3. Aktionen, die mit einem Artefakt ausführbar sind: Je nach Typ sind Aktionen aus der Menge {lesen, schreiben, …} oder aber {verschlüsseln, entschlüsseln, signieren, …} oder aber {verifizieren, entsperren, …} relevant.
4. Pro Aktion eine Zugriffsbedingung, die für eine erfolgreiche Aktion erfüllt sein muss, beispielsweise:

1. lesen: MRPIN.XYZ
2. schreiben: PIN.abc AND AuthentisierungMitFlag.ijk

Diese Datenbank ist im Wesentlichen ein spezifischer Auszug aus der zugehörigen Objektsystemspezifikation. Die Datenbank enthält maximal die Aktionen, die gemäß Objektsystemspezifikation erlaubt sind. Jede darüber hinausgehende Aktion würde von der Karte abgewiesen. Es ist denkbar, dass die Datenbank weniger Aktionen enthält, als per Objektsystemspezifikation möglich. Dann würde Card Proxy eine Aktion, die über das von der Datenbank erlaubte hinausgeht, unterbinden, auch wenn so eine Aktion laut Objektsystemspezifikation möglich ist.

Hinweis (1) In diesem Dokument wird lediglich Card Proxy vor dem Hintergrund KTR-AdV betrachtet. Allerdings ist Card Proxy konzeptionell so angelegt, dass Card Proxy auch in anderen Umgebungen einsetzbar wäre, etwa in LE-AdV. Im Allgemeinen wird die Datenbank eGK G2 je nach Umgebung einen anderen Inhalt haben. Das bedeutet beispielsweise, dass die Datenbank einer eGK für ein AdV Terminal etwa die Aktion „Zugriffsprotokol lesen“ enthält, während so ein Eintrag in der Datenbank einer eGK in einer Arztumgebung nicht vorhanden ist.

2.2 Konzept der Komponente Kartenterminal Proxy

Das Konzept zu Card Proxy setzt voraus, dass Card Proxy eine Schnittstelle zu einem Kartenterminal Proxy besitzt, der wiederum Zugriff auf eine Smartcard hat. Es wird davon ausgegangen, dass die Komponente Kartenterminal Proxy alle herstellerspezifischen Aspekte eines Kartenterminals kapselt.

Falls beispielsweise ein Sicherheitsklasse-1-Kartenleser zur Verfügung steht und Card Proxy stößt eine Benutzerverifikation an, dann sorgt der Kartenterminal Proxy in diesem Fall dafür, dass der Benutzer an der „ganz normalen“ Ausgabe (Bildschirm oder ähnliches) zur Eingabe der PIN aufgefordert wird. Der Kartenterminal Proxy wird in diesem Fall die PIN von der „ganz normalen“ Eingabe (Tastatur oder ähnliches) entgegennehmen.

Falls zu einem anderen Zeitpunkt ein Sicherheitsklasse 3 Kartenleser zur Verfügung steht und Card Proxy stößt wieder eine Benutzerverifikation an, dann wird der Kartenterminal Proxy den Benutzer idealerweise am Display des Kartenlesers zur PIN-Eingabe auffordern und den Sicherheitsklasse-3-Kartenleser so ansteuern, dass die PIN am PIN-Pad eingegeben wird und direkt zur Karte gelangt. Die PIN verlässt in diesem Fall die Hardware des Sicherheitsklasse-3-Kartenlesers nicht.

Falls eine kontaktlose Verbindung zu einer Karte aufgebaut wird, dann kapselt der Kartenterminal Proxy auch die PACE Authentisierung und den dabei etablierten sicheren Kanal, ohne dass Card Proxy oder übergeordnete Komponenten davon berührt wären.

Da dieses Dokument auf Card Proxy fokussiert, werden im Folgenden nur solche Aktionen für die Komponente Kartenterminal Proxy betrachtet, die für Card Proxy relevant sind.

Falls zu einem späteren Zeitpunkt die Komponente „Kartenterminal Proxy“ ausführlich in einem eigenen Dokument behandelt wird, dann wären die folgenden Unterkapitel durch Referenzen in so ein Dokument zu ersetzen.

2.2.1 Aktion „Karte verfügbar“

Falls das Ereignis „Karte verfügbar“ am Kartenterminal Proxy eintritt sind für Card Proxy folgende Aspekte relevant:

Typischerweise enthalten kontaktbehaftete Kartenleser einen Sensor, der erkennt, wenn eine Smartcard gesteckt wird. Der Kartenterminal Proxy aktiviert die Smartcard und prüft, ob ein ATR empfangen wird. Falls kein ATR empfangen wird, so kann dies verschiedene Ursachen haben (Karte falsch gesteckt, Karte defekt, …), die hier nicht weiter betrachtet werden.

Auch kontaktlose Kartenleser erkennen typischerweise anhand von Sensoren, dass eine Smartcard im Feld des Lesers verfügbar ist und bauen einen Kommunikationskanal zu diesen auf.

Der Kartenterminal Proxy sendet an den Card Proxy das Signal „Karte verfügbar“, wenn der Kommunikationskanal zur Smartcard so geöffnet ist, dass APDU zwischen Smartcard und Kartenterminal ausgetauscht werden können.

2.2.2 Aktion „Karte entfernt“

Typischerweise erkennen Kartenleser, dass eine Smartcard aus dem Leser entfernt wurde. In diesem Fall informiert der Kartenterminal Proxy den Card Proxy über das Signal „Karte entfernt“ über dieses Ereignis.

2.2.3 Ändern eines Benutzergeheimnisses

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Ändern eines Benutzergeheimnisses, welche vom Card Proxy genutzt wird, siehe 9.4.2 Schritt 3)e) in der Variante mode=replace. Der Fall mode=set wird in 2.2.7 behandelt.

Die Umgebung erfragt vom Benutzer den alten und den neuen PIN-Wert. Es wird empfohlen, dass die vom Benutzer eingegebene Ziffernfolge für den neuen PIN-Wert anhand der von Card Proxy übergebenen Parameter minimumLength und maximumLength auf Plausibilität geprüft wird.

Die Ziffernfolgen für alten und neuen PIN-Wert werden von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierten Ziffernfolgen werden an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 1 zeigt einige Beispiele, die im Folgenden näher erläutert werden:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1, das durch die Änderung auch von vier auf fünf Stellen verlängert wird.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3, das durch die Änderung auch von neun auf sechs Stellen verkürzt wird.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12, das durch die Änderung auch von zwölf auf vier Stellen verkürzt wird.

Tabelle 1: Beispiele für die Erzeugung einer Kommando APDU, PIN ändern

2.2.4 Ausschalten Notwendigkeit Benutzerverifikation

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Ausschalten der Notwendigkeit eine Benutzerverifikation durchzuführen, welche vom Card Proxy genutzt wird, siehe 9.4.5 Schritt 3)e). Im Rahmen der Aktion erfragt die Umgebung vom Benutzer typischerweise eine PIN. Es wird empfohlen, dass die vom Benutzer eingegebene Ziffernfolge anhand der von Card Proxy übergebenen Parameter minimumLength und maximumLength auf Plausibilität geprüft wird. Die Ziffernfolge wird von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierte Ziffernfolge wird an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 2 zeigt einige Beispiele, die im Folgenden näher erläutert werden:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1, wobei zum Ausschalten das vierstellige Benutzergeheimnis mitgesendet wird.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3, wobei zum Ausschalten das neunstellige Benutzergeheimnis mitgesendet wird.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12, wobei zum Ausschalten kein Benutzergeheimnis mitgesendet wird.

Tabelle 2: Beispiele für die Erzeugung einer Kommando APDU, disable

2.2.5 Benutzerverifikation

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zur Benutzerverifikation, welche vom Card Proxy genutzt wird, siehe 9.4.10 Schritt 3)e). Im Rahmen der Benutzerverifikation erfragt die Umgebung vom Benutzer eine PIN. Es wird empfohlen, dass die vom Benutzer eingegebene Ziffernfolge anhand der von Card Proxy übergebenen Parameter minimumLength und maximumLength auf Plausibilität geprüft wird. Die Ziffernfolge wird von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierte Ziffernfolge wird an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 3 zeigt einige Beispiele, die im Folgenden näher erläutert werden:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1 und der Verifikation eines vierstelligen Benutzergeheimnisses.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3 und der Verifikation eines neunstelligen Benutzergeheimnisses.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12 und der Verifikation eines zwölfstelligen Benutzergeheimnisses.

Tabelle 3: Beispiele für die Erzeugung einer Kommando APDU, verify

Hinweis (2) Der Card Proxy erhebt keine Anforderungen, wie die Umgebung die Funktion zur Benutzerauthentisierung implementiert. Folgende Fälle sind denkbar, die sinngemäß auch auf die übrigen Beispiele mit Passwortobjekten in 2.2 übertragbar sind:

1. Die Umgebung erfragt vom Benutzer das Geheimnis (PIN) und sendet ein passendes Verify Kommando zur Karte. Die Antwortnachricht dieses Verify Kommandos wird zurückgemeldet.
2. Es ist denkbar, dass die Umgebung anhand der Antwortnachricht auf das erste Verify Kommando
• einen Transportschutz oder eine blockierte PIN erkennt und dieses Problem selbständig beseitigt, bevor ein erneutes Verify Kommando gesendet wird.
• eine fehlerhafte PIN-Eingabe erkennt und den Benutzer selbständig ein weiteres Mal zur Eingabe des Geheimnisses auffordert, bevor ein erneutes Verify Kommando gesendet wird.
3. Falls der Benutzer das Geheimnis zu oft hintereinander falsch eingibt und dabei das Passwortobjekt blockiert, könnte die Umgebung mit einer passenden Fehlermeldung abbrechen oder selbständig versuchen die Blockade wieder zu lösen.
4. Weitere Fälle sind denkbar.

2.2.6 Einschalten Notwendigkeit Benutzerverifikation

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Einschalten der Notwendigkeit eine Benutzerverifikation durchzuführen, welche vom Card Proxy genutzt wird, siehe 9.4.6 Schritt 3)e). Im Rahmen der Aktion erfragt die Umgebung vom Benutzer typischerweise eine PIN. Es wird empfohlen, dass die vom Benutzer eingegebene Ziffernfolge anhand der von Card Proxy übergebenen Parameter minimumLength und maximumLength auf Plausibilität geprüft wird. Die Ziffernfolge wird von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierte Ziffernfolge wird an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 4 zeigt einige Beispiele, die im Folgenden näher erläutert werden:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1, wobei zum Einschalten das vierstellige Benutzergeheimnis mitgesendet wird.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3, wobei zum Einschalten das neunstellige Benutzergeheimnis mitgesendet wird.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12, wobei zum Einschalten kein Benutzergeheimnis mitgesendet wird.

Tabelle 4: Beispiele für die Erzeugung einer Kommando APDU, enable

2.2.7 Setzen eines Benutzergeheimnisses

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Setzen eines Benutzergeheimnisses, welche vom Card Proxy genutzt wird, siehe 9.4.2 Schritt 3)e) in der Variante mode=set. Der Fall mode=replace wird in 2.2.3 behandelt.

Die Umgebung erfragt vom Benutzer den neuen PIN-Wert. Es wird empfohlen, dass die vom Benutzer eingegebene Ziffernfolge für den neuen PIN-Wert anhand der von Card Proxy übergebenen Parameter minimumLength und maximumLength auf Plausibilität geprüft wird.

Die Ziffernfolge für den neuen PIN-Wert wird von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierten Ziffernfolgen werden an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 5 zeigt einige Beispiele, die im Folgenden näher erläutert werden:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1 und dem Setzen eines vierstelligen Benutzergeheimnisses.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3 und dem Setzen eines sechsstelligen Benutzergeheimnisses.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12 und dem Setzen eines zwölfstelligen Benutzergeheimnisses.

Tabelle 5: Beispiele für die Erzeugung einer Kommando APDU, set PIN

2.2.8 UnblockWithPukAndSet

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Entsperren eines Benutzergeheimnisses, welche vom Card Proxy genutzt wird, siehe 9.4.9 Schritt 3)e) in der Variante mode=UnblockWithPuKAndSet.

Die Umgebung erfragt vom Benutzer die PUK und den neuen PIN-Wert. Es wird empfohlen, dass die vom Benutzer eingegebene Ziffernfolge für den neuen PIN-Wert anhand der von Card Proxy übergebenen Parameter minimumLength und maximumLength auf Plausibilität geprüft wird. Die PUK besteht stets aus acht Ziffern.

Die Ziffernfolgen PUK und neuer PIN-Wert werden von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierten Ziffernfolgen werden an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 6 zeigt einige Beispiele, die im Folgenden näher erläutert werden, wobei die PUK, wie in der Telematikinfrastruktur üblich, stets acht Stellen lang ist:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1 und dem Setzen eines fünfstelligen Benutzergeheimnisses.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3 und dem Setzen eines sechsstelligen Benutzergeheimnisses.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12 und dem Setzen eines zwölfstelligen Benutzergeheimnisses.

Tabelle 6: Beispiele für die Erzeugung einer Kommando APDU, unblock PUK set

2.2.9 UnblockWithPuk

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Entsperren eines Benutzergeheimnisses, welche vom Card Proxy genutzt wird, siehe 9.4.9 Schritt 3)e) in der Variante mode=UnblockWithPuK.

Die Umgebung erfragt vom Benutzer die PUK. Die PUK besteht stets aus acht Ziffern.

Die Ziffernfolge PUK wird von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierte Ziffernfolge wird an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 7 zeigt einige Beispiele, die im Folgenden näher erläutert werden, wobei die PUK, wie in der Telematikinfrastruktur üblich, stets acht Stellen lang ist:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12.

Tabelle 7: Beispiele für die Erzeugung einer Kommando APDU, unblock PUK

2.2.10 UnblockAndSet

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Entsperren eines Benutzergeheimnisses, welche vom Card Proxy genutzt wird, siehe 9.4.9 Schritt 3)e) in der Variante mode=UnblockAndSet.

Die Umgebung erfragt vom Benutzer den neuen PIN-Wert. Es wird empfohlen, dass die vom Benutzer eingegebene Ziffernfolge für den neuen PIN-Wert anhand der von Card Proxy übergebenen Parameter minimumLength und maximumLength auf Plausibilität geprüft wird.

Die Ziffernfolge des neuen PIN-Wertes wird von der Umgebung gemäß Format-2-PIN-Block codiert, siehe 12.3. Die so codierte Ziffernfolge wird an den Parameter commandApduPart angehängt und dann zur Karte gesendet.

Tabelle 8 zeigt einige Beispiele, die im Folgenden näher erläutert werden:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1 und dem Setzen eines fünfstelligen Benutzergeheimnisses.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3 und dem Setzen eines sechsstelligen Benutzergeheimnisses.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12 und dem Setzen eines zwölfstelligen Benutzergeheimnisses.

Tabelle 8: Beispiele für die Erzeugung einer Kommando APDU, unblock set

2.2.11 Unblock

Der Kartenterminal Proxy als Teil der Umgebung implementiert eine Funktion zum Entsperren eines Benutzergeheimnisses, welche vom Card Proxy genutzt wird, siehe 9.4.9 Schritt 3)e) in der Variante mode=Unblock. Da in dieser Variante vom Benutzer keine Daten zu erfassen sind, wird in dieser Variante der Parameter commandApduPart unverändert als Kommando APDU verwendet.

Tabelle 9 zeigt einige Beispiele, die im Folgenden näher erläutert werden:

1. Beispiel 1: Globales Passwortobjekt mit pwdIdentifier=‘01‘=1.
2. Beispiel 2: DF-spezifisches Passwortobjekt pwdIdentifier=‘03‘=3.
3. Beispiel 3: DF-spezifisches Passwortobjekt pwdIdentifier=‘0C‘=12.

Tabelle 9: Beispiele für die Erzeugung einer Kommando APDU, unblock

3 Bausteine innerhalb von Card Proxy

1. channelContext analog zu [gemSpec_COS#(N029.900)] mit den Punkten:
1. (N029.900)a     currentFolder plus dessen logischem Wert von lifeCycleStatus, woraus sich die jeweils gültige Zugriffsregel ergibt.
2. (N029.900)c     keyReferenceList
3. (N029.900)e     globalSecurityList
4. (N029.900)f     dfSpecificSecurityList
5. (N029.900)h     bitSecurityList
6. (N029.900)i     globalPasswordList
7. (N029.900)j     dfSpecificPasswordList
8. (N029.900)m     currentEF plus dessen logischem Wert von lifeCycleStatus, woraus sich die jeweils gültige Zugriffsregel ergibt.
2. SupportedActions: Pro unterstütztem Kartentyp eine Datenbank mit adressierbaren Objekten, Aktionen und Zugriffsbedingungen. Beispiele dazu finden sich in Kapitel 8.
3. CV-CertificateStore: Speicher mit Root und Sub-CA-CV-Zertifikaten sowie dem End-Entity-CV-Zertifikat der SM-B im AdV-Server.
4. StatusTransparentChannel: open oder closed.
5. Buffersize, enthält Informationen über die maximale Größe einer Nachricht, die zu einer Smartcard geschickt werden, oder von dort abgeholt werden kann.
6. Sicherheitsstatus: Hier wird gespeichert, für welche Passwortobjekte ein Sicherheitszustand in der Smartcard gesetzt wurde und Rollen bzw. Flaglisten per Card-2-Card in der Smartcard authentisiert wurden. Diese Informationen werden in Kapitel 10 benötigt. Alternativ ist es möglich den Sicherheitszustand
1. eines Passwortobjektes von der Smartcard mittels cardOperation(IdentifikatorDesPasswortObjektes, getStatus) zu erfragen und
2. einer Flaglist cardOperation(„Wildcard“, getSecurityStatusFlagList, oid, flagList) und
3. einer Rolle mittels cardOperation(„Wildcard“, getSecurityStatusRole, role).

4 Ablauf einer Kartensession

In diesem Kapitel wird davon ausgegangen, dass Card Proxy vom Kartenterminal Proxy über die Ereignisse „Karte verfügbar“ (siehe 2.2.1) und „Karte entfernt“ (siehe 2.2.2) informiert wird. Dieses Kapitel betrachtet die Aktionen, die Card Proxy in so einem Fall durchführt.

4.1 Signal „Karte verfügbar“ empfangen

Sobald Card Proxy das Signal „Karte verfügbar“ empfängt ist eine Kommunikation zwischen Card Proxy und der Smartcard möglich. Der Card Proxy ermittelt dann zunächst die Stammdaten der Smartcard und meldet diese an die Umgebung. Sobald die Umgebung die Stammdaten der Smartcard empfangen hat, ist es für die Umgebung möglich über den Card Proxy mit der Smartcard zu arbeiten.

Die Ermittlung der Stammdaten startet mit der Abfrage in 4.1.1.

4.1.1 Kartentyp ermitteln

Card Proxy sendet eine Select Kommando gemäß [gemSpec_COS#(N041.300)] an die Smartcard: Selektiere das Wurzelverzeichnis, Antwortdaten mit File Control Parametern FCP, Kommando APDU = ´00 A4 04 04 00 0000´.

Falls die Antwortnachricht einen Trailer enthält, der nicht Element der Menge {

1. ´62 83´ = FileDeactivated,
2. ´62 85´ = FileTerminated,
3. ´90 00´ = NoError

} ist, dann meldet Card Proxy der Umgebung in den Stammdaten den Kartentyp „ungültig“.

Andernfalls wird in den FCP nach einem applicationIdentifier gesucht. Falls die FCP einen applicationIdentifier mit dem Wert

1. ´D276 0001 44 80 00´    enthalten  eGK,         weiter mit 4.1.2
2. ´D276 0001 46 01´     enthalten  HBA,         weiter mit 4.1.3
3. ´D276 0001 46 06´     enthalten  SMC-B,         weiter mit 4.1.4
4. ´D276 0001 44 80 01´     enthalten  gSMC-K,     weiter mit 4.1.5
5. ´D276 0001 44 80 01´     enthalten  gSMC-KT,     weiter mit 4.1.6

Falls keiner der vorgenannten applicationIdentifier vorhanden ist, dann meldet Card Proxy der Umgebung in den Stammdaten den Kartentyp „ungültig“.

4.1.2 eGK, Kartengeneration ermitteln

1. Kartengeneration ermitteln:
1. Es wird eine cardOperation(EF.Version, read) ausgeführt. Falls der Inhalt des ersten Rekords
1. ´003 000 0000´ ist, dann liegt eine Generation 1 eGK vor. Dem Inhalt des zweiten Rekords wird die Version des Objektsystems entnommen, weiter mit 4.1.2.1.
2. ´004 000 0000´ ist, dann liegt eine Generation 2 eGK vor. Weiter mit 4.1.2.2.

4.1.2.1 Generation 1 eGK, weitere Stammdaten ermitteln

1. Puffergrößen ermitteln für G1 eGK: Es wird eine cardOperation(EF.ATR, read) ausgeführt. Der Inhalt des Datenobjektes mit Tag ´E0´ wird gemäß [gemSpec_Karten_Fach_TIP#Card-G2-A_2386] ausgewertet und die dort angegebenen Puffergrößen werden in den Baustein Buffersize übernommen.
2. Eine G1 eGK enthält keine Produkttypversion für das COS. Implizit ergibt sich die Produkttypversion aber bereits aus der Information „G1 eGK“.
3. Eine G1 eGK enthält keine Produkttypversion für das Objektsystem. Implizit ergibt sich die Produkttypversion aber dem zweiten Rekord von EF.Version, der bereits in 4.1.2 Punkt 1)a) ausgelesen wurde. Aus dem Inhalt des zweiten Rekords lassen sich die Typen G1 und G1+ unterscheiden.
4. End-Entity-CV-Zertifikat auslesen: Es wird aus EF.C.eGK.AUT_CVC ausgelesen.
5. Konditional: Falls das Sub-CA-CV-Zertifikat zu C.eGK.AUT_CVC nicht im Baustein CV-CertificateStore gespeichert ist, wird diese aus EF.C.CA_eGK.CS ausgelesen und im Baustein CV-CertificateStore gespeichert.
6. Falls beim Import der CV-Zertifikate in den Baustein CV-CertificateStore festgestellt wird, dass
1. mindestens eines der CV-Zertifikate nicht gültig ist, dann meldet Card Proxy der Umgebung in den Stammdaten den Kartentyp „ungültig“.
2. alle CV-Zertifikate gültig sind, wird dem End-Entity-CV-Zertifikat die ICCSN entnommen sowie der öffentliche Schlüssel PuK.C.eGK.AUT_CVC.
7. Die Echtheit (nicht die Gültigkeit) der Smartcard wird geprüft. Dazu werden folgende Schritte ausgeführt:
1. Es wird eine cardOperation(PrK.eGK.AUT_CVC, rsaRoleAuthentication) durchgeführt.
2. Die Signatur aus dem vorherigen Internal Authenticate Kommando wird mittels PuK.eGK_AUT_CVC geprüft. Falls die Signaturprüfung
1. nicht erfolgreich verläuft, dann wird als Kartentyp „ungültig“ in die Stammdaten eingetragen.
2. erfolgreich verläuft, dann wird in den Stammdaten die Smartcard als „echt“ gekennzeichnet.
3. Die Stammdaten werden an die Umgebung gemeldet und bestehen dabei entweder nur aus „Kartentyp ungültig“, oder aus den folgenden Artefakten:
1. Kartentyp,
2. Produkttypversion COS,
3. Produkttypversion Objektsystem,
4. ICCSN und
5. Smartcard „echt“.

4.1.2.2 Generation 2 eGK, weitere Stammdaten ermitteln

1. Puffergrößen ermitteln für G2 eGK: Es wird eine cardOperation(EF.ATR, read) ausgeführt. Der Inhalt des Datenobjektes mit Tag ´E0´ wird gemäß [gemSpec_Karten_Fach_TIP#Card-G2-A_2386] ausgewertet und die dort angegebenen Puffergrößen werden in den Baustein Buffersize übernommen.
2. Die Produkttypversion des COS wird dem Inhalt des EF.ATR entnommen, siehe [gemSpec_Karten_Fach_TIP# Card-G2-A_3488].
3. Die Produkttypversion des vorhandenen Objektsystems wird EF.Version2 entnommen, siehe [gemSpec_Karten_Fach_TIP# Tab_Karten_Fach_TIP_002] und dort das Datenobjekt mit dem „Pfad“ ‘EF‘  ‘C1‘.
4. End-Entity-CV-Zertifikat auslesen: Es wird aus EF.C.eGK.AUT_CVC.E256 ausgelesen.
5. Konditional: Falls das Sub-CA-CV-Zertifikat zu C.eGK.AUT_CVC nicht im Baustein CV-CertificateStore gespeichert ist, wird diese aus EF.C.CA_eGK.CS.E256 ausgelesen und im Baustein CV-CertificateStore gespeichert.
6. Falls beim Import der CV-Zertifikate in den Baustein CV-CertificateStore festgestellt wird, dass
1. mindestens eines der CV-Zertifikate nicht gültig ist, dann meldet Card Proxy der Umgebung in den Stammdaten den Kartentyp „ungültig“.
2. alle CV-Zertifikate gültig sind, wird dem End-Entity-CV-Zertifikat die ICCSN entnommen sowie der öffentliche Schlüssel PuK.C.eGK.AUT_CVC.
7. Die Echtheit (nicht die Gültigkeit) der Smartcard wird geprüft. Dazu werden folgende Schritte ausgeführt:
1. Es wird eine cardOperation(PrK.eGK.AUTR_CVC.E256, elcRoleAuthentication) durchgeführt.
2. Die Signatur aus dem vorherigen Internal Authenticate Kommando wird mittels PuK.eGK_AUT_CVC geprüft. Falls die Signaturprüfung
1. nicht erfolgreich verläuft, dann wird als Kartentyp „ungültig“ in die Stammdaten eingetragen.
2. erfolgreich verläuft, dann wird in den Stammdaten die Smartcard als „echt“ gekennzeichnet.
3. Die Stammdaten werden an die Umgebung gemeldet und bestehen dabei entweder nur aus „Kartentyp ungültig“, oder aus den folgenden Artefakten:
1. Kartentyp,
2. Produkttypversion COS,
3. Produkttypversion Objektsystem,
4. ICCSN und
5. Smartcard „echt“.

4.1.3 HBA, weitere Stammdaten

Dieser Kartentyp ist für die KTR-AdV irrelevant. Falls dieses Dokument auch für andere Einsatzzwecke verwendet wird, dann ist es möglich dieses Kapitel in einer späteren Version inhaltlich zu füllen.

4.1.4 SMC-B, weitere Stammdaten

1. Puffergrößen ermitteln für SMC-B: Es wird eine cardOperation(EF.ATR, read) ausgeführt. Der Inhalt des Datenobjektes mit Tag ´E0´ wird gemäß [gemSpec_Karten_Fach_TIP#Card-G2-A_2386] ausgewertet und die dort angegebenen Puffergrößen werden in den Baustein Buffersize übernommen.
2. Die Produkttypversion des COS wird dem Inhalt des EF.ATR entnommen, siehe [gemSpec_Karten_Fach_TIP# Card-G2-A_3488].
3. Die Produkttypversion des vorhandenen Objektsystems wird EF.Version2 entnommen, siehe [gemSpec_Karten_Fach_TIP# Tab_Karten_Fach_TIP_002] und dort das Datenobjekt mit dem „Pfad“ ‘EF‘  ‘C1‘.
4. End-Entity-CV-Zertifikat auslesen: Sie werden aus
1. EF.C.SMC.AUTR_CVC.E256 und
2. EF.C.CA_SMC.CS.R2048 ausgelesen.
5. Konditional: Falls das Sub-CA-CV-Zertifikat zu
1. C.SMC.AUT_CVC.E256 nicht im Baustein CV-CertificateStore gespeichert ist, wird diese aus EF.C.CA_SMC.CS.E256 ausgelesen und im Baustein CV-CertificateStore gespeichert.
2. C.SMC.AUT_CVC.R2048 nicht im Baustein CV-CertificateStore gespeichert ist, wird diese aus EF.C.CA_SMC.CS.R2048 ausgelesen und im Baustein CV-CertificateStore gespeichert.
6. Falls beim Import der CV-Zertifikate in den Baustein CV-CertificateStore festgestellt wird, dass
1. mindestens eines der CV-Zertifikate nicht gültig ist, dann meldet Card Proxy der Umgebung in den Stammdaten den Kartentyp „ungültig“.
2. alle CV-Zertifikate gültig sind, wird dem E256 End-Entity-CV-Zertifikat die ICCSN entnommen sowie der öffentliche Schlüssel PuK.C.SMC.AUT_CVC.E256.
7. Die Echtheit (nicht die Gültigkeit) der Smartcard wird geprüft. Dazu werden folgende Schritte ausgeführt:
1. Es wird eine cardOperation(PrK.SMC.AUTR_CVC.E256, elcRoleAuthentication) durchgeführt.
2. Die Signatur aus dem vorherigen Internal Authenticate Kommando wird mittels PuK.eGK_AUT_CVC.E256 geprüft. Falls die Signaturprüfung
1. nicht erfolgreich verläuft, dann wird als Kartentyp „ungültig“ in die Stammdaten eingetragen.
2. erfolgreich verläuft, dann wird in den Stammdaten die Smartcard als „echt“ gekennzeichnet.
3. Die Stammdaten werden an die Umgebung gemeldet und bestehen dabei entweder nur aus „Kartentyp ungültig“, oder aus den folgenden Artefakten:
1. Kartentyp,
2. Produkttypversion COS,
3. Produkttypversion Objektsystem,
4. ICCSN und
5. Smartcard „echt“.

4.1.5 gSMC-K, weitere Stammdaten

Dieser Kartentyp ist für die KTR-AdV irrelevant. Falls dieses Dokument auch für andere Einsatzzwecke verwendet wird, dann ist es möglich dieses Kapitel in einer späteren Version inhaltlich zu füllen.

4.1.6 gSMC-KT, weitere Stammdaten

Dieser Kartentyp ist für die KTR-AdV irrelevant. Falls dieses Dokument auch für andere Einsatzzwecke verwendet wird, dann ist es möglich dieses Kapitel in einer späteren Version inhaltlich zu füllen.

4.2 Signal „Karte entfernt“ empfangen

Falls Card Proxy das Signal „Karte entfernen“ empfängt, dann werden alle kartenspezifischen Informationen aus den Bausteinen des Card Proxys entfernt.

5 Anforderungserhebung

5.1 Zielsetzung

Die kurzen, knappen Ausführungen in 1.1 werden an dieser Stelle etwas ausführlicher am Beispiel eines Kostenträger AdV-Terminals behandelt. Die folgenden Unterkapitel gehen dabei näher auf die Bereiche aus 1.1 ein.

5.1.1 Card Proxy unterstützt die Beschreibung fachlicher Abläufe

Dazu werden die Use Cases „Versichertendaten anzeigen“ und „Zugriffsprotokoll anzeigen“ betrachtet. Der folgenden Beschreibung liegt dabei die Annahme zu Grunde, dass es an der Benutzerschnittstelle Buttons oder ähnliches gibt, mit denen sich unter anderem diese Use Cases auslösen lassen.

Beispielsweise ist es denkbar, dass eine Beschreibung des Use Cases „Versichertendaten anzeigen“ unter anderem folgendes enthält: Falls der Benutzer die Aktion „Versichertendaten anzeigen“ auslöst werden folgende Schritte ausgeführt:

1. Falls noch nicht geschehen, wird in der eGK das Verzeichnis DF.HCA selektiert.
2. Falls noch nicht geschehen, wird PIN.CH vom Benutzer abgefragt und deren Sicherheitszustand in der eGK gesetzt.
3. Falls noch nicht geschehen, wird eine Freischaltung der eGK wie folgt durchgeführt:
1. Import von CV-Zertifikaten, wie folgt …
2. Authentisierungsprotokoll, wie folgt …
4. Die Versichertendaten werden wie folgt ausgelesen:
1. Daten aus EF.StatusVD werden mittels Read Binary ausgelesen.
2. Daten aus EF.GVD werden mittels Read Binary ausgelesen.
3. Daten aus EF.PD werden mittels Read Binary ausgelesen.
4. Daten aus EV.VD werden mittels Read Binary ausgelesen.
5. Die ausgelesenen Daten werden wie folgt angezeigt: …

Beispielsweise ist es denkbar, dass eine Beschreibung des Use Cases „Zugriffsprotokoll anzeigen“ folgendes enthält:

1. Falls noch nicht geschehen, wird in der eGK das Verzeichnis DF.HCA selektiert.
2. Falls noch nicht geschehen, wird PIN.CH vom Benutzer abgefragt und deren Sicherheitszustand in der eGK gesetzt.
3. Falls noch nicht geschehen, wird eine Freischaltung der eGK wie folgt durchgeführt:
1. Import von CV-Zertifikaten, wie folgt …
2. Authentisierungsprotokoll, wie folgt …
4. Alle Rekords werden aus EF.Logging mittels Read Record ausgelesen.
5. Die ausgelesenen Daten werden wie folgt angezeigt: …

Die Beispiele zeigen, dass jeweils die ersten drei Schritte aus fachlicher Sicht eher uninteressant sind und sehr viel mit der konkreten Kartenimplementierung zu tun haben. Bei dieser Art der Darstellung entsteht viel Beschreibungsaufwand im kartennahen Bereich, der sich vielfach wiederholt.

Unter Zuhilfenahme einer (möglicherweise fiktiven) Komponente „Card Proxy“ ließen sich die oben dargestellten Use Cases etwa wie folgt formulieren:

Use Case „Versichtertendaten anzeigen“:

1. Die Versichertendaten werden wie folgt ausgelesen:
1. cardOperation(EF.StatusVD,    read)
2. cardOperation(EF.GVD,     read)
3. cardOperation(EF.PD,     read)
4. cardOperation(EF.VD,     read)
2. Die ausgelesenen Daten werden wie folgt angezeigt: …

Use Case „Zugriffsrprotokoll anzeigen“:

1. cardOperation(EF.Logging,     read)
2. Die ausgelesenen Daten werden wie folgt angezeigt: …

Die kartennahen Implementierungsdetails, etwa wo die Daten liegen, welche Kommandos zum Auslesen erforderlich sind, wie wird der Sicherheitszustand passend gesetzt, all das wird von Card Proxy gekapselt.

Dieses Dokument erhebt keine Anforderungen wie fachliche Abläufe darzustellen sind. Falls bei der Beschreibung fachlicher Abläufe kartennahe Operationen gekapselt werden, dann unterstützt Card Proxy das.

5.1.2 Card Proxy unterstützt die Implementierung

Ähnlich wie in 5.1.1 bei der Beschreibung fachlicher Use Cases ist es auch bei der Implementierung eines KTR-AdV-Terminals denkbar, dass jeder Use Case für sich separat implementiert wird, was voraussichtlich zu vielen Dopplungen im Code führte.

Andererseits ist es denkbar, dass so ein KTR-AdV-Terminal intern Subkomponenten verwendet, und eine der Subkomponenten die Implementierung eines Card Proxy gemäß diesem Dokument ist.

Dieses Dokument erhebt keine Anforderungen an eine Implementierung. Aus Sicht dieses Dokumentes ist eine Vielzahl von Implementierungsvarianten zulässig, von einem monolithischen Block bis hin zu einer hochgradig strukturierten Software.

Card Proxy, so wie er in diesem Dokument beschrieben ist, ist nur eine mögliche Realisierungsvariante um kartennahe Operationen zu kapseln.

5.1.3 Card Proxy unterstützt die Beschreibung der Testerwartungshaltung

Im Rahmen von funktionalen Zulassungstests (hier wieder am Beispiel eines KTR-AdV-Terminals) spielen unter anderem zwei Schnittstellen eine Rolle: Benutzerschnittstelle und Kartenschnittstelle.

Fachliche Abläufe lassen sich, wie in 5.1.1 gezeigt, auf verschiedene Arten darstellen, oder, wie in 5.1.2 gezeigt auf verschiedene Arten implementieren. Im Folgenden wird davon ausgegangen, dass bei der Beschreibung fachlicher Abläufe Card Proxy verwendet wird. Für die Kartenschnittstelle bedeutet das, dass innerhalb der fachlichen Abläufe Card Proxy möglicherweise zum Einsatz kommt (oder auch nicht) und die Beschreibung von Card Proxy in diesem Dokument beschreibt dann, welche Kommandos an der Kartenschnittstelle erwartet werden. Daraus ergibt sich dann die Testerwartungshaltung.

Im Folgenden soll exemplarisch am Beispiel der Use Case „Versichertendaten anzeigen“ (siehe 5.1.1) dargestellt werden, wie sich die Testerwartungshaltung ableiten lässt. Für die Testerwartungshaltung an der Kartenschnittstelle ist für den Use Case „Versichertendaten anzeigen“ folgendes relevant, wobei die gezeigte Abfolge als Beispiel zu verstehen ist. Es ist denkbar, dass aus fachlicher Sicht eine andere Reihenfolge zwingend vorgeschrieben ist. Es ist auch denkbar, dass aus fachlicher Sicht explizit keine Reihenfolge vorgeschrieben wird (das heißt ein Auslesen in einer beliebigen Reihenfolge wäre erlaubt). In diesen Fällen änderte sich die Testerwartungshaltung entsprechend.

1. Die Versichertendaten werden wie folgt ausgelesen:
1. Schritt 1: cardOperation(EF.StatusVD, read)
2. Schritt 2: cardOperation(EF.GVD, read)
3. Schritt 3: cardOperation(EF.PD, read)
4. Schritt 4: cardOperation(EF.VD, read)

Für das weitere Verständnis ist es wichtig zu erwähnen, dass Card Proxy gemäß Kapitel 3 in channelContext den inneren Zustand er Karte mitführt (so gut es geht). Zur Abschätzung des inneren Zustandes (soweit es Card Proxy und die Testerwartungshaltung betrifft) sind die Anforderungen aus [gemSpec_COS] hinreichend. Weitergehende oder herstellerspezifische Kenntnisse sind nicht erforderlich. Im Folgenden werden zwei, aus Sicht dieses Dokumentes zulässige, Implementierungsvarianten unterschieden:

1. Implementierung 1, aufwändiger channelContext:    
   Diese Implementierung sei dadurch gekennzeichnet, dass sie den inneren Kartenzustand sehr genau abbildet, wozu ein hoher Aufwand erforderlich ist. Weil diese Implementierung den inneren Kartenzustand sehr genau kennt, sind für die Implementierung eines Use Cases mitunter weniger Kartenkommandos erforderlich, was die Performanz verbessert.
2. Implementierung 2, rudimentärer channelContext:    
   Diese Implementierung sei dadurch gekennzeichnet, dass sie den inneren Kartenzustand nur rudimentär abbildet, was wenig aufwändig ist. Dafür sind zusätzliche Kartenkommandos erforderlich, was Zeit erfordert.

Annahmen:

1. Es werde der Use Case „Versichertendaten anzeigen“ ausgeführt.
2. Der Sicherheitszustand zum Auslesen von EF.StatusVD, EF.GVD, EV.PD und EF.VD ist wegen vorangegangener Aktionen in der Karte bereits passend gesetzt, das heißt:
1. Sicherheitszustand von PIN.CH ist gesetzt und
2. flagTI.29 ist in bitSecurityList eingetragen.
3. In der Karte ist der Ordner DF.ESIGN selektiert.

Tabelle 10: Kartenschnittstelle „Versichertendaten anzeigen“

Die Anforderungen in diesem Dokument betreffen die Testerwartungshalt und sind so gewählt, dass beide Implementierungen diesbezüglich zulassungsfähig sind. Dem liegt folgendes Konzept zu Grunde:

1. Eine Testerwartungshaltung für die Kartenschnittstelle lässt sich nur auf Basis eines Funktionsaufrufes mit konkreten Parametern ermitteln, wobei hier als Einstieg nur die Funktionen aus Kapitel 6 relevant sind.
2. Kartenoperationen sind in der Reihenfolge auszuführen, die in diesem Dokument beschrieben ist.
3. Falls Kartenoperationen ausgeführt werden, die im Rahmen einer Aktion nicht beschrieben sind, dann wird das als zulassungsverhindernd gewertet.
4. Falls die Selektion eines Ordners, einer Datei oder eines Schlüsselobjektes gemäß diesem Dokument
1. zwingend erforderlich ist, dann wird dies verpflichtend in die Testerwartungshaltung aufgenommen.
2. deshalb nicht erforderlich ist, weil sie bereits zuvor passend erfolgte, dann wird eine nochmalige Selektion nicht als zulassungsverhindernd eingestuft.
5. Falls das Setzen eines Sicherheitszustandes gemäß diesem Dokument
1. zwingend erforderlich ist, dann wird dies verpflichtend in die Testerwartungshaltung aufgenommen.
2. nicht erforderlich ist, dann wird ein nochmaliges Setzen dieses Sicherheitszustandes als zulassungsverhindernd eingestuft (damit Benutzer nicht unnötig oft zur PIN-Eingabe aufgefordert werden).
6. Im Rahmen der Anpassung des Sicherheitsstatus ist die Abfrage eines Sicherheitsstatus zulässig und wird nicht als zulassungsverhindernd eingestuft.

5.2 Anforderungen

Der Einstieg in die Testerwartungshaltung ist der Aufruf einer Schnittstellenfunktion aus Kapitel 6.

Die genaue Testerwartungshaltung ergibt sich daraus, dass nach dem Aufruf der Funktion diese so abgearbeitet wird, wie in diesem Dokument dargestellt. Das bedeutet, dass

1. die Reihenfolge einzuhalten ist,
2. notwendige Aktionen ausgeführt werden,
3. konditionale Aktionen, die aufgrund der Kondition überflüssig sind, toleriert werden,
4. keine zusätzlichen Aktionen ausgeführt werden.

Hinweis (3) Die Anforderung „Konditionale Aktionen tolerieren“ wird im Folgenden anhand eines Beispiels beschrieben. Angenommen eine transparente Datei EF.a sei in einer Smartcard als currentEF markiert und im Prüfling werde die Aktion cardOperation(EF.a, read) aufgerufen, siehe 9.2.6. Dann wird gemäß 9.2.6 Schritt 1 zunächst eine Aktion select ausgeführt. Dort ist in 9.2.7 Schritt 1 eine Kondition enthalten derzufolge der Prüfling nur dann ein oder mehrere Select Kommandos an die Smartcard schickt, falls currentEF im Prüfling (ja, currentEF im Prüfling, nicht currentEF in der Smartcard) nicht passend gesetzt ist. Falls der Prüfling currentEF nicht implementiert, wird er (überflüssigerweise) ein oder mehrere Select Kommandos an die Smartcard schicken, was gemäß der vorstehenden Anforderung in der Testerwartungshaltung zu tolerieren ist.

6 Schnittstelle Card Proxy zu Anwendungen

Dieses Kapitel beschreibt die Schnittstelle zwischen der Komponente Card Proxy und Anwendungen, die Card Proxy nutzen um darüber auf Smartcards zuzugreifen.

Die hier behandelte Schnittstelle steht etwa Fachanwendungen zur Verfügung und hilft diesen mit Daten auf einer Smartcard zu arbeiten, die mit einem Kartenterminal verbunden ist. Die Beschreibung in diesem Kapitel geht von der Sichtweise eines Funktionsaufrufes aus. Die Fachanwendung ruft demzufolge eine Funktion der Schnittstelle auf und übergibt dabei abhängig von der gewünschten Aktion eine Reihe von Parametern. Die Komponente Card Proxy errechnet basierend auf den Inputparametern einen Rückgabewert, der typischerweise Daten und einen Status- oder Fehlercode enthält.

6.1 Funktion cardOperation, Überblick

Mit einem Objekt der Karte im Kartenterminal soll eine Aktion ausgeführt werden. Die Unterkapitel gehen spezifischer auf die erforderlichen Parameter und Rückgabewerte ein. Dabei gibt es pro Objekttyp (beispielsweise Ordner, transparente Datei, strukturierte (rekordorientierte) Datei, Passwortobjekt, Schlüssel, …) ein Unterkapitel.

Tabelle 11: Genereller Ablauf der Funktion cardOperation

6.1.1 cardOperation für Ordner

Als Objekt wird ein Ordner gemäß [gemSpec_COS#8.3.1] adressiert. Die folgende Tabelle enthält lediglich einen Überblick über Aktionen für Ordner. Für die Nutzung der Schnittstelle zwischen Fachanwendungen und Card Proxy ist das hinreichend. Details, die für die Implementierung von Card Proxy relevant sind, werden in den referenzierten Unterkapiteln behandelt.

Hinweis (4) Absichtlich enthält Tabelle 12 keine Aktionen, die zu den folgenden Kommandos aus [gemSpec_COS] gehören:

1. Fingerprint, weil dies ein Kommando ist, welches im Rahmen der Kartenzulassung verwendet wird, für reguläre Use Cases aber keine Rolle spielt.
2. Load Application, weil dies eine administrative Aufgabe ist, die typischerweise über einen „transparenten Kanal“ abgewickelt wird.

Tabelle 12: Funktion cardOperation für Ordner

Hinweis (5) Zusätzlich zu den vorgenannten Fehlermeldungen sind auch solche aus Tabelle 69 möglich, die im Rahmen der Anpassung des Sicherheitszustandes auftraten.

6.1.2 cardOperation für transparente Elementary Files

Als Objekt wird ein transparentes Elementary File gemäß [gemSpec_COS#8.3.2.1] adressiert. Die folgende Tabelle enthält lediglich einen Überblick über Aktionen für transparente Elementary Files. Für die Nutzung der Schnittstelle zwischen Fachanwendungen und Card Proxy ist das hinreichend. Details, die für die Implementierung von Card Proxy relevant sind, werden in den referenzierten Unterkapiteln behandelt.

Tabelle 13: Funktion cardOperation für transparentes Elementary File

Hinweis (6) Zusätzlich zu den vorgenannten Fehlermeldungen sind auch solche aus Tabelle 69 möglich, die im Rahmen der Anpassung des Sicherheitszustandes auftraten.

6.1.3 cardOperation für strukturierte Elementary Files

Als Objekt wird ein strukturiertes Elementary File gemäß [gemSpec_COS#8.3.2.2] adressiert. Die folgende Tabelle enthält lediglich einen Überblick über Aktionen für strukturierte Elementary Files. Für die Nutzung der Schnittstelle zwischen Fachanwendungen und Card Proxy ist das hinreichend. Details, die für die Implementierung von Card Proxy relevant sind, werden in den referenzierten Unterkapiteln behandelt.

Tabelle 14: Funktion cardOperation für strukturiertes Elementary File

Hinweis (7) Zusätzlich zu den vorgenannten Fehlermeldungen sind auch solche aus Tabelle 69 möglich, die im Rahmen der Anpassung des Sicherheitszustandes auftraten.

6.1.4 cardOperation für Passwortobjekte

Als Objekt wird ein reguläres-Passwortobjekt gemäß [gemSpec_COS#8.4] oder ein Multireferenz-Passwortobjekt gemäß [gemSpec_COS#8.5] adressiert. Die folgende Tabelle enthält lediglich einen Überblick über Aktionen für Passwortobjekte. Für die Nutzung der Schnittstelle zwischen Fachanwendungen und Card Proxy ist das hinreichend. Details, die für die Implementierung von Card Proxy relevant sind, werden in den referenzierten Unterkapiteln behandelt.

Tabelle 15: Funktion cardOperation für Passwortobjekte

Hinweis (8) Zusätzlich zu den vorgenannten Fehlermeldungen sind auch solche aus Tabelle 69 möglich, die im Rahmen der Anpassung des Sicherheitszustandes auftraten.

6.1.5 cardOperation für private Schlüsselobjekte

Als Objekt wird ein privates Schlüsselobjekt gemäß [gemSpec_COS#8.6.3] adressiert. Die folgende Tabelle enthält lediglich einen Überblick über Aktionen für private Schlüsselobjekte. Für die Nutzung der Schnittstelle zwischen Fachanwendungen und Card Proxy ist das hinreichend. Details, die für die Implementierung von Card Proxy relevant sind, werden in den referenzierten Unterkapiteln behandelt.

Hinweis (9) Aktionen, die mit dem Schlüsselmaterial arbeiten, verwenden dazu den algorithmIdentifer gemäß [gemSpec_COS#Tab.268]. Folgende algorithmIdentifier, die in [gemSpec_COS] für private Schlüsselobjekte definiert sind, fehlen absichtlich in der unten stehenden Tabelle:

1. Fachanwendungen der AdV-Umgebung führen administrative Aufgaben nicht direkt durch:
• elcAsynchronAdmin
2. Eine AdV-Umgebung baut niemals selbst einen Trusted Channel auf.
• elcSessionkey4SM
• elcSessionkey4TC
• rsaSessionkey4SM
• rsaSessionkey4TC

Hinweis (10) Im Rahmen von Signaturoperationen geht diese Version des Dokumentes davon aus, dass die gesamte zu signierende Nachricht dem Card Proxy übergeben wird und als Hashverfahren stets SHA-256 verwendet wird. Die Signaturoperationen geben dann im Erfolgsfall lediglich die Signatur als Ergebnis der Berechnung mit dem privaten Schlüssel zurück.

Tabelle 16: Funktion cardOperation für private Schlüsselobjekte

Hinweis (11) Zusätzlich zu den vorgenannten Fehlermeldungen sind auch solche aus Tabelle 69 möglich, die im Rahmen der Anpassung des Sicherheitszustandes auftraten.

6.1.6 cardOperation für öffentliche Schlüsselobjekte

Als Objekt wird ein öffentliches Schlüsselobjekt gemäß [gemSpec_COS#8.6.4] adressiert. Die folgende Tabelle enthält lediglich einen Überblick über Aktionen für private Schlüsselobjekte. Für die Nutzung der Schnittstelle zwischen Fachanwendungen und Card Proxy ist das hinreichend. Details, die für die Implementierung von Card Proxy relevant sind, werden in den referenzierten Unterkapiteln behandelt.

Hinweis (12) Aktionen, die mit dem Schlüsselmaterial arbeiten, verwenden dazu den algorithmIdentifer gemäß [gemSpec_COS#Tab.268]. Folgende algorithmIdentifier, die in [gemSpec_COS] für öffentliche Schlüsselobjekte definiert sind, fehlen absichtlich in der unten stehenden Tabelle:

1. Signaturprüfungen im Rahmen des Importes von CV-Zertifikaten werden an der äußeren Schnittstelle von Card Proxy nicht benötigt. Der Import von CV-Zertifikaten wird bei Bedarf von Card Proxy veranlasst:
• sigS_ISO9796-2Withrsa_sha256
• ecdsa-with-SHA256
• ecdsa-with-SHA384
• ecdsa-with-SHA512
2. Externe Authentisierungen werden an der äußeren Schnittstelle von Card Proxy nicht benötigt, sondern bei Bedarf intern veranlasst.
• autS_ISO9796-2Withrsa_sha256_mutual
• authS_gemSpec-COS-G2_ecc-with-sha256
• authS_gemSpec-COS-G2_ecc-with-sha384
• authS_gemSpec-COS-G2_ecc-with-sha512

Tabelle 17: Funktion cardOperation für öffentliche Schlüsselobjekte

Hinweis (13) Zusätzlich zu den vorgenannten Fehlermeldungen sind auch solche aus Tabelle 69 möglich, die im Rahmen der Anpassung des Sicherheitszustandes auftraten.

6.1.7 cardOperation ohne zugeordnetes Objekt

In diesem Unterkapitel werden Aktionen behandelt, die keinem Objekt des Objektsystems zugeordnet werden können und deshalb in den vorangegangenen Unterkapiteln unberücksichtigt blieben. Allen hier behandelten Aktionen ist gemeinsam, dass als Identifikator in den Inputparametern der Wert „Wildcard“ verwendet wird.

Hinweis (14) Absichtlich enthält Tabelle 18 keine Aktionen, die zu den folgenden Kommandos aus [gemSpec_COS] gehören:

1. List Public Key, weil dies ein Kommando ist, welches im Rahmen der Kartenzulassung verwendet wird, für reguläre Use Cases aber keine Rolle spielt.
2. Manage Security Environment, weil dieses Kommando im Rahmen einer Smartcard Nutzung zur Schlüsselauswahl verwendet wir, welche Teil der übrigen Aktionen ist.

Tabelle 18: Funktion cardOperation für Aktionen ohne zugeordnetes Objekt

Hinweis (17) Da der Sicherheitszustand für die hier behandelten Aktionen irrelevant ist, treten die Fehlermeldungen aus Tabelle 69 hier nicht auf.

6.2 Funktion transparentChannel

Diese Funktion ermöglicht die Nutzung eines transparenten Kanals zur Smartcard. Ein transparenter Kanal lässt sich öffnen, nutzen und schließen. Solange ein transparenter Kanal offen ist, ist die Funktion cardOperation nicht nutzbar.

Tabelle 19: Funktion transparentChannel

7 Schnittstelle Card Proxy und Kartenleser

Diese Schnittstelle wird in [gemSpec_KTR-AdV#6.2.2] beschrieben.

8 Konfigurationstabelle Card Proxy

Dieses Kapitel beschreibt beispielhaft die Tabellen innerhalb von Card Proxy, welche die Objekte und Aktionen enthalten, die produkttypspezifisch ausführbar sind. Die Motivation für diese Art Tabelle ergibt sich aus 2.1 Punkt (1) und folgende.

8.1 Konfigurationstabelle Card Proxy eGK G1

Dieses Kapitel wird bei Bedarf in einer späteren Version des Dokumentes ergänzt.

8.2 Konfigurationstabelle Card Proxy eGK G2 aus AdV-Sicht

Die hier dargestellten Tabellen basieren auf [gemSpec_eGK_ObjSys]. Der hier dargestellte Auszug aus [gemSpec_eGK_ObjSys] wurde unter dem Blickwinkel KTR-AdV verfasst. In anderen Umgebungen (etwa @home, oder in der Leistungserbringerumgebung eines Arztes) gäbe es inhaltlich abweichende Konfigurationstabellen.

Hinweis (18) Derzeit wurden die Informationen dieses Unterkapitels manuell erstellt. Es ist geplant derartige Informationen demnächst automatisiert aus den Objektsystemspezifikationen zu extrahieren. Dann wird es auch einfach möglich sein diese Informationen für andere Umgebungen schnell und zuverlässig zu erstellen.

Hinweis (19) [gemSpec_eGK_ObjSys] spezifiziert den Produkttyp eGK in der Produkttypversion 4.3.2, auch bekannt als G2 eGK, oder G2.0 eGK. Davon zu unterscheiden ist die G2.1 eGK, deren Konfigurationstabellen abweichende Inhalte aufweisen.

Die folgenden Tabellen sind so angeordnet, dass der Pfad alphabetisch aufsteigend sortiert ist. Dabei sind nur die Objekte aufgelistet, für die fachliche Use Cases existieren.

8.2.1 Konfigurationstabellen für Objekte im MF

Hinweis (20) / MF / EF.ATR fehlt.

Hinweis (21) / MF / EF.CardAccess fehlt.

Hinweis (22) / MF / EF.C.CA_eGK.CS.E256 fehlt.

Hinweis (23) / MF / EF.C.eGK_AUT_CVC_E256 fehlt.

Hinweis (24) / MF / EF.DIR fehlt.

Hinweis (25) / MF / EF.GDO fehlt.

Hinweis (26) / MF / EF.Version fehlt.

Hinweis (27) / MF / EF.Version2 fehlt.

Hinweis (28) / MF / MRPIN.home fehlt.

Hinweis (29) / MF / PrK.eGK.AUT_CVC.E256 fehlt.

Hinweis (30) / MF / PuK.RCA.ADMINCMS.CS.E256 fehlt.

Hinweis (31) / MF / PuK.RCA.CS.E256 fehlt.

Hinweis (32) / MF / SK.CMS.AES128 fehlt.

Hinweis (33) / MF / SK.CMS.AES256 fehlt.

Hinweis (34) / MF / SK.CMS.VSD128 fehlt.

Hinweis (35) / MF / SK.CMS.VSD256 fehlt.

Hinweis (36) / MF / SK.CAN fehlt.

8.2.2 Konfigurationstabellen für Objekte im DF.HCA

8.2.3 Konfigurationstabellen für Objekte in DF.NFD

8.2.4 Konfigurationstabelle für Objekte in DF.DPE

8.2.5 Konfigurationstabelle für Objekte in DF.GDD

8.2.6 Konfigurationstabelle für Objekte in DF.OSE

8.2.7 Konfigurationstabellen für DF.AMTS

8.2.8 Konfigurationstabellen für DF.ESIGN