6. Security Considerations (セキュリティに関する考慮事項)

6. Security Considerations (セキュリティに関する考慮事項)

このドキュメントで説明されているように、生の公開鍵の送信は、生の公開鍵が証明書全体よりも当然小さいため、無線送信のオーバーヘッドを削減することによって利点をもたらします。これらの鍵を解析および処理するためのコードサイズの観点からも利点があります。公開鍵を秘密鍵の所有に関連付けるための暗号手順も標準的な手順に従います。

ただし、主なセキュリティ上の課題は、公開鍵を特定のエンティティに関連付ける方法です。識別子と鍵の間に安全なバインディングがない場合、プロトコルは中間者攻撃に対して脆弱になります。このドキュメントでは、このようなバインディングを帯域外で行うことができると想定しており、Section 1 にいくつかの例を示しています。DANE [RFC6698] はそのようなアプローチの1つを提供します。これらの脆弱性に対処するために、拡張を使用する仕様では、識別子と公開鍵がどのようにバインドされるかを指定する必要があります。バインディングが帯域外で行われることを保証することに加えて、実装はそのバインディングのステータスを確認する必要もあります。

DANE を使用して公開鍵を取得する場合、これらの公開鍵は DNSSEC を介して認証されます。事前構成された鍵の使用は、生の公開鍵を認証するための別の帯域外の方法です。事前構成された鍵は一般的な Web ベースの e コマース環境には適していませんが、デバイス上で実行されているソフトウェアとサーバー側の通信エンドポイントとの間に密接な関係がある多くのスマートオブジェクト展開にとって、そのような鍵は合理的なアプローチです。帯域外公開鍵検証のために選択されたメカニズムに関係なく、システムのセキュリティを確保するために、展開の開始前に最も適切なアプローチの評価を行う必要があります。

攻撃者は、当事者が通常選択する証明書タイプとは異なる証明書タイプを選択させようとして、ハンドシェイク交換に影響を与えようとする可能性があります。

この攻撃の場合、攻撃者は1つ以上のハンドシェイクメッセージを能動的に変更する必要があります。これが発生した場合、クライアントとサーバーはハンドシェイクメッセージハッシュに対して異なる値を計算します。その結果、当事者はお互いの Finished メッセージを受け入れません。master_secret がなければ、攻撃者は Finished メッセージを修復できないため、攻撃が発見されます。