TLS1.3とNoiseプロトコル

wolfSSL では TLS 1.3 を推進していますが、DTLS、QUIC、SSH、MQTT、Noise などの他のプロトコルがあることも知っています。この投稿では、TLS 1.3 とNoiseを比較対照し、FIPS-140 とポスト量子暗号についていくつかのコメントを提供しようと思います。

Noise自体はプロトコルではありません。Noiseはプロトコル フレームワークです (ここに TLS 1.3 と Noise の最大の違いがあります)。 TLS 1.3 を使用することで、接続は認証され、機密性が高く、整合性が保証されます。これらの特性をTLS1.3で実現するのは非常に簡単で効率的です。 TLS 1.3 を実行する wolfSSL のサンプル サーバーおよびクライアント アプリケーションのすべてはわずか数百行のコードで、最も単純なものはすぐに 100 行以下になります (参照)。これを、必要なセキュリティ 属性に応じて独自のNoiseベースのプロトコルを設計する必要があるという要件と比較すると、Noiseは TLS 1.3 よりも少し難しいように見えます。実際専門知識が必要とされます。使用できる基本的なパターンについては、こちらのドキュメントのセクション 7.5 を参照してください。

次に大きな違いは認証です。 TLS では通常、クライアントがサーバーの身元を確認できるために、サーバーに X.509 証明書が必要です。サーバーの身元は、証明書を介して公開鍵にバインドされ、秘密鍵の所有をクライアントに証明することによって検証されます。 Noise Framework は ID 検証をサポートしていません。それはアプリケーションに任せます。ただし、静的な暗号鍵を使用することはできます。これにより、両者が過去に通信していたのと同じ相手と通信していることが保証されます。繰り返しになりますが、これを達成するには正しいパターンを設計または使用してから、ID 検証をアプリケーションに設計する必要があります。

TLS 1.3 は暗号化アルゴリズムを標準化し、NIST はそこで使用するアルゴリズムに関するガイダンスを提供します。その結果、私たちは簡単にFIPS-140 に準拠することができます。たとえば、私たちのFIPS 認定製品の上でwolfSSL のデフォルトを使用するだけでOKです。一方、Noiseについては、NIST はガイダンスを提供していないため、プロトコルを設計したり、パターンを選択したりするときは、自分で行う必要があります。

wolfSSLはTLS 1.3 でポスト量子暗号を実行できますか? はい!Supported Group拡張と署名アルゴリズムの拡張には、カスタム用のコード ポイントがあります。ただし、ポスト量子アルゴリズムが標準化されると、標準のコードポイントと OID が制定されるはずです。ポスト量子署名スキームと KEM (キー カプセル化メカニズム) のメカニズムと暗号化アーティファクトは、TLS 1.3 ハンドシェークと X.509 証明書 PKI に非常にうまく適合します。詳細についてはwolfSSL のポスト量子 TLS 1.3 に関するドキュメントを参照してください。

一方、Noiseフレームワークはどうでしょうか?答えはノーです。プロトコル フレームワークは、Diffie-Hellman 鍵交換プロトコルの「非対話性」に依存しており、KEM は対話型です!この記事の執筆時点では、ポスト量子向けの非対話型鍵交換アルゴリズムは知られていません。ただし、さまざまな可能性に関する研究が進行中であり、Noise プロトコルフレームワークは最終的にポスト量子アルゴリズムをサポートするように進化する可能性があります。たとえば、こちらを参照してください。