IoTデバイス向けファームウェア更新の情報モデル(仮翻訳)

この資料は、“An Information Model for Firmware Updates in IoT Devices” (draft-ietf-suit-information-model-07)の日本語仮翻訳です。

概要

モノのインターネット(IoT)のデバイスサイドにもいくつもの脆弱性が知られ、資源制約の強いデバイスサイドにも適した強固で安全なファームウェア更新メカニズムの必要性が高まっています。デバイスが機能し、耐用年数にわたって安全であることを保証するには、脆弱性を修正し、構成設定を更新し、新しい機能を追加するための更新メカニズムなどが必要とされています。

このようなファームウェア更新のためのコンポーネントの一つが、ファームウェアイメージを記述し、適切な保護を提供する、簡潔で機械処理可能なメタデータドキュメントまたはマニフェストです。このドキュメントでは、そのマニフェストに存在しなければならない情報について説明します。

本ドキュメントのステータス

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

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

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

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

著作権表示

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.規則と用語
 2.1.要件表記
3.マニフェスト情報要素
 3.1.マニフェスト要素:マニフェスト構造のバージョンID
 3.2.マニフェスト要素:単調増加のシーケンス番号
 3.3.マニフェスト要素:ベンダーID
  3.3.1.例:ドメイン名ベースのUUID
 3.4.マニフェスト要素:クラスID
  3.4.1.例1:異なるクラス
  3.4.2.例2:クラスIDのアップグレード
  3.4.3.例3:共有機能
  3.4.4.例4:ホワイトラベリング
 3.5.マニフェスト要素:プリカーサイメージダイジェスト条件
 3.6.マニフェスト要素:必須イメージバージョンリスト
 3.7.マニフェスト要素:有効期限
 3.8.マニフェスト要素:ペイロード形式
 3.9. マニフェスト要素:処理ステップ
 3.10.マニフェスト要素:保管場所
  3.10.1.例1:2つの保管場所
  3.10.2.例2:ファイルシステム
  3.10.3.例3:フラッシュメモリ
 3.11.マニフェスト要素:コンポーネント識別子
 3.12.マニフェスト要素:リソースインジケーター
 3.13.マニフェスト要素:ペイロードダイジェスト
 3.14.マニフェスト要素:サイズ
 3.15.マニフェスト要素:署名
 3.16.マニフェスト要素:追加のインストール手順
 3.17.マニフェスト要素:エイリアス
 3.18.マニフェスト要素:依存関係
 3.19.マニフェスト要素:暗号化ラッパー
 3.20.マニフェスト要素:XIPアドレス
 3.21.マニフェスト要素:ロード時のメタデータ
 3.22.マニフェスト要素:実行時メタデータ
 3.23.マニフェスト要素:ペイロード
 3.24.マニフェスト要素:鍵クレーム
4.セキュリティに関する考慮事項
 4.1.脅威モデル
 4.2.脅威の説明
  4.2.1. THREAT.IMG.EXPIRED:古いファームウェア
  4.2.2. THREAT.IMG.EXPIRED.ROLLBACK:オフラインデバイス+古いファームウェア
  4.2.3. THREAT.IMG.INCOMPATIBLE:ファームウェアのミスマッチ
  4.2.4. THREAT.IMG.FORMAT:ターゲットデバイスがペイロードのタイプを誤って解釈
  4.2.5. THREAT.IMG.LOCATION:ターゲットデバイスが誤った場所にペイロードをインストール
  4.2.6. THREAT.NET.REDIRECT:認証されていないペイロードホスティングへのリダイレクト
  4.2.7. THREAT.NET.MITM:トラフィック傍受
  4.2.8. THREAT.IMG.REPLACE:ペイロードの交換
  4.2.9. THREAT.IMG.NON_AUTH:認証されていないイメージ
  4.2.10. THREAT.UPD.WRONG_PRECURSOR:予期しないプリカーサイメージ
  4.2.11. THREAT.UPD.UNAPPROVED:未承認のファームウェア
  4.2.12. THREAT.IMG.DISCLOSURE:脆弱性分析のためのファームウェアイメージのリバースエンジニアリング
  4.2.13. THREAT.MFST.OVERRIDE:重要なマニフェスト要素の上書き
  4.2.14. THREAT.MFST.EXPOSURE:機密マニフェスト要素の露出
  4.2.15. THREAT.IMG.EXTRA:イメージ後の追加データ
  4.2.16. THREAT.KEY.EXPOSURE:署名鍵の公開
  4.2.17. THREAT.MFST.MODIFICATION:署名前のマニフェストまたはペイロードの変更
  4.2.18. THREAT.MFST.TOCTOU:認証から使用までの間のマニフェストの変更
 4.3. セキュリティ要件
  4.3.1. REQ.SEC.SEQUENCE:単調なシーケンス番号
  4.3.2. REQ.SEC.COMPATIBLE:ベンダー、デバイスタイプ識別子
  4.3.3. REQ.SEC.EXP:有効期限
  4.3.4. REQ.SEC.AUTHENTIC:暗号の信頼性
  4.3.5. REQ.SEC.AUTH.IMG_TYPE:認証済みペイロードタイプ
  4.3.6. REQ.SEC.AUTH.IMG_LOC:認証された保管場所
  4.3.7. REQ.SEC.AUTH.REMOTE_LOC:認証されたリモートリソースの場所
  4.3.8. REQ.SEC.AUTH.EXEC:安全な実行
  4.3.9. REQ.SEC.AUTH.PRECURSOR:認証されたプリカーサイメージ
  4.3.10. REQ.SEC.AUTH.COMPATIBILITY:認証されたベンダーおよびクラスID
  4.3.11. REQ.SEC.RIGHTS:権限には真正性が必要
  4.3.12. REQ.SEC.IMG.CONFIDENTIALITY:ペイロードの暗号化 
  4.3.13. REQ.SEC.ACCESS_CONTROL:アクセス制御
  4.3.14. REQ.SEC.MFST.CONFIDENTIALITY:暗号化されたマニフェスト
  4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST:イメージ全体のダイジェスト
  4.3.16. REQ.SEC.REPORTING:安全なレポート
  4.3.17. REQ.SEC.KEY.PROTECTION:署名鍵の保護されたストレージ
  4.3.18. REQ.SEC.MFST.CHECK:展開前にマニフェストを検証する
  4.3.19. REQ.SEC.MFST.TRUSTED:信頼できる環境でマニフェストを構築
  4.3.20. REQ.SEC.MFST.CONST:マニフェストはチェックから使用までの間に変わってはならない
 4.4. ユーザーストーリー
  4.4.1. USER_STORY.INSTALL.INSTRUCTIONS:インストール手順
  4.4.2. USER_STORY.MFST.FAIL_EARLY:早期に失敗
  4.4.3. USER_STORY.OVERRIDE:重要でないマニフェストを上書き
  4.4.4. USER_STORY.COMPONENT:コンポーネントの更新
  4.4.5. USER_STORY.MULTI_AUTH:複数の承認
  4.4.6. USER_STORY.IMG.FORMAT:複数のペイロード形式
  4.4.7. USER_STORY.IMG.CONFIDENTIALITY:機密情報の開示防止
  4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT:不明なフォーマットのアンパックからデバイスを保護
  4.4.9. USER_STORY.IMG.CURRENT_VERSION:対象ファームウェアのバージョン番号の指定
  4.4.10. USER_STORY.IMG.SELECT:デバイスがイメージを選択できるようにする
  4.4.11. USER_STORY.EXEC.MFST:マニフェストを使用した安全な実行
  4.4.12. USER_STORY.EXEC.DECOMPRESS:ロード時に解凍
  4.4.13. USER_STORY.MFST.IMG:マニフェストのペイロード
  4.4.14. USER_STORY.MFST.PARSE:単純な解析
  4.4.15. USER_STORY.MFST.DELEGATION:マニフェストで委任された権限
  4.4.16. USER_STORY.MFST.PRE_CHECK:評価を更新
 4.5. ユーザビリティ要件
  4.5.1. REQ.USE.MFST.PRE_CHECK:インストール前のチェック
  4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE:リモートリソースの場所を上書き
  4.5.3. REQ.USE.MFST.COMPONENT:コンポーネントの更新
  4.5.4. REQ.USE.MFST.MULTI_AUTH:複数の認証
  4.5.5. REQ.USE.IMG.FORMAT:フォーマットの使いやすさ
  4.5.6. REQ.USE.IMG.NESTED:ネストされたフォーマット
  4.5.7. REQ.USE.IMG.VERSIONS:ターゲットバージョンの一致
  4.5.8. REQ.USE.IMG.SELECT:宛先によるイメージの選択
  4.5.9. REQ.USE.EXEC:実行可能マニフェスト
  4.5.10. REQ.USE.LOAD:ロード時の情報
  4.5.11. REQ.USE.PAYLOAD:マニフェストスーパーストラクチャーのペイロード
  4.5.12. REQ.USE.PARSE:シンプルな解析
  4.5.13. REQ.USE.DELEGATION:マニフェストでの権限の委任
5. IANAの考慮事項
6.謝辞
7.参考資料
 7.1.引用規格
 7.2.参考文献
著者のアドレス

1. はじめに

情報モデルは、セクション4.1で説明した脅威からIoTデバイスのファームウェア更新を保護するために必要なすべての情報要素を説明し、セクション4.4でキャプチャされたユーザーストーリーを有効にします。これらの脅威とユーザーストーリーは、IoTデバイスに対する脅威の完全なリストではなく、ファームウェア更新の実行方法を説明する起こり得るユーザーストーリーでもありません。代わりに、ファームウェア更新に対する脅威を個別に説明し、幅広いユーザーストーリーをカバーする情報要素を指定するための十分なモチベーションを提供することを目的としています。情報モデルは、情報要素のシリアル化、エンコード、順序付け、または構造を定義せず、それらのセマンティクスのみを定義します。

