Nicht Signal wurde gehackt.

Die Zeremonie wurde ausgetrickst.

ToC

TL;DR

Signal wurde nach der derzeit bekannten Quellenlage nicht kryptographisch kompromittiert. Die Ende-zu-Ende-Verschlüsselung, Infrastruktur und Codeintegrität sind nicht der erkennbare Schwachpunkt dieser Angriffsklasse.

Der Angriff zielt auf die Account-Continuity-Ceremony:

  • Support-Imitation,
  • Registrierungscode,
  • Signal PIN,
  • De-Registration,
  • Re-Registration,
  • Telefonnummernwechsel,
  • Linked Devices
  • Account-Migration.
Abbildung 1: Account-Continuity Attack

Die eigentliche Schwäche entsteht dort, wo ein Nutzer eine kritische Identitätsoperation autorisiert, ohne deren technische Bedeutung vollständig zu verstehen.

Mein an Signal gesendetes Security-Design-Proposal schlägt deshalb keine Schwächung von Privacy vor, sondern lokale, datensparsame Härtung: keine GPS-Daten, keine IMEI, keine IMSI, keine Inhaltsanalyse, keine zentrale Profilnamenüberwachung.

Die wichtigsten Massnahmen sind:

  • harte lokale Warnungen bei „Signal Support“-Imitation,
  • sichtbare Account-Kontinuität,
  • De-Registration als Sicherheitsalarm,
  • Wartefristen bei Telefonnummernwechseln,
  • ein optionaler Enhanced Account Protection Mode.

Für Hochrisikonutzer sollte Signal langfristig einen Account Continuity Key prüfen: einen kryptographischen Besitznachweis für kritische Account-Aktionen, damit abgephishte Codes oder PINs allein nicht mehr ausreichen.

Ein Messenger muss nicht brechen, damit seine Nutzer die Kontrolle verlieren

Ein sicherer Messenger kann kryptographisch intakt sein und trotzdem in einer realen Angriffslage versagen. Nicht, weil sein Protokoll gebrochen wurde. Nicht, weil die Ende-zu-Ende-Verschlüsselung plötzlich nur noch Dekoration wäre. Sondern weil die Stelle, an der ein Mensch eine kritische Identitätsoperation autorisiert, unzureichend gegen Täuschung, Zeitdruck und semantische Verwirrung gehärtet ist.

Genau dort liegt der blinde Fleck der aktuellen Signal-Debatte. Die Formel „Signal wurde gehackt“ ist falsch, sofern man damit einen Bruch von Verschlüsselung, Infrastruktur oder App-Code meint. Sie ist methodisch schlampig, technisch irreführend und politisch bequem. Aber die Gegenformel „Signal wurde nicht gehackt“ reicht ebenfalls nicht. Sie ist korrekt, doch sie lässt den gefährlichsten Teil der Sache zu schnell im Diffusen verschwinden: Nutzer verlieren nicht nur dann die Kontrolle, wenn Kryptographie bricht. Sie verlieren sie auch dann, wenn sie eine Account-Migration, eine De-Registration oder eine Re-Registration falsch deuten und dem Angreifer damit die Vordertür öffnen.

Der Anlass ist ernst genug. Reuters berichtete über Ermittlungen der deutschen Bundesanwaltschaft wegen Phishing-Angriffen über Messenger-Dienste, nachdem BfV und BSI vor einer Kampagne gegen hochrangige Politiker, Diplomaten, Militärangehörige und Journalisten gewarnt hatten. Der Bericht nennt Signal als Schwerpunkt, verweist aber zugleich darauf, dass nach Einschätzung der Sicherheitsbehörden weder Malware noch technische Schwachstellen im Messenger ausgenutzt wurden, sondern legitime Funktionen in Verbindung mit Social Engineering. Reuters berichtete ferner, dass Spiegel nach eigenen Recherchen von einem kompromittierten Signal-Account der Bundestagspräsidentin Julia Klöckner und einem erfolglosen Angriff auf Friedrich Merz sprach.1

Signal selbst hat später öffentlich klargestellt, worauf es bei dieser Unterscheidung ankommt: Signal sei nicht „gehackt“ worden; Verschlüsselung, Infrastruktur und Codeintegrität seien nicht kompromittiert. Zugleich beschrieb Signal eine Phishing-Kampagne, in der Angreifer als „Signal Support“ auftraten, Credentials erlangten, Accounts übernahmen, Telefonnummern änderten, Opfer auf eine De-Registration vorbereiteten und kompromittierte Accounts anschliessend gegen deren Kontaktumfeld einsetzten.2

Aus dieser Diagnose habe ich am 28. April 2026 ein digital signiertes Security-Design-Proposal an Signal Messenger, LLC abgeleitet. Die öffentliche Fassung dieses Beitrags entwickelt denselben Gedanken weiter: Nicht die Verschlüsselung steht im Zentrum, sondern die Härtung kritischer Identitätsübergänge. Der Betreff lautete: „Proposal Following the Recent Account Takeover Campaign Targeting German Parliamentary Figures“. Es war ausdrücklich kein Vulnerability Report im engen Sinn. Es behauptete keine Kompromittierung von Signals Kryptographie, Infrastruktur oder Codeintegrität. Es war ein Vorschlag zur Härtung derjenigen Schicht, in der ein Konto seinen Status, seine Nummer, sein Gerät, seine Verknüpfungen und seine Identität wechselt.3

Diese Schicht nenne ich Account-Continuity-Ceremony.

Der Angriff zielt auf Identitätsverwirrung, nicht auf Kryptographie

Die nüchterne Beobachtung lautet: In der bisher öffentlich beschriebenen Angriffsklasse wird Signal nicht kryptographisch gebrochen. Der Angreifer versucht vielmehr, den Nutzer durch Support-Imitation, Dringlichkeitsnarrative und falsche Erklärungen dazu zu bringen, genau jene Informationen preiszugeben oder genau jene Handlung auszuführen, die Signal unter normalen Umständen als legitime Account-Operation akzeptiert.

BleepingComputer fasste die Warnungen von BfV und BSI im Februar so zusammen: Die Angriffe kombinierten Social Engineering mit legitimen App-Funktionen; es werde weder Malware eingesetzt noch würden technische Schwachstellen in den Messaging-Diensten ausgenutzt. Angreifer gäben sich als Support-Team oder Support-Chatbot aus, zielten auf Einzel- und Gruppenchats sowie Kontaktlisten und nutzten Varianten, bei denen entweder der Account übernommen oder über QR-Code ein fremdes Gerät gekoppelt werde. Besonders hässlich ist daran nicht die technische Eleganz, sondern deren Abwesenheit. Es reicht, Menschen im richtigen Moment das falsche Sicherheitsritual aufführen zu lassen.4

