Leaking control-flow (Frontal attack)

[raoulstrackx]

Description

• Type: Bug
• Priority: Minor

---

Bug

mbed TLS build:
Version: 2.16.6
OS version: SGX

---

Discoverers: Ivan Puddu, Moritz Schneider, Miro Haller, Srdjan Capkun, ETH Zurich (i.e., not me)
*Short description: The authors describe in their paper a way to determine control flow in SGX enclaves by precisely timing interrupt latency. This succeeds even in balanced branches such as:

if (secret == 'a') {
  var1 = 1 + var1;
  var2 = 1 + var2;
} else {
  var1 = 2 + var1;
  var2 = 2 + var2;
}

The root cause of this is that the front-end of the processor fetches instructions with a 16 byte well-aligned window. The time to resume an instruction will depend on its location within this fetch window (and thus its virtual address) and instructions near it.
Full description: https://arxiv.org/abs/2005.11516

Solution:

• Remove the secret dependent branch altogether

*Code locations that require fixes:

• mpi_montmul (bignum.c: 1924):

    if( mbedtls_mpi_cmp_abs( A, N ) >= 0 )
        mpi_sub_hlp( n, N->p, A->p );
    else
        /* prevent timing attacks */
        mpi_sub_hlp( n, A->p, T->p );

[gilles-peskine-arm]

Thanks for letting us know! We do consider secret-dependent branches in private-key operations to be bugs when they are not protected by blinding, which this one isn't. We'll fix this one as soon as possible.

[raoulstrackx]

Thanks!

[gilles-peskine-arm]

It turns out that the leak was originally analyzed by Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, and Hyesoon Kim, Georgia Institute of Technology; Marcus Peinado, Microsoft Research (cited in Puddu et al.). As far as I can tell, the Mbed TLS team was not aware of that 2017 paper until now.