情報モデルは幅広いユーザーストーリーと幅広い脅威を対象としているため、すべての情報要素がすべてのシナリオに適用されるわけではありません。その結果、アプリケーションの特定のドメインに存在する脅威と必要なユーザーストーリーに応じて、さまざまな情報要素が実装のオプションとして、使用もオプションと考えることができます。REQUIREDとマークされた要素は、ほとんどのアプリケーションで必要とされることが予想されるベースラインのセキュリティおよびユーザビリティプロパティを提供します。これらの要素は、実装され使われる必要があります。RECOMMENDEDとしてマークされた要素は、ほとんどのデバイスで必要とされる重要なセキュリティまたはユーザビリティプロパティを提供します。 OPTIONとしてマークされた要素は、一部のアプリケーションで役立つセキュリティまたはユーザビリティプロパティを有効にします。

一部の情報要素の定義には、それらのセマンティクスと使用方法を示す例が含まれています。

 

2. 規約と用語

このドキュメントでは、[I-D.ietf-suit-architecture]で定義されている用語を使用しています。「オペレーター」という用語は、デバイスとネットワークオペレーターの両方を指します。

このドキュメントでは、同種のストレージアーキテクチャを持つデバイスを、1つのストレージサブシステムだけの異種のストレージアーキテクチャを持つデバイスとして扱います。

2.1. 要件表記

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL このドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. マニフェストの情報要素

各マニフェスト情報要素は、あるセキュリティ要件またはあるユーザビリティ要件に固定されています。マニフェスト要素については、条件付きで以下に説明します。

3.1. マニフェスト要素:マニフェスト構造のバージョンID

構造体に含まれているマニフェスト形式の反復を説明する識別子。

この要素は必須であり、デバイスが使用中のマニフェストデータモデルのバージョンを識別できるよう必要です。

3.2. マニフェスト要素:単調増加のシーケンス番号

単調に増加するシーケンス番号。便宜上、単調なシーケンス番号はUTCタイムスタンプである場合があります。これにより、追加の管理なしでシーケンス番号のグローバル同期が可能になります。複数のマニフェストから1つを選択するコードが最新のものを選択できるように、この番号は簡単にアクセスできる必要があります。

この要素は必須であり、悪意のあるアクターが関連機関のポリシーに照らしてファームウェアの更新を元に戻すのを防ぐために必要です。

実装:REQ.SEC.SEQUENCE(セクション4.3.1)

3.3. マニフェスト要素:ベンダーID

ベンダーIDは一意である必要があります。これは、異なる地理的地域にある類似または同一の名前のエンティティが顧客のインフラストラクチャで衝突するのを防ぐためです。 [RFC4122]バージョン5のUUIDとベンダーのドメイン名およびDNSネームスペースIDを使用することをお勧めします。その他のオプションには、タイプ1およびタイプ4のUUIDがあります。

ベンダーIDは、人間が読み取れる要素を意図したものではありません。バイナリの一致/不一致の比較のみを目的としています。

ベンダーIDの使用をお勧めします。異なるベンダーの同じ名前の製品を区別するのに役立ちます。

実装:REQ.SEC.COMPATIBLE(セクション4.3.2)、REQ.SEC.AUTH.COMPATIBILITY(セクション4.3.10)。

3.3.1. 例:ドメイン名ベースのUUID

ベンダーAは、ドメイン名に基づいてUUIDを作成します。

vendorId = UUID5(DNS, “vendor-a.com”)

DNSインフラストラクチャは同じドメイン名の複数の登録を防ぐため、このUUIDは(非常に高い確率で)一意であることが保証されています。ドメイン名がわかっているため、このUUIDは再現可能です。タイプ1とタイプ4のUUIDは、同様の一意性を保証しますが、再現性は保証しません。

このアプローチでは、ベンダーが名前を変更したり、ドメイン名の制御を放棄したりすると、競合が発生します。このシナリオでは、別のベンダーが同じドメイン名の使用を開始する可能性があります。ただし、このUUIDはIDの証明ではありません。ベンダーに対するデバイスの信頼は、UUIDではなく暗号化鍵に固定する必要があります。

3.4. マニフェスト要素:クラスID

デバイス「クラス」は、変更なしで同じファームウェアアップデートを受け入れることができる、さまざまなデバイスタイプのセットです。クラスIDは、ベンダーIDのスコープ内で一意である必要があります。これは、顧客のインフラストラクチャ内で同種または同名のデバイスが衝突するのを防ぐためです。

ファームウェアの互換性を定義するために必要なだけの情報を持つ[RFC4122]バージョン5 UUIDを使用することをお勧めします。クラスUUIDの導出に使用される可能性のある情報には、次のものがあります。

oモデル名または番号
oハードウェアリビジョン
oランタイムライブラリのバージョン
oブートローダーのバージョン
o ROMリビジョン
oシリコンバッチ番号

クラス識別子UUIDは、ベンダーIDを名前空間IDとして使用する必要があります(SHOULD)。その他のオプションには、バージョン1および4のUUIDがあります。クラスは、ファームウェアの互換性を識別するために必要なものよりも細かくすることができます。クラスは、ファームウェアの互換性を識別するために必要なものよりも細かくしてはいけません。デバイスは複数のクラスIDを持つ場合があります。

クラスIDは、人間が読み取れる要素を意図したものではありません。バイナリの一致/不一致の比較のみを目的としています。

クラスIDの使用をお勧めします。これにより、デバイスはファームウェアの適用性を明確な方法で決定できます。

クラスIDが実装されていない場合、各論理デバイスクラスは、承認のために一意のトラストアンカーを使用する必要があります。

実装:セキュリティ要件REQ.SEC.COMPATIBLE(セクション4.3.2)、REQ.SEC.AUTH.COMPATIBILITY(セクション4.3.10)。

3.4.1. 例1:異なるクラス

ベンダーAが製品Zと製品Yを作成します。製品ZとYのファームウェアイメージは交換できません。ベンダーAは、次のようにUUIDを作成します。

o vendorId = UUID5(DNS, “vendor-a.com”)
o ZclassId = UUID5(vendorId, “製品Z”)
o YclassId = UUID5(vendorId, “製品Y”)

これにより、ベンダーAの製品Zは製品Yのファームウェアをインストールできず、製品Yは製品Zのファームウェアをインストールできません。

3.4.2. 例2:クラスIDのアップグレード

ベンダーAは製品Xを作成します。その後、ベンダーAは製品Xに新機能を追加し、製品X v2を作成します。製品Xは、製品X v2向けのファームウェアを使用するためにファームウェアの更新が必要です。
ベンダーAは、次のようにUUIDを作成します。

o vendorId = UUID5(DNS, “vendor-a.com”)
o XclassId = UUID5(vendorId, “製品X”)
o Xv2classId = UUID5(vendorId, “製品X v2″)

製品Xが製品X v2との互換性を確保するために必要なファームウェアアップデートを受信すると、ファームウェアアップデートの一部がクラスIDをXv2classIdに変更します。

3.4.3. 例3:共有機能

ベンダーAは、製品Xと製品Yの2つの製品を製造しています。これらのコンポーネントは、共通のコア(オペレーティングシステムなど)を共有していますが、アプリケーションは異なります。共通コアとアプリケーションは個別に更新できます。 XとYが同じ共通コアアップデートを受信できるようにするには、同じクラスIDが必要です。製品XだけがアプリケーションXを受け取り、製品YだけがアプリケーションYを受け取るようにするには、製品Xと製品Yに異なるクラスIDが必要です。ベンダーは、次のようにクラスIDを作成します。

o vendorId = UUID5(DNS, “vendor-a.com”)
o XclassId = UUID5(vendorId, “製品X”)
o YclassId = UUID5(vendorId, “製品Y”)
o CommonClassId = UUID5(vendorId、 “共有コア “)

製品Xは、XclassIdとCommonClassIdの両方に対して一致します。製品Yは、YclassIdとCommonClassIdの両方に対して一致します。

3.4.4. 例4:ホワイトラベリング

ベンダーAが製品Aとそのファームウェアを作成します。ベンダーBは、独自の名前で製品Bとして製品を販売しており、カスタマイズされた構成がいくつかあります。ベンダーは、次のようにクラスIDを作成します。

o vendorIdA = UUID5(DNS、 “vendor-a.com”)
o classIdA = UUID5(vendorIdA、 “製品A-ラベルなし”)
o vendorIdB = UUID5(DNS、 “vendor-b.com”)
o classIdB = UUID5(vendorIdB、 “製品B”)

製品は、これらのクラスIDのそれぞれと照合されます。ベンダーAとベンダーBがデバイスに異なるコンポーネントを提供する場合、実装者は、IDマッチングのスコープを各コンポーネントに設定することを選択できます(MAY)。次に、vendorIdA、classIdAはベンダーAによって提供されるコンポーネントIDと一致し、vendorIdB、classIdBはベンダーBによって提供されるコンポーネントIDと一致します。

3.5. マニフェスト要素:プリカーサイメージダイジェスト条件

ペイロード形式でプリカーサイメージが必要な場合、プリカーサイメージのダイジェスト条件が条件リストに存在する必要があります(MUST)。プリカーサイメージは、インストールされていても候補として保存されていても構いません。

この要素はオプションで実装できます。

機能:差分更新

実装:REQ.SEC.AUTH.PRECURSOR(セクション4.3.9)

3.6. マニフェスト要素:必須イメージバージョンリスト

ペイロードがファームウェアの複数のバージョンに適用される場合、必須イメージバージョンリストは、更新を適用するためにどのバージョンが存在しなければならないかを指定します。これにより、アップデートの作成者は、特定のバージョンのファームウェアをアップデートの対象にすることができ、適用すべきでないファームウェアは除外されます。

