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

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

目次

   1.  はじめに  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  規約と用語. . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  要件    . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  ファームウェアイメージと配布方法に依存しない. . . . . . .   7
     3.2.  ブロードキャスト型配布への親和性   . . . . . . . . . . .   7
     3.3.  最新のセキュリティ機能の利用   . . . . . . . . . . . . .   7
     3.4.  ロールバック攻撃からの防衛   . . . . . . . . . . . . . .   8
     3.5.  高い信頼性    . . . . . . . . . . . . . . . . . . . . .   8
     3.6.  小さなブートローダ   . . . . . . . . . . . . . . . . . .   8
     3.7.  小さなパーサー  . . . . . . . . . . . . . . . . . . . .   9
     3.8.  既存ファームウェアフォーマットに最小の影響 . . . . . . . .   9
     3.9.  堅牢な権限  . . . . . . . . . . . . . . . . . . . . . .   9
     3.10. 多様な運用モード . . . . . . . . . . . . . . . . . . . .  9
   4.  Claims  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  通信アーキテクチャ  . . . . . . . . . . . . . . . . . . . . .  12
   6.  Manifest  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  デバイスファームウェア更新の例  . . . . . . . . . . . . . . . .  17
     7.1.  単一CPU SoC  . . . . . . . . . . . . . . . . . . . . . .  17
     7.2.  セキュリティ付き単一CPU - 通常モード・パーティションニング .  17
     7.3.  デュアルCPU, 共有メモリ  . . . . . . . . . . . . . . . . .  17
     7.4.  デュアルCPU, 個別バス . . . . . . . . . . . . . . . . . .  17
   8.  ブートローダ  . . . . . . . . . . . . . . . . . . . . . . . .  18
   9.  例 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   10. IANA に関して . . . .  . . . . . . . . . . . . . . . . . .  21
   11. セキュリティに関して . . . . . . . . . . . . . . . . . . . .  22
   12. メーリングリスト情報   . . . . . . . . . . . . . . . . . . .  22
   13. 謝辞    . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   14. 参照  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
     14.1.  通常参照 . . . . . . . . . . . . . . . . . . . . . . .  24
     14.2.  参考 . . . . . . . . . . . . . . . . . .  . . . . . .  24
     14.3.  URI . . . . . . . . . . . . . . . . . . . . . . . . .  25
   著者のアドレス  . . . . . . . . . . . . . . . . . . . . . . . .  25

1. はじめに

IoTデバイス開発において最も難しい問題の1つは、デバイスのファームウェアを更新する方法です。特にデバイスが長期間使用される場合、デバイスが展開されたあとファームウェアの更新がクリティカルな課題となってきます。 IoTデバイスのファームウェア更新によって、ソフトウェアのバグ修正、新機能の追加、新しい環境での動作のためのデバイスの再構成、また、すでに展開されているコンテキストで異なる動作をさせたりもしたります。

ファームウェア更新のプロセスでは、他の目標とともに、次のようなことを満たさなければなりません。

– ファームウェアイメージは認証され、完全性が保護されること。修正されたファームウェアイメージ、未知のソースからのイメージをフラッシュしようとするような試みは阻止しなければなりません。

– 攻撃者による平文のバイナリを復元しようとするような試みを阻止できるように、ファームウェアイメージの秘匿性を確保できること。ファームウェアを入手することで、(バイナリのリバースエンジニアリングは面倒なプロセスではあるけれど)使用されるソフトウェアライブラリ、構成設定、あるいは一般的な機能についてなど攻撃者に有益な洞察を与えてしまいます。これは、しばしば攻撃の最初のステップの1つとなります。   セキュリティ目標に関する詳細は第5章で論じ、要件は第3章で説明します。

2.規約と用語

<省略>

3.要件

この仕様で説明されているファームウェアアップデートメカニズムは以下の要件を念頭に置いて設計されています。

– ファームウェアイメージと配布方法は不可視
– ブロードキャスト型配布への親和性
– 最新のセキュリティ機能の利用
– ロールバック攻撃からの防衛
– 高い信頼性
– 小さなブートローダ
– 小さなパーサー
– 既存ファームウェアフォーマットに最小の影響
– 堅牢な権限
– 多様な運用モード

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

