認証・電子署名・認証局

学習目標

本講を終えると、以下の問いに答えられるようになる。

• 「認証」と「暗号化」の違いを説明できる
• 認証の3要素(知識・所持・生体)が何かを答え、身近な例を挙げられる
• 多要素認証(MFA) がなぜ安全になるのかを説明できる
• 認証通過後にセッションID/トークンでログイン状態を継続する考え方を説明できる
• ハッシュ関数の役割(中身を見せずに一致を確認する)を説明できる
• 電子署名が「本人が書いたこと」と「改ざんされていないこと」を同時に保証する仕組みを、秘密鍵と公開鍵の言葉で説明できる
• 認証局(CA) がなぜ必要なのか、HTTPSの鍵マークが何を意味しているのかを説明できる

このレッスンの目次

認証とは何か

身近なたとえ:窓口での本人確認

銀行や役所の窓口で「免許証を見せてください」と言われた経験はありますね。あれは 「あなたが本当にあなた本人ですよね?」 を確認する作業です。コンピュータの世界でもまったく同じことが必要になります。インターネットでは相手の顔が見えないので、何らかの方法で「本人らしさの根拠」を示してもらわなければなりません。

図の見方:認証は「名乗り」をそのまま信じるのではなく、証拠を求めて照合する流れ。パスワード認証では、利用者が「合言葉を知っていること」を証拠として示す。

認証されるのは「人」だけではない

認証は人が機械にログインするときだけのものではありません。インターネットでは、機械が機械を認証する 場面もあります。たとえば、あなたのブラウザが銀行のWebサーバに接続するときに「このサイトは本物の銀行サーバか?偽物ではないか?」を確認しているのも認証です(これが後で出てくる HTTPSの鍵マーク の話)。

考えてみよう: 暗号化だけでは何が困るでしょうか。仮に通信が完全に暗号化されていても、相手がそもそも偽物のサイトだったら、あなたは 偽物に向けて 大事な情報を暗号化して送っていることになります。だから「中身を隠す(暗号化)」と「相手が本物か確かめる(認証)」は両方必要なのです。

認証の3要素

知識(Something you know)

本人だけが知っているはずの情報 を使う方式。最も歴史が古く、いまも一番よく使われています。

• パスワード・PIN(暗証番号):ログイン画面・銀行ATM・スマホのロック
• 秘密の質問:「母親の旧姓は?」「初めて飼ったペットの名前は?」

長所: 仕組みが単純で、特別な機器が要らない。 短所: 忘れる。盗み見・推測される。同じパスワードを使い回すと一気に被害が広がる。

所持(Something you have)

本人だけが持っているはずのモノ を使う方式。「これを持っているなら本人だろう」という発想です。

• キャッシュカード・社員証(IC カード)
• スマートフォンに届くSMS の確認コード
• 専用のセキュリティキー(USB トークンなど)

長所: 知識と違い、覚える必要がない。盗み見されただけでは突破できない。 短所: 紛失・盗難される。再発行に時間がかかる。

生体(Something you are)

本人の体そのものの特徴 を使う方式。生体認証(バイオメトリクス) とも呼ばれます。

• 指紋認証(スマホのホームボタン・PCのログイン)
• 顔認証(Face ID, 空港の自動化ゲート)
• 静脈・虹彩・声紋など

長所: 持ち歩く必要がなく、覚える必要もない。本人と一緒に常にある。 短所: 一度漏れた指紋情報は 変更できない(パスワードのように変えられない)。怪我などで使えなくなることもある。

3つを並べて比較

3つはそれぞれ 性質が違う(攻撃のされ方が違う) ので、これを 組み合わせる ことで安全性を高められる、という発想が次の節「多要素認証」につながります。

考えてみよう: 「秘密の質問」で「母親の旧姓は?」と聞かれることがあります。これは知識要素ですが、SNS や戸籍で調べれば分かる ことが多く、近年は安全性が低いとされています。本人しか知らない情報を作るのは、思った以上に難しい。

多要素認証(MFA)の意義

パスワードだけだと、何が困る?

MFAで使う3つの要素

図の見方:知識・所持・生体は攻撃される弱点が違う。MFA は同じ種類を重ねるのではなく、別タイプの証拠を組み合わせることで、片方が漏れても突破されにくくする。

認証後はセッション/トークンで覚える

ログインに成功した後、Webサービスは毎回パスワードを聞き直すのではなく、セッションID や トークン という一時的な通行証を発行します。次のアクセスでは、その通行証を見て「さっき認証を通った人だ」と判断します。

図の見方:セッションIDやトークンは、認証通過後に渡される一時的な通行証。盗まれると本人のふりをされるので、HTTPSで守り、有効期限を短くし、ログアウト時に無効化する。

つながる知識: 銀行のATM は昔から「キャッシュカード(所持)+ 暗証番号(知識)」の2要素認証になっていた、と気づくと面白い。MFA はWeb の話だけではなく、社会のあちこちですでに当たり前に使われている発想です。

ハッシュ関数:中身を見ずに一致を確かめる

イメージ:データの「指紋」

たとえば長文のレポート(数十KB)をハッシュ関数に通すと、315f5bdb…edd3 のような 常に同じ長さ の文字列が出てきます。レポートの本文を1文字でも変えると、ハッシュ値はまったく別物に変わります。これにより、データの中身を実際に比較しなくても、ハッシュ値だけ照らし合わせれば 「中身が同じか/変わったか」が分かります。

図の見方:長さの違うどんなデータも、ハッシュ関数を通すと 同じ長さの「指紋」 になる。1文字変えると指紋がまるで別物になるのが鍵。逆方向(指紋から元データを復元)はできない=「一方向ハッシュ関数」と呼ばれる所以。

代表的なハッシュ関数 発展

• SHA-256:現在もっとも広く使われている。256ビット(64文字の16進数) の指紋を出す。HTTPSや電子署名で標準
• SHA-1:1995年策定。今は安全でないとされ、新規では非推奨
• MD5:1992年策定。現在は 衝突を作れる ことが知られていて、セキュリティ用途には使えない過去のファイル整合性チェックなどで残っている

考えてみよう: もしハッシュ関数の性質② (1ビット違えば別物) がなく、似たデータから似たハッシュ値が出てしまったら、何が困るでしょう。攻撃者が「ほとんど同じ別データ」を作り、ハッシュ値だけ流用して改ざんを隠せてしまう。これは 衝突攻撃 と呼ばれ、ハッシュ関数の安全性を揺るがします。

電子署名:本人性と完全性を同時に保証

仕組みのカギ:第8回で学んだ公開鍵暗号の「裏の使い方」

第8回(暗号の基礎) では、公開鍵暗号は 「公開鍵で暗号化、秘密鍵で復号」 という 機密性 のための使い方を学びました。電子署名は同じ鍵ペアを 逆向き に使い、目的も変わります:「秘密鍵で本人性を示す(=署名する)、公開鍵で検証する」。秘密鍵を持っているのは本人だけなので、署名できるのも本人だけ。一方、公開鍵は誰でも持てるので、誰でも検証できる、という非対称性が生きます。

5ステップで見る:署名の付与と検証

図の見方:メッセージ自体ではなく ハッシュ値 に署名するのがポイント。理由は2つ。① 公開鍵暗号の処理は重いので長文をそのまま暗号化すると遅い、② ハッシュ値は固定長なので扱いが楽。受信側は「再計算したハッシュ値」と「署名から復元したハッシュ値」が一致するかだけ見ればよい。

なぜ「本人性」と「完全性」を同時に保証できるのか

つながる知識: ハッシュ関数の 「1ビット違えば別物」 という性質がここで効いている。もしハッシュ関数が「似たデータから似たハッシュ値」を出すような関数だったら、攻撃者は本文を少し書き換えてもハッシュ値を一致させられてしまう=改ざん検出が壊れる。電子署名の安全性は、ハッシュ関数と公開鍵暗号の 両方の安全性 に支えられている。

認証局(CA):公開鍵に「お墨付き」を与える

身近なたとえ:免許証は警察(公安委員会) が発行する

あなたが「私はアリスです」と紙に書いて見せても、相手は信じません。ところが、警察(公安委員会) が発行した 運転免許証 を出せば、たいていのお店や役所で本人確認として通用します。これは 免許証そのもの ではなく、「警察という信頼される第三者」が発行している という事実が信用の根拠になっているからです。

インターネットでも同じ。「あなたの公開鍵」だけを渡しても相手は信用しません。でも、信頼される第三者(認証局) が電子署名で保証した公開鍵 = 公開鍵証明書 なら、相手は信用してくれます。

3ステップで見る:証明書が信用されるまで

図の見方:一度に全部を読むのではなく、申請 → 発行 → 提示と検証、の順に追う。CAは通信内容を運ぶ機関ではなく、「公開鍵が本物の持ち主のものか」を署名で保証する第三者。

CA がなかったら、どんな攻撃が成立する?

考えてみよう: 信頼される第三者 = ルート CA に間違いがあったら大事故になります。実際に過去には CA の不正発行事件もありました。だから CA 自身も厳しい監査を受けていて、不正があれば「ルート証明書をブラウザから外される(=信用されなくなる)」という強い罰則があります。

HTTPSの鍵マーク:ここまでが裏でつながる

5ステップで見る:ブラウザの中で起きていること(概略)

図の見方:鍵マークは「①〜③ で身元確認 → ④〜⑤ で暗号通信」が成立した印。詳しい手順(TLSハンドシェイク)は 標準 編で扱う。

鍵マークがついていても 「絶対安全」ではない

つながる知識: 第7回(電子メール) で学んだメール送信元の偽装(差出人なりすまし) も、送信元サーバを電子署名で確かめる仕組み(SPF/DKIM/DMARC) で防げます。これも電子署名と鍵管理の応用例。考え方は HTTPS と同じで、「公開鍵を信頼ある形で公開し、署名を検証する」という流れになります。

まとめと用語チェック

用語チェック

確認問題