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-black-key-blob-feature.patch /* * 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: Is there any known limitation of the CAAM COVER operation for ECC private keys larger than 32 bytes? Is importing an external P-384 plaintext private key through COVER and then using it as an ECDSA black key a supported use case? Is the observed behavior expected due to a CAAM hardware limitation? 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-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch" 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-black-key-blob-feature.patch> "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,
View full article