更新を特定の先行バージョンにのみ適用できる場合、そのバージョンは必須イメージバージョンリストで指定する必要があります。

この要素はオプションです。

実装:REQ.USE.IMG.VERSIONS(セクション4.5.7)

3.7. マニフェスト要素:有効期限

この要素は、マニフェストが期限切れになり、使用されなくなる時刻をデバイスに通知します。これは、時間の安全なソースと組み合わせてのみ使用できます。

この要素はオプションであり、安全な時間のソースが提供され、ファームウェアが予想どおりに期限切れになることが意図されているユーザーストーリーを有効にする場合があります。

実装:REQ.SEC.EXP(セクション4.3.3)

3.8. マニフェスト要素:ペイロード形式

ペイロードの形式は、明確な方法でデバイスに示す必要があります。この要素は、署名されたメタデータ内のペイロード形式を説明するメカニズムを提供します。

この要素は必須であり、デバイスがペイロードを正しくデコードできるようにするために存在する必要があります。

実装:REQ.SEC.AUTH.IMG_TYPE(セクション4.3.5)、REQ.USE.IMG.FORMAT(セクション4.5.5)

3.9. マニフェスト要素:処理ステップ

ペイロードのデコードに必要な処理ステップの表現。表現は、使用されるアルゴリズムと、アルゴリズムに必要な追加のパラメーターを記述しなければなりません(MUST)。表現は、事前定義された組み合わせで処理ステップをグループ化する場合があります。

処理ステップは、処理が完了した後に予想されるペイロードのダイジェストを示す場合があります。

処理ステップを実装することをお勧めします。

機能:暗号化、圧縮、パックされたフォーマット

実装:REQ.USE.IMG.NESTED(セクション4.5.6)

3.10. マニフェスト要素:保管場所

この要素は、特定のコンポーネント内のペイロードを格納する場所をデバイスに通知します。デバイスはこれを使用して、必要なアクセス許可と使用する物理ストレージの場所を確立できます。

この要素は必須であり、デバイスがペイロードを正しい場所に格納できるようにするために存在する必要があります。

実装:REQ.SEC.AUTH.IMG_LOC(セクション4.3.6)

3.10.1. 例1:2つの保管場所

デバイスは、OSとアプリケーションの2つのコンポーネントをサポートします。これらのコンポーネントは個別に更新でき、依存関係を表現してコンポーネント間の互換性を確保します。作成者は2つのストレージ識別子を選択します。

o “OS”
o ”APP”

3.10.2. 例2:ファイルシステム

デバイスは完全なファイルシステムをサポートします。作成者は、ペイロードをインストールするパスとしてストレージ識別子を使用することを選択します。ペイロードはtarballである場合があります。その場合、指定されたパスにtarballが解凍されます。

3.10.3. 例3:フラッシュメモリ

デバイスはフラッシュメモリをサポートしています。作成者は、ストレージ識別子を、イメージを書き込む必要があるオフセットにすることを選択します。

3.11. マニフェスト要素:コンポーネント識別子

異機種混在ストレージアーキテクチャでは、ペイロードを格納する場所と方法を識別するにはストレージ識別子では不十分です。これを解決するために、コンポーネント識別子は、ストレージアーキテクチャのどの部分がペイロードによってターゲットにされているかを示します。同種ストレージアーキテクチャでは、この要素は不要です。

この要素はオプションであり、異種ストレージアーキテクチャデバイスでのみ必要です。

注意:マニフェストフォーマットは、コンポーネント識別子と保管場所の組み合わせを選択してもよい(セクション3.10)

実装:REQ.USE.MFST.COMPONENT(セクション4.5.3)

3.12. マニフェスト要素:リソースインジケーター

この要素は、デバイスがリソースを取得するために必要な情報を提供します。これはいくつかの方法でエンコードできます:

o 1つのURI
o URIのリスト
o URIの優先リスト
o署名されたURIのリスト

この要素はオプションであり、ターゲットデバイスがペイロードの場所を本質的に認識していない場合にのみ必要です。

注意:通常、デバイスにはURIが必要です。

実装:REQ.SEC.AUTH.REMOTE_LOC(セクション4.3.7)

3.13. マニフェスト要素:ペイロードダイジェスト

この要素には、1つ以上のペイロードの1つ以上のダイジェストが含まれています。これにより、ターゲットデバイスはペイロードの信頼性を確保できます。マニフェストフォーマットは、インプレース実行インストールアドレスなどのシステムパラメーターに基づいてリストから1つのペイロードを選択するメカニズムを提供する必要があります。

この要素は実装する必要があり、ペイロードの信頼性と整合性を保証するために基本的に必要です。複数のダイジェストのサポートは、受信デバイスに実装するオプションです。

実装:REQ.SEC.AUTHENTIC(セクション4.3.4)、REQ.USE.IMG.SELECT(セクション4.5.8)

3.14. マニフェスト要素:サイズ

ペイロードのサイズ(バイト単位)。

可変サイズの格納場所は、この要素にリストされているサイズに正確に設定する必要があります。

この要素は必須であり、予想されるペイロードの大きさをターゲットデバイスに通知します。これがなければ、デバイスはいくつかのクラスのサービス拒否攻撃にさらされてしまいます。

実装:REQ.SEC.AUTH.EXEC(セクション4.3.8)

3.15. マニフェスト要素:署名

これは厳密にはマニフェスト要素ではありません。代わりに、マニフェストは標準化された認証コンテナーによってラップされます。認証コンテナは、複数のアクターと複数の署名アルゴリズムをサポートする必要があります。

この要素は非依存マニフェストで必須であり、マニフェストのすべてのセキュリティプロパティの基盤を表します。別のマニフェストによって依存関係として含まれているマニフェストには、受信者が異なる権限を持つ異なるアクターを区別できるように、署名を含める必要があります。

マニフェストにチャネル情報(URIなど)のみが含まれている場合でも、マニフェストはチャネルセキュリティによって認証されたものと見なしてはなりません(MUST NOT)。認証されたリモートまたはチャネルが侵害された場合、攻撃者はアクセス可能なネットワークを介してトラフィックをクエリするように受信者を誘導する可能性があります。既存の関係を持つ軽量認証は、MACで行う必要があります。

実装:REQ.SEC.AUTHENTIC(セクション4.3.4)、REQ.SEC.RIGHTS(セクション4.3.11)、REQ.USE.MFST.MULTI_AUTH(セクション4.5.4)

3.16. マニフェスト要素:追加のインストール手順

マニフェストを処理するときにデバイスが実行する必要がある命令。この情報は、ペイロードの処理に必要な情報とは異なります。追加のインストール手順には、更新のタイミング(たとえば、日曜日の02:00にのみインストールする)、手順上の考慮事項(たとえば、制御下の機器をシャットダウンする)などの情報が含まれます。
この要素はオプションです。

実装:REQ.USE.MFST.PRE_CHECK(セクション4.5.1)

3.17. マニフェスト要素:エイリアス

マニフェストが1つ以上の依存関係によって定義されたURIまたはURIリストを拡張または置換するためのメカニズム。

この要素はオプションであり、一部のユーザーストーリーを有効にします。

実装:REQ.USE.MFST.OVERRIDE_REMOTE(セクション4.5.2)

3.18. マニフェスト要素:依存関係

現在のマニフェストで必要な他のマニフェストのリスト。マニフェストは、ダイジェストなどの明確な方法で識別されます。

この要素は、複数の機関と複数のペイロードの両方を含む展開で使用する必要があります。

実装:REQ.USE.MFST.COMPONENT(セクション4.5.3)

3.19. マニフェスト要素:暗号化ラッパー

ファームウェアイメージの暗号化には、対称コンテンツ暗号鍵が必要です。暗号化ラッパーは、デバイスがファームウェアの復号化に使用する鍵を取得または検索するために必要な情報を提供します。これは、処理ステップ(セクション3.9)に含まれる復号化ステップに含めることができます(MAY)。

この要素は、暗号化されたペイロードに使用する必要があります。

実装:REQ.SEC.IMG.CONFIDENTIALITY(セクション4.3.12)

3.20. マニフェスト要素:XIPアドレス

複数の可能なベースアドレスを持つXIPシステムをサポートするには、ペイロードがリンクされるアドレスを指定する必要があります。

たとえば、マイクロコントローラーには、起動する2つのイメージの1つを選択する単純なブートローダーがある場合があります。そのマイクロコントローラーは、2つのファームウェアイメージのどちらが古いかに基づいて、インストールする2つのファームウェアイメージのいずれかを選択する必要があります。

実装:REQ.USE.IMG.SELECT(セクション4.5.8)

3.21. マニフェスト要素:読み込み時のメタデータ

ロード時メタデータは、1つ以上のイメージをロードするために必要な情報をデバイスに提供します。これは、イメージの永続的な保存場所からそのイメージのアクティブな使用場所へのコピー操作です。メタデータには、イメージのソースと宛先、およびイメージに対して実行される操作が含まれています。

実装:REQ.USE.LOAD(セクション4.5.10)

3.22. マニフェスト要素:実行時メタデータ

ランタイムメタデータは、デバイスの起動に必要な追加情報をデバイスに提供します。これには、XIPイメージのエントリポイントやLinuxイメージのカーネルコマンドラインなどの情報が含まれる場合があります。

実装:REQ.USE.EXEC(セクション4.5.9)

3.23. マニフェスト要素:ペイロード

ペイロードは、マニフェスト上部構造内に含まれるペイロード全体を受信デバイスに提供します。これにより、マニフェストとペイロードを同時に配信できます。

実装:REQ.USE.PAYLOAD(セクション4.5.11)

3.24. マニフェスト要素:鍵クレーム

鍵クレーム要素は、署名(セクション3.15)では認証されません。代わりに、信頼できる鍵を使用してマニフェストを認証した鍵を検証するために、デバイスが従う鍵の委任(またはそれらへの参照)のチェーンを提供します。

