ヘルプ
英语（美国） | English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

2411142_ja-JP

キャンセル
提案をオンにする
自動提案では、入力時に可能な一致が提案されるので検索結果を素早く絞り込むことができます。
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2411142_ja-JP

2411142_ja-JP

se05x_TP_PlatformSCP03keys.cを使ってプラットフォームSCP03キーをデフォルトに戻す方法は?

こんにちは、NXPコミュニティの皆さん、

SE051のセキュア要素を扱っており、Plug and Trustミドルウェアを使ってプラットフォーム SCP03キーをデフォルト値に正しく戻す方法についてお尋ねしたいです。

これまでにやったこと:

  1. demos/se05x/se05x_RotatePlatformSCP03Keys/se05x_TP_PlatformSCP03keys.c を修正し、キーのリバートセクション (doc:start:revert-scp03-keys と doc:end:revert-scp03-keys の間) をコメントアウトしました。
  2. 私は自分のセットアップでアプリケーションをビルドし実行しました。
  3. 実行は成功し、「おめでとうございます!!! キーローテーション成功!!!!」というメッセージが表示されました。
  4. キー変更を確認するために、/tmp/SE05X/plain_scp.txtを新しいキー値(0x4041...ENC、MAC、DEK用)で更新し、SSSCLI Connectで正常に接続できました。
  5. その後の操作(ssscli generate rsa、ssscli set aes、ssscli se05x readidlist)はすべて正常に完了し、鍵が書き込まれIDが問題なく取得されたことが確認されました。
  6. 今、プラットフォーム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

アドバイスやコードに関するヒントをいただければ大変ありがたいです。

SE050Re: 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を参照してください。
-------------------------------------------------------------------------------

Re: How to revert Platform SCP03 keys back to default using se05x_TP_PlatformSCP03keys.c?

@Kan_Li

詳細なご指導をいただき、ありがとうございます。

あなたの指示に従い、キーを更新し、リバートブロックをコメントアウトし、ナノパッケージの例を無事に構築・実行しました。

しかし、実行中に、PUT KEY APDUコマンドの実行中に、SCP03キー更新操作がSWステータスコード6A80で失敗しました。実行ログの概要は以下のとおりです。

Plug and Trust nano package - version: 1.6.1
...
Establish Secure Channel to SE05x !
Sending GP Initialize Update Command !!!
...
CardCryptogram verified successfully...Calculate HostCryptogram
Sending GP External Authenticate Command !!!
APDU Tx> :84 82 33 00 10 ...
APDU Rx< :69 82
Authentication Successful!!!

Created scp03 Session
Changing SCP03 keys(version - 0b) to NEW KEYS
APDU Tx> :84 d8 0b 81 58 ...
APDU Rx< :6a 80
Error in DoAPDUTxRx
Error in ex_se05x_change_keys
SE05x Rotate SCP03 keys Example Failed !

根本的な原因としては、OpenSSLバージョン(ビルドPCとターゲット評価ボードの両方でOpenSSL 3.xが使用)がPutKey時のキーの派生やフォーマットに影響を与えているか、特にDEKの値が以前に不一致または書き換えられた可能性があります。

現時点では、これらの可能性をさらに調査したり対処したりするだけの十分な時間的余裕がありません。後日、時間があれば個別に調べてみます。

ご協力いただき、改めて感謝申し上げます。

Re: How to revert Platform SCP03 keys back to default using se05x_TP_PlatformSCP03keys.c?

こんにちは、 @Uc_S さん、


詳細な実行ログをありがとうございます。問題の特定に必要な情報がまさに揃っています。あなたが挙げた2人の容疑者は、どちらも正当で、論理的にも妥当です。以下に、最も可能性の高い状況をまとめました。

6A80エラーが教えてくれること

SW 6A80 (SW_WRONG_DATA)は、SE051がPUT KEY APDUのデータフィールドを暗号学的に無効として拒否したことを意味します。ログで認証が成功裏に完了した(CardCryptogram認証+外部認証成功)を示しているので、 ENCキーとMACキーは正しいことが確認されています。この失敗はPUT KEYステップに限定されており、これは DEKキー または 新しい鍵素材をラップするAES暗号化の問題を直接示しています。

