2411151_en-US

[#1]

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

Hi NXP team,

We are evaluating ECDSA P-384 black key/blob support on i.MX8DXL CAAM.

Observed results

P-256

Starting from an externally provided plaintext P-256 private key:

• Plaintext key → COVER → black key blob
• Restore black key from black blob
• ECDSA sign/verify

Result: PASS

P-384 (CAAM-generated black key)

• Generate ECDSA private key as KEY_COLOR_BLACK
• Generate black blob from private key without COVER operation
• Restore black key from black blob
• ECDSA sign/verify

Result: PASS

P-384 (external plaintext private key)

Starting from an externally provided plaintext P-384 private key (48 bytes):

• Plaintext key → COVER → black key blob
• Restore black key from black blob
• ECDSA sign/verify

Result: FAIL

Additional observation

We noticed the following comments in the NXP patch:

https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-blac...

/*

* KEY commands seems limited to 32 bytes, so we should use the load

* command instead which can load up to 64 bytes.

*

* TODO: The KEY command indicate it should be able to load key bigger

* than 32bytes but it doesn't work in practice

*

* TODO: The LOAD command indicate it should be able to load up to 96

* byte keys it doesn't work in practice and is limited to 64 bytes

*/

We observed similar behavior.

Using the LOAD command instead of the KEY command allows us to handle keys larger than 32 bytes, including a 48-byte P-384 private key.

However, this does not resolve the issue above. Although the key can be covered and stored in a blob, the restored black key cannot be used successfully for ECDSA sign/verify.

Our questions:

1. Is there any known limitation of the CAAM COVER operation for ECC private keys larger than 32 bytes?
2. Is importing an external P-384 plaintext private key through COVER and then using it as an ECDSA black key a supported use case?
3. Is the observed behavior expected due to a CAAM hardware limitation?
4. Is there a recommended CAAM method to import an externally generated P-384 plaintext private key and use it as a black key for ECDSA operations?

Any guidance would be appreciated.

Thanks and best regards,

hojames.

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

Additional note:

Our concern is not limited to the ECDSA use case.

Even if importing an external P-384 private key through COVER is not a supported ECDSA workflow, we would still like to understand the limitations of the COVER operation itself.

In our application, the COVER operation may also be used to protect general sensitive data, not only ECDSA private keys. Therefore, support for payload sizes larger than 32 bytes is an important consideration.

Based on our testing, using the LOAD-command workaround allows handling payloads larger than 32 bytes. Payloads below approximately 80 bytes appear to work, while larger sizes show inconsistent behavior. We would like to understand whether these observations reflect an actual CAAM limitation or an implementation issue.

Could NXP also clarify whether there are any documented size limitations for the COVER operation itself, independent of the ECDSA use case?

Thank you.

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

We need to set up the environment to test this CAAM function. We will update you once We have some results.

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

Hi yipingwang,

Thanks for the reply.

>>For this part, what CAAM error did you observed?
>>Could you provide the error code?

We are using below code patch for all ECDSA related operations:
"https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx..."

when calling caam_ecdsa_verify() for signature verification,
it returns 'ECDSA_VERIFY_FAIL (0)'.

The error occurs only with the case 'P-384 (external plaintext private key)'.

>> The application note "AN12838-Strengthening Public Key Cryptography using CAAM Secure Key" describe a demo for ECDSA signature using black key, are you testing with similar implementation?

For our succeed cases, yes, they are similar.
But for our failed case 'P-384 (external plaintext private key)',
it is a bit different: the key is from external.

Best regards,

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

"Plaintext key → COVER → black key blob
Restore black key from black blob
ECDSA sign/verify
Result: FAIL"

For this part, what CAAM error did you observed? Could you provide the error code? The application note "AN12838-Strengthening Public Key Cryptography using CAAM Secure Key" describe a demo for ECDSA signature using black key, are you testing with similar implementation? Thank you. 

For the KEY command limitation, it is still under investigation. 

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

For the failed case, are you using "KEY" command and "FIFO STORE" command to generate the black key based on the plaintext private key? Is it possible for you to dump the CAAM descriptors(the hex words) used in failure cases? It would be easier to check the commands and parameters. Thank you.

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

Hi yipingwang,

>>For the failed case,
>>are you using "KEY" command and "FIFO STORE" command
>>to generate the black key based on the plaintext private key?

No, we are using the LOAD command instead of the KEY command.
The key is 48 bytes (P384) in this case.

As mentioned in <https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-blac...>
"KEY commands seems limited to 32 bytes, so we should use the load
* command instead which can load up to 64 bytes.".

If use the KEY command for 48 bytes key, DECO error is reported:
job ring status: 0x40000106,
DECO, 06h - Invalid KEY Command

So we modifed the code to use LOAD command the same as the patch code above.

Thanks and best regards,

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

I have validated that an ECC P-384 key can be loaded to PKHA-E memory using the KEY command, and it can subsequently be used for ECDSA sign and verify. 

Please check if you are using the "Class 1" register in KEY command, the Class 1 Key register on MX8DXL is 32 bytes. So please use PKHA-E memory instead.

Here is the CAAM descriptor for your reference: Covert the plaintext private key to black key, the CAAM command is "KEY" + "FIFO STORE".

b0800005

02010030    // KEY

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

Please check the reply per the questions:

1. Is there any known limitation of the CAAM COVER operation for ECC private keys larger than 32 bytes?

The KEY command is effective at loading the KEY registers, but only to their respective max sizes.  So, the Class 1 Key register, the Class 2 Key register, and PKHA E register can all be loaded by the KEY command, but they will all have different sizes.  In general, the Class 2 Key Register is larger (128 bytes) than the Class 1 Key register, and could be substituted in this process for the use of ECC keys (which will not be larger than 1028 bytes).  More generally, you could always use the KEY command to put the ECC key into PKHA E and then store it from there as a black key.

1. Is importing an external P-384 plaintext private key through COVER and then using it as an ECDSA black key a supported use case?

Yes, the ECDSA Sign operation will accept a black key for signing.

1. Is the observed behavior expected due to a CAAM hardware limitation?

Yes.  If you LOAD (or STORE) beyond a register’s size, you will be dealing with dead space – so the LOAD bytes to the dead area are lost, and the STORE bytes will have a zero value.  The Class 1 Key register on MX8DXL is 32 bytes (256 bits),  big enough to handle a key for the available symmetric cipher engines, like AES.

1. Is there a recommended CAAM method to import an externally generated P-384 plaintext private key and use it as a black key for ECDSA operations?

Yes.  Load it into PKE (PKHA E register) and do the FIFO STORE from there like you would for a Class 1 Key (just use a different register source).