2402573_ja-JP

はい

S32K312 HSEセキュアブート:pInstAuthTagはUTEST DCFレコード領域に保存されている署名を指し示せますか?

こんにちは、NXPサポートチームの皆さん、

S32K312上でHSEベースのSecure Boot with SMRを実装しており、SMR署名がUTEST DCFレコード領域に恒久的に保存できるかどうかを確認したいと考えています。

現在の実装は以下のとおりです。

UTESTには、以下のアドレスから始まる512バイトのRSA-4096署名が格納されます。

0x1B001A00U

占有されている住所範囲は以下のとおりです。

0x1B001A00～0x1B001BFF

この地域はUTEST DCF記録領域に属します。

当プロジェクトでは、このエリアにおけるDCFの設定は一切必要ありません。そのため、未使用のDCFレコード空間を公開鍵やSMR署名を含む永久的なセキュリティデータを保存することを検討しています。
ソフトウェアイメージとその署名は当社のユースケースで固定されているため、製品のライフ期間中にシグネチャが変更されることは期待されていません。
SMRエントリでは、署名参照を次のように設定します。

smrEntry.pInstAuthTag[0]= 0x1B001A00U;

smrEntry.pInstAuthTag[1]= 0U;

我々の予想では、その後のセキュアブート検証中に、HSE は pInstAuthTag[0] で指定された UTEST アドレスから 512 バイトの署名を直接読み取ります。

HSE_SRV_ID_SMR_ENTRY_INSTALLを通じてSMRエントリをインストールする際、最初にインストールサービス認証タグを同じUTESTアドレスを参照するように設定しました。

pSmrEntryInstall->pAuthTag[0] = 0x1B000A00U;

しかし、SMRインストールサービスはHSE_SRV_RSP_INVALID_PARAMを返しました。これは、UTESTアドレスがサービスに対する無効な入力アドレスとして拒否されたためと思われます。

回避策として、SMRインストールサービスを呼び出す前に、UTESTから512バイトの署名を共有RAMバッファにコピーします。

UTEST 0x1B000A00

|

| 512バイトをコピー

V

共有RAMバッファ

次に、インストール要求を以下のように設定します。

pSmrEntryInstall->pAuthTag[0] =

PTR_TO_HOST_ADDR(signatureRamBuffer);

pSmrEntryInstall->authTagLength[0] = 512U;

SMRエントリ自体には、以下の内容が含まれています。

smrEntry.pInstAuthTag[0]= 0x1B000A00U;

この構成では、HSE_SRV_ID_SMR_ENTRY_INSTALL は成功を返し、SMR エントリは正常にインストールされます。

以下の質問について、もう少し詳しく教えていただけますか?

S32K312 上の hseSmrEntry_t.pInstAuthTag[0] のアドレスとして、0x1B001A00U は有効ですか？
その後のセキュアブート時に、HSE_B直接UTEST DCFレコード領域にアクセスし、pInstAuthTag[0]で参照されたシグネチャを読み取ることはできますか?
HSE_SRV_ID_SMR_ENTRY_INSTALL 応答が成功した場合、永続的な pInstAuthTag[0] アドレスが後の起動時の SMR 検証に有効であることが確認されるのでしょうか、それともインストールサービスは hseSmrEntryInstallSrv_t.pAuthTag[0] を介して提供される署名のみを検証するのでしょうか？
メモリ領域には、以下の用途で受け入れられる違いがありますか？

hseSmrEntryInstallSrv_t.pAuthTag[0]

そして：

hseSmrEntry_t.pInstAuthTag[0]

私たちのテストでは、UTEST アドレスを pAuthTag[0] として直接使用すると拒否されますが、同じ署名を RAM にコピーし、pInstAuthTag[0] がまだ UTEST を指している場合は SMR のインストールが成功します。

