OpenSSL Implementation Research Articles

Designing a New XTS-AES Parallel Optimization Implementation Technique for Fast File Encryption

XTS-AES is a disk encryption mode of operation that uses the block cipher AES. Several studies have been conducted to improve the encryption speed using XTS-AES according to the increasing disk size. Among them, there are researches on parallel encryption of XTS-AES using GPU. Although these studies focus on parallel encryption of AES, optimization for the entire XTS mode has not been performed. The reason is that the <inline-formula> <tex-math notation="LaTeX">$\alpha ^{j}$ </tex-math></inline-formula> computation process included in XTS mode is not suitable for parallel operation. Therefore, in this paper, we proposed several techniques for high-speed encryption in GPU by modifying XTS-AES into a form that is advantageous for parallel operation. The core idea is to pre-calculate the <inline-formula> <tex-math notation="LaTeX">$\alpha ^{j}$ </tex-math></inline-formula> calculation on the CPU into a form that is easy to operate on the GPU. To achieve this goal, we analyzed the <inline-formula> <tex-math notation="LaTeX">$\alpha ^{j}$ </tex-math></inline-formula> calculation process and present the parts that can be optimized. First, we presented a method that can replace multiple operations with a single table reference through the analyzed <inline-formula> <tex-math notation="LaTeX">$\alpha ^{j}$ </tex-math></inline-formula> computation progress. Thereafter, we proposed a method that can be calculated by partially skipping the entire <inline-formula> <tex-math notation="LaTeX">$\alpha ^{j}$ </tex-math></inline-formula> computation process that must be sequentially calculated through the table reference technique. For the proposed optimization implementation, we presented various results for evaluating the optimal implementation. In addition, we compared the performance of XTS-AES OpenSSL implementation on CPU and our proposed optimization implementation on GPU.

RASSLE: Return Address Stack based Side-channel LEakage

Microarchitectural attacks on computing systems often stem from simple artefacts in the underlying architecture. In this paper, we focus on the Return Address Stack (RAS), a small hardware stack present in modern processors to reduce the branch miss penalty by storing the return addresses of each function call. The RAS is useful to handle specifically the branch predictions for the RET instructions which are not accurately predicted by the typical branch prediction units. In particular, we envisage a spy process who crafts an overflow condition in the RAS by filling it with arbitrary return addresses, and wrestles with a concurrent process to establish a timing side channel between them. We call this attack principle, RASSLE 1 (Return Address Stack based Side-channel Leakage), which an adversary can launch on modern processors by first reverse engineering the RAS using a generic methodology exploiting the established timing channel. Subsequently, we show three concrete attack scenarios: i) How a spy can establish a covert channel with another co-residing process? ii) How RASSLE can be utilized to determine the secret key of the P-384 curves in OpenSSL (v1.1.1 library)? iii) How an Elliptic Curve Digital Signature Algorithm (ECDSA) secret key on P-256 curve of OpenSSL can be revealed using Lattice Attack on partially leaked nonces with the aid of RASSLE? In this attack, we show that the OpenSSL implementation of scalar multiplication on this curve has varying number of add-and-sub function calls, which depends on the secret scalar bits. We demonstrate through several experiments that the number of add-and-sub function calls can be used to template the secret bit, which can be picked up by the spy using the principles of RASSLE. Finally, we demonstrate a full end-to-end attack on OpenSSL ECDSA using curve parameters of curve P-256. In this part of our experiments with RASSLE, we abuse the deadline scheduler policy to attain perfect synchronization between the spy and victim, without any aid of induced synchronization from the victim code. This synchronization and timing leakage through RASSLE is sufficient to retrieve the Most Significant Bits (MSB) of the ephemeral nonces used while signature generation, from which we subsequently retrieve the secret signing key of the sender applying the Hidden Number Problem.&#x0D; 1RASSLE is a non-standard spelling for wrestle.

