Access Manager restrictions

[Riz]

Hey @Kan_Li ,

Hope you are doing well.

I wanted you to help me understand couple of things around access manager.

1. I have tired running multiple client requests (with Auth=None) at the same time with the access manager and each time I observe that the calculations/operations are done in a blocking manner.

Below is an image snippet from the document (access manager section) showing multiple client requests at the same time. I could observe that the interaction between the access manager and the secure element seems to be always blocking/synchronous in nature.

Could you help me know if this is the case always that the operations are blocking in nature. If true, then increase in number of requests AT SAME TIME, would increase the time taken. Right?

Also let me know if there is a way to enable asynchronous communication between the access manager and the Secure Element to improve the performance if at all it is possible?

Does having an auth based user sessions enable asynchronous communication? No?

2. In the documentation, under the "restrictions" in access manager section,  it says.

The SSS layer’s implementation of multistep symmetric ciphers does not allow concurrent execution of ciphers with the same cipher mode (e.g. twice kAlgorithm_SSS_AES_CBC).

What does this mean?
Does it mean if I run multiple sign operations at same time using say for example "kAlgorithm_SSS_ECDSA_SHA224" algo, then the concurrent execution would fail as I used same mode?

Looking forward for your response.

Thanks,
Riz

[michaelsalfer]

Hello Riz,

any access to the SE always is blocking until the SE has processed the command. The SE can always only process one command concurrently. The access manager only takes care that the SE only gets a new command sent when the previous one has finished the processing.

So when two requests are sent at the same time one of them needs to wait until the first one has finished processing. One request is always one APDU (command), one SSS call can create multiple APDUs. 

There is no asynchronous communication foreseen in the MW. An asynchronous implementation would also not improve the final application performance as anyway the application typically only can continue when the crypto calculation result is available.

The special issue with sss and multistep symmetric ciphers is that such a cipher requires the temporary creation of a "crypto object" which maintains the state of the cipher while the application sends in larger amounts of data in multiple steps using the Init/update/final mechanism. The library does not support parallel creation of crypto objects - typically these crypto objects needs a lot of volatile memory inside the SE and you would be quickly in a out of volatile memory situation if parallel crypto objects are created.

Kind regards,
Michael

[Riz]

Hi @michaelsalfer ,

Thank you for your response.

Does this "special issue with sss and multistep symmetric ciphers" is limited to only symmetric ciphers?

Please consider below:

I am trying to run sign operations using pkcs11-tool tool with SSS library in parallel.

I am running below two commands on my i.MX6 with SE in parallel.

pkcs11-tool --module /usr/lib/libsss_pkcs11.so --sign --id 88881000 -m SHA256-RSA-PKCS --slot 1 --input-file /tmp/data1 --output-file /tmp/data1.sig &
pkcs11-tool --module /usr/lib/libsss_pkcs11.so --sign --id 88881001 -m SHA256-RSA-PKCS --slot 1 --input-file /tmp/data2 --output-file /tmp/data2.sig

Note: Assume the data and keys are pre-generated.

I observe that most of the time this operation fails with below error and only somtimes passes.

error: PKCS11 function C_SignUpdate failed: rv = CKR_FUNCTION_NOT_SUPPORTED (0x54)

Could this be a timing issue?

Note: Same Image also attached if this screenshot is not clear

I did some trial and errors by running multiple asymmetric operations in parallel.
Following are my observations.

1. If same asymmetric operation is run in parallel, example RSA_SHA256 and RSA_SHA256, it runs into  above error most of the times. Rarely succeeds.

2. If different asymmetric operations are run in parallel (Example: RSA + ECDSA or RSA_SHA256 + RSA_SHA512), it passes most of the time. Sometimes fails.

Do you know why this might be the case?

Regards,
Riz

[Kan_Li]

Hi @Riz ,

For the case of RSA_SHA256 and RSA_SHA256, it is quite sure due to the digest collision , but for the second case such as RSA_SHA256 and RSA_SHA512, I could not reproduce it here, do you have log about it? This case works well from my side.

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

[Riz]

Hi @Kan_Li 

I am able to reproduce the issue with different SHA* scenario.

Please do the following.

1. Copy the attached shell scripts to your machine ( test.sh and rsa_sign.sh).

2. Make them executable chmod +x test.sh rsa_sign.sh

3. run ./test.sh

Note:
You would need to adapt the rsa_sign.sh accordingly.

Let me know your observations.

Regards,
Riz

[Kan_Li]

Hi @Riz ,

Thanks for the information! Just wondering how you created the id of id of 99991000 , would you please provide more details about it?

Thanks for your patience!

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

[Riz]

Hi @Kan_Li 

I used commands like below.

pkcs11-tool --module /usr/lib/libsss_pkcs11.so --keypairgen --key-type rsa:1024 --id '99991001'

Regards,
Riz

[Riz]

Hi,
Were you able to reproduce the issue at your end.

[Kan_Li]

Hi @Riz ,

Yes, I managed to get the script run on my board and I am investigating on it. I will let you know when I have any progress.

Thanks for your patience!

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

[Riz]

Hi @Kan_Li ,
Thank you for your response, I will try to get back to you with logs for the case 2.

You said "For the case of RSA_SHA256 and RSA_SHA256, it is quite sure due to the digest collision"

Do you mean this is an expected behavior or a bug?

As per my understanding this should have worked fine. or No?

"The SSS layer’s implementation of multistep symmetric ciphers does not allow concurrent execution of ciphers with the same cipher mode"

The restriction is only with multistep SYMMETRIC ciphers right?

Kindly clarify.

Regards,
Riz

[Kan_Li]

Hi @Riz ,

It is is an expected behavior with current implementation , but we are considering to modify it in the future.

For asymmetric ciphers typically the digest gets signed – so the sss function sss_asymmetric_sign_digest () gets used.

On PKCS11 the issue is that the PKCS11 function C_Sign creates the digest as well using sss functions which use the SE context – and not the host context. So the SE creates crypto objects to calculate the digest – which can collide as here typically the same crypto object numbers are used. In case different numbers would be used also the RAM can get too less.

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

[Riz]

Hi @Kan_Li ,

Gentle reminder to look into my above query.

Regards,
Riz

[Riz]

Hi @michaelsalfer , Hi @Kan_Li 

Could you please look into my above query.

Regards,
Riz

[Kan_Li]

Hi @Riz ,

We are still trying to reproduce the pkcs11 failure as you met but not succeeded yet, so it would be helpful if you may provide the complete logs from the client applications, by enabling the debug log option as shown below:

BTW, have you ever tried with an extended retry interval as mentioned below? I am not sure if it is your case, but just suspecting if one client's operation lasts too long to keep another wait.

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