Netzpolitik.org beschrieb bereits im Januar, wie eine gefälschte Support-Anfrage Opfer zur Eingabe beziehungsweise Weitergabe eines echten Signal-Verifizierungscodes bewegen sollte. Nach Annahme der Chat-Anfrage erhielten Betroffene eine echte SMS von Signal; dies deutete darauf hin, dass Angreifer unmittelbar versuchten, die betreffende Telefonnummer neu zu registrieren. Werde zusätzlich die Signal-PIN weitergegeben, könnten Profil und Kontakte wiederhergestellt und der rechtmässige Nutzer ausgesperrt werden.5

Signal selbst schreibt in seinen Supportseiten unmissverständlich, dass Signal Support Nutzer nicht direkt per In-App-Nachricht, Anruf, SMS oder Social Media kontaktiert und dass offizielle Kommunikation per E-Mail über offizielle @signal.org-Adressen erfolgt. Wer innerhalb Signal behauptet, Chatbot, Security, Support-Team oder Vertreter von Signal zu sein, wird von Signal als Betrugs- und Phishing-Versuch eingeordnet.6 Das ist als Regel klar. Die entscheidende Frage lautet: Weshalb bleibt diese Regel eine Supportseiten-Wahrheit, statt im Angriffsmoment als clientseitige Sperre sichtbar zu werden?

Die Antwort ist unbequem, aber produktiv: Viele Sicherheitsprodukte behandeln die Kryptographie als Hochsicherheitszone und die Account-Zeremonie als UI. Das ist zu flach. Eine Benutzeroberfläche, die über Registrierung, Telefonnummernwechsel, De-Registration, Linked Devices und Recovery entscheidet, ist nicht bloss Oberfläche. Sie ist Teil des Sicherheitsprotokolls, nur eben mit Menschen als fehleranfälliger Zustandsmaschine.

Account-Continuity-Ceremony

Der Begriff Account-Continuity-Ceremony bezeichnet den für Nutzer sichtbaren Ablauf, durch den ein Messenger-Konto seine Kontinuität behauptet, verliert, überträgt oder neu erzeugt. Dazu gehören Registrierungscode, Signal PIN, Registration Lock, De-Registration, Re-Registration, Telefonnummernwechsel, Linked Devices, Sicherheitsnummern, Gerätewechsel, Recovery-Mechanismen und jede UI, die dem Nutzer erklärt, was gerade mit seiner Identität geschieht.

Diese Zeremonie ist keine Nebensache. Sie ist der Übergang zwischen mathematischer Sicherheit und menschlicher Handlung. Signal kann Nachrichten zuverlässig verschlüsseln; dennoch kann ein Nutzer einem Angreifer ermöglichen, die eigene Nummer auf einem anderen Gerät zu registrieren, ein fremdes Linked Device zu autorisieren oder nach einer De-Registration fälschlich zu glauben, er kehre in seinen alten Account zurück. Der Angriff läuft dann nicht durch die Hintertür der Kryptographie. Er läuft durch die Vordertür der autorisierten Fehlhandlung.

In meinem Proposal habe ich das Threat Model so gefasst: Ein Angreifer imitiert Signal Support, Signal Security, Account Recovery, Verification oder ähnliche vertrauenswürdige Labels. Das Opfer wird zur Herausgabe eines Registrierungscodes, der Signal PIN oder anderer accountrelevanter Credentials bewegt. Der Angreifer registriert, migriert oder verändert den Account-Zustand, häufig inklusive Telefonnummernwechsel. Das Opfer erlebt De-Registration und wird darauf vorbereitet, dies als erwartetes Verhalten zu deuten. Danach registriert sich das Opfer erneut und glaubt, in den ursprünglichen Account zurückzukehren, während tatsächlich eine neue Signal-Identität entstehen kann oder die alte Identität unter Kontrolle des Angreifers verbleibt. Der kompromittierte Account wird danach gegen die Kontaktliste des Opfers verwendet.7

Das ist kein abstraktes Problem. Es trifft gerade jene Personengruppen, für die Signal nicht Bequemlichkeitssoftware ist, sondern Kommunikationsinfrastruktur: Journalisten, Anwälte, politische Personen, Diplomaten, Aktivisten, Beamte, Führungskräfte und sicherheitssensible Organisationen. Für diese Gruppen ist ein Account nicht nur ein Chat-Konto. Er ist ein Vertrauensanker. Wird dieser Anker übernommen, wird Vertrauen selbst zur Angriffsfläche.

Die Schwäche liegt an der Schnittstelle

Die Schwäche entsteht an der Schnittstelle zwischen Nutzerpsychologie, UI, Recovery-Logik und Account-Status. Der Nutzer sieht eine Nachricht, die nach Support klingt. Er erhält einen echten Code. Die App verhält sich erwartbar. Der Angreifer liefert die Interpretation dazu: Das sei eine Sicherheitsprüfung, eine Wiederherstellung, eine normale De-Registration, ein erforderlicher Login. Genau diese Deutung ist der eigentliche Exploit.

Starke Kryptographie schützt Nachrichten gegen fremde Leser. Sie schützt nicht automatisch den Sinn einer Handlung. Ein sechsstelliger Code ist technisch eindeutig, semantisch aber abhängig vom Kontext. Ein Nutzer muss wissen, ob der Code eine neue Registrierung erlaubt, ob seine PIN eine Wiederherstellung freischaltet, ob eine neue Anmeldung den alten Account zurückbringt oder nur eine neue Identität erzeugt. Ohne diese Klarheit wird der Nutzer zum unfreiwilligen Signaturgerät des Angreifers.

Signal weist in seinen Supportseiten darauf hin, dass die Signal PIN kein Chat-Backup ist, nicht mit dem SMS-Verifizierungscode identisch ist und auch kein Screen Lock. Registration Lock kann mit der PIN verbunden sein und nach sieben Tagen Inaktivität auslaufen, wenn die Nummer auf einem anderen Gerät registriert wurde.8 Diese Unterscheidungen sind korrekt. Sie sind aber zu komplex, um in einem Angriffsmoment aus der Erinnerung heraus sauber angewandt zu werden. Genau deshalb muss die App meiner Auffassung nach im konkreten Risiko-Moment sprechen, nicht irgendwo in einer FAQ.

Die gleiche Logik gilt für Linked Devices. Signal erlaubt das Koppeln von Signal Desktop oder Signal iPad mit dem Telefon; beim ersten Setup können Chats und Medien der letzten 45 Tage synchronisiert werden, nach der Kopplung muss das Telefon nicht online sein, das Gerät wird nach 30 Tagen Inaktivität entkoppelt, und pro Telefon sind bis zu fünf gekoppelte Geräte erlaubt.9 Das ist funktional sinnvoll. Für einen Angreifer aber ist jeder QR-Code, der ein neues Gerät koppelt, ein potenzielles Täuschungsinstrument. Nicht weil Linked Devices schlecht wären, sondern weil eine legitime Funktion zur falschen Zeremonie werden kann.

Wer kritische Kommunikation ermöglicht, muss die Zeremonie härten

