パスワード認証がフィッシング詐欺に使われたことから、金融など多くの重要サイトがパスキー方式に移行している。
一方、最初に登場したパスキーは機器固有で利用する機器にだけ保存されるものだったが使い勝手が悪い。
そこで、最近はクラウドに秘密鍵を保存し利用側はChrome や Edge Apple などを利用して本人利用機器でのパスキー利用方式が普及しはじめた。
この場合は、利用機器が本人のものと証明することが重要になる。この部分を解説記事と、AIの解説を続けて引用紹介する。
【passkey】パスキーとは
Zenn社の記事を引用紹介します https://zenn.dev/hanacus87/articles/what_is_passkey
に公開 Appendixは割愛しています。
本記事では、パスキーの設計思想と仕組みを、公開されている仕様に基づいて整理します。本文ではパスキーの定義、パスワード認証との比較、種類、認証の仕組み、限界を扱い、Appendix ではアカウント復旧と端末追加のフロー設計、およびそれらに対する攻撃と防御を扱います。
1. パスワード認証の課題
パスワード認証には、構造に由来する次の課題があります。
- 使い回し: 複数のサービスで同一のパスワードを設定した場合、一つのサービスからの漏洩が他のサービスにも波及します。
- フィッシング: パスワードは送信先のサイトを区別しない秘密情報のため、偽サイトに入力された値はそのまま攻撃者に渡ります。
- サーバ側のクレデンシャル漏洩: サービスはパスワード、またはそのハッシュを保持するため、サーバ侵害で認証情報が流出します。ハッシュ化されていても、オフラインでの総当たり攻撃の対象になります。
- リスト型攻撃: 漏洩した認証情報の組み合わせを他のサービスのログインに試行する攻撃で、使い回しと組み合わさって成立します。
これらの課題に共通する構造は、パスワードが、利用者とサービスが同一の秘密を共有する方式である点です。共有された秘密が一度でも第三者に渡ると、認証が成立します。
2. パスキーの概要
パスキーは、公開鍵暗号に基づく認証情報です。利用者の認証器、すなわちスマートフォン、PC、セキュリティキーなどが、サービスごとに鍵ペア（公開鍵と秘密鍵）を生成します。秘密鍵は認証器が保持し、公開鍵はサービス側に登録されます。認証は、認証器が秘密鍵で署名を生成し、サービスが対応する公開鍵で検証する手順で行われます。
パスキーに関連する用語の関係を整理します。
- WebAuthn（Web Authentication）: W3C が策定するブラウザ API の仕様です。Level 1 が2019年3月4日、Level 2 が2021年4月8日に W3C Recommendation として公開されました。Level 3 は策定が進められており、2026年初頭時点で Candidate Recommendation の段階です。
- CTAP（Client to Authenticator Protocol）: FIDO Alliance が策定する、クライアント（OS やブラウザ）と認証器の間の通信プロトコルです。現行は CTAP2 系が用いられています。
- FIDO2: WebAuthn と CTAP を合わせた呼称です。
- パスキー: FIDO2 および WebAuthn に基づく認証情報を指す呼称です。技術的には discoverable credential、すなわち利用者が識別子を入力しなくても認証器が利用可能なクレデンシャルを提示できる方式に相当します。パスキーは、ブラウザ API としての WebAuthn を通じて利用され、外部の認証器との通信には CTAP が用いられます。
3. パスワード認証との比較
パスワード認証とパスキーを、観点ごとに対比します。なお、表に示すパスキーの性質の一部は、サービス（リライングパーティ。以下 RP）が WebAuthn 仕様の定める検証手順を正しく実装することを前提に成り立ちます。
| 観点 | パスワード認証 | パスキー |
|---|---|---|
| 認証の秘密の所在 | 利用者とサービスが同一の秘密を共有する | 秘密鍵は認証器のみが保持し、サービスは公開鍵のみを保持する |
| サービス間の独立性 | 使い回した場合、一つの漏洩が他サービスに波及する | サービスごとに独立した鍵ペアを使用する |
| フィッシング時の影響 | 入力した秘密がそのまま攻撃者に渡る | 署名対象にオリジンが含まれ、偽サイト向けの署名は本物サービスの検証を通らない |
| サーバ漏洩時の影響 | パスワード、またはそのハッシュが流出し、総当たりの対象になる | 公開鍵のみが流出し、署名の生成には使えない |
| リプレイ | 同じパスワードを繰り返し送信できる | セレモニーごとの使い捨てチャレンジに署名が束縛される |
4. パスキーの種類
FIDO Alliance は、パスキーを同期パスキー（synced passkey）とデバイスバウンドパスキー（device-bound passkey）の二種類に分類しています。
同期パスキーは、クレデンシャルマネージャ（Apple の iCloud キーチェーン、Google パスワードマネージャー、サードパーティのパスワードマネージャーなど）に保管され、同一プロバイダを利用する複数のデバイス間で同期されます。秘密鍵は暗号化された形でクラウドに保管され、認可された他のデバイス上で復元されます。
デバイスバウンドパスキーは、単一のデバイス、主にセキュリティキーに固定され、秘密鍵がそのデバイスの外に出ません。
両者を観点ごとに対比します。
| 観点 | 同期パスキー | デバイスバウンドパスキー |
|---|---|---|
| 秘密鍵の所在 | 暗号化された形でクラウドに保管され、複数デバイスに複製される | 単一のデバイス内に留まり、外部に出ない |
| デバイス間の同期 | 同一プロバイダ配下のデバイス間で同期される | 同期されない |
| デバイス紛失時 | 他のデバイスから利用を継続できる | 当該デバイスでの利用はできず、再登録が必要になる |
| アテステーション | 端末の出自証明を提供しない | 端末の出自証明を提供しうる |
異なるデバイス間でのサインインは、CTAP のハイブリッドトランスポートを用いて行われます。
5. 認証の仕組み
パスキーの処理は、鍵ペアの生成と公開鍵の登録を行う登録フェーズと、秘密鍵による署名とその検証を行う認証フェーズに分かれます。
登録フェーズ
- サービス（RP）が、チャレンジ、RP の情報、利用者の情報などを含む登録用のオプションを生成し、ブラウザに渡します。
- ブラウザが
navigator.credentials.create()を呼び出し、認証器がユーザー検証（生体認証または PIN）を行います。 - 認証器が鍵ペアを生成して秘密鍵を認証器内に保管し、生成された公開鍵を含む attestation object を返します。
- RP は WebAuthn 仕様が定める手順でレスポンスを検証し、公開鍵とクレデンシャル ID を利用者のアカウントに紐づけて保存します。
認証フェーズ
- RP が、使い捨てのチャレンジを発行します。
- ブラウザが
navigator.credentials.get()を呼び出します。認証器がユーザー検証を行い、秘密鍵で署名を生成します。 - 署名の対象は、authenticatorData と、clientDataJSON の SHA-256 ハッシュを連結したものです。
- 認証器が authenticatorData、署名、clientDataJSON を返します（assertion）。
- RP は WebAuthn 仕様が定める手順で、保存済みの公開鍵を用いて署名を検証し、チャレンジ、オリジン、rpIdHash、各フラグを照合します。
署名対象に含まれるデータ
clientDataJSON は、操作種別（type）、チャレンジ（challenge）、オリジン（origin）を含む JSON です。authenticatorData は、RP ID の SHA-256 ハッシュ（rpIdHash）、フラグ（ユーザーの存在を示す UP、ユーザー検証の成否を示す UV など）、署名カウンタ（signCount）などを含みます。
署名アルゴリズムの識別子や公開鍵の表現は COSE（RFC 9052 / 9053）で定義されます。COSE および attestation object の符号化には CBOR（RFC 8949）が用いられます。
署名カウンタは認証のたびに増加する値で、RP はこの値が減少していないかを確認することで、複製された認証器を検知できます。ただし同期パスキーでは秘密鍵が複数のデバイスに複製されるため、カウンタが増加せず常に 0 となる実装が一般的です。このため複製検知は、主にデバイスバウンドの認証器に対する補助的な機能です。
6. パスキーの限界
パスキーには、現状、次の限界があります。
同期パスキーの安全性が依存する対象
同期パスキーでは秘密鍵がデバイス外に複製されるため、その安全性は、同期基盤となるプロバイダのアカウントおよびその復旧経路の安全性に依存します。秘密鍵が単一のデバイス内に留まるデバイスバウンドパスキーとは、この点が異なります。
また、同期パスキーは、アテステーションによる端末の出自証明を提供しません。NIST の SP 800-63B（Digital Identity Guidelines）は、同期パスキーを syncable authenticator として位置づけ、認証の保証レベル AAL2 に該当しうるものとして扱っています。一方で、AAL3 は認証に用いる鍵がエクスポート不可能であることを求めるため、秘密鍵がデバイス外に複製される同期パスキーは AAL3 には該当しません。
| 観点 | 同期パスキー | デバイスバウンドパスキー / セキュリティキー |
|---|---|---|
| アテステーション | 端末の出自を証明しない | 端末の出自を証明しうる |
| 到達可能な AAL（NIST SP 800-63B） | AAL2 | AAL2 または AAL3 |
アカウント復旧における非パスキー要素
利用者がすべてのデバイスを失った場合、定義上、パスキーによる認証は行えません。このため、アカウント復旧のフローでは、パスキー以外の要素、多くの場合はメールアドレスなどを本人確認に用いることになります。この復旧経路の強度が、システム全体の実効的なセキュリティの下限になります。復旧経路の具体的な設計については、Appendix で扱います。
エコシステム間の移行と実装状況
異なるプロバイダの間でクレデンシャルを移行する仕組みは、FIDO Alliance で仕様の策定が進められている段階です。また、パスキーに対応する RP の範囲や実装の成熟度にも、ばらつきがあります。
7. まとめ
パスキーは、サービスごとに独立した鍵ペアを用い、秘密鍵を認証器内に保持し、署名対象にオリジンとチャレンジを含めることで、使い回し、サーバ漏洩、フィッシング、リプレイに対する耐性を持ちます。これらの性質の多くは、RP が WebAuthn 仕様の定める検証手順を正しく実装することを前提とします。
一方で、同期パスキーの安全性は同期基盤に依存し、アカウント復旧の経路には非パスキー要素が残ります。パスキーの実効的なセキュリティは、日常の認証部分だけでなく、復旧経路を含めた認証経路全体のうち、最も弱い要素によって決まります。
AI解説補足：パスキーの秘密鍵がクラウドに保管されると、許容機器認証が重要になる。この部分を解説して
パスキー（Passkey）がGoogleパスワードマネージャーのようなクラウド（FIDOデータストア）に同期され、Google Chromeなどを通じてさまざまなデバイスから利用できるようになると、利便性が飛躍的に向上する一方で、セキュリティの担保として「許容機器認証（認証器自体の正当性や、物理的な端末の検証）」が極めて重要な役割を持つようになります。
この仕組みがなぜ重要であり、どのように機能しているのか、技術的な背景とともにと詳細に解説します。
1. なぜクラウド同期型パスキーで「機器の認証」が重要になるのか？
従来のパスキー（デバイス固定型）は、スマートフォンのSecure EnclaveやPCのTPMといった「特定の物理ハードウェア（チップ）内」から秘密鍵が外に出ない仕組みでした。そのため、「その端末を持っていること」自体が強力な身元証明（所有物認証）になっていました。
しかし、Googleパスワードマネージャーなどに秘密鍵が保管され、クラウドを介して複数のデバイス（PC、スマホ、タブレット）に同期されるようになると、以下の変化が生まれます。
- 秘密鍵の移動: 秘密鍵が暗号化された状態でクラウドを移動し、複数のデバイスに展開される。
- アタックサーフェス（攻撃対象領域）の変化: 万が一、Googleアカウント自体が乗っ取られたり、同期された別のデバイスがマルウェアに感染したりした場合、不正な機器からパスキーを使ってログインを試みられるリスクが生じる。
ここで、サービス（リライイングパーティ：RP）側からすると、「今、認証を要求してきたこのChrome（あるいはデバイス）は、本当に信頼してよい正当な機器なのか？」を厳格にチェックする必要が出てきます。これが「許容機器認証」の根幹となる要求です。
2. 許容機器認証を支える具体的な技術スタック
Google ChromeとGoogleパスワードマネージャーの組み合わせにおいて、許容機器認証（および端末の安全性の担保）は、主に以下の3つのレイヤーで多層的に実行されています。
① WebAuthnの「アテステーション（Attestation：検証）」
パスキーの登録時、ブラウザやデバイス（認証器）は、サービス側に対して「私は確かにGoogleが管理する安全な認証器（Googleパスワードマネージャー）であり、秘密鍵は安全に保護されています」という証明書（アテステーション文言）を送信できます。 サービス側はこのデータを検証することで、「エミュレータや改造された不正なブラウザではなく、Googleの正規の安全基準を満たした仕組み（Chrome/Googleパスワードマネージャー）から生成された鍵であること」を確認（認証）します。
② ハードウェアに紐づいたエンドツーエンドの暗号化（画面ロックの強制）
Googleパスワードマネージャーに保存されたパスキーは、クラウド上でもGoogleですら復号できない形で暗号化されています。これを新しい機器（Chrome）で復号して利用可能にするには、「その機器自体の画面ロック（PIN、指紋、顔認証）」のパスワードや、アカウント作成時に設定した「暗号化キー」の入力が必要です。 これにより、「クラウドから勝手に鍵を盗んで、認証器がセットアップされていない未許可の機器で使う」という攻撃を防ぎます。
③ 近接認証（ハイブリッド・トランスポート）の暗号化
PCのChromeでログインする際、手元のスマートフォンを認証器（パスキーの保管庫）として利用するケースがあります。このとき、FIDOの「ハイブリッド（旧BLE/QRコード）」という仕組みが使われます。
- Bluetoothによる物理的近接の証明: PCとスマホが「物理的に近くにあること」をBluetoothの電波（アドバタイズ）で確認します。これにより、遠隔地にいるハッカーが被害者のスマホのパスキーをリモートで悪用することを物理的に遮断します。
- トンネル暗号化: QRコードのスキャン、あるいは位置情報の照合（WebSocket経由）によって、PCとスマホの間で一時的なエンドツーエンドの暗号化チャネルが確立されます。通信経路上のGoogleのサーバーであっても、この認証セッションを傍受・偽装することはできません。
3. 許容機器認証がもたらすセキュリティ上のメリット
この「機器自体の正当性や状態」を厳格に認証・管理することにより、以下の脅威を無効化できます。
| 脅威シナリオ | 許容機器認証（および周辺技術）による防御 |
|---|---|
| 遠隔地からのフィッシング | 攻撃者が偽サイトを作って被害者にパスキーを使わせようとしても、フィッシングサイトのドメインとパスキーが紐づくドメインが一致しないためブラウザが拒否します。また、スマホ連動時はBluetoothによる物理的距離の制限があるため、遠隔からのリレー攻撃が成立しません。 |
| セッションハイジャック / 鍵の複製 | 万が一Googleアカウントの認証情報が盗まれても、新しい未認証の機器でパスキーを有効化するには、ハードウェアに紐づいた画面ロック（PIN等）やマスターキーの物理入力を求められるため、攻撃者は鍵を復号できません。利用機器の追加は、保有者の認証が必要になるためです。 |
| 不正ブラウザによる偽装 | エミュレータや、コードを改ざんした不正なオープンソースブラウザからのアクセスに対しては、WebAuthnのアテステーション検証により、サービス側が「未許可の機器/環境」として認証を拒否できます。 |
4. まとめ
Googleパスワードマネージャーによるパスキーのクラウド同期は、「どの端末からでもサインインできる」という利便性をもたらす反面、「そのアクセスを行っている機器や環境が、本当に改ざんされていない許容されたものであるか」の検証（機器認証）とセットでなければ、セキュリティが崩壊してしまいます。
FIDO規格およびGoogle Chromeは、「WebAuthnによる認証器の検証（Attestation）」、「デバイスの画面ロックと連動したエンドツーエンド暗号化」、そしてスマホ連携時の「Bluetooth等による物理的近接認証」を組み合わせることで、鍵がクラウドを流通してもなお、ハードウェア固有の強固なセキュリティと同等の安全性を維持しているのです。
