IoTデバイス向けファームウェア更新のアーキテクチャ(仮翻訳)

この資料は、“A Firmware Update Architecture for Internet of Things Devices” (draft-ietf-suit-architecture-11)の日本語仮翻訳です。

概要

モノのインターネット(IoT)デバイスの脆弱性により、制約のあるデバイスにも適した強固で安全なファームウェア更新メカニズムの必要性が高まっています。このような更新メカニズムを組み込んで脆弱性を修正し、構成設定を更新し、新しい機能を追加することは、セキュリティの専門家によって推奨されています。

このドキュメントでは、要件を一覧表示し、IoTデバイスに適したファームウェア更新メカニズムのアーキテクチャについて説明します。アーキテクチャは、ファームウェアイメージおよび関連するメタデータの転送に依存しません。

このメモのステータス

このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に準拠して提出されます。

Internet-Draftは、Internet Engineering Task Force(IETF)の作業文書です。他のグループも作業文書をインターネットドラフトとして配布する場合があることに注意してください。現在のインターネットドラフトのリストは、https://datatracker.ietf.org/drafts/current/にあります。

Internet-Draftは、最長6か月間有効なドラフトドキュメントであり、いつでも他のドキュメントによって更新、置き換え、または廃止される可能性があります。インターネットドラフトを参考資料として使用したり、「進行中の作業」以外の方法で引用することは不適切です。

このインターネットドラフトは、2020年11月28日に期限が切れます。

著作権表示

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

この文書は、BCP 78およびIETF文書に関するIETF Trustの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

 

目次

   1.はじめに
   2. 規則と用語
   3. 要件
     3.1. ファームウェアイメージの配布方法に依存しない
     3.2. ブロードキャスト型配信への親和性
     3.3. 最新のセキュリティ機能の利用
     3.4. ロールバック攻撃からの防衛
     3.5. 高い信頼性
     3.6. 小さなブートローダーで操作する
     3.7. 小さなパーサー
     3.8. 最小限の既存のファームウェア形式への影響
     3.9. 強力な権限
     3.10. 操作モード
     3.11. ソフトウェアおよびパーソナライゼーションデータへの適合性
   4. クレーム
   5. 通信アーキテクチャ
   6. マニフェスト
   7. デバイスファームウェア更新の例
     7.1. 単一CPU SoC
     7.2. セキュリティ付き単一CPU - 通常モード・パーティションニング
     7.3. デュアルCPU、共有メモリ
     7.4. デュアルCPU、個別バス
   8. ブートローダー
   9. 例
   10.  IANAに関して
   11. セキュリティに関して
   12. 謝辞
   13. 参考文献
   著者のアドレス

  1. はじめに

モノのインターネット(IoT)デバイスを開発する場合、最も難しい問題の1つはデバイスのファームウェアを更新する方法です。デバイスがデプロイされると、特にデバイスの寿命が長い場合、ファームウェアの更新は、手動による介入が非常に高くつくか非常に困難であるようなリモートまたはアクセスできないエリアにデプロイされる場合、そのライフサイクルの全期間にわたって重要な役割を果たします。 IoTデバイスのファームウェアの更新は、すでにデプロイされているコンテキストで異なる動作をさせるために、ソフトウェアのバグの修正、新しい機能の追加、新しい環境で動作するようにデバイスを再構成するなどのために行われます。

ファームウェアの更新プロセスは、他の目標の中でも特に、以下のような項目を満足していなければなりません。

-ファームウェアイメージは認証され、整合性が保護されていること。変更されたファームウェアイメージまたは不明なソースからのイメージをフラッシュする試みは防止されること。

-ファームウェアイメージは機密情報で保護できるようにするため、攻撃者によるプレーンテキストバイナリの復元の試みを防止できること。ファームウェアを入手することは、攻撃を開始する最初のステップの1つであることがよくあります。これは、使用されたソフトウェアライブラリ、構成設定、および一般的な機能についての貴重な洞察を敵対者へ与えるからです(バイナリをリバースエンジニアリングするのは面倒なプロセスではありますが)。

このバージョンのドキュメントでは、非対称暗号化と公開鍵インフラストラクチャを想定しています。将来のバージョンでは、非常に強い資源制約のあるデバイス向けに対称鍵アプローチについても説明する可能性があります。

標準化作業は、クラス1デバイスのファームウェア更新ユースケース(RFC 7228 [RFC7228]のデバイスクラス定義による)に基づき、また最適化されていますが、これらのリソース条件のあるIoTデバイスのみに使用を制限する要素はアーキテクチャには含まれていません。ソフトウェア更新、また設定情報や鍵などの任意のデータの配信は、マニフェストによって同様に管理できます。

セキュリティ目標の詳細はセクション5で説明され、要件はセクション3で説明されています。

 

  1. 規約と用語

このドキュメントでは、次の用語を使用します。

-マニフェスト:マニフェストには、ファームウェアイメージに関するメタデータが含まれています。マニフェストは変更から保護され、作成者に関する情報を提供します。

-ファームウェアイメージ:ファームウェアイメージまたはイメージは、デバイスの完全なソフトウェアまたはそのサブセットを含むことができるバイナリです。デバイスに複数のマイクロコントローラーが含まれている場合、ファームウェアイメージは複数のイメージで構成される場合があります。多くの場合、これは、コード、構成データ、さらにはファイルシステム全体を含む圧縮アーカイブでもあります。イメージは、パフォーマンス上の理由により、差分更新で構成されている場合があります。ファームウェアはより普遍的な用語です。ファームウェアイメージ、ファームウェア、およびイメージという用語は、このドキュメントで使用されており、互換性があります。