この構成はSMRインストールに合格しても、次のリセットやセキュアブート時にHSEがUTESTアドレスにアクセスできないため失敗する可能性はありますか?
プロジェクトでDCFレコードが不要な場合でも、未使用のUTEST DCFレコード領域は公開鍵やSMR署名などのお客様アプリケーションデータを保存することが許されていますか?
このDCFレコード領域の使用は、HSEファームウェア、ROMブートコード、FUTURE DCFプロセッシング、ライフサイクルの移行、デバッグ設定、またはデバイス構成スキャンと競合を引き起こす可能性がありますか?
このUTEST領域で生の512バイト署名を保存する際、アラインメント、レコードフォーマット、ECC、プログラミング、ロック、アクセス制限などはありますか?
もしUTESTがpInstAuthTag[0]でサポートされていない場合、永続的なSMRシグネチャは常に通常のアプリケーションコードフラッシュかデータフラッシュに保存されるべきでしょうか?

確認したい主な点は、以下の構成が公式にサポートされており、本番環境での使用が安全かどうかです。

/* セキュアブート中に使用される永続的な署名場所/*

smrEntry.pInstAuthTag[0] = 0x1B000A00U;

/ SMRインストール時のみ使用される一時的なRAMコピー */

pSmrEntryInstall->pAuthTag[0] =

PTR_TO_HOST_ADDR(signatureRamBuffer);

pSmrEntryInstall->authTagLength[0] = 512U;

MCU:S32K312
HSEタイプ:HSE_B
シグネチャアルゴリズム:RSA-PSSとRSA-4096
シグネチャ長:512バイト
永続署名アドレス:0x1B001A00U

よろしくお願いします。

Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar

申し訳ありませんが、署名位置は0x1B000A00Uではありません。それは0x1B001A00Uです。

Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar

こんにちは@Yiming2

UTESTが使えるかどうかがドキュメントに明示的に記載されていないので、ボードでテストしました。そして、私も同様の結果を得ました。

pAuthTag = pInstAuthTag = 0x1B001A00 の場合、HSE_ SRV_ RSP_ INVALID_ ADDR 応答を受け取りました。

その後、pInstAuthTagがまだUTESTを指している状態で、pAuthTagをRAMメモリに配置したところ、うまくいきました。セキュアブートがBOOT_SEQビットで有効化されると、セキュアブートは成功し、アプリケーションは動作します。HSEはUTEST DCFエリア内の署名を読み取ることができます。

テスト結果に基づくと、HSEファームウェアはアドレスpAuthTagがRAMまたはコード/データフラッシュメモリ内にあるかどうかをチェックし、UTESTのpInstAuthTagは受け入れられることが明らかです。

公式には文書化されていないが、効果はある。

しかし、署名を更新する予定がない場合は、HSE_SMR_CFG_FLAG_INSTALL_AUTHゼロのままにするオプションがあり、内部検証方式(内部ハッシュ)が検証に使われます。署名はインストール時のみに使用され、pInstAuthTagは無視されます。

私の意見では、イメージを更新する予定がない場合は、この設定の方が理にかなっています。また、検証もはるかに高速になります（ハッシュアルゴリズムとRSAアルゴリズムの比較）。これが、シンプルさを保ちつつパフォーマンスを向上させるための最良の方法でしょう。

HSE_SMR_CFG_FLAG_INSTALL_AUTHが設定されてpInstAuthTagを使用している場合、これは主にアプリケーションを簡単に更新したい場合のユースケースを対象としています。つまり、アプリケーションタグと認証タグが更新され、SMRを修正・再インストールする必要がなくなります。

DCFは停止レコード（すべて0xFF）までスキャンされ、残りは無視されます。通常、DCFエリアはユーザーデータ用に使われるべきではありませんが、ここでは問題が見当たりません。

UTESTの唯一の制約は、OTPエリアであるということです。また、ECCに関する同様の制限が適用されます（コードフラッシュやデータフラッシュと同様）。一度アラインメントされたダブルワードがプログラムされると、同じダブルワードを再度プログラムするとECCエラーが発生するため、再度プログラムしてはいけません。

よろしくお願いいたします。

ルーカス