実装:REQ.USE.DELEGATION(セクション4.5.13)

4. セキュリティに関する考慮事項

次のサブセクションでは、脅威モデル、ユーザーストーリー、セキュリティ要件、およびユーザビリティ要件について説明します。このセクションでは、各マニフェスト情報要素の動機も提供します。

4.1. 脅威モデル

以下のサブセクションでは、考慮された脅威、それらの脅威から派生したセキュリティ要件、およびセキュリティ要件の実装を許可するフィールドについての情報を提供することを目的としています。このモデルはS.T.R.I.D.E. [STRIDE]アプローチを使用し、各脅威は次のように分類されます。

oなりすまし
oデータの改ざん
o否認
o情報開示
oサービス拒否
o特権の昇格

この脅威モデルは、ファームウェアアップデートの転送に関連する要素のみを対象としています。ファームウェア更新の転送以外の脅威は明示的にカバーしていません。たとえば、物理的なアクセスによるIoTデバイスへの脅威は対象外です。

4.2. 脅威の説明

4.2.1. THREAT.IMG.EXPIRED:古いファームウェア

分類:特権の昇格

攻撃者は、古いが有効なファームウェアイメージを含む古いが有効なマニフェストをデバイスに送信します。提供されているファームウェアイメージに既知の脆弱性がある場合、攻撃者がこの脆弱性を悪用してデバイスを制御する可能性があります。

脅威のエスカレーション:攻撃者が既知の脆弱性を悪用できる場合、この脅威はすべてのタイプにエスカレーションされる可能性があります。

軽減:REQ.SEC.SEQUENCE(セクション4.3.1)

4.2.2. THREAT.IMG.EXPIRED.ROLLBACK:オフラインデバイス+古いファームウェア

分類:特権の昇格

攻撃者は、長期間オフラインであり、古いファームウェアバージョンを実行しているデバイスをターゲットにします。攻撃者は、古いが有効なファームウェアイメージを持つデバイスに、古いが有効なマニフェストを送信します。攻撃者が提供するこのファームウェアは、インストールされているファームウェアよりも新しいが、最近利用可能なファームウェアよりも古いものです。提供されたファームウェアイメージに既知の脆弱性がある場合、攻撃者がデバイスを制御できる可能性があります。デバイスは長期間オフラインになっているため、新しい更新を認識しません。そのため、古いマニフェストを最新のものとして扱います。

脅威のエスカレーション:攻撃者が既知の脆弱性を悪用できる場合、この脅威はすべてのタイプにエスカレーションされる可能性があります。

軽減:REQ.SEC.EXP(セクション4.3.3)

4.2.3. THREAT.IMG.INCOMPATIBLE:ファームウェアのミスマッチ

分類:サービス拒否

攻撃者は、有効なファームウェアイメージを間違ったタイプのデバイス用に送信します。どちらのタイプのデバイスにもファームウェアのインストール許可を持つアクターが署名したものです。ファームウェアは、適切な権限を持つアクターによって署名されているため、デバイスによって肯定的に検証されます。これは広範囲にわたる結果をもたらす可能性があります。類似のデバイスの場合、軽微な破損を引き起こしたり、セキュリティの脆弱性を露出させてしまう可能性があります。全く違うデバイスの場合、デバイスが動作不能になる可能性があります。

軽減:REQ.SEC.COMPATIBLE(セクション4.3.2)

4.2.3.1. 例:

2つのベンダー、ベンダーAとベンダーBが異なる所在地で同じ商号を採用し、両方が同じ名前の製品を製造している、または製品名の一致が使用されていないとします。これにより、ベンダーAのファームウェアがベンダーBのデバイスと一致します。

これらのベンダーがファームウェア機関である場合、ベンダーAのデバイスは、異なる資格情報を使用するため、ベンダーBによって署名されたイメージを拒否します。ただし、両方のデバイスが同じ作成者を信頼している場合、ベンダーAのデバイスはベンダーBのデバイス向けのファームウェアをインストールできてしまいます。

4.2.4. THREAT.IMG.FORMAT:ターゲットデバイスがペイロードのタイプを誤って解釈

分類:サービス拒否

デバイスがファームウェアイメージのフォーマットを誤って解釈すると、デバイスがファームウェアイメージを誤ってインストールする可能性があります。正しくインストールされていないファームウェアイメージは、デバイスの機能を停止させる可能性があります。

脅威のエスカレーション:受信したファームウェアイメージをデバイスに誤って解釈させる攻撃者は、特権の昇格を取得し、これを潜在的にすべてのタイプの脅威に拡大する可能性があります。

軽減:REQ.SEC.AUTH.IMG_TYPE(セクション4.3.5)

4.2.5. THREAT.IMG.LOCATION:ターゲットデバイスが誤った場所にペイロードをインストール

分類:サービス拒否

デバイスがファームウェアイメージをデバイス上の間違った場所にインストールすると、壊れる可能性があります。たとえば、アプリケーションとしてインストールされたファームウェアイメージは、デバイスやアプリケーションの機能を停止させる可能性があります。

脅威のエスカレーション:デバイスが受信したコードを誤って解釈する可能性のある攻撃者は、特権の昇格を取得し、これを潜在的にすべてのタイプの脅威に拡大する可能性があります。

軽減:REQ.SEC.AUTH.IMG_LOC(セクション4.3.6)

4.2.6. THREAT.NET.REDIRECT:認証されていないペイロードホスティングへのリダイレクト

分類:サービス拒否

デバイスが更新のペイロードを取得する場所を知らない場合、攻撃者のサーバーにリダイレクトされる可能性があります。これにより、攻撃者は壊れたペイロードをデバイスに提供することができてしまいます。

軽減:REQ.SEC.AUTH.REMOTE_LOC(セクション4.3.7)

4.2.7. THREAT.NET.MITM:トラフィックの傍受

分類:なりすまし、データの改ざん

攻撃者は、デバイスとの間のすべてのトラフィックを傍受します。攻撃者は、デバイスとの間で送受信されるデータを監視または変更できます。これは、マニフェスト、ペイロード、ステータスレポート、および機能レポートが変更されるか、意図された受信者に配信されないという形をとります。また、コンテンツ、サイズ、または頻度のいずれかで、デバイスとの間で送受信されるデータの分析の形式を取ることもできます。

軽減:REQ.SEC.AUTHENTIC(セクション4.3.4)、REQ.SEC.IMG.CONFIDENTIALITY(セクション4.3.12)、REQ.SEC.AUTH.REMOTE_LOC(セクション4.3.7)、REQ.SEC.MFST.CONFIDENTIALITY (セクション4.3.14)、REQ.SEC.REPORTING(セクション4.3.16)

4.2.8. THREAT.IMG.REPLACE:ペイロードの交換

分類:特権の昇格

デバイスがマニフェストの検証を完了した後、攻撃者は新しくダウンロードされたファームウェアを置き換えます。これにより、デバイスが攻撃者のコードを実行する可能性があります。この攻撃では、デバイスへの物理的なアクセスが必要になる可能性があります。ただし、この攻撃は、リモート実行を可能にする別の脅威と組み合わせて実行される可能性があります。これは、典型的なチェックタイム/使用時間の脅威です。

脅威のエスカレーション:攻撃者が既知の脆弱性を悪用できる場合、または攻撃者が独自のファームウェアを提供できる場合、この脅威はすべてのタイプにエスカレートされる可能性があります。

軽減:REQ.SEC.AUTH.EXEC(セクション4.3.8)

4.2.9. THREAT.IMG.NON_AUTH:認証されていないイメージ

分類:特権の昇格/すべてのタイプ

攻撃者がペイロードまたはメタデータを操作することにより、デバイスにファームウェアをインストールできる場合、攻撃者はデバイスを完全に制御できます。

軽減:REQ.SEC.AUTHENTIC(セクション4.3.4)

4.2.10. THREAT.UPD.WRONG_PRECURSOR:予期しないプリカーサイメージ

分類:サービス拒否/すべてのタイプ

攻撃者は、有効な現在のマニフェストを、予期しないプリカーサイメージを持つデバイスに送信します。ペイロード形式でプリカーサイメージ(たとえば、差分更新)が必要であり、そのプリカーサイメージがターゲットデバイスで使用できない場合、更新が中断する可能性があります。

攻撃者がデバイスに誤ったプリカーサイメージに対してペイロードをインストールさせることにより、特権を昇格させ、これをすべてのタイプの脅威に拡大する可能性があります。ただし、正しくないプリカーサに適用された有効な差分更新が機能するが脆弱なファームウェアになる可能性は低いです。

軽減:REQ.SEC.AUTH.PRECURSOR(セクション4.3.9)

4.2.11. THREAT.UPD.UNAPPROVED:未承認のファームウェア

分類:サービス拒否、特権の昇格

この脅威はいくつかの方法で出現する可能性がありますが、つまるところデバイスが所有者、デバイスオペレーター、またはネットワークオペレーターが必要とする動作をすることを確実にすることです。デバイスの所有者またはオペレーターは、通常、デバイスが特定の特徴、機能、能力、動作、または相互運用性の制約(より一般的には動作)を維持することを要求します。これらの要件が満たされていない場合、デバイスはその目的を果たしません。したがって、デバイスの所有者または所有者が契約しているデバイスオペレーター以外の者が承認なしにデバイスの動作を変更できる場合、これは特権の昇格を構成します。

同様に、ネットワークオペレーターは、ネットワークの整合性を維持するために、デバイスが特定の方法で動作することを要求する場合があります。ネットワーク上のデバイスの動作がネットワークオペレーターの承認なしに変更できる場合、これはネットワークに関する特権の昇格を構成します。

