Analysis of Software Countermeasures for Whitebox Encryption

Whitebox cryptography aims to ensure the security of cryptographic algorithms in the whitebox model where the adversary has full access to the execution environment. To attain security in this setting is a challenging problem: Indeed, all published whitebox implementations of standard symmetric-key algorithms such as AES to date have been practically broken. However, as far as we know, no whitebox implementation in real-world products has suffered from a key recovery attack. This is due to the fact that commercial products deploy additional software protection mechanisms on top of the whitebox implementation. This makes practical attacks much less feasible in real-world applications. There are numerous software protection mechanisms which protect against standard whitebox attacks. One such technique is control flow obfuscation which randomizes the order of table lookups for each execution of the whitebox encryption module. Another technique is randomizing the locations of the various Look up tables (LUTs) in the memory address space. In this paper we investigate the effectiveness of these countermeasures against two attack paradigms. The first known as Differential Computational Analysis (DCA) attack was developed by Bos, Hubain, Michiels and Teuwen in CHES 2016. The attack passively collects software execution traces for several plaintext encryptions and uses the collected data to perform an analysis similar to the well known differential power attacks (DPA) to recover the secret key. Since the software execution traces contain time demarcated physical addresses of memory locations being read/written into, they essentially leak the values of the inputs to the various LUTs accessed during the whitebox encryption operation, which as it turns out leaks sufficient information to perform the power attack. We found that if in addition to control flow obfuscation, one were to randomize the locations of the LUTs in the memory, then it is very difficult to perform the DCA on the resultant system using such table inputs and extract the secret key in reasonable time. As an alternative, we investigate the version of the DCA attack which uses the outputs of the tables instead of the inputs to mount the power analysis attack. This modified DCA is able to extract the secret key from the flow obfuscated and location randomized versions of several whitebox binaries available in crypto literature. We develop another attack called the Zero Difference Enumeration (ZDE) attack. The attack records software traces for several pairs of strategically selected plaintexts and performs a simple statistical test on the effective difference of the traces to extract the secret key. We show that ZDE is able to recover the keys of whitebox systems. Finally we propose a new countermeasure for protecting whitebox binaries based on insertion of random delays which aims to make both the ZDE and DCA attackspractically difficult by adding random noise in the information leaked to the attacker

The Fact-Finding Security Examination in NFC-enabled Mobile Payment System

Contactless payments devised for NFC technology are gaining popularity. Howbeit, with NFC technology permeating concerns about arising security threats and risks to lessen mobile payments is vital. The security analysis of NFC-enabled mobile payment system is precariously imperative due to its widespread ratification. In mobile payments security is a prevalent concern by virtue of the financial value at stave. This paper assays the security of NFC based mobile payment system. It discusses the security requirements, threats and attacks that could occur in mobile payment system and the countermeasures to be taken to secure pursuance suitability

Chicken or the Egg - Computational Data Attacks or Physical Attacks

Side-channel and fault injection analyses are well-known domains that have been used for years to evaluate the resistance of hardware based products. These techniques remain a threat for the secret assets embedded in products like smart cards or System On Chip. But most of these products contain nowadays several strong protections rendering side-channel and fault attacks difficult or inefficient. For two decades embedded cryptography for payment, pay tv, identity areas have relied a lot on secure elements. Nowadays more alternative solutions on mobile phones appear with the aim to offer software-based security services including payment and security solutions as the HCE and DRM products. Cryptographic operations running in such applications are then executed most often on unprotected hardware devices. Therefore the binary code is often accessible to attackers who can use static and dynamic reverse engineering techniques to extract and analyse operations including data modification as faults. Hence, hiding or obfuscating secrets and/or whitebox cryptography becomes a strong alternatives to secure element storage for assets. We explain in this paper how directly from the binary or with the extracted source code we can perform statistical and fault analyses using similar techniques as those used in hardware-based security. This concerns particularly side-channel or fault injections techniques. Using our tool and virtualization technique, an attacker can emulate and trace and modify any chosen computational data (memory or register manipulation, any machine language operation) executed in the mobile application. It means the attacker is not no longer restricted by any physical limitations imposing a leakage model (and additional noise) or making fault injection tied with physical limitations. Hence statistical and fault attacks can go potentially further in software-based implementation compared to hardware based devices. As a consequence, complex techniques like high order, collision and horizontal statistical attacks become very efficient and can be easily performed on the computational data execution traces. A similar consequence applies for fault injection attacks. Hence the word statistical and fault analysis on computational data becomes more appropriate and one can wonder who has been the first between computational data or physical attack techniques? Chicken or the Egg

