2414836_ja-JP

はい

S32K3xxマスターECUキーまたはCUST/OEM認証キーのインポート

こんにちは、NXPさん。

いつもサポートしてくださりありがとうございます。

FBL関連のお問い合わせに対する以前のご回答に基づき、ライフサイクルがインフィールド状態にある場合、スーパーユーザー（SU）権限を取得するには、MASTER_ECU_KEYまたはCUST/OEM認証キーのいずれかを事前にプロビジョニングしておく必要があり、デバイスが既にインフィールド状態にある場合は、MASTER_ECU_KEYのプロビジョニングは不可能であると理解いたしました。

私たちの理解が正しいか確認していただけますか?

現在、これら2つのキーはどちらもプロビジョニングされていません。今後同様の問題が起きないように、MASTER_ECU_KEYまたはCUST/OEM認証キーのいずれかを事前にプロビジョニングし、NVM/RAMキーカタログをフォーマットし、デバイスがインフィールド状態に入った後にHMACキーを注入できるようにしたいと考えています。

いくつか質問があります。

1.このプロジェクトでは、FBL認証はSHEに基づいていません。その代わりに、RSA公開鍵署名検証方式を採用している。ただし、CRYPTO_SPT_SHE は STD_ON に設定されています。
この場合、MASTER_ECU_KEYをプロビジョニングすべきか、それともCUST/OEM認証キーをプロビジョニングすべきか?

2. MASTER_ECU_KEYやCUST/OEM認証キーのインポート方法を説明するガイドやドキュメントはありますか?
ありがとうございます。

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

Re: S32K3xx Master_ECU_KEY or CUST/OEM authorization key import

こんにちは、 @jeongwoo

認証キーは、現在のライフサイクルと、操作に使用するキーの所有者に応じてプロビジョニングする必要があります。

CUST_DELでは、CUST認証キーをプロビジョニングできます。デバイスをOEM_PRODに進めると、OEM認証キーをプロビジョニングし、それを使ってOEM所有キーのスーパーユーザー権を取得することができます。

CUST_DEL中はOEM所有の鍵をプロビジョニングすることはできません。なぜなら、その時点で操作を承認できるOEM認可キーが持っていないからです。したがって、必要な所有者向けのキーカタログは、デバイスがライフサイクルを進める前に、CUST_DEL状態にある間に既に定義しておく必要があります。

OEM_PRODに移行した後は、キーカタログのフォーマットがCUST_DELに制限されるため、カタログの再フォーマットはできません。このライフサイクルの移行は不可逆的である。

ですので、CUSTとOEMの両方の認可機能を持つつもりなら、まずカタログで必要なCUSTおよびOEMキーグループを定義し、CUST_DELでCUST認証キーをプロビジョニングし、OEM_PRODに進み、最後にOEM認証キーをプロビジョニングしてください。

詳細はこのスレッドをご覧ください:

https://community.nxp.com/t5/S32K/Change-is-not-possible-in-LC-OEM-PROD/m-p/2356576

HSEレベルでは、キーインポート手順はHSE-Bファームウェアリファレンスマニュアルの「6.2.3 キーインポート」セクションで説明されています。2.8の後に、HSEファームウェアバージョンのHSE Service APIリファレンスマニュアルにある「struct hseImportKeySrv_t」の説明を参照してください。

On AUTOSAR Crypto ドライバ level, it is given by AUTOSAR specification.Crypto_43_HSE_KeyElementSet()およびCrypto_43_HSE_KeySetValid()APIの説明はRTD_CRYPTO_43_HSE_UM.pdfで読むことができます。

認証キーは他のキーと同様の方法でインポートされますが、コンフィギュレータでそのキーに対してUSAGE_AUTHORIZATIONとUSAGE_VERIFYのキーフラグを設定する必要があります。

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

ルーカス