共通鍵暗号(暗号化と復号化に同じ鍵を使う方法)は鍵の受け渡し時と、鍵を複製する場合に別の鍵を作成しなければいけないという欠点がある。

その欠点を解消した公開鍵暗号についてまとめてみた。
SSHやSSLにおける文脈で使用されることも多く、基本的な考え方を覚えておくことは必須。

公開鍵暗号とは

公開鍵暗号(こうかいかぎあんごう、Public-key cryptography)とは、暗号化と復号に別個の鍵(手順)を用い、暗号化の鍵を公開できるようにした暗号方式である。
暗号は通信の秘匿性を高めるための手段だが、それに必須の鍵もまた情報なので、鍵を受け渡す過程で盗聴されてしまうというリスクがあった。共通鍵を秘匿して受け渡すには(特使が運搬するというような)コストもかかり、一般人が暗号を用いるための障害であった。この問題に対して、暗号化鍵の配送問題を解決したのが公開鍵暗号である。

https://ja.wikipedia.org/wiki/%E5%85%AC%E9%96%8B%E9%8D%B5%E6%9A%97%E5%8F%B7

暗号化について補足すると、暗号化とは情報セキュリティの分野では機密性(confidentiality)に相当し、また近年では下記の3要素を保証する必要がある。

・完全性(integrity)
データの改ざんをチェックする
真正性(authenticity)
なりすましでないかを確認する
否認防止(non-repudiation)
発行されたデータをなかったことにすることを防ぐ

つまり具体的にいうと、公開鍵暗号とは、

1)暗号化の手段として2種類の鍵を使用する。サーバー・クライアント間で鍵を交換する際に安全に受け渡すことができるよう(盗聴されても問題ない)公開可能な「公開鍵」と、公開しない「秘密鍵」。

2)暗号化と復号の処理で機密性を実現し、第三者からは送受信されるデータの解読しにくい暗号方式。

3)完全性・真正性・否認防止を担保するための、電子署名・認証機能。

上記の要件を持つ仕組みのことである。

ちなみに暗号化は可逆だが、パスワード管理などに利用されるハッシュ化は不可逆であるため、使い分けに注意を。

電子署名については、かみくだいて説明しているいい文章を発見した。
下記引用。

僕「じゃあ『鍵』という言葉を使わずに説明してみよう。暗号って『平文を暗号文に変換する方法』で伝えたい文章を暗号文に変えて送り、受け取った人はそれに『暗号文を平文に戻す方法』を使って元の文章を得るわけだ。その目的は、途中の通信文が敵に取られたりしても通信の内容がバレないようにするため。」
妻「うん」
僕「昔の暗号化の方法は、片方の方法がわかるともう片方の方法も分かった。例えば『アルファベットを後ろに1個ずつずらすと平文に戻せます』って教えてもらったら、『なるほど、前に1個ずつずらせば暗号文にできるんだな』ってわかるよね。ところがある時、片方がわかってももう片方がわからない素晴らしい暗号化の方法が発明された」
妻「ほう」
僕「つまり、『平文を暗号文にする方法』を不特定多数に公開しても平気になった。それをやっても『暗号文を平文に戻す方法』は自分しか知らないままに保てる。そうすると、僕に秘密の文章を送りたい人は、公開されている暗号化の方法で暗号を作ることができて、それを読むことができるのは僕だけってことになる。」
妻「なるほど、便利。」
僕「逆に、公開していない方法を使って僕が暗号文を作ると、みんなは公開されている方法で平文に戻して読むことができる。みんな『この暗号文を作るためには、西尾泰和だけの知ってる暗号化方法を使う必要がある=書いたのは西尾泰和』とわかるので署名として使うこともできる」
妻「それで暗号の話の中に署名の話が出てくるのね。ところで暗号文にする方法を公開するの?平文に戻す方法を公開するの?」
僕「あー、今まで便宜上『暗号文に変換する方法』と『平文に戻す方法』って呼んできたけど、これを方法Aと方法Bって呼ぶことにすると、方法Aで暗号文を作って方法Bで平文に戻すこともできるし、方法Bで暗号文を作って方法Aで平文に戻すこともできるんだ。ただ、Aで作ったらBで、Bで作ったらAで、と両方が必ず必要になる」
妻「なるほど、じゃあ片方の方法Aを公開しておけば、暗号文を受け付けるのにも、署名付きで情報公開するのにも使えるのね」

https://nishiohirokazu.hatenadiary.org/entry/20140809/1407556873

より具体的にいうと、電子署名はサーバー側で「任意のデータ」とそれをハッシュ化したハッシュ値に秘密鍵で暗号化した「電子署名」と「公開鍵」の3つを一緒に送信する。
クライアント側では電子署名を公開鍵で復号した「ハッシュ値」と「任意のデータ」をハッシュ化したハッシュ値が同様であるかを確認することで「改ざんの検知」「送信者の確認」を行い、電子署名が有効があることが確認できる。

公開鍵暗号は

  • 公開鍵で暗号化したデータは秘密鍵でしか復号できない
  • 秘密鍵で暗号化したデータは公開鍵でしか復号できない

という特徴を持っているため、公開鍵を取得したところで復号ができない。
また鍵はひとつだけで構わないため、共通鍵暗号の欠点を補うものとなる。

ただし、公開鍵暗号は共通鍵暗号よりも処理が複雑化し処理速度が遅くなる傾向があるため、公開鍵暗号で共通鍵を受け渡し後の通信は共通鍵暗号で行うという方式が使われたりすることがある(ハイブリッド式と呼ばれる)。

公開鍵証明書と認証局(CA – Certificate Authority)

公開鍵認証は誰の公開鍵かを知るすべがないため、鍵を盗まれ第三者が作成した公開鍵とすり替えられる「中間者攻撃」に弱い。
その公開鍵が誰が作成したのものなのかを証明するのが「公開鍵証明書」であり、「公開鍵証明書」などさまざまな証明書を扱っているのが認証局である。
認証局に公開鍵が誰のものであるかを登録し、その登録と引き換えに公開鍵証明書を発行する。発行された公開鍵証明書は内部的には「公開鍵+証明書」となっているため公開鍵の役割も持つ。
サーバー側はその公開鍵証明書をクライアントに送信し、クラアントは公開鍵がサーバーから送信されたものかを認証局に問い合わせることで、公開鍵が誰のものかがわかるという寸法である。

SSLサーバー証明書も同じような仕組みである。
具体的には誰のSSLサーバーかを証明するだけでなく、DV・CV・OVの三段階に分けて、信用度を示している(SSLサーバー証明書の情報はブラウザから確認できる)。
フィッシングサイトなどの偽メールに記載されている偽サイト(ときにはDNSの書き換えなどで直接偽サイトに誘導する方法もあるが)に対しては、このSSL証明書の信用度である程度推し量ることができる。

また通信の流れとしては、かなり簡略化すると次のようになる。

  1. クライアントがサーバーに対してリクエストを出す
  2. サーバーはクライアントにSSLサーバー証明書(サーバー側の公開鍵と証明書)を送る
  3. クライアントはSSLサーバー証明書を認証局に問い合わせる
  4. クライアントは共通鍵を作成する
  5. クライアントはSSLサーバー証明書の公開鍵で共通鍵を暗号化してサーバーに送信する
  6. サーバーはクラアントから送信された共通鍵を秘密鍵で復号し、今後の通信は共通鍵で行うようにする

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA