2410598_ja-JP

是

imxrt1024..5A のセキュアブート

Abhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.png

署名済み画像と署名なし画像(SPTで署名済み)を比較した六角形のスナップを添付しました。
IVTには私が理解できなかったいくつかの変更点があるのがわかります。
オフセット0x1000
符号なし -> D1 00 20 41 00 20 00 60 00 00 00 00 00 00 00 00
署名済み -> D1 00 20 40 DD 22 00 60 00 00 00 00 00 00 00 00
質問1：41は私のコード内にハードコードされているIVTバージョンだと理解していますが、これを40に変更するにはどうすればよいでしょうか？
質問2。また、00 20 -> DD 22 がどのように変換されるのかも理解できません。

オフセット0x1010
これは明らかで、ここではCSFポインタが更新されています。

0x1020
符号なし -> 00 00 00 60 00 00 40 00 00 00 00 00
署名済み -> 00 00 00 60 00 A0 00 00 00 00 00 00
質問3：00 40はA0 00でどのように更新されますか？

これらの質問をする理由は、私の理解では、開発チームがブート可能なバイナリを提供すれば、CSF.binを追加してIVTのCSFポインタを更新して署名するだけでよいはずなのですが、違いを見て、もっと多くのことが起こっているように感じたからです。

Re: Secure boot in imxrt1024..5A

Abhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.png

以前の投稿でこの回答をいただいたので、CSFを追加してIVTでVSFFポインタを更新すればファームウェアが署名されると思っていましたが、画像にCSTで署名したいのでどうやって署名すればいいのでしょうか?
すでに起動可能なイメージ(FCFB、IVT、BOOTDATA,...)を持っています。パッケージに署名して発送するだけです。どうやってそれを行うかは、hab.csfを作成しました

[ヘッダ]
バージョン = 4.0
#利用可能なエンジンは、ICXRT 用の DCP、SW、ANY です。
エンジン = DCP
エンジン構成 = 0
証明書フォーマット = x509
署名形式 = CMS
ハッシュアルゴリズム = sha256

#後続の INSTALL CSFK または Install KEY で使用するためにルート公開鍵をインストールします
#HABは内部公開鍵ストアのスロット0にインストールされます
# HAB は単にテーブルを再ハッシュし、融合された SRK ハッシュと比較します。
[SRKをインストール]
ファイル = "keys/SRK_1_2_3_4_table.bin"
#使用するSRKを指定します。このインデックスの失効ヒューズが焼損している場合、インストールは失敗します。
ソースインデックス = 0
ハッシュアルゴリズム = sha256

#HAB スロット 1 に CSF キーの証明書をインストールします
[CSFKをインストール]
ファイル = "crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem"
証明書フォーマット = x509

#Authenticate CSF コマンドは、実行元の CSF を認証します。
[CSFの認証]

#後続の「鍵のインストール」または「データの認証」コマンドで使用するための公開鍵をインストールします
#HAB が IMG 証明書をキースロット 2 にインストールします
[インストールキー]
#この証明書はSRKと照合されていることを意味します
検証インデックス = 0
目標インデックス = 2
ファイル = "crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem"

[データの認証]
#インストールキーのターゲットインデックスと同じである必要があります
検証インデックス = 2
ブロック = 0x60001000 0x1000 0x6580 "evkmimxrt1024_iled_blinky_unsigned_original.bin"

Re: Secure boot in imxrt1024..5A

こんにちは、 @Abhay2080 さん。

ご質問ありがとうございます！

RT1024 IVT / ブートデータの定義に基づくと、見られる差異は想定内のものであり、CSFポインタの更新に限ったものではありません。

Q1: なぜD1 00 20 41D1 00 20 40になるのですか?
D1 00 20 41 はIVTヘッダーで、 0xD1 はIVTタグ、 0x0020 は固定されたIVT長32バイト、最後のバイトはバージョンです。RT1024リファレンスマニュアルではIVT版を 0x40/0x41と定義しているので、 0x40 は有効であり誤りではありません。こちらのオンラインガイドをご確認ください： https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mcu_bootloader/docs/iMXRT1024_Manufacturin...

Q2: なぜ00 20 00 60DD 22 00 60になるのですか?
これはIVT entry体です。リトルエンディアン形式の場合：