ファームウェアイメージは、USB、UART、WiFi、BLE、低電力WAN技術などを含む様々な方法でデバイスに伝達することができ、異なるプロトコル(例えば、CoAP、HTTP)を使用することができる。指定されたメカニズムは、ファームウェアイメージとマニフェストの配布方法から不可知である必要があります。

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

このアーキテクチャは、特定のブロードキャストプロトコルを指定しません。 しかし、ブロードキャストがいくつかのネットワークにとって望ましいかもしれないとすれば、更新はメタデータとペイロード送信の両方で可能な限り混乱を最小にしなければなりません。

更新をブロードキャストと親和性のあるものにするには、リンク層、ネットワーク層、またはトランスポート層セキュリティに依存することはできません。さらに、同じメッセージを多数のデバイスに配信する場合、適用されるデバイス、適用されないデバイス、どちらに配信する場合も、間違ったデバイスが受信する可能性がないようにする必要があります。ネットワークブロードキャストに適用される考慮事項は、ペイロード配信のためにサードパーティのコンテンツ配信ネットワークに使用する場合にも同様に当てはまります。

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

第5章に示すように、ファームウェア作成者とデバイス間のエンドツーエンドのセキュリティが、デバイスが許可された作成者によって作成されたファームウェアイメージとマニフェストを検証可能とするために使用されます。

ハッシュベースの署名など​​、量子安全な(post-quantum)署名メカニズムの使用を検討する必要があります。量子安全な署名への移行には多大な労力が必要となるため、量子安全署名に対する実装サポートを必須とする(mandatory-to-implement)が目標となります。

RFC 7925 [RFC 7925]の第20章で概説されているように、必須実装 (mandatory-to-implement) の一連のアルゴリズム、112ビットの対称鍵以上の鍵長または安全性を提供するように定義されなければなりません。これは、233ビットのECC鍵または2048ビットのRSA鍵に対応します。

ファームウェアイメージを暗号化する場合は、対象となるすべての受信者がそれを復号化できるようにする必要があります。コンテンツ配信ネットワーク、大容量記憶装置、およびブロードキャストプロトコルに対する親和性を維持するために、各デバイスに対して個別に暗号化される情報は、絶対最小値、たとえばAES Key Wrap [RFC 5649]である必要があります。

 

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

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

 

3.5. 高い信頼性

いかなるタイミングの停電も機器の故障を引き起こしてはなりません。
更新の一部分を検証できなかったとしても、そのデバイスに障害を引き起こしてはなりません。この機能を実現するための1つの方法は、ファームウェア用に最低2つの保管場所とファームウェア用に1つの起動可能な場所を提供することです。別の方法は、全ファームウェアアップデート機能を内蔵した2段階目のブートローダを使用して、電源断の後にアップデートプロセスに戻ることができるようにすることです。

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

 

3.6. 小さなブートローダ

ブートローダは最小限でなければならず、フラッシュのサポート、暗号化の基本機能、そしてオプションで回復メカニズムのみを含みます。回復メカニズムは、更新プロセスが失敗した場合に使用され、シリアル、USB、さらには限定されたBluetooth Smartなどの限定されたバージョンのワイヤレス接続規格によるファームウェア更新のサポートを含みます。このような回復メカニズムは、少なくともフル機能のファームウェア更新機能と同じレベルでセキュリティを提供する必要があります。

ブートローダは受け取ったマニフェストを確認し、起動可能なファームウェアイメージをインストールする必要があります。更新が失敗すると信頼性にリスクが生じるため、ブートローダは更新を要求してはいけません。ブートローダにさらに機能が必要な場合は、2段階ブートローダを使用して、最初の段には上記で定義した機能のみが含むようにします。

ファームウェア更新のインストールに関してデバイスが決定を下すために必要なすべての情報は、メモリー制約のあるIoTデバイスでは使用可能なRAMに収まる必要があります。これによってフラッシュ書き込みの枯渇を防ぎます。

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

 

3.7. 小さなパーサ

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

 

3.8. 既存ファームウェアフォーマットに最小の影響

このファームウェア更新機能の設計では、既存のファームウェアフォーマットへの変更を必要とするものであってはいけません。

 

3.9. 堅牢な権限

別段の承認手順なしでデバイスが単一の作成者からひと塊りのファームウェアイメージを取得するだけならば、承認の流れは比較的簡単です。しかし、デバイスを更新する前により複雑なポリシー決定を行う必要がある場合も多々あります。

このアーキテクチャでは、認可ポリシーは土台としている通信アーキテクチャとは分離されています。これはエンティティをそれらの許可から分離することによって実現されています。たとえば、重要なインフラストラクチャではファームウェア作成者はデバイスオペレータの承認なしにデバイスにファームウェアイメージをインストールする権限を持たない場合があります。この場合、ファームウェアの作成者とデバイスのオペレータの両方によって署名されていない限りデバイスはファームウェアの更新を拒否するようにプログラムされるでしょう。

あるいは、デバイスが1つのエンティティだけを信頼しそれがすべての権限管理と調整を行うという風にすることもできるでしょう。このようなエンティティによって権限に関する複雑な計算の負荷をデバイスから外すことができます。

 

3.10. 多様な運用モード

更新操作モードには大きく3つの分類があります。

– クライアント起動による更新
– サーバ起動による更新
– 複合した更新

クライアント起動による更新は、デバイス上のファームウェア使用者が新しいファームウェアイメージを積極的にチェック(ポーリング)するという形をとります。

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

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

複合アップデートは、ファームウェア利用者と状態トラッカーの間の対話を必要とするものです。状態トラッカーは、更新の利用可能性の通知をファームウェア利用者にプッシュし、その後、できるだけ早くファームウェアサーバからイメージをダウンロードします。

動作モードに対する別の見方としては、更新中にデバイスが通過しなければならないステップを考えることができます。

– 通知

– 事前承認

– 依存関係の解決

– ダウンロード

– インストール

通知ステップは、状態ストラッカーから通知されます。
ファームウェア利用者は、更新が入手可能であることを確認します。これは、ポーリング(クライアント主導)、プッシュ通知(サーバー主導)、またはより複雑なメカニズムによって実現できます。

事前承認ステップでは、マニフェストに署名するエンティティが実際に更新を実行することを承認されているかどうかを検証します。ファームウェア利用者は、マニフェストで参照されているファームウェアイメージを取得して処理する必要があるかどうかも決定する必要があります。

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

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

ファームウェア利用者が新しいファームウェアイメージをダウンロードしてインストールの準備ができている場合は、状態トラッカーからの起動を待ってインストールを開始するか、自動的にアップデートを起動するか、または更新の適切なタイミングを決定するためより複雑な意思決定プロセスを経る必要があります(エンドユーザーが更新プロセスによる影響を受けにくいときに更新プロセスを遅らせるなど)。

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

これらの各手順には、異なる権限が必要な場合があります。

 

4. クレーム

マニフェストのクレームは、ファームウェア更新プロセスに関する指示をデバイスに伝えるためのものです。クレームを利用するためには、それらの主張を含むマニフェストが認証され、完全性が保護されている必要があります。これまで使用されてきた認証情報は、Trust Provisioning Authorityによってデバイスにインストールされたトラストアンカーに直接または間接的に関連付けられている必要があります。

すべての目録に対するベースラインの主張は[I-D.ietf-suit-information-model]に記述されています。たとえば、

– 現在のメタデータより古いメタデータでファームウェアをインストールしてはいけない
– ベンダー、モデル、ハードウェアリビジョン、ソフトウェアバージョンなどが一致するファームウェアのみをインストール
– 最新のタイムスタンプより前のファームウェアのみをインストール
– 依存関係が満たされている場合にのみファームウェアのインストールを許可
– ファームウェアの種類に基づいて、ファームウェアをインストールするためのメカニズムを選択

 

5. 通信アーキテクチャ

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

 


図1アーキテクチャ

 

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

 

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

 

ファームウェアイメージとマニフェストがデバイスにプッシュされるのか、デバイスによってフェッチされるのかは、展開 (deployment) ごとの決定事項です。

以下の仮定は、ファームウェア消費者が受信したファームウェアイメージを検証し、ソフトウェアを更新する前に明示することを可能にするためのものです。

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

– マニフェストを作成および署名するすべてのエンティティが同じ権限を持つわけではありません。デバイスは、要求されたアクションが実際にマニフェストに署名した当事者の許可によってカバーされているかどうかを判断する必要があります。異なる当事者の許可についてのデバイスへの通知も別ルート (out-of-band) で行われ、Trust Provisioning Authorityの義務でもあります。

– 作者が必要とするファームウェアイメージの機密保護のために証明書/公開鍵またはデバイスの事前共有鍵を所有していること。ファームウェアイメージの機密性保護の使用は展開 (deployment) ごとに決めます。

以下の例で示されるように、さまざまな種類の配信モードがあります。

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

 


図3. ファームウェアのアタッチされたマニュフェスト

 

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

図4. ファームウェアイメージの独立した取り出し

 

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

 

6. マニフェスト

デバイスがアップデートを適用するには、アップデートに関するいくつかの決定を下す必要があります:

– アップデートの作者を信頼しているか?
– ファームウェアが壊れていないか?
– ファームウェアアップデートはこのデバイスに適用されるか?
– アップデートはアクティブファームウェアよりも古いか。
– デバイスはいつアップデートを適用する必要があるか。
– デバイスはどのようにアップデートを適用すべきか?
– それはどのようなファームウェアバイナリか?
– アップデートはどこで入手できるか?
– ファームウェアはどこに保存するか。

 

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

– ファームウェアイメージが適用されることを意図しているデバイスに関する情報
– ファームウェアアップデートの適用時期に関する情報
– マニフェストがいつ作成されたかに関する情報
– 他のマニフェストへの依存
– ファームウェアイメージへのポインタとフォーマットに関する情報
– ファームウェアイメージの保存場所に関する情報
– デジタル署名やメッセージ認証コード(MAC)などの暗号化情報。
マニフェスト情報モデルは[I-D.ietf-suit-information-model]に記述されています。

 

7.デバイスファームウェアアップデート例

これらの文書は、既存のシステムとこれからのシステムの両方に適用可能なファームウェアアップデートアーキテクチャを定義しようとしてはいますが、既存のアーキテクチャーを検討することが役に立ちます。

7.1 単一CPU SoC

最も単純で現在最も一般的なアーキテクチャは、1つのMCUと周辺機器で構成されたものです。これらのSoCには通常、コードや固定データ用の一定量のフラッシュメモリ、および作業用のRAMが含まれています。これらのシステムには、単一のファームウェアイメージ、または単一のイメージを実行する変更のないブートローダがあります。
これらのSoCの顕著な特徴は、一般に最初のコードがインプレースで実行される(XIP)ということです。コードの位置を変えられないという性質と合わせて、ファームウェアの更新は適切に行われる必要があります。

 

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

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

 

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

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

 

7.4 デュアルCPU、その他のバス

この構成には2つ以上のCPUがあり、それぞれが独自のメモリーを持ちます。それらの間には通信チャネルがありますが、共有メモリを介してではなく、周辺機器として使用されます。この場合、各CPUはそれ自身のファームウェアアップグレードを担当しなければなりません。一方のCPUがマスターと見なされ、もう一方のCPUにアップグレードを指示するような場合があります。この設定は、特定の作業を他のCPUにオフロードするためによく使用されます。

ファームウェアの依存関係は上記の他の構成の場合と似ていて、場合によって1つのイメージだけをアップグレードすることが可能だったり、複数の自動的アップグレードを求められたりします。更新は複数のCPUで行われているため、2つのイメージをアトミックにアップグレードするのは非常に困難です。

 

8.ブートローダ

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

 

– (おそらく大きな)ファームウェアのダウンロードのためのインターネットプロトコルスタック
– 更新を実行する前に、受信したファームウェアイメージを永続性のあるストレージ(通常はフラッシュメモリ)に書き込む機能
– 受信したファームウェアイメージを解凍、解凍、またはその他の方法で処理する能力
– デジタル署名の検証やメッセージ認証コードの確認など、イメージとマニフェストを検証する機能
– マニフェスト解析ライブラリ
– 自動ファームウェア更新を実行し、それらの進捗状況を追跡するための、デバイス管理デバイスへのデバイスの統合。

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

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

ファームウェアイメージは、例えばオフチップのフラッシュメモリに保存される可能性があるため、ブートプロセスはセキュリティに注意を払う必要があります。そのため、ブートローダはファームウェアイメージを起動する前にセキュリティチェックを実行する必要があります。ブートローダによるこれらのセキュリティチェックは、ファームウェアイメージとマニフェストがダウンロードされたときに行われたセキュリティチェックに加えて行われます。

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

前述のようにアプリケーションイメージにファームウェア利用者機能が含まれている場合は、ブートローダが起動してからファームウェアのダウンロードをやり直すために、ブートローダが作業ファームウェアイメージにロールバックできるように、作業イメージをデバイスに残す必要があります。それ自体は、インターネット経由でファームウェアサーバーからファームウェアイメージとマニフェストを取得するのに十分な機能を持っていません。マルチステージブートローダは、より洗練されたブートプロセスを犠牲にしてこの要求を和らげるかもしれません。

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

– SHA-256などのセキュリティアルゴリズムにアクセスして、ファームウェアイメージとデジタル署名アルゴリズムを介してフィンガープリントを計算する機能
– デジタル署名を利用するために直接または間接的なキーイング資料へのアクセス。デバイスにはトラストアンカーストアが必要
– ブートプロセス関連のデータをアプリケーションファームウェア(デバイス管理ソフトウェアなど)に公開する機能。これにより、デバイス管理サーバーはファームウェアの更新が成功したかどうか、失敗した場合はどのようなエラーが発生したのかを判断可能
– (オプションで)認証情報(測定値など)を提供
ブートローダのソフトウェアアーキテクチャとそのセキュリティメカニズムは実装に固有のものですが、マニフェストを使用して、安全なブートプロセスを強化することに加えて、インターネットからのファームウェアのダウンロードを制御することができます。これらのビルディングブロックは、マニフェストのデザインと非常に関連性があります。

 

9.例

次のメッセージフローの例は、作成者が新しいファームウェアをファームウェアサーバーにアップロードし、マニフェストを作成することから始めて、ファームウェアイメージをデバイスに配布するための考えられる対話を示しています。ファームウェアとマニフェストは同じファームウェアサーバーに格納されています。

 

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

 

10. IANAに関して

このドキュメントはIANAによるアクションを必要としません。

 

11.セキュリティ上の考慮事項

ファームウェアのアップデートはセキュリティの脆弱性を修正し、IoTデバイスをセキュリティで保護するための重要な構成要素であると考えられています。 IoTデバイスのファームウェアアップデートの重要性に鑑み、インターネットアーキテクチャ委員会(IAB)はその全体像を見るために2016年6月13日と14日にアイルランドのトリニティカレッジダブリンにて「モノのインターネットワークショップ(IoT)ソフトウェアアップデート(IOTSU)」を開催しました。このワークショップに関する報告は[RFC8240]にあります。ファームウェアの製作者からデバイスまでのエンドツーエンドのセキュリティを提供する標準化されたファームウェアマニフェストのフォーマットは、別の文書で指定されます。
ただし、ワークショップでは他にも多くの考慮事項があります。それらの多くは、製品エンジニアリング、規制の枠組み、およびビジネスモデルの分野に属し、標準化組織のスコープ外です。以下の考慮事項は、この文書のスコープ外です。

– ファームウェアのアップデートを堅牢な方法でインストールして、アップデートによってこのデバイスが動作する環境のデバイス機能が損なわれないようにする
– デバイスをアップデートする意思決定プロセスの複雑さ、再認証要件の可能性、およびアップデートをインストールするためのユーザーの同意の必要性を考慮して、ファームウェアアップデートをタイムリーにインストールする
– 実際のファームウェアアップデートの配布。潜在的には人手を介さずに多数のデバイスに効率的な方法で配布
– エネルギー効率と電池寿命の考察
– マニフェストを保護するデジタル署名を検証するために必要な鍵管理
– 製造業者がIoT製品の一部としてファームウェアアップデートメカニズムを提供する動機

 

12. メーリングリスト情報

<省略>

13. 謝辞

<省略>

14. 参照

<省略>