Die mit der Einrichtung erstellte Signal-Identität wird mit der Mobiltelefonnummer verknüpft. Für die Identitätserstellung benötigt man die Empfangsmöglichkeit einer SMS / eines Anrufs um einen Signal-Code zur Verifizierung zu erhalten.
Sicherung / Wiederherstellung / Geräteumzug:
Die Signal-Identität kann mit einer Signal-PIN gesichert werden. Bei einer Neueinrichtung erlaubt die Signal-PIN die Wiederherstellung der bisherigen Identität auf einem neuen SmartPhone ohne erneute Prüfung der Rufnummer über SMS oder Anrufempfang.
Schlüsselaustausch und Vertrauen zwischen Kommunikationspartnern:
Zu jedem Chat gibt es eine über den Chat-Titel aufrufbare „Sicherheitsnummer anzeigen“ Funktion die einen QR-Code und eine Anzahl von zwölf 5-stelligen Zahlencodes anzeigt.
Man kann bei einem persönlichen Treffen den Code mit Signal einscannen oder aber nach Abgleich der identischen Nummern mit „Als verifiziert markieren“ den Chat verifizieren.
Danach wir dieser als Chat als „Verifiziert“ im Titel angezeigt.
Schutz vor Indentitätsübernahme meiner Kontakte:
Wenn sich die verifizierte Identität eines Kontaktes durch Übernahme der Rufnummer oder durch Einsatz eines neuen Gerätes ändert, meldet mir Signal dieses mit der nächsten Nachricht über einer fetten roten Warnmeldung.
„Name ist nicht mehr als verifiziert markiert. Für Optionen bitte antippen:“
Das antippen führt einen zur Möglichkeit „Sicherheitsnummer anzeigen“ für eine erneute Verifizierung oder „Verwerfen“.
Nachdem der Anwender über „Verwerfen“ oder „Jetzt nicht“ eine Verifizierung abgebrochen hat, befindet sich der Hinweis über die geänderte Sicherheitsnummer noch im Chat, der Anwender wird jedoch nicht daran gehindert mit dem neuen Kontakt Informationen auszutauschen. In jedem Fall fehlt aber bis zur nächsten Verifizierung der Hinweis „Verifiziert“ im Chat-Titel.
Schutz vor Identitätsübernahme meiner Person:
Mit meiner Signal-PIN und der optional zu aktiviertenden Signal Option
„Signal Einstellungen“ > „Konto“ > „Registrierungssperre“ = Ein
kann ich die Neuregistrierung meiner Mobilfunknummer ohne Kenntnis meiner Signal-PIN verhindern, auch wenn die Aktivierungs-SMS / -Anruf vom Angreifer empfangen werden kann. In diesem Fall wird die Neuregistrierung für 7 Tage blockiert bevor der Angreifer meine Mobilfunknummer nutzen kann.
Mir wird eine entsprechende Übernahme meiner Mobilfunknummer über die folgenden Signal-Meldung angezeigt. Innerhalb dieser 7 Tagen kann ich von meiner Installation aus problemlos die Mobilfunknummer mit der mir bekannten Signal-PIN wieder übernehmen und der Angreifer muss seinen Angriff erneut starten.
Ich schließe dennoch die kritische Passage als Anwärter an, die besagt, dass es immer dann, wenn kein eigener Server betrieben wird, eine Frage des Vertrauens in den/die Betreiber ist, ob unseren Wünschen bspw. nach der (wegrollenden) Datenlöschung nachgekommen wird. Wenn die Keys nicht in den eigenen Händen liegen, dürfte dies einige Unsicherheiten auch gegenüber Signal und Threema weiterhin bestehen lassen.
@Joachim: Ich habe jetzt mit Signal und Threema den Aufschlag gemacht, wie diese beiden Messenger das Thema Authentisierung des Kommunikationspartners und die Reaktion auf geändertes Schlüsselmaterial z. B. beim Gerätewechsel oder eines Angriffs behandeln.
Mich würde jetzt interessieren, wie Du Dir eine saubere „Authentifizierung bei Messenger“ vorstellst.
Vielleicht bekommen wir dann einen Vorstellungen davon, was Mike sinnvollerweise in seiner Messenger-Matrix noch ergänzen könnte.
das Grundübel der meisten Messenger ist, dass es zentrale Systeme sind. Egal welcher Rechtsordnung zentrale Systeme unterliegen, ich sehe keinen Grund, denen zu vertrauen. Selbst wenn man das TKG unterstellt, auch die deutschen TK-Anbieter unterlaufen mit den SMS-Spamfiltern in meinen Augen das Gesetz. Chatkontrolle wird die Situation nicht verbessern.
Ende-zu-Ende-Verschlüsselung (E2EE) halte ich bei zentralen Systemen für erforderlich, aber je nach Realisierung des Schlüsselmanagements nicht für hinreichend bei einem nicht-vertrauenswürdigen System. Selbst wenn ich Ende-zu-Ende-Verschlüsselung verwende, kann der zentrale Anbieter zu viele Metadaten mitlesen.
Ende-zu-Ende-Verschlüsselung ist nur dann sicher, wenn der Benutzer oder seine Organisation alleine das Schlüsselmaterial verwaltet, und der Anbieter da nicht eingreifen kann oder ein Eingreifen zuverlässig die Kommunikation verhindert (die Kommunikation verhindern kann er sowieso).
Kryptographie oder Verschlüsselung erfindet man nicht neu sondern verwendet bekannt bewährtes. Denkbar wäre m.E. folgendes:
Für diesen Anwendungsfall erscheint mir für die E2EE eine Inhaltsverschlüsselung ala S/MIME mit entsprechenden personenbezogenen Zertifikaten am geeignetsten. Personenbezogen weil ich dann auf beliebigen Endgeräten der gleiche Kommunikationspartner sein kann.
Im Unterschied zu Email wird bei Messengern meist auf dem 1. Client entschlüsselt und unverschlüsselt gespeichert, das entspricht dem Gateway von Organisationen bei der Ende-zu-Ende-Verschlüsselung von Email.
Wenn man sowieso mit Zertifikaten arbeitet, dann könnte man auch Zertifikate für die Authentifizierung verwenden, muss es aber nicht. Nach den Regeln des CA/Browser-Forums darf man nicht das gleiche Zertifikat wie für Verschlüsselung verwenden.
Beim Ablauf von Zertifikaten oder Anmeldedaten muss der Anbieter kooperieren - eine Sollbruchstelle, aber die Kommunikation verhindern kann er sowieso.
Insbesondere Organisationen können die Gültigkeit Ihrer Zertifikate wahlweise durch vertrauenswürdige Wurzelzertifikate erreichen als auch durch mittels RFC 8162. Nicht vertrauenswürdige Zertifikate (auch selbst signierte) eines Kommunikationspartners müssen Anwender auf einem anderen Kanal prüfen - durch den oben erwähnten Personenbezug aber nicht bei jedem Gerätewechsel. Dadurch hat man aber auch den Freiheitsgrad, beliebig viele Zertifikate zu verwenden.
Da 99,9% der Anwender (bisher) mit Zertifikaten nicht umgehen können wird vermutlich kein kommerzieller Anbieter entsprechendes auch nur in Erwägung ziehen.
Fraglich ist dabei auch: warum überhaupt zentrale Systeme und warum eine Messengeroberfläche? Meine Wahrnehmung: WhatsApp hatte wohl nur Glück dass es eine kostengünstige Alternative zu SMS mit ähnlicher Oberfläche kreiert hat. Man hätte eine ähnliche Oberfläche auch auf Email aufsetzen können und damit eine dezentrale Lösung erreicht. Deltachat macht das, aber erzwingt dabei das wegen kaputtem Schlüsselmanagement ungeeignete PGP. Bei den meisten Anwendern dürfte es vermutlich daran scheitern, dass sie von viel zu vielen anderen Emails empfangen und damit die Oberfläche von Messengern ungeeignet wird.
Ich hatte mir eigentlich erhofft, dass Du konkret beschreibst, wie Du Dir ein sicheres Authentisierungsverfahren bei Messenger vorstellst und welche Funktionen abgebildet sein müssten, damit wir dann schauen können ob und wie Mike so etwas ggf. in der Messenger-Matrix ergänzen ließe und wir verschiedene Messenger vergleichen könnten.
Zertifikate hast Du erwähnt, allerdings verteilt sich hier das Vertrauen aktuell auf eine Vielzahl von Organisationen die aufgrund er Regeln des CA/Browser-Forums hoffentlich korrekt arbeiten. Prüfen könnte das jedoch keine Anwender. Aufgrund der entstehenden Kosten hat sich das entsprechende Verfahren bei Benutzerzertifikaten nicht durchsetzen können (S/MIME) und insbesondere lassen sich Zertifikate auch schlecht mit einer anonymem Nutzung kombinieren, da eine CA ja nichts sinnvolles prüfen könnte.
Daher denke ich nicht, dass Zertifikate eine sinnvoller Lösungsansatz für Messenger wäre.
ich denke nicht, dass es einen sinnvollen Lösungsansatz ohne Zertifikate gibt. Und ich halte auch nichts davon, dass jeder neue Verschlüsselungsoptionen erfindet die dann unerwünschte oder unverstandene Nebeneffekte haben.
Also hältst Du Zertifikate zur Authentifikation des Kommunikationspartners als die einzige, funktionierende Variante für eine Authentisierung des Gegenübers und würdest Dir wünschen, dass dieses in Mikes Messenger Matrix aufgenommen würde?
Meines Wissens nach mit dem Ergebnis, dass es keinen Messenger gibt, der ein solches Verfahren aktuell abbildet? Ich denke wenn ich hier nicht falsch informiert bin, dann könnte ich verstehen, warum Mike diesen konkreten Punkt nicht mit aufnimmt.
Ich bin kein Zertifikats-Experte, frage mich jedoch, was eigentlich eine CA zertifizieren sollte und wie dass dann mit jeweiligen Messenger zusammenhängen kann?
Vorname, Nachname, Geburtsdatum, Geburtsort was vermutlich noch nicht eindeutig wäre. Eine staatlich eindeutige Identitäts-Nummer als Ergänzung? Aber wer kennt solche Informationen von seinen Kommunikationspartnern um dieses dann zur Unterscheidung zu nutzen?
Mobiltelefonnummer oder E-Mail-Adresse? Aber wie kann die CA verifizieren, dass Hugo Boss die E-Mail-Adresse plattente-in-gruen@gmx.de oder die Mobilfunknummer +491234567890 hat?
Wenn dieses nicht durch eine Verifikation der Angaben gegenüber dem Abgleich der Datenbestände des jeweiligen Anbieter geschieht, wie verhindert man, dass sich jemand den technischen Zertifizierungsprozess bei (temprorären) Zugriff auf die Zertifizierte Adresse erneut durchführt? Und welches Zertifikat hat im Anschluss Gültigkeit und wie erkennt ein Messenger-Benutzer das sein oder das Zertifikat seines Gegenüber erneut ausgestellt wurde?
Ich sehe nicht, wie Personen-Zertifikate eine sinnvolle Lösung darstellen könnte. Vielleicht auch einfach deshalb weil es aus meiner Sicht keine erfolgreiche Massen-Implementation solcher Personenzertifikate abseits des Unternehmenseinsatzes gibt, die aus meiner Sicht für den Einsatz bei Kommunikationssystemen geeignet wären.
Ich gehe noch einmal auf diesen Aspekt ein.
Für mich macht es nicht wirklich einen Unterschied ob ich zentrale oder dezentrale Systeme habe. Wenn nicht gewährleistet ist, dass jeder Teilnehmer seinen eigenen Serversysteme ohne die Inanspruchnahme einer Dienstleistung eines Dritten betreibt, kann ich das Serversystem nicht gleichbedeutend mit dem Kommunikationspartner setzen.
Auch die Vertrauenswürdigkeit steigt nicht dadurch, dass ein Serverbetreiber weniger Nutzer hat. Ja ein solcher Serverbetreiber kann weniger Meta-Daten der Gesamtkommunikation der Welt einsehen und Massenüberwachungen werden damit unwahrscheinlicher. Ein vertrauenswürdiger Serverbetreiber der jedoch z. B. technisch das Entstehen von Meta-Daten vermeidet, die Kommunikation durch Verschlüsselung vor seinem Zugriff entzieht und meine Kommunikation nicht aktiv angreift, ist hier aus meiner Sicht nicht weniger vertrauenswürdig.
Eher habe ich als Kommunikationsteilnehmer bei dezentralen Systemen das Problem, dass ich den Serverbetreiber meines Kommunikationspartners nicht einschätzen kann, da mir dieser nicht bekannt ist.
Daher halte ich die Betrachtung, dass nur bei zentralen Diensten eine Ende-zu-Ende-Verschlüsselung notwendig ist für zu kurz gesprungen.
Kannst Du so auffassen. Genaugenommen geht es dabei nur mittelbar um Authentifizierung, sondern darum, dass der Mittelsmann/Anbieter die Schlüssel nicht manipulieren kann. Und Zertifikate sind der bewährte Weg um Identität, Schlüssel zeitbasiert zu assoziieren.
Ob eine CA dann vertrauenswürdig ist kann jeder selbst entscheiden - selbst signierte Zertifikate (auch CAs) wären möglich, und Vertrauen kann manuell oder über RFC 8162 hergestellt werden.
Wenn man schon mit Zertifikaten arbeitet, ergibt es m.E. keinen Sinn für die Authentifizierung gegenüber dem Anbieter etwas anderes zu verwenden.
Schade. Konstruktive Kritik will er nicht äußern.
Muss in einem Zertifikat ist die Identität (und ich würde Pseudonyme für wünschenswert halten), der öffentliche Schlüssel, und der Gültigkeitszeitraum. Alles andere ist optional und überwiegend auch nicht wünschenswert (außer vielleicht für die Kommunikation mit dem Staat, aber ob der das anbieten will wage ich zu bezweifeln).
Jeder kann seine eigene CA erstellen und reinpacken was ihm passt, der Kommunikationspartner muss vertrauen herstellen - das kann er heute schon bei manchen Messengern, nur dass die Prüfung meist nicht an der CA sondern an einer Gerätekonfiguration hängt.
Wenn Du Deine privaten Schlüssel aus der Hand gibst, kannst Du damit kompromittiert werden - das ist eigentlich überall so.
Halte ich schon für eine sinnvolle Lösung, aber die Anwender müssten lernen damit umzugehen. Hat sich bisher niemand auf die Fahne geschrieben. In Unternehmen funktioniert es nur weil es gemanagt wird (und Schlüssel hinterlegt werden), nicht weil die Anwender es gelernt haben.
Ich halte das für einen sehr relevanten Unterschied. Gründe u.a. Marktdominanz, Überwachungsmöglichkeiten, Rechtssystem, Vertrauen. Bei zentralen Systemen akzeptierst Du einfach was Du vorfindest.
wie soll das gehen?
Das hatte ich nicht so dargestellt. Ich hatte nur geschrieben, dass es bei zentralen Diensten zwingend ist. Und wenn Du - bin sogar der gleichen Meinung - die sichere Version für nicht vermittelbar hältst, dann solltest Du dezentrale Systeme propagieren. Wenn es dann immer noch keinen Anbieter gibt dem Du vertrauen willst, musst Du in den sauren Apfel beißen und entsprechende Kommunikation nicht verwenden oder die mögliche Überwachung akzeptieren.
Du schmeißt so viele Aspekte in die Diskussion, dass ich Dir nicht mehr wirklich folgen kann. Ich versuche das jetzt noch einmal aufzuschlüsseln wie ich das Thema Schlüssel und Zertifikate verstehe.
Symmetrische und Asymmetrische Schlüssel
Für eine kryptografisch gesicherte Kommunikation benötigt es Schlüsselmaterial. Dieses kann
a.) aus einem symmetrischen Schlüssel bestehen, bei dem sich beide Kommunikationspartner auf einen gemeinsamen Schlüssel zum Verschlüsselung und Entschlüsseln geeinigt haben müssen. Symmetrische Schlüssel skaliert nicht gut, da für jede neue Kommunikationsbeziehung ein neuer Schlüssel zwischen den Kommunikationspartnern abgestimmt werden muss, was einen sehr hohen Aufwand bedeutet.
b.) aus asymmetrischen Schlüsseln bestehen, bei denen jeder Kommunikationspartner hat einen privaten Schlüssel zum Entschlüsseln und einen öffentlichen Schlüssel zum Verschlüsseln durch den Kommunikationspartner hat. (Ergänzende kann auch eine Nachricht mit dem privaten Schlüssel signiert = unterschrieben und mit dem öffentlichen Schlüssel geprüft werden). Aysmetrische Schlüssel haben den Vorteil, dass jede Person prinzipiell nur ein Schlüsselpaar für beliebig viele Kommunikationspartner benötigt werden.
Bei unseren Diskussionen um Messenger geht es meines Wissens nach immer um asymmetrische Schlüsselpaare.
Schlüsselverteilung
Voraussetzung für eine Verschlüsselung ist, dass man den Schlüssel des Kommunikationspartners bereits hat, bevor man eine verschlüsselte Kommunikation eröffnen kann. Für die Verteilung von Schlüsseln gibt es unterschiedliche Methoden, z. B.
Persönlicher Austausch bei einem wirklichen Treffen
Bereitstellung zum Download auf dem eigenen Webserver
Einstellen in ein öffentliches Verzeichnis
Technische Bereitstellungen bei einem Verbindungsaufbau (z. B. TLS)
…
Hat man einen öffentlichen Schlüssel zu einem Kommunikationspartner, kann man Daten mit diesem verschlüsseln. Hat man den korrekten öffentlichen Schlüssel und hat ausschließlich der Kommunikationspartner seinen privaten Schlüssel im Zugriff, kann nur noch der Empfänger die Nachricht entschlüsseln und lesen. Ob der zweite Punkt gegeben ist, kann ich nicht prüfen sondern muss dem Kommunikationspartner vertrauen.
Schlüsselauthentifikation
Das Problem was mit der Verteilung des öffentlichen Schlüssels verbunden ist, ist die Frage wie man den öffentlichen Schlüssel eines Kommunikationspartners von einem anderen ähnlichen Schlüssel z. B. einem Angreifer unterscheiden kann und somit sicher ist, dass ich eine Nachricht nicht für den falschen Empfänger verschlüssel und diese anderen Person die Nachricht dann lesen kann.
Auch hier kann man verschiedene Verfahren nutzen, die einen unterschiedlichen Grad der Sicherheit der Schlüsselauthentifikation bieten. Beispielsweise:
Einfaches Nutzen der angebotenen Schlüssel ohne Authentifikation des Schlüssels. Dieses Verfahren legt eine Verschlüsselung über die Kommunikation ohne dass man sich sicher sein kann, dass die Nachricht nur durch den vorgesehenen Kommunikationspartner entschlüsselt werden kann. Wenn es jedoch keinen aktiven Angriff auf den Schlüsselaustausch gibt, sind die Inhalte trotzdem für jeden mit Zugriff auf die Daten z. B. solange diese auf einem Server gespeichert sind unlesbar. Bei einem aktiven Angriff auf die Kommunikation bei dem falsche öffentliche Schlüssel untergeschoben werden gibt es jedoch keinerlei Schutz um weiterhin vertraulich zu kommunizieren.
Trust on first use (TOFU) bei diesem Verfahren authenfiziert man explizit nicht den erstmalig geladenen öffentlichen Schlüssel des Kommunikationspartners, sondern nutzt diesen einfach ungesehen. Bei einem Wechsel des Schlüssel hingegen wird man von seiner Client-Software informiert und kann entscheiden, wie man weiter vorgeht um einen gewollten Schlüsselaustausch von einem Angriff mit untergeschobenen Schlüsseln zu unterscheiden.
Vergleich des Fingerprints des öffentlichen Schlüssels. Schlüssel haben eindeutige Quersummen = Fingerprints anhand derer man die Schlüssel identifizieren kann. Wenn man auf gesichertem Weg den Fingerprint des öffentlichen Schlüssels eines Kommunikationspartners erhält, dann lassen sich der richtige und falsche Schlüssel gut unterscheiden. Im Idealfall tauscht man den Fingerprint bei einem persönlichen Treffen aus, wenn man jedoch geringere Anforderungen an die Authentizität des Schlüssels hat, könnten auch andere Austauschvarianten genutzt werden (Übermittlung durch einen vertrauenswürdigen Freund, Herunterladen von der persönlichen Webseite, …).
Durch Zertifizierungsinstanzen geprüfte und signierte Schlüssel (Zertifikate). Da der persönliche Austausch des Fingerprints vieler Schlüssels recht aufwendig ist und insbesondere bei vielen Kommunikationspartnern schlecht skaliert, wurde das Konzept der vertrauenswürdigen Zertifizierungsinstanzen (Cerficate Authority, CA) entwickelt. Bei diesem werden die öffentlichen Schlüssel von Kommunikationspartnern durch spezialisierte Unternehmen authentifiziert und ein so geprüfter Schlüssel durch den privaten Schlüssel der Zertifizierungsinstanz signiert. Hierdurch bekommt man die Möglichkeit einen durch die Zertifizierungsinstanz authentifizierten Schlüssel ebenfalls direkt als authentifiziert anzusehen und zu verwenden.
Das Konzept der durch Zertifizierungsinstanzen authentifizierten und signierten Schlüssel (der Zertifikate) ist die Grundlage auf der heutzutage alle TLS-Verschlüsselten Kommunikationen eines Browsers mit Webseiten aber eben auch anderer Clients mit Servern basiert.
Was zertifiziert eine Zertifizierungsinstanz?
Eine Zertifizierungsinstanz zertifiziert mehr als den öffentlichen Schlüssel. Dieser muss auch ein durch die Zertifizierungsinstanz geprüftes, eindeutiges Merkmal haben, welches mit dem öffentlichen Schlüssel zwingend verbunden ist. Würde dieses fehlen, hätten wir nur einen öffentlichen Schlüssel, der durch eine Zertifizierungsinstanz signiert wäre, wüssten jedoch z. B. nicht wem dieser Schlüssel zugeordnet ist. Typischerweise wird im Zertifikat die eindeutige Adresse zu der dieser Schlüssel zugehörig ist hinterlegt. Zum Beispiel
E-Mail-Adresse für S/MIME Zertifikate
Server-URL für HTTPS-Zertifikate
Für die Authentisierung eines Messengers müsste also die Adresse des Messengers im Zertifikat hinterlegt sein. Sprich für jeden Messenger müsste sich eine Person jeweils ein neues Zertifikat von einer Zertifizierungsinstanz ausstellen lassen. Da Zertifizierungsinstanzen für jedes dieser Zertifikate bezahlt werden, haben sich meines Wissens nach Zertifikate für Personen außerhalb von geschlossenen Benutzergruppen, in denen zumeist eine eigene Zertifikzierungsinstanz betrieben wird, bisher nicht im großen Stil durchsetzen können. Selbst bei E-Mail (S/MIME) haben sich solche Zertifikate bisher nicht durchgesetzt und ein Punkt hierbei ist sicherlich auch die regelmäßigen Kosten für das Ausstellen neuer Zertifikate.
Sind Zertifikate von Zertifizierungsinstanzen eigentlich sicher?
Öffentliche Zertifizierungsinstanzen erhalten Ihr Vertrauen dadurch, dass Sie sich verpflichten die Regeln des CAB-Forums in dem soweit ich weiß Browser- und Betriebssystemhersteller sitzen, umzusetzen. Ergänzend müssen Sie regelmäßig im Rahmen von Audits durch Dritte geprüft werden, dass Sie dieses auch wirklich tun.
Solche Zertifizierungsinstanzen wird dann das Vertrauen der Browser- und Betriebssystemhersteller ausgesprochen und die öffentlichen Schlüssel der Zertifizierungsinstanzen werden einfach als vertrauenswürdig in die Systeme der Benutzer übernommen. Die wenigsten Benutzer verändern hier etwas, sondern vertrauen einfach Ihrem System. Ob die jeweilige Zertifizierungsinstanz nach der eigenen Definition vertrauenswürdig wäre, wird zumeist nicht hinterfragt.
Trotz der Regeln ist es schon mehrfach in der Vergangenheit vorgekommen, dass eine Zertifizierungsinstanz die Regeln in Einzelfällen nicht befolgt haben und unzulässig Zertifikate für Schlüssel herausgegeben haben. Auch können Mitarbeiter zur Ausstellung unberechtigter Zertifikate bewegt werden (Drohungen, Bestechung). Ebenso kann jede Zertifizierungsinstanz prinzipiell für jeden Identität Zertifikate erstellen und jeder Schlüssel kann durch beliebig viele Zertifizierungsinstanzen authentifiziert und durch eine Zertifikat ausgewiesen werden. In der Vertrauensbeziehung sind also nicht nur die eigene gewählte Zertifizierungsinstanz relevant sondern immer alle Zertifizierungsinstanzen die in den Betriebssystemen / Browsern aufgenommen wurden.
Wenn schwere Verstöße einer Zertifizierungsinstanz gegen die Regeln des CAB Forum bekannt werden, verliert die Zertifizierungsinstanz das Vertrauen und die Browser- und Betriebssystemhersteller entfernen die öffentlichen Schlüssel der Zertifizierungsinstanz aus Ihrer Software. Danach sind alle Zertifikate die von dieser Zertifizierungsinstanz ausgegeben wurden ungültig und haben keine Authentizität mehr.
Ein Zertifikat eines öffentlichen Schlüssels ist damit nicht mit einer 100% Authentifizierung des Kommunikationspartners gleich zu setzen, jedoch in Hinsicht auf die Skalierung von vielen Millionen Kommunikationspartnern (auch Webseiten) das aktuell beste Verfahren um ein gewisses Maß an Authentifizierung umsetzen zu können. Ich wollte es hier nur der Vollständigkeit erwähnen.
Machen Messenger-Anbieter nicht so etwas ähnliches wie Zertifizierungsinstanzen?
Zentralisierte Messenger-Anbieter führen zumeist Verzeichnisse von öffentlichen Schlüsseln Ihrer Benutzer und nehmen Schlüssel nach einem Authentifizierungsschritt gegenüber einer Mobilfunknummer oder E-Mail-Adresse auf. Dieses könnte man als eine Form der Authentifizierung des Kommunikationspartners ansehen.
Jedoch hast Du Recht, dass Messenger-Anbieter gleichzeitig auch die Kommunikationsinfrastruktur betreiben und daher sowohl die Möglichkeit des Unterschiebens eines falschen öffentlichen Schlüssels im Verzeichnis, wie auch die Umleitung der Kommunikation haben und damit in die Lage versetzt sein, für jede beliebige Kommunikationsbeziehung auf Ihrem Messengerdienst anzugreifen und mitzulesen.
Dieses setzt jedoch voraus, dass auch wirklich ein aktiver Angriff auf eine solche Kommunikation vorgenommen wird. Ein passives Mitlesen aller Kommunikationen ist durch die Ende-zu-Ende-Verschlüsselung trotzdem unterbunden.
Bei Angriffen die nicht vom Messenger-Anbieter selbst ausgehen, kann man jedoch die Rolle des Messenger-Anbieters durch die zumeist erfolgende Prüfung von Mobilfunknummer oder E-Mail-Adresse ein wenig mit der einer Zertifizierungsinstanz gleichsetzen (wenn dieses auch technisch vermutlich nicht über Zertifikate gelöst wird).
Mein persönliches Fazit:
Getrennte Zertifizierungsinstanzen und Kommunikationsanbieter sind eine gute Idee um die Möglichkeiten eines Man-in-the-Middle-Angriffs auf eine verschlüsselte Kommunikation stark zu erschweren. Hier stimme ich Dir zu.
Jedoch haben sich Personen-Zertifikate für Kommunikationspartner bei E-Mail, wo es mit S/MIME solche gibt, nicht in der Fläche insbesondere bei Privatnutzern durchgesetzt. Ein Grund können die Kosten sein die mit dem regelmäßigen Ausstellen der Zertifikate verbunden sind (meiner ist es bei S/MIME).
Zertifikate für Messenger zu fordern ist ein hehres Ziel jedoch in der Praxis vermutlich nicht zielführend (siehe vorhergehenden Punkt). Bevor es nicht ein Let’s Encrypt für die Ausstellung kostenloser Personen-Zertifikate analog zu Server-Zertifikaten gibt, wird aus meiner Sicht dieser Ansatz keine effektive Realisierungsmöglichkeit haben.
Verschiedene Messenger bieten heute schon die Möglichkeit an die übermittelten Schlüssel von Kommunikationspartnern manuell zu verifizieren. Man-in-the-Middle-Angriffe (des Messenger-Anbieters und anderer Personen) lassen sich also schon heute erkennen.
Insbesondere stellt jedoch der Einsatz der Ende-zu-Ende-Verschlüsselung bei Messengern, auch ohne diese saubere Authentisierung des öffentlichen Schlüssels, schon heute Maßnahmen gegen die Massenüberwachung aller nicht individuell angegriffener Kommunikationen dar. Nicht umsonst gibt es ja auch die Chat-Kontrolle-Bestrebungen.
Nun noch ein paar Antworten auf Fragen / Kommentare von @Joachim
Was hilft es in der Messenger Matrix zu rufen „Hey das ist alles nicht sicher“ (und auch keine andere Kommunikationsform die effektiv Euch zur Verfügung steht, weil Ihr Idioten kein Geld für Zertifikate ausgeben wollt und die Community keine entsprechende Lösung gebaut hat oder ein Finanzier Zertifikate für jedermann bezahlt)?
Das hat in einer Messenger-Matrix aus meiner Sicht nichts zu suchen, insbesondere weil kein Zertifikat nicht gleich unsicher ist - es gibt ja bei verschiedenen Messengern Alternativen den Kommunikationspartner sicher zu authentifizieren und Angriffe zu erkennen. Sie passen Dir nur nicht, weil Du der Meinung bist, dass niemand kann damit umgehen kann.
Du vertraust den Nutzern nicht mit einer Warnmeldung zu einem geänderten Schlüssel umzugehen, aber siehst es als sinnvoll an, dass diese unwissenden Nutzer eine beliebige CA in Ihren Keystore importieren, wo die CA dann beliebig auch andere Zertifikate für andere Personen ausstellen könnte denen das Gerät des Benutzers dann automatisch vertraut?
Wir haben in der Firma sogar der Bundesaufsicht für das Finanzwesen klar gemacht, dass sie sich mit Ihrer persönlichen CA die ein Zertifikat für einen internen Server ausgestellt hat sich vom Hof trollen sollen solange Sie nicht nach den Regel der CAB-Forums in die Betriebssysteme aufgenommen sind.
Bei dezentralen Systemen akzeptiere ich ebenfalls was ich vorfinde (wenn ich es nicht selber mache) und muss zusätzlich auch die Entscheidungen meiner Kommunikationspartner für Ihre Anbieter akzeptieren, die ich jedoch gar nicht einschätzen kann oder einfach die Prüfung der ganzen Anbieter ggf. nicht mehr schaffbar ist.
Ich verstehe was Du meinst, aber für mich ist Dezentralität kein Garant für Vertrauenswürdigkeit, sondern erschwert mir eine persönliche Einschätzung.
Zentralisierung hingegen erlaubt es mir mit einer Vertrauenseinschätzung meines Anbieters mit allen anderen Nutzer dieses Messengers unter derselben Vertrauenseinschätzung zu kommunizieren.
Signal z. B. nutzt ein Verfahren namens „sealed sender“, welches die Absender-Information in einer Nachricht nur durch den Empfänger verschlüsselt hinterlegt. Signal sieht also anhand der Nachrichten in meiner Queue nicht, wer diese geschickt hat.
Auch kann der Messenger-Anbieter die Inhalte seiner Protokolle minimieren, was nach Signals Aussage ergänzt, dass Sie zu einer eingereichten Nachrichten auch nicht den Absender protokollieren. Daher fallen bei Signal derzeit keine Daten an, die ein Ausmessen der Kommunikationsbeziehungen der Nutzer zulassen.
In verteilten Systemen ist dieses zwar prinzipiell auch möglich, nur entscheidet das eben jeder einzelne Betreiber für seinen Node. Das Problem potenziert sich daher einfach und mein Wissen darüber minimiert sich weiter. Bei dem von mir ausgewählten Anbieter habe ich immerhin noch Vertragsbedingungen / Nutzungsbedingungen die ich lesen und akzeptieren kann oder nicht.
Und ja, mir kann der Anbieter etwas vormachen - egal ob zentralisiert oder dezentral - hier hilft leider nur Vertrauen.
Fast alle Verschlüsselungsverfahren verwenden beides. Um mir Wiederholungen zu ersparen: https://blog.lindenberg.one/GrundwissenVerschlusselung. Da dabei der symmetrische Schlüssel zufällig oder durch Agreement entsteht, reicht es, sich auf den asymmetrischen zu konzentrieren - da sind wir uns einig.
ja, aber nur Standardisierung ist sinnvoll. Irgendein Verzeichnis oder URL skaliert nicht. Also z.B. RFC 8162.
Muss und kann jeder selbst entscheiden. Ich habe ausdrücklich zwei weitere Vertrauensankertechniken erwähnt, RFC 8162 und manuell (nicht ToFU sondern beliebiger Zeitpunkt).
Bei 10000 ft Höhe vielleicht. Darunter: Nein, denn weder kann ich aussuchen welchen Zertifikaten ich vertraue, noch ist eine geeignete Identität dem Schlüssel zugeordnet. Und Email und Telefonnummer sind ja oft genauso unsicher, sich darauf zu stützen ist kontraproduktiv, Mal abgesehen davon, dass mein Ansatz ohne Email und Telefonnnummer beliebige Pseudonyme erlauben würde und damit datenschutzfreundlicher ist.
Nur wenn Teilnehmer die Änderung der Devicekonfiguration zum Abbruch der Kommunikation bis zur erneuten Verifikation heranziehen - andernfalls ist ein MitM und damit Abhören und Ändern sehr wohl möglich.
Da ich selbstsignierte CAs erlauben würde fällt das Kostenargument weg. Die Hürde „mangelndes Know-How“ habe ich benannt.
skaliert halt überhaupt nicht, schon gar nicht wenn man 200 Kontakte hat und damit im Mittel täglich einer ein neues Telefon hat.
Ich glaube eher, dass die staatlichen Überwacher zu wenig von Verschlüsselung verstehen um die Angriffspunkte im Schlüsselmanagement zu verstehen.
Die Stiftung Warentest hat auch oft ein Kriterium „Datenschutzerklärung“ bei der die meisten Anbieter durchfallen. Auch bei der Messengermatrix könnte ja ein Anbieter die Kritik ernstnehmen.
Ich hab nirgends geschrieben, dass eine CA für einen Kommunikationspartner für andere Kommunikationspartner vertrauenswürdig sein soll und auch nicht, dass Vertrauen benutzer- oder profilübergreifend sein soll. Dass CAs heute für alles mögliche vertrauenswürdig sind belegt eigentlich die verbreitete Unkenntnis und die entsprechende Bequemlichkeit der Anbieter.
Zum Vergleich: SMTP-DANE braucht keine vertrauenswürdigen CAs sondern erlaubt der Domäne selbst zu definieren, welche Zertfikate (auch CAs) vertrauenswürdig sind.
Sehe ich anders. Ich vertraue weder Signal noch WhatsApp, benutze aber beides weil viele Kommunikationspartner dort sind.
kann Signal jederzeit ändern, müsste es auf eine Abhöranordnung auch, und wir wissen nicht ob tatsächlich die öffentlichen Quellen verwendet wird.
zentral hab ich keine Wahl, dezentral schon. M.E. wäre eine Dezentralisierung der Einstieg in Verbesserungen.
Ich habe mich jetzt einmal versucht durch Dein Grundwissen Verschlüsselung durchzuarbeiten, muss jedoch zugegen, dass ich Deinen Texten nicht folgen kann. Ich habe auch das verlinkte Paper „DNSSEC als Alternative zur klassischen CA“ gelesen, welches vermutlich das von Dir bevorzugte Verfahren für den Schlüsselaustausch und -authentifikation über signierte DNS-Einträge / -Zonen beschreibt.
Wenn ich dieses Paper richtig verstehe ist die Idee, Schlüssel anstatt über Zertifikate von Zertifizierungsinstanzen über eine Vertrauenskette von Zertifikaten der DNS-Zonen ausgehend von der Root-Zone über die nationalen Registries zu einem Domain-Eigentümer abzuleiten. Die DNS-Einträge selbst werden dann mit dem Zertifikat des Domain-Eigentümers signiert und können damit über DNS abgefragt und die Gültigkeit anhand der Vertrauenskette des DNS validiert werden.
Da man in DNS prinzipiell beliebige Text-Informationen speichern kann, können so über standarisierte DNS-Records beliebige Identitäten und Ihre öffentlichen Schlüssel authentifiziert verteilt werden. (Identitäten für E-Mail, Identitäten für Messenger, …)
Ist diese sehr einfache Darstellung des von Dir propagierten Konzeptes erst einmal prinzipiell richtig?
Basierend auf dieser Annahme hätte ich dann ein paar Fragen:
(1) Das Paper „DNSSEC als Alternative zur klassischen CA“ beschreibt „Vertrauenswürdige validierende DNS-Resolver sind nicht überall verfügbar“.
Ich vermute damit ist gemeint, dass wenn der DNS-Client keine Validieren der Vertrauenskette oder Prüfung der Zertifikatssignatur für die DNS-Einträge vornimmt, dass dann eben die Einträge unauthorisiert übernommen und genutzt werden.
Was ich jedoch nicht verstehe ist, welche DNS-Resolver hiermit gemeint sind? Geht es um
eine Komponente in der Client-Software?
eine Komponente eines Betriebssystems auf dem die Client-Software läuft?
eine Komponente des genutzten DNS-Anbieters der meine DNS-Anfragen beantwortet?
müssen gar alle beteiligten Komponenten zusammenspielen, damit eine Authentifikation der DNS-Inhalte korrekt funktioniert?
(2) Weiterhin beschreibt das Paper für SMIMEA-Records drei Ansätze mit denen die DNS-Einträge abgesichert werden können: „Aufbauend auf eine klassische CA“, „Aufbauend auf eine Self-Signed-CA“ und „der Nutzer kann ein beliebiges Zertifikat vorlegen“.
Ich interpretiere daraus zwei Dinge:
Wenn die Signatur-Prüfung basierend auf der DNS-Authentifikation sauber bis in die Anwendungsebene durchgezogen worden ist, dann braucht es keine Zertifizierungsinstanzen mehr. Die DNS-Signatur und die Vertrauenskette bis zur Root-Zone hat dann die Rolle vollständig übernommen.
Der Inhaber des Schlüssels zu einer DNS-Zone ist der einzige, der eine DNS-Signatur für Einträge erstellen und damit öffentliche Zertifikate / Schlüssel authentifizierter in die DNS-Zone einstellen kann. Wenn dieses der Fall ist, dann kann ich selbst die Kontrolle über die Gültigkeit meiner Zertifikate nur ausüben wenn ich auch der Eigentümer des Schlüssels für die DNS-Zone und damit der DNS-Domain bin.
Habe ich das Prinzip hinter dem Konzept soweit korrekt verstanden?
Oder stark vereinfacht: welche Zertifikate eine Organisation für sich selbst verwendet, hinterlegt sie im DNS und gesichert mit DNSSEC. DNSSEC verwendet selbst keine Zertifikate.
Das würde ich als überholt ansehen - validierende Resolvers sind üblich, begrenzt nur dadurch dass (gerade in D) nicht alle Domänen signiert sind, und dadurch dass man absichtlich Domänen mittels pi-hole o.ä. nicht haben will.
Das ist der Normalfall, bei allen DANE-Varianten aber verboten.
Alle Varianten existieren. Wie sind denn Deine Systeme konfiguriert?
Das kann man tun, will man aber nicht unbedingt, weil es den periodischen Schlüsseltausch erschwert. In vielen DANE-Szenarien gibt es mehrere Optionen.
Ich denke das primäre Problem für mich ist, dass Du sehr tief in den Details steckst und es anscheinend eine große Menge an notwendigem Wissen erfordert Dir zu folgen. Vielleicht ist auch einfach das Problem, dass so viele Komponenten und Konzepte ineinandergreifen und verstanden sein müssen, dass die Sache einfach sehr komplex ist und ich es nicht in Gänze folgen kann.
Ergänzend habe ich nicht Organisationen im Fokus, die eigenes IT-Personal und Servertechnik einsetzen können, sondern schaue aus dem Blick der technisch nicht versierten Privatperson. Für diese nicht versierten Anwender muss eine solche Messenger-Lösung und die notwendige Identitätsverwaltung einfach nutzbar sein und trotzdem ein gutes Sicherheitsnvieau bereitstellen können.
Denkst Du, dass Die von Dir vertretende Lösung der sicheren Identitätsverwaltung über DNS so einfach realisiert werden kann, dass z. B. ein Privatanwender ohne spezielle IT-Kenntnisse und mit sehr geringen zeitlichen Ressourcen so etwas sicher nutzen und verwalten kann?
Ein solches System darf aus meiner Sicht nicht viel komplizierter sein, als eine App / eine Anwendung auf dem Desktop-Computer zu installieren, ein Konto einzurichten und ggf. die Identität mit Ihren Schlüssel über das Scannen eines QR-Codes auf die eigenen Geräte zu importieren.
Gibt es da ggf. schon fertige Lösungen für die eigene Identitätsverwaltung über DNS im Rahmen einer App / einer Desktop Anwendung, die mit Kenntnissen eines nicht versierten Smartphone-Anwenders eine solche sichere Identitätsverwaltung erlauben?
Das kann auch erklären, warum sich so wenige Leute über die miserable Authentifizierung der Messenger aufregen.
Deswegen schrieb ich, kein kommerzieller Messenger wird dieses Niveau anstreben, weil er die Benutzer ausbilden müsste. Sieh Dich also als durchaus repräsentativ an.
Halt, ich hab RFC 8162 bei Organisationen erwähnt, und RFC 8162 setzt u.a. eine Domäne voraus. Dein „Privantanwender ohne“ wird die nicht haben und daher allenfalls selbst signieren.
Das ist denkbar, allerdings fehlen in Deiner Aufzählung die Anforderungen Backup und Verschlüsselung der Systeme. S.a. https://blog.lindenberg.one/DigitaleSelbstverteidigung - ohne Deine Schlüssel bist Du ein Nobody, wenn ein anderer sie bekommt wird er Du.
Nicht dass ich wüsste. Schon Backup funktioniert in meiner Umgebung nur, wenn ich das einrichte - das dauert wenige Minuten. Den Kurs „Grundwissen Verschlüsselung“ belegt niemand. Stimmt nicht ganz, meine Partnerin hat beim Schreiben mitgeholfen und im letzten Jahr hab ich den Kurs zweimal gehalten.
Danke für diesen Satz. Er stellt das Problem der Absicherungen der privaten Identitäten sehr einfach dar.
Hier beschreibst Du gut das Problem auf das Benutzer heute treffen. Wir haben viele tolle Einzellösungen und -Komponenten mit denen man mit viel Eifer und Kenntnis ziemlich perfekte Systeme bauen kann.
Nur geht dieses häufig an der Realität einer großen Menge der Bevölkerung vorbei, deren Talente woanders liegen und deren zeitlichen Freiräume ggf. so limitiert sind, dass man sich damit auch nicht in der Tiefe in die Thematik einarbeiten kann.
Was es braucht sind einfach benutzbare Systeme, die auch IT-technisch unbedarften Anwender dabei unterstützt ein gutes Sicherheitsniveau zu erreichen. Hier geht es vor allem um die Integration der verschiedenen Lösungen zu einem schlüsselfertigen System des Benutzers, sowie die Absicherung von Benutzeraktivitäten und Erweiterungen des Systems damit diese möglichst nicht die Absicherung des System gefährden können.
Hierzu habe ich noch zwei Verständnis-Fragen:
Wenn ich als Privatanwender ohne eigene Domain meine Identität / Schlüssel selbst signiere und diese auch nicht über eine DNS-Vertrauenskette einer eigenen Domain absichern kann, wie kann dann das Vertrauen in die Identität bei meinem Kommunikationspartner entstehen?
Wenn die Domain zu der ich meine selbstsignierte Identität erstellt habe (z. B. eine E-Mail-Adresse von Mailbox.org) dann noch strikte Vorgaben zur Absicherung der Domain umsetzt und ergänzend das System meines Kommunikationspartners diese auch verbindlich befolgt, dann dürfte doch eine Selbst-Signierte Identität überhaupt nicht akzeptiert werden?
Wie könnten dann in ein solches System der strikten DNS-basierenden Vertrauenskette und Identitätsverteilung überhaupt Identitäten ohne eigene Domain eingebunden werden?
Oder habe ich da jetzt einen ganzen Block der Konzeptes verpasst?
Aber warum gibt es auch 30+ Jahre nach Aufkommen des Internets kein gemeinsames Grundverständnis, was jeder in der Schule lernen sollte und auch Angebote das nachträglich zu lernen. Das Angebot der ehrenamtlichen Bürgermentoren in Karlsruhe enthält leider IT-Themen, aber nichts zu Sicherheit und Datenschutz. Das von DsiN enthält auch eher eine konfuse Mischung. Unser Staat will offensichtlich keine digital-mündigen Bürger, sonst würde er auch nicht den Unsinn wie im (nicht weiter verfolgen Referentenenwurf) den ich in https://blog.lindenberg.one/MythosEndeZuEndeVerschlusselung#RechtZukunft zerlege machen.
Einstein wird der Spruch zugeordnet, „mach es so einfach wie möglich, aber nicht einfacher“. Sicherheit ist nicht einfach, oder nur dann wenn ich jemand vertrauenswürdigen habe, der sich darum kümmert - den gibt es für freie Bürger nur wenn sie sich selbst schlau machen oder selbst bezahlen.
Durch einmaliges „hab ich geprüft“ wie bei aktuellen Messengern (oder anderen ToFUs) auch, nur dass ich ja personenbezogene statt gerätebezogene Zertifikate vorsehe. Sprich der Wechsel der Geräte interessiert nicht mehr, Änderungen sind damit relevant. Ich muss daran erinnern, das Signal bei einer Schlüsseländerung ausdrücklich darauf hinweist, der Kommunikationspartner könne ein neues Telefon haben, die Möglichkeit MitM aber verschweigt.
Öffentliche Anbieter könnten Dein selbstsigniertes Zertifikat veröffentlichen, aber zwingend ist das nicht. Noch nicht einmal, dass die Zertifikate Emailadressen als Identität verwenden (die sind bei X.509 ja nur „alternate Name“), das würde allerdings das Verständnis erleichtern und Kollisionen vermeiden helfen.
Im Zweifelsfall würde ich einem manuell vertrauten Zertifikat Vorrang einräumen vor einem über DANE ermittelten. Und wenn dieser Konflikt wirklich eintritt, dann würde ich das als Luxus-Problem sehen, denn dann hätte der Ansatz Relevanz und Akzeptanz erreicht.
O.k. ich versuche jetzt einmal aus meiner Sicht das von Dir erklärte mit Fokus auf den Normal-Benutzer zusammen zu fassen:
Es gibt mit DNS eine Technologie über die sich kryptografisch abgesichert digitale Identitäten einfach verteilen lassen. Die Kontrolle über die Identitäten ist hierbei auf den Administrator der Domain beschränkt und kann daher nicht von Kommunikationsanbietern (E-Mail-, Messenger-Provider, …), die auf solchen Identitäten aufsetzen würden, manipuliert werden.
Für Organisationen mit eigener Domain und IT-Personal, oder technisch versierten Einzelpersonen lässt sich ein solches DNS-gestütztes Identitäts-Verfahren realisieren. Für wenig technisch versierte Personen gibt es derzeit jedoch keine einfach benutzbare Anwendungs-Lösung um ihre eigenen Identitäten auf diesem Weg zu verteilen und zu kontrollieren.
Für solche Anwender würdest Du selbstsignierte Zertifikate als mögliche Lösung ansehen, bei denen die Vertrauensbeziehung durch eine einmalige, manuellen Prüfung der Kommunikationspartner hergestellt wird (z. B. durch Fingerprint-Vergleich).
Aktuell gibt es jedoch anscheinend keinen Messenger der auf solchen Zertifikats-basierenden und pber DNS-verteilten Identitäten aufsetzt. Bei dem Kommunikations-Kanal E-Mail ist dieses schon heute möglich, aber nicht verbreitet.
Am Ende komme ich zu dem Punkt, dass Du aus der konzeptionellen Sichtweise heraus argumentierst „wie es am Besten sein sollte“ (die man vor allem mit Entwickler von Messenger-Lösungen diskutieren sollte).
Ich hingegen schaue aus der praktischen Sichtweise der Benutzer von Messengern, die keine eigenen Lösungen entwickeln oder betreiben. Hier wären Deine Wünsche nach
einer geräteunabhängigen, digitalen Identität
die sich bei einem Wechsel des Endgerätes durch Einspielung des Identitäts-Backups nicht ändert
sich durch die Anwender im direkten Austausch verifizieren lässt
und bei der ein Man-in-the-Middle-Angriff sich nicht in eine bestehenden Kommunikationen einschleusen kann
am Ehesten durch Threema erfüllt. Hier könnte mit wenig Ausbildung des Benutzers
Wie mache ich ein sicheres Backup meiner Identität und wie spiele ich diese auf einem neuen Geräte wieder ein?
Wie verifiziere ich die Identität meiner Kommunikationspartner und was bedeuten die drei Vertrauensstufen rot, gelb, grün?
Was mache ich, wenn eine neue, bisher nicht verifizierte Identität in mich kontaktiert?
eine vertrauenswürdige Kommunikation realisieren.
Aus meiner Sicht würde ich unsere spezielle Diskussion hier gerne abschließen, da ich vermute aufgrund des unterschiedlichen Fokus zwischen „wie es am Besten sein sollte“ und „was effektiv für nicht IT-affine Anwender verfügbar ist“ werden wir aktuell nicht zu einer gemeinsamen Position kommen.
Es hat aber Spaß gemacht zu diskutieren und ich habe hoffentlich eine Menge aus Deinen Ausführungen gelernt.
an, die besagt, dass es immer dann, wenn kein eigener Server betrieben wird, eine Frage des Vertrauens in den/die Betreiber ist, ob unseren Wünschen bspw. nach der (wegrollenden) Datenlöschung nachgekommen wird. Wenn die Keys nicht in den eigenen Händen liegen, dürfte dies einige Unsicherheiten auch gegenüber Signal und Threema weiterhin bestehen lassen.