TCP接続をまったく暗号化したいですか？ NoiseSocketができました

Hi％username％！



この世界のすべてがブラウザを中心に展開しているわけではなく、TLSが冗長であるか、まったく適用できない状況があります。 常に証明書が必要なわけではありません。非常に多くの場合、十分な通常の公開鍵があり、同じSSHを使用します。



そして、IoTがあります。そこでは、TLSを全体としてプッシュすることは一般に、気の弱い人にとってはタスクではありません。 そして、バランサーの後の全員が通常のHTTPを介して互いに通信するバックエンド。 そして、P2Pなど、ますます...



少し前まで、 Noise Protocol Framework仕様がネットワークに登場しました。 これは基本的に、安全なデータ転送のためのプロトコル設計者であり、ハンドシェークの段階とその後の動作を簡単な言語で説明しています。 著者は、Signalメッセンジャーの主要な開発者であるTrevor Perrinであり、ノイズ自体はWhatsAppで使用されています。 そのため、このプロトコルフレームワークを詳しく調べる大きな理由がありました。



そのシンプルさと簡潔さのおかげで、私たちは非常に気に入っており、セキュリティをTLSよりも劣らないが、何らかの点で凌ぐ、まったく新しいネットワーク層プロトコルと同じくらいギャッシングすることに基づいて決定しました。 DEF CON 25で発表し、とても温かく迎えられました。 彼と私たちについて話す時が来ました。



まず、NoiseSocket自体のコアについて少し説明します。

ノイズプロトコルフレームワーク

実際、Noise Frameworkで説明されているプロトコルは、送信された公開キーとそれらに対して実行されるDiffie-Hellman操作のシーケンスです。



ノイズプロトコルフレームワークの主な考え方は、ハンドシェイク中のすべてのアクションがプロトコルの状態に、したがって結果として生じるセッションキーに絶対的に影響するということです。 DH、つまりハンドシェイク中に送信または考慮されるすべての追加データは、ハッシュを使用して一般的な状態と混合され、その結果、共通の対称キーが形成されます。



これらはすべて、3つの部分で構成される単純な状態システム内で発生します。







ちなみに、デビッド・ウォンがそこでどのように機能するかについてかなり簡単に語っている英語のビデオがあります。







HandshakeStateは、トークンとメッセージの処理を担当します。



SymmetricStateはDHの結果から対称キーを生成し、新しいDHごとに更新します。 したがって、最初のDHの直後に、後続のデータ（静的キー、ペイロード）は、何らかの種類の対称キーで既に暗号化されています。

SymmetricStateは 、キー自体、オプションのプロローグ 、プロトコル名などの追加データもハッシュします。 これにより、プロトコルは全体的であり、データ転送のすべての段階で外部干渉から保護されます。



CipherStateは、単純な対称AEAD暗号+ナンス（カウンター）であり、何らかの種類のキーで初期化されます。これは、暗号化関数の呼び出しごとに増加します。



ノイズのプロトコルは、パターン、メッセージ、およびトークンで構成される特別な言語で記述されます。







たとえば、プロセスのサーバーとクライアントの静的キーを交換することで安全な接続を確立できるプロトコルの1つ、Noise_XXを考えてみましょう。



Noise_XX(s, rs):

-> e

<- e, ee, s, es

-> s, se









Noise_XXはパターンです。 メッセージのシーケンスとその内容について説明します。



（s、rs）は、クライアントとサーバーが静的（ s ）キーペアで初期化されることを意味します。 これらは一度生成されたものです。 rはリモートを表します。



ご覧のとおり、矢印の付いた3本の線があります。 1行-1メッセージ。 矢印は、誰が誰に送信するかを意味します。 右側の場合は、クライアントはサーバーに、そうでない場合はその逆です。



各行はトークンで構成されます。 これらは、コンマで区切られた1つまたは2つの文字式です。 1文字のトークンはeとsのみであり、それぞれ一時公開キーと静的公開キーを意味します。 エフェメラルは接続ごとに1回生成され、静的に再利用可能です。

一般に、ノイズでは、すべてのプロトコルは一時キーの送信から始まります。 したがって、Perfect Forward Secrecyが実現します。 一時的でない暗号スイートがすべてキャンセルされたときに、TLS 1.3でほぼ同じことが発明されました。



2文字のトークンは、クライアントキーとサーバーキーのいずれかの間のDiffie-Hellmanを意味します。 ご想像のとおり、4つのタイプがあります。

ee 、 es 、 se 、 ss 。 DHが作成されるキーに応じて、さまざまな機能を実行します。 たとえば、 eeは、トランスポートセッションの最終キーをランダム化するために必要であり、静的キーの参加を伴うDHは相互認証を担当します。



ご覧のとおり、パターンXXでは、クライアントの静的キーがサーバーに渡されます。逆も同様です。 したがって、ここでは3つのメッセージが使用されます。 クライアントが静的サーバーキーを持っていると仮定して（たとえば、XXを最初に作成したとき）、メッセージの数を2つに減らすパターンがあります。 さらに、0-RTTと呼ばれる最初のメッセージで暗号化されたデータをすぐに送信することが可能になり、サーバーからの応答時間が短縮されます。







