Export of public EC key fails with PKCS#11 back-end on NXP Layerscape

[paulhowardarm]

Summary

If you create an elliptic curve key and try to export the public part, you get an error when using the PKCS#11 back-end with the secure objects library in the NXP Layerscape platform. The same operation works correctly on other PKCS#11 systems, so this might be a spec compliance issue in the Layerscape stack.

Affected Versions

Parsec service 1.0.0

Repro

Requires suitable NXP Layerscape device such as LS1046a, imaged with LSDK firmware and userland including OPTEE, libsecure_obj and libpkcs11 components.

1. Configure Parsec with PKCS#11 back-end with the library_path parameter set to /usr/local/lib/libpkcs11.so and slot_number set to 0. (user_pin is not required and can remain commented out). Also set software_public_operations to true.
2. Disable any other provider back-ends (eg. Mbed, TPM) by commenting them out.
3. Start Parsec service. Service should start successfully.
4. Build or install the parsec-tool (version 0.5.2 is suitable)
5. Run the parsec-tool list-providers command to ensure that only the core provider and the PKCS#11 provider are active in the service. This is important, otherwise the following commands may use the wrong provider and fail to show the issue or confirm the fix.
6. Create a default ECC key with parsec-tool create-ecc-key --key-name ecctest1
7. Attempt to export the public key with parsec-tool export-public-key --key-name ecctest1
8. Expected: public key is written to the console as a PEM object
9. Observed: an error message of type PsaErrorGenericError is displayed and the key is not written

Root Cause

Under investigation, but seems likely that this is a spec compliance issue in the LSDK libpkcs11.so component. The Parsec PKCS#11 provider expects the public key to be contained within the PKCS#11 CKA_EC_POINT attribute, and that it will be encoded as an ASN.1 octet string. This is correct, because it is what the PKCS#11 spec mandates. However, it seems that some implementations do not work this way, and they just return the raw data without wrapping it in the ASN.1 octet string. Parsec cannot cope with this, which may be the cause of the error.

Suggested Fix

If the above RCA is confirmed, then the correct fix would probably be for the LSDK to comply with the spec, in which case no changes would be required in Parsec. However, it may be more expedient to make Parsec more lenient to work around this issue, because research suggests that this is not the only PKCS#11 library that suffers from the problem. A similar situation was encountered here in OpenSC, and they decided to work around it. Fixing Parsec will improve its ability to interoperate both with LSDK and also other non-compliant implementations.

[paulhowardarm]

For reference, sources for the libpkcs11 component in LSDK are maintained here: https://source.codeaurora.org/external/qoriq/qoriq-components/libpkcs11/

[paulhowardarm]

I can confirm that the key exports correctly (and provides the right data) if the ASN.1 wrapper parsing is skipped and the raw data used instead. I can prepare a PR for this.