Wer einen sicherheitskritischen Messenger betreibt, kann sich nicht damit begnügen, Recht zu haben, wenn jemand „Hack“ ruft. Ja, Signal darf und muss klarstellen, dass seine Kryptographie nicht gebrochen wurde. Diese Klarstellung schützt das technische Vertrauen. Aber sie beantwortet nicht die Produktfrage: Wie verhindert man, dass ein Angreifer einen Nutzer durch eine legitime Account-Zeremonie führt, die der Nutzer missversteht?

Mein Werturteil lautet daher begründet: Kritische Identitätsübergänge brauchen mehr Reibung, mehr Klarheit und optional kryptographischen Besitznachweis. Nicht für jeden Nutzer, nicht bei jeder Handlung, nicht als flächendeckende Zumutung für die breite Masse. Aber für Hochrisikonutzer und Institutionen ist Reibung kein UX-Fehler. Sie ist die Brandschutztür. Wer politische Kommunikation, Quellenschutz, Kanzleikommunikation oder diplomatische Abstimmung über Messenger absichert, darf nicht so tun, als sei ein Telefonnummernwechsel eine gewöhnliche Profileinstellung.

Genau deshalb vermeidet mein Proposal bewusst alle Massnahmen, die Signals Datenschutzmodell beschädigen würden. Kein GPS. Keine IMEI. Keine IMSI. Keine Seriennummern. Keine Hardware-Fingerprints. Keine zentrale Profilnamenüberwachung. Keine Inhaltsanalyse. Keine serverseitige Social-Graph-Ausweitung. Kein Umbau von Signal zu einem Identitätsanbieter. Keine Pflicht zu Hardware Security Keys für alle Nutzer. Die Härtung muss lokal, gestuft und explizit bleiben.10

Das ist der entscheidende Punkt: Privacy-preserving Security ist kein Widerspruch. Man kann Account-Zeremonien härten, ohne Signal in eine Datensammelmaschine zu verwandeln. Man muss es nur wollen und sauber modellieren.

Support-Imitation: Die App sollte den Betrug nicht höflich durchreichen

Signal weiss, dass es keinen Signal Support per Chat gibt. Signal sagt das. Signal dokumentiert das. Die App könnte daraus eine klare lokale Policy machen.

Wenn eine Message Request von einem unbekannten Absender einen Profilnamen verwendet, der „Signal Support„, „Signal Security„, „Signal Verification„, „Account Recovery„, „Support Team„, „Security Team“ oder offensichtlichen Varianten ähnelt, sollte der Client einen blockierenden Warnscreen anzeigen. Nicht ein Icon. Nicht einen grauen Hinweis. Nicht einen Text, den der Nutzer im Reflex wegwischt. Ein harter, lokaler Bruch des Flows.

Die Meldung könnte lauten: „Signal bietet keinen Support über Signal-Chats oder Message Requests. Diese Nachricht ist sehr wahrscheinlich Betrug.“ Das Antwortfeld bleibt zunächst deaktiviert. Link-Previews, QR-Code-Previews und Schnellantworten bleiben aus. Der Nutzer kann fortfahren, aber erst nach bewusster Entsperrung. False Positives werden als Friktion behandelt, nicht als dauerhafte Zensur.

Das muss nicht zentral geschehen. Es braucht keine serverseitige Profilnamensüberwachung. Der Client kann lokal Unicode-Normalisierung, Homoglyphen, Zero-Width-Zeichen, Spacing-Tricks und sprachliche Varianten prüfen. Natürlich ist diese Heuristik nie perfekt. Natürlich wird es Umgehungen geben. Aber das ist kein Gegenargument. Sicherheit ist selten absolut. Sie ist Kostenverschiebung. Wer Support-Imitation billiger lässt als die Warnung davor, baut eine komfortable Phishing-Autobahn.

Offizielle Kommunikation darf nie wie Chat aussehen

Der zweite Schritt folgt zwingend aus dem ersten. Offizielle Signal-Kommunikation sollte niemals als normaler Chat, Message Request, Username oder Profil erscheinen. Signal braucht eine dedizierte In-App-Sicherheitsfläche, visuell und funktional getrennt von Chats. Offizielle Hinweise erscheinen dort, über zuvor initiierte Supportkorrespondenz oder über klar dokumentierte offizielle Kanäle. Nicht als „Signal Security Bot„. Nicht als „Support Team„. Nicht als freundliche Nachricht im selben Raum, in dem jeder Angreifer einen Profilnamen setzen kann.

Dann kann die App konsistent kommunizieren: Offizielle Signal-Sicherheitsmitteilungen erscheinen nicht als Chats oder Message Requests.

Diese Regel ist banal, und genau darin liegt ihre Stärke. Phishing ist ein Sprachangriff. Der Angreifer kapert nicht nur Daten, sondern Bedeutungen: Support, Sicherheit, Wiederherstellung, Bestätigung, Login. Die Verteidigung muss ebenfalls semantisch sein. Ein Nutzer muss nicht erst eine Hilfeseite kennen, um zu wissen, dass „Signal Support“ im Chat nicht existiert. Die App muss diese Weltordnung erzwingen.

Registration Lock: Kein abstraktes Extra, sondern Account-Takeover-Schutz

Registration Lock darf nicht wie eine obskure Zusatzoption wirken, die man aktiviert, wenn man zu viel Zeit in Einstellungen verbringt. Signal sollte Registration Lock als Account-Takeover-Schutz kommunizieren. Konkret, hart, ohne pädagogischen Nebel: Ohne Registration Lock kann jemand, der Deinen Registrierungscode erhält, unter Umständen Deine Nummer auf einem anderen Gerät registrieren.

Diese Aussage muss im Onboarding, bei Code-Anforderung, nach De-Registration, vor Telefonnummernwechseln, beim Hinzufügen von Linked Devices und beim Aktivieren eines Enhanced Account Protection Mode sichtbar sein. Für normale Nutzer bleibt Registration Lock eine starke Empfehlung. Für Hochrisikokonfigurationen sollte sie verpflichtend sein.

Dabei muss Signal ehrlich bleiben. Die PIN ist kein Chat-Backup; Signal kennt die PIN nicht und kann sie nicht zurücksetzen; wer sie vergisst und Registration Lock aktiviert hat, kann ausgesperrt sein.11 Sicherheit ohne Recovery ist nutzerfeindlich. Recovery ohne Reibung ist ein Angriffspfad. Genau deshalb braucht es gestufte Modi statt einer pauschalen Pflicht für alle.

Schwache numerische PINs sollten in Hochrisikokonfigurationen entmutigt werden. Alphanumerische PINs oder Passphrasen gehören dort klar bevorzugt. Die meisten Nutzer wollen einfache Zahlen. Angreifer auch. Diese Interessenüberschneidung ist kein Zufall.

Bildung im Risiko-Moment statt Sicherheitstexte im Archiv

Allgemeine Sicherheitsratschläge sind nett. Im Angriffsmoment sind sie oft wertlos. Ein Nutzer, der von einem angeblichen Support-Konto unter Druck gesetzt wird, ruft nicht gedanklich eine Supportseite ab. Er folgt dem Flow.

