C_12408_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

Es besteht der Bedarf für ein Authentisierungsverfahren „eGK ohne PIN” für die GesundheitsID auf einem Vertrauensniveau „gematik-ehealth-loa-normal”. Dazu muss Folgendes gewährleistet sein:

• Die Definition des Vertrauensniveaus „gematik-ehealth-loa-normal” muss erfolgen.
• Sektorale IDPs müssen die Möglichkeit haben, „eGK ohne PIN” als Authentisierungsmittel zuzulassen und zu implementieren.

2 Änderung in gemSpec_IDP_Sek

2.1 Kapitel "4.3 Identifizierung und Authentifizierung des Nutzers" wird angepasst

Neu - Definition des Vertrauensniveau "gematik-ehealth-loa-normal"

2.2 Kapitel "4.3.2 Authentifizierungsverfahren" wird angepasst

Alt:

Neu:

2.3 Kapitel "4.2.4.2 Token-Endpunkt Ausgangsdaten" wird angepasst

Neue Anforderung ID_TOKEN bei eGK ohne PIN

Neues Kapitel 5.4 eGK-Handling:

Neues Kapitel 5.4.1 eGK-Handling, Einführung (aus gemSpec_PoPP-Service)

In diesem Kapitel wird beschrieben und spezifiziert, wie der sektorale IDP Nachrichten mit einer Smartcard austauscht. Der Transport solcher Nachrichten wird in anderen Kapiteln behandelt. Deshalb ist das Kommunikationsmodell hier einfach: Der sektorale IDP schickt Kommando-APDU zu einer Smartcard und erhält von dort die korrespondierenden Antwort-APDU zur Auswertung.

Der IDP kommuniziert im Rahmen des folgenden Use Cases mit einer Smartcard:

• Ein Versicherter nutzt beim mobilen Check-in ein Versichertenendgerät. Das Versichertenendgerät verfügt über einen Standard-Kartenleser mit dem die eGK:
1. kontaktbehaftet kommuniziert oder
2. kontaktlos kommuniziert.

Im Rahmen der Authentifizierung einer eGK ohne Eingabe einer PIN verfolgt der sektorale IDP bei der Kommunikation mit einer Smartcard die folgenden Ziele:

1. Der sektorale IDP überzeugt sich, dass es sich bei der Smartcard um eine echte eGK handelt.
2. Der sektorale IDP überzeugt sich, dass die eGK gültig ist.
3. Der sektorale IDP liest aus der eGK Daten aus.
1. Wenn für die Versicherten keine GesundheitsID im sektoralen IDP angelegt ist übernimmt dieser die ausgelesenen Daten in das ID_TOKEN. In diesem Fall dient die eGK als Authorisierungsmittel und Datenquelle.
2. Wenn für die Versicherten GesundheitsID im sektoralen IDP angelegt ist übernimmt dieser die Daten der GesundheitsID des Versicherten in das ID_TOKEN. In diesem Fall dient die eGK ausschließlich als Authorisierungsmittel.

Die genannten Ziele werden bei kontaktloser Kartenkommunikation mit einer eGK basierend auf [gemSpec_eGK_ObjSys_G2.1](die einen PACE Kanal voraussetzt) wie folgt erreicht:

