Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Private Key Generator

    

     

      
Version
      
0.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
28.02.2020
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSpec_PKG
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert Anforderungen an den Produkttyp "Private Key Generator" (PKG) und beschreibt die Funktionsweise der identitätsbasierten (asymmetrischen) Verschlüsselung innerhalb der TI.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter des Produkts Private Key Generator" (PKG)". Weiterhin unterstützt das Dokument Anwendungen der TI, die eine identitätsbasierten Verschlüsselung verwenden möchten, indem hier ebenfalls Client-spezifische Abläufe normativ beschrieben werden. Auf diese kann eine Anwendungsspezifikation verweisen.

1.3 Geltungsbereich

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

Schutzrechts-/Patentrechtshinweis

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

1.4 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 RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

2 Überblick

Der Private Key Generator (PKG) ist ein Dienst der TI-Plattform, der von beliebigen Anwendungen der TI verwendet werden kann. Er ist Teil eines identitätsbasierten, asymmetrischen Verschlüsselungsverfahrens (Identity Based Encryption (IBE)). Bei einem IBE kann ein Sender aus systemweit bekannten öffentlichen Parametern (Public Parameter) und einem eindeutigen Identifikationsmerkmal (bspw. einer KVNR, einer Telematik-ID, einer E-Mail-Adresse etc.) einen öffentlichen Schlüssel berechnen. Mittels dieses öffentlichen Schlüssels kann der Sender eine Nachricht (ein Dokument etc.) für den Empfänger, dem dieses Identifikationsmerkmal zugeordnet ist, asymmetrisch verschlüsseln. Für diese Verschlüsselung ist keine direkte Interaktion mit dem PKG notwendig, d. h. die Verschlüsselung wird vollständig lokal beim Sender durchgeführt.

Als erste Anwendungen in der TI werden die Anwendung eRezept und die Anwendung KOM-LE ein identitätsbasiertes, asymmetrisches Verschlüsselungsverfahren verwenden.

Der PKG hat zwei Aufgaben:

1. Er berechnet initial jedes Jahr die "Public-Parameter" (ca. 800 Byte).
2. Er berechnet auf Nutzer-Anfrage (Empfänger) innerhalb eines quasi autonom arbeitenden PKG-HSM den privaten Schlüssel, der zum verwendeten öffentlichen Schlüssel passt, nachdem der Nutzer erfolgreich authentifiziert wurde.

Die Public-Parameter (ca. 800 Byte) werden über die TSL übertragen und durch die TSL authentizitäts- und integritätsgeschützt. Der Schutz der Public-Parameter auf diese beiden Schutzziele ist von zentraler Bedeutung. Für Systeme die keine TSL verwenden, bietet der PKG die Möglichkeit die aktuell gültigen Public Parameter vom PKG zu erfragen.

Der PKG bietet zwei HTTPS-Schnittstellen an -- eine im Internet und eine in der TI.

Das Standard-Vorgehen bei IBE-Verfahren ist, bei der Berechnung des öffentlichen Schlüssels ebenfalls Anwendungszweck (Anwendung) und Zeitinformationen und ggf. andere Angaben mit einfließen zu lassen. Auf diese Weise erfolgt zum einem eine Schlüsseldiversifizierung -- für unterschiedlichen Anwendungszwecken und Anwendungen werden unterschiedliche Schlüssel verwendet. Andererseits wird es aufgrund des Zeitbezugs möglich, die Schlüsselnutzung zeitlich zu begrenzen.

Zur Berechnung des öffentlichen Schlüssels eines Empfängers wird für die TI eine Zeichenkette vom Sender der folgenden Form verwendet:

<ID-Public-Parameter>:<Anwendung>:<Operation>:<Typ-des-Identifikationsmerkmals>:<Identifikationsmerkmal>:<Datum>

Beispiele:

1. PP1:eR:eR:KVNR:A0123456789:20200216
2. PP1:KOM-LE:M:TID:2-20a1201-001:20200410