-ソフトウェア:「ソフトウェア」と「ファームウェア」という用語は同じ意味で使用されます。

-ブートローダー:ブートローダーは、マイクロコントローラーがリセットされると実行されるソフトウェアです。存在するファームウェアイメージを起動するか、新しいファームウェアイメージを取得して確認するかを決定します。ブートローダーはセキュリティ上重要なコンポーネントであるため、その機能は個別のステージに分割できます。このようなマルチステージブートローダーは、最初のステージで非常に基本的な機能を提供し、ROMに常駐するのに対し、2番目のステージはより複雑な機能を実装し、フラッシュメモリに常駐するため、将来更新することができます(バグが見つかった場合) 。コンポーネントの正確な分割、IoTデバイスに保存されるファームウェアイメージの数、および詳細な機能は、実装によって異なります。より詳細な議論はセクション8で提供されます。

-マイクロコントローラー(マイクロコントローラーユニットのMCU):MCUは、組み込みシステムで使用するために設計されたコンパクトな集積回路です。典型的なマイクロコントローラには、プロセッサ、メモリ(RAMおよびフラッシュ)、入出力(I / O)ポート、およびシングルチップ上のバスを介して接続されたその他の機能が含まれます。これらのタイプのデバイスでは、「システムオンチップ(SoC)」という用語がよく使用されます。

-システムオンチップ(SoC):SoCは、CPU、メモリ、入力/出力ポート、セカンダリストレージなど、コンピューターのすべてのコンポーネントを統合する集積回路です。

-Homogeneous Storage Architecture(HoSA):ファイルシステムやフラッシュメモリなど、すべてのファームウェアコンポーネントを同じ方法で保存するデバイス。

-Heterogeneous Storage Architecture(HeSA):少なくとも1つのファームウェアコンポーネントを他のファームウェアコンポーネントとは異なる方法で保存するデバイス。たとえば、外部の更新可能なラジオを備えたデバイス、または内部および外部フラッシュメモリを備えたデバイス。

-信頼できる実行環境(Trusted Execution Environment、TEE):REEと並行して実行されますが、REEからは分離された実行環境。

-リッチ実行環境(Rich Execution Environment、REE):典型的なOS(Linux、Windows、Android、iOSなど)によって提供および管理される環境。サポートする他のオペレーティングシステムやハイパーバイザーと組み合わせて使用​​される可能性があります。それはTEEの外にあります。この環境とそこで実行されているアプリケーションは信頼されていないと見なされます。

-信頼できるアプリケーション(TA):TEEで実行されるアプリケーションコンポーネント。

TEEの詳細については、[I-D.ietf-teep-architecture]を参照してください。

 

次のエンティティが使用されます。

-作成者:作成者は、ファームウェアイメージを作成するエンティティです。デバイスが複数のマイクロコントローラで構成されている場合、または最終的なファームウェアイメージが複数の企業のソフトウェアコンポーネントで構成されている場合、システムに複数の作成者が存在する場合があります。

-ファームウェアコンシューマ:ファームウェアコンシューマは、ファームウェアイメージとマニフェストの受信者です。受け取ったマニフェストの解析と検証、および取得したファームウェアイメージの保存を行います。ファームウェアコンシューマは、通常アプリケーションファームウェアで実行されているIoTデバイス上の更新コンポーネントの役割を果たします。ファームウェアサーバーおよびステータストラッカー(存在する場合)と対話します。

-(IoT)デバイス:デバイスとは、1つ以上のMCU、センサー、アクチュエーターで構成されるIoT製品全体を指します。現在販売されている多くのIoTデバイスには複数のMCUが含まれているため、更新を正常に実行するには、1つのデバイスが複数のファームウェアイメージとマニフェストを取得する必要がある場合があります。デバイスという用語とファームウェアコンシューマはデバイス上のMCUで実行される1つのソフトウェアコンポーネントであるため、ファームウェアコンシューマは互換的に使用されます。

-ステータストラッカー:ステータストラッカーは、デバイスにインストールされているファームウェアやその他のデバイスの特性(空きメモリとハードウェアコンポーネントを含む)に関する情報を取得したり、デバイスが現在行っているファームウェア更新サイクルの状態を取得したり、更新プロセスをトリガーしたりするためのデバイス管理機能を提供します。ステータストラッカーのデプロイは柔軟であり、クラウドベースのサーバー、オンプレミスサーバーとして使用したり、エッジコンピューティングデバイス(インターネットアクセスゲートウェイやプロトコル変換ゲートウェイなど)に組み込んだり、スマートフォンやタブレットに使用したりできます。 IoTデバイス自体はステータストラッカーのクライアント側を実行しますが、プロトコル変換またはエッジコンピューティングデバイスノードで他のIoTデバイスのプロキシとして機能しない限り、ステータストラッカー自体を実行することはほとんどありません。ステータストラッカーがどの程度の機能を含むかは、デバイス管理機能の選択された構成とそれが使用される通信環境によって異なります。一般的なネットワーキング環境では、クライアントとステータストラッカーのサーバ側との間で使用されるプロトコルは、ファイアウォールやNATトラバーサルを含むインターネット通信の課題に対処する必要があリます。他の場合では、通信の相互作用はかなり単純な場合があります。このアーキテクチャドキュメントでは、ステータストラッカーに要件を課していません。

-ファームウェアサーバー:ファームウェアサーバーはファームウェアイメージとマニフェストを保存し、それらをIoTデバイスに配布します。一部のデプロイでは、ストアアンドフォワードの概念が必要になる場合があります。これには、ファームウェアイメージ/マニフェストがデバイスに到達する前に、複数のエンティティに格納する必要があります。通常、ファームウェアサーバーとステータストラッカーの間には何らかの相互作用がありますが、スケーラビリティの理由から、これらのエンティティは異なるデバイス上で物理的に分離されていることがよくあります。

-デバイスオペレーター:IoTデバイス群の日常的な運用を担当するアクター。

-ネットワークオペレーター:IoTデバイスが接続するネットワークの運用を担当するアクター。

 

上記のリストのエンティティに加えて、トラストアンカーと承認権限をシステム内のさまざまなエンティティに配布するTrust Provisioning Authority(TPA)を持つ直交インフラストラクチャがあります。TPAは、トラストアンカーをインストール、更新、拡張、または削除する権限をシステムの他の関係者に委任することもできます。このインフラストラクチャは通信アーキテクチャと重複しており、異なるデプロイでは特定のエンティティに権限を与えることができますが、他のデプロイではそうではない場合があります。たとえば、製品を設計および製造する会社であるオリジナルデザインメーカー(ODM)がTPAとして機能し、製品のファームウェア更新プロセスを完全に制御することを決定する場合があります。

「トラストアンカー」および「トラストアンカーストア」という用語は、[RFC6024]:で定義されています。

-「トラストアンカーは、公開キーと関連データを介して信頼できるエンティティを表します。公開キーはデジタル署名の検証に使用され、関連データは、トラストアンカーが信頼できる情報の種類を制限するために使用されます。」

-「トラストアンカーストアは、デバイスに格納された1つ以上のトラストアンカーのセットです。デバイスには複数のトラストアンカーストアがあり、それぞれが1つ以上のアプリケーションで使用される場合があります。」トラストアンカーストアは、不正な挿入、削除、および変更に対する変更を阻止する必要があります。

 

  1. 要件

この仕様で説明されているファームウェア更新メカニズムは、次の要件を考慮して設計されています。

 

-ファームウェアイメージの配布方法に依存しない

-ブロードキャスト型配信への親和性の親和性

-最新のセキュリティ機能の利用

-ロールバック攻撃からの防衛

-高い信頼性

-小さなブートローダーで操作する

-小さなパーサー

-最小限の既存のファームウェア形式への影響

-強力な権限

-操作モード

-ソフトウェアおよびパーソナライゼーションデータへの適合性

 

3.1. ファームウェアイメージの配布方法に依存しない

ファームウェアイメージは、USB、UART、WiFi、BLE、低電力WANテクノロジーなどのさまざまな方法でデバイスに伝達し、さまざまなプロトコル(CoAP、HTTPなど)を使用できます。指定されたメカニズムは、ファームウェアイメージとマニフェストの配布に依存しない必要があります。

 

3.2. ブロードキャスト型配信への親和性

このアーキテクチャでは、特定のブロードキャストプロトコルは指定されていません。ただし、一部のネットワークではブロードキャストが望ましい場合があるため、メタデータとファームウェアのブロードキャストの両方で更新を行うことで、混乱を最小限に抑える必要があります。

更新をブロードキャストに適したものにするために、リンク層、ネットワーク層、またはトランスポート層のセキュリティに依存することはできません。ソリューションは、代わりにマニフェストとファームウェアイメージに適用されるセキュリティ保護に依存する必要があります。さらに、同じマニフェストは、適用されるデバイスと適用されないデバイスの両方に多くのデバイスに配信可能でなければならず、間違ったデバイスが更新を受け入れる可能性はありません。ネットワークブロードキャストに適用される考慮事項は、ペイロード配信のためのサードパーティのコンテンツ配信ネットワークの使用にも同様に適用されます。

 

3.3. 最新のセキュリティ機能の利用

作成者とデバイス間のエンドツーエンドのセキュリティは、セクション5に示されています。

認証により、デバイスはファームウェアイメージとマニフェストを作成する作成者を暗号で識別できるようになります。認証されたIDは、認証プロセスへの入力として使用できます。

整合性保護により、第三者がマニフェストまたはファームウェアイメージを変更できないようにします。

ファームウェアイメージの機密保護のために、意図されたすべての受信者が暗号化を解除できるように行う必要があります。デバイスごとに個別に暗号化される情報は、コンテンツ配信ネットワーク、大容量ストレージ、およびブロードキャストプロトコルに対する親和性を維持する必要があります。

マニフェスト仕様は、さまざまな暗号化アルゴリズムとアルゴリズムの拡張性をサポートする必要があります。ブートローダーで使用するためのROM内の変更不可能なコードの性質により、ハッシュベースの署名[RFC8778]のような量子化後の安全な署名メカニズムを使用することは魅力的です。これらのアルゴリズムは、量子コンピューターの存在下でセキュリティを維持します。

実装に必須のアルゴリズムのセットは、マニフェスト仕様[I-D.ietf-suit-manifest]で指定されます。

 

3.4. ロールバック攻撃からの防衛

古いファームウェアイメージの脆弱性により、攻撃者がデバイスを制御できるようになる可能性があるため、古いが有効なマニフェストとファームウェアが提示されたデバイスはファームウェアをインストールするよう騙されてはなりません。

 

3.5. 高い信頼性

どんなときも停電がデバイスの障害を引き起こしてはなりません。更新のいずれかの部分の検証に失敗しても、デバイスに障害が発生してはなりません。この機能を実現する1つの方法は、ファームウェア用に最低2つの保存場所とファームウェア用に1つの起動可能な場所を提供することです。別のアプローチは、内蔵のフル機能のファームウェア更新機能が組み込まれた第2ステージのブートローダーを使用して、電源を切った後、更新プロセスに戻ることができるようにすることです。

