全体を通じたSignal Protocolによるエンドツーエンド暗号化とAES-256
Tosh DefenceのSanket.Chatは、独立した監査を受けたSignalの公式libsignalを通じてSignal Protocolを使用し、耐量子鍵合意のPQXDHとSPQRを組み込んだDouble Ratchetにより、すべてのメッセージ、リアクション、暗号化された一斉配信をエンドツーエンドで暗号化します。ファイル、通話フレーム、通話の転送、ローカルストレージ、および導入環境が終端するすべてのTLSセッションにはAES-256を使用し、AES-128へのフォールバックや互換モードはありません。
SANKETの設計方針は、AES-256で暗号化できなければ処理しないというもので、コードで徹底されています。設計どおりに暗号化できない場合は、暗号強度を下げずに処理を拒否します。
メッセージ: 改変を加えていないSignal Protocol
SANKETは、すべてのメッセージ暗号化にSignal公式のlibsignalライブラリを使用し、iOS、Android、デスクトップ、サーバーで同じリリースを採用しています。Signal Protocolの独自再実装も、代替のメッセージ暗号も含みません。
セッションは、X3DHの耐量子拡張であるPQXDHを用い、X25519による鍵共有とKyberによる鍵カプセル化を組み合わせて確立されます。その後、メッセージはDouble Ratchetで暗号化されます。各メッセージ鍵からAES-256鍵、HMAC-SHA256鍵、初期化ベクトルを導出し、AES-256でメッセージを暗号化してHMAC-SHA256で認証した後、その鍵を削除します。すべてのセッションで、Signalのスパース耐量子ラチェットも並行して動作します。
設計上、代替手段への切り替えなし
libsignalによる暗号化を実行できない場合、クライアントは送信を拒否します。libsignalの識別鍵を公開していないデバイスには平文で送信せず、そのデバイスを送信先から除外します。従来の平文を示す識別子は拒否され、サーバーはlibsignal形式に準拠しない鍵の組を拒否します。メッセージ本文を平文または別の暗号方式で送信する経路はありません。
共有鍵を使用しないグループ
グループメッセージは、各端末への個別配送によって暗号化されます。送信端末は、各メンバーが使用する信頼済み端末ごとに、それぞれのlibsignalセッションを通じてメッセージを個別に暗号化します。メンバー構成が変わっても鍵の再設定は不要で、削除されたメンバーは個別配送先の一覧から除外されます。
暗号化する前に、送信者は各受信者アカウント自身の鍵で署名されたデバイス一覧を確認し、一覧にないデバイスには何も送信しません。
ファイルと通話
添付ファイルの内容、名前、種類は、ファイルごとに生成されるランダムな256ビット鍵を用い、端末上でAES-256-GCMにより暗号化されます。その鍵はlibsignalのメッセージ内で送信されます。
音声と映像は二重に保護されます。各参加者のフレームは、送信者ごとに設定される鍵を用いてAES-256-GCMでエンドツーエンド暗号化されます。この鍵は200ミリ秒ごとに更新され、送信者ごとに毎秒5個の新しいフレーム鍵が生成されます。参加者が通話に加わるか退出するたびに、新しいランダムな鍵が生成されます。各端末とメディアサーバーの間では、SRTPはAEAD_AES_256_GCMのみを受け付けます。メディアサーバーは復号できない暗号化フレームを転送し、設計上、サーバー側での通話録音はできません。
- ファイルごとにAES-256-GCMを使用
- 通話鍵は送信者ごとに設定し、参加者全員で共有する鍵は使用しない
- 送信者ごとに毎秒5個のフレーム鍵
- SRTPではAES-256-GCMのみ
通信経路と保存領域
アプリからのすべての接続には、TLS_AES_256_GCM_SHA384を使用するTLS 1.3を用います。プラットフォームのネットワークスタックが必要とする場合は、ECDHEとAES-256-GCMを使用するTLS 1.2を用います。AES-128、ChaCha20、CBCモードの暗号スイート、静的RSAは除外し、耐量子暗号とのハイブリッドグループX25519MLKEM768を最優先で提示します。承認済みの各デバイスは、相互TLSを通じて固有のクライアント証明書でも自身を証明できます。
端末上では、ローカルデータベースをAES-256で暗号化し、HMAC-SHA256で認証します。スマートフォンでは、通信プロトコル用の保存領域と端末の秘密情報を、セキュアエンクレーブ、StrongBox、または信頼できる実行環境にあるハードウェア保護付きの鍵で暗号化します。
技術的な実証
詳細はSanketの白書で確認
このページに記載されたすべての内容は、一般公開されているSanketの技術セキュリティ・アーキテクチャ白書で詳しく説明されており、登録なしで無料で閲覧できます。
SANKETはSignal Protocolを使用しますか？
はい。SANKETは、すべてのプラットフォームでSignalの公式libsignalライブラリを使用し、PQXDH鍵共有とSPQRを併用したDouble Ratchetによってすべてのメッセージを暗号化します。プロトコルを独自に再実装した部分はありません。
SANKETはAES-256で暗号化されたメッセージングサービスですか？
はい。メッセージにはlibsignal内でAES-256-CBCとHMAC-SHA256を使用します。ファイル、通話フレーム、通話の伝送、ローカルストレージ、TLSにはAES-256-GCMを使用します。AES-128への代替切り替えはありません。
音声通話とビデオ通話はエンドツーエンドで暗号化されていますか？
はい。通話のフレームは、libsignalを通じて配布される送信者ごとの鍵を使用し、AES-256-GCMでエンドツーエンド暗号化されます。送信者ごとに1秒あたり5個の新しいフレーム鍵を使用し、AES-256-GCMのみを受け付けるSRTPの内部で処理されます。
リアクションと一斉送信は暗号化されていますか？
はい。リアクションと暗号化された一斉通知はlibsignalのメッセージであり、ほかのすべてのメッセージと同様にエンドツーエンドで暗号化されます。一斉通知の優先度、期限、有効期限も暗号化の対象です。
SANKETはグループ通信に送信者鍵を使用しますか？
いいえ。SANKETは、各メンバーの信頼済み端末それぞれに対し、端末ごとに独立したlibsignalセッションを通じてグループメッセージを個別に暗号化します。そのため、共有のグループ鍵はありません。
SANKETはどのバージョンのTLSに対応していますか？
TLS 1.3を優先し、暗号スイートはTLS_AES_256_GCM_SHA384のみに限定します。TLS 1.2はECDHEとAES-256-GCMを使用する場合に限り許可します。TLS 1.2未満は許可せず、ハイブリッド型の耐量子鍵交換X25519MLKEM768を最優先で提示します。
libsignalは監査を受けていますか？
はい。Sanketは、独立監査を受けたSignalのlibsignalライブラリを基盤として構築されており、PQXDHプロトコルは形式的に解析されています。
当社のエンジニアとともにSANKETの暗号技術を検証する
Tosh Defenceは、暗号設計を各層に分けてセキュリティ設計者と評価委員会に説明します。秘密保持契約の下で、ホワイトペーパーの管理対象版も提供します。