2387055_ja-JP

Yes

S32N55 HSE2 — ADKPを用いたCRS(APP)ドメインセキュアデバッグ認証

ハイ

私たちはS32N55プラットフォーム向けのSecure Debug認証に取り組んでおり、SDC-600経由でADKP(HSE_OTP_FOEM_ADKP_ATTR_ID)を用いてFSSドメインデバッグ認可を成功裏に実装しました。

現在、これをCRSドメイン（HSE_DEBUG_DOMAIN_APP = 0x1B）に拡張しようとしており、以下の質問があります。

---

[Q1]ADKPはCRSドメインのSecure Debug認証に使えますか?

HSE_OTP_FOEM_ADKP_ATTR_ID経由でADKPをプロビジョニングした後、HSE_DEBUG_CMD_APP_CHALLENGEを通じてCRSドメイン(APP)のSecure Debug認証に同じADKPを使用することは可能でしょうか?

---

[Q2]SetOwnerDebugKeyMap()はMU(FSS MUとCRS MU)ごとに別々に呼び出す必要がありますか?

hseOwnerDebugKeyMapConfig_t の RM の説明によると、次のようになります。
「このサービスは、所有するMUから、インストールされている各デバイスの所有者ごとに個別に呼び出されます。」
HSE FWは、このサービスリクエストが送信されたMUに基づいて所有者IDを推測します。

現在の実装では、SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING) は FSS MU (MU0) を介してのみ呼び出され、aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP にマッピングされます。

- CRSドメイン認証のためにCRS MUを経由した別のSetOwnerDebugKeyMap()呼び出しが必要ですか?
- もしそうなら、S32N55のCRSドメインにはどのMU番号を使うべきでしょうか?

---

[Q3]SetOwnerDebugKeyMap()は毎回起動するたびに呼び出す必要がありますか?

RMには次のように記載されています。
「numOfAuthorizationRefEntries と numOfAuthenticationRefEntries のみがログに記録されます。」
残りのエントリは無視されます。

これは、キーマッピングが揮発性であり、NVMには保存されないことを意味します。これは、FSSドメインとCRSドメインの両方において、起動時（SU権限が付与された後）に毎回SetOwnerDebugKeyMap()を呼び出す必要があるという意味でしょうか？

---

[Q4]正しいkeyRef値APP_CHALLENGE

hseDebugAuthorizeStartCmd_t では、keyRef フィールドは hseOwnerDebugKeyMapConfig_t を介してマッピングされたインデックスを参照します。aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKPをマッピングするため、CRSドメイン認証のためにkeyRef = 0x00を送信します。これは正しいですか？

---

[Q5] APP_CHALLENGEの応答サイズとパケット構造

hseDebugAuthorizeProofProvCmd_t バイトマップによると、パケット構造は常に 32 バイト (2 パケット x 8 ワード) です。HSE_CR_APP_RESPONSE_SIZE = 16U 対 HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U。

APP_CHALLENGEの場合、ホストは以下を送るべきです:
- AES暗号化レスポンス16バイト+ゼロパディング16バイト=合計32バイト?
- それとも16バイトだけ?

現在、FLAG_START + DebugSignalMap(4バイト) + Response(16バイト) + FLAG_END を送信した後、HSE2 は応答せず、T32 は無期限に待機状態になります。32バイト（16バイトの応答＋16バイトのゼロパディング）を送信した場合も、同様のハングアップが発生します。

---

参考までに：
- Sherpa_Cdd_AllocateChannel() は常に MU0 (FSS) を割り当てます
- SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302)、SU権限で呼び出されました
- crs_auth.cmm:DEBUG_TARGET=0x1B、OID=0xFF*16、keyRef=0x00
- AUTH_MODE_REQ が正常に通過しました (HSE_DEBUG_WAITING_RESPONSE_TO_CHG を受信しました)
- チャレンジ受信: 32バイト
- レスポンスを送信した後、HSE2からACK（0x4A4A4A4A）を受信しませんでした。

参考資料として、添付のCMMスクリプトとログをご覧ください。

事前に感謝いたします。

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

こんにちは、

ご回答ありがとうございます。

S32N55 hseDebugCardCmd_t CRS(APP)ドメインSecure Debug認証の実装について追加の質問があります。

---

[Q1]hseDebugCardInfo_tの所有者ID(ownerId)は、hseOwnerDebugKeyMapConfig_tでプロビジョニングされた値と同じですか?

