ハードウェアセキュリティキーの内部(CTAP・常駐鍵)

解きたい問題：ブラウザと「鍵を握る箱」をどうつなぐか

FIDO2 / WebAuthn は、サイトごとに公開鍵ペアを作り、サーバーのチャレンジに秘密鍵で署名することでフィッシングを原理から無効化します。ただし WebAuthn 仕様が定めるのは、あくまで ブラウザ（RP側 JavaScript）とサーバーの間の API だけです。秘密鍵を実際に保持し署名を生成する主体が USB に挿した YubiKey のような外付けハードウェアだった場合、その箱とブラウザはどう会話するのか。ここを埋めるのが CTAP2（Client to Authenticator Protocol v2） です。

CTAP2 が解くのは「秘密鍵を絶対に外へ出さない箱に対し、どう鍵生成と署名を依頼し、どう本人確認を伝え、どう結果を受け取るか」という一点です。プラットフォーム内蔵認証器（Touch ID 等）なら CTAP は OS 内部で完結しますが、ローミング認証器を理解するには CTAP の中身を直接見る必要があります。

CTAP2 の通信モデル：CBOR コマンドとトランスポート

CTAP2 では、ブラウザ側（CTAP用語で client）が認証器に対して コマンド を送り、認証器が レスポンス を返します。メッセージは JSON ではなく CBOR（Concise Binary Object Representation）でエンコードされます。バイナリでコンパクトかつパース実装が小さく済むため、メモリの限られたキー内部のファームウェアに向くからです。

これらのコマンドは複数のトランスポート上を流れます。USB-HID（FIDO 専用の HID 利用方法を定めた CTAPHID フレーミング）、NFC、BLE です。どのトランスポートでも CBOR の中身は同じで、違いは下回りのフレーミングだけです。つまり CTAP2 は「物理層に依存しないコマンドセット」として設計されています。

常駐鍵と非常駐鍵：鍵をどこに置くか

CTAP2 最大の設計分岐が、生成した秘密鍵を どこに保存するか です。

非常駐鍵（non-resident、別名サーバーサイド鍵）では、認証器は鍵ペアを生成した後、秘密鍵そのものを認証器内のマスター鍵で暗号化し、その暗号文を credentialId に詰めてサーバーへ返します。認証器は何も覚えません。後日の認証時、サーバーが allowCredentials でその credentialId を送り返すと、認証器はそれを自分のマスター鍵で復号して秘密鍵を一時的に復元し、署名してから捨てます。鍵を外出しするため、認証器の保存容量と無関係に何個でも作れます。これを 鍵ラッピング（key wrapping） と呼びます。

常駐鍵（resident key、現行仕様では discoverable credential と呼ぶ）では、認証器が credentialId・秘密鍵・user 情報（user.id や表示名）を自分の不揮発メモリ内に保存 します。サーバーは credentialId を覚えておく必要がなく、認証要求時に allowCredentials を空にできます。すると認証器は「この rpId に対して自分が保持する鍵」を列挙でき、ユーザーは ユーザー名を一切打たずに ログインできます（ユーザー名なし認証 / username-less）。これがパスキーの「アカウント選択画面が出る」体験の正体です。

ユーザー検証：PIN と生体を CTAP はどう運ぶか

CTAP2 は2段階の本人性を区別します。user presence（UP、ユーザーの存在） は「人がキーに触れた」事実だけを示すボタンタッチで、user verification（UV、ユーザー検証） は「正しい本人である」ことを PIN・指紋・PIN コード等で確認したものです。署名内の flags にそれぞれのビットが立ち、サーバーは UV が必要なら立っているかを確認します。

問題は、外付けキーには鍵盤も画面もないことが多い点です。PIN はブラウザ（client）側で入力させ、その PIN を安全にキーへ届けねばなりません。生の PIN を USB 上に流せば盗聴・リプレイの的になります。そこで CTAP2 は PIN/UV Auth Protocol を定めます。

PIN/UV Auth Protocol（概略）
1. client が authenticatorGetInfo でキーの公開鍵共有用パラメータを取得
2. client とキーが ECDH 鍵共有で共有秘密を確立（PIN を平文で流さない）
3. client は入力された PIN を共有秘密由来の鍵で暗号化してキーへ送る
4. キーは PIN を検証し、成功したら「pinUvAuthToken」を発行
5. 以後のコマンドは、このトークンで計算した HMAC（pinUvAuthParam）を添える
   → トークンはセッション限定・リトライ回数制限つき

要点は3つです。第一に PIN は ECDH 鍵共有で確立した共有秘密で暗号化されるため、USB バス上に平文 PIN は流れません。第二に、PIN 検証は キー内部 で行われ、PIN そのものはキーから出ません。第三に、PIN の連続失敗にはリトライ上限があり、規定回数（典型的には8回）を超えるとキーがロックまたは初期化され、総当たりを物理的に封じます。生体認証（指紋センサ内蔵キー）の場合は、指紋テンプレートの照合もキー内部で完結し、内蔵ユーザー検証（built-in user verification）として UV ビットを立てます。

署名カウンタ：クローンを暴く単調増加値

各認証器は鍵（または全体）ごとに 署名カウンタ（signature counter / signCount） を持ち、authenticatorGetAssertion を実行するたびにこれを増やして authenticatorData に含めます。サーバーは登録時・認証時のカウンタ値を保存し、毎回「前回保存した値より大きいか」を検証 します。

なぜこれでクローンが暴けるのか。攻撃者が物理的に秘密鍵を吸い出して別の偽キーを作ったとします。本物と偽物は独立にカウンタを進めるため、両者を交互に使うと、ある認証でサーバーが受け取るカウンタ値が前回値より小さい、または等しい逆転が起きます。サーバーはこの逆転を「鍵が複製された強いシグナル」として検出し、当該資格情報を失効させられます。秘密鍵が箱から出ない前提が崩れたことを、外側から間接的に観測する仕掛けです。

正常:   reg=5 → auth1=6 → auth2=7 → auth3=8   （常に増加、OK）
クローン: 本物=10 で認証 → 偽キー=8 で認証
         サーバーは 10 の次に 8 を受信 → 逆転を検出 → 不正の疑い

まとめ

CTAP2 は、秘密鍵を外へ出さないハードウェアキーへ、ブラウザが CBOR コマンドで鍵生成・署名・本人確認を依頼するためのプロトコルです。鍵の置き場所には2方式があり、非常駐鍵 は秘密鍵を暗号化して credentialId に外出しするので無制限に作れるがユーザー名提示が要り、常駐（discoverable）鍵 はキー内部に user 情報ごと保存するためユーザー名なしログインを可能にする代わりに容量上限を持ちます。PIN/UV Auth Protocol は ECDH 共有秘密で PIN を保護し、検証とリトライ制限をキー内部で完結させて総当たりを封じ、UV ビット1つで所持＋知識/生体を束ねます。署名カウンタ の単調増加は、専用キーにおいて秘密鍵の複製を逆転検出する補助手段ですが、同期パスキーでは 0 固定が正となります。

土台の公開鍵チャレンジはFIDO2 / WebAuthn の原理、認証器の信頼検証はパスキーと Attestation、署名検証の内部はデジタル署名スキームの内部と併せて押さえると、1回のタッチに畳まれた保証の層が原理から見通せます。