Ein Logbuch:Netzpolitik Spezial zu den jüngsten Sicherheitsschwankungen im digitalisierten Gesundheitswesen

Für diese Episode von Logbuch:Netzpolitik liegt auch ein vollständiges Transkript mit Zeitmarken und Sprecheridentifikation vor.
Bitte beachten: das Transkript wurde automatisiert erzeugt und wurde nicht nachträglich gegengelesen oder korrigiert. Dieser Prozess ist nicht sonderlich genau und das Ergebnis enthält daher mit Sicherheit eine Reihe von Fehlern. Im Zweifel gilt immer das in der Sendung aufgezeichnete gesprochene Wort. Formate: HTML, WEBVTT.
Transkript
Shownotes
Prolog
- www.spiegel.de: Verfassungsschutz stuft gesamte AfD als »gesichert rechtsextremistisch« ein
- mygruni.de: Umverteilung Unterstützen – myGruni
ePA
- bkastl.de: Home | bkastl
- netzpolitik.org: Bianca Kastl
- www.inoeg.de: Willkommen beim InÖG
- www.ccc.de: CCC | E-Rezept: Sicherheit nicht ausreichend, Datenschutz mangelhaft
- fachportal.gematik.de: Elektronisches Rezept
- fachportal.gematik.de: Elektronische Patientenakte für alle
- fachportal.gematik.de: Glossar
- Wikipedia (de): Gematik
- ZDFheute: Elektronische Patientenakte geht an den Start
- ZDFheute: Start der elektronischen Patientenakte
- Deutschlandfunk: Elektronische Patientenakte: Chaos Computer Club beklagt Mängel
- heise online: Datenschutz: Kritik an elektronischer Patientenakte wird lauter
- www.gematik.de: Aktuelles | ePA-Sicherheitslücke geschlossen | gematik
- www.spiegel.de: (S+) Elektronische Patientenakte: Hacker umgehen auch die neuen Schutzmaßnahmen
- heise online: E-Patientenakte weiterhin unsicher: Schutzmaßnahmen nicht ausreichend
- media.ccc.de: „Konnte bisher noch nie gehackt werden“: Die elektronische Patientenakte kommt – jetzt für alle!
- www.gematik.de: Struktur | gematik
- Public Health: Europäischer Raum für Gesundheitsdaten (EHDS)
Neue Ministerien und Minister
- Thomas Gigold: Merz’ kleines Gruselkabinett | Thomas Gigold
- netzpolitik.org: Auf den Punkt: Es gibt gleich mehrere Wirtschaftsminister.
Digitalminister
- Wikipedia (de): BDSM
- netzpolitik.org: Designiertes Bundeskabinett: Vom Lobbyisten zum Digitalminister
- www.wiwo.de: WirtschaftsWoche
Innenminister
- netzpolitik.org: Neuer Innenminister: Dobrindts zweiter Versuch
Damals habe ich als Student (muss so um 2007/2008 gewesen sein) an Projekten zu dem Thema gearbeitet. Das war auch die Zeit, als die Gesundheitskarte aufkam. Deren Zweck war nach den damaligen Plänen tatsächlich, wie eine moderne Smartcard die Schlüssel von Patienten, Ärzten und Apothekern zu schützen, womit dann die Gesudheitsdaten Ende-zu-Ende verschlüsselt werden konnten. Man beachte, dass das aus derselben Zeit stammt wie der technisch sehr gelungene Personalausweis.
Die Daten waren auf Servern, aber ohne gültige Karten nicht lesbar. Für Kartenverlust gab es Prozesse, wo nicht einer zentral die Daten aller Patienten auslesen konnte.
Die ersten Probleme kamen dann von einer ganz anderen Seite als heute. Heute ist die Hauptmotivation hinter dem schlechten Schutz der Daten (zentrale Datenbanken mit billigem Access Control statt dezentrale Datenhaltung mit Ende-zu-Ende-Verschlüsselung) die Verwendung für Big-Data-Forschung.
Damals war es ein banaler Grund, den die Informatiker einfach vergessen (?) hatten: Wer gibt die PIN ein, wenn der Patient bewusstlos ist?
Weitere Probleme waren undokumentierte Abweichungen von der Praxis. Es gibt viele Dinge, die laut Gesetzen und Verordnungen nur der Arzt oder Apotheker selbst machen darf, aber in der Praxis von deren Assistenten gemacht wurden. In dem Konzept brauchte man deshalb die entsprechende Arztkarte, die Arzthelfer- oder Krankenpflegerkarten reichten dafür nicht aus. Und das hatte dann zur Folge, dass am Ende die Arztkarte immer im Terminal steckte und alle Praxismitarbeiter die PIN des Arztes kennen.
Dann wurde dann das eigentlich dem Stand der Technik entsprechende System notfallmäßig angepasst, um diese Praxisprobleme zu umgehen. Durch einige der Änderungen wurde aber das ursprüngliche Sicherheitskonzept unterlaufen.
Die aktuelle Sache, warum sie Kartennummern statt Kartenschlüssel für die Authentisierung der Ärzte verwenden, habe ich aber trotzdem nicht verstanden. Das klingt für mich eher nach einem Implementierungsversagen auf Seiten der Gematik. Das Konzept sieht ja nicht ohne Grund vor, dass jeder Teilnehmer eine Smartcard hat.
Linus hat bei den möglichen Zugriffspersonen auf die ePA ja versucht, das möglichst weit zu fassen. Ich würde da noch eine Position hinzufügen: die Personen, die die Rechner in den Arztpraxen betreiben. Genau dort würde ich mich positionieren, wenn ich böse Absichten hätte.
Ich durfte so einen Fall schon einmal selbst miterleben – in einer kleinen Praxis. Der Arzt hatte nicht einmal eine Aushilfe und war schon etwas betagter. Dort stand ein Rechner, aber er konnte meine Karte nicht einlesen. Also rief er den Support an. Dieser wollte per TeamViewer auf den Rechner zugreifen. Das funktionierte erst, nachdem ich ihm geholfen hatte, das Netzwerkkabel wieder in die Buchse zu stecken.
Anschließend hatte der Supportmitarbeiter am anderen Ende vollen Zugriff auf den schlecht gewarteten Windows-Rechner. Zwischendurch wurde der Arzt dann gebeten, seine Zugangsdaten einzugeben. Die eingesetzte Software hieß „Elefant“.
Wenn ich also Einblick in ePAs gewinnen wollte – schön verteilt auf verschiedene Praxen –, würde ich mich genau in so ein Callcenter setzen. Dort rufen den ganzen Tag Ärzte an und bieten einem im Prinzip ihre Zugangsterminals an.
Dann geb ich hier auch ausnahmsweise mal wieder meinen Senf dazu.
Ja ich verstehe all eure Probleme mit der Krankenakte, mein Problem was ich sehe ist neben dem Sicherheitsaspekt aber auch das das ganze ja auch dann funktionieren muss wenn jemand zb in einer Einrichtung lebt. Ich selbst arbeite in einem Seniorenheim. Und wenn ich Smartphone und Passwort höre schrillen bei mir die Alarmglocken. Der normale Bewohner bei uns hat kein Smartphone und geht auch nicht mehr zum Arzt sondern der Arzt kommt zu uns oder wir müssen dann damit hin fahren. Wie macht man das dann mit den Passwörtern, haben wir dann ne dicke Akte wo die alle drin stehen? Und dann ist das mit der Sicherheit ja auch wieder passee. Einfach jeder hier muss ja alles mögliche mit allen möglichen Ärzten abklären. Ja es wäre super wenn der Arzt dann einfach in die krankenakte gucken könnte und sehen was wann wie wo. Aber der Arzt kann halt auch nicht mit pc und Lesegerät durch die Gegend laufen dazu kommt das wir dann mit dem Handy und dem Passwort zum Arzt müssen damit der das einsehen kann. Das ist unfassbar kompliziert und keiner hat die Zeit dazu. Plus man bräuchte noch mal mehr Einwilligungen. Und wenn dann dahinter noch ein Betreuer steht, na Prost Mahlzeit. Das ganze müsste also irgendwie sicher sein aber auch so funktionieren das Bewohner und Leute die zb ihr zu Hause nicht mehr verlassen können über Pfleger, betreuungskräfte, Angehörige und und und das ganze hinbekommen. Und das ist ein Ding das fast unmöglich ist. Frage wie läuft das wo anders? Ich weiß das es das ganze in anderen eu Staaten schon gibt. Wie ist das da geregelt? Und wie weit muss Sicherheit gegen Praktikabilität zurück stecken. Ja natürlich kann ich alles super sicher machen aber dann ist das ganze für viele Leute nicht mehr nutzbar. Für viele ist ja onlinebanking schon zu kompliziert und schwieriger als das darf es auf gar keinen Fall werden.
Liebe grüße
Sabrina
Meiner Meinung nach müsste man bei der Konzeptionierung von Sicherheitsmaßnahmen heutzutage auch Einschätzungen dazu einbeziehen, wie diese in der Praxis umgesetzt werden. Technisch und mathematisch sind die meisten Probleme eigentlich gelöst. Es hapert an vielen anderen Stellen: Einsicht der Notwendigkeit, grundsätzliches Verständnis der Funktion, Effizienz und Praxistauglichkeit. Leider verkommt Sicherheit schnell zu reinem Theater, um ähnlich einem Cargo Cult den Compliance-Gott zu besänftigen. Statt Duct-Tape kommen juristische Regelungen zum Einsatz, die erzwingen sollen, was sich nicht erzwingen lässt. Diese wirken immer genau dann, wenn jemand gegen das elfte Gebot verstößt.
Ein Homo Sapiens mit Internet und Smartphone ist eben immer noch ein Homo Sapiens, eine Spezies, die sich vor allem dadurch auszeichnet, dass sie Dinge in Brand setzen kann.
Danke für diese ausführliche Darstellung der technischen Seite.
Ich habe der ePA schon letztes Jahr widersprochen. Nicht weil ich viel Ahnung von den Sicherheitsproblemem hatte, sondern weil ich das Zugriffsmanagement unter alle Kanone finde. Zum einen dass ich entweder alle oder keinen auf bestimmte Daten Zugriff geben kann/muss und dass meine KK aktuell nur eine Smsrtphone-App für den Zugriff anbietet (Browser über Desktop soll irgendwann kommen). Ich finde das inakzeptabel. Geld und Gesundheit kommt mir nicht aufs Telefon (Ausnahme sind Apps die rein der 2FA dienen aber auch nur wenn es keine Alternative gibt wie TAN-Generatoren). Dafür ist das Telefon schlicht zu sehr Single-Point-of-Failure. Ich würde nicht mal einen Kalender benutzen, der ausschließlich übers Telefon gemanagt werden kann, und erst Recht nicht eine ePA.
ich bin securitymäßig nicht vom fach, aber: könnte man die sicherheitsprobleme der epa vielleicht mit der blockchain lösen? immerhin hat das bundesministerium für gesundheit – lauterbach’s vorgänger sei dank – noch fünf von den dingern irgendwo rumliegen
> Bundesministerium für Digitalisierung und Soziale Medien (BDSM)
Das war meines Wissens nach ein Aprilscherz
Grandpa Simpson hat uns schon vor Jahren vor dieser epa Katastrophe gewarnt, aber hat offenbar nix genutzt:
https://youtu.be/Plr7_SAuB6g?feature=shared
Danke für die schöne Sendung!
Hi,
danke für die spannende Sendung.
Ich verstehe leider überhaupt nicht was gegen Ende-zu-Ende gesprochen hat. Warum müsste irgendwie Schlüsselmaterial per Smartphone geonboarded werden? Was hat das mit Opt-Out zu tun?
Könnte man nicht ein EPA Schlüsselpaar generieren und die öffentlichen Schlüssel auf den Servern speichern. Bei Opt-Out werden die öffentlichen Schlüssel schlicht gelöscht, damit besteht für diese Karte kein Zugang mehr zur EPA.
Wenn ich zum Arzt gehe, dann muss die Karte wissen muss, ob sie den symmetrischen Schlüssel für meine Daten jetzt an mit dem öffentlichen Schlüssel vom Arzt verschlüsseln soll, um Zugang zu gewähren, oder nicht, Dazu lässt die Karte zufällig generierte Zahlen mit dem ihrem öffentlichen Schlüssel signieren. Klappt das nicht, wird der symmetrische Schlüssel für die Daten nicht rausgegeben. Ob der Arzt tatsächlich Zugang zu den Daten hat könnte man umsetzten, indem man sich von der Karte den öffentlichen Schlüssel des Arztes signieren lässt.
Für die paranoiden gibt es zusätzlich die Möglichkeit per NFC mit der Karte zu sprechen und dort lokal die EPA auszuschalten, unabhängig von den Daten, die auf dem Server gespeichert sind. Den NFC-Zugang könnte man per Pin absichern, analog zum Personalausweis. Damit kann ich auch meine Daten einsehen und Ärzten das Vertrauen entziehen.
Erleuchtet mich bitte. :) Vielen lieben Dank für das Lesen und eure Zeit.
Der Amthor ist definitiv einer der kompetentesten in der CDU, wenn’s um Digitales geht. Schließlich hat der doch mal was mit YouTube gemacht. Und mit KI. Und ich habe gehört, er weiß wie man in Word die Schriftart ändert.
Welche Fehleinschätzung. Amthor ist lediglich jung, aber hat keine wirkliche Ahnung.
Tolle Episode. Mir hat schon der Vortrag der beiden beim Kongress gut gefallen und ich habe mich danach für den opt-out entschieden (und family&friends Bescheid gesagt). Herzlichen Dank für Euer Engagement!
Ich fand Linus‘ Aussage krass, dass D alle Fehler wiederholt, die andere Länder mit existierender Digitalisierung schon vor Jahren gemacht haben.
Gibt’s eigentlich nen Katalog an gut abgehangenen security-Maßnahmen, den ihr immer empfehlt?
Hab mal für nen großen online shop in D gearbeitet und einer unserer Services wurde mal von nem red-Team hochgenommen. War eine spannende Erfahrung. Auf dieses Einfallstor wäre ich nie gekommen.
hey, könntet ihr eventuell einmal über stopkillinggames reden. Es läuft noch bis juli
https://netzpolitik.org/2024/videospielsterben-wie-sich-gamer-fuer-den-schutz-des-kulturgutes-videospiel-einsetzen/
Die Behauptung, wonach man beim E-Rezept auf den kryptographischen Nachweis der eGK bewusst verzichtet bzw. das Risiko akzeptiert hat, ist so nicht zutreffend. Es ist IMHO noch schlimmer.
Es gab zwar einen dahingehenden ersten Entwurf der gematik, der aber nach Kritik des CCC und Veto von BfDI und BSI zurückgezogen wurde [1]. Die Kritiker forderten, dass der nach Stecken der eGK über einen Online-Service der Kassen (VSDD bzw. konkret UFS) ausgestellte Prüfungsnachweis kryptographisch abzusichern ist. Diese Forderung wurde dann auch von der gematik umgesetzt.
Man ging davon aus, dass nun ein kryptographischer Nachweis der eGK erfolgt und damit wie vom BfDI gefordert Angriffe durch „böswillige Akteure innerhalb von Apotheken […], Personen, die in die IT-Systeme
von Apotheken eingedrungen sind oder auch Personen, die sich eine Apotheken-TI-ID erschlichen haben“ [2] unterbunden sind.
Problem dabei: Diese Annahme war falsch. Denn der Prüfungsnachweis, egal ob kryptographisch abgesichert oder nicht, weist NICHT nach, dass eine eGK steckt. Er weist nach, dass die auf einer eGK mit gegebener Kartennummer (ICCSN) gespeicherten Versichertenstammdaten bei der Kasse auf Aktualität geprüft wurden.
Zwar wird im Rahmen der Ausstellung des Prüfungsnachweises die Echtheit der eGK bzw. der Besitz von PrK.eGK.AUT_CVC geprüft – allerdings nicht durch den Online-Service der Kassen (UFS), sondern durch den Konnektor in der Apotheke bzw. Praxis. Ein Angreifer kann dazu eine beliebige echte eGK stecken. Anschließend sendet der Konnektor eine ICCSN an den Online-Service der Kassen (UFS) und bekommt den Prüfungsnachweis. Diese ICCSN wird aber – aus mir unbekanntem Grund – nicht aus C.eGK.AUT_CVC ausgelesen, sondern aus einer separaten unsignierten Datei EF.GDO auf der eGK. Ein Angreifer kann die ICCSN in dieser Datei manipulieren oder unter Umgehung des Konnektors direkt mit dem Online-Service der Kassen kommunizieren (eigenen IPsec Tunnel in die TI aufbauen) oder eigene Software auf den Konnektor bringen [3].
Es ist anzunehmen, dass den Spezifikateuren des E-Rezepts sowie der ePA diese Manipulationsmöglichkeit der ICCSN unbekannt war. Der letzte Hinweis darauf wurde innerhalb der gematik vor über 10 Jahren verfasst: „Eine von der gesteckten eGK abweichende ICCSN deutet auf einen Fehler der dezentralen TI oder einen Angriff (!) hin“ [4].
Zur Frage, warum man trotz Hinweis auf diesen Mangel im August 2024 bis heute keinen kryptographischen Echtheitsnachweis umgesetzt hat:
Es gibt zwei Zertifikate auf der eGK, die zur Authentisierung verwendet werden können:
C.CH.AUT – Authentisiert den Karteninhaber (KVNR)
C.eGK.AUT_CVC – Authentisiert die Karte (ICCSN)
Die Zugriffsfreigabe auf die alte Opt-In-ePA wurde mittels C.CH.AUT bzw. dem zugehörigen privaten Schlüssel PrK.CH.AUT erteilt. Dieser Schlüssel muss allerdings durch Eingabe einer PIN freigeschaltet werden.
Für die Zugriffsfreigabe auf die neue Opt-Out-ePA „für alle“ wollte man keine PIN nutzen, da die Beantragung einer PIN eine aktive Antragstellung mit Ident erfordert – de-facto ein Opt-In. C.CH.AUT kann aber ohne PIN nicht verwendet werden. Bleibt C.eGK.AUT_CVC, dessen privater Schlüssel durch jeden in Besitz der Karte verwendet werden kann ohne eine PIN.
Auch beim E-Rezept wollte man nicht den Karteninhaber (C.CH.AUT), sondern die Karte an sich (C.eGK.AUT_CVC) authentisieren, damit auch Vertreter des Inhabers ohne Weitergabe der PIN mit Vorlegen der eGK in der Apotheke Rezepte abholen können.
Die Lösung wäre also, eine Zugriffsfreigabe auf den E-Rezept-Fachdienst oder das ePA-Aktensystem über den Besitznachweis von PrK.eGK.AUT_CVC abzusichern. Problem ist nur, dass der Zugriff auf die in einem eHealth-Kartenterminal gesteckte eGK nur über den Konnektor möglich ist. Der Konnektor verfügt aber bis heute nicht über eine entsprechende Schnittstelle, welche eine Apotheke oder Praxis nutzen könnte, um mit PrK.eGK.AUT_CVC eine Challenge zu signieren. Denn die Nutzung von Karten ohne PIN war bis dato nie vorgesehen. Eine entsprechende Schnittstelle ist inzwischen spezifiziert, zieht aber einen Rattenschwanz an Änderungen z. B. hinsichtlich des Common-Criteria-Schutzprofils [5] hinter sich her und wäre daher unmöglich zum geplanten ePA-Start implementiert, zertifiziert und auf allen > 200.000 Konnektoren im Feld installiert.
Es wird gehofft, dass sowohl die neue Konnektor-Schnittstelle als auch ein neuer PoPP-Fachdienst, welcher zusammen mit dieser Schnittstelle den Zugang zu ePA und E-Rezept über sog. PoPP-Token absichern soll, zum Ablauf der gesetzlich vorgegebenen VSDM-Übergangsfrist Mitte 2026 verfügbar ist. Derzeit läuft ein Teilnahmewettbewerb [6], Angebotsvergabe ist für November 2025 geplant. Aus Gesellschafterkreisen wird die Verfügbarkeit nicht vor 2027 angenommen.
Leider wurde das PoPP-Konzept [7] völlig überfrachtet und ist aufgrund des hohen Zeitdrucks von grundlegenden konzeptionellen (nicht nur Sicherheits-)Mängeln durchzogen. Es wird also erst noch schlimmer, bevor es besser wird – irgendwann nach 2027.
[1] https://logbuch-netzpolitik.de/lnp441-das-pruefen-wir-im-frontend
[2] https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DokumenteBfDI/Stellungnahmen/2022/gematik-eRezept.pdf
[3] https://logbuch-netzpolitik.de/lnp443-auf-yolo-konfigurieren
[4] https://gemspec.gematik.de/downloads/gemSpec/gemSpec_SST_FD_VSDM/gemSpec_SST_FD_VSDM_V1.6.0.pdf
[5] https://commoncriteriaportal.org/nfs/ccpfiles/files/ppfiles/pp0098V3MA03a_pdf.pdf
[6] https://www.dtvp.de/Satellite/public/company/project/CXS0Y53YT5AXK6M3/de/overview?0
[7] https://gemspec.gematik.de/docs/gemKPT/gemKPT_PoPP/latest/