注:これは、マニフェスト形式の要件ではなく、実装要件です。

 

3.6. 小さなブートローダーで操作する

このドキュメントでは、ブートローダー自体はファームウェアコンシューマの役割とは異なり、ファームウェアの更新プロセスを管理しないと想定しています。これは、ブートローダー自体は完全に別のコンポーネントであり、主に起動するファームウェアイメージの選択を担当するという印象を与えるかもしれません。

ファームウェアの更新プロセスとブートローダー機能は、次の2つの形でのオーバーラップがあります。

-第一に、ブートローダーは、セキュアブートプロセスの一環として、ブートするファームウェアイメージを検証する必要があります。これを行うには、ブートローダーがファームウェアイメージをブートする前にそれが改ざんされたり置き換えられたものでいないことを暗号技術的に検証できるようにするために、ファームウェアイメージと一緒にメタデータを保存する必要があります。ブートローダーによって使用されるこのメタデータは、更新プロセス中にファームウェアイメージで取得されたものと同じマニフェストである可能性があります(分離可能なフィールドは取り除かれた状態で)。

-2番目に、ファームウェアの更新/起動プロセスが失敗した場合に備えて、IoTデバイスにはリカバリ戦略が必要です。リカバリ戦略には、デバイスに2つ以上のファームウェアイメージを保存することや、シリアル、USB、またはBluetooth Smartの限定バージョンのようなワイヤレス接続を介してファームウェア更新を使用して、第2段階のブートローダーがファームウェア更新プロセスを再度実行する機能を提供するなどがあります。後者の場合、ファームウェアコンシューマ機能は第2ステージのブートローダーに含まれ、マニフェスト解析を含むファームウェア更新プロセスを実行するための機能を必要とします。

一般に、ブートローダーの更新に失敗すると信頼性にリスクが生じるため、ブートローダー自体またはその最小部分は更新されないと想定されています。

デバイスがファームウェア更新のインストールに関する決定を行うために必要なすべての情報は、制約のあるIoTデバイスの使用可能なRAMに収まる必要があります。これにより、フラッシュ書き込み領域の枯渇を防止します。ブートローダーがアクティブな間は他のタスク/処理が実行されていないため(アプリケーションファームウェアを実行している場合とは異なり)、これは通常、難しい要件ではありません。

注:これは実装要件です。

 

3.7. 小さなパーサー

パーサーはバグの既知の原因であるため、最小限にする必要があります。さらに、最小限の露出で少なくとも1つの署名またはMACを検証するために必要なフィールドのみを簡単に解析できる必要があります。

 

3.8. 最小限の既存のファームウェア形式への影響

ファームウェア更新メカニズムの設計では、既存のファームウェア形式を変更する必要はありません。

 

3.9. 強力な権限

デバイスが追加の承認手順なしで単一の作成者からモノリシックファームウェアイメージを持っている場合、承認フローは比較的単純です。ただし、デバイスを更新する前に、より複雑なポリシー決定を行う必要がある場合もあります。

このアーキテクチャでは、承認ポリシーは基礎となる通信アーキテクチャから分離されています。これは、エンティティを権限から分離することによって実現されます。たとえば、

作成者は、デバイスオペレーターの許可なしに、重要なインフラストラクチャのデバイスにファームウェアイメージをインストールする権限を持っていない可能性があります。この場合、ファームウェアの作成者とデバイスオペレーターの両方が署名しない限り、ファームウェアの更新を拒否するようにデバイスをプログラムできます。

または、デバイスは1つのエンティティを正確に信頼し、すべての権限の管理と調整を行います。このエンティティにより、デバイスはデバイスの複雑な権限計算をオフロードできます。

 

3.10. 操作モード

更新操作モードには、次の3つの大雑把な分類があります。

 

-クライアントが開始する更新

-サーバーが開始する更新

-ハイブリッドアップデート

 

クライアントが開始する更新では、新しいファームウェアイメージをプロアクティブにチェック(ポーリング)するデバイスのファームウェアコンシューマという形をとります。

一部の 信頼性の高い環境では、更新のタイミングを厳密に制御する必要がある場合があるため、サーバー起動型の更新が重要となります。この場合、ステータストラッカーは、ファームウェア更新の対象となるデバイスを決定します。これらのデバイスが選択されると、ファームウェアサーバーはファームウェアコンシューマに更新を配布します。

注:これは、ステータストラッカーがデバイスに到達できることを前提としています。これにより、デバイスがステータストラッカーの到達可能性情報を最新に保つ必要がある場合があります。これには、NATおよびステートフルパケットフィルタリングファイアウォールの状態を維持する必要がある場合もあります。

ハイブリッドアップデートは、ファームウェアコンシューマとステータストラッカーの間の相互作用を必要とするアップデートです。ステータストラッカーは、更新の利用可能性の通知をファームウェアコンシューマにプッシュし、ファームウェアサーバーからできるだけ早くイメージをダウンロードします。

 

操作モードの別の見方は、更新の過程でデバイスが通過しなければならないステップを考えることです:

-通知

-事前承認

-依存関係解決

-ダウンロード

-インストール

 

通知ステップは、アップデートが利用可能であることをファームウェアコンシューマに通知するステータストラッカーで構成されています。これは、ポーリング(クライアント開始)、プッシュ通知(サーバー開始)、またはより複雑なメカニズムを介して実現できます。

事前承認ステップには、マニフェストに署名するエンティティが実際に更新を実行する権限があるかどうかを確認することが含まれます。ファームウェアコンシューマは、マニフェストで参照されるファームウェアイメージをフェッチして処理するかどうかも決定する必要があります。