Solch eine Zeichenkette wird im folgenden als erweiterte Identifikationszeichenkette bezeichnet. Sie wird im Klartext an jedes mit ihrer Hilfe erzeugte Chiffrat beigefügt. Sie ist (1) empfängerspezifisch (Ende-zu-Ende-Verschlüsselung), (2) anwendungsspezifisch, (3) operationsspezifisch, und (4) tagesspezifisch.

Bei der Verwendung von IBE-Verfahren in der TI muss für die Verschlüsselung kein direkter Kontakt mit dem PKG oder einem OCSP-Responder hergestellt werden -- die Verschlüsselung kann also rein lokal erfolgen. 

Der Empfänger kann sich täglich (bspw. LEI) oder beliebig oft (bspw. FdV) einen privaten Schlüssel vom PKG berechnen lassen und vom PKG erhalten. Dieser wird über einen Ende-zu-Ende verschlüsselten Kanal zwischen Client und PKG übermittelt. Die privaten Schlüssel korrespondieren immer genau zu einer erweiterten Identifikationszeichenkette. Als Beispiel bei der Anwendung eRezept wird i. d. R. ein Apothekensystem genau ein mal den privaten Schlüssel für "PP1:eR:eR:TID:2-20a1201-001:20200410" für die Entschlüsselung aller eRezepte, die für die Apotheke am 10.04.2020 verschlüsselt wurden, vom PKG berechnen lassen. Anschließend verbleibt der Schlüssel lokal im Apothekensystem.

Der PKG muss die meisten der durch Doppelpunkt (":") getrennten Bestandteile in der erweiterten Identifikationszeichenkette nicht auswerten oder verstehen. Er muss nur wissen, dass das Identifikationsmerkmal (KVNR etc.) vor dem Datum am Ende erscheint. Der PKG ist also anwendungsunabhängig. Der PKG muss bei einer Authentisierung des Nutzers über einen Token die Gleichheit der Identitätsattribute (KVNR, Telematik-ID, E-Mail-Adresse etc.) im Token und in der erweiterten Identifikationszeichenkette des öffentlichen Schlüssels überprüfen. Wenn dann zusätzlich die Datumsinformationen nicht zu alt sind (oder gar in der Zukunft liegen) kann der PKG den zur erweiterten Identifikationszeichenkette passenden privaten Schlüssel für den Nutzer berechnen und ihn sicher an den Nutzer übermitteln. Die Berechnung erfolgt dabei innerhalb eines speziellen PKG-HSM, das durch technische Maßnahmen verhindert, dass der Betreiber unberechtigte Schlüsselberechnungen vornehmen kann.

Die folgende Abbildung gibt eine Übersicht über den grundsätzlichen Aufbau eines PKG:

Abbildung 1: Strukturübersicht PKG

2.1 Akteure, Rollen und Komponenten

Die beteiligten Akteure sind:

Tabelle 1: beteiligte Akteure im Kontext IBE

Die beteiligten Komponenten und Dienste sind:

Tabelle 2: beteiligte Komponenten und Dienste im Kontext IBE

2.2 Beziehung zwischen SGD und PKG

Ein Schlüsselgenerierungsdienst (SGD) berechnet für Anfragende symmetrische Schlüssel nach bestimmten Schlüssel-Ableitungsregeln, nachdem der Anfragende vom SGD-HSM erfolgreich authentifiziert wurde. Über einen beidseitig authentisierten und Ende-zu-Ende-verschlüsselten Datenkanal übergibt ein SGD-HSM die berechneten Schlüssel dem Anfragenden. Grundsätzlich ist ein SGD anwendungsunabhängig, er wird aktuell in der TI genau nur für die Anwendung elektronische Patientenakte (ePA) verwendet.

