Zielgruppe: 
Hier dokumentiert die gematik die Nutzung der Schnittstellen, um sich mit der Telematikinfrastruktur zu verbinden. Das betrifft zum einen die Authentifizierung als Nutzer oder Institution durch den Identity Provider (IDP) und zum anderen den verschlüsselten Datentransport auf Anwendungsebene ("VAU-Transport").
Für den Verbindungsaufbau mit dem E-Rezept Fachdienst stehen verschiedene Endpunkte zur verfügung, je nach Entwicklungsumgebung. Angegeben werden jeweils der Endpunkt für den Fachdienst und den IDP:
| E-Rezept-Fachdienst Umgebung | aus der TI für Primärsysteme | aus dem Internet für E-Rezept-FdVs |
|---|---|---|
PU |
erp.zentral.erp.splitdns.ti-dienste.de |
erp.app.ti-dienste.de |
idp.zentral.idp.splitdns.ti-dienste.de |
idp.app.ti-dienste.de |
|
RU |
erp-ref.zentral.erp.splitdns.ti-dienste.de |
erp-ref.app.ti-dienste.de |
idp-ref.zentral.idp.splitdns.ti-dienste.de |
idp-ref.app.ti-dienste.de |
|
RU-DEV |
erp-dev.zentral.erp.splitdns.ti-dienste.de |
erp-dev.app.ti-dienste.de |
idp-ref.zentral.idp.splitdns.ti-dienste.de |
idp-ref.app.ti-dienste.de |
|
ℹ️
|
Für die Entwicklung in der RU-DEV ist der Scope in der Anfrage-URL umzustellen. Als Parameter der Anfrage ist statt &scope=e-rezept+openid ist &scope=e-rezept-dev+openid anzugeben. Siehe Schritt 37 im Rbelflow für Primärsysteme.
|
Die jeweiligen Konfigurationen können sich je nach Entwicklungsstand unterscheiden. Aktuelle Informationen zu den jeweiligen Umgebungen finden Sie hier.
Zur Steuerung der Funktionsaufrufe, für Sicherheitsprüfungen und die Protokollierung sind verpflichtende http-Header in allen http-Requests an den IDP-Dienst und den E-Rezept-Fachdienst erforderlich. Da mit dem VAU-Transport ein "innerer" und ein "äußerer" http-Request an den E-Rezept-Fachdienst gesendet werden, ist auf das korrekte Setzen innen und außen zu achten. Die folgende Tabelle listet die notwendigen http-Header auf.
| http-Header | äußerer Request ("/VAU") | innerer Request |
|---|---|---|
Authorization |
- |
x |
User-Agent |
x |
optional |
X-erp-user |
x |
- |
X-erp-resource |
x |
- |
X-AccessCode |
- |
x |
SOAPAction (nur für Konnektor) |
n/a |
x |
|
ℹ️
|
Der Aufbau von User-Agent hat nach A_20015-01 zu erfolgen: <Produktname>/<Produktversion> <Herstellername>/<client_id> |
|
ℹ️
|
Die Standard http-Header wie bspw. Accept-*, Connection, Host, Content-Type, Content-Length usw. sind gemäß Standard ebenfalls zu setzen.
|
Die Telematikinfrastruktur gestattet keinen Zugriff auf Dienste ohne eine Identifikation der Nutzer. Dies dient der Durchsetzung von Zugriffsregeln und der Protokollierung des Zugriffs auf medizinische Daten von Versicherten. Mit der Authentifizierung der Nutzer erfolgt keine Profilbildung, Sessiondaten werden temporär verwaltet und nach Beendigung einer Sesssion unverzüglich gelöscht. Die Protokollierung von Zugriffen auf medizinische Daten erfolgt in Abhängigkeit der genutzten Schnittstellen in den jeweils aufgerufenen Services sowie in Abhängigkeit der fachlichen Anforderungen gemäß gematik-Spezifikationen.
Die Authentifizierung übernimmt mit der Einführung des E-Rezepts ein zentraler Identity Provider (IDP). Der IDP erkennt Nutzer anhand ihrer kartenbasierten Identitäten und stellt die Identitätsmerkmale (Name, KVNR bzw. Telematik-ID) der Zertifikate auf der Karte in ID_TOKEN und ACCESS_TOKEN für die Nutzung im E-Rezept-Fachdienst bereit.
Leistungserbringerinstitutionen (Praxen, Apotheken, Krankenhäuser) weisen sich gegenüber der Telematikinfrastruktur mit der Identität des Praxisausweises SMC-B aus. Die Authentifizierung erfolgt gegenüber dem Identity Provider (IDP) unter Nutzung der Konnektorschnittstelle.
Das Primärsystem adressiert Anfragen an den IDP über eine bekannt zu machende Adresse z.B. idp.zentral.idp.splitdns.ti-dienste.de bzw. idp.app.ti-dienste.de, dabei veröffentlicht der IDP sein DiscoveryDocument mit den Informationen zu verschiedenen Endpunkten zur Tokenausstellung unter einer "/.well-known"-Adresse, d.h. idp.ti-dienste.de/.well-known/openid-configuration.
Die folgende Abbildung zeigt den detaillierten Ablauf mit allen beteiligten Komponenten. Das Primärsystem gliedert sich in die E-Rezept-Fachlogik und ein Authenticator-Modul. Letzteres übernimmt die Authentisierung mittels der kartenbasierten Identität unter Nutzung der Konnektorschnittstellen. Der IDP authentifiziert den Nutzer anhand der kartenbasierten Identität und einer Signatur durch das Schlüsselmaterial auf der Karte (SMC-B) und stellt bei Erfolg einen Zugriffstoken (ACCESS_TOKEN) für den Zugriff auf den Fachdienst aus.
|
ℹ️
|
Die Ablaufbeschreibung Rbelflow für Primärsysteme gibt ein konkretes Beispiel mit Request- und Response-Parametern für die Authentifizierung mittels SMC-B einer Test-Apotheke "3-SMC-B-Testkarte-883110000xxxxxx" (siehe auch "professionOID": "1.2.276.0.76.4.54" = "Öffentliche Apotheke"). |
Die folgenden Schritte sind von besonderer Bedeutung und werden kurz erläutert.
Step |
eRp (Fachlogik) / AM (Auth-Modul) |
Beschreibung |
1 - 5 |
AM/eRP |
Laden des Discovery Documents (DD) vom IDP (Diese Operation wird vorbereitend sowohl vom Auth-Modul, wie auch von der Fachlogik und dem Fachdienst durchgeführt) |
6 - 8 |
eRp |
Erzeugung eines CODE_VERIFIER (128 zufällige Zeichen aus der Menge [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~") und bilden der CODE_CHALLENGE als dessen sha256-Hashwert sowie,
Erzeugung einer |
AuthorizationCode über Handshake mit Kartenidentität beziehen |
||
9 - 12 |
AM |
Lesen des X509-Signatur-Zertifikats zum |
13 - 17 |
AM |
Senden der in Schritt 8 übergebenen Werte (als URL-Parameter wie z.B. 'code_challenge') an den authorization_endpoint des IDP, ,+ dieser antwortet mit dem CHALLENGE_TOKEN und dem |
18 - 19 |
AM |
Anzeige des |
20 |
AM |
Zertifikat der Authentisierungs-Identität C.HCI.AUT von der SMC-B lesen (siehe unten Konnektor-Aufruf) |
21 |
AM |
Berechnen des HASH-Werts der empfangenen Challenge und Signieren des Challenge-HASH mit PrK.HCI.AUT der SMC-B (siehe unten Konnektor-Aufruf) |
22 |
AM |
JWE-Verschlüsselung der signierten Challenge als njwt und des Zertifikats C.HCI.AUT mit |
23 - 27 |
AM |
Senden der verschlüsselten Challenge und des verschlüsselten Zertifikats an den authorization_endpoint des IDP |
28 |
AM |
Die Response ( |
Authentifizierung des Nutzers abgeschlossen, im Folgenden wird der ACCESS_TOKEN für den Zugriff am E-Rezept-Fachdienst mit Hilfe des AuthorizationCodes abgerufen. |
||
29 - 32 |
eRp |
Generierung eines |
33 - 37 |
eRp |
Der Aufruf übergibt den zuvor erhaltenen |
38 - 41 |
eRp |
Das ACCESS_TOKEN und das ID_TOKEN werden mit Hilfe des |
42 - 44 |
Der Fachdienst prüft die Signatur des ACCESS_TOKEN, liest die dem Scope zugewiesenen Claims und gibt dem identifizierten Benutzer Zugriff auf die Fachdaten der Anwendung. |
|
-
Dem Nutzer soll der vom IDP bereitgestellte UserConsent angezeigt werden. Stimmt der Nutzer der Bereitstellung der Daten für den E-Rezept-Fachdienst nicht zu, muss der Authentifizierungsvorgang abgebrochen werden, da der Fachdienst ohne diese Informationen den E-Rezept-Workflow nicht umsetzen kann.
-
Die vom IDP in der obigen Response übermittelte Challenge beinhaltet ein Challenge-Token
{"iss":"https://idp.zentral.idp.splitdns.ti-dienste.de","response_type":"code","snc":"syQAvJmxPnRtLjT6uPVERb_RF7MmVzhS1sP8FbHjhLM","code_challenge_method":"S256","token_type":"challenge","nonce":"887766","client_id":"gematikTestPs","scope":"openid e-rezept","state":"xxxstatexxx","redirect_uri":"http://test-ps.gematik.de/erezept","exp":1616686048,"iat":1616685868,"code_challenge":"Ca3Ve8jSsBQOBFVqQvLs1E-dGV1BXg2FTvrd-Tg19Vg","jti":"5e5ad23ae3e7d8aa"}in Base64-CodierungeyJpc3MiOiJodHRwczovL2lkcC56ZW50cmFsLmlkcC5zcGxpdGRucy50aS1kaWVuc3RlLmRlIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJzbmMiOiJzeVFBdkpteFBuUnRMalQ2dVBWRVJiX1JGN01tVnpoUzFzUDhGYkhqaExNIiwiY29kZV9jaGFsbGVuZ2VfbWV0aG9kIjoiUzI1NiIsInRva2VuX3R5cGUiOiJjaGFsbGVuZ2UiLCJub25jZSI6Ijg4Nzc2NiIsImNsaWVudF9pZCI6ImdlbWF0aWtUZXN0UHMiLCJzY29wZSI6Im9wZW5pZCBlLXJlemVwdCIsInN0YXRlIjoieHh4c3RhdGV4eHgiLCJyZWRpcmVjdF91cmkiOiJodHRwOi8vdGVzdC1wcy5nZW1hdGlrLmRlL2VyZXplcHQiLCJleHAiOjE2MTY2ODYwNDgsImlhdCI6MTYxNjY4NTg2OCwiY29kZV9jaGFsbGVuZ2UiOiJDYTNWZThqU3NCUU9CRlZxUXZMczFFLWRHVjFCWGcyRlR2cmQtVGcxOVZnIiwianRpIjoiNWU1YWQyM2FlM2U3ZDhhYSJ9. Da die Signatur immer über einen Hashwert der zu signierenden Daten erfolgt, muss dieser Hashwert vom Clientsystem berechnet werden. Als kryptografisches Verfahren kommt hier SHA-256 zum Einsatz. Aus dem obigen BeispieleyJpc3MiOiJodHRwczovL2lkcC56ZW50cmFsLmlkcC5…ergibt sich folgender Hashwert:94238882b24aaade41950ecee5a8ab14c4196ed4c5d9d2dfa344fdfd63a27262
|
ℹ️
|
Der JWS-Payload muss zusammen mit dem Base64 enkodierten Header {"alg": "ES256","typ": "JWT"} kombiniert und dann gehasht werden: eyJhbGciOiAiRVMyNTYiLCJ0eXAiOiAiSldUIn0.eyJpc3MiOiJodHRwczovL2lkcC56ZW50cmFsLmlkcC5zcGxpdGRucy50aS1kaWVuc3RlLmRlIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJzbmMiOiJzeVFBdkpteFBuUnRMalQ2dVBWRVJiX1JGN01tVnpoUzFzUDhGYkhqaExNIiwiY29kZV9jaGFsbGVuZ2VfbWV0aG9kIjoiUzI1NiIsInRva2VuX3R5cGUiOiJjaGFsbGVuZ2UiLCJub25jZSI6Ijg4Nzc2NiIsImNsaWVudF9pZCI6ImdlbWF0aWtUZXN0UHMiLCJzY29wZSI6Im9wZW5pZCBlLXJlemVwdCIsInN0YXRlIjoieHh4c3RhdGV4eHgiLCJyZWRpcmVjdF91cmkiOiJodHRwOi8vdGVzdC1wcy5nZW1hdGlrLmRlL2VyZXplcHQiLCJleHAiOjE2MTY2ODYwNDgsImlhdCI6MTYxNjY4NTg2OCwiY29kZV9jaGFsbGVuZ2UiOiJDYTNWZThqU3NCUU9CRlZxUXZMczFFLWRHVjFCWGcyRlR2cmQtVGcxOVZnIiwianRpIjoiNWU1YWQyM2FlM2U3ZDhhYSJ9 SHA256(x) = 94238882b24aaade41950ecee5a8ab14c4196ed4c5d9d2dfa344fdfd63a27262 |
Der Konnektor authentifiziert Nutzer anhand einer kartengebundenen, kryptografischen Identität. Die Karte hält den privaten Schlüssel zu dieser Identität, welcher für die Signatur über eine Challenge des IDP genutzt wird. Zur Prüfung der Signatur benötigt der IDP das Zertifikat dieser Identität. Dieses enthält den öffentlichen Schlüssel für die kryptografische Signaturprüfung sowie weitere Nutzerinformationen (Name, KVNR/Telematik-ID, fachliche Rolle), die der IDP in Identitätsbestätigungen zur Nutzung gegenüber dem E-Rezept-Fachdienst attestiert. Der Abruf des Zertifikats erfolgt über die Konnektor-Operation ReadCertificate.
URI |
|||
|---|---|---|---|
Method |
POST |
||
Requester |
|
||
Responder |
Konnektor |
||
HTTP Header |
Content-Type: text/xml; charset=UTF-8 Content-Length: 1234 SOAPAction: "http://ws.gematik.de/conn/CertificateService/v7.4#ReadCardCertificate" |
||
Payload |
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns8:ReadCardCertificate xmlns:ns2="http://ws.gematik.de/conn/CertificateServiceCommon/v2.0"
xmlns:ns3="urn:oasis:names:tc:dss:1.0:core:schema"
xmlns:ns4="http://www.w3.org/2000/09/xmldsig#"
xmlns:ns5="http://ws.gematik.de/conn/ConnectorCommon/v5.0"
xmlns:ns6="http://ws.gematik.de/tel/error/v2.0"
xmlns:ns7="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:ns8="http://ws.gematik.de/conn/CertificateService/v7.4"
xmlns:ns9="http://ws.gematik.de/conn/ConnectorContext/v2.0">
<ns5:CardHandle>smc-b_2</ns5:CardHandle>
<ns9:Context>
<ns5:MandantId>Mandant1</ns5:MandantId>
<ns5:ClientSystemId>myPVS</ns5:ClientSystemId>
<ns5:WorkplaceId>WP1</ns5:WorkplaceId>
</ns9:Context>
<ns8:CertRefList>
<ns8:CertRef>C.AUT</ns8:CertRef>
</ns8:CertRefList>
</ns8:ReadCardCertificate>
</S:Body>
</S:Envelope>
|
Response
HTTP/1.1 200 OK
Content-Type: text/xml;charset=utf-8
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns3:ReadCardCertificateResponse xmlns="http://ws.gematik.de/conn/ConnectorCommon/v5.0"
xmlns:ns2="http://ws.gematik.de/conn/ConnectorContext/v2.0"
xmlns:ns3="http://ws.gematik.de/conn/CertificateService/v7.4"
xmlns:ns4="http://ws.gematik.de/tel/error/v2.0"
xmlns:ns5="http://ws.gematik.de/conn/CertificateServiceCommon/v2.0"
xmlns:ns6="http://www.w3.org/2000/09/xmldsig#"
xmlns:ns7="urn:oasis:names:tc:dss:1.0:core:schema"
xmlns:ns8="urn:oasis:names:tc:SAML:1.0:assertion">
<Status>
<Result>OK</Result>
</Status>
<ns5:X509DataInfoList>
<ns5:X509DataInfo>
<ns5:X509Data>
<ns5:X509Certificate>MIIFcTCCBFmgAwIBAgIHAXumDkbX3zANBgkqhkiG9w0BAQsFADCBmjELMAkGA1UEBhMCREUxHzAdBgNVBAoMFmdlbWF0aWsgR21iSCBOT1QtVkFMSUQxSDBGBgNVBAsMP0luc3RpdHV0aW9uIGRlcyBHZXN1bmRoZWl0c3dlc2Vucy1DQSBkZXIgVGVsZW1hdGlraW5mcmFzdHJ1a3R1cjEgMB4GA1UEAwwXR0VNLlNNQ0ItQ0EyNCBURVNULU9OTFkwHhcNMjAwNjEwMDAwMDAwWhcNMjUwNjA5MjM1OTU5WjCB+DELMAkGA1UEBhMCREUxFDASBgNVBAcMC03DvGhsaGF1c2VuMQ4wDAYDVQQRDAU5OTk3NDEeMBwGA1UECQwVTGFuZ2Vuc2FsemFlciBTdHIuIDI1MSowKAYDVQQKDCEzLVNNQy1CLVRlc3RrYXJ0ZS04ODMxMTAwMDAxMjkwNjgxHTAbBgNVBAUTFDgwMjc2ODgzMTEwMDAwMTI5MDY4MRQwEgYDVQQEDAtCbGFua2VuYmVyZzEWMBQGA1UEKgwNRG9taW5pay1QZXRlcjEqMCgGA1UEAwwhQXBvdGhla2UgYW0gU3BvcnR6ZW50cnVtVEVTVC1PTkxZMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjVMEf2TTXlfkuCDyiMpo96jA5XRvkaHTy+4qTcDR1awUP4yemfKsB1BTWMMSDrA1/2YdnlZJeynEnQi0K4LWMvTcq+CRGi4ghcIokb2TURZXZ1K6FTJHqITojp9ZRaNTap+kIpOZCmSRa7ftRzEgooPjG6C+7XxUViczlVE17UJMPavWQfY2+A1M/0vx9Jbi7wPmXCMuEvj7yEAVRCGQExVxzbLZPE7FS/vlXcwkFtmnMUVWiQFFXlVLG7uUc9CQFvTXPT5ppDhxAmVeUBLNXKruDkpSeuq3sCi93ln9hXXw/xPeNAAehtvxFp6eMGf5LEVGvZj8v51qu4eDPaKtJwIDAQABo4IBWjCCAVYwEwYDVR0lBAwwCgYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdDgQWBBSEkJ1lgmhiHfVZyKKyVw2Qd86PPDA4BggrBgEFBQcBAQQsMCowKAYIKwYBBQUHMAGGHGh0dHA6Ly9laGNhLmdlbWF0aWsuZGUvb2NzcC8wDAYDVR0TAQH/BAIwADAgBgNVHSAEGTAXMAoGCCqCFABMBIEjMAkGByqCFABMBE0wHwYDVR0jBBgwFoAUeunhb+oUWRYF7gPp0/0hq97p2Z4wgYQGBSskCAMDBHsweaQoMCYxCzAJBgNVBAYTAkRFMRcwFQYDVQQKDA5nZW1hdGlrIEJlcmxpbjBNMEswSTBHMBcMFcOWZmZlbnRsaWNoZSBBcG90aGVrZTAJBgcqghQATAQ2EyEzLVNNQy1CLVRlc3RrYXJ0ZS04ODMxMTAwMDAxMjkwNjgwDQYJKoZIhvcNAQELBQADggEBAGwmbkXMdRrIZwTzUVsdH6RUB7cc3+CcDN0NqLSOM7sdCQrr5NfzcK2dzhc77KVzviZbvz6MxfEq47Y/dPMmtVlU0Amw5bbnYT4WnadjrLOHnKCxLFssrfo0izB7IJvBswMQl/KnUXbk/X57KcNKTYOfuCVVVt+yET63N4qp9YOPiMdCHxu+BUvgwmOgr/enRnh+HgCYVQtzLmDXimBcneRoZg3XgukoMQPd5TlVlZAF1JZ6W8uGN+LEiddnHdzYFVInest3xMzwHj4T3lXLCkr6oc9jvwKe2A2qsBvcbEFDR0mi0CW9NjfJ05v/52GKZZZyjEnFjnHJ1J5r1DlD5S8=
</ns5:X509Certificate>
</ns5:X509Data>
</ns5:X509DataInfo>
</ns5:X509DataInfoList>
</ns3:ReadCardCertificateResponse>
</soap:Body>
</soap:Envelope>|
ℹ️
|
Der Konnektor liefert das Zertifikat in <ns5:X509Certificate> zurück, wie es auf der Karte gespeichert ist, ASN.1 DER codiert in Base64-Darstellung.
|
Code |
Type Success |
200 |
OK |
Code |
Type Error |
400 |
Bad Request |
Der Konnektor prüft das übergebene Zertifikat gegen den Vertrauensraum der Telematikinfrastruktur, dabei führt er eine Online-Prüfung des Sperrstatus durch und liefert das Ergebnis der Prüfung sowie die im Zertifikat enthaltene technische Rolle. Diese technische Rolle muss das Primärsystem im Anschluß gegen die Rolle des erwarteten Dienstes abgleichen.
URI |
|||
|---|---|---|---|
Method |
POST |
||
HTTP Header |
Content-Type: text/xml; charset=UTF-8 Content-Length: 1234 SOAPAction: "http://ws.gematik.de/conn/CertificateService/v6.0#VerifyCertificate"
|
||
Payload |
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:m0="http://ws.gematik.de/conn/ConnectorContext/v2.0"
xmlns:m1="http://ws.gematik.de/conn/ConnectorCommon/v5.0"
xmlns:m2="http://ws.gematik.de/conn/CertificateServiceCommon/v2.0">
<SOAP-ENV:Body>
<m:VerifyCertificate xmlns:m="http://ws.gematik.de/conn/CertificateService/v6.0">
<m0:Context>
<m1:MandantId>Mandant1</m1:MandantId>
<m1:ClientSystemId>ClientID1</m1:ClientSystemId>
<m1:WorkplaceId>CATS</m1:WorkplaceId>
</m0:Context>
<m2:X509Certificate>MIICsTCCAligAwIBAgIHA61I5ACUjTAKBggqhkjOPQQDAjCBhDELMAkGA1UEBhMCREUxHzAdBgNV
BAoMFmdlbWF0aWsgR21iSCBOT1QtVkFMSUQxMjAwBgNVBAsMKUtvbXBvbmVudGVuLUNBIGRlciBU
ZWxlbWF0aWtpbmZyYXN0cnVrdHVyMSAwHgYDVQQDDBdHRU0uS09NUC1DQTEwIFRFU1QtT05MWTAe
Fw0yMDA4MDQwMDAwMDBaFw0yNTA4MDQyMzU5NTlaMEkxCzAJBgNVBAYTAkRFMSYwJAYDVQQKDB1n
ZW1hdGlrIFRFU1QtT05MWSAtIE5PVC1WQUxJRDESMBAGA1UEAwwJSURQIFNpZyAxMFowFAYHKoZI
zj0CAQYJKyQDAwIIAQEHA0IABJZQrG1NWxIB3kz/6Z2zojlkJqN3vJXZ3EZnJ6JXTXw5ZDFZ5Xjw
Wmtgfomv3VOV7qzI5ycUSJysMWDEu3mqRcajge0wgeowHQYDVR0OBBYEFJ8DVLAZWT+BlojTD4MT
/Na+ES8YMDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL2VoY2EuZ2VtYXRpay5k
ZS9vY3NwLzAMBgNVHRMBAf8EAjAAMCEGA1UdIAQaMBgwCgYIKoIUAEwEgUswCgYIKoIUAEwEgSMw
HwYDVR0jBBgwFoAUKPD45qnId8xDRduartc6g6wOD6gwLQYFKyQIAwMEJDAiMCAwHjAcMBowDAwK
SURQLURpZW5zdDAKBggqghQATASCBDAOBgNVHQ8BAf8EBAMCB4AwCgYIKoZIzj0EAwIDRwAwRAIg
VBPhAwyX8HAVH0O0b3+VazpBAWkQNjkEVRkv+EYX1e8CIFdn4O+nivM+XVi9xiKK4dW1R7MD334O
pOPTFjeEhIVV</m2:X509Certificate>
</m:VerifyCertificate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
Response
HTTP/1.1 200 OK
Content-Type: text/xml;charset=utf-8
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<ns4:VerifyCertificateResponse xmlns:ns2="http://ws.gematik.de/conn/ConnectorCommon/v5.0"
xmlns:ns3="http://ws.gematik.de/tel/error/v2.0"
xmlns:ns4="http://ws.gematik.de/conn/CertificateService/v6.0">
<ns2:Status>
<ns2:Result>OK</ns2:Result>
</ns2:Status>
<ns4:VerificationStatus>
<ns4:VerificationResult>VALID</ns4:VerificationResult>
</ns4:VerificationStatus>
<ns4:RoleList>
<ns4:Role>1.2.276.0.76.4.260</ns4:Role>
</ns4:RoleList>
</ns4:VerifyCertificateResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>|
ℹ️
|
In <ns4:VerificationResult></ns4:VerificationResult> wird das Prüfergebnis des Zertifikats [VALID = gültig, INCONCLUSIVE = offline-gültig ohne Sperrstatus, INVALID = ungültig] angegeben
|
|
ℹ️
|
in <ns4:Role>VALID</<ns4:Role> ist die technische Rolle hinterlegt, wie im Zertifikat angegeben.
|
|
ℹ️
|
Aufgrund der im Feld befindlichen unterschiedlichen Konnektorversionen ist ggfs. nicht in allen Installationen die aktuell gültige Liste der OIDs gemäß gemSpec_OID bekannt. Daher kann es vorkommen, dass einige Konnektorversionen die Zertifikate als ungültig betrachten. Die gematik arbeitet an einer Lösung, die Primärsystemen die Implementierung des PKI-Stacks in einer Übergangsphase erspart. |
|
❗
|
Die Gültigkeitsprüfung von ECC-Zertifikaten unterstützt der Konnektor erst in der Version PTV4 ("ePA 1.0"). |
Das vom IDP bereitgestellte Challenge-Token muss mit der AUT-Identität der SMC-B signiert werden. Das Primärsystem berechnet den Hashwert der Challenge im vom IDP vorgegebenen SHA-256-Verfahren und ruft für diesen Hashwert die Konnektor-Operation ExternalAuthenticate auf.
Für das obige Challenge-Beispiel ergibt sich der folgende SHA-256-Wert: 94238882b24aaade41950ecee5a8ab14c4196ed4c5d9d2dfa344fdfd63a27262 in HEX-Darstellung, welcher dann Base64-codiert werden muss (ergibt lCOIgrJKqt5BlQ7O5airFMQZbtTF2dLfo0T9/WOicmI=, siehe CyberChef-Beispiel).
URI |
|||||
|---|---|---|---|---|---|
Method |
POST |
||||
HTTP Header |
Content-Type: text/xml; charset=UTF-8 Content-Length: 1234 SOAPAction: "http://ws.gematik.de/conn/SignatureService/v7.4#ExternalAuthenticate" |
||||
Payload |
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:ExternalAuthenticate xmlns:ns0="http://ws.gematik.de/conn/SignatureService/v7.4">
<ns1:CardHandle xmlns:ns1="http://ws.gematik.de/conn/ConnectorCommon/v5.0">smc-b_2</ns1:CardHandle>
<ns2:Context xmlns:ns2="http://ws.gematik.de/conn/ConnectorContext/v2.0">
<ns3:MandantId xmlns:ns3="http://ws.gematik.de/conn/ConnectorCommon/v5.0">Mandant1</ns3:MandantId>
<ns4:ClientSystemId xmlns:ns4="http://ws.gematik.de/conn/ConnectorCommon/v5.0">myPVS</ns4:ClientSystemId>
<ns5:WorkplaceId xmlns:ns5="http://ws.gematik.de/conn/ConnectorCommon/v5.0">WP1</ns5:WorkplaceId>
</ns2:Context>
<ns0:BinaryString>
<ns7:Base64Data xmlns:ns7="urn:oasis:names:tc:dss:1.0:core:schema">lCOIgrJKqt5BlQ7O5airFMQZbtTF2dLfo0T9/WOicmI=</ns7:Base64Data>
</ns0:BinaryString>
</ns0:ExternalAuthenticate>
</soap-env:Body>
</soap-env:Envelope>
|
Response
HTTP/1.1 200 OK
Content-Type: text/xml;charset=utf-8
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns4:ExternalAuthenticateResponse xmlns="http://ws.gematik.de/conn/ConnectorCommon/v5.0"
xmlns:ns2="http://ws.gematik.de/conn/ConnectorContext/v2.0"
xmlns:ns3="urn:oasis:names:tc:dss:1.0:core:schema"
xmlns:ns4="http://ws.gematik.de/conn/SignatureService/v7.4"
xmlns:ns5="http://www.w3.org/2000/09/xmldsig#"
xmlns:ns6="http://ws.gematik.de/tel/error/v2.0"
xmlns:ns7="http://uri.etsi.org/01903/v1.3.2#"
xmlns:ns8="http://ws.gematik.de/conn/CertificateServiceCommon/v2.0"
xmlns:ns9="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:ns10="http://www.w3.org/2001/04/xmlenc#"
xmlns:ns11="http://uri.etsi.org/02231/v2#"
xmlns:ns12="urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:schema#"
xmlns:ns13="urn:oasis:names:tc:dss-x:1.0:profiles:SignaturePolicy:schema#"
xmlns:ns14="urn:oasis:names:tc:SAML:2.0:assertion">
<Status>
<Result>OK</Result>
</Status>
<ns3:SignatureObject>
<ns3:Base64Signature Type="urn:ietf:rfc:3447">iSCNtUJUaH3uameymaYdplnmn5iq6k90a8i/TvSRvYOjw3x7zXn6+74LoVDc1xWNplmy6fzZejoIZAPxAJ0wBGQWFbdpD6ZLdOqC+Cm3BXUEXHeW2swfI6KfUwfWj43pujBTdzYI6JYG08sL63fxuY9eeGndzuWCDvHQVK0bPPjxq0K/fHx+PFQ1DxuNr5jbDaCBKOegPvcPXOFBY8dRGW0fu/T8baEpm5ACNGmX3vIqC3SWsP7M1TcTbEwxh82vMc0iOkIVDa2LKJAk5H4gSBBAGJahsFD3N3fnKgdLr81HiEQaoIyb+uEIVvaemz8yQ59dAIv3Hrb0Em5k/faHDQ==</ns3:Base64Signature>
</ns3:SignatureObject>
</ns4:ExternalAuthenticateResponse>
</soap:Body>
</soap:Envelope>Code |
Type Success |
200 |
OK |
Code |
Type Error |
400 |
Bad Request |
|
ℹ️
|
<ns3:Base64Signature></ns3:Base64Signature> enthält die Signatur, die mittels Konnektor und dem privaten Schlüssel der SMC-B erstellt wurde.
|
|
ℹ️
|
Nutzung der Gesundheitskarte Versicherte weisen sich gegenüber der Telematikinfrastruktur mit der Identität der elektronischen Gesundheitskarte aus. Der Ablauf ist analog zu dem oben ausgeführt Ablauf für Primärsysteme. Das E-Rezept-FdV bündelt dabei (wie das Primärsystem) in Stufe 1 die E-Rezept-Fachlogik und die Funktion des Authenticator-Moduls. Die Signatur der Challenge erfolgt bei Nutzung der elektronischen Gesundheitskarte bspw. über die NFC-Schnittstelle des Mobilgeräts. Dabei wird das Schlüsselmaterial PRK.CH.AUT für Private-Key und C.CH.AUT für das Zertifikat inkl. PublicKey verwendet. |
Der Einsatz moderner Transportverschlüsselung ab TLS 1.2 schützt vor der Einsicht sensibler Daten beim Transport über das Internet. Dabei sind sowohl die Daten des HTTP-Body als auch die aufgerufene URL und die HTTP-Header verschlüsselt. In modernen Cloud-Infrastrukturen enden solche TLS-Verbindungen meist an einem Internetgateway, müssen jedoch in einer Serverinfrastruktur häufig zu dahinterliegenden Applicationservern und -diensten weitertransportiert werden.
Um sensible Daten bis hinein in einen vertrauenswürdigen Ausführungskontext verschlüsselt zu transportieren, erfolgt der Zugang zum E-Rezept-Fachdienst mit einer zusätzlichen Transportverschlüsselung für eine kryptografische Identität der vertrauenswürdigen Ausführungsumgebung (VAU). Dabei werden die Daten des HTTP-Body für den Verarbeitungskontext der VAU um einen symmetrischen Antwortschlüssel ergänzt und anschließend asymmetrisch verschlüsselt. Dieser verschlüsselte HTTP-Request wird dann mittels TLS transportverschlüsselt an den E-Rezept-Fachdienst übergeben.
|
ℹ️
|
Das Diagramm inkl. der konkreten Ablaufbeschreibung befindet sich auch im Spezifikationsdokument [gemSpec_Krypt] in Kapitel 7. |
Die VAU des E-Rezept-Fachdienstes erzeugt eine HTTP-Response entsprechend des Workflows im E-Rezept und verschlüsselt diese Response symmetrisch mit dem vom Client bereitgestellten Antwortschlüssel. Die verschlüsselte Response wird anschließend mittels TLS transportverschlüsselt an den Client zurückgegeben.
Ein zusätzlich in den Aufrufen vom E-Rezept-Fachdienst generiertes, wechselndes Nutzerpseudonym wirkt zusätzlich Überlastungsangriffen entgegen, indem Aufrufe ohne Nutzerpseudonym mit einer geringeren Priorität bearbeitet werden.
|
🔥
|
Die zusätzliche Verschlüsselung erfolgt mit dem AES-GCM-Verfahren, die über ein AuthenticationTag am Ende des Bitstroms die Integrität des transportierten Ciphertextes sicherstellt. Der AES-Schlüssel ergibt sich zufällig aus der Ableitung über den öffentlichen ECC-Schlüssel des VAU-ENC-Zertifikats. Sind der verwendete Random oder die X- und Y-Koordinaten des ECC-Schlüssels dabei nicht exakt 32 Byte groß, werden die Daten zwar korrekt verschlüsselt, aber das AuthenticationTag passt am Ende nicht zum Ciphertext - der Fachdienst muss das dann gemäß AES-Spezifikation als "manipuliert" ablehnen und antwortet mit einer Fehlermeldung vau decryption failed: AesGcmException can’t finalize AES-GCM decryption;
|
Die folgenden beispielhaften Code-Zeilen prüfen auf eine exakte Länge:
//sharedSecretBytes muss 32 Byte groß sein entweder vorn abschneiden oder mit 0 auffüllen
if (sharedSecretBytes.Length > 32) {
sharedSecretBytes = sharedSecretBytes.Skip(sharedSecretBytes.Length - 32).ToArray();
} else if (sharedSecretBytes.Length < 32) {
sharedSecretBytes = Enumerable.Repeat((byte) 0, 32 -
sharedSecretBytes.Length).Concat(sharedSecretBytes).ToArray();
}Ein Java-Beispiel stellen wir in der folgenden Datei VAUClientCrypto.java bereit, in der dieses Problem mit der Methode pad32(byte[] input) behandelt wird.
Der E-Rezept-Fachdienst benötigt eine Kennzeichnung im äußeren http-Request, um den verschlüsselten Inhalt an den fachlich zuständigen VAU-Kontext zu routen. Um eine Überlastung nutzerrollen- und workflowspezifischer VAU-Kontexte zu vermeiden, werden die http-Header X-erp-user und X-erp-resource genutzt. Die folgende Tabelle zeigt die Belegung der Header zur Nutzung durch die entsprechenden E-Rezept-Nutzer (in den Beispielen der verschiedenen UseCases sind die jeweiligen Header-Belegungen für den äußeren http-Request angegeben):
Leistungserbringer (PVS, AVS ,KIS) |
Versicherte (E-Rezept-App) |
|
|
|
|
Zunächst muss das Verschlüsselungszertifikat der VAU vom E-Rezept-Fachdienst abgerufen werden.
URI |
|||
|---|---|---|---|
Method |
GET |
||
HTTP Header |
X-erp-user: l
|
||
Payload |
- |
||
Response |
HTTP/1.1 200 OK
Content-Type: application/pkix-cert
1100110001111111000000011011000010100111100001111000010010111001... |
Der E-Rezept-Fachdienst stellt zusätzlich eine frische OCSP-Response für die erweiterte Prüfung des Verschlüsselungszertifikats bereit.
URI |
|||
|---|---|---|---|
Method |
GET |
||
HTTP Header |
X-erp-user: l
|
||
Payload |
- |
||
Response |
HTTP/1.1 200 OK
Content-Type: application/ocsp-response
100100100110001011110001110111011000110000101111101100100111011... |
Für den verschlüsselten VAU-Transport wird der zu transportierende HTTP-Request für die VAU in mehreren Schritten aufbereitet. Als Beispiel wird im Folgenden die Abfrage aller E-Rezepte eines Versicherten verwendet.
GET /Task HTTP/1.1
Host: erp.zentral.erp.splitdns.ti-dienste.de
Authorization: Bearer eyJraWQ.ewogImL2pA10Qql22ddtutrvx4FsDlz.rHQjEmB1lLmpqn9J
User-Agent: E-Rezept FdV/1.0.0 gematik GmbH/GEMxxxxxxxxxxxxxxxxx
Accept: application/fhir+json;charset=utf-8|
❗
|
Der zu verschlüsselnde http-Request muss vollständig und syntaktisch korrekt gemäß RFC-2616 erstellt werden (d.h. inkl. aller verpflichtenden http-Header und ggfs. http-Body 'new line'-getrennt). |
Zunächst müssen im Client eine zufällige Request-ID (z.B. b69f01734f34376ddcdbdbe9af18a06f) und ein symmetrischer Antwortschlüssel (z.B. 16bac90134c635e4ec85fae0e4885d9f) generiert werden.
Als nächstes wird die folgende leerzeichengetrennte Zeichenkette p für die anschließende Verschlüsselung gebildet: p="1" + " " + ACCESS_TOKEN + " " + Request-ID + " " + Antwortschlüssel + " " + HTTP-Request, mit obigem Beispiel ergibt sich für p:
"1 eyJraWQ.ewogImL2pA10Qql22ddtutrvx4FsDlz.rHQjEmB1lLmpqn9J b69f01734f34376ddcdbdbe9af18a06f 16bac90134c635e4ec85fae0e4885d9f GET /Task HTTP/1.1
Host: erp.zentral.erp.splitdns.ti-dienste.de
Authorization: Bearer eyJraWQ.ewogImL2pA10Qql22ddtutrvx4FsDlz.rHQjEmB1lLmpqn9J
User-Agent: E-Rezept FdV/1.0.0 gematik GmbH/GEMxxxxxxxxxxxxxxxxx
Accept: application/fhir+json;charset=utf-8"Diese Zeichenkette wird nun mit dem ECIES-Verfahrens [SEC1-2009] und dem öffentlichen Schlüssel aus dem zuvor abgerufenen Verschlüsselungszertifikat der VAU hybrid verschlüsselt. Sei 1101110011011110000101101000111000010101100110111011111100011111111110001101110010011010010110000101000001011000000100 ein unvollständiges Beispiel für das Ergebnis der Verschlüsselungsoperation. Dieses wird nun als Payload im HTTP-Body des folgenden Requests an den E-Rezept-Fachdienst übergeben.
URI |
|||
|---|---|---|---|
Method |
POST |
||
HTTP Header |
|
||
HTTP Body |
|
||
Response |
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Userpseudonym: 5a049a2c1654e685247e2d20136445d9-632f841a029564ce000f29675d192513
001111101111100110001001001111010110010010111110101100100011110... |
|
ℹ️
|
Die 0 am Ende der URL des Requests steht für ein (dem Client nicht bekanntes) Nutzerpseudonym, nach der ersten Antwort der VAU des E-Rezept-Fachdienstes kann das vom Fachdienst mitgeteilte Userpseudonym 5a049a2c1654e685247e2d20136445d9-632f841a029564ce000f29675d192513 anstelle der 0 verwendet werden, um Folgezugriffe höher zu priorisieren.
|
Nach dem erfolgreichen Abschluss der Bearbeitung des Requests durch die VAU des E-Rezept-Fachdienstes erhält der Client die verschlüsselte HTTP-Response der VAU in einer äußeren "VAU-Transport"-HTTP-Response.
Der HTTP-Statuscode 200 signalisiert dabei die korrekte Verarbeitung und Erstellung der verschlüsselten Antwort. Die innere HTTP-Response des fachlichen Ergebnisses aus der VAU kann dabei einen abweichenden HTTP-Statuscode beinhalten, wenn aufgrund der Daten oder Verarbeitung innerhalb der VAU Fehlerzustände eintreten oder ungültige Daten übergeben wurden. Sei 001111101111100110001001001111010110010010111110101100100011110… die verschlüsselte Response zum obigen Beispiel. Die Entschlüsselung mit dem für den Request generierten Antwortschlüssel `16bac90134c635e4ec85fae0e4885d9f`mittels AES-GCM liefert die innere HTTP-Response der VAU als leerzeichengetrennte Zeichenkette:
1 b69f01734f34376ddcdbdbe9af18a06f HTTP/1.1 200 OK
Content-Type: application/fhir+json;charset=utf-8
Content-Location: https://erp.zentral.erp.splitdns.ti-dienste.de/Bundle/f5ba6eaf-9052-42f6-ac4e-fadceed7293b
{
"resourceType": "Bundle",
"id": "authentisieren-07-response-InnerVau",
"meta": {
"lastUpdated": "2025-01-15T15:29:00.434+00:00"
},
"type": "searchset",
"total": 2,
"link": [
{
"relation": "self",
"url": "https://erp.zentral.erp.splitdns.ti-dienste.de/Task/"
}
],
"entry": [
{
"fullUrl": "https://erp.zentral.erp.splitdns.ti-dienste.de/Task/Example-Task",
"resource": {
"resourceType": "Task",
"id": "Example-Task",
"meta": {
"profile": [
"https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Task|1.4"
]
},
"intent": "order",
"extension": [
{
"url": "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_EX_PrescriptionType",
"valueCoding": {
"code": "160",
"system": "https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_FlowType",
"display": "Muster 16 (Apothekenpflichtige Arzneimittel)"
}
},
{
"url": "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_EX_AcceptDate",
"valueDate": "2025-02-12"
},
{
"url": "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_EX_ExpiryDate",
"valueDate": "2025-04-15"
}
],
"identifier": [
{
"use": "official",
"system": "https://gematik.de/fhir/erp/NamingSystem/GEM_ERP_NS_PrescriptionId",
"value": "160.000.000.000.000.01"
},
{
"system": "https://gematik.de/fhir/erp/NamingSystem/GEM_ERP_NS_AccessCode",
"use": "official",
"value": "777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea"
}
],
"for": {
"identifier": {
"system": "http://fhir.de/sid/gkv/kvid-10",
"value": "X123456789"
}
},
"status": "in-progress",
"authoredOn": "2025-01-15T15:29:00+00:00",
"lastModified": "2025-01-15T15:29:00.434+00:00",
"performerType": [
{
"coding": [
{
"code": "urn:oid:1.2.276.0.76.4.54",
"system": "https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_OrganizationType",
"display": "Öffentliche Apotheke"
}
],
"text": "Öffentliche Apotheke"
}
],
"input": [
{
"type": {
"coding": [
{
"code": "1",
"system": "https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_DocumentType"
}
]
},
"valueReference": {
"reference": "Binary/281a985c-f25b-4aae-91a6-41ad744080b0"
}
}
]
},
"search": {
"mode": "match"
}
}
]
}|
ℹ️
|
Die innere HTTP-Response hat die folgende Struktur "1" + " " + ursprüngliche-Request-ID + " " + Response-Header-und-Body |
|
|
Ein Splitten der inneren Struktur anhand des Leerzeichens " " könnte dazu führen, dass auch der Payload im inneren HTTP-Response-Body zerstückelt wird. Robuster ist das Prüfen auf Vorhandensein der ursprünglichen Request-ID und anschließendes Entfernen des von der VAU hinzugefügten Präfixes "1" + " " + ursprüngliche-Request-ID + " ". Nun kann die innere HTTP-Response standardgemäß weiterverarbeitet werden.
|