要約

  • RFC 9019 はファームウェア更新を「許可された遠隔コード実行」と位置づける。署名は作者とマニフェストを認証するが、その作者が要求された操作を行えるかは別のポリシー判断である。
  • 作者、機器運用者、ネットワーク運用者、利用者、信頼プロビジョニング機関は異なる権限を持ち得る。RFC 9124 が複数署名を扱うのは、異なる役割の承認を組み合わせるためである。
  • マニフェスト、権限、展開時期、起動、観測結果を結ぶ「ファームウェア変更承認レシート」をローカルに残すべきだ。これは Daniel Kade の編集提案であり、SUIT の新要素ではない。

正しい署名は重要な証拠である。受け入れた鍵の保有者がマニフェストを保護し、対象バイトが変わっていないことを示す。ペイロードのダイジェストが含まれれば、受信したイメージもその指示に結び付く。更新経路を攻撃経路にしないための基礎である。

しかし、その証拠は実行許可より狭い。2021 年 4 月に IETF の Informational RFC として公表された RFC 9019 は、認証された作者の識別子を認可の入力とし、作者ごとに権限が異なり、要求された操作が署名者の許可範囲に入るかを機器が判断しなければならないとする。

つまり、信頼された鍵は万能鍵ではない。あるセンサー群のアプリケーションを変更できても、ブートローダを変更できるとは限らない。緊急修正を配布できても、恒久的な機能追加まで許されたわけではない。暗号は署名者を示し、ポリシーがその人の行える操作を定める。

複数 MCU は真正性と全体整合性を分ける

RFC 9019 は、現在の IoT 機器が複数の MCU を含み、一回の更新に複数のイメージやマニフェストを必要とする場合があると説明する。主 MCU、無線部、セキュア要素、センサー制御部が別々に更新されるなら、個々の署名が正しいだけでは組み合わせの安全性は証明されない。

一つの部品は新しい API を期待し、別の部品は旧形式のままかもしれない。差分更新は特定の前駆イメージを前提にする。格納先や起動順序も結果を変える。RFC 9124 がベンダー、クラス、デバイス、コンポーネント、前駆ダイジェスト、依存関係、処理手順を扱うのは、真正なイメージでも現在状態に適合しないことがあるからだ。

ローカル条件も残る。制御中の装置を停止できるか、予備電源があるか、回復用イメージが使えるか、先行群が正常か、担当者が現場にいるか。共通マニフェストは機械可読な条件を運べるが、すべての現場事実を世界共通形式に変える必要はない。

必要なのは、共通指示とローカル入場判断の接続である。各部品が真正であること、依存関係が満たされること、運用者がその組み合わせと時期を受け入れたことを別々に確認する。

作者と運用者は同じ役割とは限らない

RFC 9019 は作者、機器運用者、ネットワーク運用者、利用者、信頼プロビジョニング機関（TPA）を区別する。TPA は信頼アンカーと認可ポリシーを配布し、権利を委任できる。作者はイメージを作り、運用者は日々の機器群を管理する。

単純な製品では一つの組織が全役割を担い、ポリシーが一つの署名に十分な権限を与えることもある。標準は必ず人がクリックすることや、必ず二人が署名することを求めていない。

それでも、役割が同じであるという事実は署名方式からは導けない。部品メーカーは自分のコードを作るが、工場の停止時期を決めない。ネットワーク運用者は転送を管理しても、アプリケーションを書き換える権利を得ない。所有者が変われば、従来のメーカーと現在の運用責任者の関係も変わる。

TPA ポリシーは更新経路の権力図になる。鍵を役割に、役割を機器クラス、部品、操作、委任期限に結び付ける。その版が古い、権限が広すぎる、または監査できない場合、署名検証が完全でも制度上の許可は誤る。

複数署名は数ではなく役割で読む

RFC 9019 は重要インフラの例で、作者だけでは設置権限が足りず、作者と機器運用者の両方の署名を要求できるとする。運用者の署名は作者の真正性を補強するものではない。現場で変更を受け入れる別主体の決定である。

RFC 9124 は、異なる権限を持つ複数当事者がインストールを許可できるよう、マニフェスト形式が複数署名を運べなければならないとする。機器運用者が製品群の相互運用性を確認し、明示的承認を要求する利用例も示す。

したがって、署名を数えるだけでは足りない。作者役の鍵が二つあっても、作者と運用者を要求する規則は満たさない。安全責任者が必要なら、三つの一般署名で代用できない。各鍵の役割、権限範囲、ポリシー版、対象操作を評価する必要がある。

