はじめに
近年、セキュリティ業界の「最近の推しメン」といえば Passkey（パスキー）。
Apple・Google・Microsoft の三巨頭が揃って推していることから、
「パスワードはもう古代遺跡」
と言われる時代が到来しようとしている。
1. Passkey とは何か？
Passkey とは、
公開鍵暗号（Public Key Cryptography）を使った、パスワード不要の認証方式。
FIDO2（WebAuthn + CTAP）の標準に基づき、
以下の特徴を持つ：
- パスワードを使わない
- 秘密鍵は端末に残る（サーバに送らない）
- 生体認証（Face ID / Touch ID / Windows Hello）で解錠
- フィッシング不可能
- 漏洩耐性が非常に高い
もう一歩踏み込むと：
サーバには 公開鍵だけ を保存し、ログイン時は
「秘密鍵で署名されたチャレンジを公開鍵で検証」
して本人確認する仕組み。
2. パスキーの基礎：公開鍵暗号（超簡単版）
Passkey の核心はこれ一つだけ：
秘密鍵（private key）で署名したものは、対応する公開鍵（public key）でしか検証できない。
秘密鍵は端末内から出ないため、
漏洩のリスクがほぼゼロになる。
3. Passkey 登録フロー（図解）
ユーザー登録（MakeCredential）
---------------------------------------
1. クライアントが秘密鍵・公開鍵を生成
2. 公開鍵をサーバへ送信
3. サーバは公開鍵を保存
概念図：
[Client] 生成 → (publicKey, privateKey)
↓ publicKey を送信
[Server] 公開鍵をDBに保存
秘密鍵は端末内に固定化（Secure Enclave / TPM / Keystore）
4. Passkey 認証フロー（図解）
ログイン（GetAssertion）
---------------------------------------
1. サーバ → challenge（ランダム文字列）送信
2. クライアントは秘密鍵で challenge + authenticatorData を署名
3. サーバが公開鍵で署名を検証
4. OK → ログイン成功
図：
[Server] --- challenge ---> [Client]
Client:
署名 = Sign(privateKey, challenge + authenticatorData)
[Client] --- 署名 + AuthData ---> [Server]
Server:
Verify(publicKey, 署名)
-----------------------------------
OK → 認証成功
5. Passkey のタイプ：同期型 vs 端末限定型
① 同期型（Sync Passkey）
Apple / Google / Microsoft が
クラウドに end-to-end で暗号化して同期するタイプ。
| プラットフォーム | 同期先 |
|---|---|
| Apple | iCloud Keychain |
| Google Password Manager | |
| Microsoft | Microsoft Cloud (Entra) |
メリット：
- 新デバイスに即復元
- 同一アカウント間でシームレス
- 使い勝手最強
デメリット：
- アカウントロックで詰む
- エンタープライズ用途では好まれない場合あり
② 端末限定（Device-bound Passkey）
秘密鍵が端末専用。同期しない。
例：
- YubiKey
- Windows Hello のローカルキー
- Android ローカル Passkey
メリット
- 企業ポリシー的に強固
- クラウドに出ない
デメリット
- 壊れたら復旧不可（設計通り）
6. クロスデバイス Passkey（UX の革命）
Apple の Passkey → Android ログイン
Android → Mac
Windows → iPhone
全部可能。
仕組み：
- Bluetooth の近接確認
- QR コードによる暗号化チャネル
- CTAP 2.2 の Hybrid フロー
※ 同期ではなく “一時認証”
7. サーバ側で何を検証しているか？（技術者向け）
サーバは 署名だけを検証しているわけではない。
実は多項目チェック。
1. 署名検証（ECDSA / ES256）
Verify(publicKey, challenge + authenticatorData, signature)
2. RP ID のハッシュチェック
- example.com の鍵を evil.com で使うのを防ぐ
3. Challenge がサーバのものと一致？
4. User Presence（UP）
ユーザーがタップしたか？
5. User Verification（UV）
生体認証したか？
6. Sign Count（counter）
クローン防止
（偽造端末が同じ key を使って連続ログインすると検出）
8. Passkey が強い理由（攻撃モデル視点）
Passkey により以下の攻撃がすべて無効化される：
| 攻撃手法 | Passkey の防御 |
|---|---|
| パスワード漏洩 | そもそもパスワードがない |
| キーロガー | 秘密鍵は打たない・送らない |
| フィッシング | domain binding により不可能 |
| 認証情報再利用 | 秘密鍵がサイトごとに異なる |
| ブルートフォース | 無意味 |
| 中間者攻撃（MITM） | サーバの challenge が検証される |
Passkey は、“攻撃者の商売を根こそぎ潰す存在”。
9. Passkey の弱点
Passkey = 完璧ではない。
アカウントロック問題（同期型）
Apple ID／Google アカウント失効 →
全部失う
（これは重大）
デバイス紛失時の復旧 UX が未成熟
- iCloud Keychain で E2EE 有効化が必要
- Windows の復旧は企業依存
企業のゼロトラスト構成だと“管理”が複雑
- device-bound をどう配布？
- ローテーションどうする？
- バックアップポリシーは？
10. Passkey の実装（WebAuthn API 基礎コード）
登録（create）
const cred = await navigator.credentials.create({
publicKey: {
challenge: serverChallenge,
rp: { name: "Example Inc." },
user: {
id: userIdBuffer,
name: "test",
displayName: "Test User"
},
pubKeyCredParams: [{ type: "public-key", alg: -7 }],
authenticatorSelection: {
authenticatorAttachment: "platform"
}
}
});
認証（get）
const assertion = await navigator.credentials.get({
publicKey: {
challenge: serverChallenge,
allowCredentials: [{
id: credentialIdBuffer,
type: "public-key"
}]
}
});
11. エンタープライズ導入のポイント
| 項目 | 注意点 |
|---|---|
| デバイス紐付け | device-bound を優先？ |
| 復旧ポリシー | Sync だけに依存しない |
| 認証器管理 | FIDO2 キー管理が必要 |
| プライバシー | 生体情報は送らない |
| 監査 | SignCount の取り扱い |
12. Passkey の未来
- ブラウザ互換性はほぼ完成
- 銀行・保険・通信キャリアも採用開始
- OAuth + Passkey の併用が主流に
- メール＋SMSコードは淘汰予定
認証基盤のスタンダードになるのは確実。
まとめ
Passkey は単なる“便利ログイン”ではなく：
- 秘密鍵は端末から出ない
- サーバには公開鍵だけ
- フィッシング不能
- パスワード破り不可
- 同期型で UX 最強
という パスワードの弱点を根こそぎ潰す仕組みです。