Darum braucht Signal kurze, konkrete Hinweise im exakten Risiko-Moment.

  • Beim Registrierungscode: „Dieser Code registriert Deine Signal-Nummer auf einem Gerät. Teile ihn nicht. Signal Support wird niemals danach fragen.“
  • Bei der Signal PIN: „Die Eingabe Deiner Signal PIN kann diese Registrierung fortsetzen. Signal Support wird niemals danach fragen.“
  • Bei De-Registration: „Dein Signal-Account funktioniert auf diesem Gerät nicht mehr, weil Deine Nummer möglicherweise anderswo registriert oder geändert wurde. Hast Du das nicht veranlasst, kann Dein Account gefährdet sein.“
  • Bei Re-Registration: „Eine erneute Registrierung kann einen neuen Signal-Account erzeugen. Sie stellt Deine bisherige Signal-Identität möglicherweise nicht wieder her.“

Der letzte Satz ist entscheidend. Viele Nutzer verstehen „erneut registrieren“ als „wieder einloggen“. In einer Account-Continuity-Attacke ist genau diese Mehrdeutigkeit ausnutzbar. Die App muss nicht nur sagen, dass etwas passiert. Sie muss sagen, was es bedeutet.

Telefonnummernwechsel: Kein Profilfeld, sondern Identitätsübergang

Ein Telefonnummernwechsel verändert den primären Routing-Identifier eines Signal-Accounts. Signal selbst beschreibt, dass Change Number nur unterstützt wird, wenn der Nutzer ein aktives Signal-Konto verwendet und SMS an die neue Nummer empfangen kann; nicht unterstützt ist der Vorgang unter anderem, wenn das alte Gerät fehlt, das Telefon verloren wurde oder keine Signal-Nachrichten gesendet und empfangen werden können.12 Schon diese Regeln zeigen: Telefonnummernwechsel ist kein kosmetisches Detail.

Im Standardmodus sollte Signal den Sicherheitskontext deutlicher erklären. Im Enhanced Account Protection Mode sollte ein Telefonnummernwechsel eine Wartefrist auslösen, etwa 24 Stunden. Während dieser Frist zeigt das bestehende Primary Device eine persistente Abbruchoption: „This phone-number change was not initiated by me.“ Ist das bisherige Primary Device aktiv, muss es bestätigen. Ist es verloren, zerstört oder nicht verfügbar, braucht es einen langsameren Recovery-Pfad, der sichtbar von normaler Migration getrennt ist.

Der Designgrundsatz ist schlicht: Wer den primären Routing-Identifier eines Accounts entfernt oder ändert, sollte Lärm erzeugen, Zeit kosten und möglichst reversibel bleiben. Lautlosigkeit ist hier kein Qualitätsmerkmal. Sie ist Komfort für den falschen Akteur.

Account-Kontinuität sichtbar machen

Signal sollte einen Account-Continuity-Indicator einführen. Drei Zustände reichen für den Anfang:

  • „Same Signal identity restored.“
  • „New Signal identity created. Previous identity not restored.“
  • „Previous Signal identity may still be active or controlled elsewhere.“
Abbildung 2: Account-Continuity Status

Das braucht keine zentrale Account-Historie. Ein Gerät, das früher eine Signal-Identität hielt und nach Re-Registration eine andere Identität sieht, kann diese Diskontinuität lokal erkennen und erklären. Die App muss nicht alles über den Nutzer wissen. Sie muss wissen, was sie selbst gerade erlebt hat.

Das ist der Unterschied zwischen kryptographischer Präzision und menschlicher Lesbarkeit. Signal kennt Sicherheitsnummern. Signal informiert Nutzer, wenn sich Sicherheitsnummern ändern; verifizierte Sicherheitsnummern müssen bei Änderung manuell erneut genehmigt werden, bevor neue Nachrichten gesendet werden können.13 Account-Kontinuität muss eine eigene Anzeige bekommen. Nicht als verstecktes Detail im Menü. Nicht als Folgerung aus fehlender Historie. Als klare Aussage.

De-Registration als Alarm, nicht als Schluckauf

De-Registration darf nicht wie eine neutrale Session-Störung erscheinen. Wird ein bestehendes Gerät deregistriert, weil die Nummer anderswo registriert oder die Telefonnummer geändert wurde, sollte Signal das als mögliches Sicherheitsereignis darstellen. Nicht panisch, aber klar.

Die App könnte sagen: „Your Signal account stopped working on this device because your number may have been registered or changed elsewhere. If this was not you, your account may be at risk.“ Dazu ein Button: „This was not me.„

Dieser Button muss keine magische Rückabwicklung versprechen. Er kann einen Incident Flow starten: Erklärung, Prüfung von Linked Devices, Empfehlung von Registration Lock, Recovery-Pfad, temporäres Verlangsamen weiterer kritischer Änderungen, optionaler Hinweis an Kontakte. Entscheidend ist der semantische Bruch. Der Angreifer sagt: De-Registration ist erwartet. Die App muss sagen: De-Registration kann ein Alarm sein.

Diese Änderung wäre vielleicht unspektakulär. Gerade deshalb ist sie wichtig. Die meisten wirksamen Sicherheitsverbesserungen sind nicht glamourös. Sie entfernen Ambiguität an der Stelle, an der ein Angreifer sie gerade ausbeutet.

Kontaktwarnungen: Vertrauenswert frisch veränderter Accounts senken

Nach Telefonnummernwechsel, jüngster Re-Registration oder Hochrisiko-Migration sollten Kontakte eine verständliche, sicherheitsgerahmte Warnung erhalten: „This account recently changed its phone number. Verify through another channel before sharing sensitive information.„

Das Ziel ist nicht Panik. Ein Routine-Nummernwechsel braucht keinen Alarm. Eine Kombination aus Nummernwechsel, De-Registration, Re-Registration oder Enhanced-Recovery ist eine andere Lage. Ein expliziter „This was not me„-Incident rechtfertigt eine temporär stärkere Warnung, allerdings mit Missbrauchsschutz. Sonst wird die Warnfunktion selbst zum Werkzeug für Belästigung oder Rufschädigung.

Der sicherheitspolitische Punkt ist: Ein frisch kompromittierter Account besitzt hohen Vertrauenswert. Genau diesen Wert nutzt der Angreifer, wenn er aus dem übernommenen Konto heraus Kontaktlisten, Gruppen oder vertrauliche Netzwerke adressiert. Die Warnung soll nicht jeden Account verdächtig machen. Sie soll den Vertrauenswert nach kritischen Identitätsübergängen temporär senken.

Das ist besonders relevant für Journalisten und politische Gruppen. Ein kompromittierter Account ist dort kein isoliertes Problem. Er ist ein Einstieg in Netzwerke. Wer Zugriff auf Gruppen erhält, sieht Beziehungen, Rollen, Zeitpunkte, Gesprächspartner und oft mehr Kontext, als eine einzelne Nachricht verrät.