1. Der sektorale IDP authentisiert die eGK mit der Identität ID.C.eGK.AUT_CVC.E256. Wegen [gemSpec_COS#N107.235)b] ist es nicht möglich dabei einen Trusted Channel zwischen dem sektoralen IDP und der eGK zu etablieren.
2. Der sektorale IDP liest aus der eGK das X.509-Zertifikat aus der Datei EF.C.CH.AUT.E256 aus und überprüft dieses auf Gültigkeit. Da der Kommunikationskanal zwischen sektoralem IDP und eGK im kontaktlosen Fall nicht Ende-zu-Ende gesichert ist, ist der sektorale IDP nicht ohne weiteres in der Lage zu beurteilen, ob das präsentierte X.509-Zertifikat von derselben eGK stammt, deren Echtheit er mit der Identität ID.C.eGK.AUT_CVC.E256 überprüft hat. Deshalb konsultiert der sektorale IDP im kontaktlosen Fall eine Datenbank, welche die Frage beantwortet: Stammen das CV-Zertifikat der Echtheitsprüfung und das präsentierte X.509-Zertifikat aus ein und derselben eGK? So eine Datenbank wird im Kapitel "eGK-Hash Datenbank" beschrieben.
3. Der sektorale IDP entnimmt dem präsentierten X.509-Zertifikat die Daten je nach Konstellation für das Auffinden der GesundheitsID oder für die Befüllung des ID_TOKEN.

Der sektorale IDP schaltet in der eGK nichts frei und erwartet auch nicht, dass in der eGK etwas freigeschaltet ist, insbesondere weder durch Card-2-Card noch durch eine PIN-Eingabe. Technisch ist dies gleichbedeutend mit der Aussage, dass der sektorale IDP nur solche Kommando-APDU an eine eGK sendet, für die im Rahmen der Objektsystemspezifikation die Zugriffsbedingung "ALWAYS" festgelegt ist ("ALWAYS" = jeder, der im Besitz der Karte ist, ist in der Lage diese Operation auszuführen).

Hinweis: Im kontaktlosen Fall funktioniert eine sinnvolle Kartenkommunikation mit der eGK nur nach Aufbau eines PACE-Kanals. Weil die dazu notwendige CAN auf der eGK aufgedruckt ist und somit jeder, der im Besitz der eGK ist so einen PACE-Kanal aufzubauen in der Lage ist, wird hier der Einfachheit halber die Etablierung eines PACE-Kanals und die damit verbundene Freischaltung von Funktionalität in der eGK auch unter "ALWAYS" subsumiert.

Hinweis: Im kontaktlosen Fall stehen nach Etablierung eines PACE-Kanals dieselben Daten und Funktionen in einer eGK zur Verfügung, wie im kontaktbehafteten Fall unmittelbar nach Stecken einer eGK.

Hinweis: Für die Generation 3 einer eGK ist geplant, dass eine eGK G3 eine Identität besitzt, die sich ohne PIN-Eingabe nutzen lässt und deren zugehöriges X.509-Zertifikat alle Informationen enthält, die für ein für die Ermittlung der GesundheitsID im sektoralen IDP relevant sind.

Abbildung 1 : Zustandsdiagramm für die Verarbeitung einer eGK

Abbildung "Zustandsdiagramm für die Verarbeitung einer eGK" zeigt das Zustandsdiagramm für die Verarbeitung einer eGK. Der sektorale IDP wartet in jedem der gezeigten Zustände auf den Empfang einer Nachricht. Er bearbeitet die Nachricht, sendet eine passende Nachricht zurück und geht in den Folgezustand über. Berücksichtigt sind die kontaktbehaftete und die kontaktlose Handhabung einer eGK Generation (G)2.x, sowie die (geplante) Handhabung einer eGK G3 (für welche die Handhabung kontaktbehaftet und kontaktlos identisch ist). Für den sektoralen IDP und die Nutzung der eGK ohne PIN als Authentisierungsmittel ist in erster Linie der kontaktlose Ablauf relevant. Das Zustandsdiagramm berücksichtigt nur Gutfälle. Das bedeutet, Fehlerfälle, Abbrüche und ähnliches sind im abgebildeten Zustandsdiagramm nicht enthalten.

Neues Kapitel 5.4.2 Szenario

In diesem Kapitel ist "Szenario" definiert als eine Abfolge von Elementen in einer Liste. Jedes Element enthält eine Kommando-APDU und eine Liste von Statuswörtern, die als Gutfall für eine Antwort-APDU gewertet werden.

Definition CommandApdu: Eine Kommando-APDU gemäß [gemSpec_COS].

Definition ExpectedStatusWord: Eine Menge mit einem oder mehreren Statuswörtern aus [gemSpec_COS].

Definition Step: Eine Aggregation von genau einer CommandApdu und einem Objekt ExpectedStatusWord.

Definition Szenario: Eine Liste mit keinem, einem oder mehreren Elementen des Typs ScenarioStep.

analog PoPP A_27000

analog PoPP A_27017

analog PoPP A_27129

Hinweis zu A_28385: Die Beschreibung des StandardScenarioMessage folgt noch in einer OpenAPI-Spezifikation!

Neues Kapitel 5.4.2.1 eGK öffnen

Dieses Kapitel beschreibt, wie ermittelt wird, ob es sich bei der präsentierten Smartcard um eine eGK handelt und welche Version diese hat.

Die gematik stellt mit der Prüfkarte eGK eine elektronische Identität zur Überprüfung verschiedener Anwendungsfälle in der TI zur Verfügung. Sie wird vorrangig von Dienstleistern vor Ort (DVOs) genutzt. Die Prüfkarte eGK ist nicht für die Nutzung im regulären Versorgungsalltag von Leistungserbringern oder Versicherten vorgesehen. Um sie nutzen zu können, muss sie vom sektoralen IDP wie eine normale eGK behandelt werden.

Definition: eGKincludedPtvObjSys ist eine Menge mit Produkttypversionen von eGK-Objektsystemen, die der sektorale IDP zu unterstützen hat. Produkttypversionen werden in diese Menge aufgenommen oder aus ihr entfernt, wenn sich die Anforderungslage (also die Vorgaben der gematik) ändert. Basierend auf den Erfahrungen der Vergangenheit ist davon auszugehen, dass sich diese Menge nur wenige Male pro Jahr ändert, während sich die Anzahl zugelassener Kartenprodukte häufiger wechselt. Deshalb wird die Menge zulässiger Kartenprodukte über die Produkttypversion definiert.

Definition: eGKexcludedPiObjSys ist eine Menge mit Produktidentifikationen aktiver Objektsysteme, die von der Verwendung durch den sektoralen IDP ausgeschlossen werden. Produktidentifikationen der Kartenhersteller werden in diese Menge aufgenommen, wenn es Schwierigkeiten mit einem konkreten Kartenprodukt gibt. Basierend auf den Erfahrungen der Vergangenheit ist davon auszugehen, dass die Mächtigkeit der Menge klein ist und sich nur selten ändert.

analog PoPP A_28040

analog PoPP A_27008

analog PoPP A_27018

analog PoPP A_27019

angepasste Afo nach PoPP A_27009

Neues Kapitel 5.4.2.2 eGK G2 kontaktlos

Dieses Kapitel behandelt die kontaktlose Kommunikation einer eGK gemäß [gemSpec_eGK_ObjSys_G2.1]. Dies deckt den Anwendungsfall "Versicherter mit Versichertenendgerät mit NFC-Schnittstelle zum Auslesen der eGK" ab.

Im Gutfall schickt der sektorale IDP nach dem in [A_28387*] beschriebenen Szenario ein weiteres Szenario mit einer Reihe von Kommando-APDU an die Karte:

analog PoPP A_27020

analog PoPP A_27021

Neues Kapitel: 5.4.2.3 eGK G3

Dieses Kapitel behandelt die kontaktlose Kommunikation einer eGK der Generation 3, so wie es Stand März 2025 geplant ist.

Im Gutfall schickt der sektorale IDP nach dem in [A_28387*] beschriebenen Szenario ein weiteres Szenario mit einer Reihe von Kommando-APDU an die Karte:

analog PoPP A_27022

analog PoPP A_27023

Neues Kapitel: 5.4.2.4 Prüfung des X.509-Zertifikates einer eGK

In [A_28392*] und [A_28394*] wird gefordert, dass der sektorale IDP das aus einer eGK ausgelesene X.509-Zertifikat zu prüfen hat. Dies geschieht wie folgt:

analog PoPP A_27130

Neues Kapitel: 5.4.2.5 eGK-Handling Fehlercodes

In den vorherigen Kapiteln zum eGK-Handling werden diverse Fehlermeldungen definiert. Dabei ist es das Ziel für jede Stelle, an der ein Fehler detektierbar ist, eine eigene Fehlermeldung zu definieren, für den Fall, dass es an der Außenschnittstelle relevant ist. Derart aussagekräftige Fehlermeldungen unterstützen in der Entwicklungs- und Testphase das Debugging. Für den realen Betrieb ist zweifelhaft, ob aussagekräftige Fehlermeldungen sinnvoll sind. Mitunter wird gewünscht einem Angreifer nicht zu viel darüber zu verraten, an welcher Stelle genau sein Angriff scheiterte. Konkret auf das eGK-Handling bezogen ist es aus Sicht menschlicher Nutzer eher so, dass eine eGK sich eignet um sich am sektoralen IDP zu authentifizieren, oder eben nicht. Die Tabelle in diesem Kapitel weist jeder (internen) Fehlermeldung des PoPP-Service eine Fehlermeldung zu, die an der Außenschnittstelle am Interface [OpenAPI.yaml wird nachgereicht] sichtbar sind.

analog PoPP A_27049

Neues Kapitel: 5.4.2.6 eGK-Hash DB

Übersicht zu den weiteren Unterabschnitten:

1. "Einleitung und Mengengerüst": die eGK-Hash-Datenbank wird auf hoher Abstraktionsebene beschrieben
2. "Use Cases im laufenden Betrieb": Analyse der Fälle, die im laufenden Betrieb auftreten, das ist die Grundlage für die Spezifikation der "check(. . .)" Funktion in [A_28401*]
3. "Definition von Begriffen zur Wahrscheinlichkeit": Definition von Begriffen, die in Folgeabschnitten verwendet werden
4. "Use Cases zur Befüllung durch Kostenträger": Analyse der Fälle, die beim Befüllen durch Kostenträger (oder deren Dienstleister) auftreten, das ist die Grundlage für die Spezifikation der "import(. . .)" Methode in [A_28402*]
5. "Weitere Anforderungen an die eGK-Hash-Datenbank": unter anderem Spezifikation der "check(. . .)" Funktion und der "import(. . .)" Methode, basierend auf der Analyse in vorherigen Abschnitten

Neues Kapitel: 5.4.2.6.1 Einleitung und Mengengerüst eGK-Hash DB

Die eGK-Hash-Datenbank im sektoralen IDP beantwortet die Frage: "Stammt ein vorgelegtes CV-Zertifikat und ein vorgelegtes X.509 AUT-Zertifikat aus ein und derselben eGK?"

So eine eGK-Hash-Datenbank wird im sektoralen IDP für eGK der Generation 2.x benötigt. Die einfachste Art der technischen Umsetzung wäre eine (mathematische) Funktion, die jedem CV-Zertifikat genau ein AUT-Zertifikat zuordnet. Softwaretechnisch wäre das eine Tabelle (in Java ein Map<CVC, AUT>). In dem Fall enthielte die Tabelle personenbezogene Daten, was weder datensparsam noch datenschutzfreundlich wäre. Stattdessen verwendet die eGK-Hash-Datenbank eine Menge egkEntries, die statt der Zertifikate unter anderem Hashwerte der Zertifikate enthält. Wenn der eGK-Hash-Datenbank dann ein Paar aus CV-Zertifikat und AUT-Zertifikat präsentiert wird, beantwortet die eGK-Hash-Datenbank letztendlich die Frage: "Ist a) dem Hashwert des CV-Zertifikats der Hashwert des AUT-Zertifikats zugeordnet und b) wenn das CV-Zertifikat unbekannt ist, ist dem Hashwert des AUT-Zertifikats nicht bereits der Hashwert eines anderen CV-Zertifikats zugeordnet?"

Überlegungen zum Mengengerüst: Es gibt (Stand März 2025) fast 75 Millionen gesetzlich Versicherte mit eGK G2.x. Es ist davon auszugehen, dass die Anzahl "nicht abgelaufener eGK" darüber liegt, weil es Versicherte gibt, die über mehr als eine "nicht abgelaufene eGK" verfügen, beispielsweise Ersatz für defekte eGK oder infolge eines Kassenwechsels. Hier wird geschätzt, dass die eGK-Hash-Datenbank so zu dimensionieren ist, dass die Mächtigkeit der Menge egkEntries bis zu 150.000.000 (150 Millionen) reicht. Zweimal 150 Millionen SHA-256 Werte beanspruchen netto 9.400 Millionen Byte, also 9,4 Gigabyte. Das ist eine Größenordnung, die für eine moderne Infrastruktur keine besonderen Ansprüche stellt.

Überlegungen zur Befüllung der Menge egkEntries: Ein neues Element wird der Menge egkEntries hinzugefügt, wenn ein KTR (oder dessen Dienstleister) das neue Element dem sektoralen IDP mitteilt. Bei der Anlieferung von Elementen für die Menge egkEntries verwendet der KTR (oder dessen Dienstleister) eine mTLS-Verbindung und übermittelt die Elemente als signierte Nachricht.

Überlegungen zum Entfernen von Elementen aus egkEntries: Es ist vorgesehen, dass KTR (oder deren Dienstleiter) in der Lage sind das Entfernen eines Elementes aus egkEntries zu veranlassen (remove). Zusätzlich ist vorgesehen, dass jedem Element ein Verfallsdatum zugeordnet ist, welches sich aus dem Element "notAfter" aus dem AUT-Zertifikat ergibt. Die eGK-Hash-Datenbank ist damit in der Lage "abgelaufene" Elemente aus der Menge egkEntries zu entfernen. Die eGK-Hash-Datenbank wird nicht dazu verpflichtet "abgelaufene" Elemente aus der Menge egkEntries zu entfernen. Falls die eGK-Hash-Datenbank in der Lage ist auch mit einer sehr großen Anzahl an Elementen in egkEntries performant umzugehen, dann ist ein Entfernen "abgelaufener" Werte auch nicht erforderlich. Die eGK-Hash-Datenbank beantwortet ja nur die Frage, ob ein vorgelegtes Paar aus einer eGK stammt, nicht aber, ob das AUT-Zertifikat des Paars noch gültig ist. Die Frage "ist ein AUT-Zertifikat noch gültig?" wird nicht von der eGK-Hash-Datenbank, sondern an anderer Stelle beantwortet (siehe Prüfung des AUT-Zertifikats in [A_28395*]).

Definition „Lieferant“: Mit „Lieferant“ ist in diesem Unterkapitel eine Instanz gemeint, die berechtigt ist dem sektoralen IDP neue Elemente für die eGK-Hash-Datenbank zu übermitteln. Es ist möglich, dass die Rolle des „Lieferanten“ von einem Kostenträger selbst wahrgenommen wird. Vermutlich wird es Kostenträger geben, welche das Einliefern von neuen Elementen an ihre Dienstleister delegieren. „Lieferant“ ist im Folgenden damit eine verkürzte Form von „Kostenträger (oder deren Dienstleister)“.

Definition listImportClients: Die Liste listImportClients enthält Identitäten, die der sektorale IDP akzeptiert, wenn diese als Client eine mTLS-Verbindung aufbauen zum Zweck des Imports von Elementen in die eGK-Hash-Datenbank.

Definition listSignatureVerificationKeys: Die Liste listSignatureVerificationKeys enthält Identitäten, die der sektorale IDP akzeptiert, wenn diese signierte Nachrichten zum Zweck des Imports von Elementen an die eGK-Hash-Datenbank übermitteln.

analog PoPP A_27043

Hinweis: Elemente für die Liste listImportClients erhält der Anbieter des sektoralen IDP direkt vom jeweiligen Lieferanten und die Liste listSignatureVerificationKeys wird dem Hersteller des sektoralen IDP von der gematik zur Verfügung gestellt.

Neues Kapitel: 5.4.2.6.2 Use Cases im laufenden Betrieb

Dieser Abschnitt beschreibt die möglichen Konstellationen, die im sektoralen IDP bei der Überprüfung von CV-Zertifikaten und AUT-Zertifikaten mittels der eGK-Hash-Datenbank auftreten, also im Rahmen der "check(. . .)" Funktion nach [A_28401*]. Es gilt folgende Nomenklatur:

1. Für das genutzte Übertragungsprotokoll zur eGK sind zwei Werte möglich:
1. "T=1": kontaktbehaftete Übertragung mit dem Protokoll T=1 aus ISO/IEC 7816-3.
2. Nicht "T=1", also "T=CL": kontaktlose Übertragung mit einem Protokoll aus der ISO/IEC 14443 Serie.
2. Für das CV-Zertifikat, welches dem sektoralen übermittelt wird, sind zwei Werte möglich:
1. "CVC bekannt": Das übermittelte CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "CVC bekannt" also "CVC unbekannt": Das übermittelte CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
3. Für das AUT-Zertifikat, welches dem sektoralen IDP übermittelt wird, sind zwei Werte möglich:
1. "AUT bekannt": Das übermittelte AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "AUT bekannt" also "AUT unbekannt": Das übermittelte AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
4. Für das vorgelegte Paar aus CV-Zertifikat und AUT-Zertifikat sind zwei Werte möglich:
1. "match": Die eGK-Hash-Datenbank bestätigt, dass das vorgelegte CV-Zertifikat zum vorgelegten AUT-Zertifikat gehört.
2. Nicht "match" also "mismatch": Die eGK-Hash-Datenbank ist nicht in der Lage zu bestätigen, dass das vorgelegte CV-Zertifikat zum vorgelegten AUT-Zertifikat gehört. Folgende Ursachen sind möglich:
1. Felder 3 und 4: Weder das CV-Zertifikat noch das AUT-Zertifikat sind der eGK-Hashdatenbank bekannt.
2. Felder 7 und 8: Nur das CV-Zertifikat ist der eGK-Hash-Datenbank bekannt.
3. Felder 11 und 12: Sowohl das CV-Zertifikat als auch das AUT-Zertifikat sind der eGK-Hash-Datenbank bekannt, aber sie gehören nicht zusammen.
4. Felder 15 und 16: Nur das AUT-Zertifikat ist der eGK-Hash-Datenbank bekannt.
5. Des Weiteren speichert die eGK-Hash-Datenbank zu jedem Element einen Zustand, der einen der folgenden Werte annimmt:
1. "imported": Das Element wurde mittels "import(. . .)" Methode in die eGK-Hash-Datenbank aufgenommen.
2. "ad hoc": Das Element wurde mittels "check(…)" Methode in die eGK-Hash-Datenbank aufgenommen.
3. "blocked": Der PoPP-Service stellt keine PoPP-Token aus, wenn ein vorgelegtes CV-Zertifikat oder ein vorgelegtes AUT-Zertifikat in einem Element enthalten sind, dessen Zustand "blocked" ist.

Aus der obigen Liste folgt, dass fünf Variablen zu berücksichtigen sind und die fünfte (Zustand des Elementes) keine boolesche Variable ist. Leider sind Karnaugh-Veitch-Diagramme mit mehr als vier Variablen unübersichtlich und Karnaugh-Veitsch-Diagramme berücksichtigen lediglich boolesche Variablen. Zwecks Komplexitätsreduktion wird das System deshalb wie folgt vereinfacht:

1. Für alle Felder "CVC unbekannt" und "AUT unbekannt" liegt kein Element vor. Deshalb liegt auch kein Zustand vor. Daraus folgt, dass der Zustand "blocked" für solche Felder keine Rolle spielt.
2. Für alle übrigen Felder in denen der Zustand des Elementes "blocked" ist generiert der PoPP-Service eine Fehlermeldung.
3. Fazit: Der Zustand "blocked" eines Elementes ist für die weitere Betrachtung im Karnaugh-Veitch-Diagramm irrelevant. Deshalb sind hier lediglich binäre (boolesche) Variablen relevant. Zudem ist der Zustand des Elements nur für wenige Felder relevant, die dann waagerecht unterteilt werden.

Abbildung 2 : Karnaugh-Veitch Diagramm zur "check"-Funktion

Einträge in der eGK-Hash-Datenbank werden wie folgt dargestellt:

1. cvcX bezeichnet den Hashwert eines bestimmten CV-Zertifikates "X".
2. autY bezeichnet den Hashwert eines bestimmten AUT-Zertifikates "Y".
3. {cvcX, autY, imported} bezeichnet einen Eintrag in der eGK-Hash-Datenbank, der durch den Import gemäß [A_28402*] entstand.
4. {cvcX, autY, adHoc} bezeichnet einen Eintrag in der eGK-Hash-Datenbank, der durch "trust on first (contact based) use" gemäß [A_28401*] entstand.
5. {cvcX, autY, blocked} bezeichnet einen Eintrag in der eGK-Hash-Datenbank, der nicht zur Erzeugung eines PoPP-Token nutzbar ist.

Für das zugehörige Karnaugh-Veitch-Diagramm gilt:

1. Felder 1, 2, 5, 6, 13, 14: Es gibt sechs mit "x" gekennzeichnete "don’t care" Felder, weil es unmöglich ist, dass "match" zutrifft, wenn "CVC unbekannt" oder "AUT unbekannt" ist.
2. Feld 3: Bei kontaktbehafteter Kommunikation ist "CVC unbekannt" und "AUT unbekannt". Gemäß "trust on first (contact based) use" wird hier "ad hoc" ein neuer Eintrag zur eGK-Hash-Datenbank hinzugefügt: {cvcX, autY, adHoc}.
3. Feld 4: Bei kontaktloser Kommunikation ist "CVC unbekannt" und "AUT unbekannt". Der sektorale IDP ist nicht in der Lage sicher zu entscheiden, ob CV-Zertifikat und AUT-Zertifikat zusammengehören. Der sektorale IDP generiert eine  Fehlermeldung.
4. Feld 7i: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit "AUT unbekannt" vor und der Eintrag stammt aus einem Import. Aus "mismatch" folgt, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Da der Eintrag zum CV-Zertifikat "importiert" wurde ist sicher auszuschließen, dass in der Vergangenheit missbräuchlich ID_TOKEN vom sektoralen IDP ausgestellt wurden. Wegen dieses Sicherheitsvorfalls wird sowohl das CV-Zertifikat als auch die AUT-Zertifikate blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. {cvcX, autX, imported}
2. "kein Eintrag für autY"
3. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcX, autY, blocked}
5. Feld 7a: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit "AUT unbekannt" vor und der Datenbankeintrag stammt aus einem "ad hoc" Vorgang. Vorgelegt werde das Paar (cvcX, autY). Der Datenbankeintrag laute vorher: {cvcX, autZ, adHoc}. Der sektorale IDP ist in diesem Fall nicht in der Lage zu entscheiden, ob cvcX zu autY oder zu autZ oder zu einem anderen AUT-Zertifikat gehört. Es ist möglich, dass in der Vergangenheit missbräuchlich ID_TOKEN dazu von einem sektoralen IDP ausgestellt wurden. Es ist sicher, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Wegen dieses Sicherheitsvorfalls werden das CV-Zertifikat und die AUT-Zertifikate blockiert.
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. "kein Eintrag zu autY"
2. {cvcX, autZ, adHoc}
3. Zustand hinterher:
1. {cvcX, autY, blocked}
2. {cvcX, autZ, blocked}
6. Felder 8, 12, 16: Bei kontaktloser Kommunikation gibt es ein "mismatch". Neben dem unter Feld 7 beschriebenen Vorfall ist es hier auch möglich, dass ein Angreifer zwei verschiedene eGK dem sektoralen IDP präsentiert: Eine eGK für Authentisierung mit CV-Zertifikat und eine andere aus der das AUT-Zertifikat ausgelesen wird. Der sektorale IDP generiert eine  Fehlermeldung. Der Inhalt der eGK-Hash-Datenbank wird nicht verändert.
7. Felder 9, 10: Bei "CVC bekannt" und "AUT bekannt" liegt ein "match" vor. Das ist der Gutfall, der zur Ausstellung eines ID_TOKEN durch den sektoralen IDP führt (egal ob der Zustand des CV-Zertifikates "imported" oder "ad Hoc" ist).
8. Feld 11i: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit "AUT bekannt" vor und der Eintrag stammt aus einem Import. Aus "mismatch" folgt, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Da der Eintrag zum CV-Zertifikat "importiert" wurde, ist sicher auszuschließen, dass in der Vergangenheit missbräuchlich ID_TOKEN dazu ausgestellt wurden. Wegen dieses Sicherheitsvorfalls werden sowohl die CV-Zertifikate als auch die AUT-Zertifikate blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. {cvcX, autX, imported}
2. {cvcY, autY, *=egal}
3. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcY, autY, blocked}
9. Feld 11a: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit „AUT bekannt“ vor und der Datenbankeintrag stammt aus einem "ad hoc" Vorgang. Vorgelegt werde das Paar (cvcX, autY). Der Datenbankeintrag laute vorher: {cvcX, autZ, adHoc}. Der sektorale IDP ist in diesem Fall nicht in der Lage zu entscheiden, ob cvcX zu autY oder zu autZ oder zu einem anderen AUT-Zertifikat gehört. Es ist möglich, dass in der Vergangenheit missbräuchlich ID_TOKEN dazu von sektoralen IDPs ausgestellt wurden. Es ist sicher, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Wegen dieses Sicherheitsvorfalls werden sowohl die CV-Zertifikate als auch die AUT-Zertifikate blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. {cvcX, autZ, adHoc}
2. {cvcY, autY, *=egal}
3. Zustand hinterher:
1. {cvcX, autZ, blocked}
2. {cvcY, autY, blocked}
   
