Automated Detection of Instruction Cache Leaks in Modular Exponentiation Software

Abstract

The shared instruction cache of modern processors is an established side-channel that allows adversaries to observe the execution flow of other applications. This has been shown to be a threat to cryptographic software whose execution flow depends on the processed secrets. Testing implementations for these dependencies, or leaks, is essential to develop protected cryptographic software. In this work, we present an automated testing methodology that allows to detect execution flow leaks in implementations of modular exponentiation, a key operation in schemes like RSA, ElGamal, and Diffie-Hellman. We propose a simple and effective leakage test that captures problematic properties of vulnerable exponentiation algorithms. The execution flow of an implementation is directly monitored during exponentiation using a dynamic binary instrumentation framework. This allows to efficiently detect leaking code with instruction-level granularity in a noiseless and controlled environment. As a practical demonstration, we test multiple RSA implementations of modern cryptographic libraries with the proposed methodology. It reliably detects leaking code in vulnerable implementations and also identifies leaks in a protected implementation that are non-trivial to spot in a code review. We present a fix for these leaks and strongly recommend to also patch the other implementations. Because instruction cache attacks have been shown to be a threat in practice, it seems advisable to integrate an automated leakage test in the software release process of cryptographic libraries.

A Configuration of Cryptographic Libraries

Most of the cryptographic libraries configure themselves with automatic scripts that adapt the library to the current processor, which is an Intel Xeon E5440 in our tests. The paragraphs beneath discuss all manual configuration steps and also list the functions and source code files containing the exponentiation code. This is important to verify and reproduce our results, because libraries often feature multiple implementations of modular exponentiation and pick one depending on their configuration.

wolfSSL. On our x86-64 test system, wolfSSL automatically speeds up public key operations by defining the fastmath option. In addition, we define the flag TFM_TIMING_RESISTANT, because it is recommended in the documentation [29]. The exponentiation function _fp_exptmod is defined in wolfcrypt/src/tfm.c.

MatrixSSL. For MatrixSSL no extra configuration steps are done. The exponentiation function pstm_exptmod is implemented in crypto/math/pstm.c.

Nettle. This library offers two functions for RSA decryption, rsa_decrypt and rsa_decrypt_tr. We use the latter one, because it implements base blinding to mitigate timing attacks and is therefore recommended in practice. For the required random numbers, we use the included implementation of the Yarrow PRNG. By default Nettle calls the external GNU multi precision arithmetic library (GMP) [26] to perform exponentiation. In particular, it relies on the function mpn_powm in the source file mpn/generic/powm.c. We compile GMP in version 6.1.0 with default configuration and link it with decryption program.

mbed TLS. The mbed TLS library is compiled with the flag MBEDTLS_RSA_NO_CRT to enforce decryption without CRT components. Setting this flag does not affect the exponentiation code in function mbedtls_mpi_exp_mod defined in library/bignum.c. For the implemented base blinding countermeasure the CTR_DRBG random number generator is used.

Libgcrypt. The Libgcrypt library implements a secure memory feature that can be used for key storage. Because this is not required in our tests and does not change the exponentiation algorithm, we disable the feature during runtime. Exponentiation is done in function _gcry_mpi_powm, which is implemented in mpi/mpi-pow.c.

cryptlib. Before triggering the decryption in the cryptlib library, we set the CRYPT_RANDOM_SLOWPOLL and CRYPT_OPTION_MISC_SIDECHANNELPROTECTION options. A random slowpoll gathers entropy before the library actually needs it, which speeds up the retrieval of random numbers at a later point in time. The enabled side-channel protection activates a base blinding countermeasure, sanity checks in the code and the constant-time, fixed window exponentiation in function BN_mod_exp_mont_consttime, which is defined in bn/bn_exp.c.

OpenSSL and Forks. The OpenSSL library is compiled with the options OPENSSL_BN_ASM_MONT and OPENSSL_BN_ASM_MONT5, which activate assembly optimized Montgomery multiplication. By default, the base blinding countermeasure and the constant-time, fixed window exponentiation in function BN_mod_exp_mont_consttime defined in crypto/bn/bn_exp.c are enabled. The LibreSSL and BoringSSL libraries are compiled and used with the default options, which enable a similar exponentiation implementation as in OpenSSL. Sliding window exponentiation can be manually enabled in OpenSSL and LibreSSL by setting the RSA_FLAG_NO_CONSTTIME flag during runtime.