ブロックチェーンハンドシェイク: トラストレスな鍵交換

2人のZ-Textユーザーがメッセージを交換する前に、「ハンドシェイク」を完了する必要があります -- 共有暗号化鍵を確立する暗号プロトコルです。この記事では、その仕組みとセキュリティに とってなぜ重要かを説明します。

なぜハンドシェイクが必要なのか？

従来の暗号化メッセンジャーでは、中央サーバーが鍵交換を仲介します。Signalで誰かにメッセージを 送るとき、Signalのサーバーが最初の鍵合意を促進します。これはうまく機能しますが、信頼の 依存関係を導入します -- サーバーが正しい鍵を配信することを信頼する必要があります。

Z-Textにはサーバーがありません。ハンドシェイクは完全にブロックチェーントランザクションを 通じて行われ、トラストレスで検証可能です。鍵交換を改ざんしたり監視したりできる仲介者は いません。

プロトコル

Z-Textのハンドシェイクは、ブロックチェーンベースの配信に適応された、修正版Diffie-Hellman 鍵交換プロトコルに従います:

ステップ1: 開始

AliceがBobにメッセージを送りたいとします。彼女はBobのz-addressを知っています。Aliceの アプリはエフェメラル鍵ペアを生成し、Bobのz-addressへのシールドトランザクションを作成します。 トランザクションmemoにはAliceのエフェメラル公開鍵と彼女のz-addressが含まれています。

これはシールドトランザクションであるため、ブロックチェーンを監視している誰も、Aliceが Bobに何かを送ったことや、memoに何が含まれているかを見ることができません。

ステップ2: 検出

Bobがウォレットを同期すると、彼のアプリは受信トランザクションを検出し、memoを読み取ります。 memoフォーマット内の特定のプロトコルマーカーにより、これがハンドシェイクリクエストであると 認識します。

Bobのアプリは、Aliceのz-addressとともにハンドシェイクリクエストを表示し、承認または 拒否を促します。

ステップ3: 応答

Bobが承認すると、彼のアプリは独自のエフェメラル鍵ペアを生成し、Aliceのz-addressに 応答トランザクションを送信します。memoにはBobのエフェメラル公開鍵が含まれています。

ステップ4: 鍵導出

AliceとBobの両方が互いのエフェメラル公開鍵を持っています。それぞれが楕円曲線 Diffie-Hellman（ECDH）を使用して独立に共有秘密を計算します。ECDHの数学的特性により、 共有秘密が一度も送信されることなく、両者が同じ共有秘密に到達することが保証されます。

この共有秘密は、AliceとBob間のすべての将来のメッセージの対称暗号化鍵を導出する 基盤として使用されます。

セキュリティ特性

ブロックチェーンハンドシェイクは、いくつかの重要なセキュリティ特性を提供します:

• 機密性: 鍵交換はシールドトランザクション内に隠され、オブザーバーからは見えません
• 完全性: ブロックチェーンのProof of Workにより、トランザクションは改ざんできません
• 真正性: z-addressの秘密鍵の保持者のみがハンドシェイクの応答を作成できます
• MITM攻撃なし: 中央サーバーがないため、鍵をすり替えることができる仲介者がいません

Signal Protocolとの比較

Signal Protocolは、事前鍵の保存と配信に中央サーバーを使用します。これにより非同期の 鍵交換が可能になりますが（オフラインの相手にメッセージを送ることができます）、Signalの サーバーが正しい鍵を配信することを信頼する必要があります。

Z-Textのブロックチェーンハンドシェイクも非同期です（AliceがリクエストをSend送信する時に Bobがオンラインである必要はありません）が、配信メカニズムは企業サーバーではなく分散型 ブロックチェーンです。ハンドシェイクのステップはG-stream mempoolプッシュを介して検出され、 ステップごとに数秒で完了し、信頼モデルは根本的に強固です。

実用上の考慮事項

ハンドシェイクは通常、G-stream mempoolプッシュを介してステップごとに数秒以内に完了します。 各ステップには少額のBTCZトランザクション手数料が必要です。一度確立されると、共有鍵は ローカルに保存され、更新する必要はありません -- 2つの連絡先間のすべての将来のメッセージに 同じ鍵が使用されます。

連絡先を削除して再追加した場合、新しいハンドシェイクを行う必要があり、完全に新しい 共有秘密が生成されます。