Chapter 13
セキュア OTA とロールバック防止
この章がなぜ必要なのか——更新できない機器は、法的にも技術的にも終わっているから.
03 章で見たとおり、EU CRA はサポート期間中のセキュリティ更新の提供を義務化した。 更新機能を持たない機器は、EU 市場で売れなくなる。
そして技術的にも——脆弱性は必ず見つかる。 見つかったときに直せるかどうかが、製品の寿命を決める。
この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、ハッシュ（04 章 4 節）、eFuse（06 章 2 節）、完全性（06 章 6 節）、機密性（06 章 6 節）、AES（08 章 8 節）、レート制限（09 章 5 節）、必要（09 章 6 節）、Espressif（12 章 3 節）、NXP（12 章 3 節）、ライフサイクル状態（12 章 1 節）
1. OTA が守るべき 5 つの性質
| 性質 | 内容 | 手段 |
|---|---|---|
| 完全性 (Integrity) | 転送中に壊れていない・改ざんされていない | ハッシュ + 署名 |
| 真正性 (Authenticity) | 正規のメーカーが作ったものである | 署名検証（05 章） |
| 機密性 (Confidentiality) | 中身を第三者に見られない（IP 保護・秘密の秘匿） | 暗号化（任意だが推奨） |
| 鮮度 (Freshness) | 古いバージョンに戻されない | ロールバック防止（本章 4 節） |
| 原子性 (Atomicity) | 途中で電源が切れても壊れない | A/B 面、トランザクション |
このうち、真正性とロールバック防止が最重要である。
OTA の検証チェーンを見る
各段階での検証と、どれか 1 つを飛ばすと何が起きるかを確かめられる。
2. 基本の流れ
手順 4 と 7 で二重に検証する理由.
手順 4 は「無駄な再起動を避ける」ため（ダウンロード直後に弾く）。 手順 7 はセキュリティ上必須である。
手順 4 と 6 の間に、フラッシュの内容が書き換えられているかもしれない （04 章の TOCTOU）。ブートローダが起動のたびに検証するのが本筋である。
3. A/B 面（デュアルバンク）
最も確実な構成である。
| 方式 | 内容 | 長所 | 短所 |
|---|---|---|---|
| スワップ方式 | 2 面の内容を入れ替える | どちらのスロットからも起動できる | 入れ替えに時間がかかる。スクラッチ領域が要る |
| オーバーライト方式 | Slot 1 の内容を Slot 0 に上書きする | 単純 | 失敗すると戻れない（旧版が消える） |
| ダイレクト XIP | どちらのスロットからも直接実行する | 入れ替え不要で速い | リンクアドレスが 2 通り必要 |
MCUboot はこれら複数のモードに対応している。
フラッシュ容量の問題
アプリケーションが 400 KB なら、最低でも 900 KB 程度が要る。 フラッシュ 512 KB の MCU では A/B 面が取れない。
| 対策 | 内容 | 注意 |
|---|---|---|
| 外付けフラッシュに Slot 1 を置く | 内部に Slot 0、外部に Slot 1 | 外部は暗号化する（06 章） |
| 差分更新（デルタ更新） | 差分だけ送る。適用時に旧版と合成 | 合成中に電源断すると危険。中間状態の保護が必要 |
| 圧縮 | 転送量とスロットサイズを減らす | 展開に RAM が要る |
| 単一バンク + リカバリ | 失敗したらブートローダのリカバリで復旧 | リカバリ経路が攻撃面になる（05 章） |
「A/B 面が取れるフラッシュ容量か」は、SoC 選定の重要な基準である.
01 章で述べたとおり、フラッシュ容量は後から変えられない。 「更新機能を後で付けよう」としたら容量が足りなかった、という事故が起きる。
企画段階で、アプリケーションサイズの見積り × 2 + 余裕を確保すること。
4. ロールバック防止
最も見落とされる、そして最も重要な機構である。
攻撃のシナリオ
署名検証だけでは、これを防げない.
v1.0 はメーカーが正規に署名したファームウェアである。 署名検証は当然通る。「古い」ことを検出する別の仕組みが必要である。
対策: セキュリティバージョン番号（SVN）と単調カウンタ
| 単調カウンタの実装 | 内容 |
|---|---|
| OTP / eFuse のビット列 | ビットを 1 本ずつ焼く。焼ける本数が上限（例: 32 回まで） |
| 専用の単調カウンタ回路 | 一部の SoC / セキュアエレメントが持つ |
| RPMB（Replay Protected Memory Block） | eMMC / UFS の機能。鍵付きで書き込み回数を保護 |
| TPM の NV カウンタ | TPM を積んでいる場合（22 章） |
OTP のビット数が、更新可能回数の上限になる.
eFuse に 32 ビット割り当てたなら、SVN は 32 回しか上げられない。 20 年使う機器で、年 2 回のセキュリティ更新なら 40 回必要になる。
だから——SVN は「表示上のバージョン」とは別に管理する。
SVN は「戻ってはいけない境界」を示すもの。上げすぎるとカウンタの寿命を無駄に消費する SVN を上げるのは「その版より前に戻したくない」ときだけにする。 これで OTP の消費を最小限にできる。
カウンタを更新するタイミング
「確定（confirm）」の設計が、可用性とセキュリティのバランスを決める.
- 早く確定する → ロールバック防止が強い。だが文鎮化のリスク
- 遅く確定する → 復旧できる。だがその間、旧版に戻せる窓が開く
実務的には、「新版が起動して、自己診断とネットワーク接続に成功したら確定」 が妥当な線である。
5. イメージの暗号化
必須ではないが、多くの場合で望ましい。
| 目的 | 内容 |
|---|---|
| 知的財産の保護 | ファームウェアを解析されない |
| 脆弱性の隠蔽 | 修正内容から脆弱性を逆算されない（パッチ差分解析への対策） |
| 秘密の保護 | イメージ内の設定値などを隠す |
「パッチ差分解析」は現実的な脅威である.
攻撃者は v1.0 と v1.1 の差分を取り、 「どこが修正されたか」から脆弱性の場所を特定する。 PC のソフトウェアでは日常的に行われている手法である。
IoT では更新が行き渡るのに数週間〜数か月かかるため、 「攻撃者が脆弱性を知ってから、全機器が更新されるまで」の窓が長い。 イメージの暗号化は、この窓を守る価値がある。
鍵の配り方
| 方式 | 内容 | 評価 |
|---|---|---|
| 全機器共通の鍵で暗号化 | 単純 | 1 台から鍵が漏れたら全滅。時間稼ぎのみ |
| 機器固有鍵でラップした鍵を個別配信 | イメージ本体は共通鍵で暗号化。その鍵を機器ごとに暗号化して配る | 実用的で安全。サーバ側の負荷も小さい |
| 機器ごとにイメージ全体を暗号化 | 完全に個別 | サーバ負荷が大きい。大規模には向かない |
これは TLS のハイブリッド暗号や、PGP と同じ考え方である。
MCUboot は暗号化イメージに対応しており、 ECIES（ECDH + AES-KW）や RSA-OAEP による鍵配送をサポートしている。
6. 電源断への耐性
更新中に電源が切れても壊れないことは、必須要件である。
| 危険な瞬間 | 対策 |
|---|---|
| ダウンロード中 | Secondary Slot に書くだけ。Primary は無傷 |
| スワップ中 | 最も危険。スワップの進捗を不揮発に記録し、再開できるようにする |
| ブートローダ更新中 | ブートローダ自体は更新しない設計が安全。するなら二重化 |
| カウンタ更新中 | 順序を設計する（本章 4 節） |
ブートローダの更新は最大のリスクである.
ブートローダを書き換えている最中に電源が切れると、確実に文鎮化する。
対策:
- ブートローダを更新しない設計にする（機能を最小に保つ = 04 章の Immutable RoT に近づける）
- どうしても更新するなら、2 面持ちにして ROM が選択する
- ST の STM32H5 や NXP の一部品種は、ブートローダ領域の二重化に対応している
7. 更新の運用設計
技術以外の部分も、実は同じくらい重要である。
| 項目 | 考慮点 |
|---|---|
| 段階的展開（カナリアリリース） | 1 % → 10 % → 100 %。問題があれば止める |
| 更新のタイミング | ユーザの使用時間を避ける。産業機器は保守窓を調整する |
| ネットワーク帯域 | 全機器が同時にダウンロードするとサーバが落ちる。ランダムな遅延を入れる |
| 電池残量の確認 | 更新中に電池切れは最悪。閾値を設ける |
| 失敗の検出と報告 | どれだけの機器が更新に失敗したかを把握する |
| 強制更新 | 深刻な脆弱性のときは、ユーザの同意なしに更新できるか（法的・契約的な検討が要る） |
| サポート終了 (EOL) | いつまで更新するかを購入前に明示する（03 章の PSTI・CRA 要件） |
「全機器が同時に更新を取りに来る」問題は、実際に起きる.
100 万台の機器が一斉にダウンロードを始めると、 CDN の帯域が飽和し、更新自体が失敗する。
- チェック間隔にランダムなジッタを入れる
- サーバ側でレート制限し、機器には再試行させる
- 段階的展開で母数を制御する
技術的な正しさだけでは運用できない。
8. 標準とプロトコル
| 標準 | 内容 |
|---|---|
| IETF SUIT (RFC 9019 / 9124 / 9459 など) | 組み込み向けのソフトウェア更新アーキテクチャとマニフェスト形式。CBOR/COSE ベース |
| TUF / Uptane | The Update Framework。鍵の危殆化（漏洩して信頼できなくなること）に耐える設計。Uptane は自動車向け |
| LwM2M Firmware Update | OMA LwM2M のオブジェクト 5。制約デバイス向け |
| PSA Firmware Update API | TF-M の一部（17 章） |
| OMA-DM / TR-069 | レガシーだが、通信機器で現役 |
SUIT マニフェストの考え方は参考になる.
「何を、どこから取得し、どう検証し、どこに書き、いつ再起動するか」を 署名されたマニフェストに記述する。
- イメージ本体とマニフェストを分離できる（マニフェストだけ先に検証）
- 複数のコンポーネント（MCU + 無線モジュール + FPGA など）をまとめて扱える
- 依存関係とバージョン制約を表現できる
自前でプロトコルを設計する前に、SUIT の RFC を読む価値がある。
TUF / Uptane の「鍵の危殆化に耐える」設計:
これは「オンラインに置く鍵の権限を最小にする」という原則の実装である.
署名サーバがハッキングされても、 オフラインの Root/Targets キーがなければ偽のファームウェアは配れない。
自動車業界では Uptane が事実上の標準になりつつある。 一般 IoT でも、署名鍵をオフライン HSM に置き、配信サーバには置かない という原則は共通である。
9. 実装の選択肢
| 実装 | 特徴 |
|---|---|
| MCUboot | 最も広く使われる。A/B、ロールバック防止、暗号化イメージに対応 |
| ベンダ提供（ST の SBSFU、NXP の ..., Espressif の esp_ota） | チップの機能に最適化されている |
| クラウドサービス連携 | AWS IoT Jobs / OTA、Azure Device Update、各社の IoT PaaS |
| 自作 | 強く非推奨 |
OTA も自作しないこと.
セキュアブートと同じで、細部で必ず事故る領域である。
- スワップの中断復帰
- ロールバック防止のタイミング
- 署名検証の抜け
- 電源断のあらゆるパターン
既に何百万台で動いている実装を使うのが正解である。
10. この章のまとめ
| ポイント | 内容 |
|---|---|
| 法的要求 | CRA がサポート期間中の更新提供を義務化。更新できない機器は売れない |
| 5 つの性質 | 完全性・真正性・機密性・鮮度・原子性 |
| 二重検証 | ダウンロード直後と起動のたびに検証する（TOCTOU 対策） |
| A/B 面 | 最も確実。フラッシュ容量は企画段階で確保する（後から変えられない） |
| ロールバック防止 | 署名検証だけでは防げない。SVN + 単調カウンタが必要 |
| SVN の運用 | 脆弱性修正のときだけ上げる。OTP のビット数が上限になる |
| 確定のタイミング | 起動して自己診断が通ってからカウンタを更新する |
| イメージ暗号化 | パッチ差分解析への対策として価値がある |
| 鍵の配り方 | 共通鍵で暗号化 + その鍵を機器ごとに暗号化して配る |
| ブートローダ更新 | 最大のリスク。更新しない設計が安全 |
| 運用 | 段階的展開・ジッタ・電池確認・EOL の明示 |
| 鍵の分離 | オンラインに置く鍵の権限を最小に（TUF / Uptane の原則） |
| 実装 | MCUboot などを使う。自作しない |
次章では、機器の一生を通した状態管理—— ライフサイクル状態と廃棄を扱う。