パスキーはどのようにパスワードをなくすのか — WebAuthnとFIDO2の動作原理

パスキーでログインする際、ユーザーは指紋や顔、デバイスのPINを確認するだけで、長いパスワードを入力することはありません。一見すると生体情報がサーバーに送信されているように見えますが、実際の構造は異なります。

パスキーの核心は、サイトごとに個別の公開鍵・秘密鍵ペアを作成し、サーバーから送られたワンタイムのチャレンジに対してデバイスが電子署名を行うことです。サーバーには公開鍵のみが保存され、秘密鍵と生体情報は認証デバイスの保護領域から外に出ることはありません。

この記事では、まずパスキー、WebAuthn、FIDO2、認証デバイスがどのような関係にあるのかを整理し、その後、登録とログインのメッセージフロー、フィッシング防止の原理、同期パスキーとリカバリー設計までを詳しく見ていきます。

パスキー、WebAuthn、FIDO2は同じ言葉なのか

互いに密接に関連していますが、同じ用語ではありません。


用語	意味	担当範囲

—	—	—
Passkey	ユーザーがパスワードの代わりに使うFIDOベースのログイン資格情報	同期型または特定のデバイスに結合された公開鍵資格情報
WebAuthn	ウェブアプリケーションが公開鍵資格情報を作成・使用するためのW3CウェブAPI	ブラウザ・RPサーバー・認証デバイス間の登録と認証手順
CTAP	ブラウザ・OSなどのクライアントが外部認証デバイスと通信するためのFIDOプロトコル	USB・NFC・BLEセキュリティキーとプラットフォーム間の通信
FIDO2	WebAuthnとCTAPを組み合わせた公開鍵認証スキーム	ウェブと認証デバイスを包括する標準の集合

ウェブサイトのJavaScriptはnavigator.credentials.create()とnavigator.credentials.get()を呼び出します。ブラウザはオペレーティングシステムのパスキー保存場所やセキュリティキーなどのAuthenticatorと通信し、サーバーは返された署名を検証します。

웹 애플리케이션 ─ WebAuthn ─ 브라우저·운영체제 ─ CTAP ─ 외부 보안키
                                      └ 플랫폼 Authenticator

図: Passkey・WebAuthn・CTAP・FIDO2の構成関係 · W3C WebAuthn Level 3とFIDO Allianceの資料を基に再構成

パスワード認証と何が違うのか

パスワード方式では、ユーザーが知っている同じ秘密をサーバーと共有します。サーバーが平文の代わりに安全なハッシュを保存していても、ユーザーはログイン時にパスワードをサイトに提出する必要があります。偽サイトに入力すると、攻撃者がそのまま再利用できてしまいます。

パスキーは非対称鍵を使用します。

사용자 기기: 개인키 보관 + Challenge 서명
서비스 서버: 공개키 보관 + 서명 검증

秘密鍵は、ログインするサイトのRP IDに紐付けられて生成されます。ユーザーは秘密鍵の値を知る必要がなく、サーバーも秘密鍵を受け取りません。サーバーデータベースが流出して公開鍵が露出しても、その公開鍵だけで新しい署名を作成することはできません。

生体情報の役割も誤解されがちです。顔や指紋は、サーバーに自身を証明するログインデータではなく、デバイス内の秘密鍵の使用を承認するローカルなユーザー検証手段です。デバイスのPINも同じ役割を果たすことができます。

1. パスキー登録はどのように行われるのか

パスキー登録は、サーバーがユーザーのアカウントと新しい公開鍵資格情報を関連付けるプロセスです。

サーバーが登録オプションとチャレンジを作成する

サーバーは、十分なエントロピーを持つワンタイムのチャレンジ、RP情報、ユーザー識別子、許可されるアルゴリズム、ユーザー検証要件などを生成します。

{
  "challenge": "server-random-bytes",
  "rp": {"id": "example.com", "name": "Example"},
  "user": {"id": "opaque-user-id", "name": "user@example.com"},
  "pubKeyCredParams": [{"type": "public-key", "alg": -7}],
  "authenticatorSelection": {"userVerification": "required"}
}

チャレンジは、リプレイ攻撃を防ぐためにサーバーが信頼する環境でランダムに生成され、登録が完了するまでセッションと関連付けて一時的に保管される必要があります。

ブラウザが認証デバイスに鍵生成を要求する

ウェブアプリケーションはnavigator.credentials.create()を呼び出します。ブラウザは現在のOriginとRP IDの関係を確認し、ユーザーにパスキー生成UIを表示します。

