2404351_ja-JP

Yes

プラットフォームSCP03のキー回転SE050C1 — PUT KEYが拒否(6A80 / 6982)

NXPファクトリー(OEF)のキーから、当社独自のデバイス派生キーにSE050C1のプラットフォームSCP03キーをローテーションすることはできません。Plug&Trust 3.0.6と4.7.1の両方で、新品の部品に対して試したすべてのバリエーションでPUT KEYが拒否されました。

工場キーを使ったプラットフォーム SCP03セッションは正常に動作します — 開いてアプレットコマンド(GetVersion、GetRandom、ReadObject、WriteBinary)を正常に実行できます。PUT KEYのみが失敗します。

この部品でプラットフォームSCP03キーを回転させるための正しいAPDUシーケンスと、理想的には参照実装を知りたい。

設定：

セキュア要素SE050C1(SSS_PFSCP_ENABLE_SE050C1 = 1)
ATR 00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08 01 00 00 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41 54 50 4F(「JCOP4 ATPO」)
ホストMCU ESP32-S3、ESP-IDF v5.3.4
I2C経由でのT=1の転送（T1oI2C）
ミドルウェアPlug&Trust — 3.0.6と4.7.1をテストしましたが、どちらもミニ版で同じ動作でした。
認証 SE05X_Auth=PlatfSCP03、SSS_HAVE_SE05X_AUTH_PLATFSCP03
ホスト暗号化mbedTLS

この部品は工場出荷時の新品です。一度も正常に回転したことはなく、ex_sss_tp_scp03_keys.h の SE050C1 OEF キーで認証されます。

私たちが目指していること：

プラットフォームSCP03キーセット(ENC / MAC / DEK)を工場出荷時のOEFキーから、ESP32上で派生したデバイス固有のキー(PBKDF2-HMAC-SHA256、ESP32のeFuse常駐HMACキー上)にローテーションし、特定のホストMCUのみがSE050でプラットフォームSCP03セッションを開けるようにします。

うまくいっている点：

工場出荷時キーでプラットフォームSCP03セッションを開くと成功し、その中のコマンドはwork:scp :DEBUG:認証 Successful!!!

APDU :DEBUG:GetVersion [] -> 90 00

APDU EBUG:GetRandom [] -> 90 00
APDU EBUG:WriteBinary [] -> 90 00
つまり、チャネル、キー、セキュアメッセージングはすべて正常に機能しています。

何が失敗するか：

ケースA:
PUT KEYは6A80(誤ったデータ)で却下されます。

コマンドヘッダーと平文データフィールド（SCP03によるラッピング前）：

hdr : 80 D8 0B 81 Lc=70

データ: 0B <- キーバージョン番号
88 11 10 <16 バイト ENC エンコード。DEK> 03<3-byte KCV>
88 11 10 <16 バイト MAC 暗号化。DEK> 03<3-byte KCV>
88 11 10 <16 バイト DEK エンコード。DEK下＞ 03<3-byte KCV>

キー値は現在の(工場出荷時の)DEKでAES-CBCを用いてゼロIVで暗号化されます。KCVは、新しい鍵の下で16バイトの0x01ブロックのAES暗号化の最初の3バイトです。

ケースB:ISD選択
まずISDを選択すると:

GP_Select(A0 00 00 01 51 00 00 00) -> 90 00

応答:6F 10 84 08 A0000001 510000000 A5 04 9F 65 01 FF
同じPUT KEYは6A80ではなく6982(セキュリティ未履行)で却下されます。
これは、ISDがコマンドを認識しているものの、安全なチャネルを必要としていることを示唆しており、CASE Aの場合、コマンドはD8命令がないSE050アプレットに送られていたことになります。

しかし、ミドルウェアのGP_Select()は平文のAPDUを送信し、既存のSCP03チャネルを切断します。ISDを選択した後（セッションでfp_Transform / authType / pdynScp03Ctxをリセットした後、nxScp03_AuthenticateChannel()を再度呼び出した）にSCP03を再確立しようとする試みは失敗します。

scp :WARN :nxEnsure:'status == kStatus_SSS_Success' が失敗しました。

行:148 関数:nxScp03_AuthenticateChannel

ケースC:
DoAPDUTxRx_s_Case4_ext経由(Leと共に送信)すると6700(長さが誤り)を返し、ISDのFCI広告で9F 65 01 FF(最大データフィールド255)と一致します。

既に除外されているもの：

これらのそれぞれについてテストを行ったが、結果に違いはなかった。

試した変数の価値
P1 0x00(新規作成)、0x0B(現在のバージョンを置き換える)、0x11(ターゲットバージョン)
データフィールドの先頭KVNバイトが存在/不在
APDUケース4(短編)/Case4_ext(拡張)
キーブロック構造 88 11 10 03
現在のDEK(1ブロックのECBに相当)でのAES-CBC 0 IVキーラッピング
KCV方法AESは新しいキーで16×0x01の最初の3バイトを使いました
ミドルウェアバージョン Plug&Trust 3.0.6 および 4.7.1
DEKソースは、KEKがセッションを開く鍵セットと同じであることを確認した。
アプレットを選択した場合、すべてのバリアントで6A80が返されます。ISDを選択した場合、すべての短縮形バリアントで6982が返されます。

質問：

プラットフォームSCP03キーをSE050C1上で回転させる正しいAPDUシーケンスは何ですか?具体的には、PUT KEYは発行者セキュリティドメインに送信される予定ですか、それともSE050アプレットに送られる予定ですか?

もしISDに送る必要がある場合、Plug&Trustミドルウェアを使ってプラットフォームSCP03チャネルをISDに対してどのように構築すべきでしょうか?EX_SSS_BOOT_SKIP_SELECT_APPLET意図されたメカニズムでしょうか?もしそうなら、正しい呼び出し順序(SELECT ISD → INITIALIZE UPDATE → EXTERNAL AUTHENTICATE → PUT KEY)は何でしょうか?

上記のキーデータフィールドのフォーマットは、この部分において正しいでしょうか？特に、キータイプのコーディング、長さのエンコーディング、DEKラッピングモード、およびKCVアルゴリズムについて教えてください。

当社のPlug&TrustパッケージはnxScp03_Const.hでINS_GP_PUT_KEY(0xD8)を定義していますglobal_platf.h は存在するが、実装も使用例も含まれていない。プラットフォーム SCP03のキーローテーションの例やデモ(se05x_Delete_and_test_provisionプロビジョニング用のものに相当)を教えてもらえますか?またはフルSDKで教えていただけますか?

AN12436(ex_sss_auth.hで参照)を教えていただけますか?OEFプラットフォームSCP03キーのソースとして、あるいはこの部分のキー回転を文書化したアプリケーションノート?

背景 ― なぜこれが見過ごされたのか
透明性を保つために申し上げると、これは私たちが自ら招いた問題であり、ごく最近になってようやく気づいたことです。

当社のプロビジョニングコードはPUT KEYを呼び出し、その後、戻りステータスを破棄しました。

sw = gp_put_key_using_nxp_middleware(se, DERIVED_SCP03_KEYVER, ...);

/* ステータスは一度もチェックされていません */
mark_rotated(se, DERIVED_SCP03_KEYVER); /* "rotated"マーカーを書き込む */
ESP_LOGI(TAG, "SCP03キーが正常に回転しました"); /* 無条件に出力されます */

マーカー書き込み(WriteBinary)は成功するため、すべてのデバイスは「回転」フラグが設定され、プラットフォームSCP03キーが工場出荷時のままであり、プロビジョニングで成功が報告されます。その後、ステータスチェックを追加したところ、PUT KEYがどのユニットでも実際に成功したことがないことが判明しました。
その部分については、助けを求めていません。既に修正済みです。私たちがこの件を最初に提起するのではなく、今提起する理由を説明するため、そして当該部品が部分的に回転した状態ではなく、完全に回転していない状態であることを明確にするために、このことを言及しています。

SE050

Re: Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982)

こんにちは、 @Rutwik0409 さん。

提供された情報に基づき、SE050C1はアプレットレベルで正しく動作しているようです: SELECT 、 GetVersion 、 GetRandom 、 ReadObject 、そして WriteBinary 全員がSCP03プラットフォーム上で成功。したがって、これは基本的な輸送、T=1、SCP03キー、またはセキュアメッセージングの失敗ではないようです。

ESP32-S3をカスタムT=1のI²Cトランスポートで使用しているため、これはGlobalPlatformセキュリティドメインSCP03セッションに関するポートや統合の問題であり、SE050C1がSCP03キーローテーションをサポートしていない証拠ではない可能性が高いです。

Platform SCP03キーローテーション において、the PUT KEY コマンドは GlobalPlatform Security Domain操作 であり、SE050のIoTアプレットコマンドではありません。文書化された手順は以下のとおりです。

セキュリティドメイン/SSDを選択してください。
プラットフォームSCP03のセキュアチャネルを INITIALIZE UPDATE / EXTERNAL AUTHENTICATE で開け。
プラットフォームSCP03キーセットを更新するためにSend PUT KEY 。

これは観察された挙動とも一致する。

SE050アプレットを選択すると、 PUT KEY returns 6A80 これはGlobalPlatformコマンドを誤ったターゲットに送ることと一致します。
ISDを選択しても、そのドメインへのチャネルが PUT KEY returns 6982 に確立されていない場合、これは「セキュリティステータスが満たされていない」と一致します。

ですので、確認すべき主なポイントは SCP03プラットフォームがSE050アプレットに動作するかどうかだけでなく ミドルウェアが発行前に正しいセキュリティドメインに対してSCP03プラットフォームを開いているかどうかです PUT KEY 。

NXPは、この操作に関するリファレンスデモを提供しています。

se05x_RotatePlatformSCP03Keys

デモは、デフォルトのプラットフォームSCPキーでの認証と、そのキーをユーザー定義キーにローテーションする様子を具体的に説明しています。

弊社の推奨事項は、手動で構築することを避けることです。 PUT KEY 最初はAPDUを使用し、代わりにNXPのリファレンス実装と比較する。

まずは、NXPの公式リファレンスパス、例えばZephyr + nanoパッケージに収録されている「se05x_RotatePlatformSCP03Keys」デモを使って実装を検証することをお勧めします。これにより、移植作業なしでESP32 MCUがしっかりサポートされます。このデモは、NXPによるSCP03キー回転プラットフォームのリファレンス実装として機能しています。現在の問題は、「PUT KEY」コマンドが誤ったターゲットに送られているか、または対応するプラットフォームSCP03のセキュアチャネルがISD/SSDを選択した後に正しく確立されていないことを示唆しています。SCP03がSE050アプレットと通信しているからといって、GlobalPlatformセキュリティドメインレベルでの「PUT KEY」プロセスが正しく設定されているとは限りません。

詳細については、 https://github.com/NXPPlugNTrust/nano-package/blob/master/zephyr/readme.rstを参照してください。

お役に立てば幸いです。

すてきな一日を、
カン

-------------------------------------------------------------------------------
注記：
この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます!
- 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています
もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。
-------------------------------------------------------------------------------