00 20 00 60 = 0x60002000
DD 22 00 60 = 0x600022DD

RT1024 RMは、entryをイメージから実行される最初の命令の絶対アドレスとして定義します。AN12108では、デフォルトのエントリポイントがReset_Handlerでない場合、 entryPointAddress Reset_Handlerアドレスに設定する必要があるとも記載されています。
したがって、SPTはIVTのエントリーを 0x60002000 から実際の申請エントリーポイントに更新した可能性が高いです。マップファイル/ELFシンボルテーブル内のReset_Handlerアドレスを確認してください。

Q3: なぜ00 00 40 0000 A0 00 00になるのですか?
0x1020にはブートデータがあります。

start 遺体 0x60000000
length 0x00400000から 0x0000A000

RT1024 RMは、ブートデータにイメージの開始アドレスとイメージの長さが含まれていると定義しており、ブートROMはこの構造体からイメージのアドレスと長さを読み取ります。
そのため、SPTは最終的に生成されたブート可能/署名済みイメージのレイアウトに合わせて、長さフィールドを更新しました。

RTシリーズのHABセキュアブートの場合、最終的な署名付きイメージは単に「CSF.binを追加してCSFポインタを更新する」だけではありません。IVTヘッダー、エントリ、ブートデータの長さ、CSFポインタ、およびCSF認証データコマンドでカバーされるアドレス/長さはすべて一致している必要があります。HABはソフトウェアからハッシュをフラッシュで再計算し、署名から回収された参照ハッシュと比較します。認証済み領域が署名後に変更されると、検証は失敗します。[0dfe-E1]
推奨される方法は、CSF.binだけを手動で追加するのではなく、SPT/CSTによって生成された最終的な署名付きイメージを使用することです。

この説明がお役に立てば幸いです！

よろしくお願いします、
ギャビン

Re: Secure boot in imxrt1024..5A

こんにちは、 @Abhay2080 さん。

良い質問ですね。重要な点は、CSTは画像自体を変更するのではなく、指定した領域のハッシュ値を計算してCSF（署名）を生成するだけであるということです。IVTエントリ、ブートデータの長さ、バージョンは一切変更されません。

そのため、SPT ではこれらのフィールドが変更されました。SPT は ELF からブートイメージを再構築し、IVT.entry (実際の Reset_Handler に) とブートデータの長さを正規化します。これらの変化は、署名の段階ではなくイメージの再構築から生まれます。CSTダイレクトフローなら再現する必要がありません。元のイメージがすでにオープン/開発状態で起動しているなら、そのエントリとバージョンはすでに正しく、そのまま維持できます。

しかし、一つだけ厳しい条件があります。あなたの[Authenticate Data]ブロック

Blocks = 0x60001000 0x1000 0x6580

これはIVT全体をカバーしており、IVT CSFポインタはこの符号付き領域内に位置しています。HABはこの領域を再ハッシュし、署名と比較するため、署名後にバイトが変更されると認証が失敗します。

まさにこれが、「最初に署名してからCSFを追加し、CSFポインタを更新する」という方法が機能しない理由です。順序が間違っているのです。

CSTの署名および発送手順を正しく行う（CSTを実行する前にこれを行ってください）：

CSFを配置する場所を決定します（アプリの後に添付）。あなたのブロックの場合、アプリは 0x1000 + 0x6580 = 0x7580で終わります。つまりCSFはファイルオフセット 0x7580 (メモリ 0x60007580)から始まります。
署名する画像では、以下の設定が事前に行われます。
- IVT CSF ポインタ → CSF メモリアドレス (例:0x60007580);
- ブートデータの長さ → CSFを含むイメージ全体のサイズ。
FCFBとエントリは変更しないでください（FCFBはHABの範囲外です。ROMはHABの前にそれを読み取ります）。
実行: cst -i hab.csf -o csf.bin (RT1024 の場合、hab.csf と Engine = DCP の組み合わせが正しいです)。
連結: cat prepared.bin csf.bin > signed_firmware.bin、ステップ1のアドレスにCSFを配置し、直接フラッシュします。

つまり、 hab.csf 自体は問題ありません。唯一の解決策は署名前にCSFポインタとブートデータの長さを設定することです。署名後ではなく。

よろしくお願いします、
ギャビン