Giters

gematik / api-ti-messenger

API specification for gematik's TI-Messenger - a messaging standard, which will enable healthcare personnel in the German healthcare sector to communicate interoperable via DSGVO-conform messaging-services. The TI-Messenger builds on matrix, the open standard for interoperable, decentralised, real-time communication over IP.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Automatische Kryptografische Nutzerverifizierung

benkuly opened this issue · comments

commented

Dies ist abgeleitet aus ANFTIM-152. Dieses Ticket soll eine öffentliche Diskussion anregen.

Stand TIM 1.1 keine automatische kryptografische Nutzerverifizierung:

  1. ❌ Vertrauen des Servers notwendig - Zero-Trust Ansatz wird verletzt
  2. ❌ Falsches Vertrauen wird erweckt (Pseudo-Sicherheit) – wer haftet?
  3. ❌ Manuelle Verifizierung aufwendig

Vorgeschlagene Lösung (Kurzfassung):

  • Beim ersten Einrichten des Kontos den eigenen Master Signing Key von VZD-RootKey signieren lassen und dann in Matrix hochladen
  • Hinterlegung des vertrauenswürdigen VZD-RootKey public key im Client

Vorgeschlagene Lösung (Langfassung):

Beim Einrichten des Matrix-Konto Cross Signing wird vom VZD-RootKey der MSK signiert. Dies erfolgt z. B. zusammen mit der HBA als 2FA. Der MSK wir dann Matrix-Spec konform hochgeladen.

Wenn ein Matrix-Konto nun einen Chat mit einem anderen Matrix-Konto startet, kann einer Vertrauenswürdigkeit anhand der signierten MSK festgestellt werden. Der VZD-RootKey muss dafür bereits auf dem Client als vertrauenswürdig markiert worden sein. Dies entspricht dem Matrix-Spec Vorgehen, ist jedoch dadurch erweitert, dass eine weitere (also der vorher hochgeladene VZD-RootKey) Signatur vom Homeserver ausgeliefert wird.

Kurz gefasst bedeutet das, dass abweichend von der Matrix-Spec eine extern erzeugte Signatur in das Matrix-Konto eingebracht wird. Dies benötigt vorraussichtlich eine kleine Änderung in Synapse, da Synapse bisher die Sichtbarkeit von Signatur beschränkt, je nachdem, welches Konto die Signaturen herunterladen möchte. Es ist aber keine Änderung von Matrix-Client-SDKs notwendig, was die Implementierung deutlich vereinfacht.

image

Vorteile dieser Lösung:

  1. ✅ Kein Vertrauen des Servers notwendig
  2. ✅ Sehr viele Kommunikationswege verifiziert (weniger manuelle Verifizierungen) - dabei auch einseitig verifiziert, also z. B. Patient zu Arzt.
  3. ✅ Größtenteils Matrix Spec konform (⚠️ kleine Änderung in Synapse notwendig)
commented

Interessant.
Ich möchte vorschlagen, dass wir uns das Thema
"Ist der Nutzer hinter dem TIM-Account/MXID authentisch und gibt es eine zugehörige, verlässliche Rollenauthentisierung?"
anschauen, um dann sinnvolle technische Lösungen abzuleiten.

Aus Gründen der Schweigepflicht ergeben sich hinlängliche Bedarfe für einen "Informationssendenden", dass er sich hinreichend sicher sein kann, dass die Person auf der Gegenseite wirklich
a) die Person ist, die sie vorgibt zu sein
und
b) die Person eine bestimmte Rolle einnimmt

Aus (b) lässt sich u.a. für den Sendenden ableiten, ob der Empfänger auch der Schweigepflicht unterliegt oder nicht.
Diese beiden Themen sind aus meiner Sicht in TIM 1.1 bislang überhaupt nicht berücksichtigt und stellen ein echtes Problem für einen Branchenmessenger im HealthCare-Bereich dar...