IoTセキュリティの基礎（第3部）：セキュアブートとファームウェアアップデートの安全確保

編集者注：IoTデバイスはその急増にもかかわらず、セキュリティ面の懸念が払拭されておらず、産業用IoT（IIoT）やミッションクリティカルなアプリケーションでは、攻撃された場合に企業や個人のデータが被害を受ける可能性あり、セキュリティの課題がコネクテッドデバイス導入の障壁になる場合もあります。IoTアプリケーションのセキュリティ確保は難しいと考えられがちですが、実際には、IoTデバイスのセキュリティは、ハードウェアセキュリティデバイスによって支えられる、さほど複雑でない基本的な仕組みをいくつか組み合わせれば構築できます。すでに確立されたセキュリティ手法に従うことで、これらの懸念を払拭することができます。5回に分けてお届けするこのシリーズでは、開発者が最初からベストプラクティスを実践するのに役立つ実際的なガイダンスを提供します。第1部では、安全設計の基盤となる暗号アルゴリズムについて説明します。第2部では、セキュアIoT設計における秘密鍵の役割、鍵管理、およびセキュアストレージについて説明します。この第3部では、IoTデバイスへの他のタイプの脅威を低減するために、セキュアプロセッサに組み込まれたメカニズムについて説明します。第4部では、高度なプロセッサでセキュリティメカニズムを適用して、IoTデバイスのランタイム環境に対する攻撃を低減するのに必要な分離を確保する方法を特定して紹介します。第5部では、IoTデバイスから、これらのデバイスをIoTクラウドリソースに接続するために使用されるハイレベルのセキュリティ対策へとIoTセキュリティを移行する方法について説明します。

ハードウェアベースの暗号化とセキュアストレージを組み合わせて利用することで、セキュアなモノのインターネット（IoT）設計の実装に必要不可欠な機能が実現できます。しかし、IoTデバイスはいったん展開されると、そのデバイスを故障させたり、即座に攻撃を始めたりするように設計された脅威や、巧妙で高度な永続的脅威など、さまざまな脅威に直面します。

この記事では、信頼のルートを使用してIoTデバイスのセキュリティを強化する方法について説明します。信頼のルートは、セキュリティメカニズムを基盤として構築され、Maxim Integrated、Microchip Technology、NXP Semiconductors、およびSilicon Labsなどのベンダーから提供されるセキュアプロセッサでソフトウェアを実行するための信頼できる環境を提供します。

信頼のルートとは？ それが必要な理由とは？

暗号化方式とセキュアキーは、あらゆるコネクテッドデバイスのセキュリティを実現するための重要な要素です。このシリーズの第1部、第2部で述べたように、これらはデータおよび通信の保護のために上位プロトコルで使用される基本的なメカニズムを提供します。システム自体を保護するには、組み込みシステムでのシステム動作とソフトウェア実行に影響する脆弱性を考慮する必要があります。

標準的な組み込みシステムでは、停電または重大なソフトウェア例外によりシステムがリセットされると、ソフトウェアのブートプロセスが起動して不揮発性メモリからファームウェアイメージがリロードされます。通常であれば、ソフトウェアの再起動は、偶発的または故意に不安定になったシステム機能を回復させるための重要な安全メカニズムです。コネクテッドシステムではハッカーがさまざまなブラックハットツールを使用してソフトウェアに害を及ぼすおそれがあり、そのような状況ではセキュリティの専門家は、ソフトウェア実行に影響を及ぼす侵入への対策として再起動を推奨することもよくあります。たとえばFBIは2018年に消費者および事業主に対して、当時進行中だった大規模なハッキング活動を阻止するためにルータを再起動するように推奨しました。

実際には、再起動ではシステムの完全性は保証されません。ファームウェアイメージが毀傷した状態で再起動しても、システムはハッカーの制御下にあるままです。このような脅威を低減するには、開発者は自身が開発したソフトウェアが信頼チェーン上で実行することを保証する必要があります。信頼チェーンは、ブート時に確立された信頼のルート上に構築され、ソフトウェア実行環境のすべてのレイヤに及びます。このようなレベルのセキュリティを実現できるか否かは、信頼できるファームウェアでブートプロセスが起動されるかどうかに大きく左右されます。

セキュアブートのためのファームウェアイメージの検証

組み込みシステムでは、ホストプロセッサがファームウェアイメージをフラッシュからメインメモリにロードして実行を開始します（または、XIP（execute-in-place）機能によりフラッシュから直接実行を開始します）。ハッカーによってファームウェアイメージが攻撃された場合、ブートプロセスで立ち上がったシステムは毀傷した状態です。

