Bedrohungsmodell
Bedrohungsmodell
Ein Sicherheits-Tool ohne klares Bedrohungsmodell ist ein Werbeversprechen. Hier steht, was Hokono schützt, gegen wen, was du dafür voraussetzen musst — und was es ausdrücklich nicht leistet. Wenn du auf Basis deines eigenen Bedrohungsmodells entscheidest: Diese Seite ist die Grundlage.
Was Hokono schützt
- Gesprächs- und Nachrichteninhalt — Ende-zu-Ende, post-quanten-sicher (Hybrid X25519 + ML-KEM-768; Signatur Ed25519 + ML-DSA-65). Forward Secrecy über den Double Ratchet: kompromittierte Schlüssel geben vergangene/künftige Nachrichten nicht preis.
- „Jetzt speichern, später entschlüsseln" — der post-quanten-Hybrid soll heute abgegriffenen Verkehr auch gegen künftige Quantencomputer schützen.
- Identität ohne Kennung — keine Telefonnummer, kein Konto, keine E-Mail. Kontakte werden per QR-Pairing out-of-band verknüpft (mit Safety-Number-Abgleich gegen Man-in-the-Middle).
- Verkehrsmetadaten — Wer-mit-wem/wann wird durch ein Sphinx-Mixnet verschleiert (konstante Paketgröße, drei Hops, jeder Knoten kennt nur den nächsten), statt offen beobachtbar zu sein. Während eines Telefonats sendet die App zusätzlich mit konstanter Rate und füllt Pausen mit Füllverkehr, sodass Gesprächsbeginn, -ende und -rhythmus verdeckt sind. (Wichtige Grenzen: außerhalb von Anrufen läuft kein Füllverkehr, und die Knoten verzögern derzeit nicht — Details unter „Was Hokono ausdrücklich NICHT leistet".)
- Serverseitige Spurenlosigkeit — die Produktionsserver laufen log-frei (keine Inhalte, keine IPs, keine Verbindungsdaten).
Angreifer, gegen die Hokono zielt
- Passiver Netzbeobachter / Massenüberwachung entlang der Leitung (ISP, Backbone, WLAN).
- Zukünftiger Quanten-Angreifer, der heute Abgegriffenes später entschlüsseln will.
- Neugieriger einzelner Knoten im Mixnet — ein einzelner Hop lernt weder Absender noch Ziel noch Inhalt.
- Teilweise der Server-Betreiber — durch No-Logs und (perspektivisch) verteilte, unabhängige Betreiber.
Was du voraussetzen musst (Vertrauensannahmen)
- Dein Endgerät ist nicht kompromittiert. Malware, ein Trojaner oder ein entsperrtes Gerät in fremder Hand lesen alles vor der Verschlüsselung. Kein Transport-Schutz hilft dagegen.
- Der Code, den du liest, ist der, der läuft. Hokono ist quelloffen; die Server-Binaries bauen reproduzierbar (Stufe 1: derselbe Commit → byte-identisches Binary, im CI geprüft), sodass du einen Knoten gegen den Quellcode nachprüfen kannst. Noch nicht lückenlos: veröffentlichte Soll-Hashes je Release und eine Digest-gepinnte Toolchain sind in Arbeit; die iOS-App ist wegen App-Store-Signierung nicht bit-reproduzierbar.
- Betriebssystem und Hardware (Secure Enclave, Krypto-Bibliotheken) tun, was sie sollen.
- Bis zur Föderation: der Betreiber (wir). Solange die Knoten bei uns laufen, musst du uns vertrauen, dass wir nicht mehr korrelieren, als das Modell erlaubt. Das ist eine Annahme, die wir abbauen wollen (siehe unten).
- Für den Anruf-Weckruf: Apple (außer im Hochsicherheitsmodus).
Was Hokono ausdrücklich NICHT leistet (Stand heute)
- Schutz eines kompromittierten Endgeräts. Siehe oben — das ist außerhalb der Reichweite jeder Transport-Kryptografie.
- Anonymität gegenüber einem Betreiber, der ALLE Knoten kontrolliert. Aktuell laufen Eintritts-Relays, Gateway und Push-Dienst im selben Konto von uns. Wer alles kontrolliert, kann mehr korrelieren, als das Mixnet-Modell verspricht. Echte IP-/Metadaten-Blindheit setzt einen unabhängigen Vor-Hop voraus, der nicht mit dem Gateway-Betreiber kolludiert — das ist Roadmap.
- Schutz vor Traffic-Confirmation, wenn ein Angreifer gleichzeitig Ein- und Austritt beobachtet oder kontrolliert. Mixnets erschweren das, aber ein globaler aktiver Angreifer bleibt ein hartes Problem — besonders bei kleinem Anonymitäts-Set.
- Zeitliche Unverkettbarkeit gegen einen globalen Beobachter — heute für allen Verkehr, nicht nur für Sprache. Echtzeit-Telefonie verträgt keine Misch-Verzögerung an jedem Knoten. Deshalb läuft im Betrieb derzeit gar keine Per-Hop-Verzögerung — auch nicht für Nachrichten, die sie vertragen würden. Wer das gesamte Netz gleichzeitig beobachtet, kann Sender und Empfänger am Zeitverlauf verketten; die Onion-Verschlüsselung verbirgt Inhalt und nächsten Knoten, nicht das Timing. Der Code für Poisson-Mischen ist in den Knoten vorhanden, aber abgeschaltet. Beides getrennt zu fahren — Sprache niedriglatent, Nachrichten gemischt — ist eine offene Aufgabe, keine erledigte. Wirksames Mischen braucht zudem Verkehrsvolumen + unabhängige Betreiber; ein optionaler Hochsicherheits-Anrufmodus mit Zusatz-Verzögerung steht auf der Roadmap.
- Verbergen, wann du eine Nachricht sendest. Füllverkehr läuft nur während eines Telefonats. Außerhalb davon sendet die App nichts von sich aus — ein Beobachter auf deiner Leitung sieht daher den Zeitpunkt deiner Nachricht (nicht Empfänger, nicht Inhalt).
- Verbergen, dass du Hokono nutzt. Die Verbindung zum Eintrittspunkt ist heute unverschleiert; ein Beobachter auf deiner Leitung (ISP, WLAN, Staat) kann an Zieladresse und Paketmuster erkennen, dass Hokono läuft — nicht was gesprochen/geschrieben wird. Tarnung (TLS/Pluggable-Transport) ist eine bewusst benannte offene Grenze auf der Roadmap.
- Verbergen, dass dein iPhone gerufen wird. Damit es zuverlässig klingelt, geht ein Apple-Push. Apple und unser Push-Dienst sehen Empfänger + Zeitpunkt (nicht den Anrufer — der Auslöser läuft anonym durchs Mixnet — und nie den Inhalt). Der Hochsicherheitsmodus verzichtet auf Push und vermeidet auch das (die App muss dann laufen).
- Schutz vor rechtlichem Zwang gegen den Betreiber. No-Logs bedeutet, dass wenig herauszugeben ist — aber ein Betreiber existiert und unterliegt einer Jurisdiktion.
- Große Anonymität bei kleinem Nutzerkreis. Anonymität ist eine Eigenschaft der Menge. Zum Start ist diese Menge klein.
- Auditierte Garantien. Hokono ist noch nicht unabhängig auditiert. Bis dahin: nicht für lebenskritische Bedrohungsmodelle verlassen.
Einordnung (ehrlich)
Wir stehen auf den Schultern von Signal (Double Ratchet), der NIST-PQ-Standardisierung und der Mixnet-Forschung (Sphinx, Loopix). Signal ist reifer und breiter auditiert, schützt Metadaten aber anders (kein Mixnet). Tor hat ein weit größeres Anonymitäts-Set. Hokono verbindet Post-Quanten-Ende-zu-Ende + Mixnet + Wecken ohne Telefonnummer — und ist dabei jünger und kleiner. Das ist kein Ersatz-Versprechen, sondern ein anderer Punkt im Trade-off-Raum.
Was diese Grenzen abbaut
- Unabhängige Betreiber für Eintritts-Relays und ein schwellenwert-signiertes Directory, in getrennten Jurisdiktionen — der eigentliche Metadaten-Schutz.
- Externes Audit (Krypto-Kern zuerst, dann Infrastruktur).
- Android/GrapheneOS für Weck-Anonymität ohne Push-Dienst im Weg.
Etwas übersehen oder falsch dargestellt? Sag es uns — wir räumen berechtigte Punkte öffentlich ein.