Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dighealth:ti:elektronische_patientenakte [2024/01/14 11:46] – [Verschlüsselungsmechanismus der ePA] fjh
+++ dighealth:ti:elektronische_patientenakte [2024/04/04 06:08] (aktuell) – fjh
@@ Zeile 1: / Zeile 1: @@
 ====== Elektronische Patientenakte (ePA) ======
-<note>Zum Angriff auf das Video-Ident-Verfahren, dass zur Identifikation bei der Registrierung zur ePA u.a. verwendet wurde und nun nicht mehr erlaubt ist: [[https://www.ccc.de/system/uploads/329/original/Angriff_auf_Video-Ident_v1.2.pdf|https://www.ccc.de/system/uploads/329/original/Angriff_auf_Video-Ident_v1.2.pdf]]</note>
-Weitere Quellen:
-  * [[https://www.zeit.de/digital/datenschutz/2022-08/videoident-verfahren-online-identitaetsnachweis-ausweis-risiken
-]]
 ===== Abgrenzung zur Primärdokumentation =====
@@ Zeile 130: / Zeile 126: @@
 Die Berechtigungsschlüssel (symmetrische AES-256-Bit-Schlüssel) werden von zwei Schlüsselgenerierungsdiensten (SGD) für die jeweils authentisierte eGK, al.vi-Identität, SMC-B(/-KTR) generiert, einem fachanwendungsspezifischen (SGD 1) und einem zentralen (SGD 2). Letzterer gehört zu den zentralen Diensten der TI. Vor der Speicherung durch den Fachdienst werden die Daten vom Client (FdV bzw. Konnektor) mit dem Schlüssel des SGD 1, dann das Chiffrat mit dem Schlüssel des SGD 2 verschlüsselt. Auf diese Weise ist sichergestellt, dass die Daten weder von der TI-Plattform noch vom Anbieter des Fachdienstes entschlüsselt werden können. Zudem lassen sich trotz Verlust des privaten asymmetrischen Schlüssels (der eGK, al.vi-Identität, SMC-B(/KTR) individuell für einen Benutzer verschlüsselte Daten widerherstellen, ohne dass ein Ersatzschlüssel (ggf. treuhänderisch) sicher aufbewahrt oder bei Bedarf z.B. aus geteilten Geheimnissen erzeugt werden müsste.((https://fachportal.gematik.de/fachportal-import/files/gemSpec_SGD_ePA_V1.5.0.pdf.))
-Die Metadaten und technische Daten (Inhalte des Zugriffsprotokolls und Policy Document als Summe aller vom Versicherten vergebenen Zugriffsberechtigungen auf Datenobjekte in der Komponente Dokumentenverwaltung) eines Aktenkontos werden ebenfalls verschlüsselt abgelegt. Die Verschlüsselung erfolgt mittels eines sogenannten **Kontextschlüssel**s. Dieser wird beim Start einer Aktenkonto-Session in die VAU eingebracht, in der Metadaten verarbeitet werden können. Beim Beenden der Sitzung wird der Kontextschlüssel wieder aus dem Arbeitsspeicher der VAU gelöscht. Das Prinzip ist mit einer virtuellen Festplattenverschlüsselung vergleichbar. Auch der Kontextschlüssel wird initial beim Aktivieren eines Aktenkontos erzeugt und mit den SGD-Schlüsseln für die Zugriffsberechtigten verschlüsselt abgelegt.
+Die Metadaten und technische Daten (Inhalte des Zugriffsprotokolls und Policy Document als Summe aller vom Versicherten vergebenen Zugriffsberechtigungen auf Datenobjekte in der Komponente Dokumentenverwaltung) eines Aktenkontos werden ebenfalls verschlüsselt abgelegt. Die Verschlüsselung erfolgt mittels eines sogenannten **Kontextschlüssel**s. Dieser wird beim Start einer Aktenkonto-Session in die VAU eingebracht, in der Metadaten und andere technische Daten über den sog. **Verarbeitungskontext** verarbeitet werden können. Auf die sensiblen Daten des Verarbeitungskontextes kann nur von Berechtigten zugegriffen werden, die über das kryptografische Material verfügen. Beim Beenden der Sitzung wird der Kontextschlüssel wieder aus dem Arbeitsspeicher der VAU gelöscht. Das Prinzip ist mit einer virtuellen Festplattenverschlüsselung vergleichbar. Auch der Kontextschlüssel wird initial beim Aktivieren eines Aktenkontos erzeugt und mit den SGD-Schlüsseln für die Zugriffsberechtigten verschlüsselt abgelegt.
+Anders bei der VAU des E-Rezept-Fachdienstes. Die symmetrischen Schlüssel zur verschlüsselten Persistierung der E-Rezepte werden in einem HSM in der VAU abgeleitet. Es gibt keine Kontextseparierung, da Versicherte keinen schreibenden Zugriff haben, d.h. der versichertenindividuelle Kontextschlüssel entfällt und ein Sandboxing der verarbeiteten Daten verschiedener Versicherter während des Betriebs ist nicht notwendig.
+==== Kritik an VAU-Konzept/-Implementierung ====
+  * SGX-Exploits: https://downfall.page/media/downfall.pdf
 ===== Metadaten =====
@@ Zeile 175: / Zeile 177: @@
 ===== Fristen und Sanktionen =====
+<note important>Die Sanktionierung läuft mittlerweile über die TI-Pauschale. Bis zur Einführung der [[dighealth:ti:epa:status_epa4all|ePa für alle]] wird es aber keine Sanktionierung geben, wenn die "alte" ePA nicht technisch vorgehalten oder aktualisiert wird.((https://www.aerzteblatt.de/nachrichten/148563/Elektronische-Patientenakte-Ministerium-setzt-Sanktionen-fuer-Praxen-aus.))</note>
   * **Krankenkassen** sind zum **1.1.2021** verpflichtet, den Versicherten eine ePA zur Verfügung zu stellen. Zudem sind die für die Folgestufen definierten Anforderungen zu den jeweiligen Terminen ebenfalls fristgerecht zu erfüllen.((§ 342 Abs. 1 SGB V))
@@ Zeile 224: / Zeile 228: @@
 **Kann man einfach ein Tablet mit einem FdV (ePA-App des Versicherten) in eine Arztpraxis oder eine Geschäftsstelle der Krankenversicherung "hinlegen", um auch Menschen, die kein Smartphone besitzen, eine (feingranulare) Berechtigungsvergabe für ihre ePA-Dokumente zu ermöglichen?**
 Nein. Die App (bzw. das FdV) ist an das Gerät gebunden, was durch eine Codeeingabe jeweils bestätigt werden muss. Für das erste Gerät, dass in Betrieb genommen wird, muss zudem eine Identifizierung (bspw. über Post- oder Video/Robo-Ident) erfolgen. Man müsste auf eine Webbrowser-Lösung ausweichen, die aber auch nicht besonders geeignet sind für sichere Lösungen auf einem öffentlich zugänglichen PC/Gerät.
-===== ePA in anderen Ländern =====
-==== Österreich ====
-=== Collection ===
-https://www.derstandard.de/story/2000141847524/unautorisierter-zugriff-auf-elga-patientendaten-in-wiener-spital