ユーザーが生体認証またはデバイスPINで承認すると、Authenticatorが新しい公開鍵・秘密鍵ペアを作成します。秘密鍵とRP ID、ユーザーハンドルなどのCredential Sourceは、認証デバイスまたは安全なパスキー保存場所で管理されます。

サーバーは登録応答を検証し、公開鍵を保存する

ブラウザはCredential ID、Attestation Object、Client Dataなどをサーバーに送信します。サーバーは少なくとも以下を検証します。

返されたチャレンジが発行した値と一致するか
originが許可されたHTTPS Originであるか
rpIdHashが期待するRP IDのハッシュと一致するか
ユーザーの存在とユーザー検証フラグがポリシーを満たしているか
要求された公開鍵アルゴリズムが使用されたか
Attestationが要求された場合、信頼ポリシーを通過するか

検証が完了すると、サーバーはCredential ID、公開鍵、ユーザー関連情報、Sign CountやTransportなどの必要なメタデータを保存します。秘密鍵は保存しません。

図: WebAuthn登録セレモニーの主要メッセージと検証項目 · W3C WebAuthn Level 3登録手順を基に再構成

2. パスキーログインはどのように行われるのか

ログインは、サーバーが「このチャレンジに署名する秘密鍵を実際に持っているか」を確認するプロセスです。

サーバーが認証チャレンジを送信する

サーバーは新しいチャレンジとRP ID、許可される資格情報リスト、ユーザー検証ポリシーを提供します。Discoverable Credentialを使用すると、ユーザーが最初にIDを入力しなくても、ブラウザがそのサイトで使用できるパスキーを提案できます。

認証デバイスがユーザー承認後に署名する

ウェブアプリケーションがnavigator.credentials.get()を呼び出すと、ブラウザは現在のOriginとRP IDをAuthenticatorに渡します。ユーザーが指紋・顔・PINで承認すると、Authenticatorは以下の情報に秘密鍵で署名します。

authenticatorData || hash(clientDataJSON)

これには、RP IDのハッシュ、ユーザーの存在・検証フラグ、署名カウンター、およびサーバーチャレンジとOriginに接続されたデータが含まれます。

サーバーが公開鍵でAssertionを検証する

サーバーは登録時に保存した公開鍵を見つけ、電子署名を検証します。チャレンジ、Origin、RP ID Hash、UP・UVフラグ、Credential ID、署名アルゴリズム、およびポリシーを確認した後にのみセッションを発行します。

서명 유효 + Challenge 일치 + Origin 허용 + RP ID 일치 + 정책 충족
→ 로그인 성공

図: WebAuthn認証セレモニーとAssertion検証フロー · W3C WebAuthn Level 3認証手順を基に再構成

パスキーがフィッシングに強い理由

パスキーの秘密鍵は特定のRP IDに紐付けられています。example.comで作成された資格情報を攻撃者のexamp1e.comで使用しようとしても、ブラウザとAuthenticatorが異なるRP IDと判断するため、その秘密鍵を提供したり署名に使用したりすることはありません。

パスワードマネージャーはユーザーが警告を無視してパスワードをコピーする可能性がありますが、WebAuthnの秘密鍵はウェブスクリプトが読み取ってコピーする値ではありません。W3Cの仕様では、スクリプトが資格情報自体にアクセスできず、Credentialオブジェクト形式の結果のみを受け取るように設計されています。

サーバーも返されたoriginを必ず検証する必要があります。RP IDの範囲制限が一次防御であるとすれば、Origin検証は誤った実装やクロスオリジンリスクを軽減する追加の層です。

ただし、パスキーがすべての攻撃を防ぐわけではありません。

すでに認証されたセッションクッキーが奪取される攻撃
ユーザーデバイスやブラウザ自体が侵害された場合
パスキー登録前にアカウント復旧手順が奪取された場合
悪意のあるOAuth承認やリモート制御詐欺
サーバーがチャレンジ・Origin・RP ID検証を誤って実装した場合

パスキーはログインフィッシングやCredential Stuffingを大幅に削減する技術であり、アカウント全体のセキュリティを代替する万能なものではありません。

同期パスキーとデバイス結合パスキー

FIDO Allianceは、パスキーを複数のデバイスに安全に同期できる形式と、特定のデバイスに紐付けられたデバイス結合形式に分類しています。


区分	同期パスキー	デバイス結合パスキー

