Chapter 01

組み込みセキュリティはなぜ難しいのか

この章がなぜ必要なのか——「PC と同じつもり」で設計すると必ず破られる.

サーバやスマートフォンのセキュリティと、IoT 組み込み機器のセキュリティは、 前提条件が根本的に違う。

最大の違いは 1 つ。攻撃者が現物を手に持てることである。 ここから、他のすべての困難が派生する。

1. 決定的な違い — 攻撃者が現物を持っている

サーバは鍵のかかったデータセンターにある。スマホは持ち主が肌身離さず持っている。

IoT 機器は違う。 スマートロック、電力メータ、ネットワークカメラ、EV 充電器—— これらは誰でも買えるし、屋外に設置されている。

攻撃者は次のことができる。

これが最も重い制約である.

ネットワーク越しの攻撃には「試行回数の制限」「異常検知」「アカウントロック」という 防御が使える。物理的に手元にある機器には、それが一切効かない。

だから組み込みでは、「破られるまでのコスト」を上げるという考え方になる。 「絶対に破られない」は存在しない。「割に合わないほど高くつく」を目指す。

2. 攻撃コストと防御コストの非対称

攻撃面を見る

機器の各部位をクリックすると、そこにどんな攻撃があり、いくらで実行でき、 何で防ぐのかが表示される。

攻撃の難度は、必要な設備と時間でおおむね決まる。

防御の投資は、この表のどこまでを想定するかで決まる。 一般消費者向け IoT なら、上から 5 番目くらいまでを止めれば実用上は十分である。 決済端末や自動車の ECU なら、下 3 行まで考える必要がある。

セキュリティは「レベル」ではなく「境界線をどこに引くか」である.

JIL（Joint Interpretation Library）という枠組みでは、攻撃の困難さを 経過時間・専門性・対象知識・機材へのアクセス・機材の高度さという項目で点数化し、 合計点で「Basic / Enhanced-Basic / Moderate / High / Beyond-High」に分類する。

Common Criteria の AVA_VAN や、GlobalPlatform の SESIP はこの点数を使う。 「どのレベルまで耐えるか」を最初に決めることが設計の出発点になる。

3. 5 つの構造的な困難

困難 1: リソースが足りない

これが効いてくるのは、たとえばこういうところである。

• RSA-2048 の署名検証をソフトウェアでやると、Cortex-M4 @100 MHz で数百ミリ秒かかる
• TLS ハンドシェイクは RAM を数十 KB 消費する（証明書チェーンのバッファだけで数 KB）
• ファームウェアの二面持ち（A/B）は、フラッシュを 2 倍必要とする（13 章）
• 暗号化ストレージは、書き込みのたびに演算が入る

だからハードウェアアクセラレータが重要になる.

AES・SHA・公開鍵演算・乱数生成をハードウェアで持っているかどうかで、 できる設計が変わる。08 章と 17 章〜21 章で、各社が何を持っているかを見る。

困難 2: 寿命が長い

今日安全な暗号が、20 年後も安全とは限らない。

• SHA-1 は 2005 年に理論的に破られ、2017 年に実際の衝突が示された
• RSA-1024 は現在では使うべきでないとされる
• 耐量子暗号（PQC）への移行が始まっている（NIST が ML-KEM / ML-DSA / SLH-DSA を標準化）

「暗号アジリティ」という要件.

アルゴリズムを後から差し替えられる設計にしておくこと。 ハードウェアアクセラレータが特定のアルゴリズムに固定されていると、これができない。

特にブート ROM に焼かれた署名検証アルゴリズムは変更できない。 20 年使う機器なら、RoT の署名アルゴリズムを何にするかは重い判断である。

困難 3: 更新が難しい

サーバなら毎日パッチを当てられる。IoT ではそうはいかない。

それでも更新機能は必須である.

EU CRA は「脆弱性に対処し、セキュリティ更新を提供すること」を法的義務にした（03 章）。 更新できない機器は、脆弱性が 1 つ見つかった時点で製品として終わる。

13 章で、この難しさに正面から取り組む。

困難 4: 開発チームに専門家がいない

これは技術的な困難ではないが、実際には最大の要因である。

• 組み込みエンジニアは、暗号やセキュリティの専門教育を受けていないことが多い
• 「動くこと」の締め切りに追われ、セキュリティは後回しになる
• サンプルコードをそのまま使う（サンプルの鍵がそのまま量産品に入る）
• 「うちの製品を狙う人はいない」という思い込み

典型的な事故.

• ベンダのサンプルにあるテスト用の秘密鍵をそのまま製品に入れた
• 全台同じ鍵を使った（1 台解析されると全台が破られる）
• TLS の証明書検証を無効化したまま出荷した（つながらなかったので切った）
• デバッグポートを開けたまま出荷した
• UART コンソールに root シェルが出ていた

どれも「知らなかった」で起きる。23 章のチェックリストは、これを防ぐためにある。

困難 5: サプライチェーンが長い

鍵を誰が握るかという問題が、ここで発生する。

• 製造を EMS（電子機器の製造受託会社）に委託すると、EMS が署名鍵を持つことになりかねない
• 過剰生産（オーバービルド）——委託先が契約数以上作って横流しする
• 偽造品——正規の型番を名乗る非正規品
• サードパーティのコード——RTOS・TCP/IP スタック・BLE スタックの脆弱性を引き継ぐ

これへの技術的な答えが 12 章の「プロビジョニング」である.

「工場に平文の鍵を渡さずに、機器ごとに固有の鍵を入れる」ための仕組みが、 各社から提供されている（ST の SFI、NXP の secure provisioning、 Microchip の Trust&GO など）。18 章〜22 章で具体的に見る。

4. 何を守るのか — 保護資産の 4 分類

「セキュリティ」と一括りにせず、何を守るのかを分けて考える。

この 4 つは、必要な対策が違う。

「知的財産の保護」と「セキュリティ」を混同しないこと.

コードのコピー防止（IP protection）と、ユーザを守るセキュリティは別の目的である。 両方とも同じハードウェア機能（フラッシュ読み出し保護など）を使うので混ざりやすいが、 脅威モデルが違う。前者の敵は競合他社、後者の敵は攻撃者である。

そして——規制が要求するのは後者だけである。

5. 事故の実例から学ぶ

具体的な事例は、抽象論より遥かに説得力がある。代表的なものを挙げる。

共通しているのは「基本の欠落」である.

高度な暗号技術が破られた例より、 「パスワードが初期値だった」「デバッグポートが開いていた」「全台同じ鍵だった」 という基本の欠落による事故のほうが、圧倒的に多い。

だから 23 章のチェックリストが実務では最も価値がある。 高度な対策より先に、基本の穴を全部塞ぐこと。

6. 「セキュリティは後付けできない」

これは決まり文句だが、組み込みでは文字どおりの意味を持つ。

上 4 つは、基板を起こす前に決めなければならない.

つまりセキュリティ設計は、SoC 選定と同じタイミングで始める必要がある。 「ソフトウェアが完成したらセキュリティを追加しよう」では、 ハードウェアが要求を満たさないという結論になる。

23 章の選定指針は、まさにこの局面のためのものである。

7. この章のまとめ

次章では、「何から守るか」を体系的に決める方法—— 脅威モデリングを扱う。