Der PKG stellt, abstrahiert gesehen, die Weiterentwicklung des SGD in Bezug auf die Berechnung von asymmetrischen Schlüsseln dar. Daher ist die Architektur von PKG und SGD sehr ähnlich. An und für sich wäre der PKG durch eine neue Ableitungsregeln in einem SGD-HSM realisierbar. Da jedoch zukünftig innerhalb der TI verstärkt die tokenbasierte Authentisierung und nicht mehr vorrangig die Authentisierung über Authentisierungszertifikate verwendet werden soll, gibt es im Bereich der Authentifizierung und der authentisierten Ende-zu-Ende-Verschlüsselung zwischen PKG und SGD deutliche Unterschiede. Da ein Anfragender keine Authentsierungszertifikate bei direkten Anfragen an ein PKG verwendet, sondern JSON Web Token (JWT) ohne nutzerspezifische kryptographische Schlüssel, kann das beim SGD verwendete Kommunikationsprotokoll für die Ende-zu-Ende-Verschlüsselung nicht verwendet werden. Daher verwendet der PKG ein anderes Kommunikationsprotokoll auf Applikationsebene und stellt damit auch andere durch einen Anfragenden aufzurufende Operationen bereit. Ebenfalls unterscheidet sich die JWT-Prüfung beim PKG deutlich von der Prüfung der Zertifikate beim SGD.

2.3 Überblick PKG-Operationen

Die folgende Tabelle gibt eine kurze Übersicht über die von einem PKG auf dessen HTTPS-Schnittstellen (vgl. Abschnitt  ) angebotenen Operationen.  

Tabelle 3: Übersicht über die von außen zugänglichen Operationen eines PKG

3 Übergreifende Festlegungen

3.1 Verfügbarkeit und Performanz