ファームウェアでブートする前にファームウェアのインテグリティ（整合性）を検証するために、開発者はサプライチェーンの早い段階で始まるコード署名プロセスを使用します。セキュアな設備内では、システムのファームウェアイメージが、楕円曲線デジタル署名アルゴリズム（ECDSA）などの堅牢な暗号によるアルゴリズムで作成された非公開/公開鍵ペアの秘密鍵で署名されます。非公開鍵は設備から外部に出ることはありませんが、システム公開鍵はシステムとともに出荷されます。ブート時に、プロセッサはこのシステム公開鍵を適用して、イメージを使用する前にファームウェアの署名を検証します。

もちろん、上述のプロセスだけでは公開鍵そのものは脆弱なままで、ひいてはシステムファームウェアは不正な置き換えに脆弱な状態です。組み込みシステムで公開鍵が保護されていない状態であれば、ハッカーはその公開鍵を、ハッカー自ら生成した非公開/公開鍵ペアの公開鍵に置き換えるおそれがあります。もしハッカーがシステムのファームウェアイメージを、ハッカー所有の関連付けられた非公開鍵によって署名された悪意のあるファームウェアで置き換えると、攻撃されたファームウェア署名が検証プロセスをパスして、ブートプロセスが続行され、ハッカーに侵入された状態のシステムが立ち上がります。

このためセキュアシステムは、セキュリティ設備内のセキュアエレメントでプロビジョニングされた有効な公開鍵に依存します。Maxim IntegratedのDS28C36やMicrochip TechnologyのATECC608AなどのセキュリティICでは、従来のセキュアエレメントのセキュアストレージと、ファームウェア署名検証用の認証アルゴリズム（ECDSAなど）のセキュアな実行の両方が可能です。

ブートの前に、ホストプロセッサはシリアルインターフェース経由でDS28C36などにファームウェアを送信できます。さらに、DS28C36は前の段階でセキュアな設備でプロビジョニングされたシステム公開鍵を使用して、ファームウェア署名が同じセキュアな設備内で関連する非公開鍵によって作成されたものかどうかを確認します。そして、DS28C36は検証結果をホストプロセッサに通知し、署名が有効であればホストプロセッサはファームウェアイメージのロードに進みます（図1）。

図1：開発者により可能なMaxim Integrated DS28C36などのセキュリティICを使用したファームウェア署名の検証による、毀傷したファームウェアからのホストプロセッサ起動の阻止（画像提供：Maxim Integrated）

セキュリティを高めたブートプロセスによってファームウェアイメージが保護され、鍵やイメージが被害を受ける懸念を払拭できます。セキュアストレージと暗号アクセラレータの使用による効果的なセキュアブート機能が、Silicon LaboratoriesのGecko Series 2プロセッサ、NXPのLPC55S69JBD100、Maxim IntegratedのMAX32520、Microchip TechnologyのATSAML11D16Aなどの幅広いプロセッサに組み込まれています。これらの機能を使用することで、このクラスのセキュアプロセッサは、信頼できる環境でシステムおよびアプリケーションソフトウェアを実行するために必要な信頼のルートを実現できます。

セキュアブートによる信頼のルートの実現

このクラスのセキュアプロセッサが提供するセキュアブートオプションは、信頼のルートの基盤となるファームウェアイメージの完全性を保証するように設計されています。たとえば、Silicon LaboratoriesのEFR32MG21AおよびEFR32BG22 Gecko Series 2プロセッサは、それぞれハードウェアセキュアエレメントと仮想セキュアエレメント（VSE）に基づく多段階ブートプロセスによって、この信頼のルートを構築しています（図2）。

図2：Silicon LaboratoriesのGecko Series 2 EFR32MG21Aプロセッサが多段階ブートプロセスの第1段階で使用する統合ハードウェアセキュアエレメント（上図）。EFR32BG22が多段階ブートプロセスを開始するのは仮想セキュアエレメント（画像提供：Silicon Laboratories）

EFR32MG21Aでは、専用のプロセッサコアが暗号化機能をセキュアキーストレージ用のハードウェアセキュアエレメントとともに提供します。EFR32MG21Aプロセッサはこの専用機能にサポートされ、ブートプロセスを開始すると読み取り専用メモリ（ROM）に格納されたコードを使用して第1段階のブートローダー（FSB）コードを検証します。検証を終えた時点でFSBコードが実行され、第2段階ブートローダー（SSB）のコード署名を検証します。続けてこのブートシーケンスで検証済みのSSBが実行され、アプリケーションコードの署名を検証します。一般的にこれにはシステムレベルのコードと上位のアプリケーションコードの両方が含まれます。そして、検証されたアプリケーションコードが実行され、アプリケーションの要求に応じて引き続きシステムの操作が行われます。