10. Feld 15i: Bei kontaktbehafteter Kommunikation und "CVC unbekannt" gibt es ein "mismatch" und der Datenbankeintrag zum vorgelegten AUT-Zertifikat wurde importiert. Da der Eintrag zum AUT-Zertifikat "importiert" wurde ist sicher auszuschließen, dass in der Vergangenheit missbräuchlich ID_TOKEN ausgestellt wurden. Wegen dieses Sicherheitsvorfalls wird sowohl das vorgelegte CV-Zertifikat als auch das vorgelegte AUT-Zertifikat blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. "kein Eintrag zu cvcX"
2. {cvcY, autY, imported}
3. Zustand nachher:
1. {cvcX, autY, blocked}
2. {cvcY, autY, blocked}
11. Feld 15a: Bei kontaktbehafteter Kommunikation und "CVC unbekannt" gibt es ein "mismatch" und der Datenbankeintrag zum vorgelegten AUT-Zertifikat stammt aus einem "ad hoc" Vorgang. Vorgelegt werde das Paar (cvcX, autY). Der Datenbankeintrag laute vorher: {cvcZ, autY, adHoc}. Der sektorale IDP ist in diesem Fall nicht in der Lage zu entscheiden, ob autY zu cvcX oder cvcZ oder zu einem anderen CV-Zertifikat gehört. Es ist möglich, dass in der Vergangenheit missbräuchlich ID_TOKEN dazu von einem sektoralen IDP ausgestellt wurden. Es ist sicher, dass der private Schlüssel zu wenigstens einem der beteiligten CV-Zertifikate nicht wie vorgesehen verwendet wird. Wegen dieses Sicherheitsvorfalls werden beide Einträge blockiert.
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. "kein Eintrag für cvcX".
2. {cvcZ, autY, adHoc}.
3. Zustand hinterher:
1. {cvcX, autY, blocked}
2. {cvcZ, autY, blocked}

