NXPチームの皆様、こんにちは。
AN14003 に従って、KW45B41Z83A の量産フローを開発しています。SB3 の生成とフラッシュ プロセスは動作していますが、デバッグ認証フローで重大な問題が発生しています。これは、不完全なヒューズ プロビジョニング シーケンスが原因だと考えています。
環境:
MCU: KW45B41Z-EVKボード上のKW45B41Z83A
プローブ: J-LinkファームウェアでフラッシュされたオンボードMCU-Link
SPSDK バージョン: 3.1.0
J-Link バージョン: V8.12a
問題の説明:このテストの対象ボードは、 OEM SECURE WORLD CLOSED状態です。nxpdebugmbox -i jlink dat auth コマンドを実行すると、暗号化ハンドシェイクは成功したように見えます (DAC/DAR 交換が正しくログに記録され、RoT ハッシュが一致しています) が、最終的にコマンドは失敗し、AHB へのアクセスが許可されません。J-Link Commander との後続の接続試行は、「エラー: 間違った DM-AP IDCODE が検出されました: 0xFFFFFFFF」というエラーで失敗します。
ターゲット ボードのプロビジョニングに関する重要な情報:ボードは不完全な手順を使用して OEM SECURE WORLD CLOSED 状態に移行されました。私の同僚は、別のアプリケーション ノート (AN14158) で推奨されているシーケンスの最初のコマンドのみを実行しました。
ライフサイクルを進めるために、blhost -p COMX fuse-program 0xa 0xf が実行されました。
重要なのは、このコマンドの直後にボードが手動でリセットされたことです。
TZM_EN (ヒューズ 0xd) 、SB3KDK (ヒューズ 0x20)、および RoTKTH (ヒューズ 0x1f) をプログラムするシーケンスからの後続のヒューズ プログラム コマンドはスキップされました。
その結果、ボードは SECURE ライフサイクル状態にありますが、この状態で適切に動作するために ROM に必要なその他の重要なヒューズ構成が欠落している可能性があります。
私の核心的な質問:この不完全なプロビジョニング手順 (TZM_EN ヒューズをプログラムせずにライフサイクルを OEM SECURE WORLD CLOSED に進めるなど) が、AHB へのアクセスが許可されないエラーの根本原因である可能性はありますか?ROM ブートローダのデバッグ認証メカニズムは、認証の暗号化部分が成功した場合でも、これらの他のヒューズが正しく設定されていることに依存しますか?
すべてのキー、証明書、cc_socu 構成が正しいことが確認されているため、これが最も可能性の高い原因であると思われます。
完全かつ正しい手順を使用して別の OEM OPEN ボードをプロビジョニングする準備をしていますが、このマターについては専門家の確認をいただければ幸いです。参考までに、設定ファイルとキーログファイルを添付します。
ご指導ありがとうございます。
デバッグログ情報を添付します：
うまく動作したと聞いてうれしいです!
最後に、SEC ツールを引き続き使用することもCAN、自動的に生成されるスクリプトを使用して本番環境に移行することも可能です。もちろん、私が提案する主な変更はキーを変更することです。新しいキーを生成することも、製品キーをインポートすることもできます (ツールが認識できるように、同じ命名規則を使用するだけです)。HSM を使用しており、秘密キーに直接アクセスできない場合は、署名プロバイダを使用して HSM に接続し、シームレスに公開キーのみを提供することもできます。
こんにちは@Sabina_Bruce 、
素晴らしいニュースです！問題が解決したことをお知らせするためにフォローアップさせていただきます。
SEC GUI ツールを使用するというあなたの提案が成功の鍵でした。私はこれを使用して新しい OEM OPEN ボードをプロビジョニングしましたが、ツールがプロセスを完璧にガイドしてくれました。
ボードがOEM CLOSEDライフサイクル状態に正常になっていることを確認できます。さらに重要なことは、既存のスクリプトと構成を使用してデバッグ認証プロセスが完璧に機能していることです。
貴重なサポートとご指導をいただき誠にありがとうございます。あなたの助けがなければ、これを解決することはできなかったでしょう。
よろしくお願いいたします。
ヤベツ
こんにちは@JabezLaw
EVK に同じキーがあるため、dat_config.yaml を直接テストしました。私の側では動作します。
以下の点を確認します。
1. デバイスは正常に起動しますか?つまり、イメージに署名し、通常通りHello WorldまたはBlinkyを起動します。
2. アプリケーションの実行中に、再度デバッグ認証を試みます。デバイスが ISP モードになっていないことを確認してください。
3. テストできる別の EVK はありますか?もしSOなら、この EVK でテストする前に、ライフサイクルを Closed に進めて現在の EVK でテストし、動作が異なるかどうかを確認します。
4. 新しい EVK で再テストする場合は、ヒューズをプログラムする前にエラーや警告を通知するSEC GUI ツールを使用することをお勧めします。これは、SPSDK コマンドライン ツールで見逃された可能性のあるものを特定するのに役立ちます。
EVK で使用されるキーは、[キーのインポート] ボタンを使用して簡単にインポートCAN、PC のパス「C:\nxp\MCUX_Provi_25.06\bin\_internal\data\sample_data\targets\K32W148」に移動します。ここには、KW456 および K32W148 用の board_example_keys フォルダーが含まれています。
こんにちは@Sabina_Bruce 、
CC_SOCU ビットマスクの詳細な説明をありがとうございます。これは非常に役立ち、デバッグ認証情報がデバイスの融合されたセキュリティ ポリシー上でフィルターとしてどのように機能するかを明確にします。あなたの解釈は完全に理にかなっています。
ご提案どおり、お客様の側でテストできるように完全なワークスペースを準備しました。あなたの便宜のために、フォルダーをクリーンアップし、Jupyter Notebook スクリプト内のすべてのコメントを英語に翻訳しました。
圧縮されたワークスペースはこの投稿に添付されています。メイン スクリプトのパスは、「KW45_Debug_Auth_Workspace_JabezLaw\sb\kw45xx_k32w1xx\debug_authentication_kw4s.ipynb」です。
よろしくお願いいたします。
ヤベツ
こんにちは@JabezLaw
CC_SOCU を 0x0000 に設定すると、「証明書所有者」がデバイスで許可されているアクセス権を取得できなくなります。
これにより、たとえば、すべてのポートを開くことを許可しながら、技術者 A には特定のポートのみをデバッグさせ、技術者 B には別のポートのみをデバッグさせ、さらにアクセス権を許可または拒否することができます。特定のビット フィールドに 1 を設定すると、そのフィールドに対するデバイスのセキュリティ レベルに従うことになり、特定のビット フィールドに 0 を設定すると、デバイスのセキュリティ レベルに関係なくアクセスが禁止されます。
あなたのワークスペースと私のワークスペースの主な違いは、ライフサイクルのステージです。第二開発段階をテストしていますか?セキュアワールドを閉じることは、最終的な本番ライフサイクルでは推奨されませんが、これによってデバッグ認証セッションの成功が妨げられることはありません。ただし、それが私が気づいた主な違いです。
私の側での結果は次のとおりです。
デバッグ認証が機能するために焼き切る必要のある他のヒューズはありません。
ワークスペースを zip ファイルに圧縮してここに追加していただければ、ワークスペースをテストCAN。
こんにちは@Sabina_Bruce 、
ご提案ありがとうございます。これを調べるのに時間を割いていただきありがとうございます。
私はあなたのアドバイスに正確に従いました。dc_config.yaml を変更して cc_socu: '0xFFFF' を設定し、デバッグ資格情報を再生成し、OEM SECURE WORLD CLOSED ボードで完全なパワーオン リセット (POR) を実行してから、認証コマンドを再実行しました。
残念ながら、結果は以前の試みと同じでした。暗号化ハンドシェイクは成功したように見えますが、プロセスは最終ステップでまったく同じエラーで失敗します: AHB へのアクセスは許可されていません。
この結果は、セキュリティ リファレンス マニュアル (KW45SRM) の表 91に記載されている KW45 セキュリティ モデルに関する私の理解と一致しています。私の解釈は次のとおりです。
デバイスのヒューズ (DCFG_CC_SOCU_L1 = 0x00000000) は、デバッグ ドメインをレベル 1に構成します (デフォルトでは無効ですが、認証によって有効にすることができます)。
デバッグ資格情報で cc_socu を 0xFFFF に設定すると、レベル 0アクセス (常に有効) の要求が作成されます。
これにより、要求された権限とデバイスの実際の融合状態の間に論理的な矛盾が生じ、当然ながら失敗が発生します。
論理的に正しい要求 (cc_socu: '0x0000') と最大権限要求 (cc_socu: '0xFFFF') の両方が同じ「AHB へのアクセスが許可されない」エラーにつながるため、問題は cc_socu 値自体にはないことが強く示唆されます。
根本的な問題は、認証の暗号化部分が成功した後でも、ROM が AHB アクセスを許可しないことを決定していることのようです。
安全なライフサイクル状態で AHB アクセスを許可するためのマスター ゲートとして機能する、別のヒューズ設定または欠落している前提条件がある可能性がありますか?
分析用に、cc_socu: '0xFFFF' を使用した最新のテストからのログ ファイルを添付しました。さらに詳しい情報をCANいただければ幸いです。
よろしくお願いいたします。
ヤベツ
こんにちは@JabezLaw
DC_CONFIG.YAML を見ると、CC_SOCU をすべて 0x0 に設定して、すべてのデバッグ ポートを事実上無効化/禁止しています。すべてを有効にするには、ビット マスクを 0xFFFF にする必要があります。この変更を加えて再試行してください。また、試行の間に必ず POR を実行してください。失敗したデバッグ セッションを試行した場合、POR まで失敗として表示され続けます。
こんにちは@nxa17177さん、
フォローアップと AN14158 を紹介していただきありがとうございます。
はい、 AN14158 (「KW45/K32W148 でのデバッグ認証」) を再度注意深く確認し、ワークフローがセクション 5.5 (「デバッグ資格情報と認証」) で概説されている手順と完全に一致していることを確認できました。
正確に言うと、検証したプロセスの概要は次のとおりです。
キーとヒューズは正しいです: RoT キーと SB3KDK は正しいです。これは、（1） SB3ファイルを正常にフラッシュする能力（両方のキーに依存）と、 （2） DAC応答でデバイス自体によって報告された一致するRoTKTHによって証明されています。
構成は正しいです: dc_config.yaml は cc_socu: '0x0000' を正しく使用しており、dat_config.yaml は正しい証明書と secp384r1 秘密キーを指しています。
ツールチェーンは正しいです:最新の SPSDK (v3.1.0) を使用しています-i jlink バックエンドを使用し、推奨どおりにプローブに J-Link ファームウェアがフラッシュされます。
この正しい設定にもかかわらず、プロセスは最終ステップで常に失敗します。以下のログは、暗号ハンドシェイクが成功した後すぐに失敗したことを明確に示しています。
実行ログ (nxpdebugmbox -i jlink -v dat auth ...):
INFO:spsdk.apps.nxpdebugmbox:Starting Debug Authentication ... INFO:spsdk.apps.nxpdebugmbox:DAC: Version : Version 2.1 SOCC : 0x00000005 UUID : F33B5C9F4E9D897FB8B55A95AA388692 ROTID_rkth_hash : 650d8097079ff27a3e8a2da14781b922fd8295b6c00bfa067f00e87f1a16b8b3 ... INFO:spsdk.apps.nxpdebugmbox:============================================== DAC versus DC (Warning) =============================================== ... RoT Hash(Succeeded): 650d8097079ff27a3e8a2da14781b922fd8295b6c00bfa067f00e87f1a16b8b304bf710d45cbd591e2e24be83183922c ... INFO:spsdk.apps.nxpdebugmbox:DAR: ... Debug Authentication ends without AHB access. SPSDKAppError: Debug Mailbox authentication failed: SPSDK: Problem with debug mailbox occurred: Access to AHB is not granted.
認証の暗号化部分は成功したように見えるため、失敗はツールが実際にバス アクセスを取得する最終ステップで発生したようです。したがって、私の核心的な疑問は残ります。
KW45 ROM または J-Link ドライバの相互作用内のどのような特定の条件により、暗号化ハンドシェイクが成功した後にAHB へのアクセスが許可されないという失敗が発生するのでしょうか?
この問題は、当社の安全な開発ワークフローの最終的な障害であり、この特定の AHB アクセスの問題について提供できる具体的な洞察は非常に役立ちます。
宜しくお願い致します、JabezLaw
こんにちは@JabezLaw 、何か矛盾点を見つけましたか？ https://www.nxp.com/products/KW45?tid=vanKW45#documentationを参照してください: KW45/K32W148 でのデバッグ認証[AN14158] フロー内にありますか?
こんにちは@nxa17177さん、
調べていただきありがとうございます。デバッグ資格情報を生成し、認証を試行するために使用している構成ファイルと正確な手順は次のとおりです。
ステップ1: デバッグ資格情報キー（DCK）を生成する
まず、次のコマンドを使用して、デバッガー (DCK) 用の secp384r1 キー ペアを生成しました。
nxpcrypto key generate -k secp384r1 --force -o keys/dck_keypair_384.pem
ステップ2: デバッグ資格情報(DC)証明書を生成する
次に、デバッグ証明書を定義するための dc_config.yaml ファイルを作成しました。構成では、署名に EVK の secp384r1 RoT キーを正しく使用し、手順 1 で生成された secp384r1 DCK 公開キーを指します。
dc_config.yaml:
family: kw45b41z8 revision: latest uuid: '00000000000000000000000000000000' cc_socu: '0x0000' cc_vu: 0 cc_beacon: 0 rot_meta: - ../../_data/keys/EVK_keys/RoT_key0_secp384r1_kw45xx.pub - ../../_data/keys/EVK_keys/RoT_key1_secp384r1_kw45xx.pub - ../../_data/keys/EVK_keys/RoT_key2_secp384r1_kw45xx.pub - ../../_data/keys/EVK_keys/RoT_key3_secp384r1_kw45xx.pub rot_id: 0 dck: ../keys/dck_keypair_384.pub signer: ../../_data/keys/EVK_keys/RoT_key0_secp384r1_kw45xx.pem
この設定を使用して最終的な証明書ファイル（debug_auth.bin）を生成しました。コマンド: nxpdebugmbox dc export -c workspace/dc_config.yaml -o workspace/debug_auth.bin
ステップ3: デバッグ認証を試みる
最後に、これは nxpdebugmbox dat auth コマンドで使用する dat_config.yaml です。これは、ステップ 2 で生成された証明書とステップ 1 の DCK 秘密キーを指します。
dat_config.yaml:
family: kw45b41z8 revision: latest certificate: workspace/debug_auth.bin beacon: 0 srk_set: oem signer: ../keys/dck_keypair_384.pem
この詳細な内訳により私の手順が明確になることを願っています。このフローで何か問題が見つかった場合はお知らせください。
ご協力ありがとうございました。
https://www.nxp.com/products/KW45?tid=vanKW45#documentationで「KW45/K32W148 でのデバッグ認証[AN14158]」を参照し、必要に応じて構成ファイルを確認してください。
こんにちは@JabezLaw 、以下の内容もシェアしていただけますか:
my_dat_config.yaml
?
こんにちは@nxa17177
先週の水曜日の投稿に対するちょっとしたフォローアップです。
新しい OEM OPEN ボードをプログラムする準備をしており、私が概説したエンドツーエンドのプロビジョニングおよび認証手順を確認していただければ幸いです。ここでのあなたの指導は、回復不可能なデバイスが新たに作成されるのを防ぎ、プロジェクトを前進させるために非常に重要です。
ご多忙であることは承知しておりますが、ご意見をいただければ幸いです。
改めましてサポートありがとうございます。
よろしくお願いいたします。
ヤベツ
NXPチームの皆様、こんにちは。
ご返信と、TZM_EN ヒューズに関する貴重な情報に感謝いたします。
セットアップを明確にするために、私は公式のKW45B41Z-EVKを使用しています。これには、デフォルトで RoTKTH ヒューズと SB3KDK ヒューズが事前にプログラムされています。SB3 フラッシュ操作が成功し、DAC 応答内のハッシュが一致することから、キーが正しいことが確認されました。
これまでの調査に基づくと、私が使用していたテスト ボードは安全でない不完全な状態になっていたようです。そのボードを脇に置いておきます。
現在、新しい OEM OPEN ボードをプロビジョニングする準備をしており、回復不可能なデバイスが新たに作成されないように、計画しているエンドツーエンドの手順についてご確認をお願いしたいと思います。
これが私の計画です:
ステップ 1: デバイスのプロビジョニングnxpimage sb31 export を使用して SB3 ファイルを生成し、sb3_config.yaml に次のコマンドを追加して、デバイスを正しく構成し、単一のアトミック操作でそのライフサイクルを進めます。
commands: # Program the debug permission fuse for L1 (S-World) - programFuses: { "address": "0x22", "values": "0x00000000" } # Advance lifecycle to OEM Secure World Closed - programFuses: { "address": "0x0A", "values": "0x0F" }
ステップ 2: セキュリティ保護されたデバイスを認証する上記の構成をフラッシュし、ボードの電源を入れ直した後、cc_socu: '0x0000' を含む dc_config.yaml を使用してデバッグ資格情報を生成します。私のプローブは、J-Link ファームウェアを実行する MCU-Link です。次に、次のコマンドで認証を実行します。
nxpdebugmbox -i jlink -v dat auth -c my_dat_config.yaml
ステップ 3: J-Link Commander で接続するauth コマンドの直後、ボードをリセットせずに、J-Link Commander を使用して接続を試みます。
私の核心的な質問:新しいボードを永続的にプログラムする前に、この完全な 3 ステップの手順が、KW45 でデバッグ認証を有効にして使用するための正しい意図された方法であるかどうかを確認していただけますか?
最終的な J-Link 接続が間違った DM-AP IDCODE エラーで失敗する原因となる、他の重要なヒューズ設定や手順が欠けているのでしょうか?
正しい道筋を確認していただきありがとうございます。
よろしくお願いいたします。
こんにちは@JabezLaw 、
まず第一に、 TZM_ENヒューズのプログラミングは不要です。これは最初のサンプル（そのようなサンプルはありますか？）では必須でしたが、NXPが常にTZM_ENヒューズのプログラミングを行っているため、すべてのスクリプトから完全に削除できるようになりました。
CASE、信頼ゾーンを設定していない場合は、すべてが安全です。
私の意見では、デバイスは使用できず、簡単に回復することはできません。主に、RoTKTH ヒューズが焼損していないとデバッグ認証エラーが発生します。RKTHがなければ何もCANません。
基本的なステップは、SB3KDK (ヒューズ 0x20) と RoTKTH (ヒューズ 0x1f) の両方がプログラムされた後にのみライフサイクルを進めることです。
新しいボードで完全な手順を実行する際に問題が発生した場合はお知らせください。