要約

  • draft-ietf-suit-update-management-16 の更新管理拡張は実装も収録も任意であり、Recipientの対応状況は配備固有の知識として別経路で確立され得る。
  • 人間向けのバージョン文字列は信頼できない表示情報である。機械判定、認可、待機、導入、起動後の実行状態は別々に記録しなければならない。

正しい封筒が、実行できる命令とは限らない

署名検証が成功すると、運用画面は大きな確実性を得る。誰がマニフェストを作り、その内容が保護されているかを確認できる。しかし、その確実性はRecipientのコードに存在しない機能まで作り出さない。

SUIT更新管理案のrevision 16は、拡張の実装もマニフェストへの収録もOPTIONALだとする。さらに、Recipientが対応しているという知識は配備ごとに異なり、out-of-band、つまり主たるプロトコル経路とは別の方法で確立されてもよい。

現場では、この知識は製品仕様、部品表、ビルド設定、ブートローダー一覧、試験結果などに分散する。同じ型番でも、実装版や有効化された機能が違えば能力は異なる。「この製品は対応済み」という一文を、個体とビルドに結び付けず使うことは危険だ。

有効な能力記録には、主張者、対象範囲、実装版、確認方法、確認日時が要る。期限も必要である。署名済みマニフェストが長く保存されても、能力情報はソフトウェア更新や構成変更で古くなるからだ。

ドラフトがいうdeployment profileは、未指定の選択肢やローカルな対応付けを定める合意であり、新しいwire objectではない。形式上は通信に現れなくても、実際の結果を支配する。このプロファイルを実行記録から落とせば、同じマニフェストで二台の挙動が違った理由を説明できない。

revision 15から消えた明示規則

一つ前のrevision 15には、未実装のcommandやparameterに遭遇したRecipientはマニフェストをrejectしなければならないという文章があった。また、拡張に依存するManifest Authorは、対象Recipientが必要な能力をadvertiseしていることを事前に確保するよう求められていた。

revision 16では、その段落が「対応知識は配備固有で、別経路で確立され得る」という短い文に置き換わった。これは仕様文の変化であって、実機の挙動が変わったという観測ではない。それでも証拠設計への影響は大きい。通信記録に能力広告がなければ、判断を支えた外部資料を保存する必要がある。

別経路は、責任のない経路であってはならない。どの資料が、どの対象について、どの時点で有効だったのかを残さなければ、見えない能力表が更新の許可証になってしまう。

表示用のバージョンと、判定用のバージョン

revision 16は、人が読む値と機械が比較する値を明確に分ける。

suit-set-version は、制約された形式で損失なく表現できる場合の機械可読値である。suit-parameter-version は、componentに対する比較演算子とversionを運ぶ。build metadataはSemantic Versioningの優先順位から外れるため、機械側の比較値には含めない。

一方、suit-text-current-version と suit-text-version-required は人間の理解のためにある。必要versionの文字列が >=1.2.5,<2 のように見えても、Manifest Processorは解釈してはならない。両者に食い違いがあれば、機械可読フィールドが権威を持つ。

Security Considerationsはさらに厳しい。自由記述はuntrusted inputであり、評価もmarkup実行も禁止され、機械判定を上書きしてはならない。表示側はUI、ログ、制御文字へのinjectを防ぐ必要がある。

運用上の落とし穴は、文字列を実行することだけではない。文字列を正しく表示した後、その横に「適合」の印を出すことも、機械判定を実施していなければ証拠の取り違えである。比較のreceiptには、入力フィールド、観測対象component、version取得元、結果、時刻を含めるべきだ。

priorityは認可を要求する材料にすぎない

update priorityは小さい整数ほど高い。しかし各値の意味と行動はlocal policyが定める。suit-condition-update-authorized は、そのpriorityをアプリケーションへ渡して許可を求め、許可されなければ失敗する。

したがって「緊急」は権限ではない。Manifest Authorは優先度を示せるが、現場の認可主体を消すことはできない。特定の値を自動許可に結び付けるなら、それは配備プロファイル側の規則としてversion管理されるべきだ。