Account Security Status: Sichtbarkeit statt Einstellungsgrab

Viele Sicherheitszustände liegen in Apps wie in archäologischen Schichten: irgendwo vorhanden, selten gefunden, noch seltener verstanden. Signal sollte eine kompakte Account-Security-Übersicht anbieten.

  • Account identity unchanged since.
  • Last phone-number change.
  • Last linked-device addition.
  • Registration Lock status.
  • Linked devices count and last activity.
  • Last critical account action.

Dieses Panel muss lokal und datensparsam bleiben. Kein Telemetrieprodukt. Kein Dashboard für Signal. Ein Werkzeug für den Nutzer. Die Aufgabe lautet nicht, Signal mehr wissen zu lassen. Die Aufgabe lautet, dem Nutzer sichtbar zu machen, was sein eigener Client über kritische Account-Ereignisse ohnehin wissen kann.

Das wäre gerade bei Linked Devices nützlich. Signal dokumentiert, dass gekoppelte Geräte unter Einstellungen sichtbar sind.14 Aber sichtbare Möglichkeit ist nicht dasselbe wie gelebte Kontrolle. Kaum jemand prüft regelmässig seine Linked Devices, solange nichts wehtut. Sicherheit darf nicht darauf bauen, dass Nutzer aus Langeweile forensische Hygiene betreiben.

Enhanced Account Protection Mode: Reibung als Schutzfunktion

Signal sollte einen optionalen Enhanced Account Protection Mode anbieten. Nicht für alle. Nicht als Standardbremsklotz. Sondern für Nutzer mit erhöhtem Social-Engineering-Risiko: Journalisten, Anwälte, politische Personen, Diplomaten, Aktivisten, Beamte, Führungskräfte, sicherheitssensible Organisationen und Personen mit staatlichem oder organisiertem Bedrohungsmodell.

Dieser Modus bündelt Massnahmen, die für normale Nutzer zu hart wären:

  • Mandatory Registration Lock,
  • stärkere PIN- oder Passphrase-Anforderungen,
  • Phone-number-change delay,
  • Primary-device confirmation,
  • persistent cancellation window,
  • klare De-Registration-Warnung,
  • prominenter Account-Continuity-Indicator,
  • stärkere Kontaktwarnungen,
  • eingeschränkte Linked-Device-Addition und ein
  • kryptographischer Account Continuity Key.

Die UX-Frage ist real. Eine typed Confirmation plus Wartefrist plus Primary-Device-Bestätigung ist für Durchschnittsnutzer wahrscheinlich zu viel. Aber für politische Spitzenpersonen, Redaktionen, Kanzleien und Behörden ist genau diese Friktion der Zweck. Wer das als unzumutbar empfindet, verwechselt Messenger-Komfort mit Kommunikationssicherheit. Das ist menschlich verständlich, aber sicherheitstechnisch schwach.

Critical Account Action Confirmation: Intent Binding statt „Are you sure?“

Für kritische Aktionen sollte Signal keine generische „Are you sure?„-Abfrage verwenden. Klickmüdigkeit ist kein Randproblem. Sie ist ein Designversagen mit Tradition.

Stattdessen braucht es eine transaktionsgebundene Bestätigungszeremonie. Vor Telefonnummernwechsel, Account-Migration, Identity Restoration oder privilegierter Linked-Device-Addition zeigt Signal die genaue Aktion und deren Konsequenz. Alte Telefonnummer, neue Telefonnummer, Zielgerät, Betriebssystem, Zeit, soweit verfügbar und ohne neue Datensammlung. Dann muss der Nutzer einen dynamischen Satz eingeben:

  • „I AUTHORIZE CHANGING MY SIGNAL NUMBER TO +41 …789: 483921.“ Oder:
  • „I AUTHORIZE LINKING A NEW DESKTOP DEVICE: 483921.“ Oder:
  • „I AUTHORIZE RESTORING THIS SIGNAL IDENTITY ON A NEW PHONE: 483921.“

Diese Texteingabe ist kein kryptographischer Faktor. Sie ist Intent Binding. Sie reduziert Fehlklicks, QR-Code-Verwechslungen und reflexives Bestätigen. Gegen live geführtes Social Engineering reicht sie nicht. Ein Angreifer kann einem Opfer diktieren, was zu tippen ist. Deshalb braucht es Wartefrist, Primary-Device-Abbruch und im Enhanced Mode kryptographischen Besitznachweis.

Der Wert liegt darin, den Angriff vom reflexiven Tippen zur bewussten Transaktion zu verschieben. Das ist nicht unüberwindlich. Aber es kostet den Angreifer mehr Überzeugungsarbeit und erzeugt mehr Chancen für Abbruch.

Account Continuity Key: Vom phishbaren Code zum Besitznachweis

Die stärkste technische Massnahme ist ein optionaler Account Continuity Key. Beim Aktivieren des Enhanced Account Protection Mode erzeugt das Primary Device ein asymmetrisches Schlüsselpaar. Der Private Key bleibt lokal geschützt, etwa über Android Keystore, iOS Keychain, Secure Enclave oder vergleichbare Plattformmechanismen. Der Signal-Server speichert nur den Public Key oder einen geeigneten public-key-derived verifier. Für kritische Account-Aktionen sendet der Server eine Challenge. Das Primary Device signiert diese Challenge. Die Challenge bindet Account Identifier, Action Type, alte und neue Telefonnummer, soweit anwendbar, Target Device, Timestamp und Server Nonce. Der Server akzeptiert die kritische Aktion nur bei gültiger Signatur oder nach langsamem Recovery-Pfad.15

Damit verändert sich das Problem des Angreifers. Ein abgephishter Registrierungscode oder eine abgephishte PIN reicht im Enhanced Mode nicht mehr aus. Der Angreifer braucht Zugriff auf den geschützten Private Key oder auf Recovery-Material. Der Angriff wird nicht unmöglich, aber er wird aus der Ferne deutlich teurer.

Dieser Vorschlag ist mit Signals Datenschutzanspruch kompatibel. Der Server erhält kein Geheimnis. Er prüft Besitz. Android Keystore ist genau für solche Muster angelegt: Schlüsselmaterial kann in einem Container gespeichert werden, ist schwerer zu extrahieren, kann für kryptographische Operationen verwendet werden, ohne das Schlüsselmaterial selbst auszugeben, und kann an Nutzerauthentifizierung oder sichere Hardware gebunden werden.16 Androids BiometricPrompt unterstützt auth-per-use keys, bei denen der Nutzer für jede Nutzung eines geschützten Schlüssels biometrische oder Geräte-Credential-Authentifizierung leisten muss, was Google ausdrücklich für hochwertige Transaktionen wie grosse Zahlungen oder Gesundheitsdaten nennt.17 Auch Apples Keychain und Secure Enclave bieten Plattformmechanismen, die sensible Geheimnisse und Schlüsselmaterial gerätegebunden schützen; Apple beschreibt etwa, dass Keychain-Geheimwerte einen Roundtrip durch die Secure Enclave benötigen.18

