Re: OP-TEE queries

[Etienne CARRIERE - foss <etienne.carriere@foss.st.com>]

[-- Attachment #1: Type: text/plain, Size: 5503 bytes --]

Hello Murali,


> From: murali selvaraj <muraliselvaraj2020@gmail.com>
> On Tuesday, December 3, 2024, murali selvaraj wrote:
> 
> Hi All,
> 
> We are currently working on standard PKCS#11 TA and I'm new to this topic
> (PKCS11, OP-TEE,TA).
> 
> Please go through and share your inputs on the following queries.
> 

As an overall comment, note that PKCS#11 is only an API specification: each package/device that implements PKCS#11 services also implements its own Pkcs#11 library (a.k.a Cryptoki library).

OP-TEE pkcs11 TA also provides its Linux userland library (libckteec from OP-TEE Client [1]) to allow Linux OS application to access PKCS#11 service embedded in OP-TEE (assuming the pkcs11 TA is also embedded in the system).

On a device/platform, you could have multiple PKCS#11 "devices" (let's say "tokens" to use the PKCS#11 wording).
For example, you could have the OP-TEE pkcs11 TA, the SoftHSM package (implements  a PKCS#11 token as a Linux OS userland application [2]), some physical external HSM devices connected through an hardware bus link (I2C, SPI, ...). A client application can communicate with each of these "PKCS#11 tokens" using the same API functions, but that application needs to link with the library dedicated to that token: e.g. libckteec (OP-TEE Client) for the OP-TEE TA, libsofthsm2.so (provided by SoftHSM package) for the SoftHSM token, a dedicated libXXXXX.so for a harware specific HSM.

Package p11-kit [3] claims to centralize several PKCS#11 libraries interface into a single. Maybe have a look at it. I've never used it so I can't really tell.

I can have a look at PKCS#11 v2.40 User Guide document [4]. This user guide may be deprecated (not part of latest PKCS#11 v3.0 specs) but it gives a nice overview IMHO.

[1] https://github.com/OP-TEE/optee_client
[2] https://github.com/softhsm/SoftHSMv2
[3] https://github.com/p11-glue/p11-kit
[4] https://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.html

> -> slot
>         How do we know how many slots are supported in my device?
>         Is it based on the physical interface of the device or how do we
> find the list of available slots without pkcs11-tool?
>         Please share the details with an example.

To discover slot, you can use connect a slot, you can use API function C_GetSlotList(), C_GetSlotInfo(). But you will discover only the slots visible to the Cryptoki library you link to.
Once slots are discovered, using C_GetTokenInfo() on slots with a present token allows to find your target token based on its token label, model, serial number, ... But again, such a call sees only the token visible to the Cryptoki library you link to.
pkcs11-tool uses these API function. Note that it request you to specify (with argument "--module" or a likewise method) the Cryptoki library to link to.

>
> -> token
>         Is token is a kind of virtual to hold different objects(keys, cert
> and so on).

A token is (or pretends to be) an isolated entity that can store some secrets and allow clients to manipulate them.
A hardware HSM is likely a physical token.
OP-TEE pkcs11 TA can implement 1 or more tokens (see CFG_PKCS11_TA_TOKEN_COUNT) that are isolated by software means by the pkcs11 TA implementation but that physically reside in the very same pkcs11 TA address space and execution context.

>         Can one token have private, public, leaf cert, intermediate ca
> cert, root ca cart and so on or any limitations on the number of objects in
> a token?

Limitation of a token depends on the token implementation, being software or
hardware.


>         Can we have each token be specific to the object ( for example ,
> token1 will have cert, token 2 will have key, token 3 will have seed/client
> cert )?

Yes. Note however that object in a token are not visible from another token.

>         How many tokens maximum support on each slot?

From the PKCS#11 spec:
"Slot       A logical reader that potentially contains a token."
"Token       The logical view of a cryptographic device defined by Cryptoki."
Therefore there is at most 1 token per slot. For each slot either the token is present or it is absent (e.g. for pluggable or loadable tokens).

> 
> ->    As part of pkcs11-tool, we have been using SO-PIN, user PIN,
> token/label name which are more specific to security.
>        If the normal world/REE is compromised, any sensitive data it holds,
> including PINs and tokens, could be exposed.
>        Do we have any access control mechanism to avoid this security issue
> ( in PKCS11 TA, OP-TEE context).

OP-TEE pkcs11 TA currently implements 2 authentication methods.

- PIN based: client must provide the PIN value to login into the token. Failing the login with the right PIN increments a failure counter that can lock the token.

- Linux ACL based: client must have the right user-id or group-id to login into the token.
  See https://github.com/OP-TEE/optee_os/pull/7040#issuecomment-2370897395

There is a proposal for an variant of the PIN based login method. See https://github.com/OP-TEE/optee_os/pull/7040.
It proposes to use the PIN based implementation but with large PIN byte strings and removing the PIN locking mechanism.
The P-R has not been merge, it needs to mature IMO but is really interesting. I think it needs some kind of time based delay between login attempts.

In the hope this helps,
Best regards,
Etienne

> 
> Thanks,
> Murali.S
>