API Misuse Detection in C Programs: Practice on SSL APIs

Libraries offer reusable functionality through Application Programming Interfaces (APIs) with usage constraints such as call conditions or orders. Constraint violations, i.e. API misuses, commonly lead to bugs and security issues. Although researchers have developed various API misuse detectors in the past few decades, recent studies show that API misuse is prevalent in real-world projects, especially for secure socket layer (SSL) certificate validation, which is completely broken in many security-critical applications and libraries. In this paper, we introduce SSLDoc to effectively detect API misuse bugs, specifically for SSL API libraries. The key insight behind SSLDoc is a constraint-directed static analysis technique powered by a domain-specific language (DSL) for specifying API usage constraints. Through studying real-world API misuse bugs, we propose ISpec DSL, which covers majority types of API usage constraints and enables simple but precise specification. Furthermore, we design and implement SSLDoc to automatically parse ISpec into checking targets and employ a static analysis engine to identify potential API misuses and prune false positives with rich semantics. We have instantiated SSLDoc for OpenSSL APIs and applied it to large-scale open-source programs. SSLDoc found 45 previously unknown security-sensitive bugs in OpenSSL implementation and applications in Ubuntu. Up to now, 35 have been confirmed by the corresponding development communities and 27 have been fixed in master branch.

Exhaustive single bit fault analysis. A use case against Mbedtls and OpenSSL’s protection on ARM and Intel CPU

Faults in software implementations target both data and instructions at different locations. Bellcore attack is a well-known fault attack that is able to break CRT-RSA. In response, cryptographic libraries such as OpenSSL are designed with protection. In this paper, new faults locations are shown on OpenSSL implementation of the CRT-RSA signature running on Intel and ARM processors. Among those faults, one restores the Bellcore attack on the OpenSSL library despite a protection and another is a complete new fault that exploits the OpenSSL protection to get RSA private key. Quite surprisingly, one of the exhibited faults is, ironically enough, made possible because of the existence of such protection. Mbedtls library is also analyzed in this paper. A way to find all exploitable faults on monobit flip fault model is also detailed.

Implementation of an eCK-secure Key Exchange Protocol for OpenSSL

Security models have been developed over time to analyze the security of two-party authenticated key exchange (AKE) protocols. LaMacchia et al. (ProSec 2007) presented a strong security model for AKE protocols, namely the extended Canetti-Krawczyk (eCK) model, addressing wide range of real-world attack scenarios. They constructed a protocol called NAXOS, that is proven-secure in the eCK model. In order to satisfy the eCK security, the NAXOS protocol uses a hash function to combine the long-term secret key and the ephemeral secret key, which is often called as “NAXOS-trick”. However, for the NAXOS-trick-based protocols, the way of leakage modelled in the eCK model leads to an unnatural assumption of leak-free computation of the hash function. Precisely, the eCK model allows the attacker to reveal the ephemeral key while the output of the NAXOS-trick computation remains safe (leak-free). In a recent work of Alawatugoda et al. (IMA Cryptography and Coding 2015), a NAXOS-trick-free eCK-secure AKE protocol is presented, namely protocol P1. In this work, we implement the protocol P1 to be used with the widely-used OpenSSL cryptographic library. OpenSSL implementations are widely used with the real-world security protocol suites, such as Security Socket Layer (SSL) and Transport Layer Security (TLS). As per best of our knowledge, this is the first implementation of a eCK-secure key exchange protocol for the OpenSSL library. Thus, we open up the direction to use the recent advancements of cryptography for real-world Internet communication.

Cross-VM Cache Attacks on AES

