電子メールのセキュリティ（2） ～ 公開鍵暗号方式の疑問 ～

公開鍵暗号方式の誕生によって、どうやって鍵を安全に相手に渡すのかというそれまでの大問題が一気に解決し、安全な通信ができるようになりました。

公開鍵暗号方式では、情報の受け手（受信者）が鍵のペア（公開鍵と秘密鍵）を作成し、送信者に公開鍵を渡します。公開鍵で暗号化されたメッセージは、受信者のみが持つ秘密鍵でしか復号化できないため、途中で解読（盗聴）される危険はなくなります。なぜなら、秘密鍵を第三者が複製することはほぼ不可能だからです。

では、盗聴されないということは、第三者による「改ざん」も防ぐことができるでしょうか？

改ざんした第三者にも、本文にどう影響したのかわからないような無理やりの改ざんが行われる可能性はありますが、例えば、注文書の100個を1,000個というように内容を知り得えなければできない改ざんは防ぐことができます。

こうした見方をすればそのとおりですが、じつはこれだけでは盗聴も改ざんも可能性を完全に排除することはできません。

単純な理由です。情報の受け手（受信者）を「あなた」だとしましょう。

この場合は「あなた」が公開鍵を公開し、秘密鍵を保持しています。そして「あなた」の公開鍵で作成された暗号文が送られてきます。その暗号文を「あなた」の秘密鍵で正しく復号化できれば、盗聴もなく改ざんもされていないことになります。

公開鍵は誰でも手に入れることができるため、はっきり言えば送信相手が誰であろうと、「あなた」の秘密鍵で正しく復号化できれば、他に復号化できる第三者はいないため、盗聴も改ざんもされていないことになります。

しかし、立場を逆にした場合はどうでしょうか？

今度は「あなた」が情報を送る送信者の立場で考えてみましょう。「あなた」は送信相手（受信者）の公開鍵で暗号文を作成して送信します。ここで、本当に受信者がその人かどうか確信することができるでしょうか？

事前に電話でもしていれば話は別ですが、そうでない場合、メールアドレスから相手を確認できたとしても、公開鍵がその人のものである根拠がないのです。

お気づきでしょうか？つまり、安全な通信の根拠は、

公開鍵の作成者が受信者本人に間違いないことが前提

となっているのです。

この前提が崩れてしまうとすべての安全が崩壊します。

例えば、公開鍵が送信相手本人のものではなく、第三者が作成したものだったらどうでしょうか。

作成した暗号文はその第三者の秘密鍵で復号化されてしまい「盗聴」を防ぐことができません。そもそも、その第三者の秘密鍵でしか復号化することができなくなります。そのため「改ざん」も容易です。

このことからわかるとおり、

「なりすまし」の可能性を排除しなければ安全は確保できない

ということになります。

暗号通信において防止しなければならないのは「盗聴」「改ざん」「なりすまし」「否認」の4つでした。このうち「なりすまし」を防止しなければ、その他の3つ「盗聴」「改ざん」「否認」を防止することができません。

すなわち、キーとなるのは「なりすまし」をどうやって防止するかです。では、どうやって「なりすまし」を防止するのかですが、それが公開鍵暗号方式の最重要ポイントと言っても過言ではありません。

そのため、絶対的な方法があるわけではなく、公開鍵暗号方式でもデータや通信相手を検証していく必要があるのです。

犯罪者をゼロにすることができないように、なりすまし自体を防止する方法はありません。盗聴、改ざん、否認を含めて、それらが行われていないことを総合的に検証するしかないのです。

つまり、

「なりすまし」等を防止するのではなく行われていないことを証明していく

ことになります。

まず、公開鍵暗号方式において検証しなければならない疑問（疑い）をすべて列挙してみましょう。

例として「あなた」と「花子さん」が通信すると仮定して検証していきたいと思います。あなた自身だと思って考えてみてください。 まずは「あなた」が「花子さん」に暗号メールを送信する場合を考えてみましょう。

公開鍵暗号化方式で「あなた」を送信者とした場合の流れ

さて、疑わなければならないこととして、どんなことが挙げられるでしょうか？盗聴・改ざん・なりすまし・否認を状況ごとにもう少し詳細にみていきましょう。

1．送信相手が、本当に花子さん本人なのか？

メールアドレスが花子さん本人のものと間違いなければ、送信相手は花子さんで間違いありません。メールアドレスは世界唯一のユニークな文字列であり、世界に2つとないからです。