—	—	—
使用性	同じプラットフォームアカウントの複数のデバイスで使用	登録されたデバイスまたはセキュリティキーが必要
復旧	プラットフォームアカウントの復旧体系を活用	予備のセキュリティキー・他の登録資格情報が必要
主なリスク	クラウドアカウントの奪取と復旧ポリシーへの依存	デバイス紛失時にアカウントアクセスを失う可能性
適切な環境	一般消費者向けサービス	管理者・高リスク業務・規制環境

同期とは、秘密鍵を平文でクラウドにアップロードするという意味ではありません。プラットフォーム提供者はエンドツーエンド暗号化とデバイス・アカウント保護を適用しますが、具体的な保護と復旧方法はエコシステムごとに異なります。組織は、同期の有無、Attestation、デバイス管理要件をリスクレベルに合わせて決定する必要があります。

携帯電話で他のPCにログインするハイブリッドフロー

パスキーがない公共のPCでも、携帯電話のパスキーを使用できます。これは、ブラウザに表示されたQRコードを携帯電話でスキャンし、近接性を確認した後、携帯電話の生体認証で承認する方式です。

重要な点は、パスキーの秘密鍵をPCにコピーするのではなく、携帯電話が認証デバイスとして機能し、そのログインセレモニーに署名するということです。公共のPCには最終的なサービスセッションが残る可能性があるため、ログアウトとセッション管理は依然として必要です。

サーバー実装で必ず検証すべき項目

WebAuthnはブラウザAPIを呼び出すだけで完成するものではありません。サーバー検証がセキュリティの核心です。

チャレンジはサーバーで十分にランダムに作成し、ワンタイム・短い有効期限で管理します。
返されたチャレンジがセッションに保存された値と正確に一致するか確認します。
originは許可リストと正確に比較し、予期しないサブドメインを許可しません。
rpIdHashが設定したRP IDのSHA-256値と一致するか確認します。
UP(User Present)とUV(User Verified)フラグがサービスポリシーを満たしているか確認します。
Credential IDとユーザーアカウントの関連付けを検証します。
登録された公開鍵とアルゴリズムでAssertion Signatureを検証します。
Sign Countは複製疑いの信号として活用しますが、同期資格情報の特性を考慮します。
登録・削除・復旧・新規デバイス追加などのライフサイクルイベントを監査ログに記録します。

直接暗号処理を実装するよりも、検証済みのサーバーライブラリを使用すべきですが、ライブラリがどのような値とポリシーを検証するのかを運用者が理解する必要があります。

パスキー導入時、アカウント復旧がより重要になる

ログインだけを強力にし、アカウント復旧がメールリンク一つで終わる場合、攻撃者はより弱い経路を選択します。

推奨される設計は以下の通りです。

1つのアカウントに複数のパスキー登録を許可
パスキーリストと最終使用デバイスをユーザーが確認・削除
新しいパスキー登録と復旧時に強力な再認証
管理者アカウントは予備のハードウェアセキュリティキーを保管
復旧コードの安全な発行と再発行の監査
疑わしい登録・削除イベントの通知
パスワード併用期間中は既存のフィッシングリスクが残るという案内

パスキーを追加認証手段としてのみ提供すると、移行は容易ですが、パスワードの攻撃面はそのまま残ります。サービスは利用者転換率と復旧成功率を観察しながら、段階的にパスワードレスポリシーを拡大する必要があります。

結論

パスキーは生体情報をサーバーに送る技術ではなく、サイトごとの公開鍵暗号を使用し、パスワードという共有秘密をなくす技術です。

登録時、認証デバイスが鍵ペアを作成し、サーバーは公開鍵のみを保管します。ログイン時、サーバーがワンタイムのチャレンジを送ると、ユーザーのデバイスがローカル検証後に秘密鍵で署名し、サーバーが公開鍵で検証します。RP IDとOriginに資格情報が紐付けられるため、偽サイトが同じ秘密鍵の署名を取得することは困難です。

パスキーのセキュリティは、強力な暗号技術だけでなく、ブラウザのオリジン検証、認証デバイスのユーザー承認、サーバーの正確なセレモニー検証、そして安全なアカウント復旧が連携して機能することで完成します。

ユーザーはパスワードを覚える必要がなくなり、サービスはパスワードDB流出やフィッシング・再利用攻撃のリスクを大幅に削減できます。次の認証体系を設計するなら、パスワードにパッチを当てるよりも、パスキー中心の公開鍵認証を基本経路として検討する時期です。