Ende-zu-Ende-Verschlüsselung mit Signal Protocol und AES-256 durchgängig
Sanket (Sanket.Chat) von Tosh Defence verschlüsselt jede Nachricht, Reaktion und verschlüsselte Rundsendung durchgehend mit dem Signal Protocol. Dafür nutzt die Plattform das offizielle, unabhängig geprüfte libsignal von Signal, den PQXDH-Schlüsselaustausch sowie Double Ratchet mit SPQR. Dateien, Anrufdaten, die Übertragung von Anrufen, lokale Datenspeicherung und jede von der Installation terminierte TLS-Verbindung verwenden AES-256, ohne Rückfall auf AES-128 und ohne Kompatibilitätsmodus.
AES-256 oder Abbruch ist die im Programmcode durchgesetzte technische Vorgabe von Sanket. Kann die Verschlüsselung nicht genau wie vorgesehen erfolgen, wird der Vorgang abgelehnt, statt die Verschlüsselung abzuschwächen.
Nachrichten: Signal Protocol, unverändert
Sanket verwendet für die gesamte Nachrichtenverschlüsselung die offizielle libsignal-Bibliothek von Signal, in derselben Version auf iOS, Android, Desktop und Server. Sie enthält weder eine Neuimplementierung des Signal Protocol noch ein alternatives Verschlüsselungsverfahren für Nachrichten.
Sitzungen werden mit PQXDH aufgebaut, der Post-Quanten-Erweiterung von X3DH, die X25519-Schlüsselvereinbarungen mit einer Kyber-Schlüsselkapselung kombiniert. Anschließend werden Nachrichten mit dem Double Ratchet verschlüsselt: Aus jedem Nachrichtenschlüssel werden ein AES-256-Schlüssel, ein HMAC-SHA256-Schlüssel und ein Initialisierungsvektor abgeleitet. Die Nachricht wird mit AES-256 verschlüsselt und mit HMAC-SHA256 authentifiziert; der Schlüssel wird nach der Verwendung gelöscht. Signal's Sparse Post-Quantum Ratchet läuft für jede Sitzung parallel.
Bewusst kein Rückfallverfahren
Ein Client verweigert den Versand, wenn die Verschlüsselung mit libsignal nicht durchgeführt werden kann. Geräte, die keinen libsignal-Identitätsschlüssel veröffentlichen, werden übersprungen, statt Nachrichten im Klartext an sie zu senden. Veraltete Klartextmarkierungen werden zurückgewiesen, und der Server lehnt Schlüsselpakete ab, die nicht dem libsignal-Format entsprechen. Für Nachrichteninhalte gibt es weder einen Klartextpfad noch einen Pfad mit einem alternativen Verschlüsselungsverfahren.
Gruppen ohne gemeinsamen Schlüssel
Gruppennachrichten werden durch paarweise Verteilung verschlüsselt: Das sendende Gerät verschlüsselt die Nachricht für jedes vertrauenswürdige Gerät jedes Mitglieds einzeln, jeweils über dessen eigene libsignal-Sitzung. Änderungen der Mitgliedschaft erfordern keinen Schlüsselaustausch; ein entferntes Mitglied wird lediglich nicht mehr bei der Verteilung berücksichtigt.
Vor der Verschlüsselung prüft ein Absender für jedes Empfängerkonto die mit dem eigenen Schlüssel dieses Kontos signierte Geräteliste und sendet nichts an Geräte, die nicht darauf stehen.
Dateien und Anrufe
Inhalte, Namen und Dateitypen von Anhängen werden auf dem Gerät mit AES-256-GCM unter Verwendung eines zufälligen 256-Bit-Schlüssels pro Datei verschlüsselt. Dieser Schlüssel wird innerhalb der libsignal-Nachricht übertragen.
Sprach- und Videodaten sind doppelt geschützt. Die Medienframes jedes Teilnehmers werden mit AES-256-GCM unter einem senderspezifischen Schlüssel Ende-zu-Ende verschlüsselt. Der Schlüssel wird alle 200 Millisekunden weiterentwickelt, sodass für jeden Sender pro Sekunde fünf neue Frame-Schlüssel entstehen. Bei jedem Beitritt und jedem Verlassen wird ein neuer Zufallsschlüssel erzeugt. Zwischen jedem Gerät und dem Medienserver lässt SRTP nur AEAD_AES_256_GCM zu. Der Medienserver leitet verschlüsselte Frames weiter, die er nicht entschlüsseln kann. Die Architektur schließt serverseitige Anrufaufzeichnungen aus.
- AES-256-GCM für jede Datei
- Anrufschlüssel pro Absender, niemals ein gemeinsamer Schlüssel für den gesamten Gesprächsraum
- Fünf Frame-Schlüssel pro Sekunde und Absender
- Ausschließlich SRTP mit AES-256-GCM
Übertragung und Speicherung
Jede Verbindung zwischen Client und Installation nutzt TLS 1.3 mit TLS_AES_256_GCM_SHA384 oder, wenn der Netzwerkprotokollstapel der Plattform es erfordert, TLS 1.2 mit ECDHE und AES-256-GCM. AES-128, ChaCha20, Verschlüsselungssuiten im CBC-Modus und statisches RSA sind ausgeschlossen; die hybride Post-Quanten-Gruppe X25519MLKEM768 wird zuerst angeboten. Jedes zugelassene Gerät kann sich außerdem mit seinem eigenen Client-Zertifikat über gegenseitiges TLS authentifizieren.
Auf den Geräten werden lokale Datenbanken mit AES-256 verschlüsselt und mit HMAC-SHA256 authentifiziert. Auf Smartphones werden der Protokollspeicher und Geräteschlüssel mit einem hardwaregestützten Schlüssel in der Secure Enclave, in StrongBox oder in der vertrauenswürdigen Ausführungsumgebung verschlüsselt.
Technischer Nachweis
Lesen Sie die Einzelheiten im Sicherheitspapier zu Sanket
Jede Aussage auf dieser Seite ist im öffentlich zugänglichen technischen Weißbuch zu Sicherheit und Architektur von Sanket vollständig dargelegt. Es ist ohne Registrierung kostenlos lesbar.
Verwendet Sanket das Signal Protocol?
Ja. Sanket verschlüsselt auf jeder Plattform sämtliche Nachrichten mit der offiziellen libsignal-Bibliothek von Signal und verwendet dabei den PQXDH-Schlüsselaustausch sowie Double Ratchet mit SPQR. Eine eigene Neuimplementierung des Protokolls ist nicht enthalten.
Bietet SANKET mit AES-256 verschlüsselte Nachrichten?
Ja. Nachrichten verwenden AES-256-CBC mit HMAC-SHA256 innerhalb von libsignal; Dateien, Anruf-Frames, die Anrufübertragung, die lokale Speicherung und TLS verwenden AES-256-GCM. Ein Rückfall auf AES-128 ist nicht möglich.
Sind Sprach- und Videoanrufe Ende-zu-Ende-verschlüsselt?
Ja. Die Datenblöcke von Anrufen werden mit AES-256-GCM unter senderspezifischen Schlüsseln Ende-zu-Ende-verschlüsselt. Diese Schlüssel werden über libsignal zugestellt; für jeden Sender werden pro Sekunde 5 neue Schlüssel für Datenblöcke verwendet. Die Verschlüsselung erfolgt innerhalb von SRTP, das ausschließlich AES-256-GCM akzeptiert.
Sind Reaktionen und Rundnachrichten verschlüsselt?
Ja. Reaktionen und verschlüsselte Rundmeldungen sind libsignal-Nachrichten und wie jede andere Nachricht Ende-zu-Ende-verschlüsselt. Auch die Priorität, die Frist und der Ablaufzeitpunkt einer Rundmeldung sind verschlüsselt.
Verwendet Sanket Senderschlüssel für Gruppen?
Nein. SANKET verschlüsselt Gruppennachrichten für jedes vertrauenswürdige Gerät jedes Mitglieds separat, jeweils über eine eigene libsignal-Sitzung. Daher gibt es keinen gemeinsamen Gruppenschlüssel.
Welche TLS-Versionen akzeptiert Sanket?
TLS 1.3 wird bevorzugt, ausschließlich mit TLS_AES_256_GCM_SHA384. TLS 1.2 wird nur mit ECDHE und AES-256-GCM akzeptiert. Versionen unter TLS 1.2 werden nicht akzeptiert, und der hybride Post-Quanten-Schlüsselaustausch X25519MLKEM768 wird vorrangig angeboten.
Wurde libsignal geprüft?
Ja. SANKET basiert auf Signals unabhängig geprüfter Bibliothek libsignal, und das PQXDH-Protokoll wurde formal analysiert.
Prüfen Sie die Kryptografie von Sanket gemeinsam mit unseren Ingenieuren
Tosh Defence erläutert Sicherheitsarchitekten und Evaluierungsgremien den kryptografischen Aufbau Schicht für Schicht. Die zugangsbeschränkte Fassung des technischen Grundsatzpapiers ist im Rahmen einer Geheimhaltungsvereinbarung erhältlich.