容疑者1：DEKキーの不一致 ― 最も可能性の高い主な原因

PUT KEYコマンド内では、新しいキーはそれぞれ現在のDEKで暗号化されてからSEに送信されます。ホストコード内のDEK値がデバイスに保存されているDEK値と完全に一致しない場合、SEはガベージを復号して6A80を返します。

ほぼ同じケースで、以前のSE051C1顧客からの結論は以下の通りです。

「最小限のサンプルがPlatformSCPで動作するなら、ENCキーとMACキーは正しい。」キーの回転が依然として失敗するということは、DEKキーが間違っていることを意味します...過去にDEKキーが誤って設定された可能性があります。

これまでの経緯から考えると、これが最も可能性の高い根本原因です。以前の不完全または誤った回転により、SE051のDEKが0x4041...と一致しない状態になっている可能性があります。

確認手順：新品の工場出荷時のSE051サンプルで同じコードをテストします。即座に成功した場合、現在のデバイスのDEKの状態が破損しているか不明であることが確認され、チップを交換する必要があります。正しいDEKがなければ復旧手段はありません。

容疑者2：OpenSSL 3.x互換性 ― 実際のリスク、二次的原因

ナノパッケージのSCP03暗号パスは、レガシーの低レベルOpenSSL APIを使用しています。

AES_set_encrypt_key((uint8_t *)key, keylen * 8, &AESKey);
AES_ecb_encrypt(srcData, destData, &AESKey, AES_ENCRYPT);

ナノパッケージは OpenSSL 1.1.1のみで設計・テストされました。OpenSSL 3.xではこれらのAPIは非推奨化されており、レガシープロバイダーを実行時に明示的にロードする必要があります。もし読み込まれていなければ、これらの呼び出しは静かに誤った出力を生み出し、DEKで暗号化されたペイロードが破損し、6A80もトリガーされます。

推奨される修正方法: nanoパッケージを mbedTLS をホストの暗号バックエンド(-DEX_SE05X_USE_MBEDTLS=1)に切り替えてください。これは廃止されたOpenSSL APIに依存しず、このユースケースで完全にサポートされています。あるいは、OpenSSL 1.1.1に対して再構築してOpenSSLバージョン仮説を単独で検証する方法もあります。

推奨される手順

  1. まずは新品のSE051でテストしてください。これが、現在使用しているデバイスのDEKが根本原因かどうかを確認する最も迅速な方法です。
  2. 今後OpenSSL 3.xのリスクを排除するために、ホストの暗号バックエンドはmbedTLSに切り替えましょう。
  3. 新しいデバイスでもmbedTLSが動作しない場合は、詳細な調査のために、ビルド環境の詳細（OS、コンパイラ、mbedTLSのバージョン）をお知らせください。

ご注意ください：現在お使いのデバイスのDEKが不明な状態であることが確認された場合、それを復旧する方法はありません。工場出荷時のキーが設定された交換用チップが必要になります。

新たなサンプル検査の結果をお知らせください。喜んでさらにサポートさせていただきます。

すてきな一日を、
カン


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

Re: How to revert Platform SCP03 keys back to default using se05x_TP_PlatformSCP03keys.c?

@Kan_Li

6A80エラーに関する詳細な説明と分析をいただき、誠にありがとうございました。

DEKキーの不一致とOpenSSL 3.xとの互換性リスクに関する詳細な説明（およびmbedTLSの使用に関する提案）は有益であり、実際に作用しているメカニズムを明確にする。

これらの提案案――新しいサンプルでのテストや暗号バックエンドのmbedTLSの検討など――は、資源や帯域幅が許す将来のトラブルシューティングのために心に留めておきます。
タグ(1)
0 件の賞賛
この記事は役に立ちましたか? はい いいえ
評価なし
バージョン履歴
最終更新日:
3 週間前
更新者: