VonDoczuDoc.de

email- Verschlüsselung ist eine gute Sache, da email nicht auf dem Prinzip eines peer to peer Netztwerkes beruhen, sondern Serverbasiert sind.

Das heißt die gesendeten emails gehen nicht direkt zum Empfänger sondern laufen zuerst zu einem Zwischen-PC, dem Server, wo sie weiter bearbeitet bzw weiter geleitet werden auf die entsprechende Empfänger/ Verarbeitungssoftware /PC etc. und erst dann beim Empfänger ankommen oder abgerufen werden.

Das ist gleichwertig eines

middle of man Angriffes,

den niemand weis wer auf den Server zugriff hat, der sich irgendwo befindet.
Auch dem Betreiber selbst ist nicht zu trauen, den niemand weis, an wen er die Daten letztendlich veräußert, bearbeiten läßt, verkauft etc.

Bei pretty goog privacy (PGP) ist dies klar geregelt: es gibt einen öffentlichen Schlüssel, den ich für meine Zusender erstelle, auf der Basis meines Privaten Schlüssel auf meinem eigenen PC.
Das selbe gilt umgekehrt, wenn ich jemandem eine verschlüsselt Nachricht zusenden, brauche ich seinen öffentlichen Schlüssel um die Nachricht zu verschlüsseln und nur ER kann diese Nachricht mit seinem privaten Schlüssel entschlüsseln.

Wie sieht es nun bei KIM aus?
Wer weis Bescheid?

Grüsse aus Kiel
Johnny

Das funktioniert bei KIM im wesentlichen genauso.

Hier wurde das mal ganz gut zusammengefasst:
https://www.youtube.com/watch?v=jzKCDd1AZZc

Danke,
Die Schlüssel werden durch den "KIM Verzeichnisdienst bereitgestellt".
Das geschieht auch bei PGP.
Die öffentliche Schlüssel können in einem öffentliche Verzeichnis Anderen zur Verfügung gestellt werden um mir eine verschlüsselte Nachricht zukommen zu lassen.

Bei KIM stellen sich aber noch folgende Fragen:
1) Wer erzeugt diese, meine, öffentlichen Schlüssel für KIM?
Bei PGP bin ich es selbst.
2) Wo befindet sich der Private Schlüssel in TurboMed/KIM um die verschlüsselte Nachrichten lesen zu können?
3) Wer erzeugt den Privaten KIM-Schlüssel für mich ?
Bei PGP bin ich es selbst!


Danke für weitere Verständniserklärungen

Grüsse aus Kiel
Johnny

Ohne mich jetzt zu tief damit beschäftigt zu haben:

Die Schlüssel sind ja auf den Karten (SMC-B, eHBA, SMC-KT etc), d.h. der jeweilige Herausgeber der Karte hat den erzeugt,
und bei der Einrichtung der KIM Adresse wird dann ein Bezug zu der einer der Karten (SMC-B oder eHBA) hergestellt.

Und aus dem Video geht auch hervor:
Die Entschlüsselung und Signaturprüfung erfolgt auf dem Server und wird dann

"Die email wird durch den POP 3-Sever im Klartext übertragen."

Also nix mit EndzuEnd-Verschlüsselung.
Ein klarer Verstoß gegen Datenschutz:

1) können die emails nun auf dem Mailserver im Klartext gelesen werden.
2) Können die emails durch einen middle of man Angriff abgefangen und direkt gelesen werden....wenn
Der Schutz durch das VPN der Konnektor- Server Verbindung versagt!

Bitte um Stellungsnahme
Grüsse aus kiel
Johnny

Das Video ist ja von akquinet AG, da kann ich wenig zu sagen, es war halt einfach der erst beste Hinweis, den ich gefunden habe.

Schaut man bei CGM in den Dokus, sieht es wieder etwas anders aus:
https://www.cgm.com/deu_de/daten/downlo ... wesen.html

Dort steht, dass das KIM Modul die Ver- und Entschlüsselung der Mails übernimmt. Also alles in Ordnung (zumindest an dieser Front)

Danke @pmortara
A]

pmortara schrieb:
Schaut man bei CGM in den Dokus, sieht es wieder etwas anders aus:
https://www.cgm.com/deu_de/daten/downlo ... wesen.html

Auch aus dieser Info-Broschüre von CGM geht aus der Grafik hervor, daß die email auf dem KIM-Server entschlüssel und im "KLARTEXT" vorliegt und der Empfänger dann den Klartext bekommt?

B]

pmortara schrieb:
Dort steht, dass das KIM Modul die Ver- und Entschlüsselung der Mails übernimmt. Also alles in Ordnung (zumindest an dieser Front)

