機器固有の番号から作った暗号鍵は総当たりで戻せる：AXIS Camera Station の保存認証情報（CVE-2026-63286）
製品共通の定数と 32 ビットのディスク番号だけから鍵を作ると、AES-256 でも実質 32 ビットの強さしかない。Pro 6.20 へ更新し、古いバックアップの削除と保存した認証情報の変更までやる。
何が起きたか
- 監視カメラ管理ソフト AXIS Camera Station は、カメラの認証情報・JWT 署名鍵・内部認証局の秘密鍵のパスフレーズなどを Firebird データベースに AES-256-CBC で保存していた。
- 研究者の解析では、鍵は「製品共通の定数」と「NTFS ボリュームシリアル番号」から HMAC-SHA1 と PBKDF2-SHA1 で作られていた。変わる材料は 32 ビットの番号だけなので、データベースやバックアップの写しを持つ攻撃者は番号を総当たりして鍵を再現できる（GPU で高速化も可能）。
- 研究者は工場の侵入テストで、既知の認証回避と逆シリアル化の欠陥で SYSTEM 権限を取り、復号した認証情報で全カメラに接続できたと報告している。
利用者がやること
- 更新: AXIS Camera Station Pro を 6.20 以降へ。5 系は修正予定がないと研究者に説明されているため、移行を計画する。
- 古いバックアップを消す: 6.20 未満で作ったバックアップは更新後も同じ弱い鍵のまま。更新時に自動作成される復旧用バックアップも対象。
- 認証情報を変える: カメラのパスワードなど保存していた認証情報は、漏れた前提で変更する。
- バックアップの置き場所を守る: オフライン攻撃が前提の脆弱性なので、バックアップを読める人と経路を絞る（交換した秘密情報をバックアップから再び盗まれない（Zeabur 侵害の続報） と同じ考え方）。
自分で実装するときの教訓
- 「端末ごとに違う値」（ボリュームシリアル、MAC アドレス、ホスト名など）は秘密ではない。範囲が狭く、推測や取得が容易。
- 鍵は乱数で作り、OS の鍵保管（Windows DPAPI、macOS Keychain）、KMS、HSM など、データとは別の場所で守る。暗号文と鍵の材料を同じバックアップに入れない（暗号化したデータと復号鍵を同じ場所に置かない（ソースネクスト事例と Supabase の点検項目））。
- 鍵空間の強さは「アルゴリズムのビット数」ではなく「攻撃者が知らない材料のビット数」で決まる。
注意点
- Axis の評価は CVSS 7.1（High）、10 月 28 日の告知時点で悪用は把握していないとしている。
- 研究者は旧 2 件の攻撃コードと復号ツールを公開しているので、未更新の環境は早めに対応する。