Chapter 04

Root of Trust — 「信じるしかないもの」を最小にする

この章がなぜ必要なのか——ここが全体の土台だから.

セキュリティの議論は、突き詰めると「なぜそれを信じられるのか」の連鎖になる。

「このファームウェアは正規品だ」→ なぜ？ →「署名を検証したから」 → その検証コードは正しいのか？ →「それも署名を検証したから」 → …この連鎖はどこで止まるのか？

どこかで「これは無条件に信じる」と決めなければならない。 それが Root of Trust（信頼の基点）である。

この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、検証時（02 章 7 節）

1. 定義と性質

Root of Trust とは、 「検証できないので、無条件に信じるしかないもの」である。

だからこそ、次の 2 つの性質が必要になる。

「小さいこと」が特に重要である。 検証できないものが大きいほど、そこにバグがある確率が上がり、 バグがあってもそれを検出する手段がない。

RoT の実体は、ふつう次の 3 つの組み合わせである.

要素	実体	なぜ改変できないか
不変のコード	ブート ROM（マスク ROM）	シリコンに焼かれている。物理的に書き換えられない
不変の鍵	OTP / eFuse に焼いた公開鍵のハッシュ	一度書いたら消せない（06 章）
不変のハードウェア	暗号エンジン、乱数生成器	回路そのもの

RoT の階層を見る

各層をクリックすると、その層が何を信じ、何を保証し、どこが弱点かが表示される。

2. 4 つの Root of Trust

RoT は 1 つではない。役割ごとに分けて考えるのが標準的である。

実装では、これらが 1 つの「セキュリティサブシステム」にまとまっていることが多い。

3. Immutable RoT と Updatable RoT

「改変できない」ことは強みだが、弱みでもある。

ブート ROM にバグがあったら、直せない。

これは理論上の話ではない。実際に、複数のベンダのブート ROM に 脆弱性が見つかり、シリコンの改版でしか直せなかった事例がある。

そこで多くの設計では、RoT を 2 段に分ける。

この 2 段構成が、01 章で述べた「暗号アジリティ」への答えである.

Immutable RoT が使う署名アルゴリズムは変えられない。 だが、Updatable RoT が使うアルゴリズムは後から変えられる。

だから 20 年使う機器でも、耐量子暗号への移行が（少なくとも部分的には）できる。 Immutable RoT の検証アルゴリズムだけは、慎重に選ぶ必要がある。

4. 鍵の階層

RoT には鍵が必要である。だが使う鍵を 1 本ずつ OTP に保存するわけにはいかない （OTP は数百バイト〜数 KB しかない）。

そこで鍵を階層化する。根になる 1 本だけをハードウェアに持たせ、 それ以外は必要になるたびに導出する。

• 根になる鍵を HUK（Hardware Unique Key） と呼ぶ。機器ごとに異なる秘密で、CPU からは読めない
• HUK の実体は品種によって 2 通りある。製造時に乱数を OTP に焼き込むか、 PUF（06 章）から起動のたびに再生成するか。どちらでも以降の使い方は同じである
• 使う鍵（ストレージ暗号鍵、アプリごとの鍵など）は、HUK を KDF（鍵導出関数） に 通して導出する。保存しないので、HUK が読めない限り再現できない

重要な区別: 秘密鍵と公開鍵ハッシュ

署名検証の根になる公開鍵を ROTPK（Root of Trust Public Key） と呼ぶ。 OTP に入れるのは公開鍵そのものではなく、そのハッシュである。

公開鍵そのものではなく、ハッシュを焼くのはなぜか.

RSA-3072 の公開鍵は 384 バイト、ECC P-256 でも 64 バイト。 OTP は貴重な資源なので、32 バイトのハッシュだけを焼き、 公開鍵本体はファームウェアイメージに添付する。

検証時は「添付された公開鍵をハッシュして、OTP の値と一致するか」を確認してから使う。 これで OTP の消費を 1/2〜1/12 に減らせる。

鍵の階層を組み立てる

鍵の役割を選ぶと、どこに保管し、どう派生させ、漏れたらどうなるかが表示される。

5. アテステーション（証明）

RTR（Root of Trust for Reporting）の役割である。

アテステーションとは、 「私はこういう機器で、こういうソフトウェアが動いている」を、 暗号学的に証明することである。

この証明の署名に使う機器固有の鍵を IAK（Initial Attestation Key） と呼ぶ （前節の鍵の階層図に出てきたのはこれである）。

標準化されている形式:

DICE — 小さな機器向けの巧い方式

TPM を積めない機器向けに、TCG が定めた軽量な方式である。

DICE の美点は、「鍵がコードに縛られる」ことである.

ファームウェアを 1 ビットでも書き換えると、ハッシュが変わり、 派生される鍵が変わる。すると——

• 暗号化していたデータが復号できなくなる
• サーバが期待する公開鍵と一致しなくなる

改ざんを「検出する」のではなく、「改ざんすると使えなくなる」構造にしている。 検証コードのバグで見逃す、ということが起きない。非常にエレガントである。

加えて、UDS を読めるのは第 1 段の ROM だけにして、 CDI を計算したら UDS へのアクセスをハードウェアでロックする（ラッチする）。 こうすると、後段のコードに脆弱性があっても UDS は漏れない。

6. RoT が守れないもの

RoT は万能ではない。限界を正しく理解しておく必要がある。

最後の 2 つが本質的に重い.

「セキュアブートは、正しく署名されたファームウェアなら、 脆弱でも喜んで起動する。」

セキュアブートが守るのは完全性（正規のものか）であって、 安全性（脆弱でないか）ではない。この 2 つは別物である。

だから 15 章（脆弱性管理）と 13 章（更新）が必要になる。

7. 「Time of Check to Time of Use」問題

セキュアブートには構造的な弱点がある。

t1 と t2 の間に、内容が変わっていたら？

対策:

外付けフラッシュの XIP は、構造的に難しい.

だから多くの SoC が OTFDEC / PRINCE / BEE / Flash Encryption といった「オンザフライ暗号／復号」機構を持っている（18 章〜20 章）。

ただし——暗号化は機密性を守るが、完全性は守らない。 攻撃者は内容を読めなくても、ランダムに書き換えて動作を狂わせることはできる。 完全性まで守るには、認証付き暗号（AES-GCM など）か MAC が必要になる。 ここに対応しているかどうかは、SoC によって差が大きい。

8. この章のまとめ

次章では、この RoT から始まる検証の連鎖—— セキュアブートの実際を見る。