Ring oscillators (ROs) are widely used in on-chip sensors and security primitives due to their simplicity, scalability, and sensitivity to process variations. In true random number generators (TRNGs), ROs serve as an entropy source by exploiting jitter originating mainly from physical noises and other stochastic phenomena, enabling low-cost generation of unpredictable random numbers for cryptographic applications. Ensuring the robustness of such designs against fault injection attacks is therefore critical. In this paper, we introduce a novel attack scenario in which pulsed ElectroMagnetic Fault Injection (EMFI) degrades the randomness quality of RO-based TRNGs by exploiting their susceptibility to harmonic locking. Experimental results on FPGA demonstrate that carefully tuning EMFI parameters can deterministically reduce entropy, significantly impairing the statistical quality of the generated bits and calling into question the RO-TRNG robustness when deployed in adversarial environments.

The description of the physical noise source is of utmost importance for any TRNG certification. In the case of ring oscillators, Allan variance is a reliable and comprehensive tool which enables the distinction between the jitter coming from flicker noise (autocorrelated) and from thermal noise (random). In this paper, we realize measurements directly on the analog source of numerous TRNG structures: a ring oscillator. Our data, along with evidence from the literature, indicates the presence of a third noise source. The quantization noise has not been so far taken into consideration, but is unquestionably present in all TRNG reliant on jitter. Its importance is key to an accurate estimation of thermal noise contribution, which can be shadowed by it. Measurements presented in this paper show that insufficient sampling (i.e. higher quantization noise) can lead to an overestimation of jitter coming from thermal noise and therefore an overestimation of the calculated entropy. The latter is the only type of noise considered reliable in currently existing ring oscillator-based TRNG models. As a rule of thumb, three orders of magnitude between the sampling and the sampled signal are necessary in order to determine the thermal noise jitter correctly.

Protecting programs against hardware fault injection requires accurate software fault models. However, typical models, such as the instruction skip, do not take into account the microarchitecture specificities of a processor. We propose in this article an approach to study the relation between faults at the Register Transfer Level (RTL) and faults at the software level. The goal is twofold: accurately model RTL faults at the software level and materialize software fault models to actual RTL injections. These goals lead to a better understanding of a system's security against hardware fault injection, which is important to design effective and cost-efficient countermeasures. Our approach is based on the comparison between results from RTL simulations and software injections (using a program mutation tool). Various analyses are included in this article to give insight on the relevance of software fault models, such as the computation of a coverage and fidelity metric, and to link software fault models to hardware RTL descriptions. These analyses are applied on various single-bit and multiple-bit injection campaigns to study the faulty behaviors of a RISC-V processor.

To protect against hardware fault attacks, developers can use software countermeasures. They are generally designed to thwart software fault models such as instruction skip or memory corruption. However, these typical models do not take into account the actual implementation of a processor. By analyzing the processor microarchitecture, it is possible to bypass typical software countermeasures. In this paper, we analyze the vulnerability of a secure code from FISSC (Fault Injection and Simulation Secure Collection), by simulating fault injections in a RISC-V Rocket processor RTL description. We highlight the importance of hidden registers in the processor pipeline, which temporarily hold data during code execution. Secret data can be leaked by attacking these hidden registers. Software countermeasures against such attacks are also proposed.

As technology evolves, digital systems are becoming more vulnerable to hardware faults, while also increasing in complexity. Analyzing the security of a program hence requires powerful techniques such as static code analysis. The methods developed so far usually apply these techniques with a specific software fault model. Yet, the effects a fault can have on a program are very diverse, and are not entirely captured by typical software fault models. In this paper, we present a method to instrument a code with complex fault models, and we use it with a tool based on abstract interpretation to verify that some security properties hold whatever the user inputs. The tool allowed us to find vulnerabilities (validated with RTL simulation) that would be hard to find with other tools. Finally, we discuss the benefits and drawbacks of the method.

Fault injection is a powerful technique for attacking digital systems. Software developers have to take into account fault effects when system security is a concern. To this end, software fault models have been developed. However, these models are often designed independently of any hardware consideration and thus raise the problem of realism. The generality of these models cannot account for the specificities of each architecture. As a consequence, software countermeasures based on such software fault models do not guarantee a good protection against faults. Processor microarchitecture should be precisely analysed to better understand faulty behaviours and design stronger software countermeasures. To illustrate this assumption, we will show in this paper some faulty behaviours that have been observed on a RISC-V processor, and their consequences on typical software countermeasures.

We present in this paper a security analysis of electronic devices which considers the lifecycle properties of embedded systems. We first define a generic model of electronic devices lifecycle showing the complex interactions between the numerous assets and the actors. The method is illustrated through a case study: a connected insulin pump. The lifecycle induced vulnerabilities are analyzed using the EBIOS methodology. An analysis of associated countermeasures points out the lack of consideration of the life cycle in order to provide an acceptable security level of each assets of the device.