SE05x Middleware 04.05.00: pkcs#11 wrong behavior with key labels

[msalvinik]

Hi all,

we are using an SE050A chip on an i.MX8MN with middleware 04.05.00.
Middleware is built by ourselves with these Cmake settings:

-DCMAKE_BUILD_TYPE=Release \
-DPTMW_Host=iMXLinux \
-DPTMW_SMCOM=T1oI2C \
-DPTMW_SE05X_Auth=None \
-DPTMW_Applet=SE05X_A \
-DWithSharedLIB=ON \
-DPTMW_SE05X_Ver=03_XX \
-DPTMW_RTOS=Default \
-DSSS_HAVE_HOSTCRYPTO_MBEDTLS=ON \
-DPAHO_BUILD_STATIC=FALSE \
-DPAHO_BUILD_SHARED=TRUE \

We have some troubles using it with opensc (pkcs11-tool).

The problem is that when we have two or more public keys on the SE050, the signature verification fails. If there is only one key, the verification works properly.

Please find the attached example for all the details. Steps to reproduce are simple and are contained in section 1 of the attachment (full commands and output):

1. create a EC key pair with OpenSSL (key1)

2. sign a file with OpenSSL using private key1

2. connect to SE050, reset it and load the public key1 with label 0xaabbccdd

3. verify the signature with pkcs#11 using key label 0xaabbccdd (key1): it works

4. generate another EC key pair with OpenSSL (key2)

5. connect to SE050 and load the public key2 with label 0x01020304

6. verify again the signature with pkcs#11 using key label 0xaabbccdd (key1): it fails

7. connect to SE050 and delete the key with label 0x01020304 (key2)

8. re-do the verification of the signature with pkcs#11 using key label 0xaabbccdd (key1): it works

Section 2 of the attachment contains the same steps but using a different label (0xccddeeff) for key2. With this label, key 2 is listed after key 1 (instead of before) in the objects list: the problem stills to happen.

Section 3 of the attachment contains another test: with only one key loaded, try to verify the signature using a non-existent label: unexpectedly, it works

Seems that the pkcs11 library completely ignores the label, making the library itself completely useless when there are two or more keys.

Is this a known bug? Are there programmed fixes for this bug?

Thanks in advance.

Mauro

[Kan_Li]

Hi @msalvinik ,

I think we should use "-DPTMW_HostCrypto=MBEDTLS" instead of "-DSSS_HAVE_HOSTCRYPTO_MBEDTLS=ON" for MW ver 4.5.0. Please kindly refer to the following for details.

Please kindly let me know if the problem is still there.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[msalvinik]

Hi @Kan_Li ,

thank you for your answer.

Unfortunately I have the same problem also building with "-DPTMW_HostCrypto=MBEDTLS" instead of "-DSSS_HAVE_HOSTCRYPTO_MBEDTLS=ON"

By the way, I would suggest to fix the section "8.8.4. Building on Linux/Raspberry Pi3" of the documentation, where is stated that the flag to use is "SSS_HAVE_HOSTCRYPTO_MBEDTLS=ON" (I taken this flag from there)

[Kan_Li]

Hi @msalvinik ,

As a quick solution, please use "--id" instead of "--label" . Please kindly refer to the following for more details.

In this case, the unique identifier of the secure object is 0xaabbccdd and the related ID in pkcs11 is ddccbbaa.

Hope that helps,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[msalvinik]

Hi @Kan_Li ,

thank you for your feedback.

I confirm that your workaround works: with --id (and the reversed key ID) I'm able to select the right key when there are more than one key stored on SE050.

I would like to report another issue: on some conditions, when the signature verification fails the pkcs11-tool returns 0 instead of an error code.
In detail, it happens for example when I pass an invalid signature to check: the verification process fails with log

PKCS11:ERROR: sss_asymmetric_verify_digest Failed...
Invalid signature

but pkcs11-tool returns 0.

Instead, if I use an invalid key ID, the verification process fails with log

error: Public key nor certificate not found
Aborting.

and pkcs11-tool returns 1 (error code).

Don't know if the bug is in libsss_pkcs11.so or in pkcs11-tool.

Thanks in advance, regards

[Kan_Li]

Hi @msalvinik ,

It is a pkcs11-tool behavior as shown below:

When using an invalid Key ID , the pkcs11-tool will return 1 by calling util_fatal(). 

While doing the verify , the API always returns void even when the operation fails.

Only an error message printed in such cases.

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[msalvinik]

Hi @Kan_Li ,

thank you for your explanation.

Regards

Mauro

[rodolfoveltrigo]

@msalvinik Ciao Mauro,

first of all I would like to know if this problem is happening with the latest version of the P&T MW of December 2023.

EdgeLock SE05x Plug & Trust Middleware (04.05.00)

Rev 04.05.00 Dec 20, 2023 

Please confirm, so that i report this PKSC#11 problem to MW team.

cheers

Rodolfo

[msalvinik]

Ciao Rodolfo,

yes, the version we are using is 04.05.00, as stated in the issue title.

Thank you

Mauro