Measuring Performances of a White-Box Approach in the IoT Context

The internet of things (IoT) refers to all the smart objects that are connected to other objects, devices or servers and that are able to collect and share data, in order to "learn" and improve their functionalities. Smart objects suffer from lack of memory and computational power, since they are usually lightweight. Moreover, their security is weakened by the fact that smart objects can be placed in unprotected environments, where adversaries are able to play with the symmetric-key algorithm used and the device on which the cryptographic operations are executed. In this paper, we focus on a family of white-box symmetric ciphers substitution-permutation network (SPN)box, extending and improving our previous paper on the topic presented at WIDECOM2019. We highlight the importance of white-box cryptography in the IoT context, but also the need to have a fast black-box implementation (server-side) of the cipher. We show that, modifying an internal layer of SPNbox, we are able to increase the key length and to improve the performance of the implementation. We measure these improvements (a) on 32/64-bit architectures and (b) in the IoT context by encrypting/decrypting 10,000 payloads of lightweight messaging protocol Message Queuing Telemetry Transport (MQTT)

Towards Fully Automated Analysis of Whiteboxes: Perfect Dimensionality Reduction for Perfect Leakage

Differential computation analysis (DCA) is a technique recently introduced by Bos et al. and Sanfelix et al. for key recovery from whitebox implementations of symmetric ciphers. It consists in applying the differential power analysis approach to software execution traces that are obtained by tracing the memory accesses of a whitebox application. While being very effective, DCA relies on analyst intuition to be efficient. In particular, memory range selection is needed to prevent software execution traces from becoming prohibitively long. Moreover, analyst failure to specify the relevant range lets the vulnerable whitebox implementation be evaluated as secure. We present a novel approach for dimensionality reduction of software execution traces, that takes a significant part of analyst intuition out of the loop. The approach exploits the lack of measurement noise in the traces and selects only the samples that are relevant for the key recovery. Our experiments with the published whitebox implementations show that the length of software execution traces can be automatically reduced to a few dozens of bits. This results in an attack speedup of several orders of magnitude, which in turn facilitates the use of more computationally intensive DCA flavours such as multiple leakage targets proposed by Klemsa. Our approach simplifies the methodology for whitebox analysis down to the tracing of a large default memory range, letting our dimensionality reduction techniques extract the relevant points for DCA, and run the attack on multiple leakage targets, excluding analyst errors and saving analysis time. It also provides quick insights in case of whitebox implementations with additional protection layers such as encodings, and can be used to identify the range for fault injection in differential fault analysis. We make our techniques available to the community as a part of a free/libre open-source side channel analysis toolkit. We believe they are a step forward for fully automated whitebox analysis tools

Formal Analysis of CRT-RSA Vigilant's Countermeasure Against the BellCoRe Attack: A Pledge for Formal Methods in the Field of Implementation Security

In our paper at PROOFS 2013, we formally studied a few known countermeasures to protect CRT-RSA against the BellCoRe fault injection attack. However, we left Vigilant's countermeasure and its alleged repaired version by Coron et al. as future work, because the arithmetical framework of our tool was not sufficiently powerful. In this paper we bridge this gap and then use the same methodology to formally study both versions of the countermeasure. We obtain surprising results, which we believe demonstrate the importance of formal analysis in the field of implementation security. Indeed, the original version of Vigilant's countermeasure is actually broken, but not as much as Coron et al. thought it was. As a consequence, the repaired version they proposed can be simplified. It can actually be simplified even further as two of the nine modular verifications happen to be unnecessary. Fortunately, we could formally prove the simplified repaired version to be resistant to the BellCoRe attack, which was considered a "challenging issue" by the authors of the countermeasure themselves.Comment: arXiv admin note: substantial text overlap with arXiv:1401.817