Cache based attacks can overcome software-level isolation techniques to recover cryptographic keys across VM-boundaries. Therefore, cache attacks are believed to pose a serious threat to public clouds. In this work, we investigate the effectiveness of cache attacks in such scenarios. Specifically, we apply the Flush+Reload and Prime+Probe methods to mount cache side-channel attacks on a popular OpenSSL implementation of AES. The attacks work across cores in the cross-VM setting and succeeds to recover the full encryption keys in a short time—suggesting a practical threat to real-life systems. Our results show that there is strong information leakage through cache in virtualized systems and the software implementations of AES must be approached with caution. Indeed, for the first time, we demonstrate the effectiveness of the attack across co-located instances on the Amazon EC2 cloud. We argue that for secure usage of world's most commonly used block cipher such as AES, one should rely on secure, constant-time hardware implementations offered by CPU vendors.

Verification of a cryptographic primitive: SHA-256 (abstract)

A full formal machine-checked verification of a C program: the OpenSSL implementation of SHA-256. This is an interactive proof of functional correctness in the Coq proof assistant, using the Verifiable C program logic. Verifiable C is a separation logic for the C language, proved sound w.r.t. the operational semantics for C, connected to the CompCert verified optimizing C compiler.

Verification of a Cryptographic Primitive

This article presents a full formal machine-checked verification of a C program: the OpenSSL implementation of SHA-256. This is an interactive proof of functional correctness in the Coq proof assistant, using the Verifiable C program logic. Verifiable C is a separation logic for the C language, proved sound with respect to the operational semantics for C, connected to the CompCert verified optimizing C compiler.

A fault induction technique based on voltage underfeeding with application to attacks against AES and RSA

Fault injection attacks have proven to be a powerful tool to exploit the implementation weaknesses of cryptographic algorithms. Several techniques perturbing the computation of a cipher have been devised and successfully employed to leak secret information from erroneous results. We present a low-cost, non-invasive and effective technique to inject transient faults into a general purpose processor through lowering its feeding voltage, and to characterize the effects on the computing system. This technique is effective enough to lead attacks against a software implementation of a cryptosystem running on a full fledged ARM9 CPU with a complete operating system. We validate the effectiveness of the fault model through attacking OpenSSL implementations of the RSA and AES cryptosystems. A new attack against AES, able to retrieve the full 256-bit key, is described, and the number of faults to be collected is delineated. In addition, we propose a generalization of the attack against the RSA encryption presented in Barenghi et al. (2009), to a multi-bit fault model, and the analysis of its computational complexity. The attacks against AES retrieve all the round keys regardless of their derivation strategy, the number of cipher rounds and the diffusion layer, while the attacks against RSA retrieve either the message or the secret key.

A study of the energy consumption characteristics of cryptographic algorithms and security protocols

Security is becoming an everyday concern for a wide range of electronic systems that manipulate, communicate, and store sensitive data. An important and emerging category of such electronic systems are battery-powered mobile appliances, such as personal digital assistants (PDAs) and cell phones, which are severely constrained in the resources they possess, namely, processor, battery, and memory. This work focuses on one important constraint of such devices-battery life-and examines how it is impacted by the use of various security mechanisms. In this paper, we first present a comprehensive analysis of the energy requirements of a wide range of cryptographic algorithms that form the building blocks of security mechanisms such as security protocols. We then study the energy consumption requirements of the most popular transport-layer security protocol: Secure Sockets Layer (SSL). We investigate the impact of various parameters at the protocol level (such as cipher suites, authentication mechanisms, and transaction sizes, etc.) and the cryptographic algorithm level (cipher modes, strength) on the overall energy consumption for secure data transactions. To our knowledge, this is the first comprehensive analysis of the energy requirements of SSL. For our studies, we have developed a measurement-based experimental testbed that consists of an iPAQ PDA connected to a wireless local area network (LAN) and running Linux, a PC-based data acquisition system for real-time current measurement, the OpenSSL implementation of the SSL protocol, and parameterizable SSL client and server test programs. Based on our results, we also discuss various opportunities for realizing energy-efficient implementations of security protocols. We believe such investigations to be an important first step toward addressing the challenges of energy-efficient security for battery-constrained systems.