Neues Kapitel: 5.4.2.6.3 Definition von Begriffen zur Wahrscheinlichkeit

Hier werden einige Begriffe zu Wahrscheinlichkeiten definiert, die in Folgekapiteln verwendet werden. Die Begriffe sind nach Wahrscheinlichkeiten von "sicher" bis "unmöglich" sortiert.

1. sicher: Ein Ereignis tritt mit einer Wahrscheinlichkeit von eins ein.
   Beispiel: Eine Urne enthält nur rote Kugeln. Die Wahrscheinlichkeit aus dieser Urne eine rote Kugel zu ziehen ist eins.
2. extrem wahrscheinlich: Die Eintrittswahrscheinlichkeit ist fast eins. Theoretisch ist es möglich, dass das Ereignis nicht eintritt, aber in der Praxis muss der Nichteintritt nicht betrachtet werden.
   Beispiel: Zwei Zufallszahlen der Länge 128 bit, die unabhängig voneinander generiert werden, sind verschieden.
3. sehr wahrscheinlich: Die Eintrittswahrscheinlichkeit ist so hoch, dass in der Praxis das Gegenereignis nicht beobachtet wird.
   Beispiel: Zu einer Nachricht M wird der SHA-256 Hashwert zweimal berechnet. Beide Ergebnisse stimmen überein.
   Hinweis: In [https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf] werden RAM-Lesefehler untersucht. Bei Verwendung von ECC-RAM ist es sehr wahrscheinlich, dass RAM-Lesefehler entdeckt werden. Deshalb ist es sehr wahrscheinlich, dass eine zweimalige Hashwertberechnung dasselbe Ergebnis liefert.
