wolfSSLでは、長年にわたりお客様と共にセキュアブートソリューションを開発してきましたが、昨年、組み込みシステム向けに設計したセキュアブートローダであるwolfBootを製品としてリリースしました。
wolfBootは、最も一般的なアーキテクチャ（ARM Cortex-M、ARM Cortex-A、RISC-V RV32）をサポートし、様々なデバイス上でのリモートファームウェア更新に信頼性の高いサポートを提供します。
wolfBootはあらゆるタイプのRTOSと組み込みOSをサポートしており、FreeRTOS、Contiki、RIOT-OS、ChibiOS、ThreadX、VxWorks、QNX、TRON/ITRON/μITRON、MicriumのuC/OS、FreeRTOS、SafeRTOS、Freescale MQX、Nucleus、TinyOS、TI-RTOS、uTasker、embOS、INtime、MbedOS、Linuxなどのブートに使用することができます。
ここに、セキュアブートについて知っていただきたい10の事実を紹介します。
10. 信頼できるファームウェア更新は、既にIoTプロジェクトの必須要件に
IoTデバイスはサイバー攻撃を免れるわけではなく、誤った設定のシステムは容易に攻撃対象となると多くの実例で証明されており、時にはソフトウェアコンポーネントのたった一つの脆弱性から分散型システム全体を侵害される事さえあります。
残念ながら、脆弱性は起こるものです。ソフトウェアが完全に最初から書かれたものであっても、サードパーティのコンポーネントに依存しているものであっても、プロジェクトの最悪のタイミングで実装の欠陥が表面化する可能性があり、重要なシステムでは脆弱性のあるバージョンを実行し続ける猶予はありません。
wolfSSLは、セキュリティソフトウェアの開発者が決して安眠できないことを知っています。新しい脆弱性が発見されるとすぐに、チーム全体で修正プログラムの提供に集中し、すべてのテストを起動し、新しいバージョンのソフトウェアをリリースします。
ITサービスでは、ソフトウェアコンポーネントが更新され新バージョンが配信された直後に実行できる、継続的デプロイメントのメカニズムのメリットをすでに受けているケースが多く存在します。これは、古いソフトウェアを本番環境で実行することに関連するリスクを軽減する良い方法です。
なぜ、組み込みシステムで同様のメカニズムを広く利用できないのでしょうか？この質問はいくつかの側面があるため複雑です。市場で利用可能なマイクロコントローラの多様性は、組み込みシステムの開発者に非常に多くの課題を与えています。すべてのシナリオ、ユースケース、プラットフォーム固有のハードウェア、そして時には独自の通信インターフェースやプロトコルに適合するよう、統合メカニズムになっているためです。さらに、組み込みソフトウェアは、一般的にボード上の不揮発性メモリの物理コンテンツと1:1で対応する一枚岩の巨大なバイナリファイルでインストールされます。1つのコンポーネントだけを更新することは、特定のパーティション分割メカニズムで適切に配置されていない限り、単純にはできません。
安全なセキュアファームウェア更新メカニズムのガイドラインを定義する取り組みは、IETF内ではSUITワーキンググループが主導しており、問題を研究し標準ドラフトであるdraft-ietf-suit-architecture-08を作成しています。この文書では、要件をリストアップし、IoTデバイスに適したファームウェア更新メカニズムのアーキテクチャを説明しています。
9. 公開鍵署名認証を使用して更新を検証
SUIT の定義に従った安全なブートローダが持つ特徴は、現在のファームウェアとリモートソースからの更新の真正性を保証するために、最新の暗号技術を使用する点です。公開鍵ベースの認証を使用することで、実行する前にボード上のすべてのソフトウェアを検証することが可能です。
メカニズムは非常に単純で、デバイスの所有者が鍵ペアを作成します。秘密鍵は秘密であり、決して公開されたり、デバイス自体に保存されることはありません。秘密鍵は、スクリプトまたはプログラムによってマニフェストヘッダに署名するために使用され、新しいソフトウェアのバイナリイメージと一緒に送信されます。マニフェストヘッダには、ファームウェアイメージに関連するすべてのメタデータが含まれています。
ブートローダは公開鍵のコピーにアクセスすることができます。公開鍵のコピーはボード上の不揮発性メモリや、特定のハードウェアの安全な保管庫に保存されています。公開鍵は秘密ではありませんので、公開されてもセキュアブートプロセスにリスクはありません。
ブートローダは更新パッケージを受け取ると、公開鍵を使って検証を開始します。検証可能な署名を含む有効なメタデータがあるソフトウェアのみがターゲットデバイス上での実行を許可されます。
8. 小さなブートローダでの運用
セキュアブートローダは、多くの場合、組み込みシステムの唯一の不変部分です。SUIT の仕様では、信頼性にリスクをもたらす可能性があるため、一般にブートローダ自体はアップデートされないことを前提としています。このため、セキュアブートローダを実装するための要件の 1 つは、ブートローダは小さく保ち、システム内の他のコンポーネントをファームウェアイメージの転送と更新の実行に割り当てることです。
これは、必要なレベルの信頼性を保証し、攻撃対象領域を最小限に抑えるために、ブートローダーではコードの安全性が大変重要であることも意味しています。パーサが不具合を出しやすい場所とされているため、SUIT では特に、パーサは小さくと義務付けています。
この方向性をさらに一歩進めると、ブートローダのコードでの動的メモリ割り当ては完全に回避ということになります。コンパイル時にメモリ使用量を測定し、すべてのデータ構造に静的バッファを割り当てることで、不適切なメモリマッピングが設定されている場合に、セクションの重複やヒープスタックの衝突などのメモリ管理の不具合が発生する可能性を大幅に減らすことができます。
セキュアブートローダの実装では、リソースと安全関連の要件の両方を無視できません。そうしないと、より大きな問題を起こしてしまう危険があるからです。
7. ロールバック攻撃
継続的な脆弱性管理の観点から、新しいアップデートは頻繁にリリースされ、利用可能になるべきです。ファームウェアイメージがTLSなどの安全なチャネルを使用して転送されない限り、古いアップデートが攻撃者、またはファームウェアを利用するデバイスへのトラフィックを盗聴している誰かによって傍受されるリスクは常にあります。
これは、例えば、ファームウェアイメージがセキュアソケット通信をサポートしていないローカルメッシュネットワークを通して配布されている場合など、ブロードキャストに適した環境では特に当てはまります。
攻撃者が以前のバージョンの脆弱性を知っていた場合、ネットワーク上の盗聴によって以前に記録されたファームウェアイメージの送信を繰り返すことにより、ターゲットデバイスのファームウェアを特定のバージョンにダウングレードしようとする可能性があります。
セキュアブートメカニズムは、ファームウェアバージョンに関する情報を、マニフェストヘッダー内の他のすべての情報とともに保持する必要があります。
バージョン番号は、残りのメタデータと同様に、署名プロセス中にファームウェアイメージと一緒にエンベロープに入ります。つまり、攻撃者は更新パッケージの署名の有効性を損なうことなくバージョン番号を改ざんすることはできません。ブートローダは、現在システム上で実行されているバージョンよりも古いバージョンのパッケージをインストールすることを許可しません。
ロールバック攻撃は非常に簡単に実行でき、これを防ぐことはセキュアブートローダの重要な仕事です。
6. 停電と高信頼性
マーフィーの法則によれば、「失敗する可能性のあるものは、失敗する」のだそうです。リモートアップデートのインストールの場合、電源が落ちたり、システムがリセットされるようなハードウェアの不具合が発生する最悪のケースは、ファームウェア更新のインストール中に不揮発性メモリの内容が変更された場合です。FLASH セクタのコピー操作の途中で電源が切れると、次の起動時にコピー先のセクタの状態が予測できなくなります。
wolfBoot で実装しているように、常に同じセクターのコピーを二つ持つようにしておき、各ステップが完了したことをフラグで確認する仕組みを使うことで、このような事態を防ぐことができます。再起動時には、最後に成功した操作から操作を再開することができるので、システムが回復不可能な状態になるリスクはありません。
5. セキュアブートと安全なアップデート転送
新しいバージョンのダウンロードは、組み込みアプリケーションのタスク、またはRTOS上で実行されるスレッドです。SUITで示されているように、ブートローダーコードにファームウェアイメージを転送する任務を含めると、プロトコルスタックの実装とプラットフォーム固有のデバイスドライバーに外部依存する、より大きく複雑なセキュアブートローダになってしまいます。実際、組み込みシステムは、利用可能なさまざまな接続技術からネットワークにアクセスすることができます。これらのテクノロジーのすべてが同じプロトコルファミリやトランスポートメカニズムを共有しているわけではありません。LPWANのような低消費電力通信プロトコルの中には、帯域幅やネットワークの可用性に関する要件がさらに厳しくなっている場合もあります。
wolfSSLは、組み込みシステム向けの組み込みSSL/TLSライブラリです。トランスポート層に依存しないため、あらゆる種類のデータ転送テクノロジーやオペレーティングシステム、ベアメタルアプリケーションの上で安全なソケット通信を提供することができます。
接続の安全性を確保するために最新のTLS 1.3を使うことは、現在までに標準で利用可能な最高の暗号技術を利用し、デバイス同士で通信したり、エンドツーエンドの安全なチャネルでバックエンドと通信できることを意味します。
TLS を使用して移動中のすべてのデータを保護することの利点には、2 つのエンドポイント間で転送されるすべてのデータを暗号化することはもちろんのこと、データ、サービス、またはリモートファームウェア更新にアクセスするクライアントのために、オプションとしてサーバー側の識別があります。
TLS ソケット通信を含むスタック全体がデプロイされているシステムでは、ファームウェアイメージの転送は同じチャネル上で行えるため、更新パッケージはファームウェアの利用者まで安全にネットワークを移動することが可能です。
利用可能なリソースが非常に限られたデバイスのサブセットにとっては、TLSは選択肢にならないかもしれないので、そのようなデバイスでは少なくとも暗号化を検討する必要があります。
wolfCryptは、組み込み、RTOS、リソース制約の厳しい環境を対象とする暗号化エンジンで、wolfSSLのコアコンポーネントですが、単独のライブラリとして使用して、ほとんどすべての一般的なアルゴリズムや暗号実装を使うことができます。
4. 鍵管理とトラストアンカー
リモートファームウェアアップデートのために設計された分散システムアーキテクチャでは、 鍵管理は重要なタスクです。バックエンドシステムは、秘密鍵を安全に保ち、新しいバージョンが利用可能になったときに、ファームウェアの利用者に配布するための署名付きパッケージを生成する役割を担っています。
wolfBoot はこれらのタスクを容易にするために、サーバ側に簡単に統合できる鍵管理スクリプトやユーティリティのツールボックスとともに提供されています。
最も単純なケースでは、更新パッケージに含まれる署名は、デバイスの所有者がアクセス可能な秘密鍵を使って取得されます。
より複雑なキープロビジョニングシステムが使われているケースもあります。別個のソフトウェアまたはハードウェアコンポーネントが署名ステップを実行している場合、パッケージ作成プロセスを分割して、DSA ステップを別のコンポーネントにリダイレクトおよび委任することができます。
リモートのファームウェア更新の有効性に対する信頼は、デジタル認証に使用される公開鍵の完全性に依存するため、組み込みシステムの内部に格納されている公開鍵は「トラストアンカー」とみなされます。
トラストアンカーの管理は、ハードウェアプラットフォームに依存するため、一般的にはブートローダの範囲外です。しかし、デバイスに保存され、ファームウェアの真正性を検証するために使用する公開鍵が危殆化するリスクに対して、適切な防御を施すことはブートローダにとって極めて重要です。
トラストアンカーの保管場所は、ハードウェアで利用可能な対策を用いて、書き込みアクセスから保護する必要があります。
3. セキュアエレメントとトラストアンカーの格納
トラストアンカーやその他の暗号化マテリアルを保護する最善の方法は、この目的のために設計された ハードウェアコンポーネントを使用することです。ハードウェアセキュリティモジュール（HSM、CAAMなど）は通常、同じモジュール内で鍵ストレージと暗号演算の高速化の両方を担います。wolfBootを動かす当社の暗号エンジンであるwolfCryptは、この機能にアクセスできる全スキームをサポートしています。その中にはメーカー固有の様々なAPIがあり、Microchip ATECC608A、ARM CryptoCell、NXP CAU/mmCAU/LTC、STMicroelectronic PKAなどを含みます。
最近、セキュリティ暗号化プロセッサへのアクセスに使用されるプロトコルを作る取り組みとして、ISO / IECがTPM（Trusted Platform Module）形式を標準化しました。TPMは現在ほとんどすべてのPCやノートブックで使用されています。
TPM 2.0互換のセキュアエレメントにアクセスするためのAPIを提供するライブラリであるwolfTPMにより、同じテクノロジーが組み込みシステムでも利用できるようになりました。wolfTPMがサポートする一般的なTPMデバイスには、ST33やInfineon 9670などがあります。
wolfBootは、オプションでwolfTPMと一緒にコンパイルして、これらのデバイスが提供するセキュアな鍵ストレージや暗号化アクセラレーションを利用することもできます。
2. ブートローダの更新
ブートローダはそれ自身を更新するための信頼できる方法を実装することが本質的に複雑であるため、SUIT が提案している標準では、この小型のブートローダ部分は不変であることを推奨しています。ただし、ブートローダのコード自体を更新できる可能性があると便利なケースもあります。
公開鍵がブートローダのコードに組み込まれていて、鍵のプロビジョニングは単一の秘密鍵に依存していて、この秘密鍵がバックエンドで危険にさらされている状況がそのケースです。
もう1つのケースは、長寿命の製品で、ブートローダのコードで現在使用されているアルゴリズムや鍵長が、長年の研究によって古くなっていたり、危殆化が判明している場合です。
数年後には、新しい要件に合わせてブートローダのコードを更新する必要が生じるかもしれません。このような理由から、ブートローダコードを更新できるようにすることは重要だと考えています。wolfBootはこのオプションをサポートするようコンパイルすることができます。wolfboot self-update とマークされた特別な更新パッケージは、パッケージ自体の検証が成功した後、ブートローダ自身のコードを上書きします。
ブートローダ自身の更新プロセスは、固有のハードウェアの制約によるため完全にフェイルセーフではありませんが、上記のような緊急の場合に使用するには十分に頼りになります。
1. 開発工数の見積もり
セキュアブートとリモート更新を考える際、この単一のタスクがプロジェクト全体の開発サイクルに与える影響を過小評価してしまうことがよくあります。デバイスがデプロイされたときに起こりうるすべてのケースでシステムの信頼性を保証するには、多大な労力が費やされます。
ブートローダは、おそらくシステムの中で最もクリティカルな部分です。リモートで更新する方法が残っている限り、アプリケーションの他のすべてが壊される可能性があります。特定のプロジェクトのために1からセキュアブートローダを実装するのは、場合によってはシステム内の残りのソフトウェアコンポーネントと同じくらいの開発とテストを必要とする大変な作業です。
弊社のお客様がセキュアブートやリモート更新を構築することをサポートしてきた経験を活かし、私たちはwolfBootを設計しました。wolfBootは、あらゆるセキュアブートのアーキテクチャ要件を満たす基本的なビルディングブロックとして利用できる強固なプラットフォームを提供します。
私共は、リモート更新のためのセキュアブートソリューションに対し、wolfSSLグローバルチームによる商用サポートを提供しています。セキュアブートへの365日年中無休のサポートを提供する唯一の会社です。
wolfSSL Japan合同会社の技術サポートセンタでは、様々な組み込みシステムとの統合を実現すべく、日本人専任スタッフによるサポートサービス、カスタマイズサービスなどを提供しています。お問い合わせ、ご質問は info@wolfssl.jpまでご連絡ください。
原文: https://www.wolfssl.com/top-ten-things-know-secure-boot/