Das heisst nicht, dass der Account Continuity Key physische Kompromittierung besiegt. Ein Angreifer, der ein entsperrtes Primary Device vollständig kontrolliert, spielt in einer anderen Liga. Aber genau das muss offen gesagt werden. Der Account Continuity Key schützt gegen remote Social Engineering, nicht gegen Totalverlust des Geräts unter voller lokaler Kontrolle.

Abbildung 3: Account-Continuity Key

Multi-Device darf nicht automatisch Identitätsmacht bedeuten

Ein Account Continuity Key ist mit Multi-Device kompatibel, wenn Signal eine saubere Unterscheidung trifft: Normale Linked Devices sind nicht automatisch Primary Devices. Ein Desktop-Client darf Nachrichten empfangen, ohne kritische Account-Aktionen signieren zu dürfen.

Signal selbst dokumentiert, dass jedes Konto ein Primary Device haben muss, dass dieses mit dem Account verbunden bleibt und nicht entfernt werden kann; jedes gekoppelte Gerät hat eigene Verschlüsselungsschlüssel, und ein Gerät kann keine neuen Verschlüsselungsschlüssel für ein anderes Gerät erzeugen.19 Diese bestehende Architektur legt nahe, dass Geräte bereits rollenbezogen unterschieden werden. Genau daran könnte ein Account Continuity Key anschliessen.

Im Standard-Enhanced-Modell signiert nur das Primary Device kritische Account-Aktionen. In institutionellen Modellen könnten Threshold-Approvals hinzukommen: Primary Device plus managed recovery key, Hardware Security Key plus administrative recovery mechanism, oder andere Kombinationen. Entscheidend ist: Das darf keinen Zugriff auf Nachrichteninhalte oder Nachrichtenhistorie implizieren. Es geht um Account-Kontinuität, nicht um Organisationsescrow für Kommunikation.

Primary Device Lifecycle: Der Schlüssel braucht Biographie

Ein starker Account Continuity Key wirft sofort praktische Fragen auf. Was ist das Primary Device? Wie wird es gewechselt? Was passiert bei Verlust, Diebstahl, Zerstörung? Wie wird Key Rotation geregelt?

Für die Zwecke des Account Continuity Key sollte das Primary Device das Gerät sein, das den aktuellen Continuity Key erzeugt und registriert hat, sofern der Nutzer diese Rolle nicht explizit überträgt. Ein Primary-Device-Transfer geschieht bevorzugt durch signed handover: Das aktuelle Primary Device autorisiert das neue Primary Device durch Signatur einer action-bound Challenge, die Zielgerät, Aktion, Zeitstempel und Server Nonce bindet.

Der Fallback ist slow recovery. Ist das Primary Device verloren, zerstört, gestohlen oder nicht verfügbar, kann der Nutzer den Account Continuity Key nur über einen sichtbar langsameren Prozess rotieren: Registration Lock, Recovery Artifact oder High-Entropy Recovery Key, Wartefrist und klare Warnungen auf noch aktiven Linked Devices, soweit vorhanden. Die Key Rotation widerruft den alten Continuity Key und registriert einen neuen. Während des Recovery Window bleiben Telefonnummernwechsel, neue Linked Devices und weitere Key Rotations verzögert oder eingeschränkt.

Das verhindert, dass Recovery zur schnelleren Hintertür wird. Ein Recovery-Pfad muss Kontrolle wiederherstellen, nicht Enhanced Protections heimlich umgehen.

Recovery Artifact und QR Present Mode

Eine Recovery-Datei kann nützlich sein, darf aber kein nackter Hash und kein Bearer Token sein. Wer die Datei kopiert, hätte sonst den Recovery-Pfad. Dann liegt der Schlüssel nicht mehr unter der Fussmatte, sondern in einem hübscher benannten Dateianhang.

Besser wäre ein verschlüsseltes Recovery Artifact:

  • encrypted private recovery key oder
  • migration secret,
  • Key Version,
  • Creation Date,
  • KDF-Parameter wie Argon2id,
  • minimale account-continuity metadata,
  • optional Shamir Splitting für institutionelle Nutzer.

Geschützt durch starke Passphrase oder High-Entropy Recovery Key. Für Institutionen kann Recovery-Material in MDM, HSM, Smartcard-Infrastruktur, Hardware Security Keys oder verwalteten Secure-Backup-Systemen liegen.

Ein QR Present Mode kann lokale Migration vereinfachen. Aber er muss kurzlebig, action-bound und beidseitig bestätigt sein. Er darf kein screenshotbarer universeller Recovery-Bypass werden. Gerade QR-Codes sind anfällig für die gleiche semantische Verwechslung wie Support-Dialoge: Der Nutzer scannt etwas und glaubt, er trete einer Gruppe bei, bestätige einen Support-Fall oder stelle etwas wieder her, während er tatsächlich ein Gerät koppelt oder eine Migration freigibt.

Institutionelle Schutzstufe: Hardware Token dort, wo sie hingehören

Hardware Security Keys wie YubiKey oder Nitrokey sind für die breite Masse kein realistischer Standard. Für Behörden, Parteien, Redaktionen, Kanzleien, NGOs und sicherheitskritische Unternehmen hingegen ist zusätzliche Hardware kein grotesker Luxus, sondern ein vernünftiger Bestandteil des Schutzmodells. Wer mit politischer Kommunikation, Quellenschutz oder diplomatischen Kontakten arbeitet, kann schwerlich behaupten, ein Hardware Token sei unzumutbar, während ein Account-Takeover ganze Netzwerke kompromittiert.

Ein Institutional Tier könnte Mandatory Registration Lock, Hardware-token support, administrierbare Recovery Keys, eingeschränkte Linked-Device-Approval, Wartefristen für Telefonnummernwechsel, Account-Security-Status und lokale Auditierbarkeit für den Nutzer umfassen. Aber ohne Zugriff auf Nachrichteninhalte. Ohne Nachrichtenhistorie-Escrow. Ohne Organisationsschlüssel für Kommunikation. Der Schutz betrifft Account-Kontinuität und kritische Identitätsoperationen, nicht die Aufweichung von Ende-zu-Ende-Verschlüsselung.

Das ist ein wichtiger Grenzstein. Sicherheitsadministration darf nicht zur Hintertür werden.

Implementierung

Die Massnahmen lassen sich gestuft denken.

  • Zuerst die niedrig hängenden, aber wirkungsvollen Client-Änderungen:
    • harte lokale Warnungen bei Signal-Support-Imitation,
    • offizielle Signal-Hinweise getrennt von Chats,
    • risikospezifische Warnungen für Code, PIN, De-Registration und Re-Registration,
    • klare Unterscheidung zwischen restored identity und new account,
    • Account Security Panel.
  • Dann Enhanced Account Protection Mode:
    • Wartefrist für Telefonnummernwechsel,
    • Primary-Device Confirmation und Cancellation,
    • „This was not me„-Incident Flow,
    • sicherheitsgerahmte Kontaktwarnungen,
    • transaktionsgebundene Texteingabe.
  • Erst danach die schwere Architektur:
    • Account Continuity Key,
    • Challenge-Response-Signing,
    • encrypted Recovery Artifact,
    • institutionelle Policies,
    • Hardware-token support.

Diese Reihenfolge ist wichtig. Man muss nicht auf die perfekte kryptographische Besitznachweisarchitektur warten, um Support-Imitation im Client härter zu markieren. Man muss nicht alle Recovery-Fragen final lösen, um Re-Registration semantisch sauberer zu beschriften. Gute Sicherheitsentwicklung beginnt nicht immer mit dem elegantesten Protokoll. Manchmal beginnt sie damit, die App im richtigen Moment den richtigen Satz sagen zu lassen.

Einwände: Reibung, Recovery, Privacy, Warnmüdigkeit

Der erste Einwand lautet UX-Friction. Er ist berechtigt. Die Antwort ist Staging. Normale Nutzer bekommen klarere Hinweise und bessere Account-Kontinuitätsanzeigen. Hochrisikonutzer wählen stärkere Controls. Institutionen rechtfertigen noch mehr Friktion. Das Produkt muss nicht allen dieselbe Last auferlegen.

Der zweite Einwand lautet Recovery Risk. Auch er ist berechtigt. Wer sein Primary Device verliert, darf nicht dauerhaft aus seiner Identität fallen. Aber Recovery ohne Friktion wird selbst zum Angriffspfad. Deshalb: slow recovery, klare Wartefrist, sichtbare Warnungen, temporär geschützter Zustand nach Wiederherstellung.

Der dritte Einwand lautet Privacy. Genau deshalb vermeidet der Vorschlag GPS, IMEI, IMSI, Message Scanning, zentrale Profilnamenüberwachung und Social-Graph-Erweiterung. Die Lösung liegt in lokaler Entscheidung und Public-Key-Verifikation. Signal muss nicht mehr über Nutzer wissen, um kritische Account-Aktionen besser zu schützen.

Der vierte Einwand lautet Warning Fatigue. Warnungen sind inflationär entwertbar. Also müssen sie selten, konkret und handlungsbezogen sein. Nicht jede Nummernänderung ist Krise. Aber eine De-Registration nach angeblichem Supportkontakt ist kein gewöhnlicher Zustand. Eine App, die beides gleich behandelt, verschenkt Kontext.

Der fünfte Einwand lautet physischer Zugriff. Ein Account Continuity Key schützt nicht gegen vollständige Kontrolle eines entsperrten Primary Device. Er verschiebt den Angriff von remote Credential Phishing hin zu geschütztem Schlüsselbesitz oder Recovery-Material. Das ist keine absolute Sicherheit, aber eine erhebliche Verbesserung gegen die beobachtete Angriffsklasse.

Der sechste Einwand lautet False Positives bei Support-Imitation. Die Antwort: Friktion statt Zensur. Der Nutzer kann nach bewusster Entsperrung fortfahren. Aber der erste Kontakt wird gebremst, Link- und QR-Risiken werden reduziert, und das Geschäftsmodell der Support-Imitation wird schlechter.

Schlussbemerkungen

Signal muss seine Kryptographie in dieser Angriffsklasse nicht reparieren. Nach allem, was öffentlich belegt ist, liegt der Bruch nicht dort. Die Ende-zu-Ende-Verschlüsselung hält, während Menschen mit echten Codes, echten PINs, echten App-Funktionen und falschen Erklärungen manipuliert werden.

Das ist keine kleine Sache. Es ist die alte Lehre der Sicherheitstechnik in moderner Messenger-Gestalt: Ein Schloss ist stark, bis jemand den Bewohner überzeugt, selbst aufzuschliessen. Ein Protokoll ist sauber, bis die Account-Zeremonie den Nutzer nicht mehr erkennen lässt, ob er eine Identität wiederherstellt, neu erzeugt, überträgt oder verliert.

Die Beobachtung ist: Signal beschreibt keinen kryptographischen Bruch, sondern eine Phishing-Kampagne mit Support-Imitation, Credential-Abgriff, Telefonnummernwechsel, De-Registration-Verwirrung und Missbrauch kompromittierter Accounts. Das Modell ist: Die kritische Zone heisst Account-Continuity-Ceremony. Die Interpretation lautet: Die Schwäche entsteht an der Schnittstelle zwischen Nutzerpsychologie, UI, Recovery-Logik und Account-Status. Das Werturteil ist: Wer einen sicherheitskritischen Messenger für Journalisten, Politiker, Anwälte, Diplomaten, Aktivisten und Institutionen betreibt, muss kritische Identitätsübergänge mit mehr Klarheit, mehr Reibung und optionalem kryptographischem Besitznachweis schützen.

Nicht Signal wurde gehackt. Die Zeremonie wurde ausgetrickst. Und genau diese Zeremonie muss künftig so gebaut sein, dass ein Angreifer mit den richtigen Worten nicht mehr durch die Vordertür laufen kann.

In eigener Sache

Dieser Beitrag ist Teil meiner unabhängigen Security-Forschung und Publizistik. Er entstand ohne institutionelle Finanzierung, ohne Konzernbudget und ohne bezahlten Auftrag. Wer diese Arbeit für wertvoll hält, kann sie durch Teilen, fachliche Kritik oder direkte Unterstützung mittragen. Das hilft mir, technische Analysen, Security-Proposals und längere Recherchen weiterhin unabhängig zu veröffentlichen.

Unterstützungsmöglichkeiten:

https://www.gofundme.com/f/rechtsverteidigung-existenzsicherung-arbeitsgericht-lisbon

Oder direkt hier:

Spenden

Mille fois an alle Spender.

