IoT組み込みデバイスにおける最適なセキュリティアーキテクチャを考える
Hi, there.
本日は、システムのセキュリティを高めるうえでの核となるセキュリティアーキテクチャについて考えます。
IoT組み込みデバイスのセキュリティ設計は、単に「TLS を使う」「暗号化する」「セキュアブートを有効化する」といった個別対策の寄せ集めでは成立しません。本当に問われるのは、どこを信頼の起点にするのか、どの層で何を防ぐのか、侵害されたときにどう検知し、どう回復するのかを、製造から廃棄まで一貫したアーキテクチャとして整理できているかです。NISTIR 8259A は IoT デバイスに求められる能力として、識別、構成、データ保護、論理アクセス制御、ソフトウェア更新、サイバーセキュリティ状態の可視化を整理しています。ETSI EN 303 645 も、既定パスワードの排除、脆弱性開示、更新、機微データ保護などを基礎要件として示しています。
本稿では、IoT組み込みデバイスにおける「最適なセキュリティアーキテクチャ」を、実装可能性を意識しながら整理します。対象は、MCU/RTOS 系の軽量機器から Linux 系のエッジ機器までを含みますが、共通の設計原則としては、信頼の起点、実行分離、強いデバイスアイデンティティ、安全な更新、回復可能性、供給網管理の6本柱で捉えるのがもっとも破綻しにくいと考えます。
なぜ IoT のセキュリティ設計は難しいのか
IoT 組み込みデバイスでは、サーバや PC と違って、次の制約が常に存在します。
CPU、RAM、ストレージが小さい
電源断、通信断、フラッシュ劣化が前提
長期運用が必要
出荷後の脆弱性修正が避けられない
製造工程と運用工程が分断しやすい
現地保守や RMA が発生する
つまり、IoT の最適解は「最も強い暗号を入れること」ではなく、限られたリソースの中で、壊れにくく、侵害されても復旧できる構造を作ることです。CISA の Secure by Design も、顧客任せの防御ではなく、製品側が安全な既定値と安全な設計を提供すべきだとしています。
最適なセキュリティアーキテクチャの全体像
最初に全体像を示します。
この6層は、順番にも意味があります。最下層に信頼の起点を置き、その上で起動を保証し、その上で実行分離し、その上に通信と認可を築き、その上に更新と回復、最後に運用と供給網管理を載せるという構図です。IoT デバイスの中核能力という観点では、NISTIR 8259A が示す能力群と整合的です。
第1層: Hardware Root of Trust を設計の起点にする
IoT デバイスのセキュリティで最初に決めるべきは、秘密情報をどこに置くかです。秘密鍵を平文でフラッシュに置き、アプリケーションから読める設計にしてしまうと、その後にいくら TLS や署名検証を重ねても、根本が弱いままです。
推奨は次のいずれかです。
SoC 内蔵の HUK（Hardware Unique Key）
Secure Element
TPM
PUF ベースの鍵導出
ベンダ提供の secure storage / key ladder
設計上のポイントは、「鍵を保存する」ではなく、鍵を露出させずに利用することです。たとえばデバイス証明書の秘密鍵であっても、アプリケーションが生の秘密鍵を読み出せる形は避けるべきです。NISTIR 8259A の「Device Identification」「Logical Access to Interfaces」「Data Protection」といった能力群は、この層の設計に直結します。
第2層: セキュアブートは「検証」だけでなく「回復」まで必要
セキュアブートは、単にブートローダを署名検証する機能ではありません。本質は、このデバイスが、誰の、どのコードを信じて起動するかを連鎖で固定することにあります。
NIST SP 800-193 は、プラットフォームファームウェアのレジリエンスとして、Protect / Detect / Recover の3点を求めています。つまり、「改ざんされないようにする」だけでは不十分で、改ざんを検知し、正常状態へ回復できることまで含めて設計しなければなりません。
そのため、実装では次を推奨します。
ROM trust anchor を起点にする
ブートチェーン全体を署名検証する
重要設定ファイルも完全性確認対象にする
検証失敗時は recovery image へ遷移する
JTAG / SWD / UART コンソールは量産時に封止または強認証化する
第3層: 実行環境を分離する
組み込み機器でありがちなのが、全部入りの高権限ファームウェアです。しかし現実の IoT デバイスには、鍵処理、通信、制御、更新、UI、診断、ログなど多くの責務があります。これを1つの trust domain に詰め込むと、ひとつの脆弱性で全体が侵害されやすくなります。
Linux 系であれば、以下のような機能を組み合わせます。
capability 分離
seccomp
namespace
read-only mount
SELinux / AppArmor
systemd sandbox
MCU / RTOS 系なら、以下が中心です。
TrustZone-M
MPU によるタスク分離
privileged / unprivileged モード分離
secure service call の限定化
この考え方は、ネットワーク境界ではなく個々の資産単位で守るという NIST SP 800-207 のゼロトラスト思想とも整合します。デバイス内部でも「同じ筐体内だから信頼する」のではなく、内部の各機能も必要最小限でしか信用しないのが重要です。
第4層: 通信設計の中心は「暗号化」より「アイデンティティ」
IoT セキュリティの議論では「TLS を入れたので安全です」と言われがちですが、実際にはそれでは不十分です。重要なのは、誰が誰かをどう証明し、どの操作を誰に許可するかです。
推奨事項は次の通りです。
デバイス固有証明書を持たせる
必要に応じて相互認証（mTLS）を採用する
認可は IP やネットワーク位置ではなく ID と属性で行う
管理プレーンとデータプレーンを分離する
初期設定用のペアリング経路は短命かつ限定権限にする
この設計は、NISTIR 8259A の「Device Identification」「Logical Access to Interfaces」に対応し、かつ NIST SP 800-207 の「境界ではなく資産中心」の原則にも沿います。
第5層: OTA は“機能”ではなく“継続的安全性の土台”
出荷後の脆弱性修正が不可能な IoT デバイスは、長期的には安全ではありません。その意味で OTA はオプションではなく、セキュリティアーキテクチャの中心機能です。NISTIR 8259A はソフトウェア更新能力をコア能力に含めており、ETSI EN 303 645 も更新機能を重要項目として扱っています。
実装で押さえるべきポイントは以下です。
更新パッケージは署名検証する
通信経路の TLS だけに依存しない
A/B パーティションを使う
Boot 成功後の health check を設ける
anti-rollback を実装する
更新結果を監査可能にする
NIST SP 800-193 が「回復」を要求していることを考えると、OTA は単なる配信機能ではなく、障害や攻撃から戻れる仕組みまで含めて設計すべきです。
第6層: 運用・供給網まで入れて初めてアーキテクチャになる
ここは見落とされがちですが、量産 IoT では非常に重要です。いくらデバイス内部の設計がよくても、以下が欠けると運用段階で破綻します。
証明書失効・再発行
脆弱性情報の追跡
SBOM 管理
出荷済みデバイスの資産台帳
設定変更履歴
脆弱性報告窓口
RMA / 再プロビジョニング手順
NIST は SBOM を「ソフトウェアを構成する各種コンポーネントと供給網関係の正式な記録」と整理しており、脆弱性の影響評価やサプライチェーン可視化に有効としています。また NISTIR 8259B は、技術機能だけでなく、文書、情報提供、サポートなどの非技術的能力も重要だとしています。
よくあるアンチパターンと対策
IoT組み込みデバイスのセキュリティ設計では、強い暗号やセキュアブートを入れていても、設計全体のバランスが悪いと簡単に弱点になります。ここでは、現場で特に起こりやすいアンチパターンを絞って整理します。
共通パスワードや埋め込み認証情報を使う
全デバイスで同じパスワードを使ったり、認証情報をファームウェアやコードに埋め込んだりする設計は、典型的な失敗です。一台から情報が抜かれるだけで、同一系列の全機器へ影響が広がります。
対策：
デバイスごとに固有の認証情報を持たせ、可能であればパスワード依存を減らして証明書ベース認証へ寄せるべきです。ETSI EN 303 645 は universal default password を避けることを求めており、CWE-798 も hard-coded credentials を典型的な脆弱性として挙げています。
通信の暗号化だけで安心する
TLS を使っていても、それだけで安全とは言えません。サーバ認証だけでデバイス側の本人性が弱いと、不正デバイスの混入やなりすましを防ぎにくくなります。
対策：デバイス固有証明書や mTLS を採用し、IP アドレスやネットワーク位置ではなく、ID と属性に基づいて認可する構成が望まれます。NISTIR 8259A は識別と論理アクセス制御を中核能力として示しており、NIST SP 800-207 も境界依存ではなく資産中心の制御を勧めています。
OTA を更新機能としてしか見ていない
更新機能があっても、署名検証や rollback 制御がなければ、安全な更新とは言えません。単純な上書き更新は、改ざんや更新失敗に弱く、最悪の場合は機器が起動不能になります。
対策：更新パッケージの署名検証、A/B パーティション、自動ロールバック、anti-rollback を含めて設計するべきです。NIST SP 800-193 は保護だけでなく検知と回復も必要としています。
デバッグ経路を量産機に残す
JTAG、SWD、UART コンソールなどのデバッグ経路を量産後も開いたままにしておくと、セキュアブートやアクセス制御を迂回される入口になります。
対策：量産時には debug port を封止し、どうしても必要なら認証付きで限定的に解放する設計が必要です。こうした経路の放置は、ファームウェア保護と回復を重視する NIST SP 800-193 の考え方にも反します。
すべてを高権限で動かす
鍵処理、通信、OTA、UI、ログ収集が同じ権限で動く設計では、一つの脆弱性が全体侵害に直結します。
対策：鍵操作、更新、通常アプリケーションを分離し、最小権限で動かすべきです。Linux なら seccomp や LSM、RTOS/MCU なら MPU や TrustZone の活用が有効です。これはゼロトラストや Secure by Design の考え方とも一致します。
SBOM や脆弱性追跡の仕組みがない
依存ライブラリや OSS の構成を把握していないと、脆弱性が見つかったときに自社製品への影響をすぐ判断できません。
対策：SBOM を build 時に自動生成し、機種・版数・出荷台帳と結び付けて管理するべきです。NIST は SBOM を供給網可視化の基盤として位置付けています。
脆弱性開示や更新方針がない
報告窓口やサポート方針が曖昧だと、脆弱性が見つかっても是正までの流れが止まります。
対策：脆弱性報告窓口、サポート期間、更新方針、EOL 方針をあらかじめ公開しておくことが重要です。ETSI EN 303 645 や NISTIR 8259B の考え方とも整合します。
実務向けの推奨構成例
ここまでを踏まえ、実際の推奨構成をまとめると次のようになります。
望ましい設計指針
ルート鍵はハードウェアに置く
起動チェーン全体を検証する
実行権限を分離する
デバイスを固有 ID で認証する
OTA と Recovery を一体設計する
SBOM と脆弱性対応を運用に組み込む
この構成は、NISTIR 8259A/8259B、NIST SP 800-193、ETSI EN 303 645、CISA Secure by Design の考え方と矛盾しません。
まとめ
IoT組み込みデバイスの最適なセキュリティアーキテクチャとは、個別対策の足し算ではありません。重要なのは、信頼の起点をどこに置き、何をどう検証し、侵害時にどこまで被害を閉じ込め、どう回復し、出荷後もどう守り続けるかを、一つの構造として設計することです。
特に実務で外してはいけないポイントは次の6つです。
Hardware Root of Trust
Verified / Secure Boot
実行環境分離
強いデバイスアイデンティティ
安全な OTA と Recovery
SBOM を含む運用・供給網管理
IoT の現場では「制約が厳しいから、そこまではできない」と言われがちですが、むしろ逆です。制約が厳しいからこそ、機能追加ではなくアーキテクチャで勝つ必要があるのです。NIST、ETSI、CISA などの文書も、その方向性を一貫して支持しています。
参考リンク集
NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline (https://csrc.nist.gov/pubs/ir/8259/a/final)
NISTIR 8259B: IoT Non-Technical Supporting Capability Core Baseline (https://csrc.nist.gov/pubs/ir/8259/b/final)
NIST SP 800-193: Platform Firmware Resiliency Guidelines (https://csrc.nist.gov/pubs/sp/800/193/final)
NIST SP 800-207: Zero Trust Architecture (https://csrc.nist.gov/pubs/sp/800/207/final)
ETSI EN 303 645: Cyber Security for Consumer IoT (https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf)
CISA: Secure by Design (https://www.cisa.gov/securebydesign)
NIST: Software Bill of Materials (SBOM) (https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1)
MITRE CWE-798: Use of Hard-coded Credentials (https://cwe.mitre.org/data/definitions/798.html)
OWASP: Use of hard-coded password (https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password)
OWASP IoT Security Testing Guide (https://owasp.org/owasp-istg/02_framework/methodology.html)
