Heise: E-Rezept kommt ohne Ende-zu-Ende-Verschlüsselung

Themenvorschläge
1

Quelle: Heise: „E-Rezept kommt ohne Ende-zu-Ende-Verschlüsselung“

Ich finde es eine spannende Frage, ob wir Bürger hinnehmen müssen, dass unsere Gesundheitsdaten quasi auf dem Präsentierteller einer dysfunktionalen IT-Infrastruktur denen präsentiert werden, die in unseren Gesundheitsdaten einen besonderen Daten-Sweetspot sehen.

Stand der Technik ist Ende-zu-Ende Verschlüsselung - das kann jeder Messanger und sogar diese merkwürdigen Zuckerberg-Imperien sind dazu technisch in der Lage, das für Milliarden Menschen zu realisieren.

Ob die Software in der bitteren Realität dann nicht doch NSA-fishy ist lässt sich anhand der proprietären Software ja nicht sagen. Aber da der Signal-Messanger eingebaut wurde und der nach allen bekannten Reviews als sicher eingeschätzt wird, ist der Beweis erbracht, dass man auch Milliarden Menschen eine vertrauenswürdige IT-Infrastruktur bereit stellen kann.

Ich habe dann 2 Fragen:

  1. Wenn uns allen so eine kaputte Infrastruktur aufgezwungen wird, die bewiesenermaßen von Beginn an nicht Stand der Technik ist - wird da nicht gegen unser Recht auf Integrität Informationstechnischer Systeme verstoßen und auch gegen denn Datenschutz? Denn überall dort, wo die Daten dann unverschlüsselt vorliegen, kann illegaler Datenreichtum entstehen.

Zudem stellt sich für mich die Frage, ob es reine Inkompetenz ist, die die Dysfunktionalität treibt. Denn es kann ja auch die Begehrlichkeit existieren, die Gesundheitsdaten ein wenig zu anonymisieren und dann zu gewinnmaximierend zu verhökern. Und wenn das heute verboten ist, kann sich das ja morgen ändern: Der Flaw wurde ja eingebaut …

Eine Infrastruktur, die nur den berechtigten Stellen die relevanten Daten Ende-zu-Ende verschlüsselt bereit stelle, verhindert proaktiv ein Schadensereignis an unseren Gesundheitsdaten.

  1. frage mich daher, ob sich mit Verweis auf das Grundgesetz und die DSGVO nicht ein Riegel vor so eine kaputte Infrastruktur setzen lässt, bevor sie in Betrieb genommen wird. Denn einmal verbreitet lassen sich Daten bekanntlich nicht mehr zurück holen. Der Schaden ist irreversibel.

Viele Grüße,
P.P.

4 „Gefällt mir“
2

Mal ne ernstgemeinte Frage: Welche Enden sollten denn das Rezept lesen können?
Arzt, Apotheke, Patient, Krankenkasse, …

Bzw. wer kann es jetzt lesen, der es nicht lesen können sollte?

1 „Gefällt mir“
4

+1 dafür, dieses Thema zu beleuchten.

Aktuelle Infrastruktur macht Probleme. Für das E-Rezept scheint keine größere Verbesserung vorgesehen zu sein. Dafür sind schon viele weitere Use Cases geplant die dann auch auf der gleichen Plattform laufen sollen.

Klingt leider nicht vertrauenswürdig. Und das obwohl wir gerade mit der Corona Warn App gelernt haben wie es gehen kann. Muss man ja nicht in jedem Aspekt spiegeln aber zumindest in Teilen wäre angemessen bei solch persönlichen Informationen.

1 „Gefällt mir“
5

Hi,
ich bin nicht sicher ob das Thema hier beleuchtet werden sollte, es ist mehr ein technisches als ein politisches. Der Heise Artikel ist leider sehr oberflächlich und schürt Ängste ohne sie mit Details zu begründen.

E2E-Verschlüsselung beschreibt nur eine verbesserte Transportverschlüsselung, bei der einzig die Endgeräte die Schlüssel aushandeln oder haben. E2E sagt nichts darüber aus was die Endgeräte mit den Daten tun oder wie sicher sie sind. WhatsApp Medien sind z.b. ist unverschlüsselt auf dem Phone und das Backup geht auch in die google cloud. Zugriff auf Endgeräte bedeutet als auch mit E2E das eine andere App oder ein Fehler in der App oder im OS das E-Rezept mitlesen kann.

