OP-TEE queries

OP-TEE queries

[murali selvaraj]

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

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.

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

-> token
        Is token is a kind of virtual to hold different objects(keys, cert
and so on).
        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?
        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 )?
        How many tokens maximum support on each slot?

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

Thanks,
Murali.S

Re: OP-TEE queries

[Etienne CARRIERE - foss]

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