近年、組み込みデバイスの増加に伴い、ハッキングによる脅威も増加の一途を辿っています。
サイバー攻撃による被害はそのデバイスの使用者はもちろんですが、信用の失墜や損害賠償といった開発元の企業が被る損害も計り知れません。
そのようなリスクを最小限に抑えるために、開発する段階でセキュリティを意識することは重要と言えます。
組み込みデバイスへの攻撃は様々な方向から行われます。
例えば以下のような攻撃方法が考えられます。
-
データを抜き取るために eMMC をボードから引き剥がすなどの物理的な攻撃
-
DDoS 攻撃などのネットワークを介した攻撃、またはボットネットとして使用される
-
電磁波を使用して故障やデータ改ざんを引き起こす攻撃
-
Linux カーネルやアプリケーションの脆弱性をついた攻撃
上記は一例であり、他にも様々な攻撃方法があります。
ある方向のセキュリティ対策が強固な場合、攻撃者は回避可能な別の方向がないのか模索します。
特に、IoT デバイスはネットワーク上のサービスとデータのやり取りを行います。
通信路やパケットの暗号化、サーバーとデバイスの相互認証などの対策を講じたとしても、
IoT デバイス上にあるソフトウェアに攻撃者のコードを組み込むことで対策を回避してシステムに侵入される可能性があるのです。
そのため、ある一点に対して強固なセキュリティ対策を施すよりも、システム全体で防御策を講じる多層防御の考え方が重要になります。
とはいえ、全ての攻撃に対して対策を考えるのはコスト面を考えたとしても現実的ではありません。
デバイス上にどのような資産が保有されているのか、攻撃方法として何がありえるのか、もし攻撃された場合に影響範囲はどの程度なのかといった
リスクアセスメントを行った上で、セキュリティ対策を施すことにより大きな費用対効果が得られます。
何らかの手段でデバイスにエクスプロイトコードがインストールされることで Linux カーネルを含むソフトウェアが改ざんされることが考えられます。
セキュアブートは、起動ソフトウェアのデジタル署名を用いて正規ソフトウェアであることを確認してから起動する機能のことです。
攻撃者によって作られた不正なコードを実行前に検出することができます。
デバイスにあらかじめ書き込まれた書き換え不可のハッシュ値を起点に、署名されたブートローダーおよび OS が正規のものであるか検証しながら順番に起動します。
万が一、署名されたソフトウェアが改ざんされていた場合には起動に失敗します。
このプロセスがあることで、セキュアブートは電源投入から署名されたソフトウェアの起動までの起動プロセスを保護します。
ただし、起動後に署名されたソフトウェアが改ざんされた場合にはセキュアブートでは対処できません。
そのため、セキュアブートを有効にしたとしても、パスワードを強固なものにする、JTAG を無効化し侵入口を塞ぐ、アプリケーションをセキュアな設計にするなどの対策は必須です。
セキュアブートはチェーンオブトラスト (chain of trust) と表裏一体に実装されます。
チェーンオブトラストとは、その名の通り、信頼を繋いでいく形態のことを指します。
ルートオブトラストと呼ばれる基礎となる情報から枝葉のように繋がれた情報を認証していくことで、繋がれた個々のコンポーネントだけでなくシステムを信頼できるものにしてくれます。
セキュアブートは、起動時にソフトウェアを順番に認証することで信頼を次に繋いでいるのです。
セキュアブートによる保護範囲をどこまでにするかによりますが、起動時に認証されたソフトウェアで別の情報を認証すれば、チェーンオブトラストを繋げていくことができます。
また、IoT デバイスとクラウドサービスから構成されるような広範囲に及ぶシステムは特に信頼が必要になります。
信頼できるセキュリティ基盤を構築するためには、構成するソフトウェアが正規のリリース物であることを確認することが重要になります。
チェーンオブトラストを採用することでより信頼できる IoT システムとなり得るのです。
では、どういったケースでセキュアブートを採用するべきでしょうか。
セキュアブートはセキュアな組み込みデバイスを実現する上で最初のステップにするべき技術です。
しかし、導入するのであればコスト面にも配慮することが必要でしょう。
まず、製造時の追加コストが必要です。
鍵等を書き込む工程が必要になります。
ただ書き込めばよいわけではなく、漏洩があってはいけないので物理的な隔離などセキュアに書き込む必要があります。
メンテナンスにも追加のコストが必要です。
ソフトウェアのリリース時にはソフトウェアの署名が必要になります。
署名鍵については物理的な隔離などの漏洩対策が必要になります。
費用対効果を検討してからの導入をお勧めします。
HAB (High Assurance Booting) は、NXP が提供するセキュアブートの実装です。
i.MX 8M Plus の BootROM には HABv4 が組み込まれます。デフォルトでは無効な状態になっていますが、一度、eFuse に情報を書き込むことでセキュアブートが有効になり、それ以降、有効な状態のまま変更不可能になります。
HABv4 で規定する仕様では次の情報をブートローダーイメージに追加することで BootROM が起動時にブートローダーの認証を行います。
-
CSF (Command Sequence File)、IVT (Image Vector Table)
-
SRK (Super Root Key)、CSF、IMG 署名確認鍵
-
イメージの署名
NXP は署名ツールとして CST (Code Signing Tool) をリリースしています。
本来、署名範囲などは環境によって様々な実装がなされるべきなので署名ツール自体にはその辺りの仕様が含まれません。
ブートローダーの実装仕様に依存します。
Armadillo Base OS で採用される uboot-imx のセキュアブート処理では、Trusted Firmware-A (ATF)、OP-TEE OS、Linux カーネルイメージまでが認証の対象になります。
署名に関する概要は以下のとおりです。
-
署名確認用の鍵は X.509 証明書に対応する
署名は RSA/ECC に対応する
-
RSA 1024, 2048, 3072, 4096 bits
-
ECC NIST P-256, NIST P-384, NIST P-521
-
署名のダイジェストは SHA256 のみ
![[注記]](images/note.png) | |
---|
HAB の詳しい仕様は以下を参照してください。 以降でダウンロードする imx-boot ディレクトリ内のドキュメントもご参照ください。 |
2.5. セキュアブートの有効化及びストレージの暗号化で保証される範囲
Armadillo-X2 および Armadillo-IoT ゲートウェイ G4 ではセキュアブートによる保護はブートローダーと Linux カーネルイメージに対して行われ、ユーザーランドで使用するソフトウェアに対しては機能しません。
代わりに、ストレージを暗号化して、Armadillo 起動時に復号することでユーザーランドが正規の Armadillo によって起動されたことを保証します。
表2.1 セキュアブートの有効化及び暗号化で保証される範囲
ソフトウェア | セキュアブートの有効化 | ストレージの暗号化 |
---|
ブートローダー | ○ | × |
Linux カーネルイメージ | ○ | × |
ユーザーランドのソフトウェア | × | ○ |
セキュアブートの有効化及びストレージの暗号化は起動時に正規のものであることを保証するための機能であり、起動後にファイルが改ざんされるなどの状況には対処できません。
起動後のセキュリティ対策は別の方法で行う必要があります。
Armadillo-IoT ゲートウェイ G4/Armadillo-X2 と Armadillo Base OS を利用することで、
以下のようなセキュリティ機能を実現することができます。
表2.2 セキュリティとして期待される効果
機能 | 期待される効果 |
---|
セキュアブートの有効化 | ブートローダーと Linux Kernel の改竄を検出することができます。また、
署名とその検証によって、正規ソフトウェアのみの起動を強制させることができます。 |
ストレージの暗号化 | ファイルがフラッシュメモリに保存されている間は暗号化によって
ファイルは保護されます。
eMMC を外して他の個体に付け替えても復号できないので、保存されているアプリケーションやデータなどを外部から読み取るまたは改竄することはできません。
そのため、ファイルに情報資産が含まれるケースでの活用も考えられます。 |
以降の作業を行うことで、セキュアブートを有効化し、ストレージを暗号化することが出来ます。
![[重要項目]](images/important.png) | |
---|
ブートローダーの暗号化に関しては対応しておりません。 |