4. wahrscheinlich: Die Eintrittswahrscheinlichkeit ist so hoch, dass das Ereignis regelmäßig beobachtet wird.
5. unwahrscheinlich: Die Eintrittswahrscheinlichkeit ist so niedrig, dass das Ereignis nur selten beobachtet wird. Obwohl das Ereignis selten eintritt, müssen Systeme mit so einem Ereignis kontrolliert umgehen können, was durch Tests zu bestätigen ist.
   Beispiel: Bitfehler im RAM eines Servers, beispielhafte Gegenmaßnahme ECC-RAM.
6. sehr unwahrscheinlich: Die Eintrittswahrscheinlichkeit ist so niedrig, dass ein System gegen so ein Ereignis nicht gehärtet werden muss.
   Beispiel: Zu einer Nachricht M wird der SHA-256 Hashwert zweimal berechnet. Beide Ergebnisse sind verschieden.
   
7. extrem unwahrscheinlich: Die Eintrittswahrscheinlichkeit ist fast null. Theoretisch ist es möglich, dass das Ereignis eintritt, aber in der Praxis muss der Eintritt nicht betrachtet werden.
   Beispiel: Zwei Zufallszahlen der Länge 128 bit, die unabhängig voneinander gewürfelt werden, sind gleich.
8. unmöglich: Ein Ereignis tritt mit einer Wahrscheinlichkeit von null ein.
   Beispiel: Eine Urne enthält nur rote Kugeln. Die Wahrscheinlichkeit aus dieser Urne eine grüne Kugel zu ziehen ist null.

