Chapter 22
セキュアエレメントと TPM
この章がなぜ必要なのか——「MCU の内蔵機能で足りるか」を判断するため.
17 章〜21 章で見たとおり、現代の MCU は多くのセキュリティ機能を持つ。 では、なぜまだ外付けのセキュアエレメントが売られているのか。
答えは 2 つある。
いつ使い、いつ使わないかを判断できるようになることが、この章の目的である。
注意: 各製品の仕様・認証取得状況は変わりうる。 必ずデータシートと、認証機関の証明書で確認すること。
この章で使う既出の用語（定義は各リンク先）. 可用性（01 章 4 節）、物理攻撃（04 章 6 節）、Crypto（07 章 4 節）、TRNG（08 章 8 節）、必要（09 章 6 節）、AES-128（10 章 2 節）、ECDSA（10 章 2 節）、暗号演算（10 章 7 節）、フラッシュ暗号化（11 章 5 節）、NXP（12 章 3 節）、PKI（12 章 4 節）、監査ログ（12 章 3 節）、ロールバック防止（13 章 1 節）、量産（14 章 5 節）、開発（14 章 5 節）、要件（15 章 8 節）、運用（15 章 8 節）、PSA（17 章 1 節）、仕様（17 章 1 節）、ST33（18 章 8 節）、STSAFE-A（18 章 8 節）、ELE（19 章 5 節）、SRK（19 章 2 節）、仕組み（20 章 7 節）、HSM（21 章 6 節）、Infineon（21 章 8 節）、Microchip（21 章 8 節）
1. セキュアエレメントとは何か
独立した耐タンパチップであり、 「鍵を絶対に外に出さない」ことに特化して設計されている。
提供する機能:
| 機能 | 内容 |
|---|---|
| 鍵の生成 | チップ内で生成し、外に出さない（12 章の方式 B） |
| 署名・検証 | ECDSA、RSA |
| 鍵共有 | ECDH |
| 対称暗号 | AES、HMAC |
| 乱数生成 | 高品質な TRNG（08 章） |
| 単調カウンタ | ロールバック防止に使える（13 章） |
| セキュアストレージ | 少量のデータを保護して保存 |
| 証明書の保管 | 事前プロビジョニング済み（12 章） |
2. なぜ MCU 内蔵では足りないのか
耐タンパ設計の水準の違い
| 対策 | 一般的な MCU | セキュアエレメント |
|---|---|---|
| DPA 対策（09 章） | 品種による。明示されないことも | 設計の前提。評価済み |
| フォールト検出（10 章） | ブラウンアウト検出程度 | 専用のセンサ群（電圧・クロック・温度・光） |
| アクティブシールド | なし | チップ表面に配線を張り、断線を検出 |
| メモリのスクランブル | まれ | 標準的 |
| バスの暗号化 | まれ | 標準的 |
| 冗長演算 | ソフトウェアで実装 | ハードウェアで実装 |
| 異常検出時の応答 | リセット程度 | 鍵の即時消去 |
| 第三者評価 | PSA L1〜L3 が多い | CC EAL5+〜EAL6+ / AVA_VAN.5 が多い |
AVA_VAN.5 の意味を思い出してほしい（03 章）。
「High」レベルの攻撃ポテンシャルを持つ攻撃者に耐えると評価されている、 ということである。これは専門ラボによる長期間の攻撃に耐える水準である。
02 章の攻撃者クラスで言えば、クラス 4〜5 を想定した設計である。
一般的な MCU の内蔵機能は、通常そこまでの評価を受けていない。
プロビジョニングの問題（12 章）
これが実は、より重要な理由かもしれない。
| 問題 | セキュアエレメントによる解決 |
|---|---|
| 工場に鍵を渡したくない | プロビジョニング済み品を買うだけ |
| 自社で CA を運用したくない | ベンダの CA が署名した証明書が入っている |
| 少量生産で PKI を組めない | 少量から使える |
| 機器ごとに違う鍵を入れたい | 最初から入っている |
BOM に数十〜数百円足すだけで、12 章の困難がほぼ消える.
自前で HSM を用意し、CA を運用し、工場の書き込み装置を保護し、 監査ログを取り、鍵のライフサイクルを管理する—— この体制を構築・維持するコストと比べれば、圧倒的に安い。
小〜中規模のメーカーには、これが最も現実的な解である。
3. 主なセキュアエレメント
比較
| 製品 | ベンダ | 主な機能 | 認証（公称） |
|---|---|---|---|
| ATECC608A/B | Microchip | ECC P-256、ECDH、ECDSA、SHA-256、HMAC、AES-128。16 スロット | JIL High 相当の対策を謳う |
| SE050 / SE051 | NXP | RSA（〜4096）、ECC（各種曲線）、AES、アプレット方式 | CC EAL6+ AVA_VAN.5 |
| OPTIGA Trust M | Infineon | ECC P-256/384、RSA 1024/2048、AES、シールドコネクション | CC EAL6+（ハードウェア） |
| STSAFE-A110 | ST | ECC P-256/384、鍵ペア生成、証明書保管 | CC 認証取得を公称 |
| ATECC608 TrustFLEX 等 | Microchip | 上記の派生（プロビジョニングモデル違い） | 同上 |
セキュアエレメントを比較する
用途と要件を選ぶと、MCU 内蔵で足りるか、外付けが要るかが表示される。
選ぶときの観点
| 観点 | 内容 |
|---|---|
| 対応アルゴリズム | ECC のみか、RSA も要るか。曲線の種類 |
| 鍵スロット数 | いくつの鍵を保管する必要があるか |
| インタフェース | I2C（多数）、SPI、ISO 7816 |
| 消費電力 | 電池駆動なら重要。スリープ電流 |
| プロビジョニングモデル | 事前注入か、自社で入れるか（12 章） |
| ホストライブラリ | MCU 側のドライバ・ミドルウェア。PSA Crypto ドライバの有無 |
| 認証レベル | CC の EAL と AVA_VAN（03 章） |
| 供給の安定性 | 長期供給の保証。10〜20 年使う機器では重要 |
ホストとの通信の保護
セキュアエレメント自体が安全でも、MCU との間の I2C バスは露出している。
| 攻撃 | 内容 |
|---|---|
| バス盗聴 | I2C の信号を読む。署名結果は見えるが、鍵は見えない |
| バス上での中間者 | MCU と SE の間に割り込んで、要求や応答を改ざんする |
| SE の差し替え | 攻撃者が用意した偽の SE を接続する |
対策:
| 対策 | 内容 |
|---|---|
| シールドコネクション | MCU と SE の通信自体を暗号化・認証する（OPTIGA の用語） |
| I/O 保護鍵 | ATECC608 の同等機能。事前に共有した鍵で通信を保護 |
| SE の認証 | SE が持つ製造証明書を MCU が検証する |
ただし、この対策には「鶏と卵」の問題がある.
シールドコネクションの鍵を、MCU 側のどこに置くのか。 MCU のフラッシュに置くなら、それを読まれたら中間者攻撃ができる。
完全な解はない。 現実的には——
- MCU 側の鍵をフラッシュ暗号化・読み出し保護で守る（06 章）
- バスの配線を基板の内層に通す（プロービングを難しくする）
- SE を MCU の直下に配置する（配線長を最短に）
重要なのは、「SE を使えば MCU 側の対策が不要になるわけではない」ということである。
4. TPM（Trusted Platform Module）
PC 由来の標準化されたセキュリティチップである。
| 項目 | 内容 |
|---|---|
| 標準 | TCG（Trusted Computing Group）の TPM 2.0 仕様 |
| インタフェース | SPI、I2C、LPC |
| 主な製品 | Infineon SLB 9670/9672、ST ST33、Nuvoton NPCT7xx、Microchip |
TPM の特徴的な機能
| 機能 | 内容 | |
|---|---|---|
| PCR（Platform Configuration Register） | 測定値を「拡張」して蓄積するレジスタ。$`\text{PCR} \leftarrow H(\text{PCR} \ | \text{測定値})`$ |
| シーリング (Sealing) | 特定の PCR 値のときだけ復号できるようにデータを封印する | |
| Quote（アテステーション） | PCR 値に署名して、外部に状態を証明する（04 章） | |
| 鍵の階層 | EK（Endorsement Key）→ SRK → 各種の鍵 | |
| NV カウンタ | 単調カウンタ（13 章のロールバック防止に使える） |
PCR とシーリングの組み合わせが、TPM の真骨頂である.
検証ロジックを迂回されても効くのが強み。DICE（04 章）と同じ発想がここにも現れる これは 04 章の DICE と同じ発想である。 「改ざんを検出する」のではなく、「改ざんすると使えなくなる」。 検証ロジックのバグで見逃す、ということが起きない。
Windows の BitLocker、Linux の LUKS + TPM がこの仕組みを使っている。
TPM を IoT で使うか
| 向いている | 向いていない |
|---|---|
| Linux が動くゲートウェイ・エッジ機器 | 小規模な MCU |
| 測定ブートとアテステーションが要る（04 章） | 消費電力が厳しい機器 |
| PC 由来のソフトウェア資産を使える | コストが厳しい機器 |
| 標準化されている（ベンダロックインが少ない） | — |
MCU には TPM ではなく、セキュアエレメントが適していることが多い.
TPM セキュアエレメント 標準化 TCG の厳密な標準 ベンダ独自（API も独自） 機能 PCR、シーリング、Quote など豊富 鍵と暗号演算に特化 サイズ・消費電力 大きい 小さい ソフトウェア tpm2-tss などのスタックが必要（大きい） 軽量なドライバ 価格 やや高い 安い 「MCU + セキュアエレメント」「Linux + TPM」という組み合わせが典型的である。
5. どう使い分けるか
判断のフロー
使い分けの実際
| 用途 | 置き場所 |
|---|---|
| 機器の長期秘密鍵（アイデンティティ） | セキュアエレメント（物理攻撃を想定するなら） |
| クラウド接続用の証明書と鍵 | セキュアエレメント（プロビジョニング済み品） |
| セッション鍵 | MCU 内蔵（大量・高速に必要） |
| 大量データの暗号化 | MCU 内蔵（SE では遅すぎる） |
| ファームウェア署名の検証鍵 | MCU の OTP（公開鍵なので SE 不要） |
| 測定ブートの記録 | TPM の PCR（Linux 系）／ MCU のセキュアレジスタ |
「全部 SE に入れる」は間違いである.
SE は遅い。I2C 経由で、1 回の ECDSA 署名に数十〜数百ミリ秒かかる。 大量データの暗号化には使えない。
正しい構成:
SE の速度は MCU の暗号アクセラレータに遠く及ばない。使いどころを絞ることで両方の利点が取れる 「めったに使わないが、絶対に漏れてはいけない鍵」を SE に置く。 これが役割分担の原則である。
6. コストの見積り
| 項目 | 目安 |
|---|---|
| セキュアエレメントの単価 | 数十円〜数百円（数量による） |
| 基板面積 | 数 mm²（小さい） |
| 開発工数 | ホストライブラリの統合。数日〜数週間 |
| プロビジョニングの節約 | 自社 PKI の構築・運用コストが不要になる |
比較すべきコスト:
| 自前でやる場合 | 内容 |
|---|---|
| HSM の購入・保守 | 数百万円〜 |
| CA の構築・運用 | 人件費と監査 |
| 工場の書き込み装置の保護 | 装置と手順 |
| 鍵管理の監査対応 | 継続的な工数 |
| 事故が起きたときの回収 | 予測不能 |
数万台規模までなら、SE を使うほうが確実に安い.
それ以上の規模になると、 自社 PKI + MCU 内蔵機能のほうが単価で有利になる場合がある。 ただしその場合も、プロビジョニングの体制構築が必要である（12 章）。
7. PSA Crypto API との統合
17 章で見た PSA Crypto API は、セキュアエレメントを透過的に扱える。
/* 鍵の「置き場所」を lifetime で指定する */
psa_set_key_lifetime(&attr,
PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION(
PSA_KEY_PERSISTENCE_DEFAULT,
SECURE_ELEMENT_LOCATION)); /* ★ SE に置く */
psa_generate_key(&attr, &key_id); /* SE の中で生成される */
/* 使い方は内蔵鍵とまったく同じ */
psa_sign_hash(key_id, PSA_ALG_ECDSA(PSA_ALG_SHA_256), ...);これは実務的に大きな価値がある.
- アプリケーションコードを変えずに、SE の有無を切り替えられる
- 開発中は MCU 内蔵で進め、量産時に SE に切り替える、といった運用ができる
- SE のベンダを変えても、ドライバを差し替えるだけ
PSA Crypto API の Secure Element Driver Interface が この抽象化を提供している。
SE を採用するなら、PSA Crypto API 経由で使うことを検討する価値がある。
8. 導入時の注意点
| 注意点 | 内容 |
|---|---|
| 供給の長期安定性 | 10〜20 年使う機器では、SE の供給終了がリスク |
| ロックされた設定 | ATECC608 などは設定を確定するとロックされ、変更できない |
| 設定の検証 | ロック前に、設定内容を必ず検証する（間違えると廃棄） |
| 通信の保護 | I2C バスの中間者対策（本章 3 節） |
| 性能 | ECDSA 1 回で数十〜数百 ms。設計時に織り込む |
| 消費電力 | スリープ電流と、演算時のピーク電流 |
| ホストライブラリのサイズ | フラッシュを数十 KB 使うことがある |
| エラー処理 | SE が応答しない場合の挙動を設計する |
/* SE の異常を検出したときの設計 */
if (se_sign(hash, sig) != SE_OK) {
/* ★ 「署名なしで続行」は絶対にダメ */
log_security_event(SE_FAILURE);
enter_safe_state(); /* 通信を止める、機能を制限する */
}「SE が壊れたら動かなくなる」ことを、可用性の要件と突き合わせること.
安全側に倒すと、SE の故障で機器が使えなくなる。 可用性を優先すると、攻撃者が SE を物理的に無効化する攻撃が成立する。
どちらを選ぶかは、製品の性質による設計判断である。 少なくとも、明示的に決めて文書化すること。
9. この章のまとめ
| ポイント | 内容 |
|---|---|
| SE の本質 | 独立した耐タンパチップ。鍵を絶対に外に出さない |
| MCU との差 | 物理攻撃耐性の水準（AVA_VAN.5 相当）と、プロビジョニング |
| プロビジョニング | 12 章の困難がほぼ消える。小〜中規模には最も現実的 |
| 主な製品 | ATECC608、SE050/051、OPTIGA Trust M、STSAFE-A |
| バスの保護 | I2C は露出している。シールドコネクションが要るが、鍵の置き場所に鶏卵問題 |
| TPM | PCR・シーリング・Quote。「改ざんすると使えなくなる」構造 |
| TPM vs SE | Linux ゲートウェイには TPM、MCU にはセキュアエレメント |
| 使い分け | めったに使わないが絶対に漏れてはいけない鍵を SE に。セッション鍵は MCU で |
| よくある誤り | 全部 SE に入れる（遅すぎる）。SE があれば MCU の対策は不要（間違い） |
| コスト | 数万台規模までは SE のほうが安い。自社 PKI の構築費と比較する |
| PSA Crypto API | SE の有無をコードを変えずに切り替えられる。採用時は検討する価値がある |
| 設計判断 | SE 故障時に安全側か可用性側かを明示的に決める |
次章は最終章である。ここまでの内容を、 要件から品種を選ぶための指針としてまとめる。