VENTEX Connect / Sicherheit

Vertrauen braucht
einen Beleg.

Wir beschreiben Sicherheit nicht als absoluten Zustand. Wir zerlegen sie in überprüfbare Schichten, dokumentierte Grenzen und reproduzierbare Nachweise.

AVAILABLE NOW · CONTROLLED RELEASEMessbare Architektur statt pauschaler Versprechen
01E2EEInhaltsebene
0215mKurzlebiges Access Token
03PQHybrider Sitzungsaufbau
041×Refresh-Token-Rotation
VENTEX / PUBLIC EVIDENCEProduktclaims mit Prüfpfad
CRY-04Der Fassung-3-Pfad nutzt für fähige Geräte einen hybriden PQXDH-Sitzungsaufbau aus X25519 und ML-KEM-1024; das abgeleitete Geheimnis wird Wurzelschlüssel des Double Ratchet.Intern nachgewiesen
Prüfbasis

Automatisierte Krypto- und Schlüsseldienstprüfungen, 308 zugeordnete Bruchproben, 19 reale Browser-Durchgänge mit 189 Prüfungen, Mehrgeräte- und Downgrade-Szenarien, einmalige PreKey-Vergabe sowie ein kontrollierter Produktionsdurchstich am 6. September 2026; erneut nachgefahren am 9. September 2026.

Bewusste Grenze

Der Post-Quantum-Anteil schützt den Sitzungsaufbau, nicht einen fortlaufend post-quanten-sicheren Ratchet. Der Rollout ist geräteabhängig und bislang nicht unabhängig extern auditiert.

Vollständigen Nachweis öffnen
IAM-02Refresh Tokens rotieren und Wiederverwendung widerruft die betroffene Token-Familie.Intern nachgewiesen
Prüfbasis

Sitzungslogik und automatisierte Reuse-/Widerrufstests.

Bewusste Grenze

Ein bereits kompromittiertes, entsperrtes Gerät bleibt ein eigenes Risiko.

Vollständigen Nachweis öffnen
META-03Direkte Identifikatoren wurden aus mehreren gespeicherten Kommunikationspfaden entfernt oder durch opake, unterhaltungsbezogene Referenzen ersetzt.Intern nachgewiesen
Prüfbasis

Keine senderId in Nachrichtenzeilen, signierte Autorenschaft im Chiffrat, HMAC-Direktchatwerte, Empfängermarken statt Geräte-ID in Schlüsselumschlägen, memberRef für Reaktionen, Favoriten und Mentions sowie neue Lesestände ohne neue Receipt-Zeilen. Im aktuellen Quell-/Prüfstand stellt der Kaltstartpfad das Kennungsverzeichnis aus dem verschlüsselten Kontozustand her und wertet eine leere Beweismenge nicht als Erfolg. Verlaufsübergaben verwenden dort eine einmal berechnete opake Zielmarke und überspringen ältere unmarkierte Umschläge statt ihre Zuordnung zu erraten.

Bewusste Grenze

Der laufende Dienst benötigt für Autorisierung und Zustellung weiterhin begrenzte Konto-, Beziehungs- und technische Metadaten. Die live signierte Laufzeit wurde in diesem Website-Auftrag nicht aktualisiert; neue Kaltstart- und Verlaufsübergabe-Korrekturen gelten dort erst nach getrenntem App-Release und Migration. Historische Zeit-/Geräteverweise und aufbewahrte Sicherheitsdaten bleiben bis zur vorgesehenen Aktualisierung oder Bereinigung sichtbar. Metadatenminimierung ist keine Metadatenfreiheit.

Vollständigen Nachweis öffnen
01

Geräte statt bloßer Passwörter

Jede Installation besitzt eine eigene kryptografische Identität. Signaturschlüssel bleiben nicht exportierbar. Austauschschlüssel werden bevorzugt als nicht exportierbare CryptoKey-Objekte gehalten; wo iOS/WebKit diese nicht zuverlässig persistiert, nutzt der Client einen dokumentierten JWK-Rückfall und migriert später zurück. Neue Geräte werden sichtbar und können gezielt verifiziert oder entfernt werden.

  • Gerätegebundene Schlüssel
  • Safety Number und strikte Verifikation
  • Gezielter Geräteentzug
02

Sitzungen mit Ablaufdatum

Kurzlebige Access Tokens werden durch rotierende Refresh Tokens ergänzt. Wird ein bereits verwendetes Refresh Token erneut präsentiert, sperrt das System die gesamte Sitzungsfamilie statt still weiterzumachen. Ein Gerätewiderruf beendet zugehörige Sitzungen und Push-Abonnements; beim nächsten geeigneten Anmeldepfad baut der Client kontobezogenen lokalen Sicherheitszustand gezielt ab.

  • Hash-basierte Token-Persistenz
  • Login-Historie
  • Globaler und gerätebezogener Widerruf
