ハイブリッド暗号 ― 鍵の準備と本文の保護を分担する

鍵を包むモデルからHPKEとTLS 1.3の鍵共有へ。公開鍵技術と共通鍵暗号を組み合わせる理由を図解します。

鍵の準備と、本文の保護を分担する

大きな資料を安全に送りたいとします。共通鍵暗号は本文を効率よく保護できますが、最初に鍵を共有する方法が必要です。公開鍵技術は、その準備を助けます。

公開鍵技術で鍵を確立し、共通鍵暗号でデータを保護する。 この組み合わせが、ここでいうハイブリッド方式です。HPKEの導入

古典暗号と耐量子暗号を組み合わせる「ハイブリッド」や、OIDCのHybrid Flowとは別の意味です。

最初の図解では、分かりやすい鍵を包んで送るモデルを使います。送信者が新しいランダムな共通鍵Kを用意し、この資料の暗号化に使います。

続いて受信者の公開鍵でKを保護します。受信者の秘密鍵は送信者へ渡しません。公開鍵自体が正しい相手に属することは、あらかじめ検証する必要があります。

図の小さい鍵と、大きい資料を別の箱として見てください。二つを分けて扱うのが、この構成の要点です。

本文は共通鍵Kを使うAEADで保護します。Kは受信者の公開鍵を使う適切な鍵輸送方式で保護します。

暗号化した本文 = AEAD(K, nonce, 本文)
保護した鍵     = 受信者の公開鍵で K を包む

これは役割を示す疑似表記です。そのまま組み合わせれば安全な暗号プロトコルになる、という実装手順ではありません。実装には確立された仕様とライブラリを使います。

現代のHPKEは、単に既存のKを暗号化する形ではなく、KEMとKDFで鍵素材から鍵を導き、AEADと組み合わせます。RFC 9180

送信するのは、暗号化した本文と保護した鍵、そして処理に必要なnonceなどです。共通鍵Kや受信者の秘密鍵を平文で添付するわけではありません。

図では二つの包みが同じ方向へ移動します。本文が巨大でも、公開鍵側の処理が担当するのは鍵に関係する小さな部分です。

鍵・アルゴリズム・付随情報の取り違えを防ぎ、受信時に改ざんを検証するところまでが仕組みの一部です。箱が二重なら自動的に安全、という意味ではありません。

鍵を包むモデルでは、受信者が秘密鍵を使ってKを取り出し、Kで本文を復号・検証します。図でも、小さい包みが開いてから大きい資料が開きます。

HPKEなら受信者はカプセル化データと自分の秘密鍵から鍵素材を得て、同じ手順で鍵を導きます。モデルと具体的な仕様の違いを意識してください。

認証タグの検証に失敗した本文は受け入れません。また、送信者の認証が必要なら、それを提供するモードや別の署名・認証も必要です。

HTTPSのTLS 1.3で一般的な証明書付きECDHEの流れでは、双方が一時的な鍵ペアを作り、公開側の情報を交換します。各自の秘密と相手の公開情報から同じ共有秘密を計算し、通信に使う鍵を導きます。

共通鍵そのものを公開鍵で暗号化して送っている、と説明しないことが大切です。図では、通信路を渡る青い情報から、両端で同じ緑の鍵が現れます。サーバーの認証は証明書と署名が担当します。TLS 1.3

TLS 1.3にはPSKを使う構成もあります。ここではECDHEを使う代表例を描いています。

答えはいいえです。鍵を包む構成もありますが、HPKEや鍵共有を使う構成では、送受信者が鍵を導く仕組みを使います。

共通するのは分担です。公開鍵技術が鍵の確立を助け、その後の本文は共通鍵の認証付き暗号で保護します。

次に「暗号化してあるから、送信者も本物だ」と考えそうになったら、電子署名の教材へ進んでください。秘密を守ることと、送信元・改ざんを確かめることの関係が整理できます。