ペイロードを各ハンドシェイクメッセージに追加できます。 トップレベルのプロトコル設定、同じ証明書、デジタル署名のみ、一般的には64kバイト以内であれば何でもかまいません。 すべてのノイズパッケージはこのサイズに制限されています。 このように解析が簡素化され、長さは常に2バイトに配置され、メモリを操作しやすくなります。







ハンドシェイクの結果、実際には、以前に発生したすべてのDHの結果である対称キーは2つしかありません。 1つはメッセージの送信用、もう1つは受信用です。 すべて、その後、暗号化されたパケットを送信でき、送信後に毎回ノンスをインクリメントします。



ノイズプロトコルパターンに加えて、各ケースで使用するアルゴリズムが特徴です。 仕様には、DH、AEAD、およびハッシュのアルゴリズムがリストされています。 より多くのノイズは何も必要としません。



DH：Curve25519、Curve448、

AEAD：AES-GCM、CchachaPoly1305、

ハッシュ：Blake2、SHA2



すべてのプリミティブは非常に高速で、RSAやその他のブレーキジャンクはありません。 もちろん、必要に応じて、自分でそれを行うことができますが、誰も禁止していません。

ノイズソケット

このすべての美しさを見て、それが次世代のトランスポートプロトコルの役割の理想的な候補であることに気付きました。 結局のところ、箱から出してすぐに、必要なすべてのセキュリティ機能、パフォーマンス、認証メカニズムを台無しにする機能があります。 また、予測されたコードサイズにより、最小のデバイスからでも通常の安全な接続を作成できます。 そして彼らは考え始めました。



私がGoで書いた最初のPoCは、新しい2017年頃のどこかです。 元のノイズにはほとんど何も追加されず、パケットの長さのみが追加されました。 私はそれをみんなに見せて、 Noise Mailing Listに書いて、6月末までに、より多くのプラットフォームに実装できる共通点にやっと到達しました。



それで、ノイズに何を追加することになりましたか？ 長い会話と数十のオプションの後、本質的に残っていることが3つだけありました。

1. 交渉データ
2. パディング
3. 処理ルール

交渉データ

これは、必要なものを何でも入れることができるバイトのセットです。 クライアントとサーバー間のアルゴリズムとパターンを調整するために必要です。 このバージョンでは、次のようになります。







わずか6バイトですが、サーバーが受信したノイズメッセージの処理方法を理解するにはこれで十分です。

パディング

彼が最終仕様にいたことをとても嬉しく思います。さもないと、誰もが自分で発明しなければなりません。 これはパッケージの配置です。これにより、実際のサイズを隠し、復号化を行わなくても内容が推測されるのを防ぐことができます。 これは、実際のパケットサイズを示す追加の2バイトの初期暗号化データとして実装されます。 あとはゴミを捨てるだけです。

処理ルール

これらは、サーバーがクライアントからメッセージを受信した場合、またはその逆の場合にサーバーがクライアントにどのように応答し、それを理解せず、別のプロトコルに切り替えたいかを示す簡単なルールです。

なんで？

Virgilには独自のPKIがあり、証明書を使用せずに公開キーを使用してすぐに安全な接続を確立し、上から再度検証する機能が本当に不足していました。 そして今、 NGINXモジュールを作成し、 NoiseSocketを介してバックエンド全体にサービスを提供し、静的キーのデジタル署名を追加できます。



NoiseSocketに切り替えるには、すべてを変更する必要があると思われますか？ しかし、違います。

Goで記述し、すでにHTTPサービスがある場合は、クライアントのDialTLSメソッドを置き換え、サーバーをリッスンするだけで、他のすべてはTLSで機能すると考えるでしょう。 これは、すべて実装したGoライブラリのおかげです。







もちろん、コードと仕様にはまだ多くの作業がありますが、地獄、TLSに代わるものがあります！



パブリックキーのみを使用して2つのノード間に安全なリンクを構築する場合、独自の何かを作成する必要はありません。 ノードが公開キーによって識別されることが多いTor、i2p、ビットコインは、添加物なしですぐにNoiseSocketを使用できます。



SSH、VPN、あらゆる種類のトンネルは、静的キーのデジタル署名を追加し、opensslを自分自身にドラッグすることなく、最小限のオーバーヘッドで本格的な安全なリンクを取得できます。LibsodiumまたはNaclを実行することもできます。



もちろん、コンパイルされた暗号プリミティブの概算サイズはアーキテクチャによって異なりますが、NoiseSocketの最小限の実装で30キロバイトまたは20キロバイトにも収まることが期待されます。 秘密鍵がハードウェアで配線されているデバイスでは、このソリューションには特別な代替手段がありません。

おわりに

TLS 1.3には大きな期待がありました。それは、ノイズのように、ハンドシェイクラウンドトリップが8-9から3に削減され、25519が追加されたためです。



第一に、彼らは証明書なしで、単にキーによって機能する機能を追加しないことに決めましたが、そのような提案がありました。

第二に、ed25519証明書はいつ表示されるか不明ですが、Noiseでは今日25519署名を使用できます。



さらに、ノイズのパターンの1つであるIK（0-RTT）は、WireGuard VPNの作成者から正式な正当性の証拠を受け取り、正しい選択への自信を強めました。



NoiseSocketの仕様に慣れておくことをお勧めします。一部のプロジェクトでは、TLSよりも適していると確信しています。 その間、私たちはあなたのコメントを待っています。

参照資料

ノイズソケット仕様

Github

ノイズプロトコルフレームワークの仕様