Geräte koppeln und entziehen

Es gibt kein Master-Passwort. Geräte weisen sich mit Schlüsseln aus, neue kommen über eine Kopplung mit Ziffernvergleich dazu, und verlorene werden entzogen — gefolgt von einer Rotation, die den alten Schlüssel wertlos macht.

Alles auf dieser Seite setzt ein Konto voraus. Wer tessera ohne Server benutzt, hat keins: Dort gibt es kein zweites Gerät, nichts zu entziehen, nichts zu rotieren und keinen Wiederherstellungscode. Die Geräteliste sagt das dann auch so und bietet den Weg zum Abgleich an.

Koppeln

Das neue Gerät erzeugt einen Kopplungscode, das eingerichtete nimmt ihn entgegen. Danach stehen auf beiden Bildschirmen sechs Ziffern, die übereinstimmen müssen.

Ablauf

B  meldet sich an: Name, öffentliche Schlüssel, Nonce   → pairing_id
B  zeigt Code / QR
A  liest ihn, prüft ihn, hinterlegt seinen Schlüssel und eine SAS-Bindung
B  holt den Schlüssel von A
   beide leiten dieselben sechs Ziffern ab
   ein Mensch vergleicht sie
B  bestätigt
A  hinterlegt den gewrappten Vault Key
B  holt ihn ab und öffnet ihn mit seinem privaten Schlüssel

Angezeigt wird in zwei Dreiergruppen: 481 205.

Warum der Vergleich der eigentliche Schutz ist

Der Server vermittelt zwar, ist in diesem Ablauf aber ausdrücklich kein vertrauenswürdiger Kanal: Wer sich dazwischensetzt, kann Schlüssel austauschen — aber nicht dafür sorgen, dass beide Seiten dieselben sechs Ziffern sehen. Stimmen sie nicht, bricht man ab.

Der Kopplungscode enthält kein Geheimnis. Wer ihn abfängt, kann damit nichts anfangen: Ohne den privaten Schlüssel des neuen Geräts lässt sich der gewrappte Vault Key nicht öffnen.
Gerät A vergleicht die vom Server gelieferten Werte mit den gescannten und bricht bei Abweichung ab.
Der Server lässt drei Versuche zu und vergleicht in konstanter Zeit. Danach ist die Sitzung verbrannt.
Der gewrappte Vault Key wird erst hinterlegt, nachdem der Vergleich bestätigt wurde.
Kopplungssitzungen leben fünf Minuten und sind einmalig.
Das neue Gerät fragt den Stand alle zwei Sekunden ab. Ein Funkloch oder eine kurzzeitige Sperre des Servers beendet die Kopplung nicht — der Client wartet dann länger zwischen zwei Abfragen. Erst wenn die fünf Minuten um sind, ist Schluss.

Der Code wandert per Zwischenablage von einem Gerät zum anderen — unter Windows wie auf dem Telefon, dort wahlweise über das Teilen-Blatt.

Kamera und QR-Scan sind noch nicht eingebaut. Die Kodierung steht und wird gelesen; was fehlt, ist das Scannen. Sicherheitlich ändert das nichts: Der Code enthält kein Geheimnis, der Schutz ist der Ziffernvergleich. Es ist Bequemlichkeit, die fehlt, nicht Härte.

Entziehen

Ein Entzug allein bewirkt fast nichts. Das entzogene Gerät hat den Vault Key längst lokal und kann alles weiter entschlüsseln, was es schon hat.

Deshalb steht nach einem Entzug ein roter Balken über der Geräteliste, bis rotiert wurde. Der Token des entzogenen Geräts ist sofort tot.

Epoch-Rotation

Die Rotation ist das, was den Entzug wirksam macht:

Vollständig synchronisieren — was der Client nicht kennt, würde die Rotation überschreiben.
Neuen Vault Key erzeugen und für jedes verbliebene Gerät wrappen.
Alle Datensätze einsammeln (inklusive Grabsteine) und mit dem neuen Schlüssel verschlüsseln.
Den Wiederherstellungs-Blob neu bilden.
Alles in einem Aufruf hochladen.

Der Server nimmt das nur an, wenn die Epoch genau um eins steigt, jedes vorhandene Gerät einen neuen Wrap mitbringt und jeder gespeicherte Datensatz neu verschlüsselt mitkommt. Angewendet wird in einer einzigen Transaktion — ein Mischzustand über Epoch-Grenzen kann nicht entstehen.

Die erreichbare Zusicherung, ehrlich benannt: Das entzogene Gerät kennt den alten Schlüssel weiterhin und kann alte, mitgeschnittene Ciphertexte weiterhin öffnen. Neue Daten sieht es nicht mehr. Vergangenheit lässt sich nicht zurückholen.

Wiederherstellungscode

Bei einem passwortlosen System ist er der einzige Rückfall: 256 Bit Zufall in Crockford-Base32, 52 Zeichen in 13 Gruppen zu vier. Crockford, weil I/l/1 und O/0 dort nicht unterscheidbar sein müssen — der Code wird abgeschrieben.

Aus ihm wird über Argon2id ein Schlüssel abgeleitet, daraus getrennt ein Beweis- und ein Verschlüsselungsschlüssel. Der Server kennt nur einen Hash des Beweisschlüssels.

Der Client fragt die KDF-Parameter ab und rechnet den Beweis.
Erst nach dem Beweis gibt der Server den verschlüsselten Blob heraus. Ohne diesen Schritt könnte jeder, der eine Konto-ID kennt, den Blob herunterladen und offline dagegen rechnen.
Der Client öffnet den Vault Key, erzeugt Geräteschlüssel und meldet sich mit einem einmaligen, zehn Minuten gültigen Ticket als neues Gerät an.
Danach muss rotiert werden. Die verlorenen Geräte kennen den alten Schlüssel weiterhin. Der Server kann die Rotation nicht erzwingen — der Client muss sie tun.

Fünf Fehlversuche pro Konto und Stunde, dann Sperre. Bei einer Rotation wird der Code neu erzeugt: Der alte wrappte den alten Schlüssel und gilt danach nicht mehr. Er erscheint genau einmal.

Die Kontokennung gehört dazu

Das Wiederherstellen fragt nach drei Angaben: Serveradresse, Kontokennung und Recovery-Code. Die Kontokennung ist kein Geheimnis — der Server gibt ohne den Beweis aus dem Code nichts heraus —, aber ohne sie kommt man nicht weiter.

Sie steht an zwei Stellen:

Im Dialog, der den Recovery-Code zeigt — beim Anlegen des Kontos und nach jeder Rotation. Beides steht dort nebeneinander und wird zusammen weggelegt.
Über der Geräteliste, mit Kopierknopf.

Beides notieren, nicht nur den Code. Die Geräteliste setzt ein angemeldetes Gerät voraus. Genau das fehlt in dem Fall, für den der Recovery-Code da ist — dann gibt es keinen Ort mehr, an dem die Kennung steht.

Geräteliste

Sie zeigt Name, Epoch, Anlagezeitpunkt und den letzten Kontakt — keine Schlüssel, keine Wraps. Das eigene Gerät ist markiert; es lässt sich nicht selbst entziehen, und das letzte verbliebene auch nicht.

Über der Liste steht die Kontokennung des Kontos, an dem die Geräte hängen — zum Kopieren und Abschreiben.