2410458_ja-JP

Yes

S32K312 Secureboot認証後のFBL変更

こんにちは、NXPさん。

以前同じ問題でお問い合わせしましたが、追加の支援が必要なので再度ご連絡いたします。私たちはS32K312 MCUを使用し、HSEバージョン2.6.0を使用しています。

問題：セキュアブートが有効になっている状態で、FBL（フラッシュブートローダー）を変更した後、ECUが正常に起動しない（アプリの実行ができない）。

hseImportKeySrv_t (HSE_SRV_ID_IMPORT_KEY) で確認したところ、KEY_EMPTY が返されました。さらに、Fota_S32k3_SecureBootProcess 内では、hseRequestResult の値が KEY_EMPTY として返されるため、retVal が 1 (NOT_OK) になります。この認証が失敗するため、SMR Verifyは失敗しています。

SMR検証に必要な鍵注入は、CMAC、RSA、ECDSAを用いたSU(スーパーユーザー)権利認証を試みましたが、そのような権限を取得するには認証キーが必要であることを理解しており、その鍵は特定できていません。また、IVTセクターの消去も試みましたが、ライフサイクルがIN_FIELDに設定されているため、これも不可能でした。

質問:

1. SUに権限を付与する方法はありますか？(つまり、認証キーを調べたり取得したりすることは可能でしょうか?)

2. 以前のブートローダーをフラッシュすると正常に実行されることから、古いMETA値がHSE内にまだ残っているということでしょうか？

3. Crypto_Hse_GetKeyInfo(FOTA_HSE_MU0_INSTANCE, Crypto_aKeyElementList[ElementIndex].u32HseKeyHandle) を実行したところ、Crypto_aKeyElementList[ElementIndex].u32HseKeyHandle の値は 66305 として返されました。これはHSEメモリ/スロット/ハンドルの不一致を示し、それがSMR検証の失敗の原因となるのでしょうか?(つまり、HSEメモリ/スロット/ハンドルの不一致が根本原因なのでしょうか?)

4. SU認証キーを入手できず、フォーマットキーカタログもこの州でサポートされていない場合、現在IN_FIELDライフサイクル状態で部分的に失われたキーカタログを持つこのデバイスを適切に復旧するための公式なNXP復旧手順(例:Secure Debug認証、RMA、または別のベンダープロビジョニング手順)が存在するかご助言いただけますか?

サポートにあらかじめ感謝いたします。

Re: S32K312 Change FBL after Secureboot authentication

ルーカスは現在休暇中なので、その間に皆さんの質問にお答えします。

Q1:SU権限はIN_FIELDでチャレンジレスポンス(HSE_SRV_ID_SYS_AUTH_REQ / HSE_SRV_ID_SYS_AUTH_RESP)で取得可能ですが、IN_FIELDに進む前にCUST/OEM認可キーがプロビジョニングされている場合に限ります。もしプロビジョニングされていなかったり、秘密鍵が外部に保持されていなければ、SU権限は取得できず、鍵の取得もできません。

Q2: 古いFBLが正常に動作していることから、HMACキーと元の認証タグはHSE SYS-IMGにまだ残っている可能性が高いです。もしそうなら、新しいFBLは認証タグが古いバイナリ上で計算され、新しいものと一致しなくなったため失敗しているはずです。新しいFBLコンテンツを使用してHSE_SRV_ID_SMR_ENTRY_INSTALLを再実行すれば問題は解決しますが、SU権限が必要です。これがあなたの設定に合っているか確認してもらえますか?

Q3:ハンドル66305(0x10301)をNVMカタログ、グループ3、スロット1にデコードしますが、これは空のようです。これは、HMACキーが別のスロットにプロビジョニングされている可能性があり、新しいFBLのFOTAコードが誤ったハードコードされたハンドルを参照していることを示唆しています。まず最初に、元の HSE_SRV_ID_SMR_ENTRY_INSTALL 呼び出しの authKeyHandle と、新しい FBL の FOTA コードが参照している authKeyHandle を比較してください。おそらく両者は異なっているはずです。しかし、あなたの全構成を見ないと確実に言えません。

Q4: 選択肢は2つあります。(1) CUST/OEM認可キーがプロビジョニングされている場合、SU権利に対してチャレンジレスポンスを使用。(2) ADKPがプロビジョニングされている場合、Secure Debug認証はJTAGを診断用にのみアンロックし、HSE NVMの書き込みは解除しません。