ITパスポート対策

暗号と電子署名

本試験の最頻出であり、最も間違えやすい単元です。誰のどの鍵を使うかで4通りあり、誤りの選択肢はその入れ替えで作られます。 鍵の使い分けを徹底的に整理します。

共通鍵暗号と公開鍵暗号

観点共通鍵暗号公開鍵暗号
使う鍵暗号化と復号に同じ鍵対になる2つの鍵(公開鍵と秘密鍵)
鍵を渡す相手通信相手だけに秘密に渡す必要がある公開鍵は誰に見られてもよい
n人が互いに通信するときの鍵の数n×(n-1)÷2 個2n 個(1人あたり2本)
処理速度速い遅い
代表的な方式AESRSA

共通鍵暗号の弱点は、鍵を安全に相手へ渡す鍵配送の問題と、相手が増えるほど鍵が急増すること(10人で45本)です。公開鍵暗号はこれを解決しますが、処理が遅くなります。

鍵の使い分けを表で固定する

次の表を丸ごと覚えてください。

やりたいこと送信者の操作受信者の操作
内容を秘密にして送りたい(暗号化)受信者の公開鍵で暗号化する受信者の秘密鍵で復号する
本人が書いたと証明したい(電子署名)送信者の秘密鍵で署名する送信者の公開鍵で検証する

迷ったときの原則は次のとおりです。秘密鍵は本人しか持っていないので、本人にしかできてはいけない操作に使います。 暗号文を開ける(復号)のは受信者本人だけであるべきなので受信者の秘密鍵、署名を作れるのは送信者本人だけであるべきなので送信者の秘密鍵です。逆に、公開鍵は誰でも入手できるので、誰がやってもかまわない操作、つまり暗号化と署名の検証に使います。

誤りの選択肢はほぼこの表の入れ替えです。「送信者の公開鍵で暗号化する」「受信者の秘密鍵で署名する」「送信者の秘密鍵で検証する」はいずれも誤りだと即座に判断できるようにしてください。特に、暗号化のときに登場するのは受信者の鍵だけ、署名のときに登場するのは送信者の鍵だけという点を意識すると混乱しません。

電子署名で何がわかるか

電子署名で確認できるのは、そのデータが確かにその送信者から送られたこと(なりすましの防止と否認防止)と、途中で改ざんされていないこと(完全性の確認)の2つです。

一方、電子署名は内容を秘密にする仕組みではありません。 「電子署名によって通信内容の機密性が確保される」という選択肢は誤りで、ここは非常によく出ます。

署名は文書そのものではなく、文書のハッシュ値に対して行います。ハッシュ関数は、入力データから固定長の値(ハッシュ値、メッセージダイジェスト)を求める計算で、次の性質を持ちます。

  • 同じ入力からは必ず同じハッシュ値が得られる
  • 入力が1文字でも違えばまったく違う値になる
  • ハッシュ値から元のデータを復元することはできない(一方向性)

受信者は、受け取った文書から自分でハッシュ値を計算し、署名を検証して得た値と一致するかで改ざんの有無を判断します。

ハイブリッド暗号

共通鍵暗号は速いが鍵配送に困る、公開鍵暗号は鍵配送に強いが遅い。この両方の良いところを取ったのがハイブリッド暗号方式です。

  1. 本文そのものは、その場で作った共通鍵で暗号化する(速い)
  2. その共通鍵を、受信者の公開鍵で暗号化して一緒に送る(安全に渡せる)
  3. 受信者は自分の秘密鍵で共通鍵を取り出し、その共通鍵で本文を復号する

大きなデータ本体を公開鍵で暗号化するわけではない点に注意してください。HTTPSもこの考え方で動いています。

デジタル証明書と認証局

公開鍵暗号にはもう1つ穴があります。手に入れた公開鍵が本当に相手のものかを鍵だけでは判断できず、攻撃者が偽の公開鍵を配れば中間者攻撃が成立します。

そこで登場するのが認証局(CA)です。認証局は、申請者の実在を確認したうえで、公開鍵と持ち主の情報をまとめたデジタル証明書(公開鍵証明書)を発行し、認証局自身の秘密鍵で署名します。利用者は認証局の公開鍵でその署名を検証することで、証明書の公開鍵が本物だと確認できます。失効した証明書は失効リスト(CRL)で確認できます。

HTTPSは、WebのHTTP通信をTLSで暗号化したものです。ブラウザはサーバのデジタル証明書を検証し、問題がなければ以後の通信を暗号化します。守られるのはブラウザとサーバの間の通信であって、サーバに保管された後のデータの安全までは保証しません。「HTTPSならサイトの運営者が信頼できる企業だと保証される」という選択肢も誤りです。

生田 陸人
ゆめさくエンジニア / 現役ソフトウェアエンジニア
編集 LuaGate編集部