パスキーの同期と認証器の信頼モデル(Attestation)

解きたい問題：登録された鍵を、どこまで信頼してよいか

WebAuthn の認証フローそのものはFIDO2 / WebAuthn で見たとおり、署名にオリジンと rpId を束ねることでフィッシング耐性を得ます。しかし「登録の瞬間」には別の問いが残ります。いま公開鍵を渡してきたこの認証器は、ハードウェアに鍵を封じる高保証なセキュリティキーなのか、それともソフトウェアで鍵を保持し平気でクラウド同期する実装なのか。RP は公開鍵だけを見ても両者を区別できません。

この区別を可能にするのが アテステーション（attestation、構成証明） です。そして近年パスキーが「同期」を前提に普及したことで、もう一つの問いが重なりました。鍵が端末の外へ出てクラウドに複製されるという、従来の FIDO の前提を覆す挙動を、RP はどう検出し、どう許容するか。本稿はこの2つ――アテステーションの形式と、同期/バックアップの信頼モデル――を原理から解きほぐします。

アテステーションの基本：登録時の証明と attestationObject

アテステーションは登録（navigator.credentials.create()）のときだけ発行されます。認証器は新しい鍵ペアを生成すると同時に、authenticatorData（生成した公開鍵・credentialId・AAGUID を含む）と clientDataJSON のハッシュをまとめて、製造元由来の鍵で署名します。この署名と署名形式を入れた構造が attestationObject です。

attestationObject (CBOR) {
  fmt:      "packed" | "tpm" | "none" | ...   // アテステーション形式
  authData: authenticatorData                  // 公開鍵・AAGUID・flags 等
  attStmt: {                                   // 形式ごとに中身が変わる
    alg: -7,                                   // 例 ES256
    sig: <attestationの署名>,
    x5c: [ <認証器の証明書>, <中間CA>, ... ]   // 製造元証明書チェーン
  }
}

RP は attStmt.sig を x5c の先頭証明書の公開鍵で検証し、その証明書チェーンを製造元のルート CA まで遡って信頼の連鎖を確認します。これは仕組みとしてはX.509 証明書チェーン検証 と同じ「ルートまで辿って署名を確かめる」モデルです。検証が通れば、authData に含まれる AAGUID（Authenticator Attestation GUID、認証器モデルの識別子）が「本物のそのモデル」であることまで保証されます。

形式の違い：packed / TPM / none

fmt の値ごとに attStmt の構造と信頼の経路が変わります。代表的な3形式を比較します。

packed は最も直接的で、認証器内の attestation 秘密鍵で署名し、対応する証明書 x5c を添えます。RP はその証明書を FIDO Metadata Service（MDS） に登録されたルートまで検証します。同一モデルの認証器すべてが同じ attestation 鍵バッチを共有する（batch attestation）設計により、個体識別＝追跡を防ぎつつモデル識別を可能にしています（FIDO は同一バッチを最低10万台規模にすることを要求）。

tpm は Windows Hello が TPM と連携する場合に使われ、署名は TPM の AIK（Attestation Identity Key） で行われます。AIK は TPM 固有の EK（Endorsement Key） から証明されるため、信頼が「WebAuthn 認証器 → TPM の EK → TPM 製造元」と一段深く連なります。TPM の測定ブートやリモート構成証明と同じ信頼の起点に乗る形で、その内部はTPM の原理 に詳しく、ハードウェアの信頼基盤を共有します。

none は文字通りアテステーションを返しません。attStmt は空で、RP はモデルを識別できず、AAGUID も全ゼロにされることがあります。同期パスキー（iCloud キーチェーン、Google パスワードマネージャー）の多くはこれを返します。プライバシーを優先し、かつ「鍵がどの端末に複製されるか分からない」同期モデルでは、特定モデルとしての保証を主張しないのが整合的だからです。

アテステーション伝達方式：RP が何を要求するか

RP は登録オプションの attestation フィールドで、どこまでの構成証明を求めるかを宣言します。

ここで重要なのは、RP が direct を要求しても、認証器やプラットフォームが none を返す自由がある点です。同期パスキーは direct 指定でも構成証明を返さないことが普通で、RP 側は「証明が来なかった」事実を前提に設計せねばなりません。enterprise は唯一バッチ匿名化を外して個体識別を許す方式ですが、これはプラットフォームに事前登録した管理端末でしか働かず、一般公開サービスでは使えません。

同期パスキー vs デバイス束縛：BE / BS フラグ

パスキーが「同期」を持ち込んだことで、authenticatorData の flags に2つのビットが追加されました。これが RP に鍵の性質を伝える主要シグナルです。

