RFC: Extend Secure Sockets with engine support

[drandreas]

Introduction

Zephyr implements the concept of Secure Sockets. Those ease the integration of TLS and DTLS into arbitrary applications. However, the secure sockets hide the underlaying crypto library. Moreover, the current code lacks support for opaque private keys and engine callbacks.

The secure socket API should be extended with an API that allows replacing any of the asymmetric functions on a per context basis.

Problem description

mbedTLS has support for alternative crypto implementations and limited (RSA: yes, ECP: no) support of opaque keys. However, Zephyr’s code that setups the pk context is very rigid and cannot cope with situations where TLS_CREDENTIAL_PRIVATE_KEY is not set.

Proposed change

Add support for adding opaque private keys with TLS_CREDENTIAL_PRIVATE_KEY_BLOB in addition to the existing TLS_CREDENTIAL_PRIVATE_KEY and allow for the definition of alternative cryptographic functions.

Detailed RFC

Proposed change (Detailed)

The Secure Socket subsystem runs to the best of my knowledge in kernel space. The proposed change therefore needs to take privilege separation into account. User space should not be able to set functions that are executed in kernel mode.

mbedTLS features mbedtls_pk_setup_rsa_alt which allows the definition of mbedtls_pk_rsa_alt_decrypt_func, mbedtls_pk_rsa_alt_sign_func and mbedtls_pk_rsa_alt_key_len_func. Those could be exposed to the developer to be defined at compile time. Additionally, tls_set_own_cert could be extended to detect opaque keys and call mbedtls_pk_setup_rsa_alt instead of mbedtls_pk_setup with the above alt function pointers. Finaly Zephyr should provide a macro/function that allows for a type safe recovery of the KEY_BLOB within the alt-functions from void *ctx. Blow the function typedefs:

typedef int (*mbedtls_pk_rsa_alt_decrypt_func)
  (void *ctx, int mode, size_t *olen, const unsigned char *input,
   unsigned char *output, size_t output_max_len );

typedef int (*mbedtls_pk_rsa_alt_sign_func)
  (void *ctx, int (*f_rng)(void *, unsigned char *, size_t), void *p_rng, 
   int mode, mbedtls_md_type_t md_alg, unsigned int hashlen,
   const unsigned char *hash, unsigned char *sig );

typedef size_t (*mbedtls_pk_rsa_alt_key_len_func)
  (void *ctx );

Dependencies

The proposed change addresses RSA only. The three alt functions described above are not yet available for ecp. We would need to create a PR in the mbedTLS project to upstream mbedtls_pk_setup_ecp_alt.

Concerns and Unresolved Questions

Depending on the application an engine might need to communicate with a UI to request a password. The current RFC only addresses one-way data transfers.

Alternatives

I've created a Proof of Concept for using a Trusted Platform Modules (TPM2) as secure storage of private keys. The PoC defines MBEDTLS_ECDSA_SIGN_ALT to catch all sign-requests and forward them to the TPM2. However MBEDTLS_ECDSA_SIGN_ALT was designed with crypto accelerators in mind and does not offer a context, see the function prototype below:

int mbedtls_ecdsa_sign(mbedtls_ecp_group *grp,
                       mbedtls_mpi *r, mbedtls_mpi *s,
                       const mbedtls_mpi *d,
                       const unsigned char *buf,
                       size_t blen,
                       int (*f_rng)(void *, unsigned char *, size_t),
                       void *p_rng)

Therefore I had to pass KEY_BLOB on a side channel. I chose a global variable. Moreover since MBEDTLS_ECDSA_SIGN_ALT lacks the context, this approach only works for a single key per algorithm (1x RSA, 1xECP).

[jukkar]

This looks more like a security enhancement than network one to me. cc: @d3zd3z @ceolin

[d3zd3z]

I think this is a good start. Opaque keys will be important when wanting to store keys in a secure environment such as TF-M/PSA.

[tpennors]

Hello, Any news on this feature which could really enhance security ? Would be interested!

[d3zd3z]

At this point, we are waiting for some more progress in how this is done within TF-M. It works when chosen at build time, and there was additional information added to the keys, but it isn't yet possible to have keys that live in different places from how the system was configured.