EB5X

Was ist EB5X?

EB5X ist die geschützte Kommunikationsschicht hinter AC Sentinel Systems, AC CoreX und weiteren dafür vorgesehenen Komponenten. Anwendungen kümmern sich darum, was sie übertragen möchten – EB5X darum, dass es geschützt ankommt.

Einrichten. Verbinden. Fertig.

Neue Teilnehmer werden über einen zeitlich begrenzten Einmaltoken mit der vorgesehenen Gegenstelle bekannt gemacht und erhalten anschließend ihre eigene kryptographische Identität. Steht der geschützte Kommunikationsweg, kann darauf aufbauende Kommunikation denselben Pfad verwenden, ohne für jedes neue Feature weitere öffentlich erreichbare Dienste schaffen zu müssen.

Der Tunnel steht. Wir sahen keinen Grund, daneben noch ein Loch in die Firewall zu bohren.

Klassisch + Post-Quantum

Die aktuelle hybride Suite 0x03 kombiniert klassische Kryptographie mit ML-KEM-768 als Post-Quantum-Komponente. EB5X verlässt sich damit bewusst nicht ausschließlich auf einen einzelnen kryptographischen Mechanismus.

Science-Fiction löst das gelegentlich mit einem „fraktalen Verschlüsselungscode“. EB5X musste leider mit realer Kryptographie auskommen.

---

Ab hier wird es technisch.

Die Kurzfassung endet hier. Nachfolgend beschreiben wir Konstruktion, Sicherheitsannahmen, Schlüsselableitung, Rekeying, Transportsemantik, Testvektoren und Implementierungsgrenzen.

Wenn Sie lediglich wissen wollten, ob EB5X Daten sicher von A nach B transportieren soll: ja.

Wenn Sie wissen möchten, warum wir glauben, dass es das tut: weiterlesen.

1. Protokollfamilie und Suites

EB5X trennt die Protokollversionierung von der verwendeten kryptographischen Suite. Der Binärtransport verwendet derzeit ein Major-Byte 0x01; die kryptographische Variante wird separat über die Suite-ID ausgewählt.

• 0x00 – Legacy- und Kompatibilitätspfad auf Basis statischer X25519-Schlüssel. Dieser Pfad bleibt für bestehende Teilnehmer verfügbar, besitzt jedoch keine Forward Secrecy.
• 0x02 – Noise-KK mit ephemerem X25519 und XChaCha20-Poly1305 für den Session-Transport.
• 0x03 – Hybrid-Suite aus X25519, Noise-KK und ML-KEM-768. Der anschließende Transport folgt demselben Grundmodell wie bei 0x02.

Hybridfähige Teilnehmer können beispielsweise [3, 2, 0] anbieten. Aus den tatsächlich von beiden Seiten unterstützten Suites wird die höchste gemeinsame Suite gewählt.

EB5X akzeptiert dabei keinen stillen kryptographischen Downgrade. Wird nach dem Handshake eine niedrigere Suite ausgewählt, obwohl beide Seiten eine stärkere gemeinsame Suite angegeben haben, wird die Session nicht akzeptiert.

Kompatibilität darf nach unten gehen. Sicherheit nicht heimlich.

2. Identität vor Session

Bevor eine Session entstehen kann, müssen die beteiligten Systeme wissen, mit wem sie sprechen. EB5X trennt deshalb langfristige kryptographische Identitäten von den später verwendeten Session-Schlüsseln.

Ein Peer besitzt eine eigene statische X25519-Identität. ACSS besitzt ebenfalls X25519-Schlüsselmaterial und zusätzlich eine Ed25519-Identität für signierte Bootstrap-Informationen.

Die statischen Public Keys werden beim Pairing bekannt gemacht und anschließend als Identitätsanker verwendet. Die eigentlichen Session-Suites 0x02 und 0x03 erzeugen darüber hinaus frisches ephemeres Schlüsselmaterial.

Damit ist die kryptographische Identität eines Teilnehmers nicht dasselbe wie der Schlüssel einer einzelnen Session.

Personalausweis und Hotelzimmerschlüssel erfüllen schließlich auch unterschiedliche Aufgaben.

3. Bootstrap und Pairing

Ein neuer Teilnehmer erhält zunächst einen Pairing-Token. Dieser enthält die Informationen, die für den kontrollierten Bootstrap benötigt werden: unter anderem den vorgesehenen ACSS-Endpunkt, öffentliche kryptographische Schlüssel, Instanzinformationen, eine Pairing-Nonce, eine Ablaufzeit und einen Authority-Fingerprint.

Der Token wird kryptographisch signiert und anschließend als Base64 übertragen. Die Signatur schützt seine Authentizität und Integrität; Base64 ist dabei lediglich eine Transportdarstellung.

Base64 ist keine Verschlüsselung. Wir wissen das.

Der Bootstrap kennt darüber hinaus einen Authority-Fingerprint sowie einen Short Authentication String, der aus Authority-Schlüssel, Peer-Identität und Pairing-Nonce abgeleitet werden kann.

Pairing-Tokens sind zeitlich begrenzt und für die einmalige Aufnahme eines Teilnehmers vorgesehen. Nach erfolgreichem Pairing besitzt der Peer seine eigene Identität und benötigt den Bootstrap-Token nicht als dauerhafte Sitzungsberechtigung.

Der Token stellt die beiden vor. Er zieht nicht mit ein.

4. Suite 0x02 – Forward Secrecy

Suite 0x02 verwendet das Noise-Pattern Noise_KK_25519_ChaChaPoly_SHA256. Beide statischen Public Keys sind durch das vorherige Pairing bereits bekannt; sie müssen deshalb nicht während jedes Handshakes erneut übertragen werden.

Für eine neue Session erzeugen beide Seiten zusätzliche ephemere X25519-Schlüssel. Der zweistufige Handshake verarbeitet die für Noise-KK vorgesehenen DH-Kombinationen und bindet die Negotiationsdaten in den authentifizierten Transcript-Zustand ein.

Nach Abschluss des Handshakes entstehen zwei getrennte Transport-Schlüssel: einer für Initiator → Responder und einer für Responder → Initiator.

Forward Secrecy soll dafür sorgen, dass eine spätere Kompromittierung der langfristigen statischen Identität nicht automatisch vergangene abgeschlossene Sessions offenlegt.

Sie schützt allerdings nicht magisch einen Session-Key, der während einer laufenden Session bereits kompromittiert wurde.

Kryptographie kann viel. Zeitreisen gehören noch nicht zum Interface.

5. Suite 0x03 – Hybrid Post-Quantum

Suite 0x03 erweitert den klassischen Noise-KK-Aufbau um ML-KEM-768. Der Protokollname lautet:

Noise_KKhybrid_25519+MLKEM768_ChaChaPoly_SHA256

Der Initiator erzeugt neben seinem ephemeren X25519-Material ein ephemeres ML-KEM-768-Keypair. Der ML-KEM Public Key wird in den Handshake eingebracht und in den Transcript-Zustand gebunden.

Der Responder kapselt dagegen ein Post-Quantum Shared Secret und sendet den daraus entstandenen ML-KEM-Ciphertext zurück. Beide Seiten gelangen anschließend zum selben Post-Quantum Shared Secret, das in den kryptographischen Chaining-Zustand des Handshakes einfließt.

Die Hybridisierung ersetzt X25519 damit nicht. Beide Mechanismen gehören zur Konstruktion derselben Session.

Die mathematischen Annahmen hinter klassischer elliptischer Kryptographie und ML-KEM sind verschieden. Genau deshalb ist die Kombination interessant.

Panik ist kein Parameter der KDF.

6. Transcript und Suite-Negotiation

Eine Suite-Liste wäre wenig wert, wenn ein Dritter sie auf dem Transportweg einfach verändern könnte. Deshalb behandelt EB5X die Negotiation nicht als unverbindliche Metainformation außerhalb des Handshakes.

Die angebotenen Suites und die gewählte Suite werden kryptographisch in den Handshake eingebunden. Der Initiator überprüft nach Abschluss, ob die Antwort tatsächlich die höchste gemeinsame Suite darstellt.

Wird diese Bedingung verletzt, wird die Session nicht als gültiger kryptographischer Kontext übernommen.

„Aber die andere Suite hätte doch auch funktioniert“ ist kein Downgrade-Schutz.

7. Transport

Nach erfolgreichem Handshake verwenden die Session-Suites XChaCha20-Poly1305 für den eigentlichen Nachrichtentransport. Beide Kommunikationsrichtungen besitzen getrennte Schlüssel.

Ein Transportframe enthält unter anderem Major-Version, Suite, Frame-Typ, Session-ID und einen monotonen Counter. Diese Headerinformationen werden als Additional Authenticated Data in die AEAD-Operation eingebunden.

[ major ][ suite ][ frame_type ][ session_id ][ counter ][ ciphertext || tag ]

Damit werden kryptographischer Inhalt und relevanter Session-Kontext gemeinsam authentifiziert.

Für die XChaCha20-Poly1305-Nonce wird der Counter in ein fest definiertes 24-Byte-Format eingebettet. Da jede Session und jede Richtung einen eigenen Schlüssel besitzt und der Counter monoton geführt wird, soll eine Nonce-Wiederverwendung innerhalb desselben Schlüsselkontextes verhindert werden.

Déjà-vu ist hier kein Feature.

8. Replay und Reihenfolge

