いつでも同じところに行き着くのさ(共通鍵)
ハローワールド。
鍵交換法、というと必ず出てくるDH法。今回はちょっとだけ詳しく調べてみました。
DH法について
Diffie-Hellman鍵共有法(DH法)は1976のWhitfield DiffieとMartin Edward Hellmanによる論文、“New directions in cryptography”で提案された鍵交換の実装方法の1つです。
直訳すると「新しい暗号の方向性」といった感じです。当該論文で実現したかったことは論文の概要に記載があります。
Widening applications of teleprocessing have given rise to a need for new types of cryptographic systems, which minimize the need for secure key distribution channels and supply the equivalent of a written signature.
遠隔処理の適用範囲が広がる中で、安全な鍵の流通経路の必要性を最小限に抑え、書面による署名に相当するものを提供する新しいタイプの暗号システムが必要とされている。
当時は、当然ながら公開鍵暗号方式というものはないので、共通鍵暗号で暗号化を行っていたと考えられます。
よくDH法の背景として語られる「非セキュアな環境での共通鍵の配送問題」ですが、当時の唯一の解決法は"secure key distribution channels"が有り、そこで共通鍵を受け渡していたという感じでしょうか。[1]。
“supply the equivalent of a written signature"については論文を読むと"one-way functions”、つまり一方向性関数のことについて示唆しています[2]。
また、そこから秘密鍵でメッセージを「復号」し、公開鍵で受け取ったメッセージを「暗号化」することで「真の一方向性関数」を生成できるという記載もあります。残念ながらDH法には其の機能はないですが。
いろいろな場所で聞いた事があるかもしれないですが、DH法が解決したいのは「非セキュアな環境でのセキュアな鍵の配送」、具体的には「通信チャネルが盗聴されている場合の安全な共通鍵の配送」を達成したかったものですね(実際にはもう1つ署名に相当するものの提供もあります)。
DH法の鍵交換方法
DH法はRFC2631"Diffie-Hellman Key Agreement Method"(日本語訳)などに記載がありますが、DH法以外の部分の式も色々と記載があります。今回はとりあえずDH法の核となる部分のみ記載します。
DHで利用するパラメータは下記となります。ここでが最終的に交換された鍵となります。
A(lice)さんとB(ob)さんはお互いに非セキュアな通信経路でお互いのみが知りうる事のできる共通鍵を作ろうと思い、DH法を利用することにしました。
まずは、秘密鍵を生成します。この時、となるように生成します。
そして下記の計算でお互いを獲得します。ただし、は剰余、つまりをで割った余りを求める計算です。
Alice:
Bob:
よく言われるのががバレなければは求められないというものです。つまりこれらのパラメータのうちはバレても全然問題ないという夢のような方法です。
因みにRFC3526におおよそ代表的なの値がまとまってます。これらはIPSECのIKE(RFC2409)プロトコルで利用されるものであり、IKE(そしてDH全般)ではは大体2が使われていると記載があります[3]。SSHの場合はDiffie-Hellman鍵交換入門に記載されていますが、としも固定の値を利用しているらしいです。
具体例
具体的な値を入れ込んで見てみます。
DH法はの値が大きければ大きいほど安全となりますが、ここではは小さな値にしてみます。
具体的に下記のパラメータで計算してみます。
そしてお互いのを交換し、AliceとBobでそれぞれを計算しましょう。
すごい(小並感)。
最後に
上記の計算をいろいろな値で試すことのできるサイトを作ってみました。
https://sa2taka.github.io/dh-viewer/
2, 3時間で作ったので完成度はかなりアレですが。
実際に論文内では書留などの物理的な手段での共通鍵の配送が主だった様子が示唆されています。 ↩︎
具体的にはKerberos認証でも有名なR.M Needhamについて記載があります。彼は今では当たり前であるパスワードのハッシュ関数によって保護する手段についてのパイオニアらしく(リンク先Wikipediaより)、 彼の作ったログインシステムを例示しています。 ↩︎
IKEではなく、その前身となったOrcleyプロトコル(RFC2412)のAppendix.Aにそのような記載がありますhttps://tools.ietf.org/html/rfc2412#appendix-A ↩︎