S32DS activation code expired Hi: My license of S32 Design Studio for S32 Platform v.3.4 is about to expire. Could you help check and extend it for me?  Activation code: 533B-878B-88A9-C68F Thanks.

se05x_TP_PlatformSCP03keys.cを使ってプラットフォームSCP03キーをデフォルトに戻す方法は? こんにちは、NXPコミュニティの皆さん、 SE051のセキュア要素を扱っており、Plug and Trustミドルウェアを使ってプラットフォーム SCP03キーをデフォルト値に正しく戻す方法についてお尋ねしたいです。 これまでにやったこと: demos/se05x/se05x_RotatePlatformSCP03Keys/se05x_TP_PlatformSCP03keys.c を修正し、キーのリバートセクション (doc:start:revert-scp03-keys と doc:end:revert-scp03-keys の間) をコメントアウトしました。 私は自分のセットアップでアプリケーションをビルドし実行しました。 実行は成功し、「おめでとうございます!!! キーローテーション成功!!!!」というメッセージが表示されました。 キー変更を確認するために、/tmp/SE05X/plain_scp.txtを新しいキー値(0x4041...ENC、MAC、DEK用)で更新し、SSSCLI Connectで正常に接続できました。 その後の操作(ssscli generate rsa、ssscli set aes、ssscli se05x readidlist)はすべて正常に完了し、鍵が書き込まれIDが問題なく取得されたことが確認されました。 今、プラットフォームSCP03キーをデフォルトのキー(sss/ex/inc/ex_sss_tp_scp03_keys.hで定義)に戻したいと考えています。 どなたかse05x_TP_PlatformSCP03keys.cの修正方法や、このキーリバートを行う正しい手順について教えてもらえますか? 環境: ボード：MCIMX8M-WEVK（OM-SE051ARD搭載） Plug and Trust MW バージョン: v04.07.01 OP-TEE OSバージョン：3.19.0 Linuxカーネル:6.1.151 OEF ID: A8FA アドバイスやコードに関するヒントをいただければ大変ありがたいです。 SE050 Re: How to revert Platform SCP03 keys back to default using se05x_TP_PlatformSCP03keys.c? こんにちは、 @Uc_S さん。 キーをデフォルトに戻すだけなら、nanoパッケージの例が 推奨されるよりシンプルな経路 です。更新すれば3つの scp03_* 配列(認証用現在のキー)と3つの NEW_scp03_* 配列(デフォルトキーをターゲットに)だけを更新し、ex_se05x_rotate_scp03_keys()内のリバートコールはコメントアウトすればよいのです。詳細については、以下をご参照ください。 変更点1 — 現在のキー（SCP03セッションを開くために使用）を設定します。 38～43行目は、 ex_set_scp03_keys() に渡される認証キーです。プレースホルダー 0xABCD... の値を現在のキー( 0x4041... に置き換えてください。😞 uint8_t scp03_enc_key[AES_KEY_LEN_nBYTE] = { 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F }; uint8_t scp03_mac_key[AES_KEY_LEN_nBYTE] = { 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F }; uint8_t scp03_dek_key[AES_KEY_LEN_nBYTE] = { 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F }; c   変更点2 — 新しいターゲットキー（デフォルトのSE051C A8FAキー）を設定します。 45～50行目は、 PutKey を介して SE051 に書き込ま れるキーです。 0x4041... のプレースホルダーをSE051C OEF A8FAのデフォルト値に置き換えてください。 uint8_t NEW_scp03_enc_key[AES_KEY_LEN_nBYTE] = { 0xbf, 0xc2, 0xdb, 0xe1, 0x82, 0x8e, 0x03, 0x5d, 0x3e, 0x7f, 0xa3, 0x6b, 0x90, 0x2a, 0x05, 0xc6 }; uint8_t NEW_scp03_mac_key[AES_KEY_LEN_nBYTE] = { 0xbe, 0xf8, 0x5b, 0xd7, 0xba, 0x04, 0x97, 0xd6, 0x28, 0x78, 0x1c, 0xe4, 0x7b, 0x18, 0x8c, 0x96 }; uint8_t NEW_scp03_dek_key[AES_KEY_LEN_nBYTE] = { 0xd8, 0x73, 0xf3, 0x16, 0xbe, 0x29, 0x7f, 0x2f, 0xc9, 0xc0, 0xe4, 0x5f, 0x54, 0x71, 0x06, 0x99 }; c   変更点3 — リバートブロックをコメントアウトする ex_se05x_rotate_scp03_keys() では、85行目から90行目までコメントアウトして、コードが1回だけ回転(→現在のデフォルト)を行い、再び回転しようとしないようにします。 /* -- Comment out the revert block below -- */ // SMLOG_I("Reverting SCP03 keys(version - %02x) to OLD KEYS \n", KEY_VERSION); // ret = ex_se05x_change_keys(&se05x_session, &scp03_enc_key[0], &scp03_mac_key[0], &scp03_dek_key[0]); // if (ret != 0) { // SMLOG_E("Error in ex_se05x_change_keys \n"); // return 1; // } c     すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: How to revert Platform SCP03 keys back to default using se05x_TP_PlatformSCP03keys.c? @Kan_Li ご説明いただきありがとうございます。 私の場合、現在のキーは既知です(0x4041...ENC、MAC、DEK)で、これらのキーを使ってSSSCLIを通じてSCP03セッションを正常に確立できます。 現在の認証キーが使えるので、se05x_TP_PlatformSCP03keys.cをデフォルトに戻すためにキー回転を修正する方法について詳しく教えていただけますか? 具体的には、以下の点について知りたいです。 セッション設定時に認証のために、現在のキー(0x4041...)で更新すべき変数やマクロはどれでしょうか。 ターゲットのデフォルトキー値を保持する変数または構造体はどれですか（例：sss_tp_scp03_keys.h）PutKey操作の場合。 se05x_TP_PlatformSCP03keys.cのコードスニペットや特定の行参照などは（または関連するブート/認証ヘッダー）を提供していただけると大変ありがたいです。 Re: How to revert Platform SCP03 keys back to default using se05x_TP_PlatformSCP03keys.c? こんにちは、 @Uc_S さん。 プラットフォームSCP03キーをデフォルト値に戻すのは、 現在のキーが既知である場合にのみ可能であり、SE051に対してキー更新( PutKey )コマンドを出す前に、SCP03セッションが成功裏に認証されている必要があります。 現在の鍵を紛失または忘れてしまった場合、SE051への認証および鍵のローテーションを実行することはできません。バックドアやオーバーライド機構は存在せず、これはデバイスのセキュリティモデルを維持するための設計上のものです。 さらに、工場出荷時リセットは効果 がなく 、プラットフォームSCP03キーは工場出荷時リセット手順の影響を受けません。 このような状況では、 SE051を、NXPがデフォルトで提供するキーを搭載した新しいデバイスに交換する以外に選択肢はありません。   すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

关于移除与设备的连接 你好， 我正在尝试使用 MCUXpresso SDK 版本 26.03 实现 BLE 通信。 我有一个关于 API 函数 Gap_RemoveBond 的问题。 该说明指出：“此 API 要求在调用时不能有任何活动连接。” 1.这是否意味着它只能在没有连接设备的情况下使用？ 2. 如果在存在活动连接的情况下不能使用 Gap_RemoveBond 删除绑定，那么在活动连接处于活动状态时，是否有办法删除绑定信息？ 关于此问题的更多信息 假设有三种设备： ・外围设备 ・中央设备A ・中央设备B takuya08_0-1788256233203.pngtakuya08_0-1788256233203.pngtakuya08_0-1788256233203.pngtakuya08_0-1788256233203.png 外围设备已与中央 A 和中央 B 连接。 当外围设备同时与中央设备 A 和中央设备 B 连接时： takuya08_1-1788256275044.pngtakuya08_1-1788256275044.pngtakuya08_1-1788256275044.pngtakuya08_1-1788256275044.png 根据上述说明，我理解外围设备在中心 A 和中心 B 连接时无法删除它们的绑定信息。 在连接进行中，有没有办法删除绑定信息？ 当外围设备仅与中央设备 A 连接时： takuya08_2-1788256364083.pngtakuya08_2-1788256364083.pngtakuya08_2-1788256364083.pngtakuya08_2-1788256364083.png 外围设备是否有可能删除中央 A 和中央 B 的绑定信息？ 或者是否可以只删除中央 B 的绑定信息？ 当外围设备未连接到任何设备时： takuya08_3-1788256474725.pngtakuya08_3-1788256474725.pngtakuya08_3-1788256474725.pngtakuya08_3-1788256474725.png 根据这句话，我理解在这种情况下，外围设备可以删除中央 A 和中央 B 的绑定信息。 感谢您的帮助。 Re: Regarding Removes the bond with a device @sofiaurueta 感谢您的回复。 根据您的回答，我理解即使只连接了一个设备，绑定信息也无法删除。 不过，为了确保万无一失，我想再确认一下。 2-1788256364083.png2-1788256364083.png2-1788256364083.png 如果外围设备存储了两个设备（中央 A 和中央 B）的绑定信息，并且当前连接到中央 A，则会发生下列哪种行为？ 1.可以删除未连接的中央 B 的债券信息。 2. 这两条债券信息记录均不可删除。 Re: Regarding Removes the bond with a device 你好，希望你一切都好。 只有当没有活动的 BLE 连接时才能调用Gap_RemoveBond() 。API 文档明确要求在删除债券信息之前必须断开所有连接。同样的限制也适用于 Gap_RemoveAllBonds()。 目前 MCUXpresso SDK BLE 主机堆栈中没有 API 支持在任何连接处于活动状态时删除 NVM 绑定数据。 在实际使用过程中，移除绑定的推荐流程如下： 对相关的已连接对等方调用 Gap_Disconnect(deviceId)，等待确认断开连接的 gConnEvtDisconnected_c 连接事件，然后调用 Gap_RemoveBond(nvmIndex)。 此致， 索菲亚。

LX2160ARDB: DDR検証 こんにちは、 LSDKからRCWファイル（rcw_2200_750_2900_19_5_2.bin）をSDカードにロードし、DDR構成パネルでRead SPDを実行すると、 「サポートされていない生カードリビジョンです。CLKをDQSスキュー値に手動で設定してください。」というメッセージが表示されます。 QCVSツールでLX2160ARDBのDDR検証を実行する方法 Priyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.pngPriyaa_0-1788337942087.png Re: LX2160ARDB: DDR validation こんにちは、ジューン・ルーさん サポートありがとうございます USBの場合、コマンドの結果は (ビン)51% findcc cwtaps 0 (ビン)51% イーサネット接続用 (bin) 51% findcc cwtaps FSL07E3D5 (10.1.66.150):CodeWarrior TAP v2 Cortex-10 プローブチップ ブートローダー v1.0.1 オペレーティングシステム v1.0.5 1 今のところ、DDR検証のためにイーサネット接続を使ってさらに進めてもいいでしょうか? Re: LX2160ARDB: DDR validation （バイナリ）52％表示cc 0: USB接続の失敗 コマンドコンバーターは構成されていません これは、CWTAPがUSB接続から検出できないことを示しています。 USBケーブルの接続を確認し、CWTAPがホストPCに正しく認識されていることを確認してください。 また、以下のコマンドを実行して結果を共有してください。 (bin) 6% findcc cwtaps ありがとうございます。 Re: LX2160ARDB: DDR validation こんにちは、ジューン・ルーさん CodeWarrior バージョン- Priyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.pngPriyaa_0-1788417354430.png (ビン)49% log v CCS Linuxリリースビルド 503.0.0.220812-p0 詳細ログ記録 (ビン)50%全て削除 (ビン)51%構成CCのCWTAPです。 (ビン)52%、CCを表示 0: USBオープン失敗 コマンドコンバーターは構成されていません (ビン)53% (bin) 53% source IDcode.tcl(bin) USB接続で利用可能なTAPをスキャンしています..... USB接続のTAPは見つかりませんでした ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + 利用可能なリモート接続 + + 1 - CodeWarriorTAP - + 2 - GigabitTAP - + + x - 変更せずにスクリプトを終了 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 接続を指定してください: 「CONNECTION()」を読み取れません:配列にそのような要素はありません (ビン)54% (ビン)54% イーサネット経由で接続し、ターゲットにpingを送ることができます。CodeWarriorをv11.5.12にアップデートした後でも、SPDの読み取り時に「サポートされていない生カードリビジョンです。CLKをDQSスキュー値に手動で設定してください。」という同じメッセージが表示されます。 よろしくお願い申し上げます。 Re: LX2160ARDB: DDR validation CodeWarrior版は、QorIQ LSシリーズ(ARM v8 ISA)向けCodeWarrior開発スタジオについてHelp →から確認してください。 接続状態を確認するには、「CCS Windows Release Build 503.0.0.220812-p0.txt」に記載されている手順に従ってください。 まずUSB接続をテストし、その後イーサネット接続を試すことをおすすめします。 IPアドレスが変更されたようです。ターゲットに正常にpingが届くかどうか確認いただけますか? Re: LX2160ARDB: DDR validation こんにちは、ジューン・ルーさん CodeWarrior 11.5.0を使用しており、DIMMはLX2160ARDBに付属していた純正モジュールです。 CodeWarriorをアーカイブcom.freescale.armv8.11.5.12.GA.Lin.updatesite.221209.zipで更新バージョン11.5.12の場合 JTAGを検出できなくなりました Priyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.pngPriyaa_0-1788412965825.png よろしくお願い申し上げます。 Re: LX2160ARDB: DDR validation あなたの指示通りに操作したところ、SPDを正常に読み取ることができました。 どのバージョンのCodeWarriorを使っているのか確認していただけますか?CodeWarrior 11.5.12ですか？ また、そのDIMMは純正品ですか？ ありがとうございます。 Re: LX2160ARDB: DDR validation こんにちは、ジューン・ルーさん FlexSPI経由で起動した後、u-bootでtftpboot経由でRCWファイルをロードし、以下のmmc書き込みコマンドを実行しました。 => tftpboot 0x90000000 rcw_2200_750_2900_19_5_2.bin => mmc dev 0; mmc write 0x90000000 8 1 => qixis_reset sd (このコマンドの実行中にD19の電源がオン/オフされました) また、DDR構成の場合、SPDから読み取ると「サポートされていない生カードリビジョンです。CLKをDQSスキュー値に手動で設定してください。」というエラーが表示されます。 Re: LX2160ARDB: DDR validation LSDKからRCWファイル（rcw_2200_750_2900_19_5_2.bin）をSDカードにロードするにはどうすればよいですか？ D19は電源のオンオフを繰り返しましたか？ QCVSツールでのDDRのLX2160ARDB検証については、以下を参照できます: QCVS_DDR_ユーザーガイド よろしくお願いします。 Re: LX2160ARDB: DDR validation こんにちは、ジューン・ルーさん イーサネット経由で接続し、テキストファイルに記載されている通りLX2160Aを見つけることができます Priyaa_0-1788427814124.pngPriyaa_0-1788427814124.pngPriyaa_0-1788427814124.pngPriyaa_0-1788427814124.pngPriyaa_0-1788427814124.pngPriyaa_0-1788427814124.pngPriyaa_0-1788427814124.pngPriyaa_0-1788427814124.pngPriyaa_0-1788427814124.png しかし、DDR設定ウィンドウでSPDを読み取ると、「サポートされていない生カードリビジョンです。CLKをDQSスキュー値に手動で設定してください。」と表示されます。 SPD値が正常に読み取られたことを確認するにはどうすればよいでしょうか？ Re: LX2160ARDB: DDR validation (bin) 50%すべて削除 (bin) 51 % config cc cwtap:10.1.66.150 （バイナリ）52％表示cc (bin) 53% ソース IDcode.tcl もし「CCS Windows Release Build 503.0.0.220812-p0.txt」と同じものが見つかればLX2160A。 DDRの検証にはIPアドレス10.1.66.150のイーサネット接続を使うことができます。 よろしくお願いします。 Re: LX2160ARDB: DDR validation これが成功時のスクリーンショットです。 June_Lu_0-1788429917395.pngJune_Lu_0-1788429917395.pngJune_Lu_0-1788429917395.pngJune_Lu_0-1788429917395.pngJune_Lu_0-1788429917395.pngJune_Lu_0-1788429917395.pngJune_Lu_0-1788429917395.png USBを使ってCWTAPに接続しました。プローブに正しいIPアドレスを設定する必要があります。 「接続診断」を成功裏に実行できましたか? June_Lu_1-1788430165643.pngJune_Lu_1-1788430165643.pngJune_Lu_1-1788430165643.pngJune_Lu_1-1788430165643.pngJune_Lu_1-1788430165643.pngJune_Lu_1-1788430165643.pngJune_Lu_1-1788430165643.png Re: LX2160ARDB: DDR validation 接続診断が正常に完了しました Priyaa_0-1788431456696.pngPriyaa_0-1788431456696.pngPriyaa_0-1788431456696.pngPriyaa_0-1788431456696.pngPriyaa_0-1788431456696.pngPriyaa_0-1788431456696.png SPD読み取り後のDDR構成は以下のとおりです。 Priyaa_1-1788432417841.pngPriyaa_1-1788432417841.pngPriyaa_1-1788432417841.pngPriyaa_1-1788432417841.pngPriyaa_1-1788432417841.pngPriyaa_1-1788432417841.png DDRの検証が順調に開始されているか確認していただけますか? というのも、検証開始ボタンが有効になっているにもかかわらず、検証開始直後にキャンセルされてしまうという問題が発生しているからです。 Re: LX2160ARDB: DDR validation こんにちは、ジューン・ルーさん ユーザーガイドに従い、再びDDRの設定とSPDの読みのためのプロジェクトを作成しました。以下の通りです Priyaa_0-1788498272408.pngPriyaa_0-1788498272408.pngPriyaa_0-1788498272408.pngPriyaa_0-1788498272408.pngPriyaa_0-1788498272408.png DIMMモジュールはRDBのJ14、J17コネクタに挿入されます。 Re: LX2160ARDB: DDR validation あなたのスクリーンショットは私のものと同じではないようです。「戻る」ボタンと「キャンセル」ボタンがありません。 QCVS_DDR_User_Guide 1.1.1 に従いましたか？DDR設定ツールを使用していますか？ よろしくお願いします。 Re: LX2160ARDB: DDR validation こんにちは、ジューン・ルーさん スイッチ(SW1)をRCWソースが存在するSDカードモードに変更した後、検証を行うことができました。 サポートありがとうございます... Re: LX2160ARDB: DDR validation SPDの読み取りは正常に完了したようですが、スクリーンショットは私の画面で表示されるものと若干異なっています。 DDR検証用にRCWソースが構成されているeMMCから起動するには、SW1[1:4]を1001に設定してください。 また、「ターゲット接続」がコネクテッドと表示されているか、スクリーンショットをご覧ください。 確認が完了したら、DDRの検証を進めることができます。 June_Lu_0-1788504721222.pngJune_Lu_0-1788504721222.png

imxrt1024..5A のセキュアブート Abhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.png 署名済み画像と署名なし画像(SPTで署名済み)を比較した六角形のスナップを添付しました。 IVTには私が理解できなかったいくつかの変更点があるのがわかります。 オフセット0x1000 符号なし -> D1 00 20 41 00 20 00 60 00 00 00 00 00 00 00 00 署名済み -> D1 00 20 40 DD 22 00 60 00 00 00 00 00 00 00 00 質問1：41は私のコード内にハードコードされているIVTバージョンだと理解していますが、これを40に変更するにはどうすればよいでしょうか？ 質問2。また、00 20 -> DD 22 がどのように変換されるのかも理解できません。 オフセット0x1010 これは明らかで、ここではCSFポインタが更新されています。 0x1020 符号なし -> 00 00 00 60 00 00 40 00 00 00 00 00 署名済み -> 00 00 00 60 00 A0 00 00 00 00 00 00 質問3：00 40はA0 00でどのように更新されますか？ これらの質問をする理由は、私の理解では、開発チームがブート可能なバイナリを提供すれば、CSF.binを追加してIVTのCSFポインタを更新して署名するだけでよいはずなのですが、違いを見て、もっと多くのことが起こっているように感じたからです。 Re: Secure boot in imxrt1024..5A Abhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.png 以前の投稿でこの回答をいただいたので、CSFを追加してIVTでVSFFポインタを更新すればファームウェアが署名されると思っていましたが、画像にCSTで署名したいのでどうやって署名すればいいのでしょうか? すでに起動可能なイメージ(FCFB、IVT、BOOTDATA,...)を持っています。パッケージに署名して発送するだけです。どうやってそれを行うかは、hab.csfを作成しました [ヘッダ] バージョン = 4.0 #利用可能なエンジンは、ICXRT 用の DCP、SW、ANY です。 エンジン = DCP エンジン構成 = 0 証明書フォーマット = x509 署名形式 = CMS ハッシュアルゴリズム = sha256 #後続の INSTALL CSFK または Install KEY で使用するためにルート公開鍵をインストールします #HABは内部公開鍵ストアのスロット0にインストールされます # HAB は単にテーブルを再ハッシュし、融合された SRK ハッシュと比較します。 [SRKをインストール] ファイル = "keys/SRK_1_2_3_4_table.bin" #使用するSRKを指定します。このインデックスの失効ヒューズが焼損している場合、インストールは失敗します。 ソースインデックス = 0 ハッシュアルゴリズム = sha256 #HAB スロット 1 に CSF キーの証明書をインストールします [CSFKをインストール] ファイル = "crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem" 証明書フォーマット = x509 #Authenticate CSF コマンドは、実行元の CSF を認証します。 [CSFの認証] #後続の「鍵のインストール」または「データの認証」コマンドで使用するための公開鍵をインストールします #HAB が IMG 証明書をキー スロット 2 にインストールします [インストールキー] #この証明書はSRKと照合されていることを意味します 検証インデックス = 0 目標インデックス = 2 ファイル = "crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem" [データの認証] #インストールキーのターゲットインデックスと同じである必要があります 検証インデックス = 2 ブロック = 0x60001000 0x1000 0x6580 "evkmimxrt1024_iled_blinky_unsigned_original.bin" Re: Secure boot in imxrt1024..5A こんにちは、 @Abhay2080 さん。 ご質問ありがとうございます！ RT1024 IVT / ブートデータの定義に基づくと、見られる差異は想定内のものであり、CSFポインタの更新に限ったものではありません。 Q1: なぜ D1 00 20 41 D1 00 20 40 になるのですか? D1 00 20 41 はIVTヘッダーで、 0xD1 はIVTタグ、 0x0020 は固定されたIVT長32バイト、最後のバイトはバージョンです。RT1024リファレンスマニュアルではIVT版を 0x40/0x41 と定義しているので、 0x40 は有効であり誤りではありません。こちらのオンラインガイドをご確認ください： https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mcu_bootloader/docs/iMXRT1024_Manufacturing_User_Guide/topics/imx_rt_bootable_image.html Q2: なぜ 00 20 00 60 DD 22 00 60 になるのですか? これはIVT entry 体です。リトルエンディアン形式の場合： 00 20 00 60 = 0x60002000 DD 22 00 60 = 0x600022DD RT1024 RMは、 entry をイメージから実行される最初の命令の絶対アドレスとして定義します。AN12108では、デフォルトのエントリポイントが Reset_Handler でない場合、 entryPointAddress Reset_Handler アドレスに設定する必要があるとも記載されています。 したがって、SPTはIVTのエントリーを 0x60002000 から実際の申請エントリーポイントに更新した可能性が高いです。マップファイル/ELFシンボルテーブル内の Reset_Handler アドレスを確認してください。 Q3: なぜ 00 00 40 00 00 A0 00 00 になるのですか? 0x1020 にはブートデータがあります。 start 遺体 0x60000000 length 0x00400000 から 0x0000A000 RT1024 RMは、ブートデータにイメージの開始アドレスとイメージの長さが含まれていると定義しており、ブートROMはこの構造体からイメージのアドレスと長さを読み取ります。 そのため、SPTは最終的に生成されたブート可能/署名済みイメージのレイアウトに合わせて、長さフィールドを更新しました。 RTシリーズのHABセキュアブートの場合、最終的な署名付きイメージは単に「CSF.binを追加してCSFポインタを更新する」だけではありません。IVTヘッダー、エントリ、ブートデータの長さ、CSFポインタ、およびCSF認証データコマンドでカバーされるアドレス/長さはすべて一致している必要があります。HABはソフトウェアからハッシュをフラッシュで再計算し、署名から回収された参照ハッシュと比較します。認証済み領域が署名後に変更されると、検証は失敗します。[0dfe-E1] 推奨される方法は、CSF.binだけを手動で追加するのではなく、SPT/CSTによって生成された最終的な署名付きイメージを使用することです。 この説明がお役に立てば幸いです！ よろしくお願いします、 ギャビン

i.MX8M Plus – Is there any way to access MIPI CSI-2 Embedded Data (DT 0x12) together with RAW image Hello NXP Community, we are currently integrating a MIPI CSI-2 RAW image sensor with an i.MX8M Plus and would like to clarify whether there is any supported or technically possible way to make the sensor's CSI-2 Embedded Data (Data Type 0x12) available to software on the target. Our camera stream has the typical CSI-2 structure: Frame Start Embedded Data DT = 0x12 RAW image data DT = 0x2A / 0x2B / 0x2C Frame End The image data is captured through the MIPI CSI-2 receiver → Gasket → ISI → memory/V4L2 path and this part is working correctly. The problem is that we additionally need the Embedded Data belonging to each frame. The metadata contains frame-related sensor information, and therefore it is important that the metadata can be associated with the corresponding captured image. According to the i.MX 8M Plus Applications Processor Reference Manual, the MIPI CSI-2 receiver provides configurable data-type handling through the CSI-2 receiver registers, in particular the MIPI_CSIx_ISP_CONFIG0 / DATAFORMAT configuration. The relevant MIPI CSI-2 Rx / CSIS register descriptions are in Chapter 13.5, MIPI CSI-2, and in older revisions of the Reference Manual the supported image data types are described around Section 13.5.6.13. We also found NXP Application Note AN13857 – i.MX 8M Series MIPI Capture System, especially Section 7, "Embedded data support". AN13857 states that a stream containing Embedded Data with DT=0x12 and image data with another data type is considered data type interleaving, and that the i.MX 8M series capture system does not support this mode. The suggested workaround is to configure the sensor to transmit the embedded data using the same data type as the image data. Unfortunately, this workaround is not possible with our sensor. The sensor transmits standard CSI-2 Embedded Data using DT 0x12, while the image data uses the corresponding RAW data type. The Embedded Data data type cannot be changed to the RAW image data type. However, we found an older NXP Community discussion specifically concerning the i.MX8MP where NXP TechSupport stated that the CSI hardware should support DT=0x12, while the BSP did not support metadata at that time: https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-capture-MIPI-embedded-data/td-p/1383845 There is also an older discussion about accessing CSI-2 Embedded Data on i.MX8M devices: https://community.nxp.com/t5/i-MX-Processors/Does-iMX8M-CSI-support-metadata-embedded-data/m-p/977554 Therefore, we would like to clarify whether the limitation described in AN13857 applies to the complete hardware path, or mainly to the currently supported ISI/V4L2 capture architecture. Our main question is: Is there any way on the i.MX8M Plus to receive or access the payload of CSI-2 packets with Data Type 0x12 while simultaneously capturing the RAW image stream, even if this requires modifications to the Linux driver? For example, would any of the following approaches be technically possible? Route DT=0x12 and the RAW image data through different CSI/ISI paths or channels. Access the Embedded Data before the ISI, directly from the MIPI CSI-2 receiver. Configure an additional CSI-2 receiver channel/interface for DT=0x12. Use another DMA or memory path for the Embedded Data. Extend the NXP Linux CSI/ISI driver to expose the Embedded Data as a V4L2 metadata node or separate /dev/videoX device. Use any undocumented or currently unsupported hardware functionality of the CSI-2 receiver that would allow the DT=0x12 payload to reach memory. We do not necessarily require an officially supported V4L2 metadata implementation. If the i.MX8M Plus hardware is capable of transferring the DT=0x12 payload to memory, we would also be interested in implementing the necessary kernel/driver changes ourselves. Could NXP please clarify whether the restriction described in AN13857 is: a fundamental hardware limitation of the i.MX8M Plus CSI-2 → Gasket → ISI architecture, meaning that the DT=0x12 payload cannot be transferred to memory while RAW image data is being captured, or a software/driver limitation, for which a custom driver implementation could provide access to the Embedded Data? If it is a hardware limitation, is there any alternative mechanism on the i.MX8M Plus to obtain the Embedded Data payload without changing the camera's CSI-2 output format? Thank you for any clarification or implementation hints. Best regards, Peter Re: i.MX8M Plus – Is there any way to access MIPI CSI-2 Embedded Data (DT 0x12) together with RAW im Hello, The limitation in application note is a hardware architecture limitation of the i.MX8M Plus CSI. The downstream ISI block has no mechanism to separate DT=0x12 payload from the RAW stream. Unfortunately, there is no supported or officially workaround that mentioned in application note. Best regards.

SSEGold：Aniimoのリリース日、ゲームプレイガイド、そしてゲーム内通貨を素早く入手する方法 モンスター収集RPGジャンルに、新たなライバルが登場する。『Aniimo』は、モンスター収集、探索、戦闘、マルチプレイヤー機能を組み合わせた、基本プレイ無料のオープンワールドアドベンチャーゲームだ。新しい生き物を発見したり、強力なチームを編成したり、広大なファンタジー世界を探索したりするゲームが好きなら、Aniimoは間違いなく注目に値するタイトルです。 Pawprint Studioが開発した『Aniimo』は、プレイヤーをイディルの世界へと誘います。そこでは、アニモと呼ばれる不思議な生き物たちが様々な環境に生息しています。単に仲間を集めるだけでなく、プレイヤーは独自の「Twine」システムを通じてアニモとつながり、彼らの視点から世界を体験できます。 Aniimoはいつリリースされますか？ Aniimoは2026年9月16日にPCおよびコンソール向けに正式に世界中で発売予定で、PlayStation 5やXboxプラットフォームも含まれます。モバイル版は2026年9月23日に間もなく発売されます。 このゲームは基本ゲームを購入せずに基本ゲームプレイをダウンロードして体験できる基本プレイモデルを採用します。任意でゲーム内購入できるアイテムやスペシャルパックが用意されています。 Aniimoはどんなゲームですか？ Aniimoは、オープンワールド型のモンスター捕獲RPGです。プレイヤーはパスファインダーとなり、イディル大陸を探索しながら、個性豊かなアニモの仲間を探し出す。 主なゲームプレイの流れは以下のとおりです。 さまざまなエリアを探索し、隠された生き物を発見すること 特殊な道具でアニイモを捕らえる トレーニングと進化する収集コンパニオン リアルタイム戦闘で敵と戦う 他のプレイヤーと一緒にチャレンジをクリアする パーソナルスペースのカスタマイズとアニイモとの交流 従来のクリーチャー収集ゲームとは異なり、『アニモ』は探索に重点を置いている。環境や天候、時間帯によって異なる生き物が現れるため、探索は進行の重要な要素となっています。 Aniimo Twineシステムについて解説します Aniimoを他と大きく差別化する特徴の一つは、Twineというゲームシステムです。 人間キャラクターだけでなく、プレイヤーはアニモとつながり、彼らを通じて世界を体験できます。これにより、探索に次のようなさまざまなクリーチャーの能力を使用できます。 地域を横断して飛行する 水中ダイビング 地下通路を掘る パズルを解く 新たな視点から戦いに挑む このシステムにより、各アニモの価値が高まります。なぜなら、アニモは単なる戦闘の仲間ではなく、世界を探索する際にも役立つからです。 Aniimoの戦闘システムはどのようになっていますか？ 『アニモ』の戦闘システムは、従来のターン制システムではなく、リアルタイムバトルに重点を置いている。 プレイヤーは以下のことができます: さまざまなアニモのチームを編成する クリーチャーの能力を活用する PvEの敵やボスと戦う PvPチャレンジに参加する マルチプレイヤーアクティビティに参加する また、プレイヤーがチームを組んだり他者と競い合ったりできる競技モードも含まれています。その一例がPvEVPモードのエッグハイストで、チームは報酬を巡って探索し、戦い、競い合います。 アニモ通貨とプレイヤーがより多くのリソースを必要とする理由 多くの基本プレイ無料RPGと同様に、『アニモ』でも通貨と資源は重要な役割を果たす。 プレイヤーは、以下の目的でゲーム内通貨が必要になる可能性が高いです。 アニモの能力をアップグレードする 進化素材の解放 設備の改善 便利なアイテムを購入する 戦闘に向けてより強力なチームを準備する 最初は、クエストや探索を通して資源を獲得するだけで十分かもしれません。しかし、プレイヤーがより難しいコンテンツに進むにつれて、素材や通貨の周集に時間がかかることもあります。 十分な通貨を持つことで、同じ農作業を繰り返す代わりに探索や戦闘を楽しむ時間を増やせます。 Aniimoの通貨をより早く入手する方法は？ プレイヤーが資源を建設する方法はいくつかあります: 1. 日々の活動を完了する デイリーミッションや期間限定イベント情報は、報酬を集める最も確実な方法の一つです。 2. 資源を探索し収集する Aniimoはオープンワールドを基盤としているため、探索を行うことでプレイヤーは貴重な素材やアイテムを入手できる可能性が高い。 3. マルチプレイヤーコンテンツに参加する 協力プレイや競技チャレンジは追加の報酬を提供し、進行をより楽しくすることもあります。 4. 信頼できる販売者からアニモ通貨を購入する 周回作業を節約したいプレイヤーにとっては、信頼できるサードパーティのマーケットプレイスで通貨を購入するのが便利な選択肢となり得ます。 SSEGoldは、Aniimoのゲーム内通貨やゲーム関連サービスを提供し、プレイヤーが必要なリソースをより早く入手し、実際のゲームプレイを楽しむ時間を増やせるよう支援します。より強力なアニイモチームの準備をしている時や仲間をアップグレードする時、友達と近況を語る時など、追加の通貨を持つことで進行がスムーズになります。 Aniimoはプレイする価値があるか？ Aniimoには、クリーチャー収集ゲームのファンにとって魅力的な機能が数多く備わっている。オープンワールドのデザイン、独特のTwineシステム、進化する仲間、マルチプレイヤーアクティビティが、単なるモンスター捕獲ゲーム以上の深みを与えています。 探索や希少な生物の収集、強力なチームのビルディングを楽しむプレイヤーにとって、『アニモ』は2026年の興味深いRPGの一つになる可能性があります。 このゲームを最大限に楽しむには、イディルを探索し、新しいアニモを発見し、自分だけの冒険を作り上げるのが一番です。進行が遅すぎる場合は、SSEGoldのような信頼できるサービスで追加の通貨を手に入れることで、終わりのない周回作業よりも楽しい部分に集中できます。

iOS 26のWi-Fi Aware NAN(IW612、FRDM-IMX93サンプルコード、88W9098サポート) こんにちは、 私はWi-Fi Aware(NAN)を使ったiPhone向けの消費者向けアクセサリーを開発しています データリンクとして。AppleはiOS 26で公開Wi-Fi Awareフレームワークを追加し、 すでにiPhone間で動作するベンチマークアプリ(Publish/Subscribe、 ペアリングされたデバイス、TCPデータパスなどです。NXP側を選択します。 私の計画は、FRDM-IMX93ボード上のIW612をNANピアとして評価することです。 その後、NVMeストレージを備えた i.MX 8M Plusベースの設計に移行します。 私には4つの質問があります。 1.スレッド2170706(「iMXボード上のWiFi Aware(NAN)のサンプルコードと IW612 トライラジオ モジュール」)、NXPはWi-Fi Awareのサンプルコードを共有していました。 iOSのセキュアファイルによる相互運用性。アクセスできますか? 同じ素材?もしそれが適切であれば、正式なサポートケースを開くこともできます チャネル。 2. FRDM-IMX93 Debian/Yocto BSPはIW612ファームウェアを搭載していますか? NANは最初から有効になっていますか?どのBSPリリースを使うべきでしょうか? 3. 同じ設計の2x2バリアントの場合、88W9098ファームウェアはサポートしていますか? MXMドライバーでNAN / Wi-Fi Awareはどうですか? 4. NXPはiOS 26（Wi-Fi対応）に対してNANペアリングとデータパスの検証を行いましたか？ 4.0 / PASNペアリング）？既知の制限事項があれば、ぜひ教えていただけると大変助かります。 対象: iOS 26.5、Xcode 26 を搭載した iPhone 17 Pro Max および iPhone 12 Pro Max。 IW612 NANデータパスのスループットに関するデータも歓迎します。 ありがとう、 ユセフ ( https://community.nxp.com/t5/i-MX-Processors/Sample-code-for-WiFi-Aware-NAN-on-iMX-boards-with-the-IW612-tri/td-p/2170706 ) Re: Wi-Fi Aware NAN with iOS 26 on IW612 and FRDM-IMX93 sample code and 88W9098 support こんにちは、 あなたの調子が良いといいのですが。Wi-Fiデバイスの機能リストについては、 NXPワイヤレスSoCのLinux版機能とリリースノートをご確認ください。 Secure Filesの対象となる文書: Secure Access Rights |NXPセミコンダクターズ その手順に従っていただけますか? また、 Secure Access Rights FAQs | NXP Semiconductorsをご確認することをお勧めします。 よろしくお願いいたします。 リカルド

i.MX8DXL CAAM COVER 对 P-384 私钥/黑斑用例的限制 您好，NXP团队： 我们正在评估 i.MX8DXL CAAM 对 ECDSA P-384 黑键/blob 的支持情况。 观察到的结果 P-256 从外部提供的明文 P-256 私钥开始： 明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：通过 P-384（CAAM 生成的黑键） 生成 ECDSA 私钥，颜色为 KEY_COLOR_BLACK 无需 COVER 操作即可从私钥生成黑块 从黑斑中恢复黑键 ECDSA 签名/核实 结果：通过 P-384（外部明文私钥） 从外部提供的明文 P-384 私钥（48 字节）开始： 明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：失败 补充观察 我们在NXP的补丁中注意到以下注释： https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEY 命令似乎限制为 32 字节，因此我们应该使用加载方式。 * 改为使用最多可加载 64 字节的命令。 * * TODO：KEY 命令表明它应该能够加载更大的密钥。 * 小于 32 字节，但实际上行不通 * * TODO：LOAD 命令表明它应该能够加载最多 96 个文件 * 字节键在实践中不起作用，并且限制为 64 字节。 */ 我们观察到了类似的行为。 使用 LOAD 命令而不是 KEY 命令，我们可以处理大于 32 字节的密钥，包括 48 字节的 P-384 私钥。 然而，这并不能解决上述问题。虽然可以将密钥覆盖并存储在一个块状物中，但恢复后的黑密钥不能成功用于 ECDSA 签名/验证。   我们的疑问： CAAM COVER 操作对于大于 32 字节的 ECC 私钥是否存在任何已知限制？ 通过 COVER 导入外部 P-384 明文私钥，然后将其用作 ECDSA 黑密钥，这是否是支持的用例？ 观察到的这种现象是否是由于 CAAM 硬件限制造成的？ 是否有推荐的 CAAM 方法可以导入外部生成的 P-384 明文私钥并将其用作 ECDSA 操作的黑密钥？ 任何指导都将不胜感激。 谢谢，并致以最诚挚的问候！ 霍詹姆斯。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 补充说明：   我们关注的重点不仅限于 ECDSA 用例。   即使通过 COVER 导入外部 P-384 私钥不是 ECDSA 支持的工作流程，我们仍然想了解 COVER 操作本身的局限性。   在我们的应用中，COVER 操作不仅可以用于保护 ECDSA 私钥，还可以用于保护一般敏感数据。因此，支持大于 32 字节的有效载荷大小是一个重要的考虑因素。 根据我们的测试，使用 LOAD 命令变通方法可以处理大于 32 字节的有效载荷。小于约 80 字节的有效载荷似乎可以正常工作，而更大的有效载荷则表现出不稳定的行为。我们想了解这些观察结果反映的是 CAAM 的实际局限性还是实施问题。 NXP能否也澄清一下，COVER 操作本身是否存在任何已记录的大小限制，而与 ECDSA 用例无关？   谢谢！

i.MX8M Plus – 是否有办法在访问 RAW 图像的同时访问 MIPI CSI-2 嵌入式数据 (DT 0x12) NXP社区的各位朋友，大家好！ 我们目前正在将 MIPI CSI-2 RAW 图像传感器与i.MX8M Plus集成，并想确认是否有任何受支持或技术上可行的方法，使目标上的软件能够访问传感器的CSI-2 嵌入式数据（数据类型 0x12） 。 我们的摄像机视频流具有典型的CSI-2结构： Frame Start Embedded Data DT = 0x12 RAW image data DT = 0x2A / 0x2B / 0x2C Frame End 图像数据通过MIPI CSI-2 接收器 → 垫片 → ISI → 存储器/V4L2路径捕获，这部分工作正常。 问题是，我们还需要每一帧所包含的嵌入数据。元数据包含与帧相关的传感器信息，因此，元数据能够与相应的捕获图像关联起来非常重要。 根据i.MX 8M Plus 应用处理器参考手册，MIPI CSI-2 接收器通过 CSI-2 接收器寄存器提供可配置的数据类型处理，特别是 MIPI_CSIx_ISP_CONFIG0 / DATAFORMAT 配置。相关的 MIPI CSI-2 Rx / CSIS 寄存器描述在第 13.5 章 MIPI CSI-2中，在参考手册的旧版本中，支持的图像数据类型在第 13.5.6.13 节中进行了描述。 我们还找到了 NXP 应用笔记AN13857 – i.MX 8M 系列 MIPI 捕获系统，特别是第 7 节“嵌入式数据支持” 。 AN13857 指出，包含 DT=0x12 的嵌入式数据和另一种数据类型的图像数据的数据流被视为数据类型交错，并且 i.MX 8M 系列捕获系统不支持此模式。建议的解决方法是将传感器配置为使用与图像数据相同的数据类型来传输嵌入式数据。 遗憾的是，我们的传感器无法实现这种变通方法。传感器使用DT 0x12传输标准 CSI-2 嵌入式数据，而图像数据使用相应的 RAW 数据类型。嵌入数据类型不能更改为 RAW 图像数据类型。 然而，我们找到了一篇较早的 NXP 社区讨论，专门针对 i.MX8MP，其中 NXP 技术支持表示 CSI 硬件应该支持 DT=0x12，而当时的电路板支持包。不支持元数据： https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-capture-MIPI-embedded-data/td-p/1383845 此外，还有一篇关于访问 i.MX8M 设备上的 CSI-2 嵌入式数据的较早讨论： https://community.nxp.com/t5/i-MX-Processors/Does-iMX8M-CSI-support-metadata-embedded-data/m-p/977554 因此，我们想澄清 AN13857 中描述的限制是否适用于整个硬件路径，还是主要适用于当前支持的 ISI/V4L2 捕获架构。 我们的主要问题是： i.MX8M Plus 是否有办法在捕获 RAW 图像流的同时接收或访问数据类型为 0x12 的 CSI-2 数据包的有效载荷，即使这需要修改 Linux 驱动程序？ 例如，下列哪些方法在技术上可行？ 将 DT=0x12 路由到不同的 CSI/ISI 路径或通道，并将 RAW 图像数据路由到这些路径或通道。 在 ISI 之前，直接从 MIPI CSI-2 接收器访问嵌入式数据。 为 DT=0x12 配置额外的 CSI-2 接收器通道/接口。 嵌入式数据应使用其他 DMA 或内存路径。 扩展 NXP Linux CSI/ISI 驱动程序，将嵌入式数据公开为 V4L2 元数据节点或单独的 /dev/videoX 设备。 使用 CSI-2 接收器的任何未记录或当前不支持的硬件功能，使 DT=0x12 有效载荷能够到达内存。 我们并不一定需要官方支持的 V4L2 元数据实现。如果 i.MX8M Plus 硬件能够将 DT=0x12 有效载荷传输到内存，我们也有兴趣自行实现必要的内核/驱动程序更改。 NXP能否澄清一下AN13857中描述的限制是否为： i.MX8M Plus CSI-2 → Gasket → ISI 架构存在一个根本性的硬件限制，这意味着在捕获 RAW 图像数据时，DT=0x12 有效载荷无法传输到内存中。 或 这是软件/驱动程序的限制，而自定义驱动程序实现可以提供对嵌入式数据的访问？ 如果这是硬件限制，i.MX8M Plus 是否有其他机制可以在不改变摄像机 CSI-2 输出格式的情况下获取嵌入式数据有效载荷？ 感谢您的任何澄清或实施建议。 此致， 彼得 Re: i.MX8M Plus – Is there any way to access MIPI CSI-2 Embedded Data (DT 0x12) together with RAW im 你好， 应用笔记中的限制是 i.MX8M Plus CSI 的硬件架构限制。下游 ISI 块没有机制将 DT=0x12 有效载荷与 RAW 流分离。 遗憾的是，应用笔记中没有提到任何官方支持的解决方法。 顺祝商祺！

「スマートエネルギー」太陽光発電に関する意見 今日はスマートエナジーという会社の訪問販売員が何人か来て、太陽光パネルについて話したがっていました。太陽光発電に興味はあるのですが、初期投資をする資金がありません。そこで、初期費用ゼロで利用できる政府資金による制度があると聞きました。 もちろん、私は非常に懐疑的です。彼らと取引したことのある方からのご意見をぜひお聞かせください。

在 Zephyr 系统中使用 FRDM-MCXW71 上的两个 LPSPI 端口？ 你好， 我们希望在 Zephyr 应用中使用 FRDM-MCXW71 上的两个 LPSPI 端口。 但是当我在 Zephyr 4.4.0 中检查时，在下面 zephyrproject/zephyr/boards/nxp/frdm_mcxw71 我找到了以下文件： frdm_mcxw_71.dts 文件。 它只有 &lpspi1 的条目。（用于 SPI 闪存演示） &lpspi0 的条目不存在？ frdm_mcxw71-pinctrl.dtsi 此外，只有 &lpspi1 的条目 是否有关于如何使用 lpspi0 的示例？ 除了常规的 Zephyr 项目文件（.overlay 和 prj.conf）之外，还需要修改哪些文件？ 谢谢。 Re: Using the two LPSPI ports on the FRDM-MCXW71 with Zephyr? 我注意到 zephyrproject/zephyr/drivers/spi/spi_nxp_lpspi 中有一个特定的驱动程序。 不过我不确定如何利用这个方法来同时处理两个 lpspi 端口。

Linux上でOP-TEE経由でSE051でキー生成、エンコン/デック、署名/検証を行う方法は? こんにちは、NXPコミュニティの皆さん、 現在、この投稿「Plug and Trust MWをOP-TEEに統合する方法」で説明されている環境に基づいて、Plug and Trust MiddlewareをOP-TEEに統合する作業を行っています。 私の目標は、SE051のセキュア要素を活用し、Linux上で動作するユーザー空間アプリケーションから以下の操作を実現することです。 AESキーを生成し、SE051に保存します。 RSA鍵ペアを生成し、SE051に保存します。 SE051に保存されたAESキーを使ってファイルを暗号化します。 SE051に保存されているAESキーを使ってファイルを復号します。 SE051でRSA秘密鍵を使用してデータに署名します。 SE051にあるRSA公開鍵を使用して署名を検証します。 SE051でRSA公開鍵を使用してデータを暗号化します。 SE051でRSA秘密鍵を使用してデータを復号します。 これらの手術を達成するための最適な方法について、どなたかアドバイスをいただけませんか?このOP-TEE環境でサポートされている限り、以下のコマンドラインツール（またはそれらの組み合わせ）のいずれかを使用することに抵抗はありません。 openSSLコマンド(OpenSSLプロバイダー経由) ssscliツール pkcs11-tool(PKCS#11インターフェース経由) この特定のOP-TEE環境に関する例、ドキュメントリンク、コマンドの使用例があれば大変ありがたいです。 SE050 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? こんにちは、 @Uc_S さん。 Linuxユーザー空間からSE051への サポートされた経路は3 つあります。これら3つはすべてPlug & Trust MW v04.07.01で利用可能です。 パス 図書館 最適な用途 PKCS#11 libsss_pkcs11.so AES、RSAキーの生成/署名/検証/エンク/デック pkcs11-tool OpenSSL プロバイダー(3.x) libsss_provider.so RSA署名/検証/エンコード/デコード openssl pkeyutl ssscli Python CLI キーの注入/プロビジョニングのみ OP-TEE環境に関する重要な注意点: OP-TEEセットアップ( CFG_NXP_SE05X=y )では、SE051はOP-TEEコアがネイティブI2Cドライバを通じて直接アクセスします。Linuxユーザー空間アプリケーションはI2Cバスを所有 していません 。上記の3つのパスはすべて正しく動作します。なぜなら、Plug & Trust MWアクセスマネージャー( accessManager )またはT1oI2CソケットインターフェースがOP-TEEの信頼されたワールドを通じてコマンドをSE051にルーティングするためです。 操作1:AESキーを生成し、SE051に保存する ssscli を使って特定のキーID(SE051のオブジェクトID)でAES-256キーを生成します: # Generate AES-256 key at Key ID 0x20000001 ssscli generate aes 0x20000001 256 キーが存在することを確認するには： ssscli get aes 0x20000001 aes_key_info.txt 注意: AESキーは対称的であり、SE051からエクスポートすることはできません。キーID 0x20000001 は、SE051 NVMに永続的に保存される32ビットのオブジェクト識別子です。 操作2：RSA鍵ペアを生成し、SE051に保存する オプションA — pkcs11-tool を使用する（推奨） RSAキーラベルは以下の形式を使用します sss: : # Generate RSA-2048 key pair at Key ID 0x10101010 pkcs11-tool --module $PKCS11_MODULE --keypairgen --key-type rsa:2048 --label "sss:10101010" オプションB — 使用 ssscli ssscli generate rsa 0x10101010 2048 AN13030 セクション 3.3.8.3 注記: RSA キー ペアを外部から注入する場合は、PKCS#8 または従来の OpenSSL フォーマットを使用して DER エンコードする必要があります。 sss_key_store_get_key() を介して取得した場合、公開鍵のみが返されます。 操作3:SE051のAESキーを使ってファイルを暗号化する AES対称暗号化はSSS API( sss_cipher_one_go )またはコマンドライン使用の場合は小型ラッパーアプリケーションを介して行われます。MWには、以下の場所に組み込みの対称例が用意されています。 simw-top/sss/ex/symmetric/ex_sss_symmetric.c コマンドラインから直接使用するには、以下のサンプルをビルドして実行してください。 # After building the MW examples: ./se05x_symmetric_aes_cbc_encrypt --keyid 0x20000001 --input plaintext.bin --output ciphertext.bin --iv 00000000000000000000000000000000 MWは以下をサポートしています: kAlgorithm_SSS_AES_ECB 、 kAlgorithm_SSS_AES_CBC 、 kAlgorithm_SSS_AES_CTR 、 kAlgorithm_SSS_AES_GCM 、 kAlgorithm_SSS_AES_CCM (AN13030の第3.3.9.1節より)。 操作4:SE051のAESキーを使ってファイルを復号する ./se05x_symmetric_aes_cbc_decrypt --keyid 0x20000001 --input ciphertext.bin --output decrypted.bin --iv 00000000000000000000000000000000 SSS APIは、ワンショット復号には sss_cipher_one_go() を使用した kMode_SSS_Decrypt モード、ストリーミングには複数ステップの sss_cipher_init() / sss_cipher_update() / sss_cipher_finish() シーケンスを使用します。 操作5：SE051のRSA秘密鍵を使用してデータに署名する pkcs11-tool を使用します（キーはSE051に保持されます） # Sign with RSA private key (key never leaves SE051) pkcs11-tool --module $PKCS11_MODULE --sign --label sss:10101010 -m SHA256-RSA-PKCS --slot 1 -i in.der -o signature.der PKCS#11でサポートされている手話メカニズム： SHA256-RSA-PKCS (RSASSA-PKCS1-v1_5、SHA-256) SHA1-RSA-PKCS 、 SHA384-RSA-PKCS 、 SHA512-RSA-PKCS RSA-PKCS-PSS (PSSパディング) OpenSSL プロバイダー(v3.x)の使用 # OpenSSLをNXPプロバイダーを使用するように設定してください(/etc/ssl/openssl.cnf参照) openssl pkeyutl -provider nxp -sign -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in in.txt -out signature.der   操作6：SE051のRSA公開鍵を使用して署名を検証する ステップ1 — SE051から公開鍵をエクスポートする # Method A: via ssscli ssscli get rsa pub 0x10101010 rsa_pub.der # Method B: via pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --read-object --type pubkey --slot 1 --label sss:10101010 -o pubkey.der # Convert DER to PEM for OpenSSL openssl rsa -in pubkey.der -inform der -out pubkey.pem -outform pem -pubin ステップ2 — 検証（ホスト側、SE051は不要） openssl dgst -keyform PEM -verify pubkey.pem -sha256 -signature signature.der in.txt # Expected output: Verified OK 操作7：SE051のRSA公開鍵を使用してデータを暗号化する RSA暗号化は公開鍵を使用します（暗号化にセキュアエレメントは不要です）。 # Encrypt with public key (host side) openssl rsautl -encrypt -inkey pubkey.pem -in in.txt -pubin -out crypt.txt OAEPパディング（推奨）には以下を使用してください。 openssl pkeyutl -encrypt -inkey pubkey.pem -pubin > -pkeyopt rsa_padding_mode:oaep > -pkeyopt rsa_oaep_md:sha256 > -in in.txt -out crypt.txt AN13030 セクション 3.3.5.6 には、 kAlgorithm_SSS_RSAES_PKCS1_OAEP_SHA256 および kAlgorithm_SSS_RSAES_PKCS1_V1_5 を含むサポートされているアルゴリズムがリストされています。 操作8：SE051のRSA秘密鍵を使用してデータを復号化する RSA秘密鍵の復号化は、SE051内部で完全に実行されます。秘密鍵はセキュアエレメントから決して外に出ることはありません。 使用 pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --decrypt --label sss:10101010 --slot 1 -i crypt.txt -o decrypt.txt cat decrypt.txt OpenSSL プロバイダー(v3.x)の使用 openssl pkeyutl -provider nxp -decrypt -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in crypt.txt -out decrypt.txt AN13030 セクション2.3.4は「RSAの暗号化および復号機能がプロバイダーに追加された」(v04.05.03以降、v04.07.01に含まれます)を確認しています。 キーIDラベルの慣例 NXP PKCS#11ライブラリで pkcs11-tool を使用する場合、Key IDラベル形式は以下の通りです。 sss: 例えば、キーID 0x10101010 →ラベル sss:10101010 バージョン04.07.00 (PKCS#11 v4.7) における互換性のない変更点:バイトスワップを回避するため、 CKA_ID 属性（ --id ）はバイト配列として扱われるようになりました。エンディアンを変更せずにIDを渡します。 PKCS#11トークンの初期化（初回設定） pkcs11-tool を使用する前に、トークンスロットを初期化する必要がある場合があります。 # Initialize slot 0 pkcs11-tool --module $PKCS11_MODULE --init-token --slot 0 --label "SE051_Token" --so-pin 12345678 # Set user PIN pkcs11-tool --module $PKCS11_MODULE --init-pin --slot 0 --login --so-pin 12345678 --pin 87654321 OpenSSL 3.x プロバイダー構成 /etc/ssl/openssl.cnf （またはカスタム設定ファイル）に追加します。 [openssl_init] providers = provider_sect [provider_sect] default = default_sect nxp = nxp_sect [default_sect] activate = 1 [nxp_sect] module = /usr/local/lib/libsss_provider.so activate = 1 OpenSSLプロバイダーのソースは以下の場所でも利用可能です: https://github.com/NXPPlugNTrust/se05x-openssl-provider ソースコード例（simw-top内） MWパッケージに内蔵された以下の例は、これらの操作を直接示しています: 動作 パス例 AESの暗号化/復号 simw-top/sss/ex/symmetric/ex_sss_symmetric.c RSA署名/検証 simw-top/sss/ex/rsa/ （AN13030のセクション5.2.1.2） ECC署名/検証 simw-top/sss/ex/ecc/ （AN13030のセクション5.2.1.1） PKCS#11 スクリプト simw-top/sss/plugin/pkcs11/scripts/ OpenSSL プロバイダ RSA enc simw-top/sss/plugin/openssl_provider/scripts/openssl_RsaEnc.py OP-TEEにおける既知の制限事項 OP-TEEカーネル側からSE051へのAESオフロードは、 CFG_NXP_SE05X_CTR_DRV 有効化されている必要があります。PKCS#11を経由したユーザー空間AESはアクセス**マネージャ**を経由し、OP-TEEの暗号**ドライバ**オフロードとは別に行われます。 SE051のRSA鍵生成は、バージョン04.07.01でデフォルトでCRT形式となっています(PKCS11 v4.8でサポートが追加され RSA_CRT )。cmakeオプション PKCS11_ENABLE_RSA_KEY_GEN_CRT を使ってCRTと普通のRSAを切り替えてください。 SE051 NVMには制限があります。RSA鍵ペアの生成回数が多いと、永続ストレージが枯渇する可能性があります。使用されていないオブジェクトは ssscli delete で削除してください。 複数のプロセス同時アクセス(例:複数のユーザー空間アプリ)には、 simw-top/hostlib/hostlib/accessManager のアクセスマネージャを使用します。 -DSMCOM:STRING=JRCP_V1_AM で構築します。 参考資料 ドキュメント 説明 AN13030 プラグ&トラストMWドキュメント(主要参照) AN12660 SE05xによるIEC 62443準拠 ― SSS APIの例へのポインタを含む simw-top/doc/ (ローカルHTML) インストール済みバージョンv04.08.01の完全なドキュメント simw-top/doc/plugins/pkcs11.html PKCS#11 スタンドアロンライブラリのドキュメント simw-top/doc/demos.html 利用可能なデモ例の完全なリスト お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? こんにちは、 @Uc_S さん。 CFG_NXP_SE05X=y が設定されると、OP-TEEはSE051のI2Cバスの独占所有権を取得します。Linux DTSはそのI2Cコントローラを無効にしなければなりません(統合ガイドに記載されています)。これは、Plug & Trust MW の使用方法を根本的に変えるものです。 レイヤ 誰が運営しているのか SE051への到達方法 OP-TEE セキュアワールド OP-TEEコア ネイティブI2Cドライバー( CFG_IMX_I2C=y )— ダイレクト、排他 Linuxユーザースペース あなたのアプリケーション、ssscli、アクセス マネージャ T1oI2Cは使えません — Linux DTSではI2Cが無効化されています つまり、既存のcmake設定はLinuxが直接I2Cを所有している場合にのみ適用される -DPTMW_SMCOM=T1oI2C です。OP-TEEの設定では、以下に説明する2つの異なるビルドシナリオに適用されます。 シナリオ1：MWビルドがOP-TEE（ CFG_NXP_SE05X_PLUG_AND_TRUST= ）に供給される これが最も重要な事件です。MWはOP-TEE内部で静的ライブラリとしてコンパイルされるため、 cmake 手動で実行する必要はありません。OP-TEEのMakefileは、 CFG_NXP_SE05X_PLUG_AND_TRUST で抽出したMWディレクトリを指定すると、自動的に統合処理を行います。 CFG_NXP_SE05X_PLUG_AND_TRUST=$HOME/linux-factory/plug-and-trust あなたが挙げたSMCOM、Host、およびAuthフラグは、ここでは適用されません。OP-TEEは独自のネイティブI2C抽象化層( CFG_IMX_I2C=y )を介してSE051を駆動し、Linux MW通信スタックを完全にバイパスします。 シナリオ2:Linuxユーザースペースツール(ssscli / Access Manager / デモ) ここで、CMakeのフラグが適用されます。OP-TEEがI2Cを所有する場合、変更が必要な箇所をフラグごとに分析した結果は以下のとおりです。 変更しなければならない旗 フラグ 現在の価値 OP-TEEセットアップの推奨値 理由 -DPTMW_SMCOM T1oI2C JRCP_V1_AM (アクセス マネージャを使う場合) Linuxは直接I2Cを使用できません。アクセス マネージャはソケットプロキシを提供します -DPTMW_SE05X_Auth PlatfSCP03 None SCP03チャネルはLinuxユーザースペースではなくOP-TEEによって確立されています -DPTMW_SCP SCP03_SSS None 同じ理由です。SCP03はOP-TEEセキュアワールドが所有しています。 変わらない旗 フラグ バリュー 理由 -DPTMW_Applet SE05X_C お使いのSE051C2バリアント（OEF ID A8FA）に適合しています。 -DPTMW_SE05X_Ver 07_02 OP-TEEのブートログに見られるアプレットバージョン7.2に一致します。 -DPTMW_Host iMXLinux まだLinux i.MX 動いています -DPTMW_HostCrypto OPENSSL 変更なし -DPTMW_RTOS Default 変更なし -DPTMW_OpenSSL 3_0 OpenSSL 3.x では変更なし -DPTMW_FIPS None 変更なし -DPTMW_SBL None 変更なし -DPTMW_mbedTLS_ALT None 変更なし -DPTMW_Log Silent 変更なし -DPTMW_SE_RESET_LOGIC 1 変更なし。v04.07.00で新しいオプションが追加されました。 LinuxユーザースペースツールのOP-TEEセットアップにおける推奨cmakeコマンド cd simw-top && mkdir build_optee_linux cmake -S . -B ./build_optee_linux/ -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=None -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=None -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 cd build_optee_linux && make -j8 注: JRCP_V1_AM アクセスマネージャーがターゲット上でデーモンとして動作している必要があります。アクセスマネージャー自体はSE051に接続しますが、重要な注意点を参照してください。 重要な注意点:アクセスマネージャーとのI2C対立 アクセスマネージャー( hostlib/hostLib/accessManager )は、複数のLinuxプロセスからの同時I2Cアクセスをシリアライズするよう設計されています。しかし： OP-TEEがLinux DTSでI2Cインターフェースを完全に無効にした場合( CFG_NXP_SE05X=y で求められます)、アクセスマネージャー自体もI2Cを起動できません。 つまり、有効なデプロイメントオプションは2つあります。 選択肢A：OP-TEE限定（生産向け推奨） OP-TEEはI2Cを完全に所有しています。Linuxユーザースペースでは、暗号操作にはOP-TEE PKCS#11 TA( libckteec.so )のみを使用しています。このモードでは、Plug and Trust MWのSSSCLIやデモはLinuxからは実行されません。 Linux App → libckteec.so → OP-TEE PKCS#11 TA → SE051 これは i.MX Linux ユーザーガイド(UG10163)で説明されているOP-TEEベースのSE05x使用に関する経路です。 選択肢B：共存（テスト／プロビジョニング） LinuxからI2Cを無効化 しない LinuxのDTSを使いましょう(つまり、 lf-6.12.y-i2c-disabled-se050 DTSパッチを適用しないでください)。この構成では： OP-TEEは暗号化オフロード（RSA/ECC）にSE051を使用します。 Linuxのユーザースペースは、元のフラグを使ってSSSCLIやアクセスマネージャーを T1oI2C 実行できます。 リスク:OP-TEEとLinuxの両方からの同時I2Cアクセスには慎重な仲裁が必要です この選択肢では、 SMCOM、SCP、およびAuthフラグを元の値に戻し、元のI2C DTSを維持してください（無効にしないでください）。 要約表 ユース・ケース SMCOM SCP 認証 備考 OP-TEE内部MW（OP-TEEビルド用の静的ライブラリ） N/A N/A N/A cmakeは不要です。 CFG_NXP_SE05X_PLUG_AND_TRUST= Linuxユーザースペース、OP-TEE独占I2C JRCP_V1_AM None None Access Managerが必要ですが、I2Cを無効にするとAM自体がSE051にアクセスできません Linuxユーザースペース、共存(I2C共有) T1oI2C SCP03_SSS PlatfSCP03 あなたの元のフラグは、Linux DTSがまだI2Cを有効にしている場合に有効です Linuxユーザースペース(PKCS#11 TA経由、OP-TEE限定) 該当なし（MWビルドなし） N/A N/A pkcs11-tool / openssl を libckteec.so 追加参考資料 AN13030 Rev. 2.4 — セクション4.4(i.MX Linux ビルド)、セクション8.9(PKCS#11 スタンドアロンライブラリ)、Access Managerドキュメント UG10163 i.MX Linuxユーザーガイド — libckteec.so を用いたOP-TEE PKCS#11コマンド例(セクション10.4.7および10.4.8、110–114ページ); 注: これらの例はOP-TEE内部セキュアストレージをキーバックエンドとして使用しており、SE05xを直接使うわけではありません。SE051がOP-TEE暗号バックエンドとしてCFG_NXP_SE05X=yを介して設定されている場合もコマンド構文は同じです すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? @Kan_Li 丁寧かつ詳細なご回答をいただき、誠にありがとうございました。 サポートされている3つのパスの詳細な説明とコマンド例は非常に役立ちます。 OP-TEE環境に関して、Linuxのrootfs上のPlug & TrustミドルウェアのCMakeビルド構成について追加の質問があります。 以前は、OP-TEEルーティングなしでLinux上でミドルウェアを直接実行していた際、以下のCMake設定フラグを使用していました: -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=T1oI2C -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=SCP03_SSS -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 上記の設定のうちどれを変えるべきか、またこのOP-TEEセットアップで推奨される新しい値は何であるべきか教えていただけますか? 詳細： OP-TEEがSE051への直接I2Cアクセス(CFG_NXP_SE05X=y経由)を所有している今、Linuxのユーザー空間ミドルウェアやツール(SSSCLIやアクセス マネージャなど)を構築する際に、これらのCMakeフラグのいずれかを変更する必要があるのか教えていただけますか? 具体的には、-DPTMW_SMCOM(例:T1oI2CからJRCP_V1_AMやソケットインターフェースへの変更)や-DPTMW_Hostのようなオプションは、Linuxユーザー空間向けにOP-TEE経由でリクエストを適切にルーティングするために更新すべきでしょうか? 私の環境情報は以下のとおりです。 基板：MCIMX8M-WEVKおよびOM-SE051ARD Plug and Trust MW バージョン: v04.07.01 OP-TEE OSバージョン：3.19.0 Linuxカーネル:6.1.151 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? この非常に詳細かつ明快な説明をいただき、誠にありがとうございました。 フラッグごとの説明、ビルドコマンドの例、特にI2Cの競合と選択肢A(OP-TEE独占、libckteec.so 経由)の選択に関する重要な注意点そして選択肢B（共存）によって、設定オプションが明確になりました。 この情報は、今後のアーキテクチャを決定する上でまさに必要なものでした。

How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Hello, NXP Community, I am currently working on integrating the Plug and Trust Middleware into OP-TEE based on the environment described in this post: How to integrate Plug and Trust MW into OP-TEE. My goal is to achieve the following operations from a user-space application running on Linux, leveraging the SE051 secure element: Generate an AES key and store it in SE051. Generate an RSA key pair and store it in SE051. Encrypt a file using the AES key stored in SE051. Decrypt the file using the AES key stored in SE051. Sign data using the RSA private key in SE051. Verify the signature using the RSA public key in SE051. Encrypt data using the RSA public key in SE051. Decrypt data using the RSA private key in SE051. Could anyone guide me on the best approach to achieve these operations? I am open to using any of the following command-line tools (or a combination of them), provided they are supported in this OP-TEE setup: openssl commands (via OpenSSL provider) ssscli tool pkcs11-tool (via PKCS#11 interface) Any examples, documentation links, or command usage samples for this specific OP-TEE environment would be greatly appreciated. SE050 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Hi @Uc_S , There are three supported paths from Linux user-space to the SE051. All three are available with Plug & Trust MW v04.07.01: Path Library Best For PKCS#11 libsss_pkcs11.so AES, RSA key gen/sign/verify/enc/dec via pkcs11-tool OpenSSL Provider (3.x) libsss_provider.so RSA sign/verify/enc/dec via openssl pkeyutl ssscli Python CLI Key injection / provisioning only Important note for OP-TEE environment: In your OP-TEE setup ( CFG_NXP_SE05X=y ), the SE051 is accessed by OP-TEE core directly via the native I2C driver. Linux user-space applications do not own the I2C bus. All three paths above work correctly because the Plug & Trust MW Access Manager ( accessManager ) or the T1oI2C socket interface routes commands through OP-TEE's trusted world to the SE051. Operation 1: Generate an AES Key and Store It in SE051 Use ssscli to generate an AES-256 key at a specific Key ID (object ID in SE051): # Generate AES-256 key at Key ID 0x20000001 ssscli generate aes 0x20000001 256 To verify the key exists: ssscli get aes 0x20000001 aes_key_info.txt Note: AES keys are symmetric and cannot be exported from SE051. The Key ID 0x20000001 is a 32-bit object identifier stored persistently in SE051 NVM. Operation 2: Generate an RSA Key Pair and Store It in SE051 Option A — Using pkcs11-tool (recommended) RSA key labels use the format sss: : # Generate RSA-2048 key pair at Key ID 0x10101010 pkcs11-tool --module $PKCS11_MODULE --keypairgen --key-type rsa:2048 --label "sss:10101010" Option B — Using ssscli ssscli generate rsa 0x10101010 2048 AN13030 Section 3.3.8.3 notes: RSA key pairs must be DER encoded using PKCS#8 or traditional OpenSSL format when injecting externally. When retrieved via sss_key_store_get_key() , only the public key is returned. Operation 3: Encrypt a File Using the AES Key in SE051 AES symmetric encryption is performed via the SSS API ( sss_cipher_one_go ) or, for command-line use, through a small wrapper application. The MW provides a built-in symmetric example at: simw-top/sss/ex/symmetric/ex_sss_symmetric.c For direct command-line use, build and run the example: # After building the MW examples: ./se05x_symmetric_aes_cbc_encrypt --keyid 0x20000001 --input plaintext.bin --output ciphertext.bin --iv 00000000000000000000000000000000 The MW supports: kAlgorithm_SSS_AES_ECB , kAlgorithm_SSS_AES_CBC , kAlgorithm_SSS_AES_CTR , kAlgorithm_SSS_AES_GCM , kAlgorithm_SSS_AES_CCM (from Section 3.3.9.1 of AN13030). Operation 4: Decrypt a File Using the AES Key in SE051 ./se05x_symmetric_aes_cbc_decrypt --keyid 0x20000001 --input ciphertext.bin --output decrypted.bin --iv 00000000000000000000000000000000 The SSS API uses kMode_SSS_Decrypt mode with sss_cipher_one_go() for one-shot decryption, or the multi-step sss_cipher_init() / sss_cipher_update() / sss_cipher_finish() sequence for streaming. Operation 5: Sign Data Using the RSA Private Key in SE051 Using pkcs11-tool (key stays in SE051) # Sign with RSA private key (key never leaves SE051) pkcs11-tool --module $PKCS11_MODULE --sign --label sss:10101010 -m SHA256-RSA-PKCS --slot 1 -i in.der -o signature.der Supported sign mechanisms via PKCS#11: SHA256-RSA-PKCS (RSASSA-PKCS1-v1_5 with SHA-256) SHA1-RSA-PKCS , SHA384-RSA-PKCS , SHA512-RSA-PKCS RSA-PKCS-PSS (PSS padding) Using OpenSSL Provider (v3.x) # Configure OpenSSL to use the NXP provider (see /etc/ssl/openssl.cnf) openssl pkeyutl -provider nxp -sign -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in in.txt -out signature.der   Operation 6: Verify Signature Using the RSA Public Key in SE051 Step 1 — Export public key from SE051 # Method A: via ssscli ssscli get rsa pub 0x10101010 rsa_pub.der # Method B: via pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --read-object --type pubkey --slot 1 --label sss:10101010 -o pubkey.der # Convert DER to PEM for OpenSSL openssl rsa -in pubkey.der -inform der -out pubkey.pem -outform pem -pubin Step 2 — Verify (host-side, no SE051 required) openssl dgst -keyform PEM -verify pubkey.pem -sha256 -signature signature.der in.txt # Expected output: Verified OK Operation 7: Encrypt Data Using the RSA Public Key in SE051 RSA encryption uses the public key (no secure element needed for encrypt): # Encrypt with public key (host side) openssl rsautl -encrypt -inkey pubkey.pem -in in.txt -pubin -out crypt.txt For OAEP padding (recommended), use: openssl pkeyutl -encrypt -inkey pubkey.pem -pubin > -pkeyopt rsa_padding_mode:oaep > -pkeyopt rsa_oaep_md:sha256 > -in in.txt -out crypt.txt AN13030 Section 3.3.5.6 lists supported algorithms including kAlgorithm_SSS_RSAES_PKCS1_OAEP_SHA256 and kAlgorithm_SSS_RSAES_PKCS1_V1_5 . Operation 8: Decrypt Data Using the RSA Private Key in SE051 The RSA private key decryption is performed entirely inside SE051. The private key never leaves the secure element. Using pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --decrypt --label sss:10101010 --slot 1 -i crypt.txt -o decrypt.txt cat decrypt.txt Using OpenSSL Provider (v3.x) openssl pkeyutl -provider nxp -decrypt -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in crypt.txt -out decrypt.txt AN13030 Section 2.3.4 confirms: "RSA Encrypt and decrypt feature added in provider" (from v04.05.03 onwards, included in v04.07.01). Key ID Label Convention When using pkcs11-tool with the NXP PKCS#11 library, the Key ID label format is: sss: For example, Key ID 0x10101010 → label sss:10101010 Breaking change in v04.07.00 (PKCS#11 v4.7): The CKA_ID attribute ( --id ) is now treated as a byte array to avoid byte swapping. Pass the ID without changing endianness. PKCS#11 Token Initialization (First-Time Setup) Before using pkcs11-tool , you may need to initialize the token slot: # Initialize slot 0 pkcs11-tool --module $PKCS11_MODULE --init-token --slot 0 --label "SE051_Token" --so-pin 12345678 # Set user PIN pkcs11-tool --module $PKCS11_MODULE --init-pin --slot 0 --login --so-pin 12345678 --pin 87654321 OpenSSL 3.x Provider Configuration Add to /etc/ssl/openssl.cnf (or a custom config file): [openssl_init] providers = provider_sect [provider_sect] default = default_sect nxp = nxp_sect [default_sect] activate = 1 [nxp_sect] module = /usr/local/lib/libsss_provider.so activate = 1 The OpenSSL provider source is also available at: https://github.com/NXPPlugNTrust/se05x-openssl-provider Source Code Examples (in simw-top) The following built-in examples in the MW package directly demonstrate these operations: Operation Example Path AES encrypt/decrypt simw-top/sss/ex/symmetric/ex_sss_symmetric.c RSA sign/verify simw-top/sss/ex/rsa/ (Section 5.2.1.2 of AN13030) ECC sign/verify simw-top/sss/ex/ecc/ (Section 5.2.1.1 of AN13030) PKCS#11 scripts simw-top/sss/plugin/pkcs11/scripts/ OpenSSL Provider RSA enc simw-top/sss/plugin/openssl_provider/scripts/openssl_RsaEnc.py Known Limitations in OP-TEE Context AES offload to SE051 from OP-TEE kernel side depends on CFG_NXP_SE05X_CTR_DRV being enabled. User-space AES via PKCS#11 goes through the Access Manager and is separate from the OP-TEE crypto driver offload. RSA key generation in SE051 is CRT format by default in v04.07.01 ( RSA_CRT support added in PKCS11 v4.8). Use PKCS11_ENABLE_RSA_KEY_GEN_CRT cmake option to switch between CRT and plain RSA. SE051 NVM is limited. Many RSA key pair generations may exhaust persistent storage — delete unused objects with ssscli delete . For concurrent multi-process access (e.g., multiple user-space apps), use the Access Manager at simw-top/hostlib/hostlib/accessManager . Build with -DSMCOM:STRING=JRCP_V1_AM . Reference Documents Document Description AN13030 Plug & Trust MW Documentation (primary reference) AN12660 IEC 62443 compliance with SE05x — includes SSS API example pointers simw-top/doc/ (local HTML) Full documentation for your installed version v04.08.01 simw-top/doc/plugins/pkcs11.html PKCS#11 Standalone Library documentation simw-top/doc/demos.html Complete list of available demo examples Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Hi @Uc_S , When CFG_NXP_SE05X=y is set, OP-TEE takes exclusive ownership of the I2C bus to the SE051. The Linux DTS must disable that I2C controller (as described in the integration guide). This fundamentally changes how the Plug & Trust MW is used: Layer Who Runs It How It Reaches SE051 OP-TEE Secure World OP-TEE core Native I2C driver ( CFG_IMX_I2C=y ) — direct, exclusive Linux Userspace Your application, ssscli, Access Manager Cannot use T1oI2C — I2C is disabled in Linux DTS This means your existing cmake configuration with -DPTMW_SMCOM=T1oI2C applies only when Linux directly owns I2C. In the OP-TEE setup, it applies to two separate build scenarios described below. Scenario 1: MW Build Fed into OP-TEE ( CFG_NXP_SE05X_PLUG_AND_TRUST= ) This is the most important case. The MW is compiled as a static library inside OP-TEE — you do not run cmake manually for this. OP-TEE's Makefile handles the integration automatically when you point CFG_NXP_SE05X_PLUG_AND_TRUST at your extracted MW directory: CFG_NXP_SE05X_PLUG_AND_TRUST=$HOME/linux-factory/plug-and-trust The SMCOM, Host, and Auth flags you listed are not applicable here. OP-TEE drives the SE051 via its own native I2C abstraction layer ( CFG_IMX_I2C=y ), bypassing the Linux MW communication stack entirely. Scenario 2: Linux Userspace Tools (ssscli / Access Manager / Demos) This is where your cmake flags do apply. When OP-TEE owns I2C, here is the flag-by-flag analysis of what must change: Flags That MUST Change Flag Your Current Value Recommended Value for OP-TEE Setup Reason -DPTMW_SMCOM T1oI2C JRCP_V1_AM (if using Access Manager) Linux cannot use I2C directly; Access Manager provides socket proxy -DPTMW_SE05X_Auth PlatfSCP03 None SCP03 channel is established by OP-TEE, not Linux userspace -DPTMW_SCP SCP03_SSS None Same reason — SCP03 is owned by OP-TEE secure world Flags That Stay the Same Flag Value Reason -DPTMW_Applet SE05X_C Correct for your SE051C2 variant (OEF ID A8FA) -DPTMW_SE05X_Ver 07_02 Matches applet version 7.2 seen in OP-TEE boot logs -DPTMW_Host iMXLinux Still running on i.MX Linux -DPTMW_HostCrypto OPENSSL Unchanged -DPTMW_RTOS Default Unchanged -DPTMW_OpenSSL 3_0 Unchanged for OpenSSL 3.x -DPTMW_FIPS None Unchanged -DPTMW_SBL None Unchanged -DPTMW_mbedTLS_ALT None Unchanged -DPTMW_Log Silent Unchanged -DPTMW_SE_RESET_LOGIC 1 Unchanged; new option added in v04.07.00 Recommended cmake Command for Linux Userspace Tools in OP-TEE Setup cd simw-top && mkdir build_optee_linux cmake -S . -B ./build_optee_linux/ -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=None -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=None -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 cd build_optee_linux && make -j8 Note: JRCP_V1_AM requires the Access Manager to be running as a daemon on the target. The Access Manager itself connects to the SE051 — but see the important caveat below. Critical Caveat: The Access Manager I2C Conflict The Access Manager ( hostlib/hostLib/accessManager ) is designed to serialize concurrent I2C access from multiple Linux processes. However: When OP-TEE fully disables the I2C interface in Linux DTS (as required by CFG_NXP_SE05X=y ), the Access Manager itself cannot open I2C either. This means you have two valid deployment choices: Choice A: OP-TEE Exclusive (Recommended for Production) OP-TEE owns I2C completely. Linux userspace uses only the OP-TEE PKCS#11 TA ( libckteec.so ) for crypto operations. The Plug & Trust MW ssscli and demos are not run from Linux in this mode. Linux App → libckteec.so → OP-TEE PKCS#11 TA → SE051 This is the path described in the i.MX Linux User's Guide (UG10163) for OP-TEE-based SE05x use. Choice B: Co-existence (Testing / Provisioning) Use a Linux DTS that does not disable I2C from Linux (i.e., do NOT apply the lf-6.12.y-i2c-disabled-se050 DTS patch). In this configuration: OP-TEE uses SE051 for crypto offload (RSA/ECC) Linux userspace can still run ssscli / Access Manager using T1oI2C (your original flags) Risk: concurrent I2C access from both OP-TEE and Linux requires careful arbitration For this choice, revert SMCOM, SCP, and Auth flags to your original values and keep the original I2C DTS (do not disable it). Summary Table Use Case SMCOM SCP Auth Notes OP-TEE internal MW (static lib for OP-TEE build) N/A N/A N/A No cmake needed; handled by CFG_NXP_SE05X_PLUG_AND_TRUST= Linux userspace, OP-TEE exclusive I2C JRCP_V1_AM None None Requires Access Manager, but AM itself can't reach SE051 if I2C disabled Linux userspace, co-existence (I2C shared) T1oI2C SCP03_SSS PlatfSCP03 Your original flags — valid if Linux DTS still has I2C enabled Linux userspace via PKCS#11 TA (OP-TEE exclusive) N/A (no MW build) N/A N/A Use pkcs11-tool / openssl with libckteec.so Additional Reference AN13030 Rev. 2.4 — Section 4.4 (i.MX Linux Build), Section 8.9 (PKCS#11 Standalone Library), Access Manager documentation UG10163 i.MX Linux User's Guide — OP-TEE PKCS#11 command examples using libckteec.so (Sections 10.4.7 & 10.4.8, pages 110–114); Note: these examples use OP-TEE internal secure storage as the key backend, not SE05x directly — the command syntax is the same when SE051 is configured as the OP-TEE crypto backend via CFG_NXP_SE05X=y Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? @Kan_Li  Thank you very much for the thorough and detailed response. The breakdown of the three supported paths and the command examples are extremely helpful. Regarding the OP-TEE environment, I have a follow-up question regarding the CMake build configuration for the Plug & Trust Middleware on the Linux rootfs. Previously, when running the middleware directly on Linux (without OP-TEE routing), we used the following CMake configuration flags: -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=T1oI2C -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=SCP03_SSS -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 Could you please advise which of the above settings should be changed and what their new recommended values should be for this OP-TEE setup? Details: Now that OP-TEE owns the direct I2C access to the SE051 (via CFG_NXP_SE05X=y), could you please clarify if any of these CMake flags need to be modified when building the Linux user-space middleware/tools (such as ssscli or Access Manager)? Specifically, should options like -DPTMW_SMCOM (e.g., changing from T1oI2C to JRCP_V1_AM or socket interface) or -DPTMW_Host be updated for the Linux user-space side to properly route requests through OP-TEE? Here are my environment details: Board: MCIMX8M-WEVK and OM-SE051ARD Plug and Trust MW Version: v04.07.01 OP-TEE OS Version: 3.19.0 Linux Kernel: 6.1.151 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Thank you very much for this exceptionally detailed and clear explanation. The flag-by-flag breakdown, the build command example, and especially the critical caveat regarding the I2C conflict and the choice between Choice A (OP-TEE Exclusive via libckteec.so) and Choice B (Co-existence) have clarified our setup options. This information was exactly what we needed to determine our architecture moving forward.

Opinions on "Smart Energy" solar I had some door knocker salesmen around today from Smart Energy wanting to talk about solar panels. I'm interested in solar but don't have the funds to invest up front and they said something about a govt funded scheme with $0 upfront. Naturally I'm very sceptical. Would love to hear from anyone who has dealt with them.

NTAG 224/223 ドキュメント こんにちは、 223/224 TTタグとNon-TTタグの設定ページのドキュメントを見ているのですが、223 DNA(非TT)構成は他のタグとはかなり異なっているようで、SUNCMAC_KEY 2つの別々の領域に分かれて漂っています。これはドキュメントの誤りのように思われますので、問題を解決するか誤解を解消するためにお知らせしたいと思います。 敬具 ティノ 223 TT 223 224 224 TT

【紧急】从 SEM 任务调用 S32N55 GrayVIP HSE MAC 服务时返回 KEY_EMPTY (0xA5AA5317) 错误 您好。 请您帮忙查一下这个问题好吗？ 环境： SW32N5_GRAYVIP_1.0.25.0 尝试通过自定义 SEM 任务作业在运行时（用于 OTA）重新安装 SMR。 我做了什么： 添加了一个自定义 SEM 命令，该命令从 Fss_Sem_PerformHSERequests（SEM 任务上下文）触发 SMR 重新安装。 SMR 签名使用 AES-256 CMAC，通过 HSE_SRV_ID_MAC（GenerateMAC）进行，密钥安装在 AES NvmKeyGroup（MuMask = MU_0）中。 HSE 请求通过 Fss_Sem_SendServiceRequest(FSS_SEM_CSSI_MU0, ...) 发送，路径与 PublishSysImage 相同。 问题： MAC 服务请求已被接受（发送返回 OK），但 HSE 响应为 0xA5AA5317 (HSE_SRV_RSP_KEY_EMPTY) 在初始启动时 SMR 安装过程中，相同的 CMAC 密钥和密钥插槽可以正常工作。 只有当从 SEM 任务（运行时）调用时，它才会返回 KEY_EMPTY。 从同一个 SEM 任务中执行 PublishSysImage（只读，无密钥）操作正常。 问题： 运行时 SMR 重新安装（初始配置之后）是否是受支持的工作流程？如果是这样，建议采取什么方法？ 为什么同一个密钥槽在启动时可以正常工作，但在 SEM 任务上下文中却会报告 KEY_EMPTY 错误？启用安全启动后，是否存在 MU/分区或密钥目录访问限制？

デバイスとの結合を解除することに関して こんにちは、 MCUXpresso SDKバージョン26.03を使ってBLE通信を実装しようとしています。 API関数Gap_RemoveBondについて質問があります。 その注記には、「このAPIは、呼び出し時にアクティブな接続が存在しないことを前提としています」と記載されている。 1.つまり、コネクテッドデバイスがない時だけ使えるということですか? 2. Gap_RemoveBondがアクティブな接続が存在する間に結合を除去できない場合、アクティブな接続が有効な状態で結合情報を除去する方法はありますか? 質問に関する追加情報 3つのデバイスがあると仮定します。 ・周辺機器 ・中央装置A ・中央装置B takuya08_0-1788256233203.pngtakuya08_0-1788256233203.pngtakuya08_0-1788256233203.pngtakuya08_0-1788256233203.png ペリフェラルはすでにセントラルAとセントラルBの両方と結合されています。 ペリフェラルがセントラルAとセントラルBの両方に積極的にコネクテッドされている場合: takuya08_1-1788256275044.pngtakuya08_1-1788256275044.pngtakuya08_1-1788256275044.pngtakuya08_1-1788256275044.png その指摘から、ペリフェラルはセントラルAとBがコネクテッドされている間は結合情報を削除できないと理解しています。 アクティブな接続中に、ボンディング情報を削除する方法はありますか？ ペリフェラルがセントラルAにのみ積極的に接続されている場合: takuya08_2-1788256364083.pngtakuya08_2-1788256364083.pngtakuya08_2-1788256364083.pngtakuya08_2-1788256364083.png 周辺機器がセントラルAとセントラルBの両方の結合情報を削除することは不可能でしょうか? それともセントラルBのボンディング情報だけを削除することは可能でしょうか? ペリフェラルがいかなるデバイスにも接続されていない場合: takuya08_3-1788256474725.pngtakuya08_3-1788256474725.pngtakuya08_3-1788256474725.pngtakuya08_3-1788256474725.png このコメントから、この場合、周辺機器はセントラルAとセントラルBの両方の結合情報を削除できると理解しています。 ご協力ありがとうございます。 Re: Regarding Removes the bond with a device @sofiaurueta ご返信ありがとうございます。 あなたの回答から、たとえ1台でも接続されていればボンディング情報は削除できないと理解しました。 ただ、念のためもう一度確認したいです。  2-1788256364083.png2-1788256364083.png2-1788256364083.png ペリフェラルにセントラルAとセントラルBの2つのデバイスの結合情報が保存されており、現在セントラルAにコネクテッドされている場合、以下の挙動のうちどれが起こるのでしょうか? 1.接続されていないセントラルBのボンド情報は削除可能です。 2. 2つの債券情報記録はいずれも削除できません。 Re: Regarding Removes the bond with a device こんにちは、お元気でお過ごしでしょうか。 Gap_RemoveBond() は、アクティブなBLE接続がない場合のみ呼び出せます。APIのドキュメントには、ボンド情報が削除される前にすべての接続を切断することを明記しています。同じ制限はGap_RemoveAllBonds()にも適用されます。 現在、MCUXpresso SDKのBLEホストスタックには、接続がアクティブな間にNVMボンドデータを削除することをサポートするAPIはありません。 アクティブなユースCASEでボンドを除去するための推奨フローは以下の通りです: 関連するコネクテッドピアの連絡先としてGap_Disconnect(deviceId)を呼び出し、切断を確認させるgConnEvtDisconnected_c接続イベント情報を待ってからGap_RemoveBond(nvmIndex)を呼び出します。 よろしくお願いします、 ソフィア。

Secure boot in imxrt1024..5A Abhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.png I have attached a snap of hex compare of signed and unsigned image (signed using SPT) i can see IVT have several changes that i didnt understand.  At 0x1000 offset Unsigned -> D1 00 20 41 00 20 00 60 00 00 00 00 00 00 00 00 Signed ->     D1 00 20 40 DD 22 00 60 00 00 00 00 00 00 00 00 Question 1 i understand that 41 is the IVT version that is hardcode inside my code how this is changed to 40? question 2. Also i dont understand  how 00 20 -> DD 22 At 0x1010 offeset This is clear as here CSF pointer got updated At 0x1020 Unsigned -> 00 00 00 60 00 00 40 00 00 00 00 00 Signed ->     00 00 00 60 00 A0 00 00 00 00 00 00 Question 3 how 00 40 is update with A0 00 The reason to ask these question is as per my understanding if development team gave bootable binary then i just need to append CSF.bin and update the CSF pointer in IVT to make it sign , but after seeing the difference i feel there are more things happening Re: Secure boot in imxrt1024..5A Abhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.png In earlier post i got this answer so i thought just appending csf and updating the vsff pointer in IVT means firmware is signed but since i want to use CST for signing the image how to do that? I already have bootable image (FCFB, IVT, BOOTDATA,...) . I just need to sign and ship the package how to do that , i have created hab.csf  [Header] Version = 4.0 #Avalibale engine are DCP, SW, ANY for IMXRT Engine = DCP Engine Configuration = 0 Certificate Format = x509 Signature Format = CMS Hash Algorithm = sha256 #Install root public key for use in subsequent INSTALL CSFK or Install KEY #HAB install in slot 0 of its internal public key store # HAB just re-hashes the table and compares against the fused SRK-hash. [Install SRK] File = "keys/SRK_1_2_3_4_table.bin" #Tell which SRK to use, installation will fail if revocation fuse with this index is burned Source index = 0 Hash Algorithm = sha256 #HAB install CSF key's cert in slot 1 [Install CSFK] File = "crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem" Certificate Format = x509 #Authenticate CSF command authenticates the CSF from which it is executed [Authenticate CSF] #Install a public key for use in subsequent Install key or Authenticate Data commands #HAB install IMG cert into key slot 2 [Install Key] #Means this cert is checked against the SRK Verification index = 0 Target index = 2 File = "crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem" [Authenticate Data] #Should be same as Target Index in Install Key Verification index = 2 Blocks = 0x60001000 0x1000 0x6580 "evkmimxrt1024_iled_blinky_unsigned_original.bin" Re: Secure boot in imxrt1024..5A Hi @Abhay2080 , Thanks for your questions! Based on the RT1024 IVT / Boot Data definition, the differences you see are expected and are not limited to the CSF pointer update. Q1: Why does D1 00 20 41 become D1 00 20 40 ? D1 00 20 41 is the IVT header: 0xD1 is the IVT tag, 0x0020 is the fixed IVT length of 32 bytes, and the last byte is the version. The RT1024 Reference Manual defines the IVT version as 0x40/0x41 , so 0x40 is valid and not an error. Please check this online guide: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mcu_bootloader/docs/iMXRT1024_Manufacturing_User_Guide/topics/imx_rt_bootable_image.html Q2: Why does 00 20 00 60 become DD 22 00 60 ? This is the IVT entry field. In little-endian format: 00 20 00 60 = 0x60002000 DD 22 00 60 = 0x600022DD The RT1024 RM defines entry as the absolute address of the first instruction to execute from the image. AN12108 also states that if the default entry point is not Reset_Handler , entryPointAddress should be set to the Reset_Handler address. So SPT likely updated the IVT entry from 0x60002000 to the actual application entry point. Please confirm the Reset_Handler address in the map file / ELF symbol table. Q3: Why does 00 00 40 00 become 00 A0 00 00 ? At 0x1020 this is Boot Data: start remains 0x60000000 length changes from 0x00400000 to 0x0000A000 The RT1024 RM defines Boot Data as containing the image start address and image length, and the Boot ROM reads the image address and length from this structure. Therefore, SPT updated the length field to match the final generated bootable/signed image layout. For RT-series HAB secure boot, the final signed image is not just “append CSF.bin + update the CSF pointer”. The IVT header, entry, Boot Data length, CSF pointer, and the address/length covered by the CSF Authenticate Data command must all be consistent. HAB recalculates the hash from the software in flash and compares it with the reference hash recovered from the signature; if an authenticated region is modified after signing, verification fails.[0dfe-E1] The recommended approach is to use the final signed image generated by SPT/CST, not to manually append CSF.bin only. I hope this clarification helps! Best regards, Gavin

Regarding Removes the bond with a device Hello, I'm trying to implement BLE communication using MCUXpresso SDK version 26.03. I have a question about the API function Gap_RemoveBond. The remark states, "This API requires that there are no active connections at call time." 1. Does this mean it can only be used when there are no connected devices? 2. If Gap_RemoveBond cannot be used to remove a bond while an active connection exists, is there a way to remove bonding information while an active connection is active? Additional information regarding the question Suppose there are three devices: ・Peripheral device ・Central device A ・Central device B takuya08_0-1788256233203.pngtakuya08_0-1788256233203.pngtakuya08_0-1788256233203.pngtakuya08_0-1788256233203.png The Peripheral device is already bonded with both Central A and Central B. When the Peripheral is actively connected to both Central A and Central B: takuya08_1-1788256275044.pngtakuya08_1-1788256275044.pngtakuya08_1-1788256275044.pngtakuya08_1-1788256275044.png Based on the remark, I understand that the Peripheral cannot delete the bonding information for Central A and B while they are connected. Is there any way to delete bonding information during an active connection? When the Peripheral is actively connected only to Central A: takuya08_2-1788256364083.pngtakuya08_2-1788256364083.pngtakuya08_2-1788256364083.pngtakuya08_2-1788256364083.png Is it impossible for the Peripheral to delete the bonding information for both Central A and Central B? Or is it possible to delete only Central B's bonding information? When the Peripheral is not connected to any device: takuya08_3-1788256474725.pngtakuya08_3-1788256474725.pngtakuya08_3-1788256474725.pngtakuya08_3-1788256474725.png Based on the remark, I understand that the Peripheral can delete the bonding information for both Central A and Central B in this case. Thank you for your help. Re: Regarding Removes the bond with a device @sofiaurueta  Thank you for your response. Based on your answer, I understand that bonding information cannot be deleted if even a single device is connected.  However, I would like to double-check to be sure.  2-1788256364083.png2-1788256364083.png2-1788256364083.png If the peripheral has bond information stored for two devices, Central A and Central B, and it is currently connected to Central A, which of the following behaviors occurs? 1. The bond information for the unconnected Central B can be deleted. 2. Neither of the two bond information records can be deleted. Re: Regarding Removes the bond with a device Hello, hope you are doing well. Gap_RemoveBond() can only be called when there are no active BLE connections. The API documentation explicitly requires that all connections be disconnected before bond information is removed. The same restriction applies to Gap_RemoveAllBonds(). There is currently no API in the MCUXpresso SDK BLE Host Stack that supports deleting NVM bond data while any connection is active. The recommended flow for removing a bond during an active use case is as follows: Call Gap_Disconnect(deviceId) for the relevant connected peers, wait for the gConnEvtDisconnected_c connection event confirming disconnection, then call Gap_RemoveBond(nvmIndex). Best regards, Sofia.