ECDH shared secret derivation about incubator-teaclave-trustzone-sdk

[syedelec]

@DemesneGH

I noticed that the TEE_ALG_ECDH_P192, TEE_ALG_ECDH_P224 ... defines are deprecated and are being replaced as mentioned in the TEE API
Table B-2: Deprecated Algorithm Identifiers Page 327

They are all being replaced by TEE_ALG_ECDH_DERIVE_SHARED_SECRET

But it seems that OP-TEE did not update to comply with latest TEE Internal Core API Specification and OP-TEE is still using TEE_ALG_ECDH_P192, TEE_ALG_ECDH_P224 ...

[DemesneGH]

Hi @syedelec

In the TEE Internal GlobalPlatform API, it's specified if supported, is it related to the reason these are not supported?

Algorithms marked as If supported means they're not mandatorily implemented in TEE OSs. Those are optional features.

What would be the approximate effort to implement these algorithms in the Rust SDK?

In Rust SDK we just wrap the TEE crypto APIs which are implemented in the OP-TEE Core.

For example, I noticed that OP-TEE supports TEE_ALG_DH_DERIVE_SHARED_SECRET. To invoke this algorithm, we should allocate a TransientObject whose type is TEE_TYPE_ECDH_KEYPAIR. Allocation of an ECDH_KEYPAIR object is in TEE_Generatekey() which needs these arguments: TEE_ATTR_ECC_CURVE, TEE_ATTR_ECC_PUBLIC_VALUE_X, TEE_ATTR_ECC_PUBLIC_VALUE_Y and TEE_ATTR_ECC_PRIVATE_VALUE. (See the definitions in the GP Specification).

In Rust SDK we can populate and pass those values to TransientObject::generate_key() (which is the wrapper of TEE_Generatekey()).
Since OP-TEE supports TEE_ALG_DH_DERIVE_SHARED_SECRET, it is possible to invoke this algorithm in Rust but we've not tested for it. The function call is similar to the Diffie-Hellman example.

Do you plan on supporting these algorithms?

As mentioned above, there're just wrappers in Rust SDK and the algorithms are implemented in OP-TEE Core.
Since Rust SDK supports using third-party crates, the other way is using Ring which supports the ECDH key agreement and other algorithms. Reference: https://docs.rs/ring/latest/ring/agreement/index.html

[syedelec]

Algorithms marked as If supported means they're not mandatorily implemented in TEE OSs. Those are optional features.

Thanks I understood. These algorithms are implemented in TEE OS part.

For example, I noticed that OP-TEE supports TEE_ALG_DH_DERIVE_SHARED_SECRET. To invoke this algorithm, we should allocate a TransientObject whose type is TEE_TYPE_ECDH_KEYPAIR. Allocation of an ECDH_KEYPAIR object is in TEE_Generatekey() which needs these arguments: TEE_ATTR_ECC_CURVE, TEE_ATTR_ECC_PUBLIC_VALUE_X, TEE_ATTR_ECC_PUBLIC_VALUE_Y and TEE_ATTR_ECC_PRIVATE_VALUE. (See the definitions in the GP Specification).

Let me know if I am mistaken but the:
TEE_ALG_DH_DERIVE_SHARED_SECRET should ONLY work with DH_KEYPAIR
and
TEE_ALG_ECDH_DERIVE_SHARED_SECRET should ONLY work with ECDH_KEYPAIR

As you mentioned in the: Diffie-Hellman example, the DH_KEYPAIR is used instead of ECDH_KEYPAIR (which is supported)

In the Rust SDK, the TEE_ALG_ECDH_DERIVE_SHARED_SECRET 0x80000042 define is missing so we cannot derive shared secret using ECDH_KEYPAIR

[Same for the algorithms in my initial screenshots, TEE_ALG_ECDSA_SHAXXX are also missing in the Rust SDH so EC signatures are not available]

As mentioned above, there're just wrappers in Rust SDK and the algorithms are implemented in OP-TEE Core.
Since Rust SDK supports using third-party crates, the other way is using Ring which supports the ECDH key agreement and other algorithms. Reference: https://docs.rs/ring/latest/ring/agreement/index.html

Yes I am using also this crate but I just wanted to try the wrappers.

[DemesneGH]

Let me know if I am mistaken but the:
TEE_ALG_DH_DERIVE_SHARED_SECRET should ONLY work with DH_KEYPAIR
and
TEE_ALG_ECDH_DERIVE_SHARED_SECRET should ONLY work with ECDH_KEYPAIR

Sorry I copied the wrong text which should be TEE_ALG_ECDH_DERIVE_SHARED_SECRET instead of TEE_ALG_DH_DERIVE_SHARED_SECRET in the previous comment.

In the Rust SDK, the TEE_ALG_ECDH_DERIVE_SHARED_SECRET 0x80000042 define is missing

If this constant flag is needed, just add the definition in crypto_op.rs after this line of code:

incubator-teaclave-trustzone-sdk/optee-utee/src/crypto_op.rs

Line 1718 in 341b77a

DhDeriveSharedSecret = 0x80000032,

[DemesneGH]

In OP-TEE it uses TEE_ALG_ECDH_P192, TEE_ALG_ECDH_P224, etc. Not the TEE_ALG_ECDH_DERIVE_SHARED_SECRET:
https://github.com/OP-TEE/optee_test/blob/00b3f2cbf4ad959423f8f1abdef52a2f0280db1b/host/xtest/regression_4000_data.h#L6490-L6504

The function call example can be found at the xtest code:
https://github.com/OP-TEE/optee_test/blob/1cf0e6d2bdd1145370033d4e182634458528579d/host/xtest/regression_4000.c#L4793

[syedelec]

Sorry I copied the wrong text which should be TEE_ALG_ECDH_DERIVE_SHARED_SECRET instead of TEE_ALG_DH_DERIVE_SHARED_SECRET in the previous comment.

No worries, thanks!

If this constant flag is needed, just add the definition in crypto_op.rs after this line of code:

Thanks I will try to add the definitions for TEE_ALG_ECDH_DERIVE_SHARED_SECRET and also for the TEE_ALG_ECDSA_SHAXXX and verify that it works

In OP-TEE it uses TEE_ALG_ECDH_P192, TEE_ALG_ECDH_P224, etc. Not the TEE_ALG_ECDH_DERIVE_SHARED_SECRET:
https://github.com/OP-TEE/optee_test/blob/00b3f2cbf4ad959423f8f1abdef52a2f0280db1b/host/xtest/regression_4000_data.h#L6490-L6504
The function call example can be found at the xtest code:
https://github.com/OP-TEE/optee_test/blob/1cf0e6d2bdd1145370033d4e182634458528579d/host/xtest/regression_4000.c#L4793

I did not notice, thanks! I will keep testing.