Neues Kapitel: 5.4.2.6.3 Use Cases zur Befüllung durch Kostenträger

Dieses Kapitel betrachtet die Befüllung der eGK-Hash-Datenbank durch Lieferanten.

Annahmen:

1. Es ist "extrem unwahrscheinlich", das zwei verschiedene Zertifikate denselben Hashwert haben. Deshalb werden derartige Fälle hier nicht weiter betrachtet.
2. Es ist "unwahrscheinlich" (aber denkbar), dass eGKs erst im Feld eingesetzt werden und für diese ein Eintrag in die eGK-Hash-Datenbank erfolgt (per "trust on first (contact based) use") und zu einem späteren Zeitpunkt liefert ein Lieferant für dieselbe eGK per Import einen Eintrag für die eGK-Hash-Datenbank. Daraus folgt, dass es zwar "unwahrscheinlich" aber möglich ist, dass zum Zeitpunkt des Imports bereits ein Eintrag in der eGK-Hash-Datenbank vorliegt. Dieses Kapitel betrachtet dann die dabei auftretenden Fälle und wie mit ihnen umzugehen ist.

Hinweis: Falls die Wahrscheinlichkeit des Ereignisses "eine eGK wird im Feld benutzt bevor ein Import ihrer Daten in die eGK-Hash-Datenbank" von "unwahrscheinlich" auf "sehr unwahrscheinlich" oder niedriger eingestuft wird, dann wird dieses Kapitel gegenstandslos. Derzeit ist die Annahme, dass dieses Ereignis lediglich "unwahrscheinlich" ist. Daraus folgt, dass dieses Kapitel relevant ist.

