本記事では簡略化のため、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にログインして、下記コマンドで確認できます。

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