パスキーとは何か: FIDO認証から実装概要まで
概要
楽天の板倉氏が、FIDO認証の基本構造を振り返ったうえで、パスキーが従来の課題をどう緩和するかを解説する。中心は、公開鍵暗号、認証器、クラウド同期、アカウントリカバリー、そして真のパスワードレス化。後半では Device Public Key、Attestation、バックアップ状態、自動入力UI、Hybrid Transport など、実装・仕様面の論点も整理する。
要点
- FIDO認証は、秘密情報をサーバーへ送らず、認証器側で本人確認し、検証結果だけをサーバーへ返す仕組み。
- 従来のFIDO認証では、認証器の紛失・故障時のアカウントリカバリーが大きな課題だった。
- パスキーは資格情報をプラットフォームベンダーのクラウドへ安全にバックアップし、複数デバイスで利用できる。
- パスキーにより、パスワードをリカバリー手段として残す必要が下がり、パスワードレス実現に近づく。
- 高セキュリティ用途では、デバイスに紐づく Device Public Key や Attestation の扱いが重要になる。
- 自動入力UIやHybrid Transportにより、ユーザーID入力不要のログインや、スマートフォンを使ったクロスプラットフォーム認証が可能になる。
構造化サマリ
FIDO認証の基本
冒頭では、FIDO認証モデルの復習から始まる。FIDO2は、認証器とブラウザ間の CTAP、ブラウザとRPサーバー間の WebAuthn を組み合わせた仕様として説明される。
従来のID・パスワード認証では秘密情報をサーバーへ送って検証する。一方、FIDO認証では認証器がクライアント側で本人確認を行い、その結果だけをサーバーに送るため、秘密情報がネットワーク上を流れない。フィッシング耐性の高さがここから生まれる。
従来FIDOの課題
FIDO認証の主要な検討点として、アカウントリカバリーが挙げられる。スマートフォン、PC、USB型セキュリティキーなどの認証器を紛失・破損すると、登録済みの資格情報を使えなくなる。
これまでは複数の認証器を事前登録することがベストプラクティスとされていた。しかし一般消費者向けサービスでは、複数登録を強制しにくい。結果として、携帯契約時のネットワーク暗証番号、あるいは残されたパスワードなど、サービスごとの復旧手段が必要になっていた。
もう一つの課題は、RP側がクライアントにFIDO資格情報が登録されているかを事前判別しにくい点。新しいデバイスを登録しようとした際、認証処理の要求がエラーになるケースがあり、FAQや追加実装で補う必要があった。
パスキーの仕組みと利点
パスキーでは、作成された資格情報が iCloud や Google Cloud など、プラットフォームベンダーのクラウドに安全にバックアップされる。同一のプラットフォームアカウントにログインした複数デバイスで利用でき、機種変更や紛失時にも継続利用しやすい。
同期時にはセキュアチャネルが使われ、たとえばAppleでは iCloud Keychain によるエンドツーエンド暗号化が説明される。Apple自身も暗号鍵を知ることができず、総当たり攻撃へのレート制限もあると紹介される。
登録フローは、RPサーバーがチャレンジを発行し、認証器が本人確認後に鍵ペアを生成し、秘密鍵で署名したチャレンジと公開鍵を返す形。パスキーでは、このユーザーに紐づく秘密鍵がクラウド上に保管される点が従来との大きな違いになる。
パスキーが解決する運用課題
パスキーの第一のメリットは、アカウントリカバリーの容易化。ユーザーはデバイス紛失や故障時にも復旧しやすく、サービス事業者はFIDO以外の復旧手段を残す必要性を下げられる。
第二に、RP側がパスキー登録状態を把握しやすくなる。ユーザーが新しいデバイスを使うたびに資格情報を登録する負担が減り、FAQや代替手段で補う運用も軽くなる。
第三に、パスワードを念のため残すユースケースを減らせる。ユーザビリティを保ちながらセキュリティレベルを上げる、真のパスワードレスに近づく機能として位置づけられる。
Device Public Key と Attestation
一方で、すべての用途がクラウド同期された資格情報だけで十分とは限らない。高いセキュリティレベルを求める用途や、FIDO資格情報はデバイスに紐づくべきだと考えるケースでは、Device Public Key、略してDPKを使う選択肢が検討されている。
パスキーはクラウドアカウントに紐づくが、DPKを確認すれば、RPは同じデバイスからの認証要求か、別デバイスからの認証要求かを検証できる。DPKを必須にするかどうかは、当時も継続議論中とされる。
さらにFIDOには Attestation という仕組みがある。認証器が自らの真正性をRPサーバーへ示すためのもので、工場出荷時に格納されたAttestation用秘密鍵を使う。動画では、DPKにも出生証明としてAttestationが必要ではないかという議論に触れるが、詳細は後続セッションに委ねている。
バックアップ状態と関連技術
パスキーの状態をRPが管理したいニーズに対して、Backup Eligibility と Backup State のビットが紹介される。前者は資格情報がバックアップ可能か、後者は実際にバックアップ済みかを示す。これにより、ユーザーの資格情報がどの状態にあるかを認証レスポンスから評価できる。
関連技術として、まず自動入力UI、別名 Conditional UI が説明される。ログイン画面でアカウントセレクターにパスキーが表示され、ユーザーはパスワードだけでなくユーザーIDの入力も省ける。
次に Hybrid Transport、旧称 caBLE が紹介される。スマートフォンをセキュリティキーのような認証器として使う技術で、QRコードを読み取り、スマートフォンで本人確認を行う。Bluetoothのブロードキャストで鍵のネゴシエーションを行い、その後はインターネット経由で安全なトンネルを確立する。
共有機能と実装概要
AppleのAirDropでパスキーを共有する機能にも触れる。誰にでも共有するものではなく、信頼する相手に限定する想定で、FIDO Alliance内でもリスクやユースケースが議論されている。
実装面では、まずクライアントがパスキーや自動入力UIに対応しているかを確認する。PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() と PublicKeyCredential.isConditionalMediationAvailable() の戻り値を確認し、対応していれば登録画面を表示する。
登録処理では、ブラウザのJavaScriptから navigator.credentials.create() を呼び出す。自動入力UIでは、ユーザー名入力欄に autocomplete="username webauthn" を指定し、ページロード時に条件を確認したうえで navigator.credentials.get() を呼び出す。最後に、パスキーはFIDOの従来課題を解くエポックメイキングな機能としてまとめられる。
登場エンティティ・コンセプト
- fido-alliance — FIDO認証やパスキーの標準化を進める業界団体。
- rakuten-group — 本動画の講演者が所属する企業で、一般消費者向けID認証の文脈から課題を語る。
- apple — iCloud Keychain、AirDrop、パスキー同期の例として登場するプラットフォームベンダー。
- google — Google Cloud やクロスプラットフォーム利用の例として登場するプラットフォームベンダー。
- passkeys — クラウド同期可能なFIDO資格情報により、パスワードレス認証と復旧性を両立する仕組み。
- fido-authentication — 公開鍵暗号と認証器を使い、秘密情報をサーバーに送らず認証する方式。
- device-public-key — パスキー利用時にも個別デバイスを識別・検証するためのデバイス紐づき公開鍵。
- conditional-ui — パスキーをアカウントセレクターに表示し、ユーザーID入力を省けるログインUI。
- hybrid-transport — スマートフォンを認証器として使い、QRコードとトンネルでクロスプラットフォーム認証する技術。
印象的な引用
「秘密情報がネットワーク上を流れることはありません。」
「真の意味でパスワードレスが実現されて、ユーザビリティとセキュリティレベルのさらなる向上を見込める可能性がある」
「パスキーはこれまでのFIDOの課題を解決する、非常にエポックメイキングな機能」