{"id":18985611,"url":"https://github.com/gematik/ref-epa-vauchannel","last_synced_at":"2025-04-19T20:34:46.033Z","repository":{"id":49655476,"uuid":"347898797","full_name":"gematik/ref-ePA-vauchannel","owner":"gematik","description":"Possible solution for communication of an ePA-Client and a VAU utilizing the vau-channel-protocol according to gemSpec_Krypt","archived":false,"fork":false,"pushed_at":"2022-04-11T14:30:17.000Z","size":2091,"stargazers_count":8,"open_issues_count":2,"forks_count":3,"subscribers_count":14,"default_branch":"master","last_synced_at":"2025-04-16T19:23:57.817Z","etag":null,"topics":["epa","reference-implementation"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/gematik.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-03-15T08:57:07.000Z","updated_at":"2025-02-22T18:02:33.000Z","dependencies_parsed_at":"2022-09-19T10:10:47.116Z","dependency_job_id":null,"html_url":"https://github.com/gematik/ref-ePA-vauchannel","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fref-ePA-vauchannel","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fref-ePA-vauchannel/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fref-ePA-vauchannel/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fref-ePA-vauchannel/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/gematik","download_url":"https://codeload.github.com/gematik/ref-ePA-vauchannel/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249795067,"owners_count":21326776,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["epa","reference-implementation"],"created_at":"2024-11-08T16:27:25.305Z","updated_at":"2025-04-19T20:34:46.015Z","avatar_url":"https://github.com/gematik.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Basismodul VAU-Kanal, Version 1.3.10\n\n## Überblick\n\nDas vorliegende Modul zeigt exemplarisch, wie das im Spezifikationsdokument [gemSpec_Krypt] normativ festgelegte \nKommunikationsprotokoll \nzwischen VAU und ePA-Clients implementiert werden kann.\n\nSpezifikationsbasis ist \"Release 4.0.2\". \n\n\n## Aufbau des Moduls\n\nDie Implementierung erfolgt in Java (Version 11). Buildsystem ist Apache Maven (Version 3.6.1).\n\n- **vauchannel** ist das maven reactor module, das die einzelnen Teilmodule in einem Build baut.\n- **vauchannel-contract-2-java** legt das Format der ausgetauschten JSON-Nachrichten per JSON Schema (draft-04) und \ndamit unabhängig von der Implementierungssprache fest. Aus den Schemas werden Java Klassen generiert.\n- **vauchannel-protocol** implementiert das Protokoll mit der Verarbeitung der Nachrichten in der Javaklasse \n```VAUProtocol.java```. Die Definition des Kommunikationsprotokoll zwischen VAU und ePA-Clients aus [gemSpec_Krypt] Kapitel 6 \nwerden in ```VAUProtocol.java``` detailliert kommentiert auf die Java-Implementierung gemappt.\nAbgedeckt sind \n    - der Handshake, \n    - der verschlüsselte Nutzdatentransport,\n    - das Fehlerhandling. \n  Alle benötigten kryptografischen Funktionen werden über ein Interface ```VAUProtocolCrypto``` angesprochen. \n  Die konkrete Implementierung des Interfaces ist damit unabhängig von der Protokollimplementierung. \n  Sessioninformationen werden in der ```VAUProtocolSession``` abgelegt.\n- **vauchannel-cxf** zeigt die Einbettung in die WebService-Bibliothek Apache CXF \n(XML/SOAP für die fachlichen Services und JSON/REST für das VAUProtokoll). Der VAU-Kanal startet und endet in dieser Einbettung \nin CXF-spezifischen Interceptoren. Die konkrete Implementierung des VAUProtokolls mit Kryptofunktionen und Ablage der Sessioninformationen wird als \n\"dependency injected\".\n- **vauchannel-server** zeigt exemplarisch die Umsetzung der serverseitigen Endpunkte für Handshake und fachlichen Service \n(hier ein sayHello-Service) als Spring-Boot-Anwendung. Nicht thematisiert:\n    - Das Ansprechen von Handshake-Service und OpenContext-Service unter einem Interface, das beispielsweise durch Trennung \n  der Anfragen über den HTTP-Header ```Content-Type``` in einem vorgelagerten Gateway erfolgen kann.\n    - Die Verwaltung mehrerer ```VAUProtocolSession```.\n- **vauchannel-client** implementiert einen Spring-Boot-Client, der gegen einen laufenden vauchannel-server Integrationstests ausführt.\n\n\n\n## Bauen\n\nDas Modul **vauchannel** wird samt seinen Untermodulen wie folgt gebaut:\n```\nmvn clean install\n```\n\nDas Ergebnis des Builds sollte etwa so aussehen:\n```\n[INFO] ------------------------------------------------------------\n[INFO] Reactor Summary for vauchannel 1.3.10:\n[INFO]\n[INFO] vauchannel ............................. SUCCESS [  0.256 s]\n[INFO] vauchannel-contract-2-java ............. SUCCESS [  2.333 s]\n[INFO] vauchannel-protocol .................... SUCCESS [  6.351 s]\n[INFO] vauchannel-cxf ......................... SUCCESS [  0.686 s]\n[INFO] vauchannel-server ...................... SUCCESS [  7.882 s]\n[INFO] vauchannel-client ...................... SUCCESS [  1.019 s]\n[INFO] ------------------------------------------------------------\n[INFO] BUILD SUCCESS\n[INFO] ------------------------------------------------------------\n```\n\n## Starten\nDen Server starten \n```\ncd vauchannel-server/target\njava -jar vauchannel-server-1.3.10.jar\n```\nund vom Client aus Integrationstests ausführen\n```\ncd vauchannel-client\nmvn verify -Ptest\n```\n\n\n## Release-Notes\n\n### V1.3.10, 2021.12.21\nInterne Anpassungen für die Veröffentlichung über Maven Central.\n\n### V1.3.9, 2021.12.20\nUpgrade von log4j\n\n### V1.3.8, 2021.03.15\nInterne Anpassungen für die Veröffentlichung über Maven Central.\n\n### V1.3.7, 2021.03.12\nDie Generierung der OCSPResponse wurde gemäß Anforderung GS-A_4693-01 [gemSpec_PKI] um die OCSP-Extension \"certHash\" erweitert. \\\nAußerdem wird nun in der OCSP-Response gemäß RFC6960 folgendes sichergestellt:\n- Das Feld CertID wird mit den Informationen des CA-Zertifikates befüllt\n- Die ResponderID wird basierend auf dem Key des OCSP-Signers berechnet\n- Das öffentliche Zertifikat des OCSP-Signers wird in der Response mitgeliefert\n                      \n### V1.3.6, 2020.10.28\n- Die Unterstützung der Deserialisierung des \"Time\"-Felds in VAUServerError-Nachrichten gemäß der Kodierung nach ISO-8601 \n  (Anforderung \"A_16851 - VAU-Protokoll: VAUServerError-Nachrichten\") wurde optimiert.\n\n### V1.3.5, 2020.08.06\n- Fehlermeldungen, die vom Kontextmanager zurückgegeben werden, werden nicht als VAUServerError transportiert.\n- Eine leere OCSPResponse wird in der Nachricht VAUClientSigFin gemäß A_17070-01 als leere Zeichenkette übertragen.\n- Bei der AES-Verschlüsselung im VAU-Kanal muss gemäß A_16945-01 (Client) und A_16952-01 (Server) der Initialisierungsvektor \n      den Nachrichtenzähler enthalten. Dieser wurde bisher nicht in den Initialisierungsvektor übernommen, was durch die Änderung korrigiert wird. Da der Wert jeweils nicht von der Gegenseite geprüft wird, hat die Korrektur keinen Einfluß auf die Interoperabilität. \n\n\n### V1.3.4, 2020.07.27\nBei der Prüfung der Clientidentität an Hand der Nachricht VAUClientSigFinMessage wurden die Hash-Werte zu VAUClientHelloData und VAUServerHelloData aus der Nachricht VAUClientSigFinMessage verwendet.\n    Das wurde korrigiert: Bei der Prüfung werden jetzt die vom Server verifizierten Hashes verwendet. \n    \n### V1.3.3, 2020.05.07\nDas Encoding aus dem HTTP-ContentType-Header wird im CXF-AESInterceptor nun korrekt durch den verschlüsselten Kanal geleitet.\nDadurch wird der HTTP-Content-Type für Typ (2) Nachrichten spezifikationskonform gemäß \n\"A_16884 - VAU-Protokoll: Nachrichtentypen und HTTP-Content-Type\". \n\n### V1.3.2, 2020.03.26\nDie mit V1.3.1 eingeführte Hülle um die ECDSA-Signatur wurde wieder herausgenommen. Der Stand diesbezüglich entspricht \njetzt wieder dem von V1.3.0. Hintergrund: Aus Gründen der Kompatibilität zwischen verschiedenen VAU-Protokollversionen \nsollen Parameter, welche die ECDSA/RSA-Signatur charakterisieren, zukünftig mit der Signatur übertragen werden. \nAnstatt aber auf ASN.1-Ebene diese Parameter zu platzieren ist angedacht, in einer zukünftigen Spezifikationsversion \ndie Parameter auf JSON-Ebene zu transportieren. \n\n### V1.3.1, 2020.03.19\n* **Neu:** Serverzertifikat wird gegen TSL sowie per OCSP geprüft.\n* \u003cdel\u003e**Fehlerbehebung:** Die Einbettung der ECDSA-Signaturen wird in Aktor korrigiert und an die Spezifikation angepasst.\nZur Anforderung [A_16901-0] ist erläutert „Die ECDSA-Signatur MUSS nach [TR-03111#5.2.2. X9.62 Format] (inkl. OID \"ecdsa-with-Sha256\") kodiert sein.“ \nDie Sequenz mit den zwei „Integer“ (r und s aus der ECDSA-Signatur) ist umhüllt von einer Sequence und am Anfang ist die OID „ecdsaWithSHA256“ aufgeführt.\nDiese Hülle hatte bisher bei allen VAU-Kanal ECDSA-Signaturen im Aktor gefehlt.\nWie die Hülle aussieht erläutert das Beispiel in gemSpec_Krypt#5.2 nach „Und am Ende des Zertifikats befindet sich die ECDSA-Signatur“: \n```\n535  10:   SEQUENCE {\n537   8:     OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)\n       :     }\n547  73:   BIT STRING, encapsulates {\n550  70:     SEQUENCE {\n552  33:       INTEGER\n       :         00 A5 0E AA 18 74 F1 F7 B2 2C 77 38 28 58 7F 7F\n       :         5B 7D B2 B7 8A E4 B9 D5 22 B3 4C 71 19 9E 3C 60\n       :         E5\n587  33:       INTEGER\n       :         00 93 43 8A 6E A2 5E 58 60 80 19 62 4E F8 99 F8\n       :         9D DC 90 4E BC C0 55 FD 78 0F 57 65 A9 4B FF 7D\n       :         CA\n       :       }\n       :     }\n       :   }\n```\u003c/del\u003e\n\n### V1.3.0, 2020.03.11\n* **Neu:** Anpassung auf Spezifikationsstand zum Online-Produktivbetrieb, Release 3.1.3.\n\n### V1.2.0, 2019.12.18\n* **Optimierung:** Vollständiger HTTP-Body der entschlüsselten Nachricht wird geloggt.\n* **Optimierung:** Bessere Unterstützung für die Umsetzung der Anforderungen \n\"A_14545 - Komponente ePA-Dokumentenverwaltung - Operationen des Dokumentenmanagements nur über sicheren Kanal nutzbar\"\nund\n\"A_18714 - Komponente ePA-Dokumentenverwaltung - Verhalten des Kontextmanagements bei ungeöffnetem Verarbeitungskontext\"\n* **Optimierung:** Unit-Tests zum Fehlerhandling erweitert\n\n### V1.1.1, 2019.10.23\n* **Fehlerbehebung:** Eine Einschränkung für den Transport großer Dokumente über den VAU-Kanal im Modul vauchannel-cxf wurde behoben.\n\n\n### V1.1.0, 2019.09.18\n* **Neu:** Anpassung auf Spezifikationsstand zum Online-Produktivbetrieb, Release 3.1.2.\n* **Neu:** Insbesondere wurde Change C_7029 implementiert, der für einen verschlüsselten Transport \ndes Content-Type HTTP-Headers sorgt. \n\n\n### V1.0.0, 2019.09.03\n* **Neu:**  Initiale Implementierung gemäß der Spezifikationsdokumente zum Online-Produktivbetrieb, Release 3.1.1.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgematik%2Fref-epa-vauchannel","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgematik%2Fref-epa-vauchannel","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgematik%2Fref-epa-vauchannel/lists"}