たとえば、特徴A、B、Cが決め手となりデバイスの所有者がそのデバイスを購入し、製造元が特徴Aを削除するファームウェアアップデートを発行した場合、デバイスは所有者の要件を満たさなくなる可能性があります。特定の状況では、これにより非常に大きな脅威が発生する可能性があります。安全性が要求されるシステムを実装するために特徴Aが使用されているとします。 製造元がこの動作を意図していたかどうかは関係ありません。承認されていないファームウェアをインストールすると、システムが安全でなくなる可能性があります。

2番目の例では、2つ以上の相互運用デバイスのシステムの所有者またはオペレーターは、システム内の他のデバイスとの相互運用性を確保するために、システムのファームウェアを承認する必要があります。ファームウェアが適格でない場合、システム全体が動作しない可能性があります。したがって、デバイスの所有者またはオペレーターの承認なしにデバイスがファームウェアをインストールすると、これはデバイスまたはシステム全体に対する脅威になります。

同様に、ネットワークのオペレーターは、ネットワーク内の好ましい動作条件を確保するために、ネットワークに接続されたデバイスのファームウェアを承認する必要がある場合があります。ファームウェアが適格でない場合、ネットワークのパフォーマンスが低下する可能性があります。したがって、ネットワークオペレーターの承認なしにデバイスがファームウェアをインストールすると、これはネットワーク自体への脅威となります。

脅威のエスカレーション:ファームウェアが、ネットワークAに展開されたデバイスに存在するがネットワークBに展開されたデバイスには存在しない構成を想定している場合、デバイスのセキュリティが低下し、すべてのタイプの脅威につながる可能性があります。

軽減:REQ.SEC.RIGHTS(セクション4.3.11)、REQ.SEC.ACCESS_CONTROL(セクション4.3.13)

4.2.11.1. 例1:単一のデバイスオペレーターを持つ複数のネットワークオペレーター

この例では、デバイスオペレーターはファームウェアを作成する権利を要求し、ネットワークオペレーターはネットワーク上での用途に適したファームウェアに限定する権利を要求しています。さらに、デバイスオペレーターは、この例のネットワークAとBを含む、任意のネットワークに展開できるデバイスを管理すると仮定します。

攻撃者はネットワークA上のデバイスのマニフェストを取得する可能性があります。次に、この攻撃者はそのマニフェストをネットワークB上のデバイスに送信します。ネットワークAとネットワークBは異なるオペレーターの制御下にあり、ネットワークA上のデバイスのファームウェアにはネットワークBに展開する資格がないため、オペレーターBのポリシーに違反しており、この適切ではないが署名されたファームウェアによってネットワークBのターゲットデバイスは無効にされてしまう可能性があります。

これは、デバイスを操作不能にする可能性があるため、サービス拒否です。これは、オペレーターが行うべきインストールの決定を攻撃者が行うことができるため、特権の昇格です。

4.2.11.2. 例2:複数のデバイスオペレーターを持つ単一のネットワークオペレーター

相互運用する複数のデバイスが同じネットワークで使用され、相互に通信します。一部のデバイスはデバイスオペレーターAによって製造および管理され、その他のデバイスはデバイスオペレーターBによって製造されています。デバイスオペレーターBのデバイスとの互換性を損なう新しいファームウェアがデバイスオペレーターAによってリリースされています。攻撃者はネットワークオペレータの承認なしにデバイスオペレーターAが管理するデバイスに新しいファームウェアを送信します。これにより、より大きなシステムの動作が中断され、サービス拒否やその他の脅威が引き起こされる可能性があります。ネットワークが分散SCADAシステムである場合、これは制御下にあるプロセスの誤動作を引き起こす可能性があります。

4.2.12. THREAT.IMG.DISCLOSURE:脆弱性分析のためのファームウェアイメージのリバースエンジニアリング

分類:すべてのタイプ

攻撃者は、IoTデバイスに攻撃を仕掛けたいと考えています。 攻撃を準備するには、提供されたファームウェアイメージを取得し、ファームウェアイメージのリバースエンジニアリングを実行して、特定の脆弱性を分析します。

軽減:REQ.SEC.IMG.CONFIDENTIALITY(セクション4.3.12)

4.2.13. THREAT.MFST.OVERRIDE:重要なマニフェスト要素の上書き

分類:特権の昇格

作成者ではないが権限を与えられているアクターが、オーバーライドメカニズム(USER_STORY.OVERRIDE(セクション4.4.3))を使用して、作成者によって署名されたマニフェストの情報要素を変更します。たとえば、権限を与えられているアクターがペイロードのダイジェストとURIを上書きする場合、アクターはペイロード全体を任意のペイロードに置き換えてしまうことができます。

脅威のエスカレーション:ペイロードのインストール手順やファームウェアダイジェストなどの要素を上書きすることにより、この脅威をすべてのタイプにエスカレートできます。

軽減:REQ.SEC.ACCESS_CONTROL(セクション4.3.13)

4.2.14. THREAT.MFST.EXPOSURE:機密のマニフェスト要素の露出

分類:情報開示

第三者がマニフェストから機密情報を抽出できる可能性があります。

軽減:REQ.SEC.MFST.CONFIDENTIALITY(セクション4.3.14)

4.2.15. THREAT.IMG.EXTRA:イメージ後の追加データ

分類:すべてのタイプ

第三者がイメージを変更して、有効で信頼できるイメージの後に追加のコードが含まれるようにした場合、その第三者は既存の脆弱性をさらに活用するために独自のコードを使用できてしまいます。

軽減:REQ.SEC.IMG.COMPLETE_DIGEST(セクション4.3.15)

4.2.16. THREAT.KEY.EXPOSURE:署名鍵の公開

分類:すべてのタイプ

第三者が鍵を取得した場合、またはHSM内などの鍵へ間接的にアクセスした場合、第三者は鍵の正当な所有者と同じアクションを実行できてしまいます。鍵がファームウェア更新用に信頼されている場合、第三者は鍵の正当な所有者であるかのようにファームウェア更新を実行できてしまいます。

たとえば、インターネットに接続されたサーバーでマニフェスト署名が実行された場合、マニフェスト署名の鍵がサーバーからアクセスされるHSMに保持されていても、攻撃者はサーバーを危険にさらし、マニフェストに署名できる可能性があります。

軽減:REQ.SEC.KEY.PROTECTION(セクション4.3.17)

4.2.17. THREAT.MFST.MODIFICATION:署名前のマニフェストまたはペイロードの変更

分類:すべてのタイプ

署名する前にマニフェストまたはペイロードを 攻撃者が変更できた場合、マニフェストの作成者と同じアクションをすべて実行できてしまいます。これにより、攻撃者はマニフェストの作成者を信頼するすべてのデバイスにファームウェアの更新を展開できます。対応するマニフェストが作成される前に攻撃者がペイロードのコードを変更できる場合、攻撃者は独自のコードを挿入できてしまいます。署名される前にマニフェストを攻撃者が変更できる場合、マニフェストを自分のペイロードにリダイレクトできてしまいます。

たとえば、攻撃者は、マニフェスト作成アクティビティを監視し、マニフェストによって参照されるバイナリにコードを挿入する開発者のコンピューターまたは署名サービスにマルウェアを展開します。

たとえば、攻撃者はマルウェアを開発者のコンピューターまたは署名サービスに展開し、参照されているバイナリ(ダイジェスト)とURIを攻撃者のバイナリ(ダイジェスト)とURIに置き換えます。

軽減:REQ.SEC.MFST.CHECK(セクション4.3.18)、REQ.SEC.MFST.TRUSTED(セクション4.3.19)

4.2.18. THREAT.MFST.TOCTOU:認証から使用までの間のマニフェストの変更

分類:すべてのタイプ

マニフェストが認証された後(チェックの時間)、使用される前(使用の時間)に攻撃者がマニフェストを変更できる場合、攻撃者はいかなるコンテンツもマニフェストに配置できてしまいます。

軽減:REQ.SEC.MFST.CONST(セクション4.3.20)

4.3. セキュリティ要件

ここでのセキュリティ要件は、セクション4.1で説明されている脅威を軽減する一連のポリシーです。

4.3.1. REQ.SEC.SEQUENCE:単調なシーケンス番号

ファームウェアのインストール権限を持つアクターのみが、デバイスファームウェアをインストールできる時期を決定できます。このルールを適用するには、マニフェストに単調に増加するシーケンス番号を含める必要があります。マニフェストは、UTCエポックタイムスタンプを使用して、多くの場所にある多くのアクターにわたって単調に増加するシーケンス番号を調整できます。 UTCエポックタイムスタンプが使用される場合、それらは時間として扱われてはならず、シーケンス番号としてのみ扱われなければなりません(MUST)。デバイスは、ボード上のシーケンス番号よりも小さいシーケンス番号を持つマニフェストを拒否する必要があります。

注:これはファームウェアバージョンではありません。マニフェストシーケンス番号です。ファームウェアバージョンは、遅いシーケンス番号で古いファームウェアバージョン用に新しいマニフェストを作成することによってロールバックできます。

軽減:THREAT.IMG.EXPIRED(セクション4.2.1)

実装:単調増加のシーケンス番号(セクション3.2)

4.3.2. REQ.SEC.COMPATIBLE:ベンダー、デバイスタイプ識別子

デバイスは、そのデバイス用のファームウェアのみを適用する必要があります。デバイスは受け取るアップデートがそのデバイスのベンダー、モデル、ハードウェアリビジョン、ソフトウェアリビジョン用のものか細かく知る必要があります。人間が読み取り可能な識別子は、この点でエラーが発生しやすいことが多いため、一意の識別子を使用する必要があります(SHOULD)。

軽減:THREAT.IMG.INCOMPATIBLE(セクション4.2.3)

実装:ベンダーID条件(セクション3.3)、クラスID条件(セクション3.4)

4.3.3. REQ.SEC.EXP:有効期限