しかし「あなた」が「花子さん」と面識がない場合はどうでしょうか。迷惑メールでよくある手口で、Amazonや宅配業者など実在の企業の担当者になりすましたメールが世の中にあふれています。「なりすまし」の可能性を疑わなければなりません。

2．公開されている花子さんの公開鍵が、本当に花子さん本人のものなのか？

これは、1と同じことのようですが意味はまったく異なります。そして、ここが重要なポイントでもあります。

送信相手は花子さんに間違いなくても、公開鍵は文字どおり公開されているので、それが花子さんのものではなく、なりすましによる第三者のものである可能性があります。

公開鍵は花子さんと直接会って受け取るわけではありません。（そもそもそれができるなら暗号通信は必要ありません）花子さんではなく、悪意のある第三者が作成した公開鍵であった場合、情報はその第三者に復号化されてしまい、花子さんの秘密鍵では復号化できないということになります。「なりすまし」によって「盗聴」「改ざん」される可能性があります。

3．花子さんにメールが届いているか？

花子さんより返信があれば届いていることは確認できますが、返信を求めない一方通行のメールの場合は、花子さんから何らかの返信がない限り到着確認ができません。

受け取っていないと「否認」される可能性があります。

4．内容が盗聴されていないか？

秘密鍵を花子さん本人が大切に保管していれば第三者が盗聴することはできません。

しかし、1および2の疑問を解決する必要があります。「なりすまし」によって「盗聴」される可能性があります。

5．内容が改ざんされていないか？

1および2の疑問を解決しなければ「なりすまし」によって改ざんが可能になります。

また、または暗号化されたデータを無理やり改ざん（改ざんした第三者も本文にどう影響したのかわからないような改ざん）される可能性もあります。

以上が、送信者側から見た（あなたから花子さんに送信する際の）疑うべき点です。この5つについて検証を行えば安全な通信が可能になります。

今度は逆に「花子さん」が送信者となり「あなた」が受信する場合を考えてみましょう。「あなた」が鍵の作成者になります。

公開鍵暗号化方式で「あなた」を受信者とした場合の流れ

6．あなた宛ての暗号文が、本当に花子さん本人からのものなのか？

この場合は「あなた」が配布した公開鍵で暗号文が送られてきます。その暗号文が「あなた」の秘密鍵で復号化できれば、間違いなく「あなた」の公開鍵で作成された「あなた」宛ての通信であることは確定します。

しかし「あなた」の公開鍵は誰でも手に入れることができるので、相手が本当に花子さんであるのか確かめる必要があります。「なりすまし」の可能性を疑わなければなりません。

7．内容が改ざんされていないか？

「あなた」の秘密鍵で復号化するため、「あなた」が秘密鍵を大切に保管していれば、いかなる場合も第三者が盗聴することはできません。しかし、前述のとおり暗号化されたデータを無理やり「改ざん」される可能性があります。

8．花子さんがメールを送ったという事実を否定しないか？

「あなた」はメールを受け取っているのに、花子さんがそんなもの送っていないと「否認」する可能性があります。（つまり、誰かが花子さんになりすまして送ったと言い逃れをする）

以上が、受信者側から見た（あなが受信する際の）疑うべき点です。この3つについて検証を行えば安全な通信が可能になります。受信側では「あなた」自身の秘密鍵でしか復号化できないため、「盗聴」については完全に防止することができます。（自分の「なりすまし」は存在しないため）

こうして、送信と受信の場合で計8つの疑問について認証を行い、それぞれ正しいことを証明できれば、完全に安全な通信が行えたことになります。

重要なポイントは、もうおわかりのとおり「なりすまし」をどうやって防ぐかになります。さらに言えば、なりすましが行われていないことをどうやって証明するかです。

実際にどのような方法で「なりすまし」の検証を含め、これら8つの疑問は解決されるのでしょうか？

以後、少し難解な部分もありますが、こうした技術や仕組みについて学習していきます。まずは、もっともポピュラーな方法である「デジタル署名」について次項から学んでいきましょう。

更新履歴

2008年11月24日
ページを公開。
2009年5月22日
ページをXHTML1.0とCSS2.1で、Web標準化。レイアウト変更。
2018年1月30日
ページをSSL化によりHTTPSに対応。
2023年3月2日
内容修正。

参考文献・ウェブサイト

当ページの作成にあたり、以下の文献およびウェブサイトを参考にさせていただきました。

情報セキュリティ入門：ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060214/229302/?ST=security
電子証明書とPKI入門
http://www.verisign.co.jp/basic/pki/index.html