依存関係解決フェーズでは、複数のコンポーネントを更新できる場合、または差分更新を使用する場合に必要です。インストールの前に、必要な依存関係が利用可能である必要があります。

ダウンロードステップは、ファームウェアイメージのローカルコピーを取得するプロセスです。ダウンロードがクライアントによって開始される場合、これは、ファームウェアコンシューマがダウンロードの発生するタイミングを選択し、ダウンロードプロセスを開始することを意味します。ダウンロードがサーバーによって開始される場合、これはステータストラッカーがデバイスにダウンロードするタイミングを通知するか、ファームウェアコンシューマへの直接転送を開始することを意味します。たとえば、HTTPベースのファームウェアサーバーからのダウンロードはクライアントが開始します。 LwM2Mファームウェア更新オブジェクト[LwM2M]のパッケージリソースへの転送にマニフェストとファームウェアイメージをプッシュすると、サーバーが開始します。

ファームウェアコンシューマが新しいファームウェアイメージをダウンロードしてインストールする準備ができている場合は、ステータストラッカーからのトリガーを待ってインストールを開始するか、更新を自動的にトリガーするか、より複雑な意思決定プロセスを実行する必要があります。更新の適切なタイミングを決定する(更新プロセスによるエンドユーザーへの影響が少ない時間に更新プロセスを遅らせるなど)。

インストールは、ペイロードをIoTデバイスが認識できる形式に処理する行為であり、ブートローダーは、新しくインストールされたファームウェアイメージから起動します。

これらの各ステップには、異なる権限が必要な場合があります。

 

3.11. ソフトウェアおよびパーソナライゼーションデータへの適合性

標準化されたマニフェスト形式での作業は、最初は最も制約の多いIoTデバイスに焦点を当てており、それらのデバイスには1人の作成者がまとめたコードが含まれています(ただし、その作成者は他の開発者からコードを取得する場合がありますが、一部はバイナリ形式でしか取得できません)。

後で、ソフトウェアだけでなくソフトウェアと一緒にパーソナライゼーションデータを伝達するためにも、標準化されたマニフェストフォーマットから他のユースケースが恩恵を受ける可能性があることがわかりました。たとえば、Trusted Execution Environments(TEE)は、TEE内で実行されている信頼されたアプリケーション(TA)のライフサイクルを管理するためのプロトコルから大きな恩恵を受けます。 TEEはさまざまな作成者からTAを取得する場合があり、それらのTAは支払い情報などのパーソナライゼーションデータをTEEに安全に伝達する必要がある場合があります。

したがって、このより幅広いユースケースをサポートするには、マニフェスト形式を拡張して、他の形式のペイロードも伝達できるようにする必要があります。

 

  1. クレーム

マニフェストのクレームは、ファームウェアの更新プロセスに影響を与える指示をデバイスに伝える方法を提供します。そうするためにはクレームを含むマニフェストを認証し、整合性を保護する必要があります。使用される信用証明は、TPAによってデバイスにインストールされたトラストアンカーに直接的または間接的に関連付けられている必要があります。

すべてのマニフェストの基本のクレームは、[I-D.ietf-suit-information-model]で説明されています。たとえば、次のようなものがあります。

-現在のメタデータより前のメタデータでファームウェアをインストールしない

-ベンダー、モデル、ハードウェアリビジョン、ソフトウェアバージョンなどが一致するファームウェアのみをインストール

-有効期限前のファームウェアのみをインストール

-依存関係が満たされた場合にのみ、ファームウェアのインストールを許可

-ファームウェアのタイプに基づいて、ファームウェアをインストールするメカニズムを選択

 

  1. 通信アーキテクチャ

図1は、作成者がファームウェアイメージを作成し、ファームウェアサーバーにアップロードする通信アーキテクチャを示しています。ファームウェアイメージ/マニフェストは、デバイスに常駐するファームウェアコンシューマを使用して、プッシュまたはプル方式でデバイスに配布されます。デバイスオペレーターは、ステータストラッカーを使用してプロセスを追跡します。これにより、デバイスオペレーターは、どのデバイスが更新を受信し、どのデバイスがまだ更新を保留しているかを把握および制御できます。

図1:アーキテクチャ

エンドツーエンドのセキュリティメカニズムは、ファームウェアイメージとマニフェストを保護するために使用されますが、図2は独立して配布される可能性があるため、マニフェスト自体を示していません。

図2:エンドツーエンドのセキュリティ

 

ファームウェアイメージとマニフェストがデバイスにプッシュされるか、デバイスによってフェッチされるかは、デプロイによります。

ファームウェアコンシューマがソフトウェアを更新する前に、受信したファームウェアイメージとマニフェストを確認できるように、次の前提条件が設けられています。

-更新を受け入れるために、デバイスはマニフェストをカバーする署名を検証する必要があります。検証する必要のある1つまたは複数のマニフェストが存在する場合があり、異なる当事者によって署名される可能性があります。これらの署名を検証するには、デバイスがトラストアンカーを所有している必要があります。 TPAを介したデバイスへのトラストアンカーのインストールは、ファームウェアのアップデートプロセスの前に、アウトオブバンド方式で行われます。

-マニフェストを作成および署名するすべてのエンティティが同じ権限を持つわけではありません。デバイスは、要求されたアクションがマニフェストに署名した当事者の許可によって本当にカバーされているかどうかを判断する必要があります。さまざまな関係者の権限についてデバイスに通知することも、帯域外で行われ、TPAの職務でもあります。

