How to partially accelerate ECC

[gilles-peskine-arm]

TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer expose single-function replacement in the ECC code (MBEDTLS_ECP_INTERNAL_ALT and its sub-options) or the replacement of core ECC arithmetic (MBEDTLS_ECP_ALT). Vendors who have partial acceleration for some functions, but want to use the Mbed TLS code for the rest of the arithmetic, will have to copy the Mbed TLS code.

Is this a problem? Should TF-PSA-Crypto offer an ECC function replacement at a lower level than algorithms such as ECDH and ECDSA?

Mailing list thread: https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/74FARSYBRCF33UIREIQCC4G3EVHSR4HV/

[mschulz-at-hilscher]

To support our ECC hardware accelerator, we would like to call an alternative version of ecp_mul_comb if our accelerator can handle the group.

To achieve this, we currently edited the ecp_mul_restartable_internal function and require ecp_randomize_jac to be non-static. However, it would be nicer to have an interface to replace exactly that operation.

#if defined( MBEDTLS_ECP_INTERNAL_ALT ) && defined( MBEDTLS_ECP_WEIERSTRASS_MUL_ALT )
    if( mbedtls_ecp_get_type( grp ) == MBEDTLS_ECP_TYPE_SHORT_WEIERSTRASS )
    {
      if( ( is_grp_capable = mbedtls_internal_ecp_grp_capable( grp ) ) )
      {
        /* use hw accel */
        MBEDTLS_MPI_CHK(mbedtls_internal_ecp_mul( grp, R, m, P, f_rng, p_rng ));
      }
      else
      {
        /* use sw implementation */
        MBEDTLS_MPI_CHK(ecp_mul_comb( grp, R, m, P, f_rng, p_rng, rs_ctx ));
      }
    }
#else
    if (mbedtls_ecp_get_type(grp) == MBEDTLS_ECP_TYPE_SHORT_WEIERSTRASS) {
        MBEDTLS_MPI_CHK(ecp_mul_comb(grp, R, m, P, f_rng, p_rng, rs_ctx));
    }
#endif

[gilles-peskine-arm]

We are not going to keep the current ALT interfaces for function substitution. Instead, we are planning to have optional diversion points in the library, configured in the same way as accelerator drivers. For example, ecp_randomize_jac could have an optional dispatch to a driver. We haven't yet designed how these diversion points will look like, in particular their granularity and how data would be passed. I cannot promise that the design will be ready by the time of the release of TF-PSA-Crypto 1.0: it is likely that this work will appear gradually in 1.x versions.