Ein neuer Eintrag {cvcX, autX, imported} wird der eGK-Hash-Datenbank neu hinzugefügt oder entfernt (remove).

1. Für das CV-Zertifikat, welches im Eintrag enthalten ist, sind zwei Werte möglich:
1. "CVC bekannt": Das CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "CVC bekannt" also "CVC unbekannt": Das CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
2. Für das AUT-Zertifikat, welches im Eintrag enthalten ist, sind zwei Werte möglich:
1. "AUT bekannt": Das AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "AUT bekannt" also "AUT unbekannt": Das AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
3. Für Einträge, die das CV-Zertifikat oder das AUT-Zertifikat (oder beide) enthalten, sind zwei Werte relevant:
1. Wenigstens einer dieser Einträge ist im Zustand "blocked".
2. Keiner dieser Einträge ist "blocked" (also "unblocked").
4. Für den Vergleich zwischen dem Eintrag und einem bestehenden Eintrag in der eGK-Hash-Datenbank sind zwei Werte denkbar:
1. "match": Die Hashwerte im Eintrag sind identisch zu den Hashwerten in einem bestehenden Eintrag.
2. Nicht "match" (also "mismatch"): Die Hashwerte des Eintrags sind nicht identisch zu irgendeinem bestehenden Eintrag.

Aus der obigen Liste folgt, dass vier binäre (boolesche) Variablen zu berücksichtigen sind. Für das zugehörige Karnaugh-Veitch Diagramm gilt:

Abbildung 3 : Karnaugh-Veitch Diagramm zur "import"-Methode

1. Felder 1, 4: Der Fall, dass "CVC unbekannt" und "AUT unbekannt" aber "blocked" ist, kann nicht vorkommen. Deshalb sind diese Felder irrelevant (don’t care).
2. Felder 1, 2, 5, 6, 13, 14: Der Fall, dass ein "match" vorliegt, wenn cvcX oder autX "unbekannt" sind, kann nicht vorkommen. Deshalb sind diese Felder irrelevant (don’t care).
3. Feld 3: Weder cvcX, noch autX sind in der eGK-Hash-Datenbank enthalten.
1. "import": Ein neuer Eintrag wird der eGK-Hash-Datenbank hinzugefügt.
2. "remove": Der zu entfernende Eintrag ist nicht in der eGK-Hash-Datenbank enthalten. Die eGK-Hash-Datenbank wird nicht verändert.
4. Felder 7, 8: cvcX ist "bekannt" aber autX ist "unbekannt". Daraus folgt, dass der private Schlüssel des CV-Zertifikates nicht wie vorgesehen verwendet wird. In der Vergangenheit wurden missbräuchlich ID_TOKEN dazu ausgestellt. Der Eintrag wird gesperrt.
1. Zustand in der eGK-Hash-Datenbank vorher:
1. "kein Eintrag zu autX"
2. {cvcX, autY, *=egal}
2. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcX, autY, blocked}
5. Feld 9: cvcX ist "bekannt" aber "blocked" und es liegt ein "match" vor. Die eGK-Hash-Datenbank wird nicht verändert.
6. Feld 10: Sowohl cvcX, als auch autX sind "bekannt" und auch in der eGK-Hash-Datenbank sind cvcX und autX einander zugeordnet ("match") und der Zustand von cvcX in der eGK-Hash-Datenbank ist nicht "blocked".
1. "import": Ein neuer Eintrag wird der eGK-Hash-Datenbank hinzugefügt. Dann lassen sich folgende Fälle unterscheiden: Der Zustand von cvcX in der eGK-Hashdatenbank ist
1. "imported": Keine Aktion erforderlich, da die eGK-Hash-Datenbank den neuen Eintrag bereits enthält.
2. "adHoc": Der Zustand des cvcX in der eGK-Hashdatenbank wird von "adHoc" auf "imported" geändert.
1. Zustand vorher: {cvcX, autX, adHoc}
2. Zustand nachher: {cvcX, autX, imported}
2. "remove": Der Eintrag wird aus der eGK-Hash-Datenbank entfernt.
7. Felder 11, 12: Sowohl cvcX, als auch autX sind "bekannt", aber in der eGK-Hash-Datenbank einander NICHT zugeordnet ("mismatch"). In der Vergangenheit wurden dazu ID_TOKEN missbräuchlich ausgestellt. Einträge werden gesperrt.
1. Zustand vorher:
1. {cvcX, autY, *=egal}
2. {cvcZ, autX, *=egal}
2. Zustand nachher:
1. {cvcX, autY, blocked}
2. {cvcZ, autX, blocked}
8. Felder 15, 16: cvcX ist "unbekannt", autX ist "bekannt". Daraus folgt, dass der private Schlüssel des CV-Zertifikates nicht wie vorgesehen verwendet wird. In der Vergangenheit wurden missbräuchlich dazu ID_TOKEN ausgestellt. Der vorhandene Eintrag wird gesperrt und ein neuer Eintrag angelegt.
1. Zustand vorher:
1. "kein Eintrag für cvcX"
2. {cvcY, autX, *=egal}
2. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcY, autX, blocked}

analog PoPP A_27044

analog PoPP A_27045

Neues Kapitel: 5.4.2.6.4 Weitere Anforderungen an die eGK-Hash-Datenbank

analog PoPP A_27046

analog PoPP A_27622

analog PoPP A_27623

analog PoPP A_27624

analog PoPP A_27201

Neues Kapitel: 5.4.2.6.4 Anmerkungen zur Implementierung

Die Intention dieses Unterkapitels ist es, Hilfestellungen bei der Implementierung der eGK-Hash-Datenbank zu liefern. Dieses Unterkapitel enthält keine Anforderungen.

Am Anfang dieses Unterkapitels sei zunächst angenommen, dass der sektorale IDP und mit ihm die eGK-Hash-Datenbank in Betrieb seien. Aus Performancegründen erscheint es ratsam die eGK-Hash-Datenbank im RAM zu halten, weil Speicherzugriffe auf (volatile) RAM-Inhalte vielfach schneller ablaufen als solche auf ein persistentes Dateisystem.