当社のデバイスは、Fss_Firmware_au8Oid[] = {0xFF * 16} となるシングルオーナーシナリオで構成されています。
hseDebugCardCmd_t の ownerId フィールドも 0xFF * 16 に設定すべきでしょうか？
それとも、デバイスオーナーのインストール時に設定された特定の値と一致させる必要があるのでしょうか？

---

[Q2]hseDebugCardCmd_t APP_CHALLENGE後に送る必要があるのか、それともhseDebugAuthorizeProofProvCmd_tの代わりに送る必要があるのか?

RMによると:「APPベースのオプションでは、デバッグ信号はデバッグカード認証(hseDebugCardCmd_t参照)のみ有効かつ承認されます(フィールドは無視されます)。」

現在のフロー：
1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B)
2. rx_authmode → HSE_DEBUG_WAITING_RESPONSE_TO_CHG を受信しました
3. APP_CHALLENGE → rx_challenge (32バイト受信)
4. hseDebugCardCmd_t を直接送信します (hseDebugAuthorizeProofProvCmd_t はスキップされます)
5. HSE2が応答しなくなる（T32がCARD_REQUESTのFLAG_ENDでハングアップする）

hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC) は、hseDebugCardCmd_t より前に送信する必要がありますか？
それとも、ProofProvなしでrx_challengeの直後にhseDebugCardCmd_tを送信すべきでしょうか？

---

[Q3]MAC方式を使用する場合、hseDebugCardTag_tの正しい認証タグ(authTag)計算方法は何ですか?

私たちは以下を使用しています：
authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11)
authTag = AES256-CMAC(key=ADKP, data=Challenge[32 bytes])
認証長 = 16

この計算は正しいですか？あるいは、CMACの入力には追加のフィールド（OID、ドメインマップなど）を含めるべきでしょうか？

---

[Q4]hseDebugCardCmd_tの正しいパケット構造は何ですか?

RMバイトマップに基づくと、現在の実装は次のようになります。
パケット 1 (32 バイト): KRI(4B) + CMD(4B=0x5DCDEB77) + OID(16B=0xFF*16) + AuthScheme(8B=CMAC)
パケット 2 (32 バイト): enabledDebugDomainMap(bit27=0x08000000) + padding(28B)
パケット 3: debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B)

この構造は正しいですか？HSE2はOIDフィールド（0xFFバイト）を受信した後に応答を停止します。

---

CANメールアドレスを教えていただけませんか?CRS認証用のCMMファイルを送付します。

BRs。

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

こんにちは、

ご提案ありがとうございます。ご要望に応じて、CRS(APP)のSecure Debug認証の問題を追跡するために新しい投稿を作成しました。

[S32N55 HSE2 — CRS(APPドメイン)セキュアデバッグ認証(hseDebugCardCmd_t経由)
(上記のタイトルをNXPコミュニティで検索してください)

この問題が現在、お客様の配達スケジュールを妨げています。できるだけ早く新しい投稿をご覧いただけますか?

CMMスクリプト（crs_auth.cmm）ログファイルは新しい投稿に添付されています。

緊急のサポートに心より感謝いたします。

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

こんにちは、 @EddiePark

投稿ありがとうございます。

S32N55プラットフォームのSecure Debug認証が、SDC-600経由でADKP(HSE_OTP_FOEM_ADKP_ATTR_ID)を用いてFSSドメインデバッグ認証を成功裏に実装したことを嬉しく思います。

引き続き、新しい問題の詳細確認をお手伝いいたします。添付のCMMスクリプトとログを確認できなかったことをお詫び申し上げます。よろしければ、再度アップロードして共有していただけますでしょうか？

BR

チェイン

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

こんにちは、 @EddiePark

ご返信ありがとうございます。

この投稿には既に6つの質問があり、調査には比較的長い時間がかかる可能性があります。効率を向上させるため、追加の質問については、追跡用の新しい投稿を作成することをお勧めします。

ご指摘のとおり、確認用のスクリプトやログが添付されているとのことですが、投稿には見当たりません。再度アップロードしていただけますでしょうか？

BR

チェイン

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

こんにちは、 @EddiePark

ご返信ありがとうございます。

1.いつも通り、ご質問にできる限りサポートいたします。

2. 緊急の問題であることは理解していますが、前回のサポートで述べたように、S32N55はまだプリプロダクション段階にあり、コミュニティチャネルでのサポートはまだされていません(この期間中は、効率化を加速するために直接FAE/代理店に連絡することをお勧めします)そのため、返信には比較的長い時間がかかります。さらに、 LC Advancedによるセキュアデバッグは通常、比較的開発の後期段階にあり、近年もドキュメントやサンプルは限られています。

ご迷惑をおかけして申し訳ございません。

BR

チェイン