監査記録は、生のpriority、解釈したpolicy version、判断主体、結果、時刻を分離する。これがなければ、作者の緊急度と現場の許可が一つの緑色ステータスに潰れる。

waitは停止理由を持つ状態である

suit-directive-wait は、認可、外部電源、network、別装置のfirmware version、時刻、現地時刻、曜日を待てる。複数イベントがあれば、すべて満たすまで先へ進まない。

待ち方そのものはimplementation-definedだ。semaphoreでblockする、event handlerを登録してsuspendする、pollする、いったんabortして通知後にrestartする、といった実装があり得る。再起動、電池消費、状態保存、重複取得への影響は異なる。

現地時刻イベントはtime zoneとdaylight-saving ruleがなければunsupportedである。別装置versionの待機も、identifier namespace、unique scope、version取得方法、encodingを配備プロファイルが定めなければunsupportedとなる。値が存在するだけでは、対象は定まらない。

ドラフトは、管理interfaceがRecipientの対応拡張と、更新が待機または失敗している理由を示すことを推奨する。さらに、waitがrebootを越えて残るか、operatorがどうcancelするか、local timeoutをどう置くかもpolicyで決めるべきだとする。

単一の「保留中」表示では、機能未対応、mapping不足、正当な条件待ち、resume失敗、後段failureを区別できない。状態、未解決イベント、signal source、最終評価、永続化規則、次の許可遷移を記録して初めて回復可能になる。

CoSWIDは期待値であり、起動の観測ではない

suit-coswid はsoftware inventory、SBOM、attestationを支援する。severableなら、不要なRecipientやintermediaryがmanifest signatureを壊さず取り除ける。非severableでも、存在だけで全Recipientに詳細処理を要求するわけではない。

CoSWIDは「何があるはずか」を記述できるが、「この装置で今それが動いている」を証明しない。fetch、write、install、activate、reboot、running componentのmeasurementは後続の別記録である。

また、componentとversionの詳細は攻撃者にも有用だ。誰がmetadataへアクセスできるか、どこでseverしたかも証拠の一部になる。

version一致よりdigestのほうが狭い事実を語る

ドラフトは、version checkよりimage digestの検証を優先する。versionは互換性の範囲を表せるが、必ずしも一つのbyte列を指さない。同じ公開versionの再buildや異なるcompile optionがあり得る一方、人間向け文字列には機械の優先順位で使わないbuild metadataも含められる。

したがって、versionのreceiptとdigestのreceiptを統合してはいけない。前者はlocal ruleに対する比較結果、後者は処理対象contentの同一性を狭く示す。さらにdigestが一致しないというconditionが真でも、その後のfetchやinstallが完了した証拠にはならない。

component metadataにもlocal policyが関わる。actor identifier、permission、file pathのような値は配備側のaccess-controlへ対応付けられるため、well-formedであることと適用を許可されることは別だ。値を設定した主体、対象component、適用時点、policy resultを残す必要がある。

Capabilityが正しい場合でも、結果まで保証されない。battery condition、use-before、authorization、version、waitのいずれかで止まり得る。すべてを通過しても、write、activate、reboot、rollback、running-state measurementは後段の状態である。運用画面が「manifest verified」を「deployment complete」へ短絡しないことが、復旧可能性を守る。

一つの成功印ではなく、連続したreceiptを

必要なのは、文書とregistryの状態、署名済みmanifest、対象Recipient、能力主張の由来と有効期限、deployment profile、machine fieldとlocal signal、各condition、wait/failure、install、activation、running-state observationを分けた鎖である。

調査時点でDatatrackerはrevision 16にApproved-announcement sentを示していたが、文書はなおInternet-Draftで、IANA actionも進行中だった。制度上の前進は、RFC番号でも採用率でも実装成功でもない。

署名が弱いのではない。署名の発言範囲が正確なのだ。指示の真正性、装置の能力、ローカルな権限、実行結果を分けるほど、更新は説明可能になる。

出典