Dev Study
← セキュリティとAIの仕組み
レッスン 5 / 13·約 9 分·第4期 セキュリティとAIの仕組み

鍵を配る問題 — 対称鍵と公開鍵はなぜ両方要るのか

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力今ここ
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け今ここ
  5. Nginx受け口
  6. アプリ処理
  7. DB保存

前回、経路上の第三者に平文が読まれることを見ました。では暗号化すればよい——そこで必ずぶつかるのが「その鍵をどうやって相手に渡すのか」です。第22週のTLSハンドシェイクが何をしていたのかも、ここで繋がります。

まず結論

対称鍵だけの世界では「最初の1本をどうやって相手に届けるか」が解けません。RFC 4949 は、まだ鍵を共有していない2者に鍵を渡す役として**双方と既に鍵を共有している第三者**(KDC)を挙げています。

公開鍵系の道具が要るのはそのためです。ただし置き換えではありません。TLS 1.3 は鍵交換のモードを3つ持ち、事前共有鍵にも固有の難しさがあると明記しています。

? 読む前に予測

RFC 4949 の KDC(key distribution center)の説明では、KDCを必要とする2者はどういう状態にあるとされているでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

定義の中に、もう問題が書かれている

前回の結論は「秘匿は経路とは別の仕組みで与えるしかない」でした。暗号を使えばよい、という話になります。ところが暗号には鍵が要り、鍵は両者が持っていなければなりません。

RFC 4949 の定義を読むと、問題の所在がはっきりします。

"key distribution (I) A process that delivers a cryptographic key from the location where it is generated to the locations where it is used in a cryptographic algorithm."

生成される場所と、使われる場所が別であることが定義に入っています。ならば、その間を運ばなければなりません。そして運ぶ道は、前回見たとおり信頼できません。

「鍵を暗号化して送ればよい」と考えたくなりますが、その暗号にも鍵が要ります。同じ問題が1段ずれるだけです。

✓ ここまでの確認

RFC 4949 が定義する「鍵配送 (key distribution)」とは何をする過程ですか。

具体実物

対称鍵だけで解こうとすると、第三者が要る

対称鍵の世界でこの問題をどう解くか。RFC 4949 は KDC という仕組みを説明しています。

"A KDC distributes keys to Alice and Bob, who (a) wish to communicate with each other but do not currently share keys, (b) each share a KEK with the KDC, and (c) may not be able to generate or acquire keys by themselves."

条件 (b) に注目してください。AliceとBobは互いに鍵を持っていませんが、KDCとの間にはあらかじめ鍵があるという前提です。

対称鍵だけの世界で、鍵を共有していない2者が通信するには
AliceとBobが通信したい両者は鍵を共有していない× このままでは暗号化できない
経路で鍵を送る経路は信頼できない(前回)× 読まれうる
鍵を暗号化して送るその暗号にも鍵が要る× 問題が1段ずれるだけ
KDCを使う両者がKDCとは既に鍵を共有している○ セッション鍵を受け取れる
↓
解けるが、「あらかじめ誰かと鍵を共有していること」が前提として要る
  • ・前提を満たすには、いつか一度は鍵を安全に運ぶ必要がある
  • ・RFC 4949 は KDC を「対称暗号で使われる」鍵センターの一種として説明している

つまり対称鍵だけでも解けるには解けるのですが、「最初の1本」がどこかに必ず残ります。 KDCと鍵を共有する、その鍵はどう配ったのか、という問いです。

✓ ここまでの確認

TLS 1.3 (RFC 8446) が持つ基本的な鍵交換モードはいくつで、どれですか。

⇄ 2つを見比べる
具体例 A

KDC — 第三者と先に鍵を共有しておく

AliceとBobは互いに鍵を持っていませんが、両者ともKDCとは鍵を共有しています。だからKDCを経由してセッション鍵を受け取れます。ただしKDCとの鍵をどう配ったかは、この仕組みの外側の話です。

KDCが要求する前提表
解けること: AliceとBobのセッション鍵
前提:       両者がKDCとKEKを共有済み
具体例 B

PSK — 相手と先に鍵を共有しておく

TLS 1.3 のPSKモードは、両者が既に共有秘密を持っている前提で動きます。RFC 8446 §2.2 によれば、PSK は帯域外で用意することも、前回の接続で確立することもできます。前回の接続で得る再開用の PSK は最初のハンドシェイクから導出されるので、そのハンドシェイクが前提です。帯域外で用意する PSK には、RFC 8446 が固有の注意を置いています。

PSKが要求する前提表
解けること: 以降のハンドシェイク
前提:       帯域外で用意するか、前回の接続で得ておく

KDCとPSK。どちらも「先に共有しておく」形ですが、この形が共通して残してしまう問題は何でしょうか。

それぞれの仕組みが「解いていること」の一段下に、何が前提として置かれているかを見てください。

この章のまとめ

  • RFC 4949 の鍵配送の定義には、生成場所と使用場所が別であることが織り込まれている。だから運搬が要り、運搬経路は信頼できない。
  • 対称鍵だけで解こうとすると、双方と既に鍵を共有している第三者(KDC)が要る。ただしその第三者との鍵をどう配ったかは残る。
  • TLS 1.3 の鍵交換モードは 3つ((EC)DHE / PSK-only / PSK with (EC)DHE)。PSKを使うモードが2つ残っているので、「公開鍵が対称鍵を置き換えた」は誤り。
  • RFC 8446 は静的RSA・静的Diffie-Hellmanのスイートの削除と同じ項目に、公開鍵による鍵交換がすべて forward secrecy を提供することを併記している。
  • PSKにも固有の難しさがある。“Deriving a shared secret from a password or other low-entropy sources is not secure.”

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

「公開鍵暗号が登場したので、対称鍵はもう使われていない」——この説明の評価はどれですか。

用語集(4語)
鍵配送 (key distribution)
鍵が生成された場所から、暗号アルゴリズムで使われる場所へ鍵を届ける過程(RFC 4949)。生成場所と使用場所が異なることが定義に含まれている。
KDC (key distribution center)
対称暗号で使われる鍵センターの一種で、安全に通信したい2者(以上)へ鍵——通常はセッション鍵——を提供するもの(RFC 4949)。利用する2者は、あらかじめKDCとの間で鍵を共有している必要がある。
TLS 1.3 の3つの鍵交換モード
(EC)DHE、PSK-only、PSK with (EC)DHE の3つ(RFC 8446 §2)。静的RSAと静的Diffie-Hellmanのスイートは削除された(§1.2)。
事前共有鍵 (PSK)
あらかじめ両者が持っている共有秘密。RFC 8446 §2.2 によれば帯域外で用意するほか、前回の接続で確立することもできる。帯域外で用意する場合に十分なエントロピーが要り、パスワード等の低エントロピーな源から導出するのは安全でないと注意している。

出典(一次ソース)