組み込みセキュリティ設計の実践
組み込み機器の安全性は、事後の対策だけでは十分に確保できません。設計の段階からセキュリティを織り込む考え方が重要です。
この記事では、脅威分析で守る対象を洗い出し、多層防御で固めるまでの筋道を追います。ハードウェアとソフトウェア、出荷後の運用まで、必要な項目を紹介します。読み終えるころには、何をどう守るかの全体像がつかめるでしょう。
組み込み機器が抱える固有のセキュリティ課題
2016年、Miraiに感染したIoT機器が大規模DDoS攻撃（例：大手DNS事業者への攻撃）の踏み台になりました。2015年にはある自動車メーカ車両の制御システムが遠隔操作で乗っ取られる脆弱性が判明し、大規模なリコールに発展した事例もあります（例：車両遠隔ハックの実証と、それにともなう大規模なソフト更新／リコール）。どちらもサイバー空間だけで完結せず、交通・通信など現実世界へ影響を及ぼしました。
組み込み機器では、ネットワーク経由の攻撃だけでなく、攻撃者が機器に直接触れて内部にアクセスする可能性も考慮する必要があります。また産業機器や車載機器では、同じハードウェアを10年以上使い続けるケースもよくあります。
ここでは「触れられること」と「長く使われること」の2点に分けて、セキュリティ課題を確認していきましょう。
物理アクセスを前提とした脅威モデル
セキュリティを考える際には、攻撃者が組み込み機器に直接アクセスする可能性を考慮する必要があります。JTAGやUARTなどのデバッグ・保守用インタフェースが有効なままだと、設定次第ではファームウェアや機密情報の取得、任意コード実行につながるおそれがあります。「出荷前に消したはず」のデバッグ機能が残っていた例も、実際に報告されています。
リソース制約と長期運用がもたらすセキュリティリスク
もう1つの壁は、限られた計算資源です。性能が高くないCPUや少ないメモリを用いる場合、公開鍵暗号のような重い処理を気軽に回せないことがあります。一般に公開鍵暗号は共通鍵暗号より計算コストが大きく、応答の遅延や電力増加につながるおそれがあるため、組み込みシステムでは軽量な暗号が選ばれてきました。
組み込み機器は、時間の経過やコンピュータの性能向上によるセキュリティリスクの増大にも注意が必要です。出荷時に安全だった鍵やアルゴリズムも、いずれは解読されやすくなるおそれがあるためです。実際、RSAの1024ビット鍵は推奨されず、一般に2048ビット以上が推奨されます（用途・規格に依存）。
脅威分析（脅威モデリング）で守る対象を定義する
どのような対策も、「何を守るのか」が決まっていなければ空振りに終わります。そのため脅威分析では、守る資産を洗い出し、そこへ届く攻撃に結び付けるのが大切です。勘に頼ると、必ず穴が残ってしまうでしょう。
鍵になるのは、「守る資産」と「攻撃の入り口」の2つです。
資産・攻撃面・攻撃者能力を洗い出す
まず、守るべき資産をリストアップします。機器そのものや保存されたデータ、通信でやり取りするデータなど、失っては困るものをあげます。次に、攻撃の経路となりうる端子やネットワークを洗い出しましょう。通信ポートやデバッグ端子はその一例です。近年ではWi-FiやBluetoothなどの無線通信を経由した攻撃もあることに注意が必要です。
脅威分析の際には、攻撃者の属性や能力も考慮する必要があります。基板を解析できる相手と、通信をのぞける相手では、対策を取るべき項目や内容が変わるためです。
STRIDE（分類手法）やEMB3D（脅威モデル）を使った体系的な脅威列挙
では、どうすれば脅威を漏れなくあげられるのでしょうか。STRIDEの活用は、その1つです。脅威を「なりすまし」「改ざん」など、6つの項目に分類する手法です。ただしSTRIDEはIT向けに考案された手法のため、組み込み固有の項目を見落とすおそれがあります。組み込み向けのMITRE EMB3Dも有効です。システムを構成するハードウェアやソフトウェア、機能の脅威を可視化できる特徴があります。
セキュリティ・バイ・デザインの設計原則
脆弱性は、見つかってから直すほど修正コストが増大します。設計のやり直しになれば、発売も遅れるでしょう。そのため、上流工程の企画・設計段階からセキュリティを考慮する必要があります。この考え方がセキュリティ・バイ・デザインです。どのような原則なのか、1つずつ見ていきましょう。
最小権限・攻撃面の縮小・多層防御
組み込み機器を守る基本は、余分な機能や権限を提供しないことです。使わないポートや残ったデバッグ機能は、悪意ある者による侵入のきっかけとなりえます。これらは無効化しましょう。ユーザには、必要最小限の権限を付与することも欠かせません。一方で単一のセキュリティ対策には限界があるため、複数の対策を組み合わせる必要があります。もし対策の1つが破られても、別の対策でセキュリティを守れます。多層防御は、この考え方に基づくセキュリティ手法です。
ライフサイクル全体で守る（設計〜廃棄）
組み込み機器における製造者の責任は、設計から廃棄までのライフサイクル全般におよびます。特に大切なのは、鍵と証明書の管理でしょう。設計では、暗号鍵の作成や保管方法を決めます。運用中は、証明書の更新も重要です。更新を怠れば通信が止まるなど、機器の運用に支障をきたすおそれがあるためです。また必要のない証明書は速やかに失効させ、暗号鍵は適切な方法で廃棄しましょう。あわせて、OTAアップデートによる継続的な脆弱性の修正も必要です。廃棄する際は、暗号鍵や証明書を含めたデータを確実に消去することが重要です。
実装レイヤ別の具体的対策
ここまでは、設計の考え方を見てきました。では、開発者は何を実装すればいいのでしょうか。対策は、大きくハードウェアとソフトウェアの2層に分かれます。ハードウェアは、デバイスの信頼の基点を提供し、鍵を保護します。ソフトウェアは、セキュアブートや安全な更新・通信を担います。
ここからは、その具体策を層ごとに確認しましょう。
ハードウェア：Root of Trust・Secure Element・Tamper Resistance
ハードウェアのセキュリティは、「信頼の基点（RoT、Root of Trust）」の概念を用います。デバイスの安全性を支える機能であり、ハードウェアを用いた実装が望ましいとされています。Secure ElementはRoTを構成する要素の1つで、セキュリティ機能を持つIC（集積回路）を指します。ただし、実装手段はこれだけではありません。SoCに内蔵されたセキュア領域やTPM（Trusted Platform Module）なども使われます。
チップには耐タンパ性（タンパ耐性、Tamper Resistance）が備わっており、暗号鍵や認証鍵などが保管されます。耐タンパ性とは、物理的な分解や解析による不正なデータの読み出し・改ざんを困難にする特性です。攻撃を検知した際に暗号鍵を自動消去するなどの応答機能を持つ実装も含まれます。これらの取り組みにより、物理的な攻撃から組み込み機器を守ります。
ソフトウェア：Secure Boot・Secure Update・TLS
ソフトウェアの守りは、起動・更新・通信の3つの経路に分かれます。起動する際には、署名を検証しソフトウェアの信頼性を確認する「Secure Boot」が実行されます。
ソフトウェアを安全に更新する「セキュアアップデート（Secure Update）」では、更新ファイルの提供元が信頼できること、更新情報が改ざんされていないことを検証してから受け入れます。この検証には、検証鍵を使用します。
通信はTLSで暗号化し、のぞき見やなりすまし、データの改ざんを防ぎます。いずれも、組み込み機器を守るために必要な仕組みです。
出荷後の運用で堅牢性を維持する
出荷は、ゴールではありません。攻撃者の技術は進み、昨日まで安全だった機器にも、ある日穴が見つかります。そのため開発者は、運用中でも守りを続けなければなりません。
堅牢性を維持するための具体策を、詳しく見ていきましょう。
脆弱性情報の追跡とセキュア更新の運用
開発に用いたOSS（オープンソースソフトウェア）やライブラリには、後から脆弱性が見つかる場合があります。まずソフトウェアに含まれるOSSやライブラリの部品を、SBOM（ソフトウェア部品表、Software Bill of Materials）を用いて一覧にしましょう。そのうえでCVEやJVN（Japan Vulnerability Notes：脆弱性情報ポータル）などを定期的にチェックして脆弱性を把握し、更新などの対応をします。
脆弱性を修正する際には、更新そのものが新たな攻撃の原因にならないよう留意する必要があります。配信されたファイルの署名をチェックして、正規のファイルであることを確認後に適用するのが基本です。一部の機器へ配布し、問題があれば戻せる体制をつくることも有効です。
デバッグ端子無効化と鍵・証明書のライフサイクル管理
開発で使うデバッグ端子は、攻撃者による侵入を受けやすい場所です。そのため、JTAGやUARTが有効な状態のまま出荷することはお勧めできません。量産時には、これらの端子を無効化するなどの対策を取る必要があります。
暗号鍵や証明書は、作成から廃棄までの管理が必須です。暗号鍵は安全な場所で作成し、証明書とひも付けて配布することが求められます。また、証明書には期限があるため、期限切れを迎える前に新しい証明書に入れ替える必要があります。古い証明書は、失効させて使えなくするのが原則です。
