Loading article…
ノイズプロトコルフレームワークは、ノイズまたはノイズフレームワークとも呼ばれ、2者間の安全なチャネルプロトコルの設計を可能にします。TLS 1.3と比較すると、ノイズフレームワーク（パブリックドメイン仕様[1]で説明）では、ハンドシェイクパターンと暗号化アルゴリズムを選択して、RTTの動作など、現在のタスクに最も適切な暗号化特性とトレードオフを持つ具体的なプロトコルを作成できます。ノイズは、SlackのNebula、[2] WhatsApp、WireGuardなど、広く導入されているプロトコルの基礎となっています。
概要
セキュア チャネル プロトコルには 2 つのフェーズがあります。
- ハンドシェイクフェーズ:認証鍵交換(AKE)用のDiffie-Hellman 鍵交換(DH)を使用して、共有秘密鍵を認証し確立します。
- 転送フェーズ: 共有秘密鍵を使用してデータを暗号化する
ハンドシェイク パターンは、図ではメッセージのセットとして記述できます。各メッセージには、パーティのハンドシェイク状態で実行される暗号化操作を記述するトークンのリストが注釈として付けられます。
3 つのメッセージを持つハンドシェイク パターンの例:
IK
<- s
...
-> e、es、s、ss
<- e、ee、se
ハンドシェイクの名前は定型的です:
I= アイデンティティの隠蔽が減少または欠如しているにもかかわらず、発信者Iの静的キーが応答者に直ちに送信されるK=応答者に知られているイニシエーターKの静的キー
前の行は、...公開鍵の帯域外転送など、DH AKE の前のメッセージを表します。
仕様には、3 つの一方向ハンドシェイク パターンと 12 の基本的な対話型ハンドシェイク パターンが記載されています。これらのいくつかにはバリエーションがあります。
- 遅延パターンでは、認証DHは次のメッセージに延期されます。
1最初の文字と/または2番目の文字の後に数字が使用されます。例:NK1またはX1X1 - 双方が32バイトの共有秘密鍵を持つプロトコルをサポートするための事前共有対称鍵、例：
Npsk0またはXpsk1 - 複合プロトコルでは、モディファイアを介してイニシエーターとレスポンダーの役割が逆転し、ネゴシエーションのメカニズムとなる
fallback。ノイズパイプは§10.4 [3]に記載されている例である。
実際の例としては、ホワイトペーパーの 10 ページに記載されている WireGuard の構築Noise_IKpsk2_25519_ChaChaPoly_BLAKE2sが挙げられます。
各ハンドシェイク パターンは、仕様に記載されている 8 つの暗号化アルゴリズムの 16 の組み合わせのいずれかと組み合わせることができます。これらのアルゴリズムは同等の品質であり、設計スペースを拡大しません。
仕様書では、§5 [4]で、それぞれが少数のメソッドを持つ以下のオブジェクトを使用したAPIの概要を示しています。
- オブジェクトにはk 個とn 個の
CipherState変数が含まれており、これらを使用して暗号文を暗号化および復号化します。ハンドシェイク フェーズでは各当事者は 1 つの を持ちますが、トランスポート フェーズでは各当事者は送信用と受信用の 2 つのオブジェクトを持ちます。CipherStateCipherState - オブジェクトには、とckおよびh
SymmetricState変数が含まれます。Noise で使用されるすべての「対称暗号」をカプセル化するため、このように呼ばれています。ハンドシェイク フェーズ中、各パーティは 1 つの を持ち、ハンドシェイクが終了すると削除できます。CipherStateSymmetricState - オブジェクトには、と DH 変数 ( s、e、rs、re
HandshakeState) およびハンドシェイク パターンを表す変数が含まれます。ハンドシェイク フェーズ中、各パーティは 1 つの を持ちますが、ハンドシェイクが終了すると削除できます。SymmetricStateHandshakeState
具体的なプロトコルの実装には、メッセージ表現の設計だけでなく、Noise Framework 以外の側面も関係します。後者の例としては、UDP トランスポートを使用するプロトコルが挙げられます。たとえば、スライディング ウィンドウを使用して順序外の到着を処理する WireGuardなどです。
仕様では、いくつかのハンドシェイクパターンのセキュリティ特性が説明されており、相互認証、前方秘匿性、ゼロラウンドトリップ暗号化、ID隠蔽などの高度な機能をサポートできます。一般的なハンドシェイクパターンの正式な暗号分析は、学術文献に掲載されています。[5] [6] 2番目の取り組みは、オンラインツールNoise Explorerにつながりました。[7]
以下の大部分は、フォーマットされた仕様からの抜粋で構成されています。
IKハンドシェイクパターン、暗号化、修飾子で構成されるプロトコル名- ハンドシェイクステートマシンの変数のck
- メッセージパターン内のトークンのe
- § 仕様書のセクションへの参照を接頭辞として付ける
重点は以下のとおりです。
- 握手パターン
- セキュリティ特性とトレードオフ
- アプリケーションの責任とセキュリティの考慮事項
背景
このフレームワークは、Open Whisper Systemsでの作業に基づいて、 Trevor Perrin がMoxie Marlinspikeの支援を受けて開発しました。
なぜ "ノイズ「
「ノイズ」とは設計上の根拠の一つである。[8]
暗号文は、次の理由によりランダムと区別できない必要があります。
これにより、ノイズプロトコルは、ランダムパディング（長さを隠すため）、検閲耐性のある「指紋が取れない」プロトコル、またはステガノグラフィーでの使用が容易になります。ただし、エリゲーターなどの技術を使用しない限り、一時キーはランダムキーと区別できる可能性があることに注意してください。[9]
おそらく、 Signal (ソフトウェア)の語呂合わせでもある。
DH ベースのプロトコル (RWC 2018 の講演より)
最も安全なチャネル プロトコルは、署名 (認証用) と Diffie-Hellman (鍵交換用) に基づく AKE を使用します。過去 10 ～ 15 年間で、DH ベースの AKE (署名なし) への関心が高まっています。
エレガントだが、各プロトコルはゼロから始まる
- アイデア1: シンプルな要素を組み合わせて異なるプロトコルを作成する
- アイデア2：「スポンジのような」対称暗号を使用する（マイク・ハンバーグ[14]のStrobe [15]のアイデア）
発達
仕様の最初のコミットは2014年8月4日でした[16] 。その後、メーリングリストでの議論を経て、2018年7月11日のrev34まで多くの変更が行われました。 [17] NBはもともと2013年2月10日からWikiでメンテナンスされていました。[18]
プロトコル名と修飾子 §8
ノイズプロトコル名を生成するには、Initialize()ASCII文字列をNoise_、ハンドシェイクパターン、DH関数、暗号関数、ハッシュ関数の順に名前を付けた4つのアンダースコアで区切られた名前セクションと連結します。結果の名前は255バイト以下でなければなりません。[19]例:
Noise_XX_25519_AESGCM_SHA256Noise_N_25519_ChaChaPoly_BLAKE2sNoise_IK_448_ChaChaPoly_BLAKE2b
各名前セクションは、英数字 (つまり、「A」...「Z」、「a」...「z」、および「0」...「9」のいずれかの範囲の文字) と 2 つの特殊文字「+」および「/」のみで構成する必要があります。
以下に指定されているように、各名前セクションには追加のルールが適用されます。
ハンドシェイクパターン名セクション §8.1
ハンドシェイクパターン名セクションには、ハンドシェイクパターン名と0個以上のパターン修飾子のシーケンスが含まれます。[20]
ハンドシェイク パターン名は、アルファベット文字または数字のみを含む大文字の ASCII 文字列である必要があります (例:XX1または IK)。
パターン修飾子は、ハンドシェイク パターンによって指定された動作に対する任意の拡張または変更を指定します。たとえば、ハンドシェイク パターンに修飾子を適用して、何らかのルールに従って別のパターンに変換することができます。psk0およびfallback修飾子は、この例であり、このドキュメントの後半で定義されます。
パターン修飾子は、小文字の英数字 ASCII 文字列で名前が付けられ、アルファベット文字 (数字ではない) で始まる必要があります。パターン修飾子は、次のように基本パターンに追加されます。
基本パターンに追加された最初の修飾子は、単純に付加されます。したがって、fallback修飾子をパターンに追加するとXX、 が生成されますXXfallback。追加の修飾子はプラス記号で区切られます。したがって、psk0修飾子を追加すると、名前セクションXXfallback+psk0、または などの完全なプロトコル名が生成されますNoise_XXfallback+psk0_25519_AESGCM_SHA256。
場合によっては、修飾子の順序によって異なるプロトコルが指定されます。ただし、一部の修飾子の順序が重要でない場合は、それらをアルファベット順に並べる必要があります (これは相互運用性を確保するための任意の規則です)。
暗号アルゴリズム名セクション §8.2
DH、暗号、ハッシュ名セクションのルールは同じです。各名前セクションには、プラス記号で区切られた1つ以上のアルゴリズム名が含まれている必要があります。[21]
各アルゴリズム名は、英数字とスラッシュ文字 ("/") のみで構成する必要があります。アルゴリズム名は短くし、あいまいさを避けるために必要な場合にのみ "/" 文字を使用することをお勧めします (例: はSHA3/256よりも推奨されますSHA3256)。
ほとんどの場合、各名前セクションには 1 つのアルゴリズム名があります (つまり、プラス記号はありません)。複数のアルゴリズム名は、パターンまたは修飾子によって要求された場合にのみ使用されます。
このドキュメントのパターンや修飾子はいずれも、名前セクションに複数のアルゴリズム名を必要としません。ただし、この機能は将来の拡張で役立つ可能性があります。たとえば、DH セクションで複数のアルゴリズム名を使用して「ハイブリッド」ポスト量子前方秘匿性を指定したり、さまざまな目的で複数のハッシュ アルゴリズムを指定したりする場合があります。
暗号化アルゴリズム、§12
仕様書には、以下の名前の8つの最新アルゴリズムが記載されています。[22] [23]
Wikiには非公式アルゴリズムのリストがあります。[24]ポスト量子暗号のものは省略しました。これは、 2016年に始まったNISTポスト量子暗号標準化の取り組みよりも前のものであり、2024年に最初の3つのポスト量子暗号標準であるFIPS 203、FIP 204、FIP 205が策定されるからです。
ここで、私たちは[誰? ]非標準アルゴリズムに使用できるいくつかの名前を文書化します。これにより、これらのアルゴリズムの実験的な使用で一貫した名前を使用できるようになります (注: これらのアルゴリズムはいずれも Noise での使用が推奨されていません。自己責任で使用してください)。
プロローグ §6
ノイズプロトコルにはプロローグ入力があり、任意のデータをh変数にハッシュすることができます。両者が同一のプロローグデータを提供しない場合、ハンドシェイクは復号エラーにより失敗します。これは、ハンドシェイクの前に両当事者が交渉を行い、その交渉について同一の見解を共有したい場合に便利です。[34]
たとえば、ボブがサポートしたいノイズ プロトコルのリストをアリスに伝えるとします。アリスは 1 つのプロトコルを選択して実行します。「中間者」がボブのリストを編集してオプションを削除しないようにするために、アリスとボブはリストをプロローグ データとして含めることができます。
当事者はプロローグが同一であることを確認していますが、プロローグ データを暗号化キーに混ぜることはありません。入力に暗号化を強化するための秘密データが含まれている場合は、代わりに PSK ハンドシェイクを使用する必要があります (§9 を参照)。
握手パターン
ハンドシェイクパターン: 3 一方向 §7.4
以下のハンドシェイクパターンは、送信者から受信者への一方向のデータストリームをサポートする「一方向」ハンドシェイクを表しています。これらのパターンは、ファイル、データベースレコード、またはその他の非対話型データストリームを暗号化するために使用できます。[35]
一方向ハンドシェイクの後、送信者は から返された最初の CipherState を使用して暗号化したトランスポート メッセージのストリームを送信できます。Split()からの 2 番目の CipherStateはSplit()破棄されます。受信者はそれを使用してメッセージを送信してはなりません (これは §7.3 の規則に違反するため)。
一方向パターンは、送信者の静的キーのステータスを示す 1 文字で名前が付けられます。
N=送信者用の静的キーはありませんK=応答者に知られているイニシエーターKの静的キーX= 送信者Xの静的キーが受信者に送信（「送信」）される
N:
<-秒 ... -> e、es
K:
-> s <- s ... -> e、es、ss
X:
<-秒 ... -> e、es、s、ss
Nは、従来の DH ベースの公開鍵暗号化です。他のパターンでは、送信者の認証が追加され、送信者の公開鍵は受信者に事前に知られているか ( K)、暗号化されて送信されます ( X)。
ハンドシェイクパターン、12 基本インタラクティブ §7.5
以下のハンドシェイクパターンは対話型プロトコルを表しています。これらの12のパターンは「基本的な」対話型ハンドシェイクパターンと呼ばれています。[36]
基本的なインタラクティブ パターンは、イニシエーターとレスポンダーの静的キーの状態を示す 2 つの文字で名前が付けられます。
最初の文字はイニシエーターの静的キーを参照します。
N=No イニシエーターの静的キーKK=応答者に知られている発信者の静的キーXX= 発信側から応答側に送信される（「送信」される）静的キーI= アイデンティティの隠蔽が減少または欠如しているにもかかわらず、発信者の静的キーIが応答者に直ちに送信される
2 番目の文字は、応答側の静的キーを参照します。
N=No 応答者の静的キーKK= 応答側が開始側に認識している静的キーXX= 応答側から発信側に送信される静的キー
上記の表の最初の 2 つの列は、各メッセージ パターンの前に、§7.4 のすべての一方向パターンと §7.5 の基本パターンのノイズ ハンドシェイクおよびトランスポート ペイロードのセキュリティ プロパティを一覧表示します。各ペイロードには、受信者に提供される送信者の認証の程度に関する「ソース」プロパティと、送信者に提供される機密性の程度に関する「宛先」プロパティが割り当てられます。
送信者の場合:
- 0.認証なし。このペイロードは、アクティブな攻撃者を含むあらゆる当事者によって送信された可能性があります。
使用者: IN#1、IN#2、IN#4、IX#1、KN#2、 # KN3、KN#5、KX#2、NK#2、NK#4、NN#1、NN#2、NN#3、NX#1、NX#3、 # XK2、XN#1、XN#2、XN#4、XX#1
- 1.送信者認証は、鍵侵害偽装 (KCI) に対して脆弱です。送信者認証は、両者の静的鍵ペアを含む静的-静的 DH ( ss ) に基づいています。受信者の長期秘密鍵が侵害された場合、この認証は偽造される可能性があります。Noise の将来のバージョンには署名が含まれる可能性があり、これによりこのセキュリティ特性が向上する可能性がありますが、他のトレードオフも発生することに注意してください。
使用者: IK#2、IN#3、KK#3、KN#4、NK#3 NN、NN#2、NX#3、XK#2、#3、XN#2、XN#3、XX#2
- 2.鍵侵害偽装に耐性のある送信者認証(KCI) 。送信者認証は、送信者の静的鍵ペアと受信者の一時鍵ペア間の一時静的 DH ( esまたはse ) に基づいています。対応する秘密鍵が安全であると仮定すると、この認証は偽造できません。
使用者: IK#2、IK#3、IK#4、IK#5、IN#3 IX、IX#2、 # IX3 KK、KK#4、#3、#4、KK#5、KK#6、KN#4、KX#3、KX#4、KX#5 、#2、#3、 NK# NK2、NX#3 、 XK#4、#5、XK#2、#3、#2、XK#3、XK#4、XN#5、#3、XX#2、XX#3、XX#4
受取人の場合:
- 0.機密性なし。このペイロードはクリアテキストで送信されます。
使用者: IN#1、IN#2、IN#4、IX#1、KN#2、 # KN3、KN#5、KX#2、NK#2、NK#4、NN#1、NN#2、NN#3、NX#1、NX#3、 # XK2、XN#1、XN#2、XN#4、XX#1
- 1.一時的な受信者への暗号化。暗号化には一時的な一時的な DH ( ee )が含まれるため、このペイロードには前方秘匿性があります。ただし、送信者は受信者を認証していないため、このペイロードはアクティブな攻撃者を含むあらゆる相手に送信される可能性があります。
使用者: IK#2、IN#3、KK#3、KN#4、NK#3 NN、NN#2、NX#3、XK#2、#3、XN#2、XN#3、XX#2
- 2.既知の受信者への暗号化、送信者のみが侵害される前方秘匿性、リプレイに対して脆弱。このペイロードは、受信者の静的キー ペアを含む DH のみに基づいて暗号化されます。受信者の静的秘密キーが侵害された場合、後日でも、このペイロードは復号化できます。受信者からの一時的な寄与がないため、このメッセージもリプレイ可能です。
使用者: IK#2、IK#3、IK#4、IK#5、IN#3 IX、IX#2、 # IX3 KK、KK#4、#3、#4、KK#5、KK#6、KN#4、KX#3、KX#4、KX#5 、#2、#3、 NK# NK2、NX#3 、 XK#4、#5、XK#2、#3、#2、XK#3、XK#4、XN#5、#3、XX#2、XX#3、XX#4
- 3.既知の受信者への暗号化、弱い前方秘匿性。このペイロードは、受信者の静的キー ペアを含む一時的 - 一時的 DH と一時的 - 静的 DH に基づいて暗号化されます。ただし、受信者の一時的公開キーと受信者の静的公開キーの結合は送信者によって検証されていないため、受信者の一時的公開キーはアクティブな攻撃者によって偽造されている可能性があります。この場合、攻撃者は後で受信者の静的秘密キーを侵害してペイロードを復号化できます。Noise の将来のバージョンには署名が含まれる可能性があり、これによりこのセキュリティ プロパティが向上する可能性がありますが、他のトレードオフも発生することに注意してください。
使用者: IN#2、IX#2、KN#3、KX#3
- 4.既知の受信者への暗号化、送信者の秘密鍵が侵害されている場合は弱い前方秘匿性。このペイロードは、一時的-一時的 DH に基づいて暗号化され、受信者の静的鍵ペアを含む一時的-静的 DH にも基づいて暗号化されます。ただし、受信者の疑わしい一時的公開鍵と受信者の静的公開鍵の間の結合は、それらの公開鍵と送信者の静的秘密鍵の両方を含む DH に基づいてのみ検証されています。したがって、送信者の静的秘密鍵が以前に侵害されていた場合、受信者の疑わしい一時的公開鍵はアクティブな攻撃者によって偽造されている可能性があります。この場合、攻撃者は後で意図した受信者の静的秘密鍵を侵害してペイロードを復号化できます (これは「弱い前方秘匿性」攻撃を可能にする「KCI」攻撃のバリエーションです)。Noise の将来のバージョンには署名が含まれる可能性があり、これによりこのセキュリティ プロパティが向上する可能性がありますが、他のトレードオフも発生します。
使用者: IK#3、KK#4
- 5.既知の受信者への暗号化、強力な前方秘匿性。このペイロードは、受信者の静的キー ペアを使用して、一時的 - 一時的 DH と一時的 - 静的 DH に基づいて暗号化されます。一時的秘密キーが安全であり、受信者が静的秘密キーを盗んだ攻撃者によって積極的になりすまされていないと仮定すると、このペイロードは復号化できません。
使用者: IK#4、IK#5、IN#4、IX#3、IX#4 KK、KK#5、#6 、# KN5、KX#4、KX#5、NK#4、NX#3、XK#4、XK#5、XN#4、XX#3、XX#4
共通パターンの同一性隠蔽特性 §7.8
次の表は、§7.4の一方向ハンドシェイクパターンと§7.5の基本ハンドシェイクパターンのアイデンティティ隠蔽特性の一覧です。さらに、対応する基本パターンとは異なるアイデンティティ隠蔽特性を持つ遅延ハンドシェイクパターンをいくつか示します。[37]
各パターンには、イニシエーターの静的公開キーとレスポンダーの静的公開キーに提供される機密性を説明するプロパティが割り当てられます。基本的な前提は、一時的な秘密キーは安全であり、相手側から信頼できない静的公開キーを受け取った場合は、当事者がハンドシェイクを中止することです。
このセクションでは、ハンドシェイクの静的公開キー フィールドを介した ID 漏洩についてのみ検討します。もちろん、Noise 参加者の ID は、ペイロード フィールド、トラフィック分析、IP アドレスなどのメタデータなど、他の手段を通じて公開される可能性があります。
関連する公開鍵のプロパティは次のとおりです。
- 0. クリアに送信されます。
- 1. 前方秘匿性で暗号化されていますが、匿名のイニシエーターによってプローブできます。
- 2. 前方秘匿性で暗号化され、匿名の応答者に送信されます。
- 3. 送信されませんが、受動的な攻撃者は、応答者の秘密鍵の候補をチェックし、候補が正しいかどうかを判断できます。攻撃者は、以前に記録されたメッセージを新しい応答者に再生し、受信者がメッセージを受け入れるかどうかによって、2 つの応答者が「同じ」であるかどうか (つまり、同じ静的キー ペアを使用しているかどうか) を判断することもできます。
- 4. 応答者の静的公開鍵に暗号化され、前方秘匿性はありません。攻撃者が応答者の秘密鍵を入手した場合、発信者の公開鍵を復号化できます。
- 5. 送信されませんが、受動的な攻撃者は (応答者の秘密鍵、発信者の公開鍵) のペアの候補を確認し、候補のペアが正しいかどうかを知ることができます。
- 6. 暗号化されていますが、前方秘匿性が弱い。発信者の静的秘密鍵を持たずに発信者になりすまし、後に発信者の秘密鍵を知ったアクティブな攻撃者は、応答者の公開鍵を復号化できます。
- 7. 送信されませんが、イニシエーターの静的秘密鍵を持たずにイニシエーターになりすますアクティブな攻撃者は、後でイニシエーターの秘密鍵の候補を知り、その候補が正しいかどうかを確認できます。
- 8. 認証された相手に対して前方秘匿性で暗号化されます。
- 9. 発信者を装い、単一のプロトコル実行を記録するアクティブな攻撃者は、応答者の公開鍵の候補を確認できます。
ハンドシェイクパターン: 対話型、遅延 §7.6
前のセクションの基本的なハンドシェイクパターンは、認証（esとse）のためのDH操作をできるだけ早く実行します。[38]
これらの認証 DH を次のメッセージまで延期する追加のハンドシェイク パターン セットを記述できます。これらの延期されたハンドシェイク パターンに名前を付けるには、1基本パターン名の最初と 2 番目の文字の後に数字を使用して、イニシエーターとレスポンダーの認証 DH が次のメッセージまで延期されることを示します。
遅延パターンは、いくつかの理由で役立つ場合があります。
- イニシエーターは、レスポンダーの静的公開キーを事前に知っているかもしれませんが、0-RTT で暗号化されたデータを送信したくない場合があります。
- 場合によっては、認証を延期することで、ハンドシェイクの ID 隠蔽特性が向上することがあります (§7.8 を参照)。
- ノイズの将来の拡張では、DH 操作を署名または KEM 暗号文に置き換えることができる可能性がありますが、送信者が自分自身を認証している場合 (署名)、または送信者が受信者を認証している場合 (KEM 暗号文) にのみ、これを行うことができます。したがって、すべての基本的なハンドシェイク パターンでは、各認証 DH を署名または KEM 暗号文に置き換えることしかできませんが、延期されたバリアントでは、両方の置き換えが可能になります。
以下に、左側に基本的なハンドシェイクパターン、右側に遅延ハンドシェイクのバリエーションを示す2つの例を示します。遅延ハンドシェイクのパターンの完全なセットは、付録§18に記載されています。[39]
握手パターン: 複合 §10
[40]
複合プロトコルの根拠 §10.1
これまで、アリスとボブはイニシエーター（アリス）が選択した単一のノイズプロトコルを実行すると仮定してきました。しかし、アリスの最初のメッセージを受信した後、ボブが別のノイズプロトコルに切り替えたいと思う理由はいくつかあります。例えば、次のようになります。[41]
アリスは、ボブがサポートしていない暗号、DH 機能、またはハンドシェイク パターンに基づいてノイズ プロトコルを選択した可能性があります。
アリスは、ボブの静的公開鍵または PSK の古いバージョンに基づいて、「ゼロ RTT」で暗号化された初期メッセージを送信した可能性があります。
これらのシナリオを処理するには、ボブがアリスが選択した最初のノイズ プロトコルから新しいノイズ プロトコルに切り替える複合プロトコルが必要です。このような複合プロトコルでは、イニシエーターとレスポンダーの役割が逆転します。つまり、ボブが新しいノイズ プロトコルのイニシエーターになり、アリスがレスポンダーになります。
複合プロトコルでは、アリスが最初に使用するノイズ プロトコルと切り替え可能なノイズ プロトコルをアドバタイズする必要があり、両者が安全な移行をネゴシエートする必要があるため、大幅な複雑さが生じます。
これらの詳細は、このドキュメントの範囲外です。ただし、複合プロトコルの構築方法の例を示し、いくつかの構成要素を提供するために、次のセクションではフォールバック修飾子を定義し、それを使用してノイズ パイプ複合プロトコルを作成する方法を示します。
ノイズ パイプはXXパターンをサポートしますが、アリスがボブの静的公開キーをキャッシュし、IK0-RTT 暗号化によるハンドシェイクを試行することもできます。
ボブがアリスの初期メッセージを解読できない場合IK、パターンに切り替えます。これにより、基本的に、アリスが初期メッセージではなく初期メッセージを送信したかのように、XXfallback当事者はハンドシェイクを完了できます。
XXXXIK
修飾語fallback§10.2
修飾子fallbackは、アリスの初期メッセージをボブが他の手段（例えばIKアリスからの初期メッセージ）で受信しなければならない事前メッセージに変換することにより、アリス開始パターンをボブ開始パターンに変換します。この変換後、ハンドシェイクパターンの残りの部分はボブ開始ハンドシェイクパターンとして解釈されます。[42]
たとえば、を生成するfallbackために に適用された修飾子は次のとおりです。
XXXXfallback
XX:
-> e <- e、ee、s、es -> s、se
XXfallback:
->え ... <- e、ee、s、es -> s、se
フォールバックは、アリスの最初のメッセージが事前メッセージとして解釈できる（つまり、 e、s、または「e、s」のいずれかである必要がある） アリス開始形式のハンドシェイク パターンにのみ適用できることに注意してください。
ゼロRTTとノイズプロトコル §10.3
ゼロRTT暗号化のための典型的な複合プロトコルには、3つの異なるノイズプロトコルが含まれます。[43]
- アリスがゼロ RTT 暗号化を可能にするボブに関する保存情報を所有していない場合、またはゼロ RTT ハンドシェイクを使用しない場合は、完全なプロトコルが使用されます。
- ゼロ RTT プロトコルでは、最初のメッセージ内のデータの暗号化が可能です。
- ボブがアリスの最初のゼロ RTT ハンドシェイク メッセージを復号化できない場合、スイッチ プロトコルがトリガーされます。
ボブが最初のメッセージを受信したときに、フル RTT の場合とゼロ RTT の場合を区別する方法が必要です。アリスがゼロ RTT を試行した場合、応答を受信した際にゼロ RTT の場合とスイッチの場合を区別する方法が必要です。
たとえば、各ハンドシェイク メッセージの前には、タイプ バイトなどのネゴシエーション データが付加される場合があります (§13 を参照)。このデータはノイズ メッセージ自体の一部ではありませんが、どのノイズ プロトコルが使用されているかを示します。
騒音管 §10.4
このセクションでは、ノイズパイプ複合プロトコルを定義します。次のハンドシェイクパターンは、前のセクションで説明したフル、ゼロRTT、スイッチの役割を満たすため、単純なゼロRTTオプションを備えたフルハンドシェイクを提供するために使用できます。[3]
XX:
-> e <- e、ee、s、es -> s、se
IK:
<-秒 ... -> e、es、s、ss <- e、ee、se
XXfallback:
->え ... <- e、ee、s、es -> s、se
このXXパターンは、当事者が以前に通信したことがない場合に完全なハンドシェイクに使用され、その後、アリスはボブの静的公開キーをキャッシュできます。
このIKパターンはゼロ RTT ハンドシェイクに使用されます。
このパターンは、ボブが最初のメッセージの復号化に失敗した場合（おそらく静的キーを変更したため）、
XXfallbackスイッチ ハンドシェイクに使用されます。IK
NoiseSocket 上の NoiseLingo ネゴシエーション言語
2018年3月4日のトレバー・ペリンからの電子メール[44]
私は、NoiseSocket (したがって「NoiseLingoSocket」) の上にネゴシエーション言語 (「NoiseLingo」) を追加する「NLS」フレームワークのドラフト仕様を作成しました。これは、1 のアイデアに基づいています。[45]
これには、NoiseSocketドラフトを微調整し、2 [46]から変更を加える必要があります（いくつかの名前を変更し、プロローグの計算を変更して「再試行」ケースを区別し、アプリケーションプロローグを追加します）。
- NLSフレームワーク[47]
- ノイズソケットプロトコル[48]
NLS ドラフトでは、アプリケーション開発者が使用できる高レベル プロトコルとして意図されたいくつかの「基本プロファイル」も定義されています。
- NoiseLink (1-RTT ハンドシェイク)
- NoiseZeroLink (0-RTT ハンドシェイク)
- NoiseShortLink（ローエンド組み込み向け）
- NoiseAnonBox (公開鍵暗号化)
- NoseAuthBox (公開鍵暗号化 + 送信者認証)
アイデアとしては、NoiseLingo と NLS は、プロファイルを作成するために簡単に選択できるネゴシエーション フィールドのメニューを提供します。また、これらのプロファイルには多くの類似点があるため、相互運用の可能性があります (たとえば、NoiseZeroLink クライアントは、1-RTT にフォールバックすることで NoiseLink サーバーと通信できます)。また、NoiseLink のようなシンプルなものから始めると、新しいニーズが見つかったときに新しい NLS フィールドとネゴシエーション オプションを簡単に追加できます。
申請者の責任 §13
ノイズをベースにしたアプリケーションでは、いくつかの問題を考慮する必要があります。[49]
- 暗号関数の選択:
25519DH 関数は一般的な用途に推奨されますが、448楕円曲線暗号に対する暗号解読攻撃が開発された場合には、DH 関数によって追加のセキュリティが提供される可能性があります。DH 関数は、またはのような448512 ビット ハッシュで使用する必要があります。DH 関数は、またはのような256 ビット ハッシュで使用できますが、より小さなハッシュ関数に対する暗号解読攻撃が開発された場合には、512 ビット ハッシュによって追加のセキュリティが提供される可能性があります。をソフトウェアで高速かつ一定時間で実装するのは困難です。SHA512BLAKE2b25519SHA256BLAKE2sAESGCM - 拡張性: アプリケーションでは、すべてのメッセージのペイロードに拡張可能なデータ形式 (JSON、プロトコル バッファーなど) を使用することをお勧めします。これにより、古い実装では無視されるフィールドを将来追加できるようになります。
- パディングアプリケーションでは、すべての暗号化メッセージのペイロードにパディングを許可するデータ形式を使用することをお勧めします。これにより、実装でメッセージ サイズに関する情報の漏洩を回避できます。前の項目に従って、拡張可能なデータ形式を使用すれば十分な場合があります。
- セッション終了: アプリケーションは、ノイズ トランスポート メッセージのシーケンスが攻撃者によって切り捨てられる可能性があることを考慮する必要があります。アプリケーションは、トランスポート ペイロード内に明示的な長さフィールドまたは終了信号を含めて、対話型セッションの終了、またはトランスポート メッセージの一方向ストリームの終了を通知する必要があります。
- 長さフィールド: ノイズ メッセージの長さは最大 65535 バイトになる可能性があることを考慮して、アプリケーションはノイズ メッセージのフレーミングまたは追加の長さフィールドを処理する必要があります。明示的な長さフィールドが必要な場合は、アプリケーションで各メッセージの前に 16 ビットのビッグ エンディアン長さフィールドを追加することをお勧めします。
- ネゴシエーション データ: アプリケーションは、ハンドシェイクの前、または各ハンドシェイク メッセージの前に、ネゴシエーション データの送信をサポートすることを望む場合があります。ネゴシエーション データには、Noise プロトコルのバージョン情報や識別子などが含まれます。たとえば、シンプルなアプローチは、各 Noise ハンドシェイク メッセージの前に 1 バイトの型フィールドを送信することです。より柔軟なアプローチは、protobuf などの拡張可能な構造を送信することです。ネゴシエーション データは、ロールバック攻撃などの重大な複雑さとセキュリティ リスクをもたらします (次のセクションを参照)。
セキュリティに関する考慮事項 §14
このセクションでは、さまざまなセキュリティ上の考慮事項をまとめています。[50]
- 認証: 静的公開鍵を使用するノイズ プロトコルは、対応する秘密鍵が参加者によって所有されていることを確認しますが、リモート パーティの静的公開鍵が受け入れ可能かどうかを判断するのはアプリケーション次第です。これを行う方法には、公開鍵に署名する証明書 (ハンドシェイク ペイロードで渡される場合もあります)、事前構成された公開鍵のリスト、またはパーティが遭遇した公開鍵を記憶し、同じパーティが将来同じ公開鍵を提示するかどうかをチェックする「ピンニング」/「鍵の連続性」アプローチなどがあります。
- セッション終了: 攻撃者がトランスポートストリームを切り捨てるのを防ぐ
- ロールバック: 当事者がプロローグとして含まれていない以前のネゴシエーションに基づいてノイズ プロトコルを決定した場合、ロールバック攻撃が発生する可能性があります。これは複合プロトコルで特に発生するリスクであり、当事者間の通信がノイズ ハンドシェイクに先行する場合は注意が必要です。
- 静的キーの再利用: Noise で使用される静的キー ペアは、単一のハッシュ アルゴリズムで使用する必要があります。キー ペアは、Noise 以外や複数のハッシュ アルゴリズムで使用することはできません。すべての Noise プロトコルで同じハッシュ アルゴリズムが使用されている限り、静的キー ペアを異なる Noise プロトコルで使用することは可能です。(Noise の静的キー ペアを Noise 以外で再利用するには、使用が互いに危険にさらされないように、またセキュリティ証明が保持されるように、非常に慎重な分析が必要になります)。
- PSK の再利用: Noise で使用される PSK は、単一のハッシュ アルゴリズムで使用する必要があります。PSK は、Noise 以外や複数のハッシュ アルゴリズムで使用することはできません。
- 一時キーの再利用: ノイズ プロトコルのすべての当事者は、暗号化されたデータを送信する前に、新しい一時公開キーを送信する必要があります。一時キーは再利用しないでください。これらのルールに違反すると、壊滅的なキーの再利用が発生する可能性があります。これは、§7 のパターンと §7.3 の有効性ルールの背後にある 1 つの理論的根拠です。これは、一方向ハンドシェイクが送信者からのトランスポート メッセージのみを許可し、受信者からのトランスポート メッセージを許可しない理由でもあります。
- 公開鍵を秘密鍵として誤用する: 事前メッセージ公開鍵のパターンを使用し、ハンドシェイクが成功したということは相手側が公開鍵を知っていることを意味すると想定したくなるかもしれません。残念ながら、これは当てはまりません。公開鍵を無効な値に設定すると、予測可能な DH 出力が発生する可能性があるためです。たとえば、
Noise_NK_25519イニシエーターは、応答側の静的公開鍵を知らないにもかかわらず、無効な一時的な公開鍵を送信して、既知の DH 出力がすべてゼロになることがあります。当事者が共有秘密鍵で認証する場合は、それを PSK として使用する必要があります。 - チャネルバインディング: DH 機能によっては、悪意のある者が、公開鍵を無効な値に設定して予測可能な DH 出力を発生させることにより、同じ共有秘密鍵を導出する複数のセッションに従事する可能性があります (前の箇条書きのように)。また、公開鍵を同等の値に設定して、異なる入力に対して同じ DH 出力を発生させる可能性もあります。これが、§11.2 で説明されているように、高レベルプロトコルがckではなく、ハンドシェイクハッシュ ( h ) を使用して一意のチャネルバインディングを行う必要がある理由です。
- ノンスの増加: 暗号化に同じキーkでnのノンス値を再利用すると、悲惨な結果になります。実装では、ノンスのルールに注意深く従う必要があります。整数オーバーフローによりノンスがゼロに戻ることは許可されておらず、最大のノンス値は予約されています。つまり、当事者は 2⁶⁴-1 を超えるトランスポート メッセージを送信することはできません。
- プロトコル名: で使用されるプロトコル名は、
Initialize()使用されるすべてのキー (一時キー ペア、静的キー ペア、または PSK) のハンドシェイク パターンと暗号化機能の組み合わせを一意に識別する必要があります。同じ秘密キーが同じプロトコル名で異なる暗号化操作セットで再利用された場合、不正な相互作用が発生する可能性があります。 - 事前共有対称キー: 事前共有対称キーは、256 ビットのエントロピーを持つ秘密の値である必要があります。
- データ量:
AESGCM単一のキーで暗号化されるデータの量が増えると、暗号機能のセキュリティは徐々に低下します。このため、当事者は単一のキーで暗号化された 2⁵⁶ バイト (約 72 ペタバイト) を超えるデータを送信しないでください。このような大量のデータを送信する可能性がある場合は、別の暗号機能を選択する必要があります。 - ハッシュ衝突: 攻撃者がプロローグ データまたはハンドシェイク ハッシュでハッシュ衝突を発見した場合、当事者を騙してハンドシェイク データの異なるビューを持たせる「トランスクリプト衝突」攻撃を実行できる可能性があります。Noise を衝突耐性ハッシュ関数とともに使用し、弱点の兆候があればハッシュ関数を置き換えることが重要です。
- 実装フィンガープリント: このプロトコルを匿名のパーティとの設定で使用する場合、実装がすべてのケースで同じように動作するように注意する必要があります。これには、無効な DH 公開キーの処理について正確な動作を義務付ける必要がある場合があります。
実装
具体的なプロトコル
- I2P (ntcp2 ルーター)
- 稲妻
- libp2p
- FacebookのLibra / Diem（デジタル通貨）（2022年に廃止予定[67]）
- nQUIC [68]
- SlackのNebula、[2]「スケーラブルなオーバーレイネットワークツール」
- ワッツアップ
- ワイヤーガード
TLS1.3との比較
ノイズフレームワークとTLS 1.3の開発は、どちらも2014年から2018年にかけて行われました。RFC 8446の最初のドラフト[69]は2014年8月に作成され、28回のドラフトを経て2018年8月にProposed Standardがリリースされました。メーリングリストには、提案との比較に関する短いスレッド[70]OPTLSがありました。[71]
参照
一般的な暗号の意味でノイズが使用される他の例:
参考文献
- ^ 「ノイズプロトコルフレームワーク - IPR」。noiseprotocol.org 。2024年12月15日閲覧。
- ^ ab slackhq / nebula、Slack、2024-12-15、2024-12-15取得
- ^ ab 「ノイズ プロトコル フレームワーク - ノイズ パイプ」。noiseprotocol.org 。2024年 12 月 15 日閲覧。
- ^ 「ノイズプロトコルフレームワーク - 処理ルール」noiseprotocol.org . 2024年12月15日閲覧。
- ^ ダウリング、ベンジャミン、ロスラー、ポール、シュウェンク、ヨルグ（2020）、「柔軟な認証および機密チャネル確立（fACCE）：ノイズプロトコルフレームワークの分析」、コンピュータサイエンスの講義ノート、Cham：Springer International Publishing、pp. 341–373、doi：10.1007 / 978-3-030-45374-9_12、hdl：20.500.11850 / 399156、ISBN 978-3-030-45373-2、 2024-05-17取得
- ^ Kobeissi, Nadim; Nicolas, Georgio; Bhargavan, Karthikeyan (2019 年 6 月)。「ノイズ エクスプローラー: 任意のノイズ プロトコルの完全自動モデリングと検証」。2019 IEEE欧州セキュリティおよびプライバシー シンポジウム (EuroS&P)。IEEE。pp. 356–370。doi :10.1109/ eurosp.2019.00034。ISBN 978-1-7281-1148-3。
- ^ 「ノイズエクスプローラー：パターンの探索」noiseexplorer.com . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - 理論的根拠」noiseprotocol.org . 2024年12月15日閲覧。
- ^ “Elligator”. elligator.org . 2024年12月15日閲覧。
- ^ チェン、リクン;クドラ、キャロライン。パターソン、ケネス G. (2004)。 「同時署名」。カチンではクリスチャン。 Camenisch、Jan L. (編)。暗号学の進歩 - EUROCRYPT 2004。コンピューターサイエンスの講義ノート。 Vol. 3027. ベルリン、ハイデルベルク：シュプリンガー。 287–305ページ。土井：10.1007/978-3-540-24676-3_18。ISBN 978-3-540-24676-3。
- ^ 「認証キー交換のセキュリティ強化」( PDF) 。Microsoft。
- ^ ab 「鍵交換プロトコルにおける匿名性と一方向認証」(PDF) . cacr.uwaterloo.ca .
- ^ 「OPTLS と TLS 1.3」(PDF) . www.ndss-symposium.org .
- ^ 「マイク・ハンバーグ」iacr.org . 2024年12月15日閲覧。
- ^ 「Strobe Protocol Framework」www.cryptologie.net . 2024年12月15日閲覧。
- ^ 「進行中の仕様を追加します。 · noiseprotocol/noise_spec@213237c」。GitHub 。 2024年12月15日閲覧。
- ^ “rev34draft -> rev34 · noiseprotocol/noise_spec@ecdf084”. GitHub . 2024年12月15日閲覧。
- ^ “ホーム”. GitHub . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - プロトコル名と修飾子」noiseprotocol.org . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - ハンドシェイクパターン名セクション」noiseprotocol.org . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - 暗号化アルゴリズム名セクション」noiseprotocol.org . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - DH関数、暗号関数、ハッシュ関数」。noiseprotocol.org 。2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - 暗号関数」。noiseprotocol.org 。2024年12月15日閲覧。
- ^ 「非公式暗号アルゴリズムリスト」。GitHub 。2024年12月15日閲覧。
- ^ "secp256k1". neuromancer.sk . 2024年12月15日閲覧。
- ^ “FourQ”. neuromancer.sk . 2024年12月15日閲覧。
- ^ “P-256”. neuromancer.sk . 2024年12月15日閲覧。
- ^ “P-384”. neuromancer.sk . 2024年12月15日閲覧。
- ^ “P-521”. neuromancer.sk . 2024年12月15日閲覧。
- ^ 「クラヴァッテ」。ケチャックチーム。2024 年 12 月 15 日に取得。
- ^ “Keccak Team”. keccak.team . 2024年12月15日閲覧。
- ^ 「KangarooTwelve: Keccak-p に基づく高速ハッシュ」keccak.team . 2024 年 12 月 15 日閲覧。
- ^ 「なぜ KangarooTwelve は 12 ラウンドしか使用しないのか?」Cryptography Stack Exchange 。 2024 年 12 月 15 日閲覧。
- ^ 「ノイズプロトコルフレームワーク - プロローグ」。noiseprotocol.org 。2024年12月15日閲覧。
- ^ 「ノイズ プロトコル フレームワーク - 一方向ハンドシェイク パターン」。noiseprotocol.org 。2024年 12 月 15 日閲覧。
- ^ 「ノイズプロトコルフレームワーク - インタラクティブハンドシェイクパターン（基本）」noiseprotocol.org 。 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - アイデンティティ隠蔽」noiseprotocol.org . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - インタラクティブなハンドシェイクパターン（延期）」noiseprotocol.org 。 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - 付録」noiseprotocol.org . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - 複合プロトコル」。noiseprotocol.org 。2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - 複合プロトコルの根拠」noiseprotocol.org . 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - フォールバック修飾子」。noiseprotocol.org 。2024年12月15日閲覧。
- ^ 「ノイズ プロトコル フレームワーク - Zero-RTT とノイズ プロトコル」。noiseprotocol.org 。2024年 12 月 15 日閲覧。
- ^ 「[ノイズ] NLS?」. moderncrypto.org . 2024年12月15日閲覧。
- ^ 「[noise] NoiseLink のカスタマイズ」. moderncrypto.org . 2024年12月15日閲覧。
- ^ 「[ノイズ] ドキュメントのステータスと計画」moderncrypto.org . 2024年12月15日閲覧。
- ^ "nls_spec/output/nls.pdf at master · noiseprotocol/nls_spec" (PDF) . GitHub . 2024年12月15日閲覧。
- ^ 「noisesocket_spec/output/noisesocket.pdf at master · noiseprotocol/noisesocket_spec」(PDF) . GitHub . 2024 年 12 月 15 日閲覧。
- ^ 「ノイズプロトコルフレームワーク - アプリケーションの責任」noiseprotocol.org 。 2024年12月15日閲覧。
- ^ 「ノイズプロトコルフレームワーク - セキュリティに関する考慮事項」noiseprotocol.org 。 2024年12月15日閲覧。
- ^ rweather (2024-12-07)、rweather/noise-c 、2024-12-15取得
- ^ ミハイロビッチ、ネマニャ (2024-11-18)、Metalnem/ノイズ、 2024-12-15取得
- ^ Giacomo、Gerardo Di (2024-11-16)、gedigi/noisecat 、 2024-12-15取得
- ^ aeternity/enoise、æternity、2024-09-14、2024-12-15取得
- ^ rweather (2024-11-27)、rweather/noise-java 、2024-12-15取得
- ^ Mokrynskyi, Nazar (2024-05-17)、nazar-pc/noise-c.wasm 、2024-12-15取得
- ^ haskell-cryptography/cacophony、Haskell Cryptography Group、2024-09-23、2024-12-15取得
- ^ flynn/noise、Flynn、2024-12-02、2024-12-15取得
- ^ Angel, Yawning (2024-11-26), Yawning/nyquist 、2024-12-15閲覧
- ^ 「NoiseGo/noise at master · mimoo/NoiseGo」。GitHub 。 2024年12月15日閲覧。
- ^ ab OuterCorner/Noise、Outer Corner、2024-11-18、2024-12-15閲覧
- ^ Lizończyk、Piotr (2024-12-07)、plizonczyk/noiseprotocol 、 2024-12-15取得
- ^ Tarek (2024-11-12), tgalal/dissononce 、2024-12-15閲覧
- ^ 山口 (2024-06-28), 山口/ノイズ、2024-12-15閲覧
- ^ McGinty, Jake (2024-12-15), mcginty/snow 、2024-12-15閲覧
- ^ Guanhao, Yin (2024-12-05)、blckngm/noise-rust 、 2024-12-15閲覧
- ^ Victor (2024-12-02). 「David MarcusがLibraがシャットダウンされた理由を明かす」Altcoin Buzz 。 2024年12月15日閲覧。
- ^ Hall-Andersen, Mathias; Wong, David; Sullivan, Nick; Chator, Alishah (2019)、nQUIC: ノイズベースの QUIC パケット保護、 2024 年 12 月 15 日取得
- ^ Rescorla, Eric (2018 年 8 月). トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3 (レポート). インターネット エンジニアリング タスク フォース.
- ^ "[noise] TLS 1.3". moderncrypto.org . 2024年12月15日閲覧。
- ^ 「OPTLS プロトコルと TLS 1.3」(PDF) . eprint.iacr.org . 2015-10-09.
外部リンク
- 仕様とWikiを備えた公式ウェブサイト
- Githubリポジトリ
- 2017 年の講演「ノイズ プロトコル フレームワーク」のスライド
- ノイズ プロトコル フレームワークの紹介
- ノイズプロトコルフレームワークを使用して分散機能システムを設計する
- ノイズキャット：ノイズのスイスアーミーナイフ
プレゼンテーション:
- トレバー・ペリンによるReal World Crypto 2018での20分間の講演
- デビッド・ウォンによる25分間の講演