ファームウェアマニフェストは一定時間後に期限切れになる場合があります。デバイスは安全なクロック(ローカルまたはリモート)を提供する場合があります。安全なクロックが提供されており、ファームウェアマニフェストに有効期限のタイムスタンプがある場合、現在の時刻が有効期限よりも遅い場合、デバイスはマニフェストを拒否する必要があります。

軽減:THREAT.IMG.EXPIRED.ROLLBACK(セクション4.2.2)

実装:有効期限(セクション3.7)

4.3.4. REQ.SEC.AUTHENTIC:暗号の信頼性

更新の信頼性は実証可能でなければなりません。通常、これは更新がデジタル認証される必要があることを意味します。マニフェストには更新プログラムのインストール方法に関する情報が含まれているため、マニフェストの信頼性も実証する必要があります。検証のオーバーヘッドを削減するために、マニフェストには2番目のデジタル署名ではなく、ファームウェアイメージのダイジェストが含まれています。マニフェストの信頼性は、デジタル署名またはメッセージ認証コードで検証できます。ファームウェアイメージの信頼性は、ファームウェアイメージのダイジェストを使用することによってマニフェストに関連付けられます。

軽減:THREAT.IMG.NON_AUTH(セクション4.2.9)、THREAT.NET.MITM(セクション4.2.7)

実装:署名(セクション3.15)、ペイロードダイジェスト(セクション3.13)

4.3.5. REQ.SEC.AUTH.IMG_TYPE:認証済みペイロードタイプ

ペイロードのタイプ(フォーマットに依存しない場合があります)は認証される必要があります。たとえば、ターゲットは、ペイロードがXIPファームウェアか、ロード可能なモジュールか、構成データかを認識している必要があります。

軽減:THREAT.IMG.FORMAT(セクション4.2.4)

実装:ペイロード形式(セクション3.8)、保管場所(セクション3.10)

4.3.6. セキュリティ要件REQ.SEC.AUTH.IMG_LOC:認証された保管場所

ペイロードが格納されるターゲット上の場所は認証されなければなりません。

軽減:THREAT.IMG.LOCATION(セクション4.2.5)

実装:保管場所(セクション3.10)

4.3.7. REQ.SEC.AUTH.REMOTE_LOC:認証されたリモートリソースの場所

ターゲットがペイロードを見つける場所は認証される必要があります。

軽減:THREAT.NET.REDIRECT(セクション4.2.6)、THREAT.NET.MITM(セクション4.2.7)

実装:リソースインジケーター(セクション3.12)

4.3.8. REQ.SEC.AUTH.EXEC:安全な実行

ターゲットは、起動時にファームウェアを検証する必要があります(SHOULD)。これには、認証済みのペイロードサイズとダイジェストが必要です。

軽減:THREAT.IMG.REPLACE(セクション4.2.8)

実装:ペイロードダイジェスト(セクション3.13)、サイズ(セクション3.14)

4.3.9. REQ.SEC.AUTH.PRECURSOR:認証されたプリカーサイメージ

更新が差分圧縮方法を使用する場合、プリカーサイメージのダイジェストを指定する必要があり、そのダイジェストは認証されなければなりません(MUST)。

軽減:THREAT.UPD.WRONG_PRECURSOR(セクション4.2.10)

実装:プリカーサイメージダイジェスト(セクション3.5)

4.3.10. REQ.SEC.AUTH.COMPATIBILITY:認証されたベンダーおよびクラスID

ファームウェアの互換性を指定する識別子は、互換性のあるファームウェアのみがターゲットデバイスにインストールされていることを確実にするため認証される必要があります。

軽減:THREAT.IMG.INCOMPATIBLE(セクション4.2.3)

実装:ベンダーID条件(セクション3.3)、クラスID条件(セクション3.4)

4.3.11. REQ.SEC.RIGHTS:権限には真正性が必要

デバイスが異なるアクターに異なる権利を付与する場合、それらの権利の行使には、真正性の証明という形でそれらの権利の証明が付随しなければなりません。 REQ.SEC.AUTHENTIC(セクション4.3.4)で必要な認証メカニズムを使用して、認証を証明できます。

たとえば、デバイスに、ファームウェアには作成者権と資格権の両方が必要であることを要求するポリシーがあり、そのデバイスがデバイスオペレーターとネットワークオペレーターなどの異なる関係者にそれぞれ作成権と資格権を付与している場合、ファームウェアのデバイスオペレーターとネットワークオペレーターの両方からの権利の証明がないとインストールできません。

緩和:THREAT.UPD.UNAPPROVED(セクション4.2.11)

実装:署名(セクション3.15)

4.3.12. REQ.SEC.IMG.CONFIDENTIALITY:ペイロードの暗号化

マニフェスト情報モデルは、暗号化されたペイロードを有効にする必要があります。暗号化は、攻撃者を含むサードパーティがファームウェアイメージの内容を読み取るのを防ぐのに役立ちます。これにより、リバースエンジニアリングによる機密情報の露出や脆弱性の発見から保護できます。したがって、マニフェストは、対象の受信者が暗号化されたペイロードを復号化できるようにするために必要な情報を伝える必要があります。

軽減:THREAT.IMG.DISCLOSURE(セクション4.2.12)、THREAT.NET.MITM(セクション4.2.7)

実装:暗号化ラッパー(セクション3.19)

4.3.13. REQ.SEC.ACCESS_CONTROL:アクセス制御

デバイスが異なるアクターに異なる権利を付与する場合、それらの権利の行使は、アクターの権利のリストに対して検証される必要があります。これは通常、アクセス制御リスト(ACL, Access Control
List)の形式を取ります。 ACLは次の2つのシナリオに適用されます。

1. ACLは、マニフェストのどの要素がオーバーライドされ、どのアクターによってオーバーライドされるかを決定します。

2. ACLは、どのコンポーネント識別子/ストレージ識別子のペアをどのアクターが書き込むことができるかを決定します。

軽減:THREAT.MFST.OVERRIDE(セクション4.2.13)、THREAT.UPD.UNAPPROVED(セクション4.2.11)

実装:マニフェストで指定されていないクライアント側コード

4.3.14. REQ.SEC.MFST.CONFIDENTIALITY:暗号化されたマニフェスト

マニフェストの一部またはすべてを暗号化できる必要があります(MUST)。これは、トランスポート暗号化または保管時の暗号化のいずれかで実現できます。

軽減:THREAT.MFST.EXPOSURE(セクション4.2.14)、THREAT.NET.MITM(セクション4.2.7)

実装:外部暗号化ラッパー / トランスポートセキュリティ

4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST:イメージ全体のダイジェスト

ダイジェストは、固定サイズの保管場所で利用可能なすべてのスペースをカバーする必要があります(SHOULD)。可変サイズの格納場所は、デプロイされたペイロードのサイズに正確に制限する必要があります。これにより、ダイジェストでカバーされずにデータが配布されるのを防ぎます。たとえば、XIPマイクロコントローラーは通常、固定サイズのストレージを備えています。これらのデバイスは、展開されたファームウェアイメージをカバーするダイジェストをデプロイし、残りのスペースのデフォルトの消去された値と連結する必要があります。

軽減:THREAT.IMG.EXTRA(セクション4.2.15)

実装:ペイロードダイジェスト(セクション3.13)

4.3.16. REQ.SEC.REPORTING:安全なレポート

デバイスからリモートシステムへのステータスレポートは、レポートの変更やなりすましを防ぐために、認証された機密チャネルを介して実行すべきです(SHOULD)。

軽減:THREAT.NET.MITM(セクション4.2.7)

4.3.17. REQ.SEC.KEY.PROTECTION:署名鍵の保護されたストレージ

マニフェストに署名/認証するための暗号鍵は、HSMやエアギャップコンピューターなどのネットワークデバイスにアクセスできない方法で格納すべきです(SHOULD)。これにより、攻撃者が鍵を取得するのを防ぎます。

鍵は、正当であるが侵害されたエンティティ(サーバーや開発者のコンピューターなど)が署名要求を発行するリスクを制限する方法で格納すべきです(SHOULD)。

緩和:THREAT.KEY.EXPOSURE(セクション4.2.16)

4.3.18. REQ.SEC.MFST.CHECK:展開前にマニフェストを検証する

マニフェストは、作成から署名までの間にコンテンツが変更されていないことを検証するために、展開前に解析および検査すべきです(SHOULD)。

軽減:THREAT.MFST.MODIFICATION(セクション4.2.17)

4.3.19. REQ.SEC.MFST.TRUSTED:信頼できる環境でマニフェストを構築

多数のデバイスや重要な機能のデバイスなどのリスクの高い展開の場合、マニフェストは、エアギャップコンピューターなどの干渉から保護された環境で構築するべきです(SHOULD)。 HSMに接続されたネットワークコンピュータはこの要件を満たさないことに注意してください(THREAT.MFST.MODIFICATION(セクション4.2.17)を参照)。

軽減:THREAT.MFST.MODIFICATION(セクション4.2.17)

4.3.20. REQ.SEC.MFST.CONST:マニフェストはチェックから使用までの間に変わってはならない

マニフェストとそこから抽出されたすべてのデータは、その真正性検証(チェック時)とその使用(使用時)の間で不変であり続ける必要があります(MUST)。 これを確実にするには、マニフェストを内部メモリ、または暗号化されたメモリなどの安全なメモリに格納する必要があります

受信者は、他のプロセスやデバッガなど、受信者に常駐するコードやハードウェアによる改ざんからマニフェストを守るべきです [SHOULD]。

アプリケーションがマニフェストを保存する前に検証する必要がある場合、これはマニフェストがRAMに収まる必要があることを意味します。

軽減:THREAT.MFST.TOCTOU(セクション4.2.18)

4.4. ユーザーストーリー

ユーザーストーリーは、予想される使用例を示します。これらは、ユーザビリティ要件に絡んできます。

4.4.1. USER_STORY.INSTALL.INSTRUCTIONS:インストール手順

デバイスオペレーターとして、ペイロードデータにプロセスの詳細が含ませないように、デバイスに追加のインストール手順を提供したいと考えています。

一部のインストール手順は次のとおりです。

oハッシュのテーブルを使用して、ペイロードの各ブロックが書き込み前に検証されることを確認する

o進捗状況を報告しない

o更新プログラムを事前にキャッシュするが、インストールはしない

oこのマニフェストに一致する事前にキャッシュされた更新プログラムをインストールする

o長く続くタスクより優先させ、この更新プログラムをすぐにインストールする

満足:REQ.USE.MFST.PRE_CHECK(セクション4.5.1)

4.4.2. USER_STORY.MFST.FAIL_EARLY:早期に失敗

リソースに制約のあるIoTデバイスの設計者として、バッテリーの寿命を維持し、消費される帯域幅を制限するために、不良アップデートをできるだけ早く失敗させたいと思っています。

満足:REQ.USE.MFST.PRE_CHECK(セクション4.5.1)

4.4.3. USER_STORY.OVERRIDE:重要でないマニフェスト要素を上書き

デバイスオペレーターとして、マニフェストの重要ではない情報を上書きして、デバイスをより正確に制御できるようにしたいと考えています。この情報を上書きする権限は、別の権限による限定トラストアンカーのインストールによって提供されます。

上書きされる可能性のある情報の例:

o URI(セクション3.12):これにより、デバイスオペレーターは、ネットワークの負荷を軽減するためにデバイスを独自のインフラストラクチャに誘導できます。

o条件:これにより、デバイスオペレーターはマニフェストのインストールに追加の制約を課すことができます。
oディレクティブ(セクション3.16):これにより、デバイスオペレーターはインストール時間などの指示を追加できます。
o処理ステップ(セクション3.9):仲介者がデバイスに代わってアクションを実行する場合、処理ステップを上書きする必要がある場合があります。デバイスが最終的なコンテンツと、ダイジェストを指定する処理ステップの結果を検証することは依然として可能です。一部の処理ステップは上書き不可でなければなりません。

満足:USER_STORY.OVERRIDE(セクション4.4.3)、REQ.USE.MFST.COMPONENT(セクション4.5.3)

4.4.4. USER_STORY.COMPONENT:コンポーネントの更新

デバイスオペレーターとして、ファームウェアをコンポーネントに分割して、更新プログラムのサイズを縮小し、複数の関係者に別のコンポーネントを担当させ、ファームウェアを頻繁に更新されるコンポーネントと頻繁に更新されないコンポーネントに分割したいと考えています。

満足:REQ.USE.MFST.COMPONENT(セクション4.5.3)

4.4.5. USER_STORY.MULTI_AUTH:複数の承認

デバイスオペレーターとして、インストールする前にファームウェア更新プログラムの品質を確認し、製品ファミリのすべてのデバイスの相互運用性を確保できるようにしたいと考えています。明示的な承認を必要とするデバイスを変更する機能を制限したいと考えています。

満足:REQ.USE.MFST.MULTI_AUTH(セクション4.5.4)、REQ.SEC.ACCESS_CONTROL(セクション4.3.13)

4.4.6. USER_STORY.IMG.FORMAT:複数のペイロード形式

デバイスオペレーターとして、デバイスの使用帯域幅を最適化できるように、更新のニーズに合わせて複数のペイロード形式を送信できるようにしたいと考えています。

満足:REQ.USE.IMG.FORMAT(セクション4.5.5)

4.4.7. USER_STORY.IMG.CONFIDENTIALITY:機密情報の開示防止

ファームウェアの作成者として、ファームウェアの更新中に機密情報が開示されないようにしたいと考えています。チャネルセキュリティまたは保管時の暗号化は、マニフェスト自体の情報開示を保護するのに十分であると想定されています。

満足:REQ.SEC.IMG.CONFIDENTIALITY(セクション4.3.12)

4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT:不明なフォーマットのアンパックからデバイスを保護
デバイスオペレーターとして、デバイスがペイロードをダウンロードする前に、ペイロードを処理できるかどうかをデバイスに判断させたいと思っています。

場合によっては、サードパーティがターゲットに代わって何らかの処理を実行することが望ましい場合があります。これが発生するためには、サードパーティは、発生した処理と、Trust Provisioning Authorityの意図に対してそれを検証する方法を示さなければなりません。

これは処理ステップ(セクション3.9)とリソースインジケータ(セクション3.12)を上書きすることになります。

満足:REQ.USE.IMG.FORMAT(セクション4.5.5)、REQ.USE.IMG.NESTED(セクション4.5.6)、REQ.USE.MFST.OVERRIDE_REMOTE(セクション4.5.2)

4.4.9. USER_STORY.IMG.CURRENT_VERSION:対象ファームウェアのバージョン番号の指定

デバイスオペレーターとして、現在のファームウェアバージョンに基づいてデバイスを更新対象にできるようにしたいと考えています。そうするとどのバージョンを置き換えるかが単一のマニフェストで制御可能となります。

満足:REQ.USE.IMG.VERSIONS(セクション4.5.7)

4.4.10. USER_STORY.IMG.SELECT:デバイスがイメージを選択できるようにする

開発者として、単一のマニフェストの複数のファームウェアバージョンに署名できるようにしたいと考えています。そうすると、インプレースで実行される複数のイメージを選択する非常にシンプルなブートローダーを使用することが可能となります。

満足:REQ.USE.IMG.SELECT(セクション4.5.8)

4.4.11. USER_STORY.EXEC.MFST:マニフェストを使用した安全な実行

安全な実行/ブートとファームウェア展開の両方の署名者として、両方のタスクに同じ署名付きドキュメントを使用して、データサイズを小さくしたり、共通コードを共有したり、署名の検証を減らしたりしたいと思います。

満足:REQ.USE.EXEC(セクション4.5.9)

4.4.12. USER_STORY.EXEC.DECOMPRESS:ロード時に解凍

RAMから実行するデバイスのファームウェアの開発者として、圧縮イメージを使用し、マニフェストで圧縮イメージを使用していることをブートローダに示すことで、安全な実行/ブートで使用できるようにしたいと考えています。

満足:REQ.USE.LOAD(セクション4.5.10)

4.4.13. USER_STORY.MFST.IMG:マニフェストのペイロード

制約のあるネットワーク上のデバイスのオペレーターとして、マニフェストの同じパケットに小さなペイロードを含めてネットワークトラフィックを削減できるようにしたいと考えています。

小さなペイロードには、たとえば、ラップされた暗号鍵、構成情報、公開鍵、認証トークン、またはX.509証明書が含まれます。

満足:REQ.USE.PAYLOAD(セクション4.5.11)

4.4.14. USER_STORY.MFST.PARSE:単純な解析

制約のあるデバイスの開発者として、デバイスに多くのアプリケーションコードを収められるように、更新を処理するためには複雑度の低いライブラリが欲しいです。

満足:REQ.USE.PARSE(セクション4.5.12)

4.4.15. ここからUSER_STORY.MFST.DELEGATION:マニフェストで委任された権限

委任された権限をファームウェアの更新を配信するよりも頻繁にローテーションするデバイスオペレーターとして、ファームウェアの更新を配信するときに新しい権限を委任して、1回の送信で両方のタスクを実行できるようにしたいと考えています。

満足:REQ.USE.DELEGATION(セクション4.5.13)

4.4.16. USER_STORY.MFST.PRE_CHECK:評価の更新

制約のあるネットワークのオペレーターとして、ネットワーク上のデバイスが大きなダウンロードを開始する前に更新の適合性を評価して、不要な帯域幅の消費を防ぐことができるようにしたいと考えています。

満足:REQ.USE.MFST.PRE_CHECK(セクション4.5.1)

4.5. ユーザビリティ要件

以下のユーザビリティ要件は、上記のユーザーストーリーを満たしています。

4.5.1. REQ.USE.MFST.PRE_CHECK:インストール前のチェック

マニフェストの作成者は、更新の処理に必要なすべての情報をマニフェストに配置できる必要があります。

例:差分更新に必要なプリカーサーイメージに関する情報は、差分圧縮ヘッダーではなく、マニフェストに配置する必要があります。

満足:[USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check),
USER_STORY.INSTALL.INSTRUCTIONS(セクション4.4.1)

実装:追加のインストール手順(セクション3.16)

4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE:リモートリソースの場所を上書き

ペイロードのフェッチをリダイレクトできる必要があります(MUST)。これは、2つのマニフェストを組み合わせて使用する場合に適用されます。たとえば、デバイスオペレーターは、ペイロードを指定するマニフェストを作成して署名し、そのペイロードのURIを提供します。ネットワークオペレーターは、最初のマニフェストに依存する2番目のマニフェストを作成します。彼らは、この2番目のマニフェストを使用して、デバイスオペレーターによって提供されたURIを上書きし、代わりに独自のインフラストラクチャに誘導します。一部のデバイスはこの機能を提供しますが、他のデバイスはファームウェアの正規のソースのみを確認します。これを可能にするには、デバイスがペイロードをフェッチする必要がありますが、ペイロードのプッシュを受け入れるデバイスはこの機能を無視します。

満足:USER_STORY.OVERRIDE(セクション4.4.3)

実装:エイリアス(セクション3.17)

4.5.3. REQ.USE.MFST.COMPONENT:コンポーネントの更新

複数のペイロードの更新を記述できるように、1つまたは複数の機関から1つまたは複数のペイロードをインストールする要件を表現できる必要があります。これにより、さまざまな権限を持つ複数の関係者が、複数のコンポーネントにわたって、IoTデバイスの単一の更新を作成する際に協力できます。

この要件は実質的に、マルチイメージターゲット上にマニフェストのツリーを構築することが可能でなければならないことを意味します。

異種ストレージアーキテクチャのデバイスを有効にするには、マニフェストでストレージシステムとそのストレージシステム内のストレージの場所の両方を指定できるようにする必要があります。

満足:USER_STORY.OVERRIDE(セクション4.4.3)、USER_STORY.COMPONENT(セクション4.4.4)

マニフェスト要素による実装:依存関係、StorageIdentifier、ComponentIdentifier

4.5.3.1. 例1:複数のマイクロコントローラー

同じ物理デバイス(HeSA)内に複数のマイクロコントローラーを備えたIoTデバイスは、異なるコンポーネント識別子を持つ複数のペイロードを必要とする可能性があります。

4.5.3.2. 例2:コードと構成

ファームウェアイメージは、コードと構成の2つのペイロードに分割できます。これらのペイロードは、インストールするために異なるアクターからの承認を必要とする場合があります(REQ.SEC.RIGHTS(セクション4.3.11)およびREQ.SEC.ACCESS_CONTROL(セクション4.3.13)を参照)。この構造は、複数のマニフェストが必要であり、それらの間に依存構造があることを意味します。

4.5.3.3. 例3:複数のソフトウェアモジュール

ファームウェアイメージは、個別のテストと配布のために複数の機能ブロックに分割できます。これはコードが複数のペイロードに分散する必要がある可能性を意味しています。たとえばこれが望ましいケースとして、配信帯域幅を削減するためにデバイス間の共通コードを確実に同一にするなどの場合があります。

4.5.4. REQ.USE.MFST.MULTI_AUTH:複数の認証

マニフェストのインストールを承認するために、異なるアクセス権限を持つ複数の当事者からの承認が必要になるように、マニフェストを複数回認証できる必要があります。

満足:USER_STORY.MULTI_AUTH(セクション4.4.5)

実装:署名(セクション3.15)

4.5.5. REQ.USE.IMG.FORMAT:フォーマットの使いやすさ

マニフェストフォーマットは、オペレーターが使用したいペイロード形式に対応する必要があります。これにより、受信者はオペレーターが選択した形式を検出できます。ペイロード形式の例は次のとおりです。

oバイナリ
oExecutable and Linkable Format (ELF)
o差分
o圧縮
oパック構成
o Intel HEX
o Motorola Sレコード

満足:USER_STORY.IMG.FORMAT(セクション4.4.6)USER_STORY.IMG.UNKNOWN_FORMAT(セクション4.4.8)

実装:ペイロード形式(セクション3.8)

4.5.6. REQ.USE.IMG.NESTED:ネストされたフォーマット

マニフェストフォーマットは、ネストされた形式に対応しなければならず、すべてのネスト手順とそれらの手順で使用されるパラメーターをすべてターゲットデバイスに通知します。

満足:USER_STORY.IMG.CONFIDENTIALITY(セクション4.4.7)

実装:処理ステップ(セクション3.9)

4.5.7. REQ.USE.IMG.VERSIONS:ターゲットバージョンの一致

マニフェストフォーマットは、リストまたは対象範囲のいずれかを使用して、マニフェストが適用されるファームウェアの複数のバージョン番号を指定する方法を提供する必要があります。

満足:USER_STORY.IMG.CURRENT_VERSION(セクション4.4.9)

実装:必須イメージバージョンリスト(セクション3.6)

4.5.8. REQ.USE.IMG.SELECT:宛先によるイメージの選択

マニフェストフォーマットは、Execute-In-Placeインストールアドレスによって複数の同等のペイロードをリストするメカニズムを提供する必要があります。これにはペイロードダイジェストとオプションでペイロードURIを含みます。

満足:USER_STORY.IMG.SELECT(セクション4.4.10)

実装:XIPアドレス(セクション3.20)

4.5.9. REQ.USE.EXEC:実行可能マニフェスト

Execute-In-Placeマイクロコントローラーと複雑なオペレーティングシステムの両方で、マニフェストを使用して実行可能システムを記述できる必要があります。これには、静的にリンクされた各依存関係のダイジェストをマニフェストで指定する必要があります。さらに、マニフェストフォーマットは、ローダーやブートローダーで使用されるカーネルコマンドラインなどのメタデータを表現できなければなりません(MUST)。

満足:USER_STORY.EXEC.MFST(セクション4.4.11)

実装:実行時メタデータ(セクション3.22)

4.5.10. REQ.USE.LOAD:ロード時の情報

暗号化情報、ロードアドレス、圧縮アルゴリズムなど、ペイロードのロード時処理用の追加のメタデータを指定できる必要があります。

注意:ロードはexec / bootの前に来ます。

満足:USER_STORY.EXEC.DECOMPRESS(セクション4.4.12)

実装:ロード時のメタデータ(セクション3.21)

4.5.11. REQ.USE.PAYLOAD:マニフェストスーパーストラクチャーのペイロード

ペイロードをマニフェストと同じ構造に置くことが可能でなければなりません(MUST)。これにより、マニフェストと同じパケットにペイロードが配置される場合があります。

統合されたペイロードには、たとえば、ラップされた暗号鍵、設定情報、公開鍵、認証トークン、またはX.509証明書が含まれます。

統合ペイロードが提供されると、これによりマニフェストのサイズが増加します。マニフェストのサイズは、慎重な検討を必要とするいくつかの処理とストレージの問題を引き起こす可能性があります。ペイロードは、マニフェスト全体が単一のネットワークパケットに含まれるのを防止できますが、損失の多いネットワークでマニフェストの一部の断片化と損失を引き起こす可能性があります。これにより、再構成と再送信のロジックが必要になります。マニフェストは検証と処理の間で不変に保つ必要があります(REQ.SEC.MFST.CONST(セクション4.3.20)を参照)。そのため、より大きなマニフェストは、たとえば内部RAMやNVRAM、または外部のセキュアメモリなど、不変性を確実にするより多くのメモリを消費します。マニフェストが利用可能な不変メモリを超える場合は、モジュール化して処理し、委任チェーン、セキュリティコンテナー、実際のマニフェスト(統合されたペイロードの検証を含む)をそれぞれ評価する必要があります。セキュリティモデルで、NVRAMの摩耗とNVRAMのエネルギー消費を防ぐために、マニフェストをダウンロードしてNVRAMに保存する前に検証する必要がある場合、マニフェストストレージに割り当てられたメモリを増やすか、受信したマニフェストのモジュラー処理が必要になることがあります。マニフェストは、このタイプの処理を可能にするように構成されていますが、パーサーの複雑さが増します。マニフェストが処理の前にNVRAMに格納されている場合、統合されたペイロードにより、マニフェストが使用可能なストレージを超える可能性があります。マニフェストは、適用性、権限、または正当性の検証の前に受信されるため、統合されたペイロードにより、受信者はネットワークの帯域幅とエネルギーを消費しますが、マニフェストが破棄されれば必要なくなる場合もあり、これらのコストは統合されたペイロードのサイズによって異なります。

参照:REQ.SEC.MFST.CONST(セクション4.3.20)。

満足:USER_STORY.MFST.IMG(セクション4.4.13)

実装元:ペイロード(セクション3.23)

4.5.12. REQ.USE.PARSE:シンプルな解析

マニフェストの構造は、汎用パーサーを必要とせず、解析が簡単でなければなりません(MUST)。

満足:USER_STORY.MFST.PARSE(セクション4.4.14)

実装:N / A

4.5.13. REQ.USE.DELEGATION:マニフェストでの権限の委任

マニフェストフォーマットでは、マニフェストを使用した、ただし認証されていない鍵クレームの配信を有効にする必要があります。この鍵クレームは、受信者がマニフェストを検証できる新しい鍵を提供します。

満足:USER_STORY.MFST.DELEGATION(セクション4.4.15)

実施:鍵クレーム(セクション3.24)

5. IANAに関する考慮事項

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

6.謝辞

作業部会の議長であるDave Thaler、Russ Housley、David Waltermireのレビューコメントとサポートに感謝します。

2018ベルリンSUITハッカソンおよび2018年6月の仮想設計チームミーティングの参加者のディスカッションへの入力に感謝します。特に、Koen Zandberg、Emmanuel Baccelli、Carsten Bormann、David Brown、Markus Gueller、Frank Audun Kvamtro、Oyvind Ronningstad、Michael Richardson、Jan-Frederik Rieckers、Francisco Acosta、Anton Gerasimov、Matthias Waehlisch、Max Groening、 Daniel Petry、Gaetan Harter、Ralph Hamm、Steve Patrick、Fabio Utzig、Paul Lambert、Benjamin Kaduk、Said Gharout、Milen Stoychevに感謝します。

この情報モデルの開発に貢献してくださった方々に感謝いたします。特に、Milosch Meriac、Jean-Luc Giraud、Dan Ros、Amyas Philips、およびGary Thomsonに感謝します。

7. 参考資料

7.1. 引用規格

[I-D.ietf-suit-architecture]
Moran, B., Tschofenig, H., Brown, D., and M. Meriac, “A
Firmware Update Architecture for Internet of Things”,
draft-ietf-suit-architecture-11 (work in progress),
May 2020.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate
Requirement Levels”, BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, “A Universally
Unique IDentifier (UUID) URN Namespace”, RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. 参考文献

[STRIDE] Microsoft, “The STRIDE Threat Model”, May 2018,
<https://msdn.microsoft.com/en-us/library/ ee823878(v=cs.20).aspx>.

著者のアドレス

Brendan Moran
Arm Limited

EMail: Brendan.Moran@arm.com

Hannes Tschofenig
Arm Limited

EMail: hannes.tschofenig@gmx.net

Henk Birkholz
Fraunhofer SIT

EMail: henk.birkholz@sit.fraunhofer.de