03

Hybrider Post-Quantum-Schutz für neue Sitzungen

Seit dem 6. September 2026 nutzt der kontrollierte Fassung-3-Pfad bei fähigen Gerätepaaren einen hybriden PQXDH-Sitzungsaufbau: X25519 wird mit ML-KEM-1024 kombiniert, das resultierende Geheimnis speist ausschließlich den Double Ratchet. Einmal-PreKeys, signierte PreKeys und eine gerätepaarbezogene Downgrade-Sperre begrenzen Wiederverwendung und stillen Rückfall. Unterhaltungen mit noch nicht fähigen Geräten bleiben auf einem sichtbar dokumentierten, versionierten Kompatibilitätspfad.

  • X25519 + ML-KEM-1024 im hybriden PQXDH-Aufbau
  • Double Ratchet für den fortlaufenden Nachrichtenschutz
  • Kontrollierter Rollout mit Downgrade-Sperre je Gerätepaar
04

Weniger zuordenbare Metadaten im Ruhezustand

Der aktuelle Ausbau entkoppelt Identität und Kommunikationsdaten: Nachrichten speichern keine Absender-ID mehr, Autorenschaft liegt signiert im verschlüsselten Inhalt; Direktchat-Schlüssel sind serverseitig HMAC-abgeleitet; Schlüsselumschläge speichern statt der Geräte-ID eine opake Empfängermarke; Reaktionen, Favoriten und Mentions arbeiten mit unterhaltungsbezogenen Mitgliedsreferenzen. Verdeckte Mitgliedskennungen werden an Besitznachweise gebunden, versiegelte Mitgliedsnamen und verschlüsselte Kontoeinstellungen reduzieren weiteren Klartext. Neue Lesestände entstehen ohne einzelne Receipt-Zeilen, betroffene Zeitfelder werden auf Minutenebene begrenzt und Realtime-Ausgaben auf den öffentlichen Vertrag reduziert. Lokale Entwürfe, UI-Merkwerte und Sicherheitsverifikation sind kontobezogen. Die Mitgliedschaftstabelle enthält für Autorisierung und Übergang weiterhin eine Kontokennung, der primäre Anzeigename bleibt beim Konto gespeichert und alte Receipt-Zeilen verbleiben bis zum Ablauf der Aufbewahrung – diese Grenzen werden ausdrücklich veröffentlicht.

  • Signierte Autorenschaft im Chiffrat
  • Opake, unterhaltungsbezogene Referenzen
  • Keine Behauptung eines metadatenfreien Dienstes
05

Verifizierbare Auslieferung

Der Web-Release wird außerhalb des Servers signiert. Ein unabhängiger Nachbau vergleicht jede ausgelieferte Datei bytegleich; der Service Worker prüft das signierte Manifest, bevor er Ressourcen in seinen Cache übernimmt.

  • Reproduzierbare Builds
  • Signiertes Release-Manifest
  • Öffentlicher Schlüssel über DNS gebunden
Alle Funktionen

Sicherheitsmodell und Geräteschutz / Capability matrix

01

Passkeys

Zusätzliche Anmeldung mit Plattform- oder Hardware-Schlüssel.

02

Panikmodus

Lokale Daten und aktive Sitzungen kontrolliert beseitigen.

03

Zwangspasswort

Unauffälliger Zugangspfad mit Sitzungswiderruf.

04

CSP

Strenge Script- und Netzwerkziele begrenzen eingeschleusten Code.

05

Private Ablage

Kurzlebige signierte Objekt-URLs statt öffentlicher Dateien.

06

Integritätswache

Produktionsdateien und Betriebsskripte fortlaufend messen.

07

Sicherheitsnummern

Schlüsseländerungen sichtbar machen und unbestätigte Geräte optional blockieren.

08

Verlaufsschutz

Lokale Historie und Ratchet-Zustand kontogebunden verschlüsseln.

09

Kontrollierte Protokollprüfung

Signal-inspirierte Architektur, eigenständige Implementierung; Detailunterlagen nur im ausdrücklich vereinbarten Review- oder Auditumfang unter Vertraulichkeit.

“Ein grüner Test ist nur so stark wie die Regel, die er tatsächlich prüft.”

VENTEX Sicherheitsgrundsatz

Nächstes KapitelMission Rooms für operative Teams
VENTEX CONNECT / CONTROLLED ACCESS

Sicherheitsarchitektur ohne Nebelkerzen.

Grenzen, Nachweise und offene Audit-Aufgaben werden ausdrücklich dokumentiert.

Erstgespräch anfragen20 Minuten · unverbindlichConnect öffnen