Gemäß [A_28401*] „check(. . .)“-Funktion Punkt 5.c.i (Feld 3) ist es möglich im laufenden Betrieb beispielsweise durch "trust on first (contact based) use" der eGK-Hash-Datenbank neue Einträge hinzuzufügen. Zudem sind in [A_28401*] weitere Punkte enthalten, bei denen sich der Inhalt der eGK-Hash-Datenbank ändert. Deshalb erscheint es nicht hinreichend zu sein, den Inhalt der eGK-Hash-Datenbank ausschließlich im RAM vorzuhalten, damit er beispielsweise durch einen Stromausfall erhalten bleibt. Daraus folgt, dass es zur eGK-Hash-Datenbank im (volatilen) RAM auch eine persistente Variante der eGK-Hash-Datenbank gibt.

Gemäß [A_28401*] und [A_28402*] spielt die Reihenfolge in welche Einträge zur eGK-Hash-Datenbank hinzugefügt werden eine Rolle.

Szenario 1:

1. Die eGK-Hash-Datenbank enthalte einen Eintrag {cvc1, aut1, imported}.
2. Aus irgendeinem Grund werde cvc1 und damit auch aut1 blockiert.
3. Anschließend werde versucht der "check(…)"-Funktion {cvc1, aut2} zu präsentieren. Ohne die eGK-Hash-Datenbank zu ändern scheitert die "check(…)"-Funktion wegen blockiertem cvc1.
4. Anschließend werde {cvc2, aut2, "T=1"} der "check(…)"-Funktion präsentiert, was zu einem neuen Eintrag {cvc2, aut2, adHoc} führt.
5. Endzustand in Szenario 1:
1. {cvc1, aut1, blocked}
2. {cvc2, aut2, adHoc}

Szenario 2:

1. Die eGK-Hash-Datenbank enthalte einen Eintrag {cvc1, aut1, imported}.
2. Anschließend werde {cvc2, aut2, "T=1"} der "check(…)"-Funktion präsentiert, was zu einem neuen Eintrag {cvc2, aut2, adHoc} führt.
3. Anschließend werde versucht der "check(…)"-Funktion {cvc1, aut2, "T=1"} zu präsentieren. Das blockiert cvc1, cvc2, aut1 und aut2.
4. Endzustand in Szenario 2:
1. {cvc1, aut1, blocked}
2. {cvc2, aut2, blocked}

Beispielhaftes Konzept für eine Implementierung der eGK-Hash-Datenbank:

1.  Nach erfolgreicher Signaturprüfung speichert die "import(…)"-Methode die "SEQUENCE OF" egkInfos zunächst zusammen mit einem Zeitstempel persistent.
2. Falls im Rahmen der "check(…)"-Funktion ein neuer Eintrag angelegt wird (Feld 3), dann wird ebenfalls mit Zeitstempel eine „SEQUENCE OF“ egkInfos mit den Daten aus dem neuen Eintrag persistent gespeichert, mit status=2=adHoc.
3. Falls im Rahmen der "check(…)"-Funktion oder der "import(…)"-Methode ein oder mehr Einträge blockiert werden, dann werden alle dabei blockierten Einträge in einer „SEQUENCE OF“ egkInfos mit Zeitstempel persistent gespeichert, mit status=3=blocked.

Daraus ergibt sich, dass die eGK-Hash-Datenbank zweimal vorliegt: Volatil im RAM und als durch Zeitstempel geordnete Liste von „SEQUENCE OF“ egkInfos, die persistent gespeichert sind. Der Zustand im RAM lässt sich dabei jederzeit aus den persistenten Informationen eindeutig rekonstruieren, wenn die zeitlich geordneten „SEQUENCE OF“ egkInfos nacheinander verarbeitet werden.

Der Neuaufbau des RAM-Zustandes der eGK-Hash-Datenbank ist möglicherweise (je nach Implementierung) zeitintensiv. Dann bietet es sich an, von der RAM-Version der eGK-Hash-Datenbank einen persistenten Speicherabzug zu erstellen, der sich performanter ins RAM laden lässt.

Neu - Anforderung an sekt. IDP eGK ohne PIN zu unterstützen

Neu - Anforderung an sekt. IDP Umgang mit Hash-DB

Neu - Anforderung an Authenticator-Modul Unterstützung Authentisierungsverfahren "eGK ohne PIN"

Verschiebung Kapitel 5.45 Authenticator-Modul für Desktop-Plattformen Anwendungen

3 Änderungen in Steckbriefen

3.1 Änderungen in gemProdT_IDP-Sek_PTV

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_IDP-Sek_PTV]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 4: Anforderungen zur sicherheits technischen Eignung "Produktgutachten"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
A_23129-05 (entfällt)	Identifikation des Authentisierungsverfahren	gemSpec_IDP_Sek
A_23129-06 (neu)	Identifikation des Authentisierungsverfahren	gemSpec_IDP_Sek
A_28229 (neu)	Inhalte des ID_TOKEN nach Authentifizierung mit eGK ohne PIN	gemSpec_IDP_Sek
A_27992 (neu)	sektoraler IDP: Unterstützung Authentisierungsverfahren NFC eGK ohne PIN	gemSpec_IDP_Sek
A_28232 (neu)	Authenticator-Modul: Unterstützung Authentisierungsverfahren "eGK ohne PIN"	gemSpec_IDP_Sek

3.2 Änderungen in gemAnbT_IDP-Sek_KTR_ATV

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemAnbT_IDP-Sek_KTR_ATV]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 5: Anforderungen zur sicherheits technischen Eignung "Anbietererklärung"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
A_28230 (neu)	sektoraler IDP: Vorhalten der Hash-DB	gemSpec_IDP_Sek
A_28231(neu)	sektoraler IDP: Befüllung der Hash-DB	gemSpec_IDP_Sek

Tabelle 6: Anforderungen zur sicherheits technischen Eignung "Gutachten (Anbieter)"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
A_28137 (neu)	Definition "gematik-ehealth-loa-normal"	gemSpec_IDP_Sek