ハイ
私たちは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スクリプトとログをご覧ください。
事前に感謝いたします。
こんにちは、
ご回答ありがとうございます。
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。
こんにちは、
ご提案ありがとうございます。ご要望に応じて、CRS(APP)のSecure Debug認証の問題を追跡するために新しい投稿を作成しました。
[S32N55 HSE2 — CRS(APPドメイン)セキュアデバッグ認証(hseDebugCardCmd_t経由)
(上記のタイトルをNXPコミュニティで検索してください)
この問題が現在、お客様の配達スケジュールを妨げています。できるだけ早く新しい投稿をご覧いただけますか?
CMMスクリプト（crs_auth.cmm）ログファイルは新しい投稿に添付されています。
緊急のサポートに心より感謝いたします。
こんにちは、 @EddiePark
投稿ありがとうございます。
S32N55プラットフォームのSecure Debug認証が、SDC-600経由でADKP(HSE_OTP_FOEM_ADKP_ATTR_ID)を用いてFSSドメインデバッグ認証を成功裏に実装したことを嬉しく思います。
引き続き、新しい問題の詳細確認をお手伝いいたします。添付のCMMスクリプトとログを確認できなかったことをお詫び申し上げます。よろしければ、再度アップロードして共有していただけますでしょうか？
BR
チェイン
こんにちは、 @EddiePark
ご返信ありがとうございます。
この投稿には既に6つの質問があり、調査には比較的長い時間がかかる可能性があります。効率を向上させるため、追加の質問については、追跡用の新しい投稿を作成することをお勧めします。
ご指摘のとおり、確認用のスクリプトやログが添付されているとのことですが、投稿には見当たりません。再度アップロードしていただけますでしょうか？
BR
チェイン
こんにちは、 @EddiePark
ご返信ありがとうございます。
1.いつも通り、ご質問にできる限りサポートいたします。
2. 緊急の問題であることは理解していますが、前回のサポートで述べたように、S32N55はまだプリプロダクション段階にあり、コミュニティチャネルでのサポートはまだされていません(この期間中は、効率化を加速するために直接FAE/代理店に連絡することをお勧めします)そのため、返信には比較的長い時間がかかります。さらに、 LC Advancedによるセキュアデバッグは通常、比較的開発の後期段階にあり、近年もドキュメントやサンプルは限られています。
ご迷惑をおかけして申し訳ございません。
BR
チェイン
こんにちは、 @EddiePark
ご辛抱いただきありがとうございます。以下に、参考までにいくつかの初期コメントを記載します。
[Q1]ADKPはCRSドメインのSecure Debug認証に使えますか?
[コメント]: はい、アプリドメインのセキュアデバッグ認証に使用される鍵はhseOwnerDebugKeyMapConfig_t->pOwnerCardAuthenticationRefから選択されており、ADKPのキーハンドルを含む可能性があります。
[Q2]SetOwnerDebugKeyMap()はMU(FSS MUとCRS MU)ごとに別々に呼び出す必要がありますか?
[コメント] : SetOwnerDebugKeyMap() は MU ではなく Device owner にバインドする必要があります。デバイス所有者は複数のコホートを含み、複数のMUインスタンスを持つこともあります。FSSとCRSが同じデバイス所有者に含まれている場合、CRS MUまたはFSS MUによって呼び出されることがあります。
[Q3]SetOwnerDebugKeyMap()は毎回起動するたびに呼び出す必要がありますか?
[コメント]: 毎回起動するたびに呼び出してはいけません。設定はSYS-IMGまたはヒューズに保存されるべきです。そうでなければ、デバイスの再電源後にセキュアデバッグが失敗し、セキュアデバッグの設計期待を満たしていません。しかし、現在利用可能なリソースからこの設定をどこに保存すればよいのか分かりません。
[Q4]正しいkeyRef値APP_CHALLENGE
hseDebugAuthorizeStartCmd_t では、keyRef フィールドは hseOwnerDebugKeyMapConfig_t を介してマッピングされたインデックスを参照します。aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKPをマッピングするため、CRSドメイン認証のためにkeyRef = 0x00を送信します。これは正しいですか？
[コメント]: はい、ADKPハンドルがOwnerCardAuthenticationRefの最初のエントリで、ユーザーがADKPを使ってCRDデバッグを認証したい場合、authKeyRefは0(ADKPハンドルエントリのインデックス)にすべきです。
[Q5] APP_CHALLENGEの応答サイズとパケット構造
[コメント]: App Debugでは、デバッグ信号マップとチャレンジ応答データに加え、パケット1の未使用データは0で埋めることができます。
対応する文書はまだこのテーマに完全には更新されていない(S32N55はまだ初期段階)ため、提供できる情報は限られています。
ご迷惑をおかけして申し訳ございません。
BR
チェイン
こんにちは、
改めて、皆様の継続的なご支援に感謝いたします。S32N55がまだプリプロダクション段階にあり、このトピックに関するドキュメントやリソースが限られていることは十分理解しています。追加の質問をして申し訳ありませんが、お客様の配達スケジュールが近づいており、これが重大な障害となるため、もう少し詳しいご助言をお願いしたいと思い申し上げます。
以前のコメント(Q1-Q5)を適用しました:keyRef=0x00、pOwnerCardAuthenticationRefのADKP、そしてパケット1は32バイトに埋められています(debugSignalMap 4B + appChallengeAuth 16B + unused 12B = 0)。
しかし、依然としてProofProv / CARD_REQUESTの段階で処理が滞っています。現在の状況：
1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) -> OK (HSE2 は 0x4A4A4A4A を返します)
2. APP_CHALLENGE -> OK（32バイトのチャレンジを受信しました）
3. ProofProv (hseDebugAuthorizeProofProvCmd_t):
- パケット 1 = debugSignalMap(4B=0) + appChallengeAuth(16B AES256-CMAC) + unused(12B=0)
- 32バイトすべてがSDC-600経由で正常に送信されました
- >>> この後、HSE2 から応答がありません <<<
SDC-600 TXは、約20バイト送信した直後に停止し、HSE2は応答フレームを一切送信しないようです。
APP(CRS)ドメイン認証の順序について、以下の点を説明していただけますか?
[Q1]ホストがProofProv(appChallengeAuth付きhseDebugAuthorizeProofProvCmd_t)APP_CHALLENGEを送った後、HSE2は中間応答フレームをホストに返しますか?それともHSE2は沈黙したまま、次のコマンドを待つのでしょうか？
参考までに、FSSドメインでは、ProofProvの後、HSE2は0x4A4A4A4Aを返します。APPドメインでは、そのような反応は観察されませんでした。これは想定内のことでしょうか？
[Q2]ProofProv(hseDebugAuthorizeProofProvCmd_t)とCARD_REQUEST(hseDebugCardCmd_t)の正しい順序はAPP_CHALLENGE?
- オプションA：APP_CHALLENGE -> ProofProv -> (HSE2応答？)-> カードリクエスト
- オプションB：APP_CHALLENGE → CARD_REQUESTに直接送信（APPの場合はProofProvをスキップ）
- オプションC：その他のシーケンス
RMはAPPではdebugSignalMapが「無視」され、認証は「デバッグカード認証のみで行われる」と述べているので、APPドメインに対してProofProvを送るべきでしょうか、それともチャレンジ後直接CARD_REQUESTに送るべきでしょうか?
[Q3]APP(CRS)ドメインのSecure Debug認証のCOMM_STARTから最終承認応答までの完全なコマンドシーケンスを教えていただけますか?
正確なコマンドの順序と、HSE2からの応答を期待するコマンドについて確認したいと思います。具体的には以下のとおりです。
COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE -> [ProofProv?] -> [CARD_REQUEST?] -> [最終応答?]
APP/CRSドメインに関する参照フローや例があれば大変助かります。現状の動作（ProofProv後のHSE2がサイレントになる）はFSSドメインのフローと一致しないためです。
ご理解とご支援に心より感謝いたします。
よろしくお願いいたします。
こんにちは、
ご返信ありがとうございます。理解しましたし、これからもずっと理解し続けます。サポートするよう努めています。
1.他の投稿から共有されたCMMと認証ファイルをダウンロードしました。S32N55 HSE2 CRSドメイン認証が完了しませんが、現在使われているものは今も同じものですか?
2. 下記の質問については、以下をご覧ください。
[Q1]hseDebugCardInfo_tの所有者ID(ownerId)は、hseOwnerDebugKeyMapConfig_tでプロビジョニングされた値と同じですか?
[コメント] : はい、hseDebugCardInfo_t の OID は、デバイス所有者インストールサービスの ownerid です。
[Q2]hseDebugCardCmd_t APP_CHALLENGE後に送る必要があるのか、それともhseDebugAuthorizeProofProvCmd_tの代わりに送る必要があるのか?
[コメント] : hseDebugAuthorizeProofProvCmd_t は CARD_REQUEST を送信する前に送信する必要があります
[Q3]MAC方式を使用する場合、hseDebugCardTag_tの正しい認証タグ(authTag)計算方法は何ですか?
[コメント]: API RM にこれに関する明確な説明がなくて申し訳ありません。しかし、App ドメインの認証タグは受け取ったチャレンジを使わず、チャレンジはhseDebugAuthorizeProofProvCmd_tに使われます。ユーザーのCRSドメインデバッグの場合、authTag = AES256-CMAC(key=ADKP, data=hseDebugCardInfo_t)かもしれません。試してみてはどうだ。
[Q4]hseDebugCardCmd_tの正しいパケット構造は何ですか?
[コメント]: hseDebugCardCmd_tの構造はHSE FW API インターフェースのコメントを参照でき、これはHSE FW API RMの説明よりも明確です。元のスクリプトを確認したところ、構造hseDebugCardCmd_tに関するいくつかの誤りが見つかりました。添付の単語を参照してください。
投稿内で共有するのが都合の悪いその他のファイルについては、プライベートメッセージで私に送ってください。
BR
チェイン