Ursprünglich veröffentlicht: https://www.kuketz-blog.de/server-in-der-eu-und-eigene-schluessel-schuetzt-das-vor-us-zugriffen/
1. Versprechen von EU-Serverstandorten – helfen sie wirklich? Immer wieder werben große US-Cloudanbieter wie Microsoft damit, Daten ausschließlich in Rechenzentren innerhalb der EU zu speichern. Auch technische Lösungen wie »Bring Your Own Key«, doppelte Verschlüsselung oder getrennte Schlüsselverwaltung werden als Schutzmechanismen gegen ungewollten Zugriff verkauft. Doch wie wirksam sind diese Maßnahmen tatsächlich – insbesondere gegenüber der Reichweite US-amerikanischer Gesetze und Behörden? Die unbequeme Wahrheit: Weder der Standort der Server noch der Einsatz eigener Schlüssel bieten echten Schutz vor Zugriffen durch US-Behörden oder Geheimdienste. 2. Drei zentrale Risiken bei US-Cloudanbietern Selbst wenn Daten physisch in Europa gespeichert werden, bestehen bei der…
das Problem sind m.W. nicht nur US-Anbieter sondern auch EU-Anbieter die Töchter oder Niederlassungen in den USA haben und damit auch Opfer von Patriot- und Cloud-Act sein können. Also z.B. auch Ionos, OVH, Lidl Schwarz, und viele andere.
würde mich im konkreten fall für netcup.de interessieren. netcup gehört zu anexia. diese haben einen standort in den usa - https://anexia.com/en/company/about-anexia/locations.
netcup ist dein server-hosting-anbieter
sollte man den nicht wechseln?
ja, einer von dreien.
kennst Du gute Alternativen?
Tatsächlich können meine Hoster nur den Inhalt meiner öffentlichen Webseiten und ein paar Logs/Kommunikationsmetadaten mitlesen, alles wichtige wird verschlüsselt an Systeme bei mir durchgereicht. Wahrscheinlich bin ich digital deutlich souveräner als die meisten anderen Organisationen. Die Abhängigkeiten beim DNS und bei Letsencrypt machen mir mehr Sorgen als Ionos oder Netcup.
Wenn eigene Schlüssel nichts bringen, wie kann der Signal dann noch sicher sein?
Der gehts auch - komplett - auf US-Clouddienste.
Da gibts Widerspruch.
Ich halte Signal nicht für sicherer als WhatsApp (siehe ausführlich https://blog.lindenberg.one/MythosEndeZuEndeVerschlusselung). Sicher geht nur mit Schlüsseln die nur ich selbst kontrolliere.
von wem gegen was?
Ich beobachte einen weit verbreiteten Enthusiasmus für E2E ohne dass das jeweilige Schlüsselmanagement das rechtfertigt. Ich speichere Daten unter meiner Kontrolle daher nur ausnahmsweise wo anders als zuhause (die Liste ist etwas länger als die drei Hoster aber noch unter zehn und enthält keine von mir als sensibel eingeschätzte Daten) oder als Backup bei Freunden und immer verschlüsselt mit von mir kontrollierten Schlüssen.
Als Nutzer fremder Dienste habe ich leider keinen Einfluss darauf wo und wie gespeichert wird. BYOK wie bei der Deutschen Bahn halte ich für ein Placebo.
Danke.
Widerspruch meinte ich - wenn Mike sagt, das klappt nicht sich mit eigenem Schlüssel Schutz zu holen. Er empfiehlt gleichzeitig Signal.
Das heisst doch, Signal wär auch nicht sicher, weils auf die US-Infrastruktur läuft.
Dann müsste Mike die Empfehlung canceln.
Vielleicht pro Signal:
Es ist open-source und man kann prüfen, ob die Mist bauen mit Schlüsseln und generell.
Ich les mir Dein Beitrag im Blog Durch!
Editierung
@Joachim Zum Blogbeitrag von dir:
dass dieses Ausleiten bei den populärsten E2E-Messengern sowieso technisch möglich ist und allenfalls die Warnung „Dein Partner hat ein neues Telefon“ auslöst enttäuscht mich auch
Hast Du das zuletztlich getestet?
Ich glaub, es ist ein großes Problem, wenn Du beim Signal das Telefon wechselst.
Du musst mindestens die SMS empfangen können.
Neue Geräte werden nur mit Zusatzverifizierung eingebunden, wenn ichs recht entsinne.
„Unterjubeln“ is nicht.
Mag sein, das Gegenüber sieht es nicht und bekommt nur die Meldung „Dein Partner hat ein neues Telefon“. Intern mein ich, wirds gut gelöst.
Im März/April 2024. Habe aber auch nirgends etwas gelesen dass es seitdem geändert wurde.
Das Telefonsystem (SS7) und damit SMS ist als unsicher bekannt. Für Strafverfolgungsbehörden oder staatliche Überwacher je nach Rechtsraum auch kein Problem, die SMS oder eine Email mitzulesen und damit ein anderes Telefon bei Signal zu registrieren.
Naja, in meinen Augen ist schon die Spezifikation nicht richtig, da nützt dann Code Quality oder Audits nichts, die bescheinigen nur, dass die falsche Spezifikation korrekt umgesetzt wurde.
Ich denke man muss unterschieden ob ein Anwendungsfall einen Software as a Service Ansatz mit der Verarbeitung von Daten mit in der Cloud laufenden Prozessen nutzt (z. B. Microsoft 365) oder ob es sich ausschließlich um die Ablage verschlüsselter Daten in der Cloud handelt (z. B. Signal).
Eine Cloud-Anwendungslösung wie Microsoft 365 kann kaum sinnvolle Funktionen mit sicher verschlüsselten Daten abseits der Datenablage durchführen. (“Technisch möglich, praktisch kaum nutzbar”), sodass eine solche Lösung eigentlich keinen Sinn macht. Der Anwender müsste je nach Datenkritikalität stark unterschiedliche Arbeitsweisen nutzen. Häufig werden dann Daten nicht mit den zur Datenkritikalität notwendigen Schutzmaßnahmen verarbeitet, da ansonsten ja die tollen, gewohnten Funktionen nicht zur Verfügung stehen.
Bei Signal hingegen ist die Datenverabeitung abseits des korrekten Zustellens der verschlüsselten Nachrichten komplett in den lokal installierten Client verlegt, sodass die Verschlüsselung der Nachrichten konsequent und immer implentiert wird. Hier gibt es einfach keine Unterscheidung der Datenkritalitäten und der damit verbundenen Funktionsabläufe mit denen der Benutzer umgehen muss.
Ergänzend konnte Signal auch das Anfallen des Großteils der Meta-Daten in seiner Implementation vermeiden. Signal weiß nur welche Nachricht es an welchen Benutzer ausliefern soll und wann sich ein Benutzer mit seiner Mobilfunknummer angemeldet und zuletzt eingewählt hat. Alle weiteren Informationen - wer mit wem über was kommuniziert - benötigt Signal nicht und hat konsequenterweise diese Informationen im Rahmen des Protokolls auch nicht dem Cloud-Service zugänglich gemacht.
Solange es also kein Gesetz gibt, dass die Implementation der Sammlung bestimmter Daten durch einen Dienst erzwingt, kann Signal so implementiert bleiben, dass keine relevanten Daten außerhalb der Verschlüsselung anfallen. Das Risiko, dass ein Dienst mit einem Schlag unzugänglich gemacht wird verbleibt natürlich in beiden Fällen.
Der Vergleich hinkt, weil Signal und typische Cloud-Dienste grundsätzlich verschiedene Dinge tun:
Signal speichert keine Inhalte in der Cloud. Nachrichten, Dateien etc. bleiben auf den Geräten der Nutzer und sind Ende-zu-Ende-verschlüsselt. Selbst wenn Signal US-basiert ist: Es gibt schlicht nichts, was der Anbieter entschlüsseln könnte.
Cloud-Dienste hingegen speichern aktiv Daten zentral – oft auch unverschlüsselt oder mit Schlüsseln, auf die der Anbieter Zugriff hat. Selbst bei Verschlüsselung sind Metadaten oder Administrationszugriffe oft nicht geschützt.
Kurz: Signal hat kein Datenzugriffsproblem, weil es nichts hat, worauf zugegriffen werden kann. Cloudanbieter speichern und verwalten Daten zentral – das ist der entscheidende Unterschied.
Die Antwort hinkt aber auch, denn Signal hat zwar nichts gespeichert, kann aber trotzdem Schlüssel manipulieren und damit inder Zukunft Daten ausleiten.
Signal könnte durch ein böswilliges Update oder gezielte Sabotage den Schlüssel austauschen – aber das wäre erkennbar, widerspricht dem Open-Source-Prinzip und ist durch die Architektur (Double Ratchet, Kontaktverifizierung) stark erschwert. Die Behauptung ist also theoretisch nicht falsch, aber in der Praxis kaum realistisch und leicht zu erkennen.
Wir schweifen aber vom Thema ab, denke ich.
Relevante Ergänzung: nicht nur Signal könnte das, im Prinzip könnte das auch bei Thunderbird, Firefox, diversen Passwortmanagern und vielen weiteren Programmen passieren. Diesen merkwürdigen Fokus auf Signal finde ich diskurstechnisch etwas unredlich, da Signal nun wirklich einen guten track record in puncto Sicherheitskultur hat.
Signal war eben nur als von Mike in Messenger-Umfeld empfohlenes aber eben auch U.S. amerikanisches Beispiel thematisiert worden und Mike hat den Unterschied Clouddienst zu Signal ja auch erklärt.
Joachim wiederum weißt einfach auf den Fakt hin, dass ohne die zumeist nicht erfolgende, eigenverantwortliche Prüfung der Identität eines Signal-Client-Eigentümer durch die Anwender, ein Anbieter wie in diesem Beispiel Signal die Zuordnung Telefonnummer zu Signal manipulieren kann. Technisch durch Anwender identifizierbar aber in den allermeisten Fällen eben ignoriert und definitiv kein Signal- oder Messenger-spezifisches Problem.
m.E. irrst Du massiv. Die Schlüsseländerung kann auf dem Signal-Server ohne Änderung des Client-Codes durchgeführt werden. Der Client sieht dann halt den Verification-Failure und zeigt - so meine Tests - „der Partner hat wahrscheinlich ein neues Telefon“. Niemand außer Signal weiß, ob der Server mit dem Quellcode übereinstimmt. Und es wäre m.E. völlig legal wenn Signal eine Schnittstelle beispielsweise nach TKÜV eingerichtet hätte, sie sind sogar verpflichtet dazu, jedenfalls dann, wenn die entsprechend autorisierten staatlichen Einrichtungen verstanden haben, dass das möglich ist.
Genau deswegen sollte man, wenn das eigene Threat Model nicht komplett larifari ist, bei geänderter Sicherheitsnummer out of band nachfragen, was da los ist.
immerhin sagst Du damit ist ernstzunehmen - im Unterschied zu Mike.
Was nimmst Du als „out of band“? reales Treffen, anderen Messenger, oder was?
Ein Hinweis zu geänderter Sicherheitsnummer ist immer ernstzunehmen, dafür ist er da. Allerdings hat das nicht unbedingt mit Trump zu tun - es kann auch das Handy geklaut worden sein und jemand versucht mit der SIM, Signal neu zu registrieren, es kann die SIM geklont worden sein, aber es kann natürlich auch einfach ganz banal das Handy in den Teich gefallen sein. Darum ist Abklärung dringend nötig.
Welcher Kanal dazu verwendet wird ist relativ egal, Hauptsache nicht via Signal, da Signal ja kompromittiert sein könnte.