前々からFIDO2ハードウェアセキュリティキーを導入したいなあと思いつつ先延ばしにしていたのですが、やっとやる気になってSwissbit iShield Keyというのを導入することに。
有名なのはYubikeyだと思う（というか私はこれしか知らなかった）のですが、買おうかと思っていたYubiKey Security Key C NFCはファームウェア5.7.0より古いものはサイドチャネル攻撃によってチップ内の秘密鍵を抽出可能な脆弱性※があり、ファームウェアアップデートは仕様上不可能、すぐ入手可能な商品はファームウェアが不明で断念。
この攻撃には高度な知識と設備が必要なうえに、攻撃者は事前にアカウントのIDパスワードを盗んで被害者が気付かないうちに本体も盗んで分解、必要な操作を終えたらまた被害者のもとに返却、という高難易度の攻撃だそうなので一般人がターゲットになる可能性はないと考えて良さそうかなとも思ったのですが、折角なので脆弱性が見つかっているファームウェアじゃないほうが良いですし、またパスキーを保存できれば良くて安いほうが良いのでiShield Keyにしました。
合っているのかは分かりませんが、LLM調べでは保存できるパスキー本数はiShield Keyが32本に対して、YubiKey Security Key C NFCはファームウェア5.7以降では100本、5.6以前では25本だそうです。
ちなみに今年発売されるiShield Key 2ではファームウェア更新に対応しているそうなので将来的に脆弱性が見つかっても自分で更新して使い続けることができるようですが、価格も上がるみたいなので現時点では初代にしておきました。
製品自体の寿命は非常に長く使えるように設計されているようですが、今後FIDO仕様が進化していったり、ECC（楕円曲線暗号）が量子コンピュータで破られるようになったりするであろうことを考えると、5年毎程度でローテーションしていく消耗品と割り切っておいたほうが良いのかなと。
不正売買で話題になった証券会社のログインには現在未対応（楽天証券は2025年秋予定だそうで、SBI証券とか他社も早く続いて欲しい…）ですが、Google、Proton、Bitwardenとか設定できるものには設定しておきました。
Google、BitwardenはTOTPをやめてパスキーに一本化することができたのですが、Protonは現時点では仕様上無理みたいなので併用になっています。金融機関系はFIDO2に早く対応してほしいです。
現実的にパスキーが設定できるサービスに全部物理キーを使うのは利便性が悪すぎるので、基本的にはGoogleパスワードマネージャーにパスキーを保存して、Google自体は物理キーという感じでいいかなと思っています。
パスキーはBitwardenに保存することもできるのですが、Bitwardenに保存した場合はアンロック中には秘密鍵が平文でRAMに出るみたいなので、同期したい場合にはGoogleパスワードマネージャーとかiCloudキーチェーンを使ったほうが安全っぽいです。
マルウェアに感染してRAMを抜かれる状態になっていたらパスキーの鍵自体は盗まれなくてもログイン中のセッションを乗っ取られたりしそうですし、まあBitwarden保存のパスキーもTOTPよりは安全みたいなので悪くはないのかなとは思いますが。
このあたりはよく理解していなかったので、従来のTOTPとあわせてLLMでまとめたものを載せておきます。
（間違っていたら教えてください！）
パスキー時代の「鍵の居場所」
パスキーは公開鍵暗号を用いた FIDO 認証。
流出・フィッシングに強く、Apple と Google はクラウド同期型パスキーをハードウェア依存で実装した。
主要 3 方式と TOTP の立ち位置
| 方式 | 鍵の保管 | 同期時の暗号化 | 平文鍵が汎用 RAM に出るか |
|---|---|---|---|
| iCloud Keychain (iPhone) |
Secure Enclave | E2EE (iCloud) | 出ない |
| Google PM (Pixel / Windows など) |
Titan M2・TPM | E2EE (GPM PIN) | 出ない |
| Bitwarden | 暗号化 Vault | ゼロナレッジ同期 | アンロック中は出る |
| TOTP アプリ (例: Google Authenticator) |
SQLite に Base32 | ※同期は任意／E2EE無し | 常時出る |
1. iCloud Keychain と Secure Enclave
Apple ID でログインした全デバイスに、封筒暗号化されたパスキーを配布。
復号は各デバイスの Secure Enclave 内で実行され、平文鍵がユーザー空間には出ない。
2. Google Password Manager (GPM) と Titan M2 / TPM
Pixel では Titan M2、Windows では TPM/StrongBox が鍵を非移出で保持。
クラウド同期時は「GPM PIN」による E2EE。PIN は英数字も指定可。
3. Bitwarden Vault の特徴
- クラウドへ送る前に ゼロナレッジ暗号化（AES-256 + PBKDF2/Argon2）。
- アンロック中は復号鍵を RAM に保持するため、ローカルマルウェア対策が鍵。
- OSS・自己ホスト可。
ロック/タイムアウトを短く設定し、デバイス暗号化と 2FA で補強を。
4. TOTP アプリの秘密鍵セキュリティ
TOTP は共有秘密鍵（seed）を使い、30 秒ごとに HMAC-SHA1 を再計算する。
- Google Authenticator (Android) は
.dbに Base32 平文で保存。root 権限があれば閲覧可。 - コード更新のため seed を RAM に常駐させる実装が一般的（リスト表示中はずっと平文）。
- クラウド同期機能は 現時点で E2EE でない と研究者が指摘。
- 代替策：Aegis などハードウェア Keystoreと暗号化 Vault を採用する OTP アプリを利用。
- より高硬度が必要なら FIDO2/U2F トークンへ移行。
5. 実務選択ガイド
- Apple エコシステム中心 → iCloud Keychain が最も摩擦が少ない。
- Android + PC 混在 → GPM + PIN。PIN を長く設定。
- OSS／自己ホスト主義 → Bitwarden + ハードウェア鍵併用。
- レガシーサービス → TOTP だが、Aegis など Keystore 対応アプリに置換。
鍵は「どこに居るか」「いつ平文になるか」で脅威モデルが決まる。
自分の運用ポリシーに合わせて鍵の居場所をデザインしよう。
よろしければ応援クリックお願いします
|  |
コメント