Die Session-Suites verwenden pro Kommunikationsrichtung ein Sliding Window. Neue Counter können akzeptiert werden; bereits verarbeitete oder ausreichend weit zurückliegende Counter werden abgelehnt.

Dadurch muss eine Nachricht nicht allein deshalb erneut als neu gelten, weil jemand dieselben Bytes ein zweites Mal auf den Draht legt.

Beim zweiten Mal wird die Geschichte nicht glaubwürdiger.

9. Rekeying

Session-Schlüssel besitzen in EB5X keinen unbegrenzten Lebenszyklus. Eine Session muss erneuert werden, sobald mindestens eine der definierten Grenzen erreicht wird.

• 24 Stunden Session-Laufzeit
• 1 GiB verarbeitete Nutzlast
• 1.048.576 Nachrichten
• Erreichen der vorgesehenen Counter-Grenze

Rekey bedeutet dabei nicht lediglich, denselben symmetrischen Schlüssel intern ein Stück weiterzudrehen.

Es entsteht ein vollständiger neuer Handshake mit neuer Session-ID, neuem ephemerem X25519-Material und – bei Suite 0x03 – ebenfalls neuem ML-KEM-Material.

Nach einem erfolgreichen Rekey wird der vorherige Schlüsselkontext nicht als alternative Rückfallposition weitergeführt. Ein abgeschlossener kryptographischer Zustand bleibt abgeschlossen.

Für RimWorld-Spieler: „Laden nicht erlaubt“.

Für alle anderen: Es gibt keinen Spielstand.

10. Session-Persistenz

Aktive Session-Zustände können gespeichert werden, damit eine Anwendung nicht bei jedem Prozesswechsel ihre kryptographische Session vergessen muss. Persistiert werden unter anderem Session-ID, Suite, Richtungsschlüssel, Counter, Replay-Zustand und Ablaufzeit.

Diese Daten werden nicht als Klartext-JSON abgelegt. Der Session-Store verschlüsselt den gespeicherten Zustand mit einem separaten Master-Key. Beim Ersetzen einer Session werden die alten Sessionobjekte verworfen und das darin gehaltene Schlüsselmaterial soweit im jeweiligen Laufzeitmodell möglich überschrieben.

Wichtig bleibt die Grenze des Modells: Forward Secrecy schützt abgeschlossene vergangene Sessions nicht automatisch vor einer Kompromittierung des gerade aktiven, im Arbeitsspeicher vorhandenen Session-Zustands.

Wenn der Angreifer bereits den laufenden vertrauenswürdigen Endpunkt kontrolliert, diskutieren wir inzwischen einen anderen Incident.

11. Canonical CBOR

Handshake-Frames und Negotiationsdaten verwenden ein bewusst eingeschränktes Canonical-CBOR-Profil.

Map-Keys sind kleine unsigned Integer, Längen werden deterministisch kodiert, überlange Integer-Repräsentationen sind nicht erlaubt und Map-Keys müssen eindeutig sowie streng sortiert sein.

Der Grund dafür ist nicht ästhetischer Natur: zwei Implementierungen sollen dieselbe logische Struktur nicht in unterschiedlich interpretierbare Bytefolgen verwandeln.

„Im Prinzip dasselbe“ ist bei einem kryptographischen Transcript eine ausgesprochen schlechte Maßeinheit.

12. Deterministische Testvektoren

EB5X besitzt reproduzierbare Known-Answer-Testvektoren für Bootstrap, klassische Session-Suites und den Hybrid-PQC-Pfad.

Dabei wird nicht nur geprüft, ob am Ende zufällig eine Nachricht geöffnet werden kann. Definierte Zwischen- und Endwerte werden reproduziert und bytegenau verglichen.

Für Suite 0x03 gehören dazu unter anderem:

• Canonical-CBOR-Payloads
• Transcript Hashes
• ML-KEM Public Key
• ML-KEM Ciphertext
• Post-Quantum Shared Secret
• finaler Chaining Key
• Initiator → Responder Key
• Responder → Initiator Key
• vollständige Transportframes

Eine Spezifikation ist schön. Dieselben Bytes sind schöner.

13. Mehrere Implementierungen. Eine Erwartung.

Die vorhandenen Verifier reproduzieren dieselben Referenzwerte in unterschiedlichen Implementierungen.

Der PHP-Verifier für 0x03 bindet dabei die produktiven Kryptographieklassen ein und reproduziert gegen dieselbe Vektordatei unter anderem ML-KEM, Hybrid-Handshake, Schlüsselableitung und Transport. Python führt dieselben definierten Zustände gegen die Referenzwerte aus. Die Architektur sieht dieselbe gemeinsame Vektorbasis auch für Go vor.

Unterschiede in Programmiersprache, Bibliothek oder interner Architektur sind zulässig.

Unterschiede im spezifizierten Ergebnis nicht.