Quellen

  1. Reuters, „German prosecutors investigate phishing attack targeting politicians“, 24. April 2026; Reuters berichtet über Ermittlungen der Bundesanwaltschaft, Warnungen von BfV und BSI, den Fokus auf Signal sowie die Einschätzung, dass legitime Funktionen in Verbindung mit Social Engineering statt Malware oder technischen Schwachstellen genutzt wurden. https://www.reuters.com/technology/german-prosecutors-investigate-phishing-attack-targeting-politicians-2026-04-24/ ↩︎
  2. Daniel AJ Sokolov, Heise online, „Signal attacks: Signal advises caution and registration lock“, 28. April 2026; Heise gibt Signals öffentliche Stellungnahme wieder, wonach Signal nicht „hacked“ worden sei, Verschlüsselung, Infrastruktur und Codeintegrität nicht kompromittiert seien, und beschreibt die von Signal genannte Kette aus Support-Imitation, Credential-Abgriff, Telefonnummernwechsel, De-Registration und Re-Registration-Verwirrung. https://www.heise.de/en/news/Signal-attacks-Signal-advises-caution-and-registration-lock-11274263.html ↩︎
  3. Marc S. Weidner, „Proposal Following the Recent Account Takeover Campaign Targeting German Parliamentary Figures“, digital signiertes Security-Design-Proposal an Signal Messenger, LLC, 28. April 2026; das Proposal bezeichnet sich ausdrücklich als strukturierten Security-Design-Vorschlag und nicht als Vulnerability Report, vermeidet Hardware-Identifier, GPS, IMEI, IMSI, zentrale Profilnamenüberwachung, Inhaltsanalyse und Social-Graph-Erweiterung. 2026.04.28_signal_proposal_final_public.pdf ↩︎
  4. Bill Toulas, BleepingComputer, „Germany warns of Signal account hijacking targeting senior figures“, 6. Februar 2026; der Bericht fasst BfV/BSI-Warnungen zusammen: keine Malware, keine technischen Schwachstellen, Support-Imitation, Account Takeover, QR-Code-basierte Linked-Device-Kopplung, Zugriff auf Chats und Kontakte. https://www.bleepingcomputer.com/news/security/germany-warns-of-signal-account-hijacking-targeting-senior-figures/ ↩︎
  5. Markus Reuter, Netzpolitik.org, „Numerous journalists targeted in attack via Signal Messenger“, 28. Januar 2026; der Bericht beschreibt gefälschte Signal-Support-Nachrichten, echte Verifizierungscodes, Re-Registration-Versuche sowie mögliche Folgen bei Weitergabe von Signal PIN und Verifizierungscode. https://netzpolitik.org/2026/phishing-attack-numerous-journalists-targeted-in-attack-via-signal-messenger/ ↩︎
  6. Signal Support, „Hat mich der Signal Support oder Signal Security kontaktiert?“ sowie „So schützt du dich vor Phishing, Betrug und Identitätsdiebstahl“; Signal erklärt, dass Support nicht per In-App-Nachrichten, Anrufen, SMS oder Social Media Kontakt aufnimmt, dass angebliche Support- oder Security-Kontakte innerhalb Signal als Betrugs- und Phishing-Versuch zu behandeln sind und dass Signal niemals nach Bestätigungscodes, Recovery Keys oder Zahlungsdaten fragt. https://support.signal.org/hc/de/articles/9922048370586-Hat-mich-der-Signal-Support-oder-Signal-Security-kontaktiert ↩︎
  7. Marc Weidner, Proposal, Threat Model und Design Goals; der Vorschlag beschreibt Support-Imitation, Credential-Offenlegung, Telefonnummernwechsel, De-Registration-Verwirrung, Re-Registration und Kontaktlisten-Missbrauch als Account-Continuity-Angriff. 2026.04.28_signal_proposal_final_public.pdf ↩︎
  8. Signal Support, „Signal PIN“; Signal erklärt, dass die PIN kein Chat-Backup, kein SMS-Verifizierungscode und kein Screen Lock ist, dass Signal die PIN nicht kennt und nicht zurücksetzen kann und dass Registration Lock nach sieben Tagen Inaktivität auslaufen kann. https://support.signal.org/hc/en-us/articles/360007059792-Signal-PIN ↩︎
  9. Signal Support, „Linked Devices“; Signal dokumentiert Kopplung von Signal Desktop oder Signal iPad mit dem Telefon, QR-Code-Linking, mögliche Synchronisierung der letzten 45 Tage Medien, Funktionsfähigkeit ohne online befindliches Telefon, 30 Tage Inaktivitätsentkopplung und maximal fünf Linked Devices. https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices ↩︎
  10. Marc Weidner, Proposal, Non-Goals und Privacy-Preserving-Mitigation-Abschnitt; der Vorschlag schliesst GPS, IMEI, IMSI, Seriennummern, Hardware-Fingerprints, Kontaktgraphen, Message Content und Profilnamen-Telemetrie ausdrücklich aus. 2026.04.28_signal_proposal_final_public.pdf ↩︎
  11. Signal Support, „Signal PIN“ und „Twilio-Vorfall: Was Signal-Nutzer*innen wissen müssen“; Signal empfiehlt Registration Lock nach dem Twilio-Vorfall als zusätzliche Verifikationsschicht und beschreibt Risiken sowie Grenzen der PIN. https://support.signal.org/hc/en-us/articles/360007059792-Signal-PIN ↩︎
  12. Signal Support, „Change Number“; Signal beschreibt, wann Telefonnummernwechsel unterstützt wird und wann nicht, insbesondere bei fehlendem altem Gerät, verlorenem Telefon oder nicht aktivem Konto. https://support.signal.org/hc/en-us/articles/360007062012-Change-Number ↩︎
  13. Signal Support, „What is a safety number and why do I see that it changed?“; Signal erklärt Sicherheitsnummern, Änderungswarnungen und manuelle Genehmigung bei verifizierten Sicherheitsnummern. https://support.signal.org/hc/en-us/articles/360007060632-What-is-a-safety-number-and-why-do-I-see-that-it-changed ↩︎
  14. Signal Support, „Linked Devices“ und „Unlinking Devices“; gekoppelte Geräte können in den Einstellungen eingesehen und entkoppelt werden. https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices ↩︎
  15. Marc Weidner, Proposal, „Account Continuity Key“, „Physical access and local user verification“ sowie „Primary device lifecycle and key rotation“; der Vorschlag beschreibt Public-Key-basierte Challenge-Response-Signaturen, Primary-Device-Rolle, signed handover, slow recovery und Grenzen bei physischem Zugriff. 2026.04.28_signal_proposal_final_public.pdf ↩︎
  16. Android Developers, „Android Keystore system“; Android beschreibt nicht exportierbares Schlüsselmaterial, mögliche Bindung an sichere Hardware, autorisierte Schlüsselnutzung und Nutzerauthentifizierung für Key Use. https://developer.android.com/privacy-and-security/keystore ↩︎
  17. Android Developers, „Show a biometric authentication dialog“; Android beschreibt auth-per-use keys, bei denen für jede Verwendung eines geschützten Schlüssels biometrische oder Geräte-Credential-Authentifizierung erforderlich ist, insbesondere für hochwertige Transaktionen. https://developer.android.com/identity/sign-in/biometric-auth ↩︎
  18. Apple Platform Security, „Keychain data protection“; Apple beschreibt Keychain-Schutz mit AES-256-GCM, Metadata Key, Secret Key und Roundtrip des Secret Key durch die Secure Enclave. https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web ↩︎
  19. Signal Support, „Re-connect your primary device to continue using Signal Desktop“; Signal beschreibt, dass jedes Konto ein Primary Device haben muss, dieses nicht entfernt werden kann und jedes gekoppelte Gerät eigene Verschlüsselungsschlüssel besitzt. https://support.signal.org/hc/en-us/articles/8997185514138-Re-connect-your-primary-device-to-continue-using-Signal-Desktop ↩︎

2026.04.28_signal_proposal_final_public.pdf

2026.04.28_signal_proposal_final_public

Changelog

Categories: IT, IT-Security, Kryptographie, Linux, USA
Tags: , ,

You may also like

Search: