2411151_ja-JP

はい

i.P-384秘密鍵/ブラックブロブの利用ケースにおけるMX8DXL CAAMカバーの制限

こんにちは、NXPチームの皆様、

私たちは、i.MX8DXL CAAMにおけるECDSA P-384ブラックキー/ブロブのサポートを評価しています。

観察された結果

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-blac...

/*

* KEYコマンドは32バイトに制限されているようなので、ロードを使うべきです

* コマンドは最大64バイトまで読み込み可能です。

*

* TODO: KEYコマンドは、より大きなキーをロードできるようにする必要があることを示しています

* 32バイトより小さいが、実際には機能しない

*

* TODO: LOAD コマンドは最大 96 までロードできるはずです

* バイトキーは実際には機能せず、64バイトに制限されています

*/

我々も同様の挙動を観察した。

KEYコマンドの代わりにLOADコマンドを使用することで、48バイトのP-384秘密鍵を含む、32バイトを超える鍵を扱うことができます。

しかし、これは上記の問題を解決するものではありません。鍵は覆ってブロブに保存できますが、復元された黒鍵はECDSA署名や検証に成功裏に使用できません。

私たちの質問：

CAAM COVER操作において、32バイトを超えるECC秘密鍵に対する既知の制限事項はありますか？
COVER経由で外部のP-384平文秘密鍵をインポートし、それをECDSAのブラックキーとして使うことはサポートされているユースケースでしょうか?
観測された動作は、CAAMハードウェアの制限によるものなのでしょうか？
外部生成されたP-384平文秘密鍵をインポートし、それをECDSA操作のブラックキーとして使う推奨されるCAAM方法はありますか?

何かアドバイスをいただければ幸いです。

ありがとうございます。よろしくお願いいたします。

ホジャメス。

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の制限を反映しているのか、それとも実装上の問題を反映しているのかを理解したいと考えています。

また、ECDSAのユースケースとは独立して、COVER操作自体に文書化されたサイズ制限があるかどうかもNXPは明確にしていただけますか?

よろしくお願いします。

Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case

このCAAM機能をテストするための環境を構築する必要があります。結果が出次第、ご連絡いたします。

Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case

こんにちは、イーピンワンさん

ご返信ありがとうございます。

>>この部分で、どのようなCAAMエラーが発生していましたか？
>>エラーコードを教えてもらえますか?

ECDSA関連のすべての操作には、以下のコードパッチを使用しています。
" https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx... "

署名検証のために caam_ecdsa_verify() を呼び出すとき、
'ECDSA_VERIFY_FAIL (0)' を返します。

このエラーは「P-384 (external plaintext private key)」の場合のみ発生します。

>> アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストしていますか?

私たちの成功例については、はい、似ています。
しかし、失敗したケース『P-384(外部平文秘密鍵)』については、
少し違います。鍵は外部から来ています。

よろしくお願いいたします。

Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case

「プレーンテキストキー → カバー → 黒キーの塊」
黒い塊から黒い鍵を復元する
ECDSAの署名/確認
結果：失敗

この部分で、どのようなCAAMエラーが発生していましたか？エラーコードを教えてもらえますか?アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストされていますか?ありがとう。

KEYコマンドの制限については、現在も調査中です。

Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case

失敗した場合、「KEY」コマンドと「FIFO STORE」コマンドを使って、平文の秘密鍵に基づいて黒鍵を生成していますか?失敗時に使われるCAAMの記述子(十六進形の単語)を捨てることは可能ですか?コマンドとパラメータを確認する方が簡単でしょう。ありがとう。

Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case

こんにちは、イーピンワンさん

>>失敗したCASEのために、
>>「KEY」コマンドと「FIFO STORE」コマンドを使っていますか?
>>平文の秘密鍵に基づいて黒鍵を生成するのですか?

いいえ、KEYコマンドではなくLOADコマンドを使用しています。
この場合、キーは48バイト(P384)です。

< https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-blac... > に記載されているとおりです。
「KEYコマンドは32バイトに制限されているようだ。だからロードを使うべきだ
* コマンドは最大64バイトまで読み込める。

KEYコマンドで48バイトのキーを使用すると、DECOエラーが報告されます。
ジョブリングステータス: 0x40000106、
DECO、06h - 無効なKEYコマンド

そこで、上記のパッチコードと同じLOADコマンドを使うようにコードを変更しました。

ありがとうございます。よろしくお願いいたします。

Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case

ECC P-384キーはKEYコマンドでPKHA-Eメモリにロードでき、その後ECDSA署名や検証に使用できることを検証しました。

KEYコマンドで「クラス1」レジスタを使用しているかどうか確認してください。MX8DXLのクラス1キーレジスタは32バイトです。ですので、代わりにPKHA-Eメモリをご利用ください。

参考までに、CAAM 記述子を以下に示します。平文の秘密鍵をブラックキーに変換するには、CAAM コマンドは「KEY」+「FIFO STORE」です。

b0800005

02010030 // キー

60220030 ....0....t.0."` // FIFO SOTRE

質問に対する回答をご確認ください。

CAAM COVER操作において、32バイトを超えるECC秘密鍵に対する既知の制限事項はありますか？

KEYコマンドはKEYレジスタへのデータロードに有効ですが、それぞれの最大サイズまでしかロードできません。したがって、クラス1キーレジスタ、クラス2キーレジスタ、PKHA EレジスタはすべてKEYコマンドでロード可能ですが、それぞれ異なるサイズを持ちます。一般的に、クラス2キーレジスタはクラス1キーレジスタよりも大きく(128バイト)、このプロセスでECCキー(1028バイトを超えない)の使用に代わることができます。より一般的には、KEYコマンドを使ってECCキーをPKHA Eに入れ、そこからブラックキーとして保存する方法もあります。

COVER経由で外部のP-384平文秘密鍵をインポートし、それをECDSAのブラックキーとして使うことはサポートされているユースケースでしょうか?

はい、ECDSAの署名業務では、署名にブラックキーを使用できます。

観測された動作は、CAAMハードウェアの制限によるものなのでしょうか？

はい。レジスタのサイズを超えてLOAD(またはSTORE)するとデッドスペースが発生し、デッドエリアへのLOADバイトは失われ、STOREバイトはゼロの値になります。MX8DXLのクラス1キーレジスタは32バイト(256ビット)で、AESのような対称暗号エンジンの鍵を処理するのに十分な大きさです。

外部生成されたP-384平文秘密鍵をインポートし、それをECDSA操作のブラックキーとして使う推奨されるCAAM方法はありますか?

はい。それをPKE（PKHA Eレジスタ）にロードし、クラス1キーの場合と同様にそこからFIFOストアを実行します（ただし、レジスタソースは別のものを使用します）。