パスキーの「署名」とは何か。暗号化との違いから理解する

パスキーを調べていると必ず出てくる「署名」という言葉。暗号化と何が違うのか、ぼんやりしたまま読み進めていませんか?この記事では、暗号化との比較を軸に、パスキーの署名を丁寧に解体します。

まず「署名」と「暗号化」の目的を分ける

混乱の根本は、どちらも同じ公開鍵暗号の数学を使っているからです。でも目的が根本的に違います。

暗号化 署名
目的 内容を隠す 本人確認・改ざん検知
秘密鍵の役割 復号(受け取り側) 署名(送り出し側)
公開鍵の役割 暗号化(送る側) 検証(受け取り側)
鍵の方向 公開鍵 → 秘密鍵 秘密鍵 → 公開鍵

数学は同じなのに鍵の役割が逆転している。これが「似てるけど違う」という直感の正体です。

パスキー認証のフロー

パスキーでログインするとき、裏側では次のことが起きています。

1
サーバーがチャレンジを送る 使い捨ての乱数: a3f9c2e1…
2
デバイスが秘密鍵でチャレンジに署名する 署名 = 秘密鍵で(チャレンジを)数学的に変換
3
署名だけをサーバーへ送る 秘密鍵はデバイスから一切出ない
4
サーバーが公開鍵で検証する ハッシュ値が一致すれば認証成功

「署名」とは印鑑を押すこと

「名前を書く」より「印鑑を押す」のほうが近いです。

「この乱数(チャレンジ)を見たのはあなたですか?」という紙に、あなたにしか押せない印鑑を押して返す。印鑑を見れば「確かにあなたが押した」と証明できる。でも内容は隠れていない。

パスワード認証では「パスワードそのもの」を送っていました。パスキーでは「私はこの鍵を持っている」という証明書だけを送ります。本物のパスワードに相当するものが通信路を流れないので、フィッシングが原理的に成立しません。

検証は「復元」ではなく「照合」

ここが暗号化と混同しやすいポイントです。

// 暗号化の場合
暗号化 → 復号 → 元のデータが出てくる

// 署名検証の場合
署名を公開鍵で変換 → ハッシュ値A が出てくる
サーバーがチャレンジを自分でハッシュ化 → ハッシュ値B
A === B ? → 一致すれば認証成功

元のチャレンジそのものは出てきません。2つのハッシュ値を照合しているだけです。

改ざんはなぜ検知できるのか

仮に通信の途中でチャレンジが a3f9c2b1e8d4 に書き換えられたとします。署名は元のチャレンジに対して作られているので、公開鍵で検証すると別のハッシュ値が出てきます。サーバー側で計算したハッシュ値と一致しない → 改ざんがバレます。

チャレンジ自体を守っているのではなく、署名がチャレンジと1対1に対応していることで、すり替えが必ず露見する構造です。

2段階の不可逆性

パスキーの安全性を支えているのは、2層の「戻れない」処理です。

ハッシュ化
完全な不可逆

チャレンジ → ハッシュ値は一方通行。署名からハッシュ値は取り出せても、ハッシュ値から元のチャレンジには絶対に戻れない。

秘密鍵演算
実用上の不可逆

理論上は逆算できるが、十分な鍵長があれば宇宙の寿命より時間がかかる。署名から秘密鍵を推測することは現実的に不可能。

結果として「壊れた情報しか外に出ない」設計になっています。署名を盗まれても秘密鍵は推測できず、ハッシュ値が漏れても元データはバレない。

まとめ

  • 暗号化は「内容を隠す」、署名は「本人を証明する」。数学は同じ、鍵の役割が逆
  • チャレンジ(使い捨て乱数)に秘密鍵で署名し、公開鍵で検証する
  • 「戻す」のではなく「ハッシュ値同士を照合する」ことで検証する
  • 署名はチャレンジと1対1対応するため、改ざんとなりすましを同時に検知できる
  • ハッシュ化と秘密鍵演算の2段階の不可逆性が安全性を支えている

コメント

タイトルとURLをコピーしました