-ファームウェアイメージの機密保護のために、作成者は証明書/公開鍵またはデバイスの事前共有鍵を所有している必要があります。ファームウェアイメージの機密保護の使用は、デプロイによります。

配信モードにはさまざまなタイプがあり、以下の例に基づいて示されています。

 

ファームウェアイメージをマニフェストに埋め込むオプションがあります。これは、デバイスがインターネットに接続されておらず、ファームウェアのダウンロードのために専用のファームウェアサーバーに接続できない場合に便利なアプローチです。ファームウェアの更新がUSBスティックまたはBluetooth Smart経由で行われる場合にも適用されます。図3は、この配信モードを示しています。

図3:ファームウェアが接続されたマニフェスト

 

図4は、デバイスをリモートで更新するためのオプションを示しています。デバイスは、ファームウェアイメージをファイルサーバーからフェッチします。 マニフェスト自体は個別に配信され、ダウンロードするファームウェアイメージに関する情報を提供します。

 

図4:ファームウェアイメージの独立した取得

 

このアーキテクチャは特定の配信モードを義務付けていませんが、ソリューションは両方のタイプをサポートする必要があります。

 

  1. マニフェスト

デバイスが更新を適用するには、更新についていくつかの決定を行う必要があります。

-更新の作成者を信頼しているか?

-ファームウェアが壊れていないか?

-このファームウェア更新はこのデバイスに適用されるものか?

-アップデートはアクティブなファームウェアよりも古くないか?

-デバイスはいつアップデートを適用する必要があるか?

-デバイスはどのようにアップデートを適用する必要があるか?

-どのようなファームウェアバイナリか?

-アップデートはどこで取得すべきか?

-ファームウェアはどこに保存すべきか?

 

マニフェストは、これらの決定を行うためにデバイスが必要とする情報をエンコードします。これは、次の情報を含むデータ構造です。

 

-ファームウェアイメージが適用されるデバイスの情報

-ファームウェアの更新をいつ適用する必要があるかに関する情報

-マニフェストがいつ作成されたかに関する情報

-他のマニフェストへの依存

-ファームウェアイメージへのポインタとフォーマットに関する情報

-ファームウェアイメージの保存場所に関する情報

-デジタル署名やメッセージ認証コード(MAC)などの暗号化情報

 

マニフェスト情報モデルは、[I-D.ietf-suit-information-model]で説明されています。

 

  1. デバイスファームウェア更新の例

この資料は、既存のシステムとまだ考えられていないシステムの両方に適用できるファームウェア更新アーキテクチャを定義しようとするものですが、既存のアーキテクチャを検討することも役に立ちます。

 

7.1. 単一CPU SoC

最も単純で現在最も一般的なアーキテクチャは、1つのMCUとその周辺機器で構成されています。これらのSoCには通常、コードと固定データ用のフラッシュメモリと、作業用ストレージ用のRAMが含まれています。これらのシステムには、単一のファームウェアイメージ、または単一のイメージを実行する不変のブートローダーがあります。これらのSoCの注目すべき特徴は、主なコードが一般にRAMにコピーされずに直接実行される(eXecutein-Place、XIP)ことです。コードの再配置不可能な性質と組み合わせて、ファームウェアの更新を適切に行う必要があります。

 

7.2. セキュリティ付き単一CPU – 通常モード・パーティションニング

次の構成は、前のものと同様のアーキテクチャで、単一のCPUで構成されています。ただし、このCPUは、メモリを(他のものに加えて)セキュアモードと通常モードに分割できるセキュリティパーティションスキームをサポートしています。通常、セキュアモード用と通常モード用の2つのイメージがあります。この構成では、ファームウェアのアップグレードは通常、セキュアモードのCPUによって行われ、フラッシュデバイスの両方の領域に書き込むことができます。さらに、関連するマニフェストで指定されているように、どちらかのイメージを個別に更新できること、およびそれらを一緒にアトミックに更新できることの要件があります。

 

7.3. デュアルCPU、共有メモリ

この構成では、メモリ(フラッシュとRAM)を共有する単一のSoCに2つ以上のCPUがあります。一般に、これらは1つのCPUが他のCPUのメモリにアクセスするのを防ぐ保護メカニズムです。この場合のアップグレードは、通常、いずれかのCPUによって行われ、セキュアモードのシングルCPUと同様です。

 

7.4. デュアルCPU、個別バス

この構成には2つ以上のCPUがあり、それぞれに独自のメモリがあります。それらの間には通信チャネルがありますが、共有メモリ経由ではなく、ペリフェラルとして使用されます。この場合、各CPUは独自のファームウェアのアップグレードを担当する必要があります。 CPUの1つがマスターと見なされ、他のCPUにアップグレードを指示する可能性があります。この構成は通常、特定の作業を他のCPUにオフロードするために使用されます。ファームウェアの依存関係は上記の他のソリューションと同様であり、1つのイメージのみをアップグレードできる場合もあれば、いくつかをアトミックにアップグレードする必要がある場合もあります。 更新は複数のCPUで行われるため、2つのイメージをアトミックにアップグレードすることは困難です。

 

8.ブートローダー

今日、これまで以上に多くのデバイスがインターネットに接続されているため、USBやRS232などの従来のインターフェイスではなく、インターネットを介してファームウェアの更新を提供する必要が出てきました。インターネット経由でデバイスを更新するには、デバイスがファームウェアイメージだけでなくマニフェストもフェッチする必要があります。したがって、ファームウェア更新ソリューションには次の構成要素が必要です。

 

-ファームウェアダウンロード用のインターネットプロトコルスタック(*)、

-更新を実行する前に、受信したファームウェアイメージを永続ストレージ(おそらくフラッシュメモリ)に書き込む機能、

