TLS v1.3の主な新機能の1つに0-RTTハンドシェイクプロトコルがあります。 事前共有鍵（PSK）を使用したこのような変則ハンドシェイクにより、クライアントは最初のフライトでサーバーに暗号化されたデータを送信できます。これは、組み込みデバイスのTLSに特に有用です。 IoTでは、数千あるいは数百万のデバイスがほんの小さな更新を定期的に報告しているというようなことがよくあります。
0-RTTを使用して、IoTデバイスはClientHelloに加えて「アーリーデータ(Early Data)」と呼ばれるすべての更新データを1つのフライトで送信できます。その後、サーバーはServerHello、EncryptedExtensions、Finishedメッセージと初期データの確認応答を1回のフライトですべて応答します。最後に、デバイスは最終フライトでEndOfEarlyDataとFinishedメッセージで応答し、セキュリティ上のループを閉じます。
サーバーからの応答を待つことなく、データがオフロードされていることがわかります。デバイスは小さな状態を保存し、応答時の割り込みの準備完了状態に戻ります。もし応答がタイムアウトしてしまったら、再度のClientHelloでデータを再送信できます。それに対応して、デバイスはハンドシェイクメッセージを処理し、接続を閉じ、更新を破棄することができます。
これは、処理と全体的なラウンドトリップ時間の点で非常に効率的です。しかし、リプレイ攻撃や前方秘匿性を含む潜在的なセキュリティ問題があります。
攻撃者はデバイスからのメッセージを再生できます。サーバは、PSKから直接導出された鍵を使用して初期のデータを解読するだけで、他の認証は実行されません。クライアントからの2回目のフライトがなければ、サーバーはそのコピーが無効であると認識しません。推奨される防御方法は一回限りのチケットです。各チケットには新しいPSKが含まれています。これは、サーバー間でチケットの共有データベースを必要とするという欠点があります。その代わり、各PSKと共に使用されるClientHelloからのユニークな値を格納することができます。
また、攻撃者はクライアントの最初のフライトを傍受し、サーバーにスパムを仕掛ける可能性があります。上記の例のようにアーリーデータに “状態変更”データが含まれている場合、サーバが悪意のコピーを処理してしまうと悲惨なことになります。 PSKが1回限りのものであれば、クライアントはサーバーとの同期を失い、完全なハンドシェイクが必要になります。サーバーは、クライアントがリプレイ攻撃を受けており、したがって、これはアプリケーションレベルで処理する必要があると解釈できます。
PSKが複数のメッセージに再利用されると、前方秘匿性は失われます。つまり、デバイスが侵害された場合、現在のPSKから派生したキーを使用して暗号化されたすべてのメッセージが解読されてしまうことです。推奨される防御策としては、チケットに短いタイムアウトを使用して脆弱性の期間を制限することです。
0-RTTを使用すると、サーバー側でより慎重なアーキテクチャが必要になりますが、クライアント側の受けるメリットは、その価値が十分にあります。
さらに詳しい情報は弊社問い合わせ窓口 (info@wolfssl.com, info@wolfssl.jp: 日本語)までお問い合わせください。
原文: https://wolfssl.com/wolfSSL/Blog/Entries/2017/9/13_How_to_use_the_0-RTT_rope_to_climb%2C_without_hanging_yourself!.html
wolfSSLホーム：www.wolfssl.jp (English：www.wolfssl.com)