共通鍵暗号方式
AはBへ手紙を送ろうとしています。
しかし、このまま送ると、途中で盗みされるかもしれませんので、鍵を使って手紙を暗号化してから送付します。
それを受け取ったBは同じ鍵を使った復号します。
暗号化も復号化も同じ鍵を使うところから、共通鍵暗号化方式と呼ばれています。
共通鍵暗号方式の問題点：鍵配送問題
共通鍵暗号方式には一つクリティカルな問題点があります。
それは、鍵配送問題です。
Aは暗号化された手紙をBに送付する際に、Cに盗み見されるリスクがあります。
これだけなら、Cは手紙を入手できても復号することができないことから、内容を知りえないのです。
しかし、もしもAとBが実際の面識がない場合（ネット上なら、これがほとんどのケース）、Bが手紙を復号するには鍵が必要なので、Aは鍵をBに配送する必要がありますが、鍵を配送する際にも、Cに盗られるリスクがあります。
そうなると、Cは、暗号化された手紙と鍵の両方を手に入れることができるので、手紙の内容が漏洩されます。
公開鍵暗号方式
同じくAはBに手紙を送ろうとしています。
ここで、Bはまず公開鍵と秘密鍵を用意します。
公開鍵を鍵付きボックス、秘密鍵をそのボックスを開けるための鍵だとイメージすると理解しやすい.
Bは公開鍵をAに送付します。
（Bは鍵付きボックスをAに送付します。）
Aは公開鍵を使って手紙を暗号化します。
（Aは手紙を鍵付きボックスに入れます。）
Aは暗号化された手紙をBに送信し、Bは秘密鍵を使えば復号することができます。
（Aは鍵付きボックスをBに送付し、Bはそれを鍵で開ければ手紙を取り出すことができます。）
暗号化された手紙も公開鍵も、盗られるリスクはありますが、盗られても秘密鍵がないため復号することはできません。宝箱を手に入れても鍵がなければ開けられないと同様にです。
公開鍵暗号方式のメリットと問題点
公開鍵暗号方式は、Bが予め公開鍵（鍵付きボックス）を公開しておけば、Aに限らず、不特定多数の送信者は簡単かつ安全に暗号化した手紙をBに送付することができます（予め配送用のボックスを大量に配布するイメージ）。
一方で、公開鍵暗号方式には、暗号化と復号を含む処理速度が遅いという点以外にも、もう一つクリティカルな問題点があります。
公開鍵の信頼性によるman-in-the-middle攻撃の問題
Bは、Aから手紙を受け取るために、公開鍵をAに送付しますが、悪意のあるCは、途中で公開鍵をすり替えることができます（配送用の鍵付きボックスをすり替えます）。
Aは、何も知らないまま、その公開鍵を使って手紙を暗号化します（手紙をCのボックスに入れてしまいます）。
Aが暗号化された手紙をBへ送付する途中、Cはそれを盗みし、復号すれば元々の手紙を入手できます（Cはそのボックスを盗み、自分の鍵で開けてしまいます）。
Cは手紙の内容を入手できましたが、このままですと、Bにバレてしまいますので、ここからがポイントです。
Cは既にBの公開鍵を入手しているので、今度は、その公開鍵を使って手紙を暗号化し、Bへ送付します（手紙をBののボックスに入れて、Bに送ります）。
こうすれば、Bは問題なく自分の鍵を用いて復号することができますので、途中で盗み見されていることは闇に葬られます。
ハイブリッド暗号方式
AはBに手紙を送ろうとしています。
Bは公開鍵（配送ボックス）と秘密鍵を用意します。
Bは公開鍵（配送ボックス）をAに送ります（ここまでは公開鍵暗号方式と同様）。
Aは受け取った公開鍵（配送ボックス）を用いて、手紙ではなく共通鍵を暗号化し、Bに送ります（共通鍵をボックスに入れてBに送付します）。
それを受け取ったBは、持っていた秘密鍵（鍵）で復号すれば（ボックスを開ければ）Aと同じ共通鍵を手に入れることができます。
その後は、共通鍵を使い、共通鍵暗号方式でやり取りをすれば良いだけです。
ハイブリッド暗号方式は、処理速度が遅い、しかし安全にやり取りできる公開鍵暗号方式を用いて、処理速度の速い共通鍵暗号方式が抱える「鍵配送問題」を解決しています。その結果、安全性と速度の両立が成立され、SSL/TLSプロトコルに利用されています。
DH（Diffie-Hellman）法（ディフィーヘルマン鍵交換方法）
DH（Diffie-Hellman）法とも呼ばれるディフィーヘルマン鍵交換方法は、「鍵を合成する」というアプローチを取りますが、その前に、この方法の3つの特徴について触れておきます。
- 鍵を一旦合成すると、それを分離させることができない。
- 合成された鍵はまた別の鍵と合成することができる。
- 合成の順番は関係ない（同じ構成要素であれば同じ鍵となる）。
理解しやすくするために、「ある料理のレシピがあり、その隠し味を出すためには、秘密の調味料が必要になりますが、この秘密の調味料は2人の料理人によって、それぞれが持ち合わせている自前の調味料をブレンドすることにより共同開発される」とイメージしましょう。（以下の例では、中華調理師とフレンチシェフによる開発を例にします。）
ようは、2人の料理人が共同で新たな調味料を開発します。そのためには、それぞれが各自で既に開発した調味料を材料にブレンドします。
このイメージから、上記の3つの特徴を言い換えると：
- 一旦調味料がブレンドされると、その中から元となる調味料を抽出することができない。
- ブレンドされた調味料を原材料に、また新しい調味料をブレンドし出すことができる。
- 原材料となる調味料の入れる順番は味に影響しない。
まずAがBに公開鍵Pを送ります。
続いて、AとBはそれぞれの秘密鍵SAとSBを用意します。
Aは、公開鍵Pと秘密鍵SAをP–SAに合成し、Bは公開鍵Pと秘密鍵SBをP–SBに合成します。その後、合成鍵を相手に送付します。
Aは、BからもらったP–SBに、元々持っているSAを加えてP–SA–SBという鍵を合成します。
Ｂも同じく、ＡからもらったP–SAに、元々持っているSBを加えててP–SB–SAという鍵を合成します。順番は関係ないので、お二人は、新たに同じ鍵を持つことになります。
この新しい鍵を使って安全に暗号化したり復号したりすることができます。
仮にCが色々な調味料を送付途中でで盗んだとしましょう。
Cは、P、P–SA、P–SBを手に入れることはできますが、分離させることができませんので、P–SAからSAを取り出すことも、P–SBからSBを取り出すこともできません。結果、P–SA–SBを作り出すことができません。
調味料の例で見てみましょう。
中華調理師はフレンチシェフに最初の調味料である塩を送ります。
続いて、中華調理師は醬油を用意し、シェフはオリーブオイルを用意します。
中華調理師は塩と醬油とブレンドし、Bは塩とオリーブオイルをブレンドします。その後、ブレンドした新しい調味料を相手に送ります。
中華調理師は、シェフから「塩+オリーブオイル」をもらったので、それに元々持っている醬油を加えて「塩+オリーブオイル+醬油」という新たな調味料にブレンドします。
同じく、シェフは、中華調理師からもらった「塩＋醬油」に、元々持っているオリーブオイルを加えることで「塩+オリーブオイル+醬油」という新しい調味料のブレンドに成功しますので、2人の料理人は同じ調味料を手に入れることができました。
この新しい調味料を使えば、二人とも秘密の隠し味を作ることができます。
仮に、配送しているときに、Cが途中で調味料を盗んだとしましょう。
Cが手に入れることができるのは、「塩」、「塩+オリーブオイル」、「塩＋醬油」ですが、「塩+オリーブオイル」から「オリーブオイル」を抽出することもできなければ、「塩＋醬油」から醬油を抽出することもできませんので、「塩+オリーブオイル+醬油」という調味料にブレンドすることはできません。
だって、「塩」、「塩+オリーブオイル」、「塩＋醬油」をブレンドしたところで、「塩」の量が通常の3倍にもなってしまいますからね。
デジタル署名とデジタル証明書の仕組み
これまで、安全に手紙を送る方法について見てきましたが、「送り手は誰だ」という問題が積み残しになっています。
これを解決する仕組みのとしては、「デジタル署名」と、第三者機関に認証してもらう「デジタル証明書」が挙げられますが、その前に、「デジタル署名」のベースとなる「メッセージ認証コード（MAC）」の仕組みをみていきます。
メッセージ認証コード（MAC）
Aは暗号化した手紙Bに送ります。
Aは鍵を作り、安全な方法でBに送付します。
続いて、Aは、暗号化された手紙とその鍵を使って、メッセージ認証コー（MAC）を作成し、Bに送付します
Bの手元には暗号化された手紙と鍵とメッセージ認証コー（MAC）がありますが、Bは、暗号化された手紙と鍵を使って、自分でもメッセージ認証コー（MAC）を作成します。
Bにより作成されたメッセージ認証コー（MAC）とAから送られたメッセージ認証コー（MAC）が一致していれば、その暗号化された手紙は、Aからの（改ざんされていない）オリジナルであることがわかります。
しかし、メッセージ認証コード（MAC）には一つの弱点があります。
結局のところ、AもBもメッセージの暗号化と同じメッセージ認証コード（MAC）の作成ができますので、「両者間のやり取り」であることは確定できるものの、「誰が送ったのか」という問題が依然として残っています。
極端な話、実際にはAが送ったのに、それはBの捏造であるととぼけることもできますし、Bが自ら捏造して、Ａから送られたと主張することもできます。
これを解決するのが、「デジタル署名」です。
デジタル署名の仕組み
公開鍵方式では、手紙の受け手が公開鍵と秘密鍵を用意し、公開鍵（鍵付きボックス）を送り手に送付するのですが、デジタル署名の仕組みとしては、手紙の送り手が自ら公開鍵と秘密鍵を用意します。
ということで、Aは手紙とともに、公開鍵（ボックスを開ける鍵）と秘密鍵（鍵付きボックス）を用意します。
AはBに公開鍵（ボックスを開ける鍵）をBに渡します。
続いて、Aは、秘密鍵を使って手紙を暗号化します（手紙を専用の鍵付きボックスに入れます）。
その後、Aは、元々の（暗号化されていない）手紙と暗号化された手紙（署名）をBに送付します。
それを受け取ったBは、先ほどもらった公開鍵（ボックスを開ける鍵）で暗号化された手紙を復号します（ボックスを開けます）。
復号された手紙と、一緒に送られてきた元々の（暗号化されていない）手紙の内容が一致すれば、送り手がAであることを確認できます。
メッセージ認証コード（MAC）と違うところは、手紙を暗号化できる秘密鍵はAしか持っていないので、暗号化できるのはAだけです。
デジタル証明書の仕組み
最後に、公開鍵第三者機関に認証してもらう仕組みを見て行きます。
Aは公開鍵をBに送付しようとしますが、その前に、Aはまず公開鍵とメールアドレス等の個人情報を第三者機関（認証局）に送付します。
第三者機関（認証局）は、届いた情報を確認した上で、認証局の秘密鍵を用いて、Aの公開鍵と個人情報をもとに、Aの（お墨付き）デジタル署名を作成します。
認証局はAの公開鍵とAの個人情報に、お墨付きデジタル署名を加えて1つのパッケージ（＝のデジタル証明書）にしてAに送り返します。
まとめると、このデジタル証明書には
まとめると、このデジタル証明書には
- Aの個人情報
- Aの公開鍵
- お墨付きデジタル署名
が入っています。
Aは、公開鍵をBに送付しようとしていましたが、お墨付きデジタル署名と自分の情報が入っているパッケージ（＝のデジタル証明書）があるので、公開鍵の代わりに、デジタル証明書をBに送付します。
Bはまず、このデジタル証明書にある個人情報（メールアドレス）がAの情報であるかを確認します。
続いて、Bは、認証局の公開鍵を取得し、お墨付きデジタル署名が認証局の署名であることを検証・確認します。
デジタル証明書に含まれている個人情報がAの情報であることとデジタル署名は認証局によって発行されたことを確認できましたので、Bは、デジタル証明書からAの公開鍵を取り出します。
まとめ
いかがでしたか？
この記事では、いくつかの暗号化の方式とSSL/TLSの仕組みを見てきました。
全く複雑ではない仕組みなのに、我々の通信の安全性に大きく貢献しているアルゴリズムになります。
言い換えれば、シンプルだけど非常に強力な仕組みと言えるでしょう。
暗号化技術やSSL/TLSのようなプロトコルは、デジタル時代のプライバシーとセキュリティを保護するための不可欠な要素です。これらの技術がなければ、私たちの個人情報やデータは容易に第三者に漏れるリスクが高まります。このような背景を考えると、暗号化やSSL/TLSの重要性がよくわかると思います。
おすすめ図書
こういったアルゴリズムをより詳しく知りたい方は以下の図書がおススメです。
網羅的にアルゴリズムを解説しており、非常に面白いのですが、やや専門的な部分もあるため、全く前提知識を持たない初心者は途中で挫折する可能性もあります。
そこでおすすめしたいのが、次の図書です。
タイトルにもある通り、「絵で見てわかる」、「図鑑」なので、様々なアルゴリズムを図解で解説しています。初心者の方はまずこちらから入ることをお勧めします。
コメント