本記事では簡略化のため、FIDO2クレデンシャル全般をパスキー／パスキー認証と呼びます。
要約
- パスキー認証は優れた認証方式だが、弱点としてVendor-lockinがある。
- パスキープロバイダ間でクレデンシャルを同期するプロトコル(CXP/CXF)の策定が進んでいる。
- iPhoneではCXFが2025年秋から実装されていて、iPhone内でアプリAからアプリBへパスキーを共有できる。
- CXFを利用して、iCloud KeyChainの外へパスキーを取り出す。
- Bitwardenではユーザー自身のパスキーの情報（秘密鍵を含む）を確認できるので、iPhoneのパスキーの秘密鍵を平文で確認できる。
- CXP/CXFが普及することでSyncedパスキーの「所有」認証の強度が低下する可能性がある。（安全性と利便性のトレードオフ？）
用語
本記事で登場する用語の意味は下記にようになります。
| 用語 | 意味 |
|---|---|
| パスキープロバイダ | パスキーを保管する主体。iCloud KeyChainやBitWarden等。 |
| CXP | ネットワーク経由でクレデンシャルを安全に交換するプロトコル。 |
| CXF | クレデンシャル交換用のフォーマット。 |
| Syncedパスキー | 複数の認証器間で同期されているパスキー。 |
| Device-Boundパスキー | 1つの認証器から出ないパスキー。 |
パスキー認証の概要
パスキー認証の基本は公開鍵認証です。公開鍵認証を安全・便利に行うための仕組みだと整理すると理解しやすいです。
安全性
他MFAとの差別化点がフィッシング耐性です。パスキー認証ではパスキーを登録したドメインでのみ認証を行うことができます。
TOTPやmailOTPではプロキシ型フィッシングを回避できませんが、パスキー認証はDomain-Bindingですのでプロキシ型フィッシングを回避できます。
(Device-Boundパスキー限定)
通常の公開鍵認証では鍵はファイル上に置かれますが、パスキー認証ではHWの安全な領域に秘密鍵がおかれて取り出せません。
利便性
他MFA(TOTPやmailOTP)ではユーザー名を入力する必要があります。パスキー認証ではResidentKeyという仕組みによってユーザー名を入力することなく認証できます。
(Syncedパスキー限定)
通常の公開鍵認証では、端末間で秘密鍵を手動でコピーする必要がありました。パスキー認証では、端末間で自動で鍵を同期する仕組みによって、ユーザーが意識的に鍵をコピーする必要がありません。
パスキー認証の弱点
このようにパスキー認証は優れた仕組みですが、明確な弱点が存在します。
それはVendor-Lockinです。
パスキー認証の秘密鍵は(Syncedパスキーの場合)同一パスキープロバイダ内では共有されていますが、パスキープロバイダをまたいでエクスポートすることは困難です。
CXP/CXFによってパスキーをプラットフォーム間でも共有できる
上述したように、パスキー認証の弱点として、パスキープロバイダ間でのパスキーの共有が難しいことがあります。
例として、iCloud KeyChainのパスキーをGoogle Password Managerに移行する、といったことは難しいです。
CXP/CXFは上記の弱点を補うもので、パスキープロバイダ間でパスキーを安全かつ標準化された手法で共有できるようになります。
Credential Exchange Protocol(CXP)ってなに？
2つのパスキーprovider間で、ネットワーク経由でクレデンシャルを安全に共有するプロトコルです。HPKEによってE-to-Eで暗号化します。
Credential Exchange Format(CXF)ってなに？
クレデンシャルを交換するための標準的なフォーマットです。
「所有」の強度が低下することが考えられる
Syncedパスキーは（認証器の実装依存ですが）同一パスキープロバイダでの共有でした。しかし、CXP/CXFによって別プロバイダ別アカウントにもパスキーが共有されることになります。これによって、認証の要素のうち「所有」の強度が低下すると考えられます。
CXFは一部のプロバイダで実装されている
一部のプロバイダではCXFに対応していて、例えばiOSは同一デバイス内でパスキーを共有できるようになっています。ネットワーク経由の共有ではないので、CXPは関係ありません。
(2025年の秋iOS26から実装されていたようです)
実際にパスキープロバイダ間でパスキーを共有してみる
iPhoneアプリの中で、いくつかのパスワードプロバイダがCXFに対応していますが、今回はBitwardenを使います。理由はOSSだからです。
具体的な操作は下記のように簡単にできます。
- 「パスワード」アプリを開き、右上から「データを別のアプリに書きだす」を選択する。
- 共有したいパスキーを選択する。今回はWebAuthn.ioのパスキーを選択。
- 共有先のアプリを選択する。iPhone内に対応するアプリがインストールされている必要がある。今回はBitwardenに共有する。
- BitwardenにWebAuthn.ioのパスキーが共有されていることが確認できる。
Bitwardenでパスキーの情報を確認する
Syncedパスキーの秘密鍵が可視・可搬になったことを示す意図で下記のデモを実施します。
iPhoneのBitwardenにパスキーをインポートすると、同一Bitwardenアカウントにログインしているデバイス間でパスキーが共有されます。
Bitwardenではユーザーが自身の秘密鍵を確認できます。
CLIからBitwardenにログインして、下記コマンドで確認できます。
> bw get item "4da6...." | jq '.login.fido2Credentials'
[
{
"credentialId": "b64.W8YSJKAhRNlWzWSgZxC3TpdfbkY",
"keyType": "public-key",
"keyAlgorithm": "ECDSA",
"keyCurve": "P-256",
"keyValue": "MIGHAg....",
"rpId": "webauthn.io",
"counter": "0",
"discoverable": "true",
"creationDate": "2026-08-01T06:41:20.000Z",
"userHandle": "d2ViYXV0aG5pby1pUGhvbmUtYnctc2hhcmU",
"userName": "iPhone-bw-share",
"rpName": "webauthn.io",
"userDisplayName": "iPhone-bw-share"
}
]
> KEY="MIGHAg...."
> python3 -c "import base64,sys; open('pkcs8.der','wb').write(base64.urlsafe_b64decode(sys.argv[1]+'=='))" "$KEY"
> openssl pkey -inform DER -in pkcs8.der -text -noout
Private-Key: (256 bit)
priv:
5c:ae:6b:....
pub:
04:b8:e7:....
ASN1 OID: prime256v1
NIST CURVE: P-256
iCloud Key Chainで管理されていたパスキーの秘密鍵を平文で確認できました。
利便性と安全性のトレードオフ
CXP/CXFでパスキーの共有が可能となると、パスキーのバックアップやパスキープロバイダ変更時に大変役に立つことが想定されます。
一方で、別プロバイダの別アカウントとパスキーを共有可能になるとで安全性が低下することも考えられます。
CXP/CXFは共有を安全に標準化された手順で行うものであり、共有先が誰のアカウントに紐付いたものかは管轄外だからです。
共有先が信頼できるかはユーザーの判断に委ねられます。
例えば、ユーザー側のリテラシーが不足している場合、下記のような攻撃の被害にあうことも考えられます。
前提：ユーザーの端末が端末内でのパスキー共有に対応している。
- 証券会社のサポートを装った攻撃者のいいなりになって、端末にパスワードマネージャをインストールさせられる。(パスワードマネージャは正当なものなので、この段階では違和感に気づきにくい)
- 攻撃者のいいなりで操作をしてしまい、攻撃者のアカウントでパスワードマネージャにログインさせられる。
- その状態でパスキーをパスワードマネージャに共有する。(共有先アカウントが信頼できるものかは、ユーザーで判断するしかない）
- パスワードマネージャがクラウド経由でパスキーを別端末に共有し、攻撃者が被害者のパスキーを入手する。
このようにCXP/CXFによってSyncedパスキーの利便性が向上する一方で、複数プロバイダ間でパスキーが共有されることで攻撃表面が増加する可能性があります。
利便性と安全性は往々にしてトレードオフの関係にあるので、CXP/CXFについても同様かもしれません。
高い認証強度が要求される組織では、Syncedパスキー禁止を検討する動機が増すかもしれません。
RPは認証器がauthenticatorDataで送信してくるBE/BSフラグをチェックすることでSyncedパスキーをブロックすることができます。
まとめ
CXP/CXFが必要とされる背景を説明した後に、CXP/CXFによってパスキー認証の「所有」強度が低下する懸念について説明しました。
また、パスキーをプロバイダ間で共有する様子についてデモしました。
安全性と利便性は往々にしてトレードオフですので、組織ごとに必要な要件を確認して適切なポリシーを設定するべきです。
参考資料
CXP/CXFについて解説している記事
https://www.corbado.com/blog/credential-exchange-protocol-cxp-credential-exchange-format-cxf