Sicherheitsmodell

Was diese App schützt, wie sie es tut, und — genauso wichtig — wogegen sie nicht hilft. Wer eine Sicherheitszusage nicht überprüfen kann, hat keine.

Wie ein Konto entsteht

Es gibt keine Registrierung. Beim Anlegen erzeugt dein Browser zwei Schlüsselpaare auf der Kurve P-256: eines zum Signieren (ECDSA), eines für Schlüsselaustausch (ECDH). Deine Identität ist der SHA-256-Hash beider öffentlicher Schlüssel. Der Server erfährt nur diesen Hash und die öffentlichen Teile — nie einen privaten Schlüssel, nie ein Passwort.

Beim Verbinden schickt der Server eine Zufallszahl, die du signierst. Damit ist bewiesen, dass du den privaten Schlüssel hast. Ein Angreifer, der die Verbindung mitschneidet, kann daraus nichts wiederverwenden.

Wo dein Schlüssel liegt

In genau zwei Zuständen: im Arbeitsspeicher dieses Tabs, und in der Schlüsseldatei, die du selbst herunterlädst. Die Datei ist mit deiner Passphrase verschlüsselt — PBKDF2-HMAC-SHA-256 mit 600 000 Iterationen, dann AES-256-GCM.

Die App benutzt kein localStorage, sessionStorage, IndexedDB, keine Cookies und keinen Service Worker. Nach dem Erzeugen wird der Schlüssel als extractable: false neu importiert: ab da kann ihn auch ein Fehler im Code nicht mehr auslesen. Tab zu, Sperren-Knopf oder 15 Minuten Inaktivität — jedes Mal sind Schlüssel und Verlauf weg.

Was der Server sieht

Der Server ist ein Relay ohne Datenbank. Alles liegt im RAM, ist gedeckelt, verfällt nach 24 Stunden und wird gelöscht, sobald alle Mitglieder es abgeholt haben. Ein Prozess-Neustart löscht alles.

Nachrichten

Jeder Raum hat einen AES-256-GCM-Schlüssel. Der Klartext wird zuerst mit deinem Identitätsschlüssel signiert, dann verschlüsselt. Raum-ID und Schlüssel-ID hängen als additional authenticated data mit drin — ein Chiffrat lässt sich also nicht in einen anderen Raum umhängen.

Weil vor dem Verschlüsseln signiert wird, reicht der Raumschlüssel allein nicht, um sich als jemand anderes auszugeben: auch ein Gruppenmitglied kann keine Nachricht in fremdem Namen fälschen.

Räume und Schlüsselwechsel

Ein Raum mit zwei Mitgliedern ist ein Direktchat, mit mehr eine Gruppe — technisch dasselbe. Der Raumschlüssel wird einzeln für jedes Mitglied verpackt: ECDH mit einem Wegwerf-Schlüssel des Absenders gegen deinen öffentlichen ECDH-Schlüssel, HKDF-SHA-256, AES-256-GCM. Der Server transportiert das Paket, ohne es öffnen zu können.

Bei jeder Änderung der Mitgliederliste wird ein neuer Raumschlüssel erzeugt. Wer neu dazukommt, kann nichts Älteres lesen — auch nicht das, was noch in der Warteschlange des Servers liegt. Wer entfernt wird, kann nichts Neues mehr lesen, selbst wenn die Verbindung bestehen bleibt.

Anrufe

Sprach- und Videoanrufe laufen als P2P-Mesh: jedes Paar hat eine eigene Verbindung, WebRTC verschlüsselt sie mit DTLS-SRTP. Medien berühren den Server nie.

Der übliche Angriff auf WebRTC ist der Signalisierungsserver, der die DTLS-Fingerabdrücke im SDP austauscht und sich dazwischenschaltet. Hier geht das nicht: SDP und ICE-Kandidaten reisen durch denselben verschlüsselten Raumkanal wie Nachrichten. Das Relay sieht nur Chiffrat und kann nichts ersetzen. STUN und TURN laufen auf diesem Server, damit kein Dritter die IP-Adressen der Anrufenden erfährt; ein TURN-Relay leitet ohnehin nur bereits verschlüsselte Pakete weiter.

Mesh trägt etwa sechs Teilnehmende, dann limitiert der Upload.

Beschlagnahmtes Gerät

Das war die Kernanforderung. Auf dem Gerät liegt nichts: kein Verlauf, kein Schlüssel, kein Kontoname, kein Cache-Eintrag mit Inhalten. Wer das Gerät hat, hat nichts — solange deine Schlüsseldatei nicht daneben liegt.

Wogegen das nicht hilft

• Metadaten. Das Relay sieht, welche Nutzer-IDs welche Raum-IDs abonnieren, wann und wie viel. Der Inhalt bleibt verborgen, der Kommunikationsgraph nicht. Dagegen hülfe nur ein Mixnet.
• Kompromittiertes Endgerät. Keylogger, bösartige Browser-Erweiterung oder ein Screenshot lesen mit, bevor verschlüsselt wird. Ende-zu-Ende endet an den Enden.
• Ein manipulierter Server. Der Code kommt vom Server. Wer ihn kontrolliert, könnte eine schlechtere Version ausliefern — das strukturelle Problem jeder Web-Krypto-App. Die CSP verbietet externe Skripte, aber gegen den Ursprung selbst schützt sie nicht.
• Vertauschte Schlüssel. Kontaktcodes kommen über einen Kanal, den diese App nicht kontrolliert. Vergleicht die Sicherheitsnummer über einen zweiten Weg, bevor es wichtig wird.
• Kein Forward Secrecy pro Nachricht. Es gibt keine Double-Ratchet-Kette. Der Raumschlüssel wechselt bei Mitgliederänderungen, nicht bei jeder Nachricht.
• Speicher ist nicht sicher löschbar. JavaScript kann Strings nicht überschreiben, und das Betriebssystem darf Speicher auf die Platte auslagern. Für harte Anforderungen: privates Fenster, Swap verschlüsselt oder aus.
• Wer beitritt, ist eine Vertrauensfrage. Jedes Mitglied kann weitere einladen. In sensiblen Räumen sollte klar sein, wer das darf.

Verwendete Verfahren

Der gesamte Client-Code liegt unter /js/ und ist unminifiziert lesbar. Prüfe ihn, statt dieser Seite zu glauben.