In cryptography when we talk about hardening a library, we mean enabling resistance to timing attacks and cache attacks, using RSA blinding and protecting against glitching.
Enabling and Disabling
Our code has many related macros which can be controlled via configure script flags such as the harden flag and maxstrength flag. When hardening is enabled, the following flags are defined:
TFM_TIMING_RESISTANT ECC_TIMING_RESISTANT WC_RSA_BLINDING
When it is disabled, the following flags are defined:
WC_NO_HARDEN WC_NO_CACHE_RESISTANT
NOTE: hardening is enabled by default and in most cases should NOT be disabled. Later in this post, we will discuss some guidance on this matter.
The “maxstrength” flag is disabled by default because it only allows AEAD-PFS (Authenticated Encryption with Associated Data - Perfect Forward Secrecy) cipher suites which can cause interoperability issues. However, when it is enabled, it defines WOLFSSL_CIPHER_TEXT_CHECK, which protects against glitching attacks. If you want other cipher suites to be available, but also want glitching protection for the relevant ciphersuites, you can add -DWOLFSSL_CIPHER_TEXT_CHECK to your CFLAGS environment variable.
Timing Attack
This requires the adversary to precisely time the logical operations performed by a CPU or other device. By measuring these times the adversary is able to uncover the private data that was used to perform these operations. These kinds of attacks are even practical against well known, generally secure algorithms including RSA and ECC. Such attacks are thwarted by making cryptographic operations run in a constant amount of time independent of the private key. More information on timing attacks can be found at: https://en.wikipedia.org/wiki/Timing_attack
Cache Attack
Modern processors perform speculative execution and can leave observable side effects due to execution of branches not taken. This can be in the form of memory access patterns which can be seen in the state of the memory cache. These patterns can indicate information about the private key. The adversary would use nefarious means to make a program access arbitrary locations in the program's memory space to get these patterns. This attack can be mitigated by eliminating branching in cryptographic operations involving the private key.
RSA Blinding
This involves transforming the input just before the RSA private key operations using some random data. After the operation, the reverse of the transform is performed giving the desired output. This prevents an adversary from gaining knowledge about the private key as they don't know the random data that was used to determine the transform and therefore do not know the true input into the RSA private key operation.
Glitching
Glitching is when the adversary can feed in modified input data into an algorithm and then observe the error behavior to deduce information about the private key. This requires the adversary to have physical access and intimate knowledge of the software and hardware. They would modify the input into the algorithm by physically changing the values of the input in physical memory. This attack can be detected by copying the input to a separate buffer before a cryptographic operation and comparing the input buffer with that separate buffer after the cryptographic operation to ensure it has not changed.
Disabling Hardening
Generally speaking, you should always leave the “harden” flag enabled, however disabling it can give some performance gains. Here are some factors to consider whether it is appropriate to disable it:
- Are you only dealing with public data and public keys?
- Do you really need the performance gains?
- Are you only doing off-line operations where cryptographic operation timings cannot be observed?
- Are restrictions in place to ensure no physical access to the hardware?
- Do you have very simple and audited application code and operating system to minimize nefarious code execution?
- Did you minimize external interaction (ie network, user interface) to prevent nefarious inputs?
- Do you sanity check all input data?
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