Das einzelne E-Rezept hat mindestens 4 Akteure (Arzt, Krankenkasse, Patient, Apotheke) und potentiell duzende Endgeräte welche die Daten unverschlüsselt benötigen. Auch braucht es eine Verwaltung und Versionierung weil sich der Zustand des E-Rezeptes verändert (Genehmigung, Kostenübernahme, Bezahlung, Lieferung, Abgebrochen etc).

Zusätzlich kommen noch diverse Randbedingungen bei jedem Akteur hinzu weil die Daten in mehreren Schritten verarbeitet und in unterschiedlicher Granularität benötigt werden.

Ohne die jeweiligen Use-Cases alle zu kennen ist es schwer zu beurteilen ob E2E-Verschlüsselung überhaupt die beste technische Lösung wäre. Die mitschwelende Unterstellung das alles was nicht E2E ist, schlecht ist, ist schlicht falsch. Es wurde auch nie gesagt das unberechtigte Zugriff haben sollen und eins der wichtigsten Ziele des E-Rezeptes soll ja die Transparenz sein damit alle Akteure vor Betrug, Mehrfachabrechungen und unlauteren Vergünstigungen etc abstand nehmen.

Ich bin hier kein Verfechter ob das E-Rezept die richtige Architektur oder Implementation gewählt hat.
Sämtliche Logik, Use-Cases, Rechte+Rollen und alle Kommunikation über eine Applikation auf den Endgeräten abwickeln zu wollen ist meiner Meinung nach nicht sinnvoll. Das betrifft ja nicht nur eine Smartphone App, sondern auch alle Kassen-, Buchungs-, Erstellungs-, Genehmigungs-, Wahrenhaltungs- und Abrechnungssysteme die damit in Verbindung stehen.

Ein Client-Server-System ist nicht inherent schlechter und kann ggf. mit einheitlicher Api, guter Skalierbarkeit und Erweiterbarkeit punkten.
Richtig umgesetzte Authentifizierung, Transportverschlüsselung sowie Absicherung auf allen Geräten, Client wie Server, ist sicherlich ein Muss und sollte auch open-source und verifizierbar werden (egal bei welcher Architektur).

Vg
Xyne

7

Unsinn. Es ist ein technisches Problem, kein politisches. Ende-zu-Ende Verschlüsselung zur fordern ohne die Enden benennen zu wollen, das ist eine politische Forderung.

Du kannst nicht einerseits eine technische Lösung fordern (weil jede andere technische Lösung entmündigend, vor-aufgeklärt und neo-feudal wäre), aber andererseits nicht erklären können, wie die von die geforderte technische Lösung einer anderen konkret überlegen wäre.

Entweder bleibst du politisch, dann wäre die Forderung, dass die Daten nur Befugten zur Verfügung stehen darf und nur Befugte sie verarbeiten dürfen (was durch Transportverschlüsselung zwischen bekannten Stellen erreicht werden kann).

Oder du wirst technisch-politisch, dann musst du aber neben einer Verschlüsselungsmethode als Allheilmittel das ganze Konzept erläutern, dass einzige in der Lage ist, deine politischen Forderungen zu erfüllen.

Bei dir könnte das dann so aussehen, dass das Rezept zwischen Arzt und Kunden E-2-E verschlüsselt übertragen wird und dann auf dem Smartphone des Patienten sitzt. Eine Apotheke, die dann auf das Rezept zugreifen will, schickt eine Anfrage an das Smartphone des Patienten und nach Freigabe des Patienten wird es E-2-E-Verschlüsselt an genau diese Apotheke übertragen.
Zum Einlösen sendet die Apotheke dann an den Krankenkassenserver (E-2-E verschlüsselt zwischen Apotheke und Krankenkasse), die entschlüsselt das Rezept und prüft, ob es bereits eingelöst wurde. Usw.

Vorteil wäre verschwindend gering, da das Rezept trotzdem bei jeder Station entschlüsselt vorliegen muss.

8

Aus meiner Sicht ist die Frage, warum man keine E2E-Verschlüsselung möchte. Und das ist hoch politisch. Spahn und die Krankenkassen erhoffen sich dauerhaft Zugriff auf Live-Daten, um so „unwirtschaftliche“ Verordnungen vor dem Einlösen zu korrigieren oder Rezepte zu lenken.
Szenario I:
Arzt verordnet teures Medikament XY an Patient. Krankenkasse merkt das, und kontaktiert den Arzt: Schönes Rezept haben Sie das ausgestellt. Ist bestimmt von Ihrer Therapiefreiheit abgedeckt, aber schöner wäre doch, wenn Sie das günstigere YZ nehmen. Dann sparen wir beide uns die Arbeit, später Regresse zu diskutieren.

Szenario II:
Patient bekommt Medikament XY verordnet. Krankenkasse kontaktiert: Hör mal, schick das doch an Apotheke Z in den Niederlanden. Die müssen sich nicht an deutsche Gesetze halten, aber wir beide bekommen einen netten Bonus.

Szenario III:
Patient bekommt Medikament XY verordnet. Krankenkasse kontaktiert: Wusstest du, dass 50% der Menschen von diesem Medikament gar nicht profitieren? Vielleicht brauchst du das gar nicht? Und falls doch, wie wäre es mal mit Sport? Wäre ja Schade, wenn deine Versicherungsprämie demnächst steigen müsste.

Klar, alles konstruiert, aber alles denkbar. Und alles würde die Grundfesten unserer hervorragenden medizinischen Versorgung erschüttern…

10

Was ihr hier beide beschreibt ist aber wiederum kein Argument für Ende-zu-Ende Verschlüsselung, sondern eine Beschränkung, wer was mit den Daten gemacht werden darf.
Auch bei E2E Verschlüsselten Rezepten liegen sie dem Arzt, Patienten, der Apotheke und der Krankenkassen unverschlüsselt vor.

Ob wund wie dann einzelne Datenobjekte, etwa Rezepte oder Befunde, dann dem jeweiligen Stakeholder (Apotheker, Spezialist, …) zugänglich gemacht werden, sind eigene Use Case, die IT-Architekten und Entwickler diskutieren sollten - und keine LdN-ForistInnen …

Komisch, mMn sind gerade das die Dinge, die von der Öffentlichkeit diskutiert werden sollten. Welche Technologie das dann absichert, dass können die IT-Architekten und Entwickler diskutieren.

Sehr wohl können und sollten wir hier aber diskutieren, wie digitale Souveränität von uns Bürgern über unsere persönlichen (Gesundheits-)Daten ausgestaltet werden soll! Und dem nachgelagert kann man dann diskutieren, wie das technisch implementiert werden kann.

Genau das tust du aber nicht. E2E ist die technische Implementierung.

Eine Krankenkasse ist eine Körperschaft des öffentlichen Rechts mit Selbstverwaltung und regelt ihren Haushalt eigenverantwortlich.

In welcher Definition wird verboten, dass Transportverschlüsselung zwischen bekannten Partnern mit bekannten Zertifikaten erfolgt und die Inhalte digital signiert wurden und damit manipulationssicher gemacht werden?

Das Problem wird aber nicht mit einer E2E-Verschlüsselung gelöst (in der die Krankenkasse als Ende ebenfalls ggf. schon im Moment der Ausstellung des Rezeptes über diese Informationen verfügt). Sondern durch eine gesetzliche Zweckbindung der Daten. Die Annahme, dass KK die Daten dann illegal benutzen, um Gesetze zu umgehen, die Kunden zu beleidigen oder plötzlich individuelle Zusatzbeiträge verlangen, darf wohl… angezweifelt werden.

1 „Gefällt mir“
12

Hier dominiert gerade recht stark die Frage der Standpunkte
‚E2E Verschlüsselung ist nur eine technische Lösung, lasst mal nicht in diesen Details verlieren‘ vs.
‚es gibt keine sichere Alternative zu E2E Verschlüsselung, wenn E2E Verschl. nicht eingeplant ist, legt man offenbar kein Wert auf Datensicherheit‘.
Ich denke Ihr habt beide recht und ihr habt eben unterschiedliche Blickwinkel auf das Thema.

Ich versuche mal die Thematik neu zu strukturieren und werfe ein sehr groben Use Case als Basis ein:

1 Beteiligte: Arzt, Patient, Apotheke, Krankenkasse
2 Epics / Use Case
2.1 E-Rezept
2.1.1 Als Arzt möchte ich ein E-Rezept ausstellen, um Patienten ein Medikament zu verschreiben.
2.1.2 Als Krankenkasse möchten wir, dass E-Rezepte online durch uns authorisiert werden, dazu werden Daten von Arzt, Patient und Medikament heran gezogen „Autorisierung Notwendigkeit“
2.1.3 Als Patient möchte ich ein E-Rezept in meiner App empfangen und mit einem Klick eine Apotheke in der nähe auswählen, in der ich das Medikament holen möchte, um das Kassenrezept weiter zu leiten.
2.1.4 Als Apothekerin möchte ich E-Rezept online empfangen oder via Barcode aus der Patienten App scannen. Nach Aushändigung des Medikaments sollen Daten zwecks Abrechnung automatisch an Krankenkasse gesendet werden.
2.1.5 Als Krankenkasse möchten wir, dass die Herausgabe von Medikamenten auf Basis von E-Rezepten in Apotheken online authorisiert wird, dazu werden Daten des Patient, der Apotheke, der Wirkstoffe und Verfügbarkeit von Alternativprodukten heran gezogen

2 Datensicherheit
2.1 Data in transit: Ende zu Ende Verschlüsselung der Daten als Goldstandard sollte angestrebt werden für Kommunikation zwischen allen Endpunkten. Ssl Transportverschlüsselung stellt keine ausreichenden Schutz da, hier gibt es eine Vielzahl Möglichkeiten von man-in-the-middle Angriffen.
2.2 Data at rest: Alle System Schichten unterhalb der Applikation müssen als unsicher betrachtet werden. Bei Patienten, Ärzten und Apotheken muss davon ausgegangen werden dass Betriebssysteme potentiell ausgespäht werden. Verschlüsselung und Datensparsamkeit ist zu betrachten.

Frage #1: Setzt man sich in dem Unterfangen mit Datenschutz auseinander? Es macht leider nicht den Eindruck wenn man alleine den Heise Artikel liest.
Frage #2: Wird in dem Unterfangen Datensparsamkeit angestrebt? Mir nicht bekannt ob es hier Quellen/ Informationen gibt.
Frage #3: Ist der Use Case einigermaßen valide? Gibt es da Transparenz, die dann später ja auch bei der Akzeptanz helfen wird?
Frage #4: data at rest- daten müssen natürlich inkl. personenbezogenen Daten in der zentralen Telematikinfrastruktur vorliegen. Daten bei anderen Beteiligten können aber doch bestimmt pseudonymisiert vorgehalten und personenbezogene Details nur bei Bedarf nur online abgerufen werden! Hier scheint aber eher der Ansatz zu sein, Verantwortung abzutreten: https://www.gematik.de/news/news/die-telematikinfrastruktur-ist-sicher/

Die telematikinfrastruktur wurde für die digitale Gesundheitskarte geschaffen, es gab IT Sicherheitsprobleme. Jetzt kommt das E-Rezept und viele weitere Use Cases sollen folgen. Aber darauf, dass hier Sicherheit ein Kernthema ist, lässt sich kein Hinweis finden.

1 „Gefällt mir“
13

Du weigerst dich von Anfang an die fachlichen Fragen zu diskutieren: Wer soll Endpunkt sein?

Die Integrität hat nur 0 damit zu tun, ob man E2E oder Transportverschlüsselt. Man kann auch die Integrität von Unverschlüsselten Daten sicherstellen.

Mir scheint du verwechselst Integrität und Vertraulichkeit.

Aber auch hier bleibt es dabei: EntscheidenD IsT, WeR DiE EndeN SinD!
Du kannst die tollste E2E-Verschlüsselung haben, wenn das Gesetz der SCHUFA erlaubt die Daten zur Bestimmung von künftigen Versicherungsprämien auszuwerten, dann nutzt sie dir NICHTS.

15

Was soll schon groß passieren, wenn man Daten unverschlüsselt ablegt?

16

Wir verlieren uns hier in Einzeldiskussionen, daher möchte ich der E2E Fraktion einfach mal zeigen was das Resultat mit E2E wäre:

Annahmen:

  1. Das Rezept wird ausschließlich per E2E-Verschlüsselung gesendet/empfangen.
  2. Das Rezept muss den 4 Beteiligten unverschlüsselt vorliegen:
  • Arzt
  • Krankenkasse
  • Patient
  • Dienstleister (z.b. Apotheke, Spezialist)

Resultat:

  • E2E kann keine Sicherheit des Rezeptes auf den Geräten beeinflussen.
  • E2E kann nicht verhindern das Arzt, KK, Patient oder Dienstleister das Rezept weitergeben.
  • E2E kann keins der Horrorszenarien ausschließen

Was ihr wollt sind Garantien der Ärzte, Krankenkassen und Dienstleister die euer Rezept bekommen:

  • Das das Rezept nicht an jemand weitergegeben wird den ihr nicht authorisiert habt.
  • Das das Rezept auf den internen Systemen nur verschlüsselt abgelegt wird.
  • Programme die darauf zugreifen sicher sind (PC vom Arzt, Datenbank der KK, Kassensysteme der Apotheke, App des Patienten, Drucker, Betriebsysteme etc…)
  • Personen die darauf zugreifen dafür authorisiert sind (Sachbearbeiter, Arzthelfer, Personal der Dienstleister, Patientenverfügte etc…)

E2E kann ein guter Baustein in einer Architektur die Privacy und Datenhoheit by Design liefert sein.
Aber E2E ist technisch nicht in der Lage um eure eigentlichen Bedenken und Forderungen umzusetzen.

vg
Xyne

1 „Gefällt mir“
18

Hallo PeerPeter,

huh, schweres Missverständnis, ich versuche mich besser auszudrücken oder zu konkretisieren, sorry.

Ich hab nur geschrieben das ein Datenleck bei allen Beteiligten passieren kann und dem in meinem Text keine Bewertung der Schwere gegeben.
Ich stelle jetzt eine Vermutung auf: es wird selbst bei einer offenen Api nur eine Handvoll Apps für Patienten geben, Ärzte und Dienstleister tun sich jeweils zusammen und es wird rund ein duzend verschiede Programme/Anbieter geben, die vielen Krankenkassen machen dies als Customized oder Eigenentwicklung. Somit könnte ein Fehler in der App oder in der Ärztesoftware aber auch in großem Stil genutzt werden und viele Anwender gleichzeitig betreffen und die „Hack“ einer einzelnen Krankenkasse betrifft dann weniger. Meine geschätzten Menge als Größenordnung nehmen. Aufgrund dieser Vermutung hab ich die Meinung das ein Datenleck bei allen Beteiligten von Einzelfall bis Katastophal passieren kann.

Wikipedia
Unter Ende-zu-Ende-Verschlüsselung (englisch „end-to-end encryption“, „E2EE“) versteht man die Verschlüsselung übertragener Daten über alle Übertragungsstationen hinweg. Nur die Kommunikationspartner (die jeweiligen Endpunkte der Kommunikation) können die Nachricht entschlüsseln.

Ich hoffe dir reicht hier die Wikipedia, sehr gleich lautende Beschreibungen findet man aber auch sonst in Büchern und Artikeln. Es handelt sich bei E2E also um einen Vorgang wie Daten zwischen Geräten übertragen werden. Demnach sind die Daten vor und nach der E2E beim Sender und Empfänger in verarbeitbarer Form entschlüsselt und es obliegt der Anwendung und dem Besitzer des Endpunktes was er damit tut. Diese Schlussfolgerung hab ich dann in Punkt eins und zwei meines Resultates niedergeschrieben woraus der Punkt 3 und mein letzter Satz implizit folgt.

Ich wollte nichts unterstellen und habe vor allem keinen der Punkte als falsch bezeichnet oder wiederlegt.
Ich habe versucht aus den vielen Beiträgen einige Punkte zu extrahieren die meiner Meinung nach wichtig für eine Umsetzungen sein könnten.
Hab ich das jetzt richtig verstanden, das es dir nicht um das eigentliche wie ist die Transportverschlüsselung geregelt geht, sondern um den Umgang mit den Rezeptdaten vor und nach der Übertragung und durch die Beteiligten?

Dann mal ran an das Problem:

  1. Bist du damit einverstanden das alle 4 Beteiligten (Arzt, KK, Patient, Apotheke/Dienstleister) das E-Rezept an ihrem Endpunkt in verarbeitbarer Form haben?
  2. Sollen diese 4 Beteiligten jeweils vollkommen eigenverantwortlich mit dem E-Rezept weiterarbeiten dürfen oder was sind deine Forderungen an weiteren Kontrollmöglichkeiten?

vg
Xyne

20

Hallo PeerPeter,

Volle Zustimmung, genau das ist doch der Knackpunkt, darauf wollte ich mit der 2ten Frage hinaus.

Und genau diese beiden Aussagen sind der Irrglaube und das Problem in diesem Thema: Es geht darum nicht am Rande sondern primär.

Szenario:
Alice sendet wunderschön per E2E an Charlie.
Charlie hat nun aber eine Legion von Bobs: Bob_Datenbank, Bob_Marketing, Bob_Sachbearbeiter, Bob_Genemigung, Bob_Betrieb, Bob_Archiv etc…
Damit gibt es zwar eine A-C Strecke die sicher ist, aber trotzdem sind many Bobs B1, B2, B7 beteiligt.