-受信したファームウェアイメージを解凍、展開、またはその他の方法で処理する機能

-デジタル署名の検証やメッセージ認証コードのチェックなど、イメージとマニフェストを検証する機能

-マニェスト解析ライブラリ、および

-自動ファームウェア更新を実行し、その進行状況を追跡するようデバイスをデバイス管理サーバーに統合

 

(*)ファームウェアイメージは、ローエンドのIoTデバイスではサイズが数キロバイト、場合によっては100キロバイトを超え、Linuxなどの本格的なオペレーティングシステムを実行しているIoTデバイスでは数メガバイトにもなるため、これらのイメージを取得するためのプロトコルメカニズムは、輻輳制御、フロー制御、断片化と再構成、中断または破損した転送を再開するメカニズムなどの機能を提供する必要があります。

 

多くの場合、これらの機能はすべて、ブートローダー自体ではなく、デバイスで実行されるアプリケーション、つまりファームウェアコンシューマによって提供されます。(信頼できる実行環境または別のハードウェアセキュリティMCU /モジュールで実行される基本的なセキュリティアルゴリズムを除く)

 

マニフェストが処理され、ファームウェアイメージが正常にダウンロードされて検証されたら、デバイスはブートローダーに制御を渡す必要があります。ほとんどの場合、これにはMCUの再起動が必要です。一度MCUが再起動を開始すると、ブートローダーが制御を引き継ぎ、新しくダウンロードされたファームウェアイメージを実行するかどうかを決定します。

 

ファームウェアイメージは、オフチップフラッシュメモリなどに格納できるため、ブートプロセスはセキュリティに敏感です。攻撃者は、リバースエンジニアリングやバイナリの変更のためにイメージに簡単にアクセスできてしまいます。したがって、ブートローダーは、ブートする前にファームウェアイメージのセキュリティチェックを実行する必要があります。ブートローダーによるこれらのセキュリティチェックは、ファームウェアイメージとマニフェストがダウンロードされたときに行われたセキュリティチェックに加えて行われます。

 

マニフェストは、起動のたびにファームウェアイメージを再検証できるように、ファームウェアイメージと一緒に保存されている場合があります。または、ファームウェアのダウンロードと検証プロセスが正常に完了した後で、アプリケーションによってセキュアブート固有のメタデータが作成されている可能性があります。最初のファームウェア取得プロセス中に使用された標準化されたマニフェスト形式を再利用するか、またはセキュアブート固有のメタデータに別の形式を使用する方が良いかは、システム設計によって異なります。ただし、マニフェスト形式は、不要な要素を取り除くことでマニフェストのサイズを縮小できる分離可能な要素を備えたセキュアブートのビルディングブロックとしても機能します。

 

上記のように、アプリケーションイメージにファームウェアコンシューマ機能が含まれている場合は、デバイス上に作業イメージを残す必要があります。これにより、ブートローダー自体にファームウェアイメージとマニフェストをファームウェアサーバーからインターネット経由で取得するのに十分な機能がない場合、ブートローダーは作業ファームウェアイメージにロールバックしてファームウェアダウンロードを実行できます。マルチステージブートローダーは、より洗練されたブートプロセスを犠牲にして、この要件を緩和できます。

 

ブートローダーが安全なブートメカニズムを提供するには、次の機能を提供する必要があります。

 

-SHA-256などのセキュリティアルゴリズムにアクセスして、ファームウェアイメージとデジタル署名アルゴリズムのフィンガープリントを計算する機能

-デジタル署名を利用するために、直接または間接的に鍵材料にアクセスします。デバイスには、トラストアンカーストアが必要

-ブートプロセス関連のデータをアプリケーションファームウェア(デバイス管理ソフトウェアなど)に公開する機能。これにより、デバイス管理サーバーは、ファームウェアの更新が成功したかどうかを判断し、失敗した場合はどのエラーが発生したかを判断

-(オプションで)認証情報を提

 

ブートローダーのソフトウェアアーキテクチャとそのセキュリティメカニズムは実装によりますが、マニフェストを使用してインターネットからのファームウェアのダウンロードとセキュアブートプロセスの強化を制御可能です。

 

図5は、作成者が新しいファームウェアをファームウェアサーバーにアップロードし、マニフェストを作成するところから始まり、デバイスにファームウェアイメージを配布するためのメッセージフローの例を示しています。 ファームウェアとマニフェストは同じファームウェアサーバーに保存されます。 このセットアップではステータストラッカーを使用しないため、ファームウェアコンシューマコンポーネントは、新しいファームウェアイメージがダウンロード可能かどうかを定期的にチェックする必要があります。

図5:ファームウェア更新の最初のフローの例

図6は、ステータストラッカーを使用したデバイスのフォローの例を示しています。編集上の理由から、ステータストラッカーでマニフェストとファームウェアサーバーでファームウェアイメージを公開している作成者は表示されていません。ファームウェアの更新プロセスが成功した後のセキュアブートプロセスも省略されています。

 

交換は、デバイスがステータストラッカーと対話することから始まります。そのような交換の詳細は、使用されているさまざまなデバイス管理システムによって異なります。いずれの場合でも、ステータストラッカーは、管理するデバイスのファームウェアバージョンについて学習します。この例では、管理対象のデバイスはファームウェアバージョンA.B.Cを使用しています。後で、作成者は新しいファームウェアをマニフェストと共にファームウェアサーバーとステータストラッカーにそれぞれアップロードします。マニフェストとファームウェアを異なるサーバーに保存する必要はありませんが、この例は業界で使用されている一般的なパターンを示しています。次に、ステータストラッカーは、人間の介入に基づいて、またはより複雑なポリシーに基づいて、自動的にデバイスに新しく利用可能なファームウェアイメージについて通知することを決定します。この例では、マニフェストをファームウェアコンシューマにプッシュすることでこれを行います。ファームウェアコンシューマは、マニフェストの検証に成功した後、新しいバージョンX.Y.Zのファームウェアイメージをダウンロードします。その後、再起動が開始され、セキュアブートプロセスが開始されます。