このプロセスはROMコードから始まり、検証済みのFSB、SSB、およびアプリケーションコードのみを実行するため、コードを実行するための信頼チェーンがこのアプローチによって検証されたことになります。この信頼チェーンでは最初のリンクがROMコード（変更不可）に依存するため、連鎖における後続の各リンクによって信頼される環境が拡張されていきます。同時にこのアプローチによって、開発者はアプリケーションコード、さらには第1段階および第2段階ブートローダーコードも安全に更新できます。各コードパッケージが検証済みの署名を提供する限り、信頼された環境はそのまま維持されます。

このようなセキュアブートを信頼のルートによって可能にするプロセッサは、一般に複数のモードとオプションをサポートしています。たとえば、Silicon LaboratoriesのGecko Series 2プロセッサには、より強力な証明書ベースのセキュアブート機能があります。

通常の公開鍵基盤（PKI）トランザクションで使用される証明書には、公開鍵とともに、関連する1つ以上の証明書に対する参照が含まれており、これらの証明書は最終的に認証局（CA）から付与されたルート証明書を指します。この連鎖におけるそれぞれの証明書は、その下位の証明書を検証する役割を果たし、信頼できるCAに基づく信頼チェーンが形成されます。ブラウザは、トランスポート層セキュリティ（TLS）の認証段階で、この信頼チェーンに基づいてウェブサーバーのIDを確認します。同様に、組み込みシステムは証明書を使用して、ブートローダーまたはアプリケーションコードのソースIDを確認できます。この場合、多段階ブートプロセスは前述のように続行しますが、各段階に関連付けられた証明書が追加で検証されます（図3）。

図3：Silicon LaboratoriesのGecko Series 2プロセッサは、ブートプロセスの各段階での署名検証で使用される公開鍵を証明書で検証することにより、システムのセキュリティを強化（画像提供：Silicon Laboratories）

NXP LPC55S69JBD100などの他のプロセッサでは、ファームウェアイメージに関する各種オプションを多数サポートしています。これらのプロセッサは、署名済みファームウェアイメージの他に、業界標準のTrusted Computing GroupのDevice Identifier Composition Engine（DICE）を使用するブートイメージをサポートしています。第3のオプションでは、開発者は、PRINCE暗号をサポートするプロセッサフラッシュの特別な領域にイメージを保存できます。PRINCE暗号は低レイテンシのブロック暗号で、他の暗号に匹敵するセキュリティ強度をはるかにに小さいシリコン領域で実現できます。LPC55S69JBD100に実装されているPRINCE暗号は、暗号化されたコードまたはプロセッサのフラッシュ専用PRINCE領域に保存されているデータをオンザフライで復号化できます。復号化に使用される秘密鍵にはPRINCE暗号化エンジンのみがアクセス可能なため、この復号化プロセスのセキュリティは維持されたままです。実際には、これらの秘密鍵は、LPC55S69JBD100のPUF（physical unclonable function）機能で生成された鍵暗号キー（KEK）によって保護されています（PUFとKEKの使用について詳しくは第2部を参照）。

このアプローチにより、開発者は追加のファームウェアイメージを保存できるようになります。この機能は、デバイスが「固まる」リスクを負うことなく、IoTデバイスでオーバーザエア（FOTA）アップデートを可能にするために必要になります。ファームウェアイメージを保存できる場所がプロセッサに1つしかない場合、ファームウェアイメージに欠陥があればデバイスが予測不能な状態またはロック状態に陥り、デバイスがロックされたり、操作不能になったりする可能性があります。ファームウェアイメージをLPC55S69JBD100の複数のPRINCE対応フラッシュ領域に保存することにより、開発者は、新しいバージョンのファームウェアが機能しない状態で起動しても、機能する以前のバージョンのファームウェアを復元するバックオフ戦略を利用できます。

これらの新しいファームウェアイメージはすべて、基盤となるブートプロセスに必要な署名検証チェックをパスする必要があるため、開発者はシステムやその信頼チェーンを損なうことなくセキュアFOTAを最大限に活用して新しい機能を追加したりバグを修正したりすることができます。

結論

システムおよびアプリケーションレベルのセキュリティには、認証済みのソフトウェアのみが実行できる稼働環境が必要です。コード署名の検証はこのような環境を実現する上で不可欠な機能ですが、セキュアなシステムでは、より包括的な機能セットを利用して、信頼できるソフトウェア実行を可能にするために必要な信頼チェーンを構築する必要があります。これらの信頼できる環境の基盤は、信頼のルートにあり、セキュアプロセッサによりサポートされるセキュアブートメカニズムによって実現されます。このクラスのプロセッサを使用することで、開発者はセキュアなIoTデバイスを実装し、システム内でソフトウェア実行を妨害したりシステムを完全に乗っ取ったりする攻撃を防御できるようになります。