Wenn das KIM-Modul die Verschlüsselung und Entschlüsselung vornimmt, dann muß dort der PRIVATE-Schlüssel erzeugt bzw vorhanden sein.
Ein Schlüssel muß aber aus Zufallszahlen erzeugt werden, dann sollte dort also ein Zufallsgenerator eingebaut sein.
Aber woher nimmt der Zufallsgenerator dann die Zufallszahlen?
Von mir bekommt es sie nicht.

Bei PGP werden die Zufallszahlen durch mich erzeugt,. Z.B. durch Mausbewegungen.

Die Signatur mit der nochmals die Eindeutigkeit des Empfängers bestätigt / unterschrieben wird, liegt natürlich auf den entsprechenden Signaturkarten (SMBC bzw HBA).

Fragen über Fragen

Grüsse aus Kiel
Johnny

Ähm... Sekunde:

Bei der Registrierung wird der öffentliche Teil des Zertifikats der SMC-B bzw. eHBA an den Verzeichnisdienst übermittelt.

Bei der Registrierung der KIM-Adresse erhalten wir ein Zertifikat.
Mit diesem Zertifikat erfolgt die AUTHENTIFIZIERUNG des KIM-Clientmoduls am KIM-Server.
Das ist wie das TLS-Zertifikat zum Konnektor.

Die Ende-zu-Ende-Verschlüsselung erfolgt mit dem privaten Schlüssel von der SMC-B bzw. eHBA (PIN-Eingabe) und dem öffentlichen Schlüssel für die Zieladresse (abgeholt vom Verzeichnisdienst).

Das erledigt das KIM-Clientmodul, indem
a) Client (TurboMed, Thunderbird, Outlook usw.) sich am KCM authentifiziert hat (der "lange" Benutzername etc., ggfs. plus Clientzertifikat für den Konnektor!)
b) Client die Payload ans KCM übermittelt
c) KCM den öffentlichen Schlüssel der Gegenseite aus dem VZD an den Konnektor gibt
d) der Konnektor mittels privatem Key (SMC-B, eHBA) die Nachricht verschlüsselt und
e) der Konnektor die Daten ans KCM zurückgibt
f) das KCM die verschlüsselte Payload als Mail an den zentralen Server übergibt.

Schwachpunkte sind eigentlich nur lokal zu finden:
- Unverschlüsselte Kommunikation Client an KCM (TLS und LDAPS nutzen!)
- KCM selbst
- Bei TurboMed zudem auch der lokale Speicher unter aWinS - da scheint alles im Klartext zu liegen. Unsicherer als die ein wenig abgesicherte Praxisdatenbank

Eine Man-in-the-middle-Attacke sehe ich hier "so" nicht.
Ich vermute, man hat aus dem Fehlstart von De-Mail aufgrund der aufgebrochenen Verschlüsselung "zu Zwecken des automatisierten Malwarescans" gelernt...

Nachtrag: Wenn z.B. das KCM bei der eAU etwas anderes überträgt als die erlaubten MIME-Typen (.PDF, .XLS etc.), dann verweigert der Konnektor die Verschlüsselung.

Das bringt mich auf Gedanken -> Konnektorspeicher groß genug? Buffer overflow nutzbar? Hmmm... das ist Fachgebiet anderer Leute, da halte ich mich raus.

Nachtrag 2:
Der eArztbrief läuft Ende-zu-Ende-verschlüsselt.
Bei KIM-Nachrichten würde ich nochmal nachschauen wollen, ob die nicht "nur" transportverschlüsselt rübergehen, also auf den beteiligten Servern im Klartext liegen und nur die Übermittlung selbst jeweils per TLS/SSL verschlüsselt wird.

Ansonsten: Das dem KIM-eAB zugrundeliegende S/MIME mit Zertifikat (hier: auf Smartcard) kann "ähnlich, aber anders sicher" sein wie PGP. Bei PGP hat man selbst die Schlüsselhoheit über den privaten Teil, bei S/MIME eben ein (hoffentlich) vertrauenswürdiger Herausgeber.

[quote="Johnny"]
Auch aus dieser Info-Broschüre von CGM geht aus der Grafik hervor, daß die email auf dem KIM-Server entschlüssel und im "KLARTEXT" vorliegt und der Empfänger dann den Klartext bekommt?
[quote]

Ich finde eigentlich nicht, dass aus dieser Grafik überhaupt irgendwas klar hervorgeht. Da steht zwar 'Klartext', aber rechts beim Empfänger steht ja nun auch wieder 'entschlüsselt'. Sieht für mich eher nach einer schnell zusammengebastelten Folie aus um die Präsentation noch etwas in die Länge zu ziehen.