図6:ファームウェア更新の2番目のフローの例

 

  1. IANAに関して

このドキュメントでは、IANAによるアクションは必要ありません。

 

  1. セキュリティに関して

ファームウェアの更新は、セキュリティの脆弱性を修正し、IoTデバイスを保護するための重要なビルディングブロックと見なされています。IoTデバイスのファームウェア更新の重要性により、その全体像を見るために、インターネットアーキテクチャボード(IAB)は、「Workshop on Internet of Things (IoT) Software Update (IOTSU)」(IoTのソフトウェア更新に関するワークショップ)を2016年6月13日と14日にアイルランドのトリニティカレッジダブリンで開催しました。このワークショップに関するレポートは[RFC8240]にあります。作成者からデバイスまでのエンドツーエンドのセキュリティを提供する標準化されたファームウェアマニフェスト形式は、別のドキュメントに記載されています。

 

ワークショップ中には他にも多くの考慮事項が上がりました。その多くは標準化の範囲外で、製品エンジニアリング、規制フレームワーク、およびビジネスモデルの領域に該当する内容でした。次の考慮事項は、このドキュメントの範囲外です。

 

-デバイスが動作する環境でアップデートによってデバイス機能が損なわれないよう、堅牢な方法でのファームウェアアップデートのインストール

 

-デバイスを更新する意思決定プロセスの複雑さ、潜在的な再認証要件、更新をインストールするためのユーザーの同意の必要性を考慮した、タイムリーなファームウェア更新のインストール

 

-効率的な方法で、人間の関与なしに多数のデバイスを対象とすることも含めた実際のファームウェア更新の配布

-エネルギー効率とバッテリー寿命の考慮

-マニフェストを保護するデジタル署名を検証するために必要な鍵管理

-製造業者がIoT製品の一部としてファームウェア更新メカニズムを提供するインセンティブ

 

 

  1. 謝辞

以下の方々からのフィードバックに感謝いたします。

–  Geraint Luff

–  Amyas Phillips

–  Dan Ros

–  Thomas Eichinger

–  Michael Richardson

–  Emmanuel Baccelli

–  Ned Smith

–  Jim Schaad

–  Carsten Bormann

–  Cullen Jennings

–  Olaf Bergmann

–  Suhas Nandakumar

–  Phillip Hallam-Baker

–  Marti Bolivar

–  Andrzej Puzdrowski

–  Markus Gueller

–  Henk Birkholz

–  Jintao Zhu

–  Takeshi Takahashi

–  Jacob Beningo

–  Kathleen Moriarty

 

また、WG議長のRuss Housley、David Waltermire、Dave Thalerのサポートとレビューにも感謝します。

 

  1. 参考文献

[I-D.ietf-suit-information-model]

Moran, B., Tschofenig, H., and H. Birkholz, “An

Information Model for Firmware Updates in IoT Devices”,

draft-ietf-suit-information-model-05 (work in progress),

January 2020.

 

[I-D.ietf-suit-manifest]

Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,

“A Concise Binary Object Representation (CBOR)-based

Serialization Format for the Software Updates for Internet

of Things (SUIT) Manifest”, draft-ietf-suit-manifest-05

(work in progress), May 2020.

 

[I-D.ietf-teep-architecture]

Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,

“Trusted Execution Environment Provisioning (TEEP)

Architecture”, draft-ietf-teep-architecture-08 (work in

progress), April 2020.

 

[LwM2M]    OMA, ., “Lightweight Machine to Machine Technical

Specification, Version 1.0.2”, February 2018,

<http://www.openmobilealliance.org/release/LightweightM2M/

V1_0_2-20180209-A/OMA-TS-LightweightM2M-

V1_0_2-20180209-A.pdf>.

 

[RFC6024]  Reddy, R. and C. Wallace, “Trust Anchor Management

Requirements”, RFC 6024, DOI 10.17487/RFC6024, October

2010, <https://www.rfc-editor.org/info/rfc6024>.

 

[RFC7228]  Bormann, C., Ersue, M., and A. Keranen, “Terminology for

Constrained-Node Networks”, RFC 7228,

DOI 10.17487/RFC7228, May 2014,

<https://www.rfc-editor.org/info/rfc7228>.

 

[RFC8240]  Tschofenig, H. and S. Farrell, “Report from the Internet

of Things Software Update (IoTSU) Workshop 2016”,

RFC 8240, DOI 10.17487/RFC8240, September 2017,

<https://www.rfc-editor.org/info/rfc8240>.

 

[RFC8778]  Housley, R., “Use of the HSS/LMS Hash-Based Signature

Algorithm with CBOR Object Signing and Encryption (COSE)”,

RFC 8778, DOI 10.17487/RFC8778, April 2020,

<https://www.rfc-editor.org/info/rfc8778>.

 

 

著者のアドレス

Brendan Moran

Arm Limited

EMail: Brendan.Moran@arm.com

 

Hannes Tschofenig

Arm Limited

EMail: hannes.tschofenig@arm.com

 

David Brown

Linaro

EMail: david.brown@linaro.org

 

Milosch Meriac

Consultant

EMail: milosch@meriac.com