Securebootが有効になっている状態で別のFBLに変更すると、HMACキーを介して生成されるMETAデータ値が変更されます。FBLが変更されると、HSEはHMACキーを使用してメタデータを再計算する必要があります。しかし、新しいFBLによってHMACキーが削除されるため、メタデータの再計算が不可能になります。その結果、FBLでの検証失敗によりリセットが発生し、アプリケーションの起動が不可能になります。HMACキーを使って変更されたFBLを再認証し、FBLとアプリケーションの両方が正常に動作できるようにする方法はありますか?
HSE_SRV_ID_SMR_ENTRY_INSTALL サービスを実行すると、HseResponse は 0xA5AA5317 を返します。これは以下の定義に相当します。
#define HSE_SRV_RSP_KEY_EMPTY ((hseSrvResponse_t)0xA5AA5317UL)
これは、鍵が空であることを示しています。（以前にも質問したように、この応答が表示されるのは、その領域が削除されたためではないかと推測しています。）
smrEntryの値を確認しました。SecureBootStateが0になる箇所にブレークポイントを設定したところ、smrEntryが完全に0であることを確認しました。Fota_S32k3_SecureBootProcessが終了する戻り点にブレークポイントを設定したところ、値が表示されることを確認しました。帰還時のSecureBootStateの値は1でした。
キーの注入方法やこの問題の解決方法について、ぜひご案内いただけると大変ありがたいです。
1) if(SecureBootState == 0) にブレークポイントが設定された場合 / 結果: smrEntry = 0
2) Fota_S32k3_SecureBootProcess 関数の最後の部分である return secureBootProcessResult にブレークポイントを設定します。
NVMおよびRAMキーカタログ内で宣言されたすべての暗号鍵は、鍵タイプHSE_KEY_TYPE_SHEを除き、プロビジョニング可能です(すなわち、ホストによって初期化および更新されるキーインポートサービスは、構造体 hseImportKeySrv_t で定義されます。
SHE鍵はホストがサービスhseSheLoadKeySrv_tまたはhseSheLoadPlainKeySrv_tを通じて提供します。鍵は上記の図のようにプレーンテキストまたは暗号化テキストでインストールでき、デモではすべてのキーがプレーンテキストでインストールされています。
\S32K3_HSE_DemoExamples\にあるS32K344_Update_NVM_keys_related_testに関するリファレンスコードを試してみましたか？
こんにちは、 @jeongwoo
現在、さらなる進展を阻んでいる主な問題は、HMACキーがまだ利用可能かどうか不明であることのようです。
まず最初に、先ほど提案した検査を行ったか、また結果を教えていただけますか?
「キーが消去されているかどうかを確認するには、サービスHSE_SRV_ID_GET_KEY_INFO、構造構造hseGetKeyInfoSrv_tを使えます。このサービスを使うと、hseKeyInfo_tの情報を得られるので、キーの状態を確認できます。」
キーの状態を確認したら、次のステップに進めます。もしキーが欠けているか消去されていれば、再インストールを試みることができます。あるいは、プロビジョニング時に最初に使った手順と同じ手順でキーを直接インストールしてみて、操作が成功するかどうかを確認することもできます。
よろしくお願いいたします。
ルーカス
鍵はHSEサービスHSE_SRV_ID_IMPORT_KEYによってインポートまたは更新可能です。
HSEファームウェアのリファレンスマニュアルのこれらの表を見てみてください。2.7:
表47。NVMキーカタログの空きスロットにキーをインポートする際のキープロビジョニングの使用方法
表48。NVMキーカタログ内のキー（空きスロット以外）を更新する際のキープロビジョニングの使用
これにより、鍵を単純にインポートできる場合や認証や暗号化が必要な場合が説明されます。
キースロットが空でSU権限がある場合、認証なしで単純にインポートできます。キースロットが空でない場合(鍵を更新している場合)、そしてSU(鍵の更新)権限がある場合、認証は必須で暗号化は任意です。
ユーザー権限のみの場合、スロットが空いているかどうかに関わらず認証と暗号化が常に義務付けられます。
S32K344_Update_NVM_keys_related_test の例では、認証済みキーのインポートに必要なキーコンテナを準備して署名する方法のみを示しています。しかし、この例ではキーはインポートされていません。
鍵のインポートは、例えばS32K344_AES_EncryptDecrypt関数で示されています。このプロジェクトでAESキーに使われているAPIはLoadAesKeyです。HMACについては、LoadHmacKey APIがあります。認証や暗号化なしで、HMAC鍵を平文でインポートするために使用できます。
Cryptoドライバーを使用する場合、API Crypto_43_HSE_KeyElementSetとCrypto_43_HSE_KeySetValidを使って鍵をインポートできます。
RTDのソフトウェア例(またはRTDバージョンによっては類似)を確認できます。
c:\NXP\SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP02\eclipse\plugins\Crypto_43_HSE_TS_T40D34M70I0R0\examples\S32DS\S32K3XX\Crypto_43_HSE_SymmetricPrimitives_S32K388\
Cryptoモジュールにはスーパーユーザー権利を要求するAPIはありません。
手順はHSEファームウェアリファレンスマニュアルrevの「8.5 スーパーユーザー権利の要求」セクションで説明されています。2.7.
ファイルhse_crypto.cの関数Grant_SuperUser_Rights()に従うこともできますこれはHSEのDemoExamplesパッケージで見つけることができます:
https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples
よろしくお願いいたします。
ルーカス
こんにちは、ルーカス
Crypto_hse.c で、ご指摘いただいた HSE_SRV_ID_GET_KEY_INFO API を定義し、呼び出しました。
しかし、GetKeyInfoのIf文は入力されていないため、KeyInfoの値を参照できません。キーが欠けているか消去されている場合は、再度インストールを試すことができます。
あるいは、プロビジョニング時に使った手順と同じ手順でキーを直接インストールし、その操作が成功したかどうかを教えてもらえますか?
新しいHSEをインポートし、ライフサイクル・インフィールドに別のFBLを追加することで作業を進めました。SU特権はどうやって取得できますか?