• BE（Backup Eligible）：この資格情報が バックアップ・同期の対象になり得る か。立っていれば「複製され得る鍵」、立っていなければ device-bound（端末束縛） で、その認証器から外に出ない。BE は鍵の生涯を通じて不変。
• BS（Backup State）：実際にいま バックアップ済み（同期済み） か。BE が立っている鍵でのみ意味を持ち、利用者がクラウド同期を有効にすると立つ。状態に応じて変化し得る。

BE=0 は鍵が単一の認証器に封じられていることを意味し、紛失すれば失効に直結します。BE=1, BS=1 は鍵がクラウド経由で複数端末に複製されている状態で、機種変や紛失時の復旧が容易な反面、安全性は同期基盤に依存します。

バックアップとリカバリの内部：鍵はどう複製されるか

同期パスキーで credential 秘密鍵が端末間を移動する経路は、プラットフォーム提供者がエンドツーエンド暗号化で保護します。iCloud キーチェーンや Google パスワードマネージャーは、利用者のデバイス群だけが持つ鍵で資格情報を暗号化し、サーバーは暗号文しか見られません。新端末への復元は、利用者認証（デバイスのパスコード等）と既存デバイスの承認を経て、HSM 保護された秘密復元サービスから復号鍵を取り出して行われます。鍵保護の一般原則は鍵管理ライフサイクル と共通で、生成・保管・複製・失効の各段階で誰が鍵にアクセスできるかが安全性を決めます。

重要なのは、この設計で credential 秘密鍵の最終的な防御線が「同期クラウドアカウント」になる ことです。アカウントが乗っ取られれば、攻撃者は新端末にパスキーを復元できる可能性があります。だからこそ、

パスキーの実効的な強度
  = min( 認証時のフィッシング耐性,        // 署名のオリジン束縛で常に高い
         同期アカウントの保護強度,        // BE=1 のとき支配的になる
         リカバリ経路の本人確認の強度 )    // 最弱経路がボトルネック

という形で、最弱経路が全体の強度を決めます。パスキー導入後もリカバリが「メールのマジックリンク」だけなら、攻撃者はそのフィッシングしやすい経路を突くため、ここの設計が認証強度を左右します。

企業での attestation ポリシー：選別の現実

高保証が要る業務システムでは、RP は「どの認証器を信頼するか」を明示的に選別します。実装の軸は次の通りです。

• attestation を required（direct/enterprise）にする：構成証明を必須化し、証明が来ない none を登録時に拒否する。これは実質的に「同期パスキーを締め出し、ハードウェアキーや管理端末に限定する」効果を持つ。
• AAGUID 許可リスト：許可するモデルの AAGUID を列挙し、それ以外を拒否する。FIPS 140 認証済みキーだけ、特定ベンダーだけ、といった粒度で絞れる。
• FIDO MDS の参照：FIDO Metadata Service から各 AAGUID の認証ステータス・既知の脆弱性・証明書失効情報を取得し、ポリシー判断に使う。脆弱性が公表されたモデルを動的に排除できる。
• BE フラグでの分岐：BE=1（同期可能）を拒否し BE=0（device-bound）のみ許可する、あるいは同期パスキーは低保証ロール、device-bound は高保証ロールと分けて扱う。

一方で、過度に厳格な attestation ポリシーは導入の障壁になります。すべての利用者にハードウェアキー配布を強いれば、紛失時の運用負荷と予備キー登録の徹底が前提になり、コストとユーザー体験を圧迫します。「フィッシング耐性さえあれば十分」な多数の用途には同期パスキーで attestation: none を許容し、鍵の非エクスポート性まで要求する一部の高保証ロールにだけ厳格ポリシーを適用する――この使い分けが現実的な落としどころです。鍵をハードウェアから出さない保証の根拠はTEE / セキュアエンクレーブ や TPM が支えており、保証レベルはハードウェアの信頼境界に帰着します。

まとめ

アテステーションは登録時に「その認証器がどんなモデルか」を製造元鍵の署名で証明する任意の仕組みで、packed（直接署名）、tpm（AIK 経由でTPMの信頼基盤に接続）、none（証明なし）といった形式があります。RP は AAGUID と証明書チェーンを MDS のルートまで検証して認証器を選別できますが、同期パスキーの多くは none を返すため、厳格な attestation ポリシーは事実上ハードウェアキーへの限定を意味します。

同期パスキーは BE/BS フラグで「複製され得る・複製済み」を RP に伝え、利便性と引き換えに鍵の安全性を同期クラウドアカウントへ移譲します。device-bound 鍵が持つハードウェア分離の保証はない代わりに、復旧の容易さを得るトレードオフです。企業では attestation required・AAGUID 許可リスト・BE フラグ分岐で保証レベルを設計し、用途ごとに同期型と束縛型を二層で使い分けるのが要点になります。認証フローの土台はFIDO2 / WebAuthn、ハードウェア信頼の起点はTPM の原理 と併せて押さえると、登録時の信頼判断が原理から見通せます。