Verfügbarkeits- und Performanzanforderungen für einen PKG befinden sich in [gemSpec_Perf#PKG] und sind dem Produkttypsteckbrief PKG zugewiesen.

3.2 Sichere Betreiberumgebung

Ähnlich wie einem TSP werden an den Betreiber eines PKG Anforderungen u. a. an die sichere Betreiberumgebung aus [gemSpec_DS_Anbieter] gestellt (vgl. Zuordnung im Anbietersteckbrief). Die zugeordneten Module sind "Basis-IS", "Basis-ISMS", "Erweitertes ISMS", "TI-Sicherheitsbericht" und "„Erweiterter TI-Sicherheitsbericht“.

3.3 Verschiedenes

4 Bestandteile eines PKG als Dienst der TI

Ein PKG besteht aus

1. einer HTTPS-Schnittstelle im Internet,
2. einer HTTPS-Schnittstelle in der TI,
3. einer Request verarbeitenden Einheit für die eingehenden HTTP-Requests

Abbildung 2: Bestandteile eines PKG

4.1 HTTPS-Schnittstellen

Vorgaben für die HTTPS-Schnittstellen befinden sich in Abschnitt . Vorgaben für das dabei zu verwendeten TLS-Protokoll finden sich in [gemSpec_Krypt] und werden über die Referenzierung im Produkttypsteckbrief PKG normativ.

4.2 Request-Verarbeitung in einem PKG

Eingehende Requests eines Clients werden von der Request verarbeitenden Einheit (RVE) an der HTTPS-Außenschnittstelle entgegengenommen. Dort werden sie entweder direkt beantwortet (Operation PublicParameter, A_xxx) oder aufbereitet und danach an ein PKG-HSM (Operation PrivateKey und Random) gesendet. Abhängig von der Antwort des PKG-HSM erzeugt die RVE eine Antwort für den Client (A_xxx) und sendet diese an ihn. Die RVE hat keinen Einblick in den beidseitig authentisierten und verschlüsselten Datenkanal zwischen Client und PKG-HSM (vgl. Abschnitt xxx). Die RVE stellt nur in Bezug auf die Verfügbarkeit (DoS-Gegenmaßnahmen, Umkodieren von Requests etc.) des PKG eine kritische Komponente dar. In Bezug auf die Vertraulichkeit der Schlüssel erbringt sie keine Sicherheitsleistung.

Die Schnittstelle zwischen RVE und PKG-HSM ist eine Innenschnittstelle (vgl. Abschnitt  ) und wird deshalb nicht ausspezifiziert beschrieben.

4.2.1 DoS-Schutzmaßnahmen in der RVE und die user_id

Ziel der DoS-Schutzmaßnahmen in der RVE (also auf Applikationsebene) ist es die rechentechnisch teuren Operationen PrivateKey und Random, die Zugriff auf die PKG-HSM erfordern, zu schützen. Um diese beschränkte Ressource zu schützen wird sie an eine für einen potentiellen Angreifer beschränkte Ressource gebunden -- die Anzahl der gültigen Authentisierungstoken, auf die er Zugriff hat. Ein PKG-HSM gibt der RVE nach erfolgreichen Kommandoausführung (inkl. Verifikation des Authentisierungstokens des Aufrufers) ein sich regelmäßig wechselndes Pseudonym des Aufrufenden zurück. Dieses Pseudonym bildet die Grundlage der "user_id". Anhand dieses Pseudonyms bzw. der user_id kann die RVE beim nächsten Aufruf den Nutzer erkennen und ggf. zu viele Anfragen von ihm drosseln. Dafür wird der Nutzer aufgrund des Interface-Designs aufgefordert seine user_id bei Anfragen mit zusenden. Nutzer sind motiviert dies auch zu tun, weil Anfragen ohne gültige user_id bei hohem Lastaufkommen deutlich herunter priorisiert werden (A_xxx).

Der Schutzbedarf von Key_RVE_A ist (nur) mittel, d. h. der Schlüssel soll per Software in der RVE vorhanden sein (keine HSM-Speicherung).

4.3 PKG-HSM

Den wesentlichen Teil der Sicherheitsleistung eines PKG erbringt das (bzw. die) PKG-HSM. Das PKG-HSM entscheidet, ob eine ausreichende Authentifizierung stattgefunden hat und führt erst danach eine Berechnung eines privaten Schlüssels für einen Client durch.

Hinweis zu Punkt 7:

Analog zu den CC-Evaluierungen der TI-Komponenten muss es möglich sein, ohne dass Verschwiegenheitsregelungen die Klärung von fachlichen Punkten während der Sicherheitsbegutachtung behindern, die notwendige Dauer der Sicherheitsbegutachtung zu minimieren.

4.4 Schlüssel im PKG-HSM

In einem PKG müssen verschiedene Schlüssel verfügbar sein, die durch ein PKG-HSM geschützt werden müssen.

Verständnishinweis zu   und  : Dies ist analog zu den Vorgaben, wie seit 2014 die CVC-Root der TI betrieben wird und so wie es auch bei den SGD umgesetzt wird. Damit wird der Betreiber eines PKG vom Verdacht befreit, er könnte die Masterkeys des IBE-Verfahrens (S4) missbrauchen. Er ist technisch aufgrund der zwei Anforderungen nicht in der Lage dies zu tun.

4.5 Pflege der Prüfschlüssel (S2) und (S3) im PKG-HSM

Hinweis: Nach der Erzeugung einer neuen Root-Version der X.509-Root-CA der TI werden dessen selbstsigniertes Zertifikat und Crosszertifikate auf den Download-Punkt  https://download.tsl.ti-dienste.de/ abgelegt. Automatisiert kann der SGD ePA von dort die Verfügbarkeit neuer Versionen überwachen. Im Regelfall wird alle zwei Jahre eine neue Root-Version erzeugt.

4.6 Funktionsablauf Firmware-Modul PKG-HSM

In diesem Abschnitt wird die Ablauflogik im speziellen HSM-Firmware-Modul beschrieben. Diese Vorgaben sind ein wichtiger Bestandteil der für die Zulassung notwendigen Sicherheitsüberprüfung (vgl.  ).

4.6.1 Zertifikats- und Schlüsselprüfung im PKG-HSM

4.6.2 Kommandozeichenkette

Die Operationen PrivateKey und Random enthalten im Request einen vom Client für die PKG-HSM über ein IBE-Verfahren (vgl. [gemSpec_Krypt#]) verschlüsselte Kommandozeichenkette. Als Identifikationszeichenkette für den dabei verwendeten öffentlichen Schlüssel verwendet der Client die Zeichenkette "PKG:YYYYMMDD" (vgl.  und xxx).

4.6.3 JWT-Prüfung

4.6.4 Schlüsselberechnung im PKG-HSM

4.6.5 Anwendungsspezifische Sonderfunktionen im PKG-HSM

 ist eine Umsetzung von [gemSysL_eRp#]. 

5 Kodierung von Schlüsseln und Nachrichten

Festlegungen in diesem Abschnitt folgen in Kürze. In der aktuell in der Entwicklung befindlichen Beispiel-Implementierung des PKG der gematik werden die Kodierungsvorgaben aktuell validiert, und anschließend in einer Folgeversion von gemSpec_PKG in diesem Abschnitt normativ festgelegt.

5.1 Kodierung der Public Parameter

Aktuell in der Validierung befindliche Kodierung der Public Parameter:

Die Public Parameter werden als JSON-Datenstruktur kodiert. Der Hauptteil ist ein Array in dem die Public Parameter ggf. mehrerer IBE-Verfahrens aufgeführt sind. Ein Client verwendet das erste Element, dessen Verfahren er unterstützt. Pro Verfahren wird genau ein Public Parameter aufgeführt.

Tabelle 4: Struktur der JSON-Kodierung der Public Parameter

5.1.1 Aufführung in der TSL

Aktuell in der Validierung befindliche TSL-Struktur.

Tabelle 5: Struktur TSL-Eintrag für die Public Parameter

5.1.2 Signatur der Public Parameter für die Operation PublicParameter

Die JSON-kodierten Public Parameter werden per JSON Web Signature (JWS) [RFC-7515] signiert und vom PKG mit dem Context-Type "application/jose" an den Client als Antwort gesendet. Die Signatur wird mit dem Schlüssel (S1) aus A_19652 im PKG-HSM erzeugt.

6 Schnittstellen und Operationen

Der PKG bietet zwei HTTPS-Schnittstellen an -- eine im Internet und eine in der TI.

Die gematik stellt auf Anfrage eine Beispiel-Implementierung für die Außenschnittstellen eines PKG bereit.

6.1 Innenschnittstellen

Die Innenschnittstellen zwischen der Request verarbeitende Einheit (RVE) für die eingehenden HTTP-Request und dem PKG-HSM sind PKG-intern. Deren Ausgestaltung bleibt dem Betreiber überlassen.

6.2 HTTPS-Schnittstellen und HTTP-Kommunikation

Hinweis: Vorgaben für das dabei zu verwendeten TLS-Protokoll finden sich in [gemSpec_Krypt] und werden über die Referenzierung im Produkttypsteckbrief PKG normativ.

6.2.1 Schutz vor DoS-Angriffen

Hinweis zu A_19633:

Das in A_19633 Punkt 2) geforderte Verhalten, kann man effizient bspw. mittels "Counting Bloom Filter" implementieren. Die Client-ID ist der dann zu verwendende Schlüsselwert für den Bloom-Filter.

6.3 Anforderungen an die JSON-Requests und -Responses

Erläuterung zu A_19636: Bei einer Sicherheitsüberprüfung muss u. a. die Validierung von Daten an der Außenschnittstelle betrachtet werden (im Fokus die Implementierung im PKG-HSM). Dabei unterstützt   indem sie eine obere Schranke für die Größe aller Eingabe-Datenfelder definiert.

6.4 Operation PublicParameter

Die Public-Parameter werden jährlich neu erstellt und über die TSL authentitäts- und integritätsgeschützt verteilt. Für Systeme, die die TSL nicht als Prüfbasis verwenden, sondern die X.509-Root der TI, stellt der PKG die aktuellen Public Parameter in signierte Form zur Verfügung.

Die Formulierung "in einer Datei" bei A_19665 soll verdeutlichen, dass diese Information semistatisch an den Client gesendet werden, also nicht dynamisch berechnet werden.

6.5 Operation PrivateKey

6.6 Operation Random

6.7 Operation Time

Über diese Operation kann ein Client die aktuelle Zeit (bspw. "2020-04-28T05:42:47.248131+00:00") im PKG (RVE) vom PKG erfragen. Ziel ist es Clients die Möglichkeit zu geben von mehreren Quellen Zeitinformationen zu erlangen und aus dieser Menge an Antworten den Median als aktuelle Zeit zu gewinnen, insbesondere für den Fall, dass Clients die Verwendung des NTP-Protokolls nicht möglich ist (bspw. Netzwerkbeschränkungen im aktuell verwendeten WLAN). Der PKG mit dieser Operation ist eine Quelle.

Beispiel-Code in Python:

from datetime import datetime, timezone

print(datetime.now(timezone.utc).isoformat())

6.8 Fehlermeldungen

Tabelle #: Tab_Fehlerfälle_und_Fehlermeldungen

6.8.1 Fehlermeldungen und HTTP-Status-Code (informativ)

Da der PKG im Gegensatz zum SGD, sowohl in der TI als auch im Internet eine HTTPS-Schnittstelle anbietet, gibt es keine Weiterleitung der Nachrichten über ein Gateway (vgl. Zugangsgateway des Versicherten bei ePA). Daher gibt es beim PKG keine Motivation die Beziehung Applikationsnachrichten und HTTP-Fehlercodes für eine einfachere Weiterleitung der Nachrichten über ein Gateway zu vereinfachen. Deshalb gilt für die Außenschnittstellen des PKG der übliche REST-Ansatz (vgl. HTTP-Status-Codes in Tabelle "Tab_Fehlerfälle_und_Fehlermeldungen").

7 Clientspezifische Festlegungen

Die kryptographischen Vorgaben für das zu verwendende IBE-Verfahren sind mit [gemSpec_Krypt#] festlegt,   legt die dabei zu verwendende Struktur der erweiterten Identifikationszeichenkette fest.

Erläuterung A_19649: Es ist sehr unwahrscheinlich, dass der Fall aus A_19649 auftritt, er kann jedoch formal nicht ausgeschlossen werden, da es aktuell keine normativen, vollständigen Vorgaben für die genaue Struktur von Identifikationsmerkmalen außer der KVNR gibt.

Bei den Operationen eines PKG (vgl. Abschnitte 6.4, 6.5 und 6.6) sendet der PKG eine pseudozufällig erzeugte user_id als Teil der Antwort an den PKG-Client. Diese user_id muss der Client beim nächsten Aufruf einer Operation des PKG an den PKG mitsenden.

Die user_id wird regelmäßig gewechselt (vgl. Abschnitt ) und ist eine für den PKG-Client opake Zeichenkette, d. h. der PKG-Client braucht die Bildungsvorschrift der user_id in der RVE nicht zu verstehen.

Erläuterung: Die user_id ist nicht erratbar und dient dem DoS-Schutz im PKG. Ihr Schutzbedarf ist (nur) mittel, sie sollte die PKG-Client-Applikation nicht unkontrolliert verlassen, da ansonsten es einem Angreifer gelingen könnte den Client mit der bekannt gewordenen user_id temporär vom PKG "auszusperren". Die Intention von  ist nicht, dass die Variable in einem TPM gespeichert werden soll.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

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

8.5.2 Weitere Dokumente