PHP, Python und Go müssen sich nicht mögen. Sie müssen dieselben Bytes verstehen.

14. Negative Testvektoren

Ein Sicherheitsprotokoll wird nicht vollständig dadurch beschrieben, welche Eingaben funktionieren.

Ebenso wichtig ist, welche Eingaben ausdrücklich scheitern müssen. Die vorhandenen EB5X-Vektoren prüfen deshalb auch definierte Negativfälle.

Dazu gehören beispielsweise:

• manipulierte Suite-Informationen
• falsche statische Identitäten
• wiederholte Counter
• unbekannte Frame-Typen
• Suite-Mismatches
• fehlendes ML-KEM-Material
• ML-KEM-Ciphertexts falscher Länge
• manipuliertes ML-KEM Public-Key-Material
• abweichende ML-KEM-Decapsulation
• manipulierte Bootstrap-Tokens
• abgelaufene Bootstrap-Tokens
• ungültige Authority-Rotationen

Die jeweiligen Fehlerpfade besitzen definierte Reason-Codes. Die Implementierung soll ungültige Zustände nicht heuristisch reparieren.

Teilpunkte werden nicht vergeben.

15. Fail closed

Kann ein kryptographischer Zustand nicht ausreichend validiert werden, wird er nicht durch Optimismus in einen gültigen Zustand verwandelt.

Auch die Testinfrastruktur folgt diesem Grundsatz: fehlen notwendige Vektordaten oder die benötigte kryptographische Implementierung, darf die betreffende Krypto-Prüfung nicht einfach als erfolgreich gelten.

Optimismus ist eine menschliche Eigenschaft, keine Protokollfunktion.

16. Was EB5X nicht behauptet

Deterministische Testvektoren, mehrere Implementierungen und eine sauber definierte Protokollmaschine sind wichtige Evidenz. Sie sind kein formaler Beweis dafür, dass keinerlei Schwäche existiert.

EB5X ersetzt insbesondere keine Host-Härtung, keine sichere Verwaltung des Betriebssystems und keine Absicherung der Anwendung oberhalb des Protokolls.

Ebenso folgt aus einer mathematisch plausiblen Konstruktion nicht automatisch, dass jede konkrete Hardware- oder Laufzeitumgebung gegen sämtliche Side Channels resistent ist.

Die Mathematik kann schweigen, während die Hardware plappert.

Aus diesem Grund unterscheiden wir bewusst zwischen:

• konstruktiv beabsichtigt,
• implementiert,
• durch reproduzierbare Tests belegt und
• unabhängig geprüft.

Diese vier Dinge sind nicht dasselbe.

Bekannte Grenzen werden durch kleinere Schrift nicht sicherer.

17. FAULTLINE Cryptographic Assessment

Hier erscheint in Kürze unser internes FAULTLINE Assessment.

Vorgesehen ist eine strukturierte interne Betrachtung von Konstruktion, Protokollzuständen, Negativfällen, Implementierungsgrenzen und Cross-Implementation-Verifikation.

FAULTLINE ist keine unabhängige oder akkreditierte Prüfstelle. Das Assessment stellt deshalb ausdrücklich keine externe Zertifizierung dar.

Die Erfolgsquote eines selbst durchgeführten Audits besitzt naturgemäß eine gewisse institutionelle Eleganz.

Wir möchten das Ergebnis deshalb zusätzlich von Menschen überprüfen lassen, die nicht wir sind.

18. Independent Review

Ein öffentliches technisches Review von EB5X ist vorgesehen – sobald dafür eine ausdrücklich freigegebene und isolierte Audit-Umgebung bereitsteht.

Darüber hinaus möchten wir EB5X durch unabhängige externe Spezialisten prüfen lassen. Ein ernsthaftes Review von Protokollspezifikation, kryptographischer Konstruktion und Referenzimplementierungen ist allerdings keine kostenlose Dienstleistung – und das soll es auch nicht sein.

Deshalb möchten wir gezielt Mittel sammeln, um ein späteres unabhängiges professionelles Audit zu organisieren. Wie und in welchem Umfang eine solche Prüfung durchgeführt werden kann, hängt von den dafür verfügbaren Mitteln und einer geeigneten unabhängigen Prüfstelle ab.

Gesucht wird dabei kein Gütesiegel, sondern ein ernsthafter Versuch, Fehler zu finden.

Den aktuellen Stand der dafür verfügbaren Mittel und den daraus abgeleiteten möglichen Zeitrahmen für ein Audit werden wir hier künftig transparent und fortlaufend aktualisieren.

19. Wofür steht EB5X?

EB5X.

Die Bezeichnung ist ein Eigenname und kein Akronym.

Insbesondere existieren keine verschollenen Protokolle EB1X bis EB4X.

Oder doch?

```

Release: Herbst 2026