パスキーはなぜフィッシングに強い？｜鍵と署名の仕組みを図解

目次

登録時に、役割の違う二つの鍵を作る

パスキーは、公開鍵暗号を使ったログイン用の認証情報です。登録時に鍵のペアを作り、役割を分けて管理します。［1］

• 秘密鍵：利用者側で保護し、ログイン要求への署名を作る
• 公開鍵：サービスがアカウントに結び付けて保存し、署名を検証する

鍵を管理して署名する仕組みを認証器と呼びます。スマートフォンやPCの機能、セキュリティキーなどが担います。ログイン先へ秘密鍵そのものを渡す必要はなく、公開鍵だけが漏れても、有効な署名を作ってログインすることはできません。

指紋・顔・PINは、認証器が鍵の使用を許可するときの確認方法です。パスキー利用時の生体情報は端末内で処理され、サイトへ顔画像や指紋を送って照合する流れではありません。ここで確認するのは鍵を使う利用者であり、現実世界の氏名や身元まで証明するものではありません。［2］

ログインでは、今回の要求に署名する

デジタル署名は、「対応する秘密鍵で作られた応答か」「署名対象のデータが変わっていないか」を確かめるためのものです。通信内容を隠す役割は、別途HTTPSが担います。

以下は、ブラウザーと認証器が同じ端末にあり、指紋・顔・PINによる利用者確認を求める例です。

図を大きく開く

最初にサービスが作るチャレンジは、今回の認証用の予測困難なランダム値です。サービスが応答と照合し、使い終えたチャレンジを再利用しないことで、過去の応答をそのまま再送する攻撃を防ぎます。［3］

署名には、このチャレンジに加え、要求元のサイトや認証器の情報も結び付きます。サービスは登録済みの公開鍵で署名を検証し、これらの情報が期待する内容と合うか、必要な利用者確認が行われたかも確かめます。［3］

もう少し詳しく：実際に署名するデータ

WebAuthnでは、認証器が次の連結データに署名します。［4］

authenticatorData || SHA-256(clientDataJSON)

• authenticatorData：RP IDのハッシュ、利用者の操作・本人確認を示すフラグなど
• clientDataJSON：チャレンジ、要求元の origin など
• ||：2つのデータを順に連結する記号

図では通信の細部を省き、これらを「署名に使うデータ」「検証用データ」とまとめています。

「秘密鍵で署名し、公開鍵で検証する」という関係は、デジタル証明書のCA・RA・VAを整理した記事でも扱っています。通常のパスキー登録では、利用者がCAへ証明書を申請するのではなく、サービスがアカウントと公開鍵の対応を管理します。

偽サイトでは、正規サイト用の鍵を使えない

正規サイトに似せた https://notes-login.example.net に誘導されたとします。パスワードなら、偽の入力欄にも同じ文字列を入力でき、攻撃者は受け取った文字列を本物のサイトで試せます。

パスキーでは、ブラウザーが把握する要求元と、鍵の利用範囲を使って判断します。Web向けの標準APIであるWebAuthnで重要になるのが、次の2つです。［4］

• RP ID：鍵を使えるサービスを識別するドメイン名。この例では notes.example.com
• origin：要求元を示す「通信方式・ホスト名・ポート」の組。正規サイトなら https://notes.example.com

ブラウザーは、呼び出し元のサイトが指定されたRP IDを使ってよいか確認します。無関係な notes-login.example.net が notes.example.com を名乗っても通りません。偽サイト自身のRP IDを使っても、認証器は正規サイト用の鍵を選びません。［4］

さらに、正規サービス側も応答のorigin、RP IDのハッシュ、チャレンジ、署名などを検証します。鍵を使える先を制限することと、返ってきた応答を検証することの両方が、フィッシング耐性を支えます。［3］

RP IDはURL全文との完全一致ではありません。条件を満たす親ドメインを指定したり、サービスが明示的に許可した関連サイトで利用したりできる仕組みもあります。名前や見た目が似ているだけのサイトに、利用範囲が広がるわけではありません。［4］

二要素認証でも、偽サイトに強いとは限らない

認証要素は、知っているもの・持っているもの・身体の特徴に分けられます。パスキーも、鍵の所持に加えて指紋・顔・PINによる確認を要求し、その結果をサービスが検証する構成なら、多要素認証として扱えます。［2］

一方、パスワードにSMSや認証アプリのコードを追加しても、偽サイトに入力したコードを有効な間に中継されるおそれがあります。「要素の数」と「入力先への結び付き」は別の話です。コードの有効期限が短いことだけでは、その場での中継を防げません。［5］

同期・復旧・別のログイン方法も確認する

パスキーには、複数端末へ同期するものと、特定の端末やセキュリティキーに固定するものがあります。同期型では、秘密鍵も保護された形で他の端末へ引き継がれます。「ログイン先に秘密鍵を渡さない」ことと、「秘密鍵が1台の端末から出ない」ことは区別しましょう。［2］

近くのスマートフォンで承認してPCにログインする使い方もあります。これはスマートフォン側で署名するもので、PCへの鍵の同期とは別の仕組みです。

登録した後は、次の点を確認しておきます。［5］［6］

• 紛失時に戻れるか：同期済みの別端末、予備のパスキー、サービスの復旧手順を確認する。同期に使うアカウントの保護・復旧も重要
• 別の入口が残っているか：パスワードやSMSでも入れるなら、その経路を狙われる余地がある。復旧手段を確保せず、まとめて削除しない
• 端末とログイン後を守れているか：マルウェアや、ログイン状態を維持するセッション情報の窃取は別に対策が必要。OS・ブラウザーの更新と画面ロックを続ける

パスキーで防ぎやすいのは、偽サイトにログイン情報を渡してアカウントを乗っ取られる攻撃です。偽の注文画面で個人情報を入力させる詐欺や、送金を促す誘導まで防げるわけではありません。

覚えておきたいのは、端末で鍵の使用を許可し、鍵は利用先に結び付き、サービスが今回の応答を公開鍵で検証するという分担です。この仕組みに、端末の保護と安全な復旧方法を組み合わせて使います。

参考資料

確認日：2026年10月12日。図は仕組みを整理した説明図です。特定サービスでの操作や実機試験を示すものではありません。

1. Google for Developers：Passkeys — 鍵の役割とサイトへの結び付き
2. FIDO Alliance：Passkeys — 生体情報、認証要素、同期型とデバイス固定型、別端末での利用
3. Google for Developers：Server-side passkey authentication — チャレンジ管理とサーバー側の検証
4. W3C：Web Authentication Level 3 — 2026年8月25日付のW3C勧告。§5.11、§6.3.3、§7.2の利用範囲・署名生成・検証
5. NIST：SP 800-63B-4 — §3.2.5のフィッシング耐性、§4の認証器管理、§5のセッション管理
6. FIDO Alliance：Recommended Account Recovery Practices — 認証器を失った場合の復旧と安全性