委任も同じである。新しい鍵が正しく委任されたかだけでなく、誰が委任できたのか、どの部品に、いつまで、さらに委任できるのかを明確にする。鍵の連鎖が長いほど、権限の説明が必要になる。

配送と起動指示は承認ではない

ステータストラッカーは新しい版を知らせ、機器の特性を受け取り、更新を遠隔で開始できる。作者、機器運用者、ネットワーク運用者などが運営できる。この柔軟性は有用だが、開始ボタンを持つことは作者権限や承認権限の継承を意味しない。

サーバは保管だけ、ゲートウェイは中継だけ、ネットワーク側は時間調整だけを担当できる。逆に作者も、物理プロセスを止められる時期、電力条件、認証済み構成、回復準備を自動的に決められるわけではない。

「利用可能」「取得済み」「格納済み」「承認済み」「インストール済み」「起動中」を一つの状態にまとめると、どの主体がどの遷移を認めたのか分からなくなる。配送成功を承認成功と読み替えないことが重要である。

シーケンス番号はファームウェア版ではない

RFC 9124 は古い有効マニフェストの再送を防ぐため、単調増加するシーケンス番号を要求する。ただし、その番号はファームウェア版ではない。より高いシーケンスの新しいマニフェストが、より低い版のイメージを意図的に許可できる。

これは制御された復旧に必要である。新リリースが失敗したとき、既知の旧版へ戻すという新しい決定を発行できる。認可オブジェクトは新しいのでシーケンスは進み、ペイロード版は戻る。

版が下がっただけで攻撃と断定すれば正当な復旧を妨げる。確認すべきはシーケンス、ロールバック権限、前駆状態、対象群と理由である。反対に版が上がっても権限は証明されない。最新版という文字列に統治権はない。

インストール済みと起動済みは別である

RFC 9019 は、マニフェストを処理してイメージを格納するコンシューマと、起動前に検証して実行するベリファイアを分ける。新イメージが無効なら、別の有効イメージを選ぶか、新たな有効イメージを取得する回復策が必要になる。

例示フローでは「Firmware Update Completed」が送られた後に、再起動、セキュアブート検証、活性化が続く。完了通知は嘘ではない。その時点の段階を完了したという意味であり、未来の起動結果を証明しない。

再起動後に拒否される、旧イメージへ戻る、一部 MCU だけ切り替わる、サービスが復旧しない、通信を失う可能性がある。管理サーバは起動後証拠を受け取るまで、どの状態が永続化したかを知らない。

必要な証拠は範囲を限定できる。選択されたイメージ、部品集合、起動結果、回復経路、重要機能の状態と観測時刻である。アテステーションは実行物を示す助けになるが、なぜ許可されたか、物理結果が安全かまでは単独で示さない。

ファームウェア変更承認レシート

実務的な修復は、真正な提案を結果まで追うローカルで最小化されたレシートである。公開デバイス台帳でも、マニフェストの代用品でもない。

最初にマニフェストハッシュ、ペイロードダイジェスト、シーケンス、宣言版、機器クラス、部品、前駆・依存状態を結ぶ。認可ポリシー版、署名者ごとの役割、満たした承認集合を記録し、「なぜこの署名群がこの操作を許したか」を説明できるようにする。

次に展開入場を記録する。対象群、保守時間、ローカル条件、先行群結果、回復イメージ、責任者、実施・延期・拒否の判断である。鍵、詳細な機器識別子、内部構成、脆弱性情報を広く公開する必要はない。アクセス制御された参照とハッシュで十分な場合が多い。

最後に取得、格納、インストール、ベリファイア受理、再起動後活性化、健全性確認、回復を分ける。旧版へ戻したなら、それを許可した高いシーケンスと最終稼働版を残す。期限付き権限や委任も終了させる。

これは Daniel Kade の編集提案であり、SUIT 要素、IETF 要求、TPA 製品、遠隔命令ではない。正確な暗号証拠が、その証拠の射程外まで権力を広げるのを防ぐための記録である。

Heng Lu の枠組みは、最小共通仕様、ローカル判断、自発的採用、実行、観測結果を区別する。RFC 9019 と RFC 9124 は共通言語を提供する。運用者は権限と時期を決め、実行結果を見て次の判断を開く。

各マニフェストが真正でも、製品全体の変更は別に承認されなければならない。

情報源