Letztendlich hat man zwar E2E aber ohne Kontrolle/Vorschrift wie C mit Bobs umgeht ist das der Schwachpunkt, deine Zitate treffen ein und man hat effektiv die gleichen Probleme.

Jetzt kann man sagen: das ist doch alles nachgelagert, am Rande und Einzelfall. Mitnichten, denn die unzähligen Charlies werden sich sicherlich der selben Bobs bedienen.

A1 ---- E2E ---- C1 ----- ? ----- B1
A2 ---- E2E ---- C2 ----- ? ----- B1
A3 ---- E2E ---- C3 ----- ? ----- B1

ist unter der Annahme unkontrollierter Bobs also genauso schwach wie:

A1 ---- TLS ---- B1 ----- TLS ----- C1
A2 ---- TLS ---- B1 ----- TLS ----- C2
A3 ---- TLS ---- B1 ----- TLS ----- C3

Es ist essentiell dem Empfänger auch nachgelagert vorzuschreiben wie er mit den Daten umgeht.
Der Fokus der Diskussion sollte sich also um die Prozesse, Datenhaltung, fahrlässiger oder missbräuchlicher Umgang und die Architektur & Kontrolle beim Empfänger drehen.

---------------- Technisch -------------

Eine Transportverschlüsselung erlaubt NICHT das ein Hop dazwischen die Daten unverschlüsselt verarbeiten kann. „Irgentwelchen Servern“ ist dies nicht möglich.
TLS basiert auf Zertifikaten und wenn A an C sendet, weiß A das die Daten auschließlich auf Empfangsstellen die von C per Zertifikat authorisiert wurden gelesen werden können.
Das heißt: C kann Bobs in der Kette vor und nachgelagert authorisieren, aber es fließt nichts an „irgendwelche“ „unbekannte“ ab sondern an die die C dafür berechtigt hat.

Das ist übrigens auch Stand der Technik, wird vom BSI empfohlen und wird aus persönlicher Erfahrung bei Banken, Versicherungen und großen Konzernen auch für geheime Daten ohne zusätzliche Absicherung für den Transport zwischen Systemen genutzt.

vg
Xyne

Buchempfehlung für Sci-Fi: Dennis E. Taylor - We are Legion (We are Bob) - Bobiverse-Serie, Buch 1

22

Danke, @Xyne, dass du hier dran bleibst.
Es bleibt dabei, ohne die Enden zu benennen, kann man hier nichts diskutieren. E2E schließe ich ja gar nicht aus. Mit Nichten! Aber es ist halt kein Allheilmittel.

Wenn der Endpunkt halt das gemeinsame Rechenzentrum der Krankenkassen ist, und man sich da entscheidet, die Daten als Klartext in einer MySQL-DB mit admin/admin abzulegen, dann hilft es nichts, dass zwischen Arzt und Rechenzentrum „E2E-Verschlüsselt“ wurde.

24

Ich glaube, wir reden einfach alle aneinander vorbei.

Ohne die Enden zu benennen, ist E2E zu wenig, ohne E2E ist Enden benennen nur die halbe Miete.

26

Jetzt wird es langsam albern. Ob das gemeinsame Rechenzentrum der Krankenkassen „dritte“ sind, ist genau die Frage, die du dich weigerst zu diskutieren.

28

Mir ist das alles bewusst. Bei Rezepten hat man halt nicht den Use Case der 1-zu-1 Kommunikation (bzw. 1-zu-n, wobei alle n einzelne Personen sind), wie bei WhatsApp und Co. Daher war der Verzicht auf E2E bei De-Mail unsinnig und eine gerechtfertigte Kritik. Aber das ist beim E-Rezept halt ein wenig anders. Zumindest bis du mir sagst, was deiner Meinung nach berechtigte Enden sind.

Also was sind die Enden? Arzt, Patient, der Apotheker, der in der vom Patienten gewählten Apotheke gerade Dienst tut und der persönliche Sachbearbeiter in der Krankenkasse des Patienten?

Beantworte doch mal die grundlegende Frage.

30

Das wird mir zu blöde. OK, E2E ist gesetzt. Wer keinen Zugriff haben darf und wer Zugriff haben darf ist zu komplex und kann hier nicht diskutiert werden.

Wo ich was nicht einsehe oder behaupte, weiß ich nicht, aber ich habe jetzt verstanden, dass man E2E fordern kann, ohne Enden zu benennen. Enden benennen zu wollen ist absurd und für die Umsetzung einer Ende zu Ende Verschlüsselung unwichtig.