Keywords: 5, 6, 10, 19, 26, 31, 33, 34 CSP cryptographic service provider. 31, 32 33 ECC elliptic curve cryptographic. 31

for reverse engineering. 7, 45, 47

Introduction

Professional context

Tracing back to my scientific origins, I hold a master's degree in cryptology from the University of Limoges. I defended my PhD thesis in microelectronics entitled A Formalism for Physical Attacks on Cryptographic Device and Its Exploitation to Compare and Research New Attacks, at École Nationale Supérieure des Mines de Saint-Étienne (ENSMSE) in Gardanne on October 24, 2014.

Then I pursued with a postdoc during approximately two years (2015-2017) at Institut national de recherche en sciences et technologies du numérique (INRIA) Rennes in the threat analysis and mitigation for information security (TAMIS) team. I was funded by the Agence Nationale de la Recherche (ANR) Cogito project [START_REF]Runtime Code Generation to Secure Devices COGITO[END_REF]. The laboratory high security (LHS) of INRIA Rennes has been created at this time. I worked on the development of different experimental benches in the LHS. In 2015, the pandemic of ransomware just began, and I took the opportunity to work on this subject.

My first PhD student, Aurélien Palisse defended in 2019 [START_REF] Palisse | Analyse et détection de logiciels de rançon[END_REF], and two others, Routa Moussalieb [START_REF] Palisse | Analyse et détection de logiciels de rançon[END_REF] and Leopold Ouairy [START_REF] Ouairy | Analyse des vulnérabilités dans des systèmes embarqués face à des attaques par fuzzing[END_REF] in 2020. Aurélien Palisse and Routa Moussalieb worked on ransomware [1-3, 6, 7]. The PhD of Léopold Ouairy was about fuzzing on smart cards [START_REF] Ouairy | Normalization of Java source codes[END_REF][START_REF]Protection of systems against fuzzing attacks[END_REF][22][23].

Since 2017, I have been an associate professor at IMT-Atlantique in OCIF team. This Institut de Recherche en Informatique et Systèmes Aléatoires (IRISA) team is focusing on the internet of things (IoT) in all its aspects, including security.

I recruited Slaheddine Zerkan for a postdoc on a project of security of wireless communications for battery management systems in cars. This project was in the OCIF team context with Nicolas Montavont, Georgios Papadopulos and the PhD student Guillaume Le Gall. Unfortunately, Covid and confinement aborted the project.

Today, I am leading a project funded by the Brittany region: "Attaques Physiques sur les Chiffrements Intègres Légers (APCIL)" on the vulnerabilities due to physical attacks on the new lightweight cryptographic algorithms proposed in the national institute of standards and technology (NIST) competition. Additionally, I am involved in other research initiatives, such as the Beyond 5G project funded by France Relance. I am also a permanent member of the Cyber CNI Chair at IMT-Atlantique.

In this context I am advising three theses. Modou Sarry works on the APCIL project. Awaleh Houssein works in the Cyber CNI Chair, on using physical information leakage such as sound to detect anomalies in programmable logic controllers. The last PhD student Pierre-Marie Lechevalier is focused on guaranteeing trust and security in the composition of distributed network services and in the Beyond 5G project.

My publications and results span various domains of security in defence and attack. I have a strong background in the field of symmetric cryptography. But, symmetric cryptography is not the only security tool I am working with. PIN code is another important as shown in [START_REF] Bouder | A template attack against VERIFY PIN algorithms[END_REF][START_REF] Bouder | Theoretical security evaluation of the human semantic authentication protocol[END_REF]. In this manuscript, I choose to focus on ransomware and physical attacks with a symmetric cryptographic view, even if they are not my only work topics.

Personal motivation to the HDR

Since my nomination as an associate professor at IMT-Atlantique, teaching has been a very time-consuming. Indeed, many of the lessons I teach did not exist at the school before. On the other hand, during three years, I was the co-head pedagogical, along with Romaric Ludinard, of the Mastère Spécialisé en Cyber-Sécurité (MSCS). This responsibility could be a full-time job.

Obtaining an HDR is a good way to refocus on my research career. My research team, OCIF, is restructuring, and it is an opportunity for me to highlight my research topics. The HDR gives me the possibility to gain true research independence. I have worked on different subjects and with different people in computer security, including: physical attacks, security of embedded devices, vehicle security, malware, trust, network security, and cryptography. I have learned a lot and have a broad vision of cybersecurity. In the future, I wish to primarily refocus on my preferred research topic: the physical attacks.

Scientific context 1.1.3.1 Computer security and cryptography

Computer security, also called cybersecurity is a critical aspect of modern computing that focuses on protecting computer systems and networks, from malicious activities. As technology continues to advance and becomes more integrated into our daily lives, the need for robust computer security measures becomes increasingly important. Without proper security measures in place, individuals, organizations, and even governments are vulnerable to cyber attacks, threats that can have serious consequences. Ransomware is an example of the most virulent attacks of our time.

Cryptography, etymologically the science of secrecy, is a subdomain of computer security. Modern cryptography focuses on four properties: 1. confidentiality: to limit data access to authorized people; 2. integrity: to ensure that the information cannot be altered;

authentication: to validate the origin of data;

4. non-repudiation: to allow a person to take part in a contract without the possibility to denounce it later.

Modern cryptography can be split in two subdomains: symmetric and asymmetric cryptography. This document focuses only on symmetric cryptography. Although the principles of cryptography are as old as the world, it never ceases to evolve to meet security needs. It must adapt to new needs and new devices, while being robust to attacks.

IoT and embedded devices

The Internet is a fantastic concept where all systems can interconnect, using a standard and recognized approach with common protocols. Internet of things (IoT) is a good illustration of this global interoperability, where embedded systems, serving as sensors or actuators, are connected to the Internet. IoT connects everyone and everything. It results that such devices can operate as servers and can make resources available to various clients, including our traditional web browser on our computers. The IoT avoids deploying systems in silos, by reusing existing principles and protocols to implement a specific application, which solves the problems of modularity, extensibility and integration. This is the main reason for the rapid growth of the IoT in many different domains, ranging from e-agriculture to smart cities, including Industry 4.0. However, as these interconnected networks became more popular among the general public, they also became susceptible to attacks. A simplified vision of the IoT could be to say that now that all systems are interconnected, any node or communication between nodes could be compromised and attackers could benefit from many different entry points and may penetrate deeply in a given system. So cybersecurity is the main feature for the sustainability of these systems.

To meet the security requirements, robust and practical solutions are expected, especially when considering embedded devices that usually have low capacity in terms of energy and computation.

The functional correctness of IoT is an absolute prerequisite. In summary, IoT needs security as cryptography [START_REF] Blanc | Benchmarking of lightweight cryptographic algorithms for wireless iot networks[END_REF] and PIN code. Today, an increasing number of embedded systems have multifunctional capabilities, similar to our mobile phones. However, the traditional definition is as follows. An embedded system is defined as an autonomous digital system, with three particular characteristics.

1.

It is often specialized in a specific task, for example a smart card can be dedicated to payment.

2. An embedded system has space constraints. Some devices are getting smaller and smaller.

3.

Finally, it has energy constraints, so restricted consumption.

Due to their spatial and energy constraints, the resources of an embedded system are generally limited. In this context, specific cryptographic algorithms called "lightweight" are developed.

These autonomous devices are more and more widespread, especially in IoT. These devices are prime targets for physical attacks.

Physical attacks

Between the mathematical algorithm and its practical implementation in a circuit as software or hardware implementation, there are various levels of abstraction. At each level of abstraction, new vulnerabilities are possible, which is why theoretical algorithms cannot anticipate all attacks (present and future) at once. A comprehensive list of the different abstraction levels is the following.

1. Algorithm: the mathematical theory.

2. Software: the different programming language such as: C, java, python, etc. Once designed, the algorithm is described by a computer scientist in a programming language. The program is then compiled to be translated into machine language into a set of instructions.

3. Architecture and microarchitecture. The processor or central processing unit (CPU) (Central Processing Unit) is the component of the computer that executes machine instructions. A processor built into a single integrated circuit is called a microprocessor. A programmer may choose to operate directly at this level and code directly in assembly code (machine language).

Register transfer logic (RTL).

An arithmetic logic unit (ALU) instruction can be split down into Boolean functions. They are implemented in electronics in the form of logic gates connected by wires.

5.

Transistors: semiconductor devices that control a current or voltage. Logic gates are built from several transistors connected appropriately. A logical 0 corresponds to a voltage below a certain value, otherwise it corresponds to a logical 1.

Even if an algorithm is proved secure mathematically, cryptanalysis has another dimension: physical attacks. These attacks rely on the interaction of the computing unit with the physical environment. Thus, these attacks occur at the levels RTL and transistors.

Physical attacks can be split in two parts: fault injection attack (FIA) and side channel analysis (SCA).

The physical cryptanalysis is the research field, in which an attacker uses physical parameters to attack cryptographic primitives. In this domain the impact of the attack is at the level 1 or 2. According to their goal, physical symmetric cryptanalysis can be classified into two categories. The attacks are those the two following categories.

® Confidentiality

• Sometimes, the attacker attempts to obtain the secret key.

• In the case of reverse engineering, an attacker aims to extract a portion or all of an algorithm function.

® Integrity

• The attacker aims to alter the data, for instance, by substituting a part of a message with a selection of their own. This constitutes an attack on data integrity at the algorithmic level 1.

• The attacker wants to change the program execution. They attempt to skip instructions or replace them with others, for instance, to avoid using a particular secret and substitute it with another.

In the literature, some frameworks have been published to evaluate and classify physical attacks [START_REF] Standaert | A unified framework for the analysis of side-channel key recovery attacks[END_REF][27][START_REF] Ito | Perceived information revisited: New metrics to evaluate success rate of side-channel attacks[END_REF][START_REF] Gangolli | A systematic review of fault injection attacks on iot systems[END_REF]. During my PhD, I worked to find a framework to describe physical attacks [START_REF] Bouder | An evaluation tool for physical attacks[END_REF][START_REF] Robisson | Physical functions: the common factor of side-channel and fault attacks?[END_REF][START_REF] Bouder | A Unified Formalism for Physical Attacks[END_REF].

Scientific challenges with a cryptographer view

In this manuscript, I have chosen to present results and future work in two contexts: ransomware and physical attacks, with symmetric cryptography as a common point of view.

A primary motivation is to study new algorithms of symmetric cryptography in the field of physical attacks. Even if I am not a pure cryptographer, I enjoy studying cryptography from different perspectives and applications. Also, in this manuscript, cryptographic primitives are sometimes a threat as in chapter 2, a target as in chapter 3 or a defensive tool as in chapter 4.

Ransomware

When discussing ransomware, it can be compared to a global pandemic, as attacks have become a significant threat across various sectors. The ethical motivation to find solutions to ransomware is clear.

Ransomware has turned encryption into a weapon, forcing us to fight back against our own robust tool. From a cryptographer point of view, it is stimulating to see encryption properties from an opposite perspective. In the ransomware context, encryption is a threat.

Physical attacks

There are more and more small circuits such as smart cards and connected devices in our daily lives. These circuits can contain critical or private information and can play a decisive role for their owner. However, if these circuits fall into the wrong hands, they can become targets for physical attacks. Also, studying physical attacks to better anticipate them improving the protection is a primary motivation.

Contributions

Ransomware

I worked for six years on the detection and remediation of ransomware. I was the advisor of two PhD students on this topic: Aurélien Palisse [START_REF] Palisse | Analyse et détection de logiciels de rançon[END_REF] and Routa Moussalieb [START_REF] Moussaileb | Log analysis for malicious software detection[END_REF]. A platform, malware-o-matic (MoM), for testing ransomware has been developed by these PhD students in the LHS. Different contributions about the detection and mitigation of ransomware behaviour were published [2][3][4][5][START_REF] Moussaileb | Ransomware's early mitigation mechanisms[END_REF][START_REF] Moussaileb | Ransomware Network Traffic Analysis for Pre-Encryption Alert[END_REF] in various conferences. A survey was published in [START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF].

Physical attacks

Since my PhD defence, I have been collaborating to the LHS platforms development. Different attacks [START_REF] Bukasa | How trustzone could be bypassed: Side-channel attacks on a modern system-on-chip[END_REF][START_REF] Bouder | A template attack against VERIFY PIN algorithms[END_REF][START_REF] Bouder | A multi-round side channel attack on aes using belief propagation[END_REF][START_REF] Houssein Meraneh | Blind Side Channel On The Elephant LFSR[END_REF] in this domain have been developed with different target cryptographic primitives and PIN code implementations. Other publications about countermeasures have been published too [START_REF] Couroussé | All paths lead to rome: Polymorphic runtime code generation for embedded systems[END_REF][START_REF] Lashermes | Hardware-Assisted Program Execution Integrity: HAPEI[END_REF]. Currently, I advise the PhD student Modou Sarry on side channel analysis (SCA) on authenticated encryption with associated data (AEAD). This manuscript presents published contributions, work in progress, and future projects.

Organization

The common link between the different chapters of this manuscript is symmetric cryptography. Indeed symmetric cryptography algorithms are studied as a threat in the chapter 2, a target in the chapter 3 and a solution in the chapter 4. In other words : ® chapter 2 explains how crypto-ransomware use symmetric encryption and solutions to stop them; ® chapter 3 presents SCA attacks against classic symmetric cryptography algorithms and new generations of lightweight symmetric cryptography algorithms: AEAD;

® chapter 4 develops the idea to use symmetric cryptography to protect processor instructions.

Finally, the conclusion is drawn in chapter 5. These three chapters have a logical time sequence. Indeed chapter 2 presents results during these last years; the chapter 3 is a big part of my current work; the chapter 4 is past and future work.

In the continuation of this chapter 1, the context of symmetric cryptography is presented in section 1.2. More specifically, the algorithms studied in the report are described in section 1.2.3. To conclude this chapter, the section 1.3 is dedicated to teaching.

Symmetric cryptography prerequisites

This section 1.2 presents the classical symmetric cryptography 1.2.1 and its evolution in 1.2.2. Then in the algorithms used in the different chapters are described as prerequisites in 1.2.3.

Classical and older symmetric cryptography

Classical and older symmetric cryptography regroups the two following tool families.

1. Symmetric encryption is used for confidentiality.

An encryption algorithm transforms a message M called plaintext, with a key K, into data called ciphertext C, unintelligible for anyone who does not have the key to decrypt. The decryption algorithm takes as inputs the ciphertext C and key K and returns the plaintext M . In a symmetric encryption algorithm, the same key is used to encrypt and decrypt. This key K must remain secret.

Message authentication code (MAC)

and hash-based message authentication code (HMAC) are used for integrity.

A MAC takes in input M a text and a secret key K and returns a tag T of integrity. Only the owners of the key can verify the integrity of the message.

These tools: symmetric encryption, MAC and HMAC are built from symmetric primitive functions.

® In a stream cipher, the ciphertext is the result of an xor between plaintext and a vector of the same size. This vector is a random secret and disposable key or a pseudo-random sequence computed with a secret key and an initial seed.

® A block cipher is a deterministic primitive function that operates on fixed-length inputs, called blocks, and a secret key K. Therefore, the message needs to be divided into blocks and each block is then ciphered individually.

® A hash function noted H maps a text of arbitrary size to data of fixed size. A cryptographic hash function resists collision attacks and pre-image attacks.

® The mode of operation, called mode, describes how to repeatedly apply a block cipher or sometimes a hash function.

So a symmetric encryption can be a stream cipher or block cipher with a mode. A MAC is built with by a block cipher and a mode and a HMAC with a hash function and a mode. Symmetric cryptography security applies the following Shannon properties [START_REF] Shannon | A mathematical theory of communication[END_REF].

® The diffusion property applied to a symmetric primitive function is the idea that changing one bit in the input, should independently change each output bit with probability 0.5.

® The confusion property applied to a symmetric primitive function is an ambition to make the link between the input and the output as complex as possible.

New generation of symmetric cryptography algorithms

In numerous use cases, users require both confidentiality and integrity. Therefore, with older symmetric cryptography, they had to utilize a specific mode to guarantee integrity in symmetric encryption, or they had to combine MACs and encryption.

On the other hand, there are more and more small devices with low computing power, that need cryptography. So lightweight algorithms are required.

In this context, the NIST started the competition [START_REF]Lightweight Cryptography Standardization Process[END_REF] for lightweight cryptography candidates for AEAD.

An authenticated encryption with associated data (AEAD) illustrated in NIST received 57 submissions to be considered for standardization. In March 2021, only 10 finalists were selected: ASCON [START_REF] Dobraunig | Ascon[END_REF], Elephant [START_REF] Beyne | Dumbo, jumbo, and delirium: Parallel authenticated encryption for the lightweight circus[END_REF], GIFT-COFB [38], Grain128-AEAD [START_REF] Hell | Grain-128aead, round 3 tweak and motivation[END_REF], ISAP [START_REF] Dobraunig | Isap v2. 0[END_REF], Photon-Beetle [START_REF] Bao | Photon-beetle authenticated encryption and hash family[END_REF], Romulus [START_REF] Khairallah | Romulus: Lighweight AEAD from Tweakable Block Ciphers[END_REF], Sparkle [START_REF] Beierle | Schwaemm and esch: lightweight authenticated encryption and hashing using the sparkle permutation family[END_REF], TinyJambu [START_REF] Wu | Tinyjambu: A family of lightweight authenticated encryption algorithms (version 2)[END_REF] and Xoodyak [START_REF] Daemen | Xoodyak, a lightweight cryptographic scheme[END_REF]. Finally, in February 2023, NIST decided to standardize ASCON [START_REF] Dobraunig | Ascon[END_REF].

I started to study these algorithms in 2020, so I did not know which algorithm would become the winner.

Algorithms studied in the report

There are numerous symmetric algorithms, but in the following, only algorithms studied in the report are described as prerequisites.

Block ciphers

Advanced encryption standard (AES)

The advanced encryption standard (AES) is a standard established by the NIST [START_REF]Specification for the Advanced Encryption Standard[END_REF] for symmetric key cryptography. It is a block cipher.

The encryption first consists of mapping the plaintext M of 128 bits into a two-dimensional array of 4×4 = 16 bytes called the state. Rows and columns are respectively indexed i and j.

Rounds description

After a preliminary xor (denoted ⊕) between the input and the key K 0 , the advanced encryption standard (AES) executes 10 times a round function that operates on the state. The operations used during these rounds are:

® SubBytes (SB) composed of non-linear transformations: 16 S-boxes, working independently on individual bytes of the state;

® ShiftRow (SR) a byte-shifting operation in each row of the state;

® MixColumns (MC) a linear matrix multiplication on GF(2 8 ), working on each column of the state;

® AddRoundKey a xor between the state and the round key

K r , r ∈ [[0, 10]].
The algorithm is summarized in Figure 1.2.

The derived key K denotes the master key. The size of the master key is 128 bits. K r is the round key used in round r, K r is represented by a two-dimensional array of 4 • 4 bytes, like the state. K i,j r is the round-key byte at row i and column j. The round key K r+1 depends on the round key K r with K 0 = K. More precisely, the round keys are computed with a KeyExpansion function described by the system of equations (1.1), where SB is the S-Box function and Rcon is a constant matrix of size 4 • 10.

K i,0 r+1 = K l,0 r ⊕ Rcon(i, r) ⊕ SB K i+1 mod 4,3 r ∀i ∈ [[0, 3]] K i,j r+1 = K i,j r ⊕ K i,j-1 r+1 ∀i ∈ [[0, 3]] and j ∈ [[1, 3]] (1.1) ------------------------round 1 to 9 ------------------------round 0 ------------------------round 10 M K 0 SB SR M C K r SB SR K 10 C Figure 1.2: scheme of block cipher AES 1.2.3.1.
2 TWINE TWINE is a 64-bit block cipher presented in [START_REF] Suzaki | TWINE: A Lightweight Block Cipher for Multiple Platforms[END_REF] aiming at a reduced circuit area while avoiding non-software friendly operation (such as bit permutations) to maintain decent performances when implemented in software. It is a generalized Feistel network (GFN) with 16 blocks β, 4 bits each, that can accept either 80-bit or 128-bit keys. The permutation layer that rearranges the blocks at the end of each round was chosen to maximize diffusion between blocks, according to a result of [START_REF] Suzaki | Improving the generalized feistel[END_REF]. Compared to the cyclic shift, this permutation requires twice less rounds for an input difference to influence all the blocks. One round of TWINE is depicted on Figure

Pelican

Pelican [START_REF] Daemen | The mac function pelican 2.0[END_REF] is an iterative MAC function based on AES block cipher.

Encryption modes

Electronic code book (ECB)

The electronic code book (ECB) mode encryption is a simple mode. The data are divided into blocks, and each block is encrypted separately (1.2).

C i = En(M i , K). (1.2)
It is illustrated in Figure 1.5. This mode is vulnerable to replay attacks in among others, but it still used. The block cipher takes a nonce (the counter) as input. Subsequently, the plaintext block is xored with the output of the block cipher. The advantage of counter (CTR) mode over CBC mode is that blocks can be decrypted in parallel.

M 0 En K C 0 M 1 En K C 1 M 2 En K C 2 • • • Figure 1.
C 0 = En(M 0 ⊕ IV, K) C i+1 = En(M i+1 ⊕ C i , K) (1.3) It is illustrated in Figure 1.6. En M 0 IV K C 0 M 1 K C 1 En M 2 K C 2 En
IV 0 En C 0 K M 0 IV 1 En C 1 K M 1 IV 2 En C 2 K M 1 Figure 1.7: Scheme of CTR

Galois counter mode (GCM)

The Galois counter mode (GCM) [START_REF] Dworkin | Galois/counter mode (GCM) and GMAC[END_REF] ensures confidentiality and integrity. Encryption operates like a stream cipher like CTR mode, with the block cipher primitive used to generate random data. [START_REF] Beyne | Dumbo, jumbo, and delirium: Parallel authenticated encryption for the lightweight circus[END_REF][START_REF] Beyne | Elephant v2[END_REF] is an AEAD finalist to the NIST lightweight cryptography competition. It is an Encryptthen -MAC construction that combines CTR mode [START_REF] Bernstein | How to Stretch Random Functions: The Security of Protected Counter Sums[END_REF] encryption with a variant of the protected counter sum [START_REF] Luykx | A MAC Mode for Lightweight Block Ciphers[END_REF]. It uses a cryptographic permutation masked with LFSRs in an Even -Mansourlikefashion [START_REF] Granger | Improved Masking for Tweakable Blockciphers with Applications to Authenticated Encryption[END_REF] in place of a block cipher. Let P be an n-bit cryptographic permutation, and φ an n-bit LFSR. Let the function mask : {0, 1} 128 × N × {0, 1, 2} → {0, 1} n be defined as follows:

IV0 IV1 IV2 IVn+1 • • • incr incr incr En K K En K En K En • • • M0 M1 Mn • • • Aν A0 • • • • • • C0 C1 Cn • E(K, 0) • E(K, 0) • E(K, 0) • E(K, 0) • • • • • • • E(K, 0) c • E(K, 0) T Figure 1.8: Scheme of Galois counter mode (GCM)

AEADs

Elephant Elephant

K || 0 • • • P mask 0,0 K φ N || A1 mask 1,0 K φ A2 P • • . . . mask n-1,0 K . . . . . . An || 10 • • • P • • φ ⊕ id mask 0,1 K N || 0 • • • P • • • φ ⊕ id mask 1,1 K N || 0 • • • P • • φ ⊕ id mask n-1,1 K N || 0 • • • P • • Trunc|M n | Mn Cn M1 C1 M2 C2 . . . . . . Cn || 10 • • • P mask n-1,2 K φ ⊕ id • P mask 1,2 K φ ⊕ id • P mask 0,2 K φ ⊕ id • . . . . . .

P

mask i,j K = mask(K, i, j) = (φ ⊕ id) j • φ i • P K||0 n-128 , (1.4)
where id is the identity function. Let Split be the function that splits an input into n-bit blocks, where the last block is zero-padded. Let Trunc ν be the function that returns ν left-most bits of an input.

Encryption En under Elephant takes as input a 128-bit key K, a 96-bit nonce N , associated data A, and a plaintext M . It outputs a ciphertext C as large as M , and a ν-bit tag T . The description is depicted on Figure 1.9.

Decryption gets as input a 128-bit key K, a 96-bit nonce N , associated data A, a ciphertext C, and ν-bit tag T . It outputs a plaintext M as large as C if the tag T is correct, or the symbol ⊥ otherwise. The description easily follows from that of encryption. Elephant comes in three flavours which differ on the n-bit cryptographic permutation P and the LFSR φ used, as well as the tag size ν.

Dumbo uses the 160-bit permutation Spongent [START_REF] Bogdanov | Spongent: a Lightweight Hash Function[END_REF], the LFSR φ Dumbo given by equation (1.5) and illustrated on Figure 1.10, and has tag size ν = 64 bits. Jumbo uses the 176-bit permutation Spongent [START_REF] Bogdanov | Spongent: a Lightweight Hash Function[END_REF], the LFSR φ Jumbo given by equation (1.6) and illustrated on Figure 1.11, and has tag size ν = 64 bits.

φ Dumbo : (B 0 , • • • , B 19 ) → (B 1 , • • • , B 19 , (B 0 ≪ 3) ⊕ (B 3 7) ⊕ (B 13 7)) (1.5) B0 B1 B2 B3 B4 . . . B12 B13 B14 . . . B18 B19 ≪ 3 ≪ 7 ≫ 7
φ Jumbo : (B 0 , • • • , B 21 ) → (B 1 , • • • , B 21 , B 0 ≪ 1 ⊕ B 3 7 ⊕ B 19 7) (1.6) B 0 B 1 B 2 B 3 B 4 . . . B 18 B 19 B 20 B 21 ≪ 1 ≪ 7 ≫ 7 Figure 1.11: 176-bit LFSR φ Jumbo . φ Delirium : (B 0 , • • • , B 24 ) → (B 1 , • • • , B 24 , B 0 ≪ 1 ⊕ B 2 ≪ 1 ⊕ B 13 7) (1.7)
Delirium uses the 200-bit permutation Keccak [START_REF] Bertoni | The Keccak Reference[END_REF][START_REF]SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions[END_REF], the LFSR φ Delirium given by equation (1.7) and illustrated on Figure 1.12, and has tag size ν = 128 bits.

B 0 B 1 B 2 B 3 . . . B 12 B 13 B 14 . . . B 23 B 24 ≪ 1 ≪ 1 ≪ 7

Sparkle

Schwaemm The main instance of Schwaemm is Schwaemm 256-128 [START_REF] Beierle | Schwaemm and esch: lightweight authenticated encryption and hashing using the sparkle permutation family[END_REF], illustrated in Figure 1 a 256-bit nonce N , a 128-bit key K and output a 128-bit authentication tag T . The master key is:

K = K 1 ||K 2 ,
where: The Sparkle 11 384 permutations are built using the following main components :

|K 1 | = |K 2 | = 64 bits.
N K F • • • β ′ 0 β ′ 1 β ′ 2 β ′ 3 β ′ 4 β ′ 5
® an S-box Alzette denoted A i , for i ∈ [ [START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF]5]], a 64-bit block cipher with a 32-bit key ® a Feistel type linear diffusion layer F.

L0 / 32 ≪ 1 L0 1 • ≪ 8 R0 / 32 • α L1 R1 ≪ 15 • L1 1 • ≪ 15 α L2 R2 • L2 1 • ≪ 1 α L3 R3 ≪ 8 • L3 1 • ≪ 16 α L4 R4
Figure 1.15: An Alzette A i with a constant α Zoom on Alzette Alzette, denoted A i , is a 64-bit block cipher. Alzette is defined as the permutation:

(L 0 , R 0 ) → A(L 0 , R 0 , α).
Alzette takes as input two 32 bits words. It is composed of four rounds where each round uses operations like modular addition, rotation and xor. After each round, the 32-bit constant is xored to the left word. Its round constant ensures that the computations in each branch of the Sparkle permutation are different from one another to break the symmetry of the permutation structure.

Chapter 1. Introduction and Context

Hélène Le Bouder Alzette illustrated in Figure 1.15 can be described with the following equations mod 32:

L 01 = L 0 ⊞ (R 0 ≪ 1); (1.8) L 1 = L 01 ⊕ α; (1.9) R 1 = (L 01 ≪ 8) ⊕ R 1 ;
(1.10)

L 11 = L 1 ⊞ (R 1 ≪ 15); (1.11) L 2 = L 11 ⊕ α; (1.12) R 2 = (L 11 ≪ 15) ⊕ R 2 ;
(1.13)

L 21 = L 2 ⊞ R 2 ;
(1.14)

L 3 = L 11 ⊕ α; (1.15) R 3 = (L 01 ≪ 1) ⊕ R 3 ; (1.16) L 31 = L 3 ⊞ (R 3 ≪ 8);
(1.17)

L 4 = L 21 ⊕ α; (1.18) R 4 = (L 01 ≪ 16) ⊕ R 3 . (1.19)
(1.20)

Teaching

Given my enthusiasm for the topic, I intend to conclude this first chapter on teaching. At IMT-Atlantique, I teach various types of students, including engineers, professional engineers pursuing master's degrees, and students in MSCS. Furthermore, I teach embedded security and cryptography in diverse contexts, including the IoT, blockchain, among others.

I am also invested in new pedagogical techniques, such as massive open online courses (MOOCs). I am a co-author, along with Gaël Thomas, of the cryptography section of Romaric Ludinard's MOOC on blockchain. I believe that fun and humour are crucial for facilitating learning. In this MOOC, cryptography is explained using farm animals. The sheep want to communicate and the wolf is the adversary. A link of these videos is: https://www.youtube.com/playlist?list=PLjXls-kqM6JBZds1p4-lyyZmOv1xpH_CK. I advocate for my work to include free content.

I am leading another MOOC project on physical attacks. For this project, I am collaborating with INRIA and ENSMSE, and I conduct guest interviews with people from Commissariat à l'Énergie Atomique (CEA), Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI), and ST-microelectronics. The synopsis is as follows: a chicken wants to protect the hen house from the malicious fox. To do this, the chicken use authentication with PIN code. The fox uses physical attacks to try to break it. Another significant part of my activity is scientific popularization. I regularly go to middle schools and high schools to popularize science. I hope to transmit the taste for science, especially to young ladies. Writing an illustrated book about hardware security is a project that I hold dear for the future.

Chapter 2

Crypto ransomware "Dorénavant vous saurez qu'il ne faut jamais charger une arbalète avec un boomerang."

Gaston dans Lagaffe mérite des baffes d'André Franquin.

Introduction

A ransomware is a malware that asks a payment to the legitimate users for accessing their machine or computer files. There are two types of ransomware: some prevent the usage of the computer, others encrypt files. So in this document, a crypto-ransomware is a malware which encrypts user data; then asks a ransom in exchange for the decryption key.

Ransomware constitutes a sensitive topic since they are rapidly spreading. They are one of the most serious security threats on the Internet. The real first occurrence of a ransomware was in 1989 [START_REF] Young | Cryptovirology: Extortion-Based Security Threats and Countermeasures[END_REF]. But, the pandemic began in 2012, when the number of ransomware victims increased significantly. Cryptocurrencies such as bitcoin made the success of this kind of malware. Indeed there is a pseudo-anonymity of transaction actors. That probably explains why the number of ransomware victims has significantly increased.

Motivation

Ransomware attacks impact various sectors: education, entertainment, financial services, healthcare, etc. The number of attacks is in constant increase in recent years. The attack consequences are often catastrophic. So, it is very important to find solutions to this evil. Thus the motivation to join the malware battle specifically ransomware is the ethical motivation: find protection for the all society.

From my point of view, there is a very strong challenge in this battle. Before ransomware, encryption was always a tool to defend against attackers. Ransomware changes that and transforms encryption into a terrible weapon. So how to fight against our own robust tool? It is very stimulating for cryptographers to see encryption properties in a different view. That was my main motivation for this work.

Contributions

I started to work on ransomware in 2015. It was just the starting of the pandemic. So some countermeasures presented in this document, have evolved.

My contributions are on the topic of detecting and stopping ransomware infections. The main goal is to detect ransomware as fast as possible. In other words, with a minimal loss of files.

In practice, I was sequentially the advisor of two PhD students.

® The first was Aurélien Palisse. He defended his PhD "Analysis and detection of ransomware" [START_REF] Palisse | Analyse et détection de logiciels de rançon[END_REF] in March 2018. The director was Jean-Louis Lanet from INRIA and Colas Le Guernic from Direction Génerale de l'Armement Maîtrise de l'Information (DGA-MI) was the co-advisor.

® Then, Routa Moussalieb defended her PhD "Log Analysis for Malicious Software Detection" [START_REF] Moussaileb | Log analysis for malicious software detection[END_REF] in 2020. The directors were Jean-Louis Lanet from INRIA and Nora Cuppens from IMT-Atlantique at first, then Yann Busnel from IMT-Atlantique replaced Nora Cuppens.

The two PhD students worked hard to design an automated analysis platform called MoM (Malware O Matic).

Countermeasures against the most specific behaviour ransomware have been developed [2][3][4][5][START_REF] Moussaileb | Ransomware's early mitigation mechanisms[END_REF][START_REF] Moussaileb | Ransomware Network Traffic Analysis for Pre-Encryption Alert[END_REF]. Finally, a practical survey was published [START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF].

Then in 2021, I continued to work on this subject with David Lubicz from DGA-MI and Alexandre Gonzalvez at INRIA.

Organization

This chapter is organized as follows. The context and a short state of the art are presented in the section 2.2. In section 2.3 different solutions to detect and/or stop encryption by malware are presented. The section 2.4 proposes other countermeasures of ransomware. The platform of tests and some results are presented in 2.5. The conclusion and future works are drawn in the section 2.6. The rise of ransomware started with the use of cryptocurrency. One has to remark that ransomware first targeted Windows, but now all OS are attacked.

Classic crypto ransomware behaviour

The classic behaviour of a cryptographic ransomware is described as follows.

Infection vector

Generally ransomware comes from spam emails, self-propagation or drive-by downloads.

Trigger of malicious behaviour

Many malware programs detect the user activity by social engineering methods, before exhibiting malicious activity. It could be opening a file, a web search on Google or a simple click.

Initiation of Encryption process

Generally ransomware uses symmetric encryption as AES [START_REF]Specification for the Advanced Encryption Standard[END_REF], described in paragraph 1.2.3.1.1, to encrypt data. The first step is to generate symmetric keys with a random number generator. One symmetric key is associated with one victims file. Then a public key is used to encrypt symmetric keys. Sometimes the public key is embedded with the code. Some ransomware programs use the crypto API of Windows while others use their own embedded cryptography.

Encryption of data

Once the keys are generated, the encryption of files begins.

Ransom note

A ransom note is displayed to explain how to pay to the victim. This marker must be significantly visible, being part of the business model.

Ransom payment

Finally if the victim agrees to pay, the ransomware program rescues the files by handing the symmetric keys. In practice, it is often the case but sometimes the attacker do not restore data.

Summary of state of the art [1]

Different surveys have been published about ransomware protections [START_REF] Genç | Next generation cryptographic ransomware[END_REF][START_REF] Al-Rimy | Ransomware threat success factors, taxonomy, and countermeasures: A survey and research directions[END_REF][START_REF] Aurangzeb | Ransomware: a survey and trends[END_REF]. In the context of the Routa Moussalieb's PhD, a survey [START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF] was published. The different countermeasures are classified according to the different steps of the infection process. Our survey focuses on Windows. A summary is given in this section.

The first and best idea to protect data against ransomware attacks is to use data back-up as explained in [START_REF] Castiglione | Dynamic distributed secure storage against ransomware[END_REF][START_REF] Baykara | A novel approach to ransomware: Designing a safe zone system[END_REF]. In practice, it is not possible to have at any time an up-to-date back-up of data and to decide when and which data need to be restored. It is necessary to have a mechanism to detect a ransomware attack when it occurs.

The classic detection techniques used for all malware, such as network intrusion detection systems (NIDS) can be used for ransomware. Signature based detection remains a valid way to detect an infection. Network traffic is compared to previously well-known malware patterns, called signatures as in [START_REF] Moussaileb | Ransomware's early mitigation mechanisms[END_REF][START_REF] Ahmadian | Connection-monitor & connection-breaker: A novel approach for prevention and detection of high survivable ransomwares[END_REF][START_REF] Cabaj | Software-defined networking-based crypto ransomware detection using http traffic characteristics[END_REF][START_REF] Almashhadani | A multi-classifier network-based crypto ransomware detection system: a case study of locky ransomware[END_REF]. The limitation of these techniques is that they are unable to detect new malware, never seen before. This is a serious problem with ransomware because new ransomware appears regularly.

The detection of specific behaviours of ransomware has to be used. Some detection mechanisms specific to ransomware can be to watch how files are touched [START_REF] Moussaileb | Ransomware Network Traffic Analysis for Pre-Encryption Alert[END_REF] or to detect ransom notes writing. Some papers [START_REF] Akcora | Bitcoinheist: Topological data analysis for ransomware detection on the bitcoin blockchain[END_REF] studied the transaction for the ransom payment.

The most specific behaviour of ransomware is to overwrite files with encrypted data. The main problem is that these methods still generate a lot of false alarms.

Often ransomware does not come with their own cryptographic libraries and rather relies on the victim's own tools. So many protections are based on controlling accesses on the cryptographic tools in Windows [2,[START_REF] Chen | Automatic ransomware detection and analysis based on dynamic api calls flow graph[END_REF][START_REF] Al-Rimy | Zero-day aware decision fusion-based model for crypto-ransomware early detection[END_REF][START_REF] Al-Rimy | Crypto-ransomware early detection model using novel incremental bagging with enhanced semi-random subspace selection[END_REF].

One other way to detect ransomware is to insert honey pots. These are files that trigger an alarm when they are modified [START_REF] Moore | Detecting ransomware with honeypot techniques[END_REF][START_REF] Patton | Behavior-based ransomware detection using decoy files[END_REF].

Finally, there is a family of ransomware detection mechanisms which rely on encryption detection. Indeed encryption produces data which have a pseudo-random distribution, therefore increasing the entropy of the files. There is an important literature about statistical tests of randomness which can be used to detect encrypted data [3,[START_REF] Scaife | CryptoLock (and Drop It): Stopping Ransomware Attacks on User Data[END_REF][START_REF] Continella | ShieldFS: A Self-healing, Ransomware-aware Filesystem[END_REF][START_REF] Kharraz | Redemption: Real-Time Protection Against Ransomware at End-Hosts[END_REF][START_REF] Kharraz | UNVEIL: A Large-Scale, Automated Approach to Detecting Ransomware[END_REF].

Encryption detection and protection

As explained in the section 2.1, detecting and stopping encryption is my main motivation in the battle against ransomware. Here, encryption is an attack and not a defence tool. The cryptographic properties are analysed as witnesses to the attack. This section is split in three parts.

® Some ransomware programs use the cryptography tool of the victim. So our first idea is to monitor these tools. This approach [2]

Monitoring the crypto libraries [2]

Cryptovirology refers to the use of cryptography to malware. The proof of concept of cryptovirology has been presented by Young et al. in [START_REF] Young | Cryptovirology: Extortion-Based Security Threats and Countermeasures[END_REF]. Ransomware may use Microsoft's cryptographic application programming interface (MS CAPI). This section presents a generic countermeasure against a malicious usage of this API. This works was published in 2016 [2]. It was the first strong result of Aurélien Palisse PhD.

Microsoft's Cryptographic API

Windows operating systems, starting with Windows 95, include an easy-to-use API that supplies cryptographic services to userland applications through MS CAPI. Cryptographic primitives are embedded in dynamic link libraries and divided in cryptographic service providers (CSPs) each one offering a set of primitives classified by their type (hash function, signature, encryption). This API aims to provide an interface for programming by non-cryptographic specialists. Moreover due to its extensible architecture design, it is possible to add cryptographic modules once Microsoft signs them. For example, hardware security module vendors can implement white-box or home-made cryptographic algorithms and comply with federal information processing standard (FIPS) approved algorithm standards. It can be noticed that no user authentication is performed in order to access the primitives, authentication relies exclusively on the operating system. The framework does not provide persistent storage of keys or archival directly, you should use separate APIs provided by Microsoft. Moreover each time a process instantiates a dynamic link library (DLL), code is shared but data remains unique for each instance and thus no key is exposed at load time. Each cryptomodule is dedicated to one process so compartmentalization is ensured. Extended details can be found in [START_REF] Young | Cryptovirology: Extortion-Based Security Threats and Countermeasures[END_REF][START_REF]Microsoft enhanced cryptographic provider, fips 140-1 documentation security policy[END_REF] which give a list of the exported functions and an in-depth documentation.

MS CAPI is old (appeared with Windows 95), but is still widely spread notably in banking infrastructure. For legacy or backward compatibility in newer Windows operating systems, MS CAPI is deprecated but still present; it is strongly recommended to use the cryptography API next generation (CNG) beginning with Windows Vista. Despite this recommendation, OpenSSL continues to initialize its deterministic random bit generator with some entropy coming from CryptGenRandom from MS CAPI.

No elliptic curve cryptographic (ECC) is supported with default providers, NIST Suite B Cryptography is fully available in CNG as well as additional chaining modes as for example GCM [START_REF] Dworkin | Galois/counter mode (GCM) and GMAC[END_REF] presented in section 1.2.3.3.4 and the DES-X [START_REF]Data Encryption Standart DES[END_REF] block cipher.

One has to remark that the windows crypto API has evolved since these works (2016).

System Protection

Presentation

In the context of protection against ransomware, the main question is: "How to prevent malicious usages of MS CAPI without intrusive methods" ? The goal is to provide a fully transparent solution, as simple as possible, and ransomware must not be informed about any analysis. Contrary to Bromium report [START_REF] Kotov | Bromium: Understanding cryptoransomware[END_REF] where an intrusive method based on the instrumentation library Detours [START_REF] Hunt | Detours: Binaryinterception ofwin 3 2 functions[END_REF] is chosen, a CSP is implemented and then plugged in the system. When incorporating a cryptographic module in the system, we are in a legitimate position to observe malicious cryptographic behaviour but also legitimate calls. We have to provide real services to user applications and so the OpenSSL library for cryptographic primitives is used.

Implementation

The OpenSSL primitives are integrated in collaboration with MS CAPI architecture in order to get a functional provider. Version 1.0.2 dated from December 2015 is used and the provider was statically linked with the resulting library. The following services are provided: ® source of randomness.

® symmetric
The above algorithms represent a set of cryptographic primitives sufficiently exhaustive to fit the needs of ransomware based on observations and reports.

Integration

Cryptographic providers on both 32-bit and 64-bit architectures are compiled as DLLs. Providers are then placed in the System32 default path, and system integration is achieved through registry entries. Administrator rights are needed to plug a CSP in the system, registration is performed with regsvr32.exe. As explained in 2.3.1.1, the system cannot trust, and thus use, any provider until a valid signature from Microsoft is obtained. For our academic proof of concept, the binary responsible for the authentication mechanism to successfully load out CSP, is patched to authorize it without Microsoft's signature. As described in In fact, this is nothing more than an indirect jump to cryptsp.dll which contains the CSP authentication mechanism and most of the framework functionalities.

Still, a ransomware program may use another provider. Indeed, during the initialization phase, a call to CryptAcquireContext with the argument pszProvider lets the user choose between available providers.

If the provider name is left null, a registry key indicates which is the default provider according to the requested type. So cryptsp.dll has been patched again to redirect all explicitly named provider to the default one. The final step is to set the name of the preferred cryptographic provider in registry as our own.

Detection

The malicious behaviour must be stopped and the damage limited. In addition file recovery is needed to render ransomware harmless. We have the control of key generation, encryption, signature, randomness and integrity operations. At load time, no key exists within a CSP and usually deletion, exportation or public-key encryption is performed once operations are done. The advantage of this opportunity to monitor and store the secrets is if malicious activities are detected. Most interesting operations are logged in a special file prepended with a PE header and extension to prevent ransomware encryption.

The difficulty is now to detect any abnormal behaviour, no intelligence has been added to the module yet, but some possibilities can be investigated. MS CAPI is marked as deprecated so very few applications on Windows down to Windows XP use its services. In any case, an intensive use is suspect, particularly encryption operations.

Limitations

It is required to place a patched cryptsp.dll. This is enough for our experimental purpose and characterization, bu is unsuitable for any real-world deployment. Signing our provider allows it to be loaded by the legitimate cryptsp.dll. Forcing its use is still a theoretical issue, in practice most ransomware use the default one: our own provider. To complete the current solution, it can be considered than ransomware detection based on a supervised machine learning classifier. The provider can be deployed on legitimate hosts then the normal behaviour MS CAPI can train a model. We do not want to see machine learning as a miracle oracle. So, user opinion has to be requested when a malicious behaviour is suspected. This solution can be incorporated in the provider and ransomware are never known about its existence. The solution presented in this paragraph 2.3.1.2 forces ransomware to embed required cryptographic primitives in their binary.

Many ransomware programs use the Microsoft's Cryptographic API. This fact avoids MS CAPI hijacking for manufacturers and aims to prevent malicious access. These two protections are placed at a different level and can be used complementary for best security, leading to a 50% success rate in our experiments. Unfortunately, they are not efficient against all ransomware, some ransomware does not use MS CAPI.

Replay attacks [2]

In this part, a protection against crypto-ransomware using block ciphers, published in [2] is presented. As explained in the section 1.2.3.3, a mode of operation is needed to encrypt data with block ciphers. In 2015, ransomware used two classic modes: ECB mode and CBC mode introduced in 1.2.3.3. The weakness of ECB chaining mode can be exploited to retrieve data even if a ransomware encrypted them. On the other hand, CBC exploitation involves more processing.

Ransomware using ECB mode

The ECB mode has a big drawback. Identical plaintext blocks are encrypted into identical ciphertext blocks; thus, it does not correctly hide data patterns. The figure 2.3 illustrates this problem. With such a mode, a replay attack [START_REF] Syverson | A taxonomy of replay attacks [cryptographic protocols[END_REF] is possible. The main idea of our protection is to use the disadvantage of ECB mode to protect our data against ransomware. For this purpose, our protection consists in a smart data encoding. The first step is to expand the data. Each byte of data is padded with 0 bytes to have block size n. In the case of the AES, n = 16. So a data file M of size ν bytes, such as:

M = M 0 , M 1 , • • • M ν ;
is transformed in an expanded data file such as:

M expanded = M 0 | 0 • • • 0 n-1 |M 1 0 • • • 0 n-1 • • • M ν | 0 • • • 0 n-1 . (2.1)
Additionally a dictionary is created:

dictionary = 0| 0 • • • 0 n-1 1| 0 • • • 0 n-1 255| 0 • • • 0 n-1
If ransomware uses the same key to encrypt all files, it also encrypts the dictionary file. The user can retrieve all files thanks to it by matching the encrypted blocks of a file with the encrypted blocks of the dictionary for which the unencrypted values are known.

If ransomware uses a different key for each file, the dictionary can be created at the beginning of each file. So a file M is expended in " dictionary+M expended ":

dictionary + M expanded = 0| 0 • • • 0 n-1 1| 0 • • • 0 n-1 255| 0 • • • 0 n-1 M 0 | 0 • • • 0 n-1 M 1 | 0 • • • 0 n-1 • • • M ν | 0 • • • 0 n-1 .
Another solution of defence is to use the entropy of the original file. If M is a text, it can be supposed that the user knows the language used. In this case, no dictionary is necessary, text files are just expended (2.1) and the entropy is used to retrieve data with a classic basic cryptanalysis. Usually the file name is not encrypted, so the entropy could be stored in the file name to avoid the use of a dictionary.

Ransomware using CBC mode

If a ransomware program uses a block cipher in CBC mode, the solution described in 2.3.2.1 fails, because of the xor at the start of block encryption. This paragraph presents a more complex protection for this mode, working if the ransomware encrypts newly created file with the same key as the file you want to retrieve. The data files are expended exactly as in (2.1); but the construction of the dictionary is different. The user does not create a dictionary file, but 256 files dictionary 0 B , one for each possible value of byte B ∈ [[0, 255]] such as:

dictionary 0 B = (B| 0 • • • 0 n-1
).

The ransomware encrypts all data files and the 256 dictionaries. At this step, the user can retrieve the first and only the first byte M 0 of each encrypted files. Then they can create new dictionaries, one for each encrypted file and for each possible value of byte B ∈ [[0, 255]] such as:

dictionary i B = (B| 0 • • • 0 n-1 ) ⊕ C 0 .
Then the ransomware encrypts the new dictionaries. At this step the user can retrieve all second bytes M 1 of the files. So the user can retrieve all bytes M i by recurrence in the dictionaries byte:

dictionary i+1 B = (B| 0 • • • 0 n-1 ) ⊕ C i .
The main problem to these countermeasures is the sizes of the files which significantly increase. The data size is multiplied by n. In our description, the size of dictionary elements is fixed to one byte. In practice, it can be any other size. The bigger the size element is, the bigger the dictionary and the file sizes. In future works, it would be interesting to optimize these sizes. It is important to specify that the countermeasure against CBC mode is limited to a ransomware program which:

® always uses the same key K and the same vector IV , ® encrypts all newly created files.

Obviously another limitation is the fact that some ransomware use other modes such as GCM.

Statistical Tools

Ransomware involves a large number of ciphertext going through the file system; to detect such behaviour, statistical tests can be used. The main idea is that ciphertexts content distribution should be hardly distinguishable from a sequence of independent and identically distributed (IID) uniform random values. In this context many statistical tools are used to detect encrypted data, which are similar to random data.

One sample goodness of fit test measures how close an information source is to a theoretical probability distribution function, also known as the "model". In practice, one data set is seen as a distribution X in the set X. This distribution X is compared to a known distribution function F . Then we disprove or not the null hypothesis:

H0 : ∀x ∈ X, x = F (x). (2.2)
It does not prove that both data sets come from the same distribution, but rather that there is no significant difference between them. The objective is to figure out which indicators of compromise are the most relevant to detect ransomware attacks in real time.

The common statistical tool to detect random data is the Shannon entropy denoted by H. It is a measure of the uncertainty of a random variable. Let X be a random variable, the entropy H is:

H(X) = - x∈X P(X = x) • log 2 (P(X = x)).
(2.3)

For uniform data, H is maximal. For example, if X is a uniform random distribution of bytes, then H(X) = 8.

Authors of the publications [START_REF] Scaife | CryptoLock (and Drop It): Stopping Ransomware Attacks on User Data[END_REF][START_REF] Kharraz | UNVEIL: A Large-Scale, Automated Approach to Detecting Ransomware[END_REF] use Shannon entropy to detect ransomware encryption activity. The main difficulty is that a lot of data are required to estimate Shannon entropy. However, in the case of ransomware detection, it is important to detect infection with as few bits as possible. In this context we have been suggested two other tools:

® the χ 2 test to replace Shannon entropy (2.3), in the section 2.3.3.1;

® Markov chains in the specific case of header files distribution, in the section 2.3.3.2.

χ 2 test [3]

This paragraph presents a protection against crypto-ransomware, published in [3].

A statistical hypothesis test is a method of statistical inference used to decide whether the data at hand sufficiently support a particular hypothesis. The χ 2 test is a statistical hypothesis test. The test is valid when the test statistic is chi-squared distributed under the null hypothesis (2.2). It is a test of distributional accuracy, it measures how closely a set of numbers follows a particular distribution. It is a non-parametric statistical test, meaning that no assumption is made on the sampled distribution.

The observed sequence of data consists of bytes. So it is discrete and arranged in a frequency histogram [[0; 255]] with the degree of freedom equal to 255 (i.e, number of possible outcomes minus one). Suppose that Γ B is the number of hits observed for the byte B, and γ B is the expected number according to a known distribution function F . The formula for calculating the one-sided χ 2 test is:

χ 2 = 255 B=0 (Γ B -γ B ) 2 γ B .
A large value indicates that the null hypothesis is not likely verified, the Γ B is not drawn from the known distribution. The significance level of the test is the probability of rejecting the null hypothesis when it is true. Traditionally, experimenters have used the 0.05 level (e.g, biology), thus we choose the same. The observed test is compared to a boundary value, called the critical value, uniquely determined by the degree of freedom (or equivalently the size of the alphabet) and the desired significance level. If the χ 2 result is more extreme than the critical value [START_REF]Gnu octave: Scientific programming language[END_REF], the null hypothesis is rejected.

Another problem on the statistical level is that we want to distinguish malign activity from normal behaviour. But if we have a clear statistical model for malign activity, namely random data, we do not have its counterpart for normal behaviour. In this situation, the use of classical χ 2 test is awkward, to say the least, since they are meant to detect improbable events under the hypothesis that the stream of data is random where we actually want to single out improbable events in the case that the stream of data is a normal structured file. This makes it impossible to carry out a precise analysis of the efficiency of the statistical hypothesis tests that using for the detection of ransomware and to design most efficient tests.

In conclusion, this solution is based on the χ 2 test which measures the frequency distribution. This detector is particularly well suited to detect a file encryption. In our experiments 99, 37% of ransomware programs have been detected. But it is unable to distinguish an authorized encryption tool, as for example OpenPGP, or compressor, as for example WinZip, from a ransomware, thus generating false positive (FP).

Markov Chain [4]

This paragraph presents a protection against crypto ransomware, I published in [4] realized with Nicolas Bailluet, a student of Rennes 1 University and David Lubicz from DGA-MI.

This work introduces another statistical tool, to detect ransomware based on their encryption behaviour. The main idea is the fact that the header files are very structured data. When a ransomware encrypts a header the structure is changed. To deal with the few data of header files, another statistical tool is used: the binary Markov chain.

Definition

A binary Markov chain X is a sequence (X j ) j≥0 of random variables defined by the following data:

® a memory m, that corresponds to the number of bits saved in a state X i .

® a transition matrix T such that:

T (x, y) = P(X i = x|X i-1 = y);

® an initial state X 0 which is a random variable.

X(m, T , X 0 ) denotes the Markov chain with memory m, transition matrix and initial state X 0 .

X i = y|X i-1 = x).

Training the Model

The main idea is to intercept write requests, then decide if a sample corresponds to a benign or a malicious write request. To do so, in a learning phase, statistical models of structured file headers are built using Markov chains.

A Markov chain of memory m is used, with the first n bits of each file.

® Let L n be the list of the first n-bit sequences of each file in the corpus.

® Let S be the set of the possible successor s.

® Let X(m, T , X 0 ) be the Markov chain which represents the best statistical approximation of the sample L n .

® Let s be a successor of L n defined in S m .

To define this Markov chain X(m, T , X 0 ), it is needed to compute T (s) and P(X 0 = s), ∀s ∈ S m .

® ∀s ∈ S m+1 , let o Ln (s) be the occurrence count of s in every sequence of L n .

® ∀s ∈ S m , let o Ln,0 (s) be the number of sequences in L n such that s is the m first bits.

|L n | denotes the size of the list L n , i.e the number of files. Finally, let

|L n |(ν) = (n -ν) • |L n | be the number of sequences of bits of length ν in L n .
Thus ∀s ∈ S m+1 there is:

T (s) = o Ln (s) |L n |(m + 1)
;

and ∀s ∈ S m :

P(X 0 = s) = o Ln,0 (s) |L n | .
On the other hand, let X En (m, T En , X En 0 ) be the Markov chain with memory m which represents the best statistical approximation of an encrypted file. As the statistical behaviour, the encrypted file is indistinguishable from the one of a perfectly random sequence. Thus ∀s ∈ S m+1 there is:

T En (s) = 1 2 m+1 ;
and ∀s ∈ S m :

P(X En 0 = s) = 1 2 m .

Testing Samples against models

Then in a detection phase, a maximum likelihood test is used to decide if a sample provided by a write request is normal or malicious.

Let X(m, T , X 0 ) and X En (m, T En , X En 0 ) be two Markov chains. The first is a model of a normal header file, the second represents encrypted data. Let s ∈ S n be a sample header. The goal is to decide which of the two trained models is the more likely to match s. For this, the likelihood ratio test is used.

Let s ∈ S ν be a sample, the likelihood ratio Λ of s with respect to the two Markov chains, is defined as:

Λ(s, X(ν), X En (ν)) = P (X(ν) = s) P (X En (ν) = s) .
The likelihood ratio test then is defined by:

1 if Λ(s, X(ν), X En (ν)) > α 0 otherwise .
Here α is a constant that allows setting the significance level of the test.

The Neyman-Pearson lemma [START_REF] Huber | Minimax tests and the neyman-pearson lemma for capacities[END_REF] states that this likelihood-ratio test is the most powerful test for a given significance level.

Results and limitations

To test the trained models against randomness, we have created for each format a corpus half composed of randomly generated files and half composed of files that match the format and were not in the original training corpus. We have used the likelihood ratio test with the constant α = 1. The test is positive if it says that the sample corresponds to a structured header and negative if it says that the sample is random.

Our countermeasure based on Markov Chains to detect ransomware is able to distinguish the structured files from random data. This approach is applicable to real-world cases by successfully distinguish structured files from files encrypted with known ransomware whose encryption schemes fit into our models. For the experiments, we have trained multiple models on different file formats: jpg, gif, msoffice and pdf. The success rate is of 100% with encrypted data by us. But this solution cannot detect a ransomware which does not encrypt the headers of files.

It is a low cost in terms of computing. It can detect ransomware with only a few processed bits. Optimal results are with a memory m = 16 bits and a size n = 512 bits. Moreover, the Markov chain models have a low computing cost. So they can be deployed in the kernel to stop malicious processes without slowing down too much the computer. This countermeasure is not enough on its own. But it's a pertinent additional tool to complete other implemented countermeasures against ransomware. In the fight against ransomware, the more indicators we have, the better is the detection.

Distance to a model [5]

This work was realized with Yassine Lemmou a PhD sudent from the University Mohammed V at Rabat and Jean-Louis Lanet from INRIA, then published in [5]. It is an improvement of first countermeasures which detect an encryption. Indeed, the problem is how to distinguish an authorized encryption from a ransomware activity. In this work, the main idea is to use the memory snapshot as a string vector. The distance of a candidate software with a vector representing the allowed cryptographic software is measured. If the distance exceeds a threshold, the suspected process is flagged as a ransomware.

Memory snapshot

To be executed, an executable program must be located in memory. The aim of this work is to demonstrate that snapshots memory can be used to extract relevant information.

If a program is flagged as suspicious with previous indicators such as the χ 2 test presented in 2.3.3.1 or the Markov chain test on the header presented in 2.3.3.2, an analysis of the memory snapshot starts. More precisely, a driver transforms the memory snapshot into a binary vector v that marks the presence or the absence of specific strings. These specific strings rely on the allowed cryptographic tools. Then the vector v is confronted to a model vector v to discriminate a malicious or benign program.

When a memory snapshot is analysed, the first step consists in removing useless information from memory. A snapshot contains thousands of strings. Some of them are just noise (string with no semantics) as code sections or previously allocated but uncleaned memory. The first step consists in removing information that is useless for the detection. Two elements are of importance: the loaded DLLs and the name of the functions called. To keep only the strings with relevant meaning, a dictionary approach (white list) is used. It reduces the number of strings by one order of magnitude keeping only relevant information. An efficient hash map structure is used for the dictionary. At that step, the strings are only valid strings. The vector v is built counting their raw value in the memory. v represents a software in two parts: the DLLs section and the function names section. The DLLs part is of a fixed length. It corresponds to all the allowed software encountered at that time. Only a valuable part of the strings is selected.

term frequency-inverse document frequency (TF-IDF)

To compare the vectors dynamically, it is required to normalize its size. For that purpose, information retrieval techniques are applied to select a subset of the strings in the vector. The set of strings of a vector can now be considered as a document and the set of valid applications as a collection of documents. The term frequency-inverse document frequency (TF-IDF) is used to choose the relevant strings to be kept in the vector. The value associated to each term has the following explanation:

® highest when the term occurs many times within a small number of documents leading to a high discriminating power;

® lower when the term occurs fewer times in a document, or occurs in many documents;

® is the lowest when the term occurs in almost all documents.

Distance to the model

In this paragraph, the distance between a candidate vector v (the suspicious one) and the model v is evaluated. The vector v can be seen has the distribution of the strings in the memory. Various distance/similarity measures are available in the literature to compare two data distributions.

To measure the divergence, two metrics are tested, the Euclidean and the cosine distances. The Euclidean distance (2.4) between each element of the candidate vector v and the model v is used, assuming n being the size of both the vectors.

distance

Euclidean (v, v) = n i=1 (v i -v i ) 2 . (2.4)
It is the ordinary distance between two points. The cosine distance(2.5) is used too. Even if at the end only one metric will remain in the driver.

distance cosine (v, v) = v • v ||v|| • ||v|| = n i=1 v i • v i n i=1 v 2 i • n i=1 v 2 i (2.5)

Results and other utilization

This solution is an improvement of previous solution to reduce FP. Indeed our previous solution detects the encryption. This approach reduces by 100% the FP generated by the χ 2 test solution, presented in 2.3.3.1.

An other utilization of the analysis of memory snapshot is possible in the case of ransomware. More precisely, ransomware writes a ransom note for the user. So specific terms and strings can be retrieved in the memory snapshot.

Other protection mechanisms

Even if stopping encryption is the main subject, this section presents other countermeasures to stop ransomware. These solutions are not all specific to ransomware infection. Moreover they are not focusing on the encryption step. That is why these solutions are less detailed.

File system traversal behaviour [6]

This section summarizes a ransomware detection technique that serves as an intrusion detection system (IDS), developed by my two PhD students Routa Moussalieb and Aurélien Palisse and published in [START_REF] Moussaileb | Ransomware's early mitigation mechanisms[END_REF].

This work is more a classification of crypto-ransomware, than a practical detection tool. It focuses on the file system exploration, before the attack (encryption) takes place. Indeed, once it is unpacked, the ransomware payload goal is to explore the file system to find files to encrypt. This search is done from the root of the file system or directly from the user's folder with a depth-first or a breadth-first search. As for the exploration phase, threads that traverse the file system behave similarly and predictably, enabling the possibility of an early detection of the ransomware and deducing its family.

Monitoring

Our solution detects ransomware behaviour based only on monitoring file system traversal. Each ransomware's file system traversal can be compared to others in order to know if they belong to the same family, or if they share some code regarding the paths exploration. We have concluded that the majority of ransomware start their encryption process from the root of the hard disk. To get a precise ransomware's classification, classical supervised machine learning techniques are used :

® K nearest neighbour [86],
® decision tree [START_REF] Safavian | A survey of decision tree classifier methodology[END_REF],

® random forest [START_REF] Ho | Random decision forests[END_REF].

Another behavioural property is additionally investigated, the execution time (the velocity of the file traversal) of a family. Indeed, the samples issued from the same families have similar patterns. Each payload can be packed or obfuscated individually, but the system impact remains the same for a particular family with the exception of new versions, as seen in Figure 2.5. To each ransomware program, it is possible to obtain a signature of the file system's traversal and its velocity.

Limitations

Any software that mimics the behaviour of ransomware's traversal is classified as malicious so our proposal raises false positives in this case. Another limitation occurs when no file system traversal is done prior to encryption.

Ransomware network traffic analysis [7]

This section presents results developed in Routa Moussalieb's thesis and published at [START_REF] Moussaileb | Ransomware Network Traffic Analysis for Pre-Encryption Alert[END_REF]. The main idea is to reconstruct ransomware's full activity to check if its network communication is distinguishable from benign network traffic.

In this work, ransomware is detected by the network traffic. Multiple malware samples have been executed. The infection mechanisms such as spam email to detect ransomware download process before its installation on the victim's computer is examined. It results of this work that the majority of ransomware behave similarly and not in a very specific manner of this malware family. Common patterns are found among various families. To get a precise ransomware detection, machine learning techniques are used. To sum up, network alerts represent a first suspicion means informing the user of the presence of potential ransomware. However, some drawbacks exist. This first alarm can take place after the creation of encrypted files or ransom notes as we noticed with some families. In addition, few elements are needed for a classification, we have under-fitting problems (Zerber samples), prone to adversarial attacks. Besides, only decision trees [START_REF] Safavian | A survey of decision tree classifier methodology[END_REF] among the tested algorithms provided high detection rates for zero-day attacks. For all the reasons mentioned before, network alerts should be backed up with system data to provide a general detection mechanism, working on all types of ransomware.

As for our future work, we will gather additional information from the file system to present a multi-layer alert strategy to detect ransomware payload as early as possible.

Experimentations

Malware-O-Matic

During the PhD of Aurélien Palisse [3,[START_REF] Palisse | Analyse et détection de logiciels de rançon[END_REF] with the help of a Master student Antoine Durand, the platform MoM has been designed and built into the LHS.

MoM is an automated malware analysis platform that does not use virtual machines, while keeping all the main features of a regular analysis framework. This fully bare-metal platform is built on top of two open-source software, Clonezilla [START_REF] Clonezilla | The free and open source software for disk imaging and cloning[END_REF] and Viper [START_REF] Viper | Binary management and analysis framework[END_REF], which makes the experiments reproducible. The platform is made of a single master server and several slaves, each one running the analysis loop in parallel. The whole system is on a dedicated network under the supervision of the network autonomous system and directly connected to the Internet, without using the institute intranet,to emulate a typical home network.

The loop itself consists of a few simple steps:

® setup of the monitoring environment, ® malware execution, ® results gathering and storage;

® clean-up.

MoM is able to analyse up to 360 malware programs per-day with only 1 server and 5 slaves. The end goal of this platform is to run uninterruptedly and thus automate the analysis of malware samples.

MoM can be used in two distinct modes for the experiments: "passive" or "active". In passive mode she only observes behaviour of ransomware. Ransomware has a short time life. So the passive mode of MoM is used to test if a ransomware program is always active The second mode evaluates ransomware countermeasures, especially countermeasures against malicious encryption.

Data Aware Defence

Data aware defence (DaD) is the piece of software to evaluate the in-house countermeasures on real ransomware samples. So DaD is an important part of MoM. Countermeasure developed in DaD can detect and block in real time most of the ransomware in the collection.

Similarly to approaches [START_REF] Continella | Shieldfs: a self-healing, ransomware-aware filesystem[END_REF][START_REF] Kharaz | {UNVEIL}: A large-scale, automated approach to detecting ransomware[END_REF][START_REF] Kharraz | Cutting the gordian knot: A look under the hood of ransomware attacks[END_REF][START_REF] Scaife | Cryptolock (and drop it): stopping ransomware attacks on user data[END_REF] reporting satisfying detection rates, DaD monitors file system activity. An important part of this contribution is the usability of the solution; furthermore, it can be used against zero-day ransomware.

File System Activity Monitoring

Windows, as most modern operating systems, splits its memory in several regions with different privilege requirements. The kernel mode (ring 0) has a high privilege level and is responsible, among other things, for managing disk operations.

Standard applications run in userland (ring 3), they are much less privileged and cannot perform disk operations directly. Instead they call the corresponding service from the Windows kernel, let the kernel manage the privileged operations, before safely returning in the userland application code. This separation ensures that no userland code directly manages critical operations in the system. To complete this security feature, the 64-bit versions of the operating system (OS) requires all kernel mode code to be signed by Microsoft to be accepted.

Up to now, to the best of our knowledge most ransomware lives in userland. That is why a countermeasure in kernel space cannot be tampered with by malicious code and is fully transparent. Users' interactions with files are ultimately mapped to operations in the kernel. On top of this stack stand the input/output (I/O) manager and at the bottom, the file system driver (ntfs.sys). Microsoft offers a file system drivers framework [START_REF]Microsoft: File system minifilter drivers[END_REF] that allows third-party developers to add functionalities between the two previous layers. Such component is called a file system minifilter driver and it is managed by the filter manager. The position of each minifilter driver in the I/O stack is defined by its "altitude". A minifilter driver that performs full disk encryption is below an anti-virus filter and thus avoid false positive detection of ransomware-like behaviour. A minifilter driver can inspect all the operations that target the disks, regardless of whether the requested operation is an I/O request packet or a fast I/O. In this context DaD is able to monitor write, read operations and so on. However a clever usage of such functionalities has to be done, otherwise a significant performance penalty occurs [START_REF] Scaife | Cryptolock (and drop it): stopping ransomware attacks on user data[END_REF] and the solution cannot be deployed in the real world. Our file system minifilter driver has been extensively tested on Windows 7 and 10, for the 32 and 64-bit versions and follows the Windows Driver Model.

Implementation Design

The Figure 2.6 represents the DaD simplified architecture. In order to catch malicious behaviours efficiently, the monitoring is restricted to write and information operations. The goal is to demonstrate that detecting ransomware behaviours with only two hooks on the I/O requests is possible. The so-called information operations allow changing various information about a file object, create a hard link, change the file position or the file name. The information operations are blocked once a thread is marked as malicious to prevent aggressive files renaming. But without malicious activity, the information operations are always accepted and are not used to construct the compromise indicators. For each intercepted write operation, the time spent in the callback function is minimized by collecting only the essential information. Only the content of the buffer is interesting. It is passed through the file system stack, its size, offset, the corresponding absolute file name, process name, process id and thread id. This information is then copied to non-paged memory and passed over to a new dedicated thread that is not part of the file system stack. Only the indispensable data is copied, not the thread context coming from the operation. As a consequence, write operations are immediately authorized to go through. So far, we were the first to inspect the I/O operations with a thread granularity. It is a significant improvement in case of malicious code injection into a benign process.

All costly computations are deferred to threads running at the lowest kernel priority level. This model solves the time restriction for the statistical computations and the synchronization deadlocks on shared resources.

Indicators of compromise

Results

Many ransomware programs have a short life. As a result, it is very difficult to compare different countermeasures between them. Indeed it is impossible to keep the same samples over time.

However, the Table 2.2 summaries all results of our different proposed countermeasures. More precisely, it lists all ransomware tested and stopped or not by the different works. It gives the success rate, i.e. the percentage of ransomware tested and detected.

Often for one ransomware, there are different versions. That explains why, for example, the χ 2 test stopped some Xorist and not all Xorist.

The solution which uses Markov chain is different. The ransomware are stopped on specific files (pdf,msoffice andjpeg) and not for other specific files(gif).

An interesting result can be to combine them.

Conclusion

Ransomware continues to be a real threat. Today all systems are targeted. More than ever, it is important to follow ANSSI recommendations to keep computers safe.

To detect new ransomware, I have worked on different countermeasures targeting specific behaviour. Some are more efficient than others. These solutions are not perfect and I can imagine undetectable ransomware would avoid all of them.

® First, undetectable ransomware can have a wait a long time before exhibiting its malicious behaviour. In this way, MoM or other test platforms cannot study it, and they class ransomware as non-active.

® The file system traversal is random and slow and not systematic. In practice, encrypting only a few but important documents are pertinent damage and ransomware has less chance to be detected by its activities. New malware as doxware and ransomware yet do it this way. A possible countermeasure is to add honey pot files in the system. These honey pots have to be created at different moments, opened periodically, and contains pertinent key words. In other words, a good honey pot has to be undetectable by a performant malware.

® With an undetectable ransomware, the encryption is not detected. First the encryption should not impact the header. Crypto-ransomware gives the entropy of files starts as in [START_REF] Genç | Nocry: No more secure encryption keys for cryptographic ransomware[END_REF]. For example, cryptosystem based on Hilbert matrix can be used. In this case all statistical tools to detect pseudo-random written data fail to detect the ransomware sample.

® The message for the ransom can be replaced by a picture. So no specific string appears in the memory snapshot.

In conclusion, there are many works to have a perfect protection against ransomware. The battle is not finished, it is just beginning.

Chapter 3

Blind side channel cryptanalysis "I have never tried that before, so I think I should definitely be able to do that."

Fifi Brindacier d'Astrid Lindgren.

Introduction

Today, IoT connects everyone and everything. This fact leads to an omnipresence of embedded systems in our life. The deployment of these circuits is a real cybersecurity issue, since one of the possible threats on such embedded systems are physical attacks, when the attacker is capable of grabbing the devices and bring them home. An attacker with access to the circuit can perform physical attacks. Physical attacks rely on the interaction of the computing unit with the physical environment. They are mainly divided in two families: side channel analysis (SCA) and fault injection attack (FIA). This chapter is focused on the first family: SCA.

Motivation

NIST has standardized lightweight cryptographic algorithms that are suitable for use in constrained environments where the performance of previous NIST cryptographic standards is not acceptable. So many new AEAD algorithms have been candidates in this NIST competition [START_REF]Lightweight Cryptography Standardization Process[END_REF]. Many attacks already exist on older symmetric cryptography algorithms like AES. Since the AEAD algorithms are relatively new, there are far fewer attacks against them [START_REF] Berti | A finer-grain analysis of the leakage (non) resilience of ocb[END_REF][START_REF] Sim | Differential analysis aided power attack on (non-) linear feedback shift registers[END_REF][START_REF] Adomnicai | Practical algebraic side-channel attacks against acorn[END_REF][START_REF] Banciu | Exploring the resilience of some lightweight ciphers against profiled single trace attacks[END_REF]. Moreover, these new algorithms are designed to be more resistant to physical attacks than AES. Therefore, one motivation is to test the resistance of these new algorithms against SCA.

Generally, the SCA as in [START_REF] Kocher | Differential Power Analysis[END_REF][START_REF] Brier | Correlation Power Analysis with a Leakage Model[END_REF] links known data with a measurement. In the case of symmetric cryptographic algorithm, this induces that the attack is often on the first or last round. The framework, described in my thesis [START_REF] Bouder | Un formalisme unifiant les attaques physiques sur circuits cryptographiques et son exploitation afin de comparer et rechercher de nouvelles attaques[END_REF] and published [START_REF] Bouder | A Unified Formalism for Physical Attacks[END_REF], suggests that other kinds of attack paths are possible. Another approach in the SCA domain is template attacks [START_REF] Chari | Template attacks[END_REF][START_REF] Archambeau | Template attacks in principal subspaces[END_REF] which compare traces from the targeted device with traces of a profiling device.

In this chapter, the main motivation is to build an attack which uses only traces, no text and no profiling. We are in the case of an attacker who can just observe a leakage but has no access to the device's input/output, hence the name of BSCA. One first idea is to construct an attack path that links one leakage measurement with another one.

One has to remark that retrieving the key without the ciphertext in BSCA may seem absurd in the context of confidentiality. However, in the context of integrity, an attacker could forge a tag for their message after obtaining the secret key.

The dual idea of BSCA in a blind side channel analysis for reverse engineering (BSCARE) context is the ability to recreate a correct output with zero prior knowledge of the algorithm. Only traces, inputs and outputs are used.

Contributions

The main idea of BSCA was initiated during my PhD, under the supervision of my advisor Yanis Linge [START_REF] Linge | Using the joint distributions of a cryptographic function in side channel analysis[END_REF]. Subsequently, the first attack that was developed targeted AES. It represents a chapter of my thesis and has been finally published during my post-doctorate at INRIA [START_REF] Bouder | A multi-round side channel attack on aes using belief propagation[END_REF].

Today I continue to work on this domain. I have obtained funding for a thesis through the APCIL project, thanks to the support of the Brittany region. APCIL focuses on BSCA applied to AEAD. The PhD student working on this project is Modou Sarry, under the direction of Laurent Toutain from OCIF and I co-advise with Gaël Thomas from DGA-MI. Over the past few years, we have hosted two internships on this subject: Awaleh Houssein Meraneh in 2020, and Eïd Maalouf in 2021.

Two new attacks are implemented in simulations [START_REF] Sarry | Blind Side Channel Analysis against AEAD with a Belief Propagation Approach[END_REF] on two AEAD: Elephant [START_REF] Beyne | Dumbo, jumbo, and delirium: Parallel authenticated encryption for the lightweight circus[END_REF] and Sparkle [START_REF] Beierle | Schwaemm and esch: lightweight authenticated encryption and hashing using the sparkle permutation family[END_REF]. An analysis of this algorithm, in this specific context, is shown.

With Ronan Lashermes at INRIA, we have implemented the first blind side channel analysis for reverse engineering (BSCARE). Our works target symmetric encryption and MAC.

Organization

In the first section 3.2, a short state of the art of SCA and side channel analysis for reverse engineering (SCARE) are presented. BSCA against AEAD are developed in section 3.3. BSCARE is presented in section 3.4. Finally, the conclusion is drawn in section 3.5.

Context and sate of the art for side channel analysis (SCA)

The side channel analysis (SCA) are based on observations of the circuit behaviour during the computation. SCA exploits the fact that some physical values of a circuit depend on intermediary values of the computation. This is the so-called leakage of information of the circuit.

Different leakages are possible, different exploitations of these leakages exist. This section summarizes the main different ideas. The domain is very large, as given evidence by the different books [START_REF] Mangard | Power analysis attacks: Revealing the secrets of smart cards[END_REF][START_REF] Ouladj | Side-Channel Analysis of Embedded Systems[END_REF]. So this section is not a detailed state of the art, it introduces what is needed for the chapter. Different leakages are presented in 3.2.1. Different attack families are summarized in 3.2.2. Although countermeasures are not the primary subject of this chapter, a selection of classical countermeasures is presented in section 3.2.3.

Leakage

Different kinds of leakage can be exploited. Only the most useful leakages are introduced.

Timing

The concept of timing attack has been introduced by Kocher [START_REF] Kocher | Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS and Other Systems[END_REF] in 1996. It consists in measuring the execution time of an algorithm. For example, during a conditional branch, two different branches of the code can be called:

® a branch of code that corresponds to the case where the condition is verified; ® a branch of code that corresponds to the case where the condition is not verified.

These two branches of the code may present differences in execution time. An attacker who measures the execution time can deduce whether the condition is verified or not.

Power consumption

The idea is to connect directly to the circuit to measure its power consumption [START_REF] Kocher | Differential Power Analysis[END_REF][START_REF] Brier | Correlation Power Analysis with a Leakage Model[END_REF]. An electric current is a movement of electric charges. Each instruction executed by a circuit involves the operation of a certain number of transistors. At any moment, the measurement of the current, known as power consumption, reflects the activity of the circuit. Logic gates combine to form a circuit. The power consumption of the device is the sum of the current consumption of each of its logic gates. We have the possibility of distinguishing a transition from 0 to 1 from a transition from 1 to 0. On the other hand, certain operations which are more expensive increase the power consumption of the circuit, in particular because of the use of more components.

Electromagnetic (EM) emission

Principle

The electromagnetic (EM) emission from a circuit is caused by the flow of the current within it. This circulation of charges in the conductor produces an electromagnetic field composed of a magnetic field and an electric field, mathematically linked by Maxwell's equations. These electromagnetic waves propagate in space and thus can be picked up by a probe. The probe should generally be positioned as close as possible to the active surface of the circuit.

The best advantage of electromagnetic (EM) analyses over power consumption analyses is that the measurements are taken locally. Another advantage is that these attacks are non-invasive. Even better, since the circuit can't easily detect that it's being watched because there is no plugging or even need for physical contact. However, EM measurements are often more sensitive to noise and are very dependent on the positioning of the probe. Power consumption and EM emissions are closely related, so they are often modelled and used very similarly.

EMA [8]

When I was in postdoc at LHS of INRIA, I worked on setting up a side channel platform called EMA. EMA test bench includes the following devices:

® a Langer PA 303 preamplifier (3GHz bandwidth) to amplify the signal from the probe; ® a DSOS404A oscilloscope from Keysight with a 4GHz bandwidth able to capture up to 20G samples per second;

® a control computer is used to orchestrate the measurements and perform the analysis with home-made tools.

The Figure 3.1 represents a platform to measure the EM emission of a device. This platform used and fully described in [START_REF] Bukasa | How trustzone could be bypassed: Side-channel attacks on a modern system-on-chip[END_REF], is owned by INRIA.

Different kinds of attacks

Even if many different leakages exist, in the following only power consumption and EM are considered. A power consumption or EM leakage is a physical function. As illustrated in the previous paragraphs, to exploit these leakage, the attacks can be split in three families.

® The attacks that extract information directly from the measurement 3.2.2.1.

® The attacks that profile the leakage 3.2.2.2.

® The attacks that use a mathematical model 3.2.2.3.

Simple power analysis (SPA)

The simple power analysis (SPA) [START_REF] Messerges | Power analysis attacks of modular exponentiation in smartcards[END_REF][START_REF] Mangard | A simple power-analysis (spa) attack on implementations of the aes key expansion[END_REF][START_REF] Clavier | Universal exponentiation algorithm a first step towards provable spa-resistance[END_REF] is called simple because they determine directly, from an observation of the leakage, during a normal execution of an algorithm, information on the calculation performed or the data manipulated.

Profiling attack

Principle Profiling attacks

work by learning about the device's behaviour. To implement a profiling attack, a pair of identical devices is needed. One is called the profiling device, the attacker has full control of it; the other is the targeted device. These attacks are in two phases.

1. The first step, called profiling or learning phase, is to build a physical model as EM traces for all possible target values with the profiling device.

Template attacks were the first statistical characterizations for side channels. They were introduced as the strongest side channel attacks possible from an information theoretical point of view [START_REF] Chari | Template attacks[END_REF]. They have been used in many attacks, such as [START_REF] Chari | Template attacks[END_REF][START_REF] Archambeau | Template attacks in principal subspaces[END_REF][START_REF] Rechberger | Practical template attacks[END_REF][START_REF] Elaabid | Template Attacks with a Power Model[END_REF][START_REF] Oswald | Template attacks on maskingresistance is futile[END_REF][START_REF] Choudary | Efficient template attacks[END_REF][START_REF] Loiseau | Template Attacks against ECC: practical implementation against Curve25519[END_REF] since. More generally, profiling attacks use machine learning method [START_REF] Jovic | Traditional machine learning methods for sidechannel analysis[END_REF][START_REF] Lerman | Side channel attack: an approach based on machine learning[END_REF][START_REF] Hospodar | Machine learning in side-channel analysis: a first study[END_REF][START_REF] Genevey-Metat | Train or adapt a deeply learned profile?[END_REF][START_REF] Li | A comparison of weight initializers in deep learning-based side-channel analysis[END_REF][START_REF] Wu | The best of two worlds: Deep learning-assisted template attack[END_REF].

An example of template attack against PIN code [9]

I worked to realize a template attack in the case of a personal identification number (PIN) code [START_REF] Bouder | A template attack against VERIFY PIN algorithms[END_REF] during my postdoc at Inria. With Jean-Louis Lanet, Ronan Lashermes, Thierno Barry and Damien Couroussé, we have presented the first SCA attack with EM traces of a naïve Verify PIN algorithm. It is an application of template attacks to a situation where very few traces are available.

Attack description

In this attack, it is assumed that the attacker has the same device as the targeted device, where correct PIN is known. They can obtain all the desired measurements on the profiling device, only a valid candidate PIN is proposed after every other candidate PIN. Namely they can:

® obtain one trace on the targeted device;

® change the correct PIN in the profiling device;

® obtain many traces on the profiling device.

In this way, it is possible to build a template attack on Verify PIN algorithms.

The attack is divided in two parts and six steps. The profiling phase is split into:

1. Campaign on the profiling device,

Detection of the points of interest,

3. Building templates.

The attack phase is split into:

4. Campaign on the targeted device,

5.

Confrontation between measurements,

Discrimination of one guess.

Experimentation Once the theoretical framework has been setup, an experimental benchmark has been performed. The Verify PIN algorithm is implemented on an ARM-based STM32-F100RB microcontroller embedding a Cortex-M3 core and running in our case at 24MHz. The board used is the STM32VLdicovery. This chip does not embed any countermeasures against side channels but it is a popular choice for IoT applications.

The experimental bench is composed of a control computer, a 3405A Picoscope and an EM probe from Langer (RF-R0,3-3) is used to measure the signal. This last one is amplified by a preamplifier from Langer (PA 303), before the measurements of the Picoscope 3405A (an USB oscilloscope). The bandwidth of the measurement setup is limited by the Picoscope with an upper frequency of 100MHz. The traces obtained are composed of 3700 points, with a 1GS/s sampling rate. We remind that 100MHz is a cutoff frequency marking an attenuation of the relevant signal, not its total removal.

One has to remark that the required equipment comes at a very low cost, under 2000 euros excluding the computer.

Results

We have shown that we can always retrieve a PIN code with 8 traces (9 trials), whatever the number of bytes in the PIN code. For a classical PIN code with 4 bytes in a Verify PIN with 3 trials, our attack has a success rate of 48.38% per byte, so finally 5.48% for the whole PIN. For a classical PIN code with 4 bytes in a Verify PIN with 4 trials, our attack has a success rate of 60.88% per byte, so finally 13.74% for the whole PIN. These results are not optimal, but the experimental set-up used is very low cost; moreover the biggest template managed had a size of n = 400000 traces. We can imagine that an attacker with a better equipment (a high bandwidth oscilloscope and a better computation power to manage more than 400000 traces) can have better results.

An important remark is that the double comparison of the PIN code to protect against fault injection attacks introduces new vulnerabilities for side channel analysis.

By using templates, the attack is made portable. The attacker can perform the profiling phase ahead of time. Then on the target location, the measures and the analysis are fast, as only a few traces are required. Moreover, they can easily perform batch attacks where multiple targets are attacked with the same templates.

A countermeasure against our attack could be to compare the different bytes in a random order. The attacker can retrieve the PIN but not in the right order; so for example, for a PIN code with 4 bytes, with 4 different values, there are 4! = 24 possibilities. In most cases, this number of possibilities is too big to be authenticated before the device gets blocked.

Correlation with a model

Principle

The most commonly used attack is correlation power analysis (CPA) [START_REF] Brier | Correlation Power Analysis with a Leakage Model[END_REF]. This a family of SCA, which consists in applying a mathematical model to a physical leakage. The first attack of this family was the differential power analysis (DPA) [START_REF] Kocher | Differential Power Analysis[END_REF].

These attacks have a divide and conquer approach. The attacker splits the target into small parts such as bytes or bits for example, which they attack separately. The idea is that for each part, it is easy to enumerate all the guesses.

First, some measurements are acquired during computations that are linked with secrets. On the other hand, a mathematical model and guesses are used to build predictions. The most common models used are the Hamming weight (HW) and the Hamming distance (HD).

The last step consists of comparing the predictions to the traces with a statistical tool called distinguisher. This tool brings out a guess. If this guess really corresponds to the real value, the attack is a success. Many distinguishers exist. The choice of the distinguisher depends on the link between the physical function and the model. The mean difference [START_REF] Kocher | Differential Power Analysis[END_REF], the correlation [START_REF] Brier | Correlation Power Analysis with a Leakage Model[END_REF], entropy [START_REF] Lashermes | A DFA on AES Based on the Entropy of Error Distributions[END_REF], mutual information [START_REF] Gierlichs | Mutual information analysis[END_REF], the principal component [START_REF] Souissi | First Principal Components Analysis: A New Side Channel Distinguisher[END_REF], the linear discriminant [START_REF] Balakrishnama | Linear Discriminant Analysis -A Brief Tutorial[END_REF]...

Hamming weight (HW) model

The power consumption or EM leakages are usually correlated to the Hamming weight (HW) of the data. It is a classical model used in the domain of SCA.

One important advantage of using HW is that it rapidly reduces the number of guesses. For example, let B be a byte, so B can take 256 values in [[0, 255]]. With the HW of B, the attacker reduces the list of possible values, as shown in Table 3 Another model for the leakage is a HW with an additive Gaussian noise. For a given discrete random variable byte B, and its HW(B) ∈ [[0, 8]]; HW(B) denotes the continuous random variable representing the "measured" Hamming weight so called "noisy"; defined in R, such as:

HW(B) = HW(B) + σ B,t ; (3.1)
with σ B,t an event of the Gaussian random variable N 0, σ 2 at a time t. The probability density function F associated to N 0, σ 2 is given by:

F σ (B) = 1 σ • √ 2π • exp - 1 2 • B σ 2 . (3.2)

Birth of blind side channel analysis (BSCA) [10]

BSCA [10]

Blind side channel analysis (BSCA) is a type of SCA where some information that is usually known, is unknown. The main concept is to perform the attack solely based on leakage measurements. Often BSCA is based on a strong assumption: the attacker is supposed to retrieve a noisy HW from the leakage. Yanis Linge et.al have presented the first BSCA in [START_REF] Linge | Using the joint distributions of a cryptographic function in side channel analysis[END_REF]. The goal is to attack a block cipher AES without using the data as plaintext or ciphertext. At the same time, I had the same idea, and finally I published with him and other colleagues a first attack in [START_REF] Bouder | A multi-round side channel attack on aes using belief propagation[END_REF]. Then, our work has been improved by Christophe Clavier et al. in [START_REF] Clavier | Improved blind side-channel analysis by exploitation of joint distributions of leakages[END_REF]. Moreover this contribution introduces for the first time, the name of BSCA. Now it is a new family of SCA [START_REF] Clavier | Quadrivariate improved blind side-channel analysis on Boolean masked AES[END_REF][START_REF] Azouaoui | Blind Side-Channel SIFA[END_REF][START_REF] Yli-Mäyry | Diffusional side-channel leakage from unrolled lightweight block ciphers: A case study of power analysis on prince[END_REF]. BSCA has not yet been proven to be feasible in practice. Most of the research on BSCA has been conducted using simulation traces. However, these attacks can reveal vulnerabilities that are not typically studied in traditional cryptanalysis. So I see this new family of attack as a new tool to analyse symmetric cryptographic primitives.

Side channel analysis for reverse engineering (SCARE)

Side channel analysis for reverse engineering (SCARE) is a technique that uses side channels in order to gain information on the inner working of a procedure, mostly a symmetric cipher. It was first introduced by Novak [START_REF] Novak | Side-channel attack on substitution blocks[END_REF] and improved by Clavier [START_REF] Clavier | An improved SCARE cryptanalysis against a secret A3/A8 GSM algorithm[END_REF] where he uses side channels to recover a secret part of the A3/A8 algorithm. With this technique, it is possible to find confidential parts of an algorithm assuming the rest is known such as permutation tables for DES-like [START_REF] Daudigny | Scare of the des[END_REF] or S-Boxes of an AES-like [START_REF] Jap | Practical reverse engineering of secret sboxes by side-channel analysis[END_REF]. Previous works have shown that it is possible to apply SCARE to recover a part of a generic cryptographic structure: Feistel [START_REF] Réal | SCARE of an unknown hardware feistel implementation[END_REF], SPN [START_REF] Rivain | SCARE of secret ciphers with SPN structures[END_REF], stream ciphers [START_REF] Guilley | Defeating any secret cryptography with SCARE attacks[END_REF] have all been shown to be vulnerable to this technique. In [START_REF] Clavier | Complete reverse-engineering of AES-like block ciphers by SCARE and FIRE attacks[END_REF], Clavier et al. demonstrate the feasibility to recover a whole AES-like algorithm with SCARE.

Another direction of SCARE is the side-channel based disassemblers, to recover executed instructions: from the traces they try to find the instructions and data handled by the chip. Eisenbarth et al. [START_REF] Eisenbarth | Building a side channel based disassembler[END_REF] build a leakage model for all instructions then compare their actual leakage to these models. With this technique, they can recover part of the software of the procedure.

Cristiani et al. [START_REF] Cristiani | A bit-level approach to side channel based disassembling[END_REF] shows up to 95% recovery of the full 14-bit instruction by exploiting the leakage of all bits individually.

Classical Countermeasures

Mask

Masking [START_REF] Granger | Improved Masking for Tweakable Blockciphers with Applications to Authenticated Encryption[END_REF][START_REF] Duc | Making masking security proofs concrete[END_REF][START_REF] Yu | A lightweight masked aes implementation for securing iot against cpa attacks[END_REF][START_REF] Mangard | Pinpointing the side-channel leakage of masked AES hardware implementations[END_REF] is one of the most common countermeasures against side channel analysis. It is often used to protect critical functions of symmetric cryptographic algorithms, like s-boxes. It consists of applying a random mask to the data which has undesirable leakage. This solution requires adapting the algorithm.

The simple case: a linear function ℓ : F 2 n ⇒ F 2 ν . Let x ∈ F 2 n be the intermediate value to protect and m ∈ F 2 n random mask value. By linearity of ℓ:

ℓ(x) = ℓ(x ⊕ m) ⊕ ℓ(m) .
The computation is done in parallel with x ⊕ m and m and the final value is reconstituted only at the last moment. No information could leak on x because ℓ(x) is never evaluated. To obtain information on x, the attacker must take into account 2 information leaks (on x ⊕ m and on m): we then speak of an attack of order 2 [START_REF] Choudary | Efficient template attacks[END_REF][START_REF] Prouff | Statistical analysis of second order differential power analysis[END_REF][START_REF] Oswald | Practical second-order dpa attacks for masked smart card implementations of block ciphers[END_REF][START_REF] Messerges | Using second-order power analysis to attack dpa resistant software[END_REF]. More generally, the literature speaks about an scheme of order n by using n random masks [START_REF] Golić | Multiplicative masking and power analysis of AES[END_REF][START_REF] Oswald | A side-channel analysis resistant description of the AES S-box[END_REF]. But this scheme remains vulnerable to an attack of order n + 1.

For a non-linear function f : F 2 n ⇒ F 2 ν (for example the s-boxes), the difficulty increases. In general, a function f m is generated such that:

f m (x ⊕ m) = f (x) ⊕ m ;
or equivalently by change of variable:

f m (x) = f (x ⊕ m) ⊕ m .
In the classic case where the non-linear function is an s-box, in software it is thus necessary:

® either recalculate a complete modified s-box before using it, ® either pre calculate all modified s-boxes (one per mask value) and save them in memory.

It is important to ensure that the implementation never evaluates f (x). In hardware, the masking function could be computed with a dedicated circuit.

Masking is a pertinent countermeasure that continues to be studied recently [START_REF] Knichel | Automated generation of masked hardware[END_REF][START_REF] Beyne | Cryptanalysis of efficient masked ciphers: Applications to low latency[END_REF][START_REF] Belenky | Redundancy aes masking basis for attack mitigation (rambam)[END_REF][START_REF] Montoya | Energy-efficient masking of the trivium stream cipher[END_REF]. Some new AEAD algorithms, such as the winner of the NIST competition: Ascon [START_REF] Dobraunig | Ascon[END_REF], have incorporated masking protection into their mathematical design.

Noise and desynchronization

Some countermeasures consist in blurring the signal using smoothing techniques, additive noise or desynchronisation effects. They are designed against statistical attacks.

Adding dummy instructions allows modification of execution time or current consumption a portion of embedded code. This added noise desynchronizes the calculations.

A desynchronization [START_REF] Joye | Side-channel analysis[END_REF][START_REF] Rivain | Higher-order masking and shuffling for software implementations of block ciphers[END_REF][START_REF] Benadjila | Deep learning for side-channel analysis and introduction to ascad database[END_REF] is possible if the program does not always execute the instructions in the same order. Obviously this modification must not impact the semantics of the algorithm.

BSCA on AEAD

These works are in the APCIL project funded by the Brittany region. In 2020, with Gaël Thomas from DGA-MI, we have started to work on BSCA against AEAD from the NIST competition [START_REF]Lightweight Cryptography Standardization Process[END_REF]. At this moment the competition was not finished. That is why the algorithms studied in this section are Elephant [START_REF] Beyne | Elephant v2[END_REF] and Sparkle [START_REF] Beierle | Schwaemm and esch: lightweight authenticated encryption and hashing using the sparkle permutation family[END_REF]. We started with two intership students, Awaleh Houssein Meraneh and Eïd Malouf. Today, we continue with a PhD student, Modou Sarry. Christophe Clavier and Julien Maillard from Xlim joined us for publications targeting the Elephant algorithm [START_REF] Houssein Meraneh | Blind Side Channel On The Elephant LFSR[END_REF][START_REF] Maillard | Blind side channel on the Elephant LFSR Extended version[END_REF].

Theoretical attacks

Attack on the LFSR of Elephant [11, 12]

LFSRs are used in different lightweight cryptography candidates, and their initial states often depend on both the key and the nonce. As the nonce needs to be changed for each encryption, attacks on such schemes are limited to the decryption algorithm. In the case of Elephant, presented in prerequisites 1.2.3.4.1, the LFSR only depends on the secret key, Consequently, our attack can be applied in an encryption scenario.

Goal

The goal of the presented attack is to retrieve the Elephant LFSR secret initial state. One has to remark three important points.

® Retrieving the initial state of the LFSR which is equal to mask 0,0 K is equivalent to retrieving the secret key. Indeed, the initial state is just the result of the known permutation P applied to the key.

® As the retroaction polynomial is publicly known, it is possible to shift the LFSR backwards: an attacker who knows 20 consecutive bytes of the secret stream is able to recover the initial state.

® The smaller the LFSR is, the more the attack is able to succeed. As a consequence, the Dumbo 1.10 instance is the most vulnerable.

Attack path

In the LFSR itself In this attack, it is assumed that the HW of all bytes of the LFSR can be obtained by an attacker.

Since the LFSR generates a single new byte at each iteration, let B 0 , • • • , B 19 be the content of the Dumbo LFSR initialized with mask 0,0 K , and extend the notation for j ≥ 20, by letting B j be the new byte generated at iteration j -20. In other words, the attacker has the following relation ((φ1)) from the LFSR definition (1.5).

(φ1) B j+20 = (B j ≪ 3) ⊕ (B j+3 7) ⊕ (B j+13 7).
The first idea is to use the knowledge of the following HWs:

® HW (B j+20 ), ® HW (B j ) = HW (B j ≪ 3), ® HW (B j+3 ) ® HW (B j+13 ).
So with the two equations (φ1) and HWs, the attacker has:

HW (B j+20 ) =                HW (B j ) or HW (B j ) + 1 or HW (B j ) -1 or HW (B j ) + 2 or HW (B j ) -2 (3.3)
Looking more precisely at equation (φ1), it can be seen that the difference HW (B j+20 ) -HW (B j ) depends on only four bits. Letting B j [i] denotes the i-th least significant bit of byte B j , these four bits are:

{B j+3 [0]; B j+13 [7]; B j [4]; B j [5]}.
The Table 3.2 gives the value of observed difference HW (B j+20 ) -HW (B j ) depending on the values of these four bits. In the worst case, there are only 6 possibilities left, out of 16.

(Bj+3[0], Bj+13[7]) = HW (Bj+20) -HW (Bj) (0, 0) (0, 1) (1, 0) (1, 1) (Bj[4], Bj[5]) = (0, 0) 0 +1 +1 +2 (1, 0) 0 +1 -1 0 (0, 1) 0 -1 +1 0 (1, 1) 0 -1 -1 -2
Table 3.2: Values of HW (B j+20 ) -HW (B j ) according to {B j+3 [0]; B j+13 [START_REF] Moussaileb | Ransomware Network Traffic Analysis for Pre-Encryption Alert[END_REF]; B j [4]; B j [5]} .

Link between the different masks

The value mask i,1 K can be expressed in terms of mask * ,0 K . As in the case of mask i,0 K , let B 1 j denote either the byte j of mask 0,1 K when 0 ≤ j ≤ 19, or the new byte obtained after j -20 iterations of the LFSR initialized with mask 0,1 K . Likewise, let B 1 j denote either the byte j of mask 0,1 K when 0 ≤ j ≤ 19, or the new byte obtained after j -20 iterations of the LFSR initialized with mask 0,1 K . Then, two equations, (3.4) and (3.5), can be written:

B 1 j = B j ⊕ B j+1 ; (3.4) B 2 j = B j ⊕ B j+2 . (3.5)
The evolution of the LFSR are analogous to (φ1):

B 1 j+20 = (B 1 j ≪ 3) ⊕ (B 1 j+3
7) ⊕ (B 1 j + 13 7). (3.6) B 2 j+20 = (B 2 j ≪ 3) ⊕ (B 2 j+3 7) ⊕ (B 2 j+13 7). (3.7)
Merge the information Finally, the attacker can thus exploit two attack vectors: on the one hand, equations (φ1), (3.6), and (3.7) coming from iterating the LFSR, and on the other hand, equations (3.4) and (3.5) coming from the different masks used for domain separation. The equations (1.20) introduce a strong link between the different points of measurement. That is the chosen attack path that we exploit.

0 / 32 ≪ 1 L 01 • ≪ 8 R 0 / 32 • α L 1 R 1 HW(L 01 ) HW(L 1 ) HW(R 1 )

First results

Eïd Maalouf during his work from home intership used the different equation (1.20) to discriminate more guesses on the key. It uses only HW. In his attack, the remaining number of possible 128bit keys to find is approximately 2 69.3 . However, it should be noted that his attack is quite rough and not very strict in practice. So we need to improve the approach.

Attacks in practice [13]

In the real world, it is not possible to obtain HW from the intermediate computation. So the results presented 3.3.1 are not pertinent in practice. In this section, our model for the leakage is a HW with an additive Gaussian noise as explained in 3.2.2.3.2. In this case, another tool is required.

Main idea: crossing information with belief propagation (BP)

Information comes in two ways.

® One is the leakage measurement on the different internal values.

® The other is the different equations which link the internal values between them.

An attacker aims to cross the information obtained from the measurements with the information derived from the equations. To this end, a technique known as belief propagation (BP) algorithm (or sum-product algorithm) [START_REF] Kschischang | Factor graphs and the sum-product algorithm[END_REF] is used. BP uses an inference Bayesian approach [START_REF] Barber | Bayesian Reasoning and Machine Learning[END_REF].

BP was first used by Gallager [START_REF] Gallager | Low-density parity-check codes[END_REF][START_REF] Robert | Low Density Parity check codes[END_REF] for decoding low-density parity-check (LDPC) codes. It was then rediscovered by Tanner [START_REF] Tanner | A recursive approach to low complexity codes[END_REF] and formalized by Pearl [START_REF] Pearl | Reverend bayes on inference engines: A distributed hierarchical approach[END_REF]. The first time that BP was used in SCA, is the attack [START_REF] Veyrat-Charvillon | Soft Analytical Side-Channel Attacks[END_REF], then it is studied in [START_REF] Grosso | ASCA, SASCA and DPA with Enumeration: Which One Beats the Other and When?[END_REF]. I worked with the same tool in [START_REF] Bouder | A multi-round side channel attack on aes using belief propagation[END_REF] to attack the AES keys.

Factor Graph

A BP algorithm relies on a bipartite graph called a factor graph (or Tanner graph). To each node in the factor graph is associated some information.

The nodes of a factor graph are of two kinds:

® variable nodes x;
® factor nodes, representing equations E.

An edge links a variable node with a factor node E j , when the equation represented by the factor node involves the variable node x i . A part of a factor graph is illustrated in Figure 3.4. N denotes a the set of neighbours for a node. Thus the set of N(E) are composed by variable nodes x; and the set of N(x) are composed by factor node E.

x 0 x 1 x 2 x 3 x 4 x 5 E 0 E 1 E 2 E 3

Use case elephant

In the case of Elephant, the Tanner graph illustrated in Figure 3.5 is defined as follows. Variable nodes are the bytes B i j of the different LFSRs. There are two types of factor nodes:

® for retroaction equations (φ1), (3.6), and (3.7);

® for equations linking the masks (3.4) and (3.5).

We chose not to represent the leakage on the Tanner graph because measurements between bytes are independent.

B0 B1 B2 B3 B4 B5 . . . B13 B14 B15 . . . B20 B21 B22 B 1 0 = B0 ⊕ B1 B 1 1 = B1 ⊕ B2 B 1 2 = B2 ⊕ B3 B 1 3 = B3 ⊕ B4 B 1 4 = B4 ⊕ B5 . . . B 1 13 = B13 ⊕ B14 B 1 14 = B14 ⊕ B15 . . . B 1 20 = B20 ⊕ B21 B 1 21 = B21 ⊕ B22 B 1 0 B 1 1 B 1 2 B 1 3 B 1 4 . . . B 1 13 B 1 14 . . . B 1 20 B 1 21 B 2 0 = B0 ⊕ B2 B 2 1 = B1 ⊕ B3 B 2 2 = B2 ⊕ B4 B 2 3 = B3 ⊕ B5 . . . B 2 13 = B13 ⊕ B15 . . . B 2 20 = B20 ⊕ B22 B 2 0 B 2 1 B 2 2 B 2 3 . . . B 2 13
. . .

B 2 20 B 1 20 = B 1 0 ≪ 3 ⊕ B 1 3 ≪ 7 ⊕ B 1 13 ≫ 7 B20 = B0 ≪ 3 ⊕ B3 ≪ 7 ⊕ B13 ≫ 7 B 2 20 = B 2 0 ≪ 3 ⊕ B 2 3 ≪ 7 ⊕ B 2 13 ≫ 7

Use case Sparkle

In the case of Sparkle, the Tanner graph is defined on the bits of Alzette blocks (L 0 , R 0 ) to (L 4 , R 4 ). The variable nodes are bits on the different (L i , R i ) There are two kinds of equations:

® the equations which described the Alzette (1.20),

® the HW equations (sum of bits on a byte).

In this case the HW is represented because it induces a new relation between the different bits. The Figure 3.6 is a part of the Tanner graph for one bit on the first round of Alzette.

L0 1 (b) c1(b -1) c1(b) L0 1 = L0 ⊞ (R0 ≪ 1) L0(b) R0(b) R0(b -8) L1 = L0 1 ⊕ α L1(b) R1 = (L0 1 ≪ 8) ⊕ R0 R1(b -8) HW (L0 1 ) = ∑ L0 1 (bi) HW(L0 1 ) HW (L1) = ∑ L1(bi) HW(L1) HW (R1) = ∑ R1(bi) HW(R1)

Generic BP algorithm

BP algorithm inputs are ® the Tanner graph, ® prior probabilities P A on the different variable nodes.

BP algorithm returns P P a better belief, from the initial value P A . BP algorithm computes probabilities a posteriori P P on the different variable nodes.

P P are computed according to the input prior probability P A and to the probabilities P(x i = y|E) conditional on factor node E in to be satisfied using the following equation:

P P ∝ P A • Ej ∈N(xi) P(x i = y|E j ) (3.8)
In practice, nodes in the factor graph exchange information messages with their neighbours. More precisely, since the graph is bipartite, two types of messages are exchanged:

® factor to variable messages between a factor node E j and a variable node x i , denoted µ Ej →xi .

µ Ej →xi (y) = ® variable to factor messages between a variable node x i and a factor node E j , denoted µ xi→Ej ; The equation (3.9) comes from the law of total probability.

µ xi→Ej (y) ∝ P A (x i = y) • E l ∈{N(xi)\Ej } µ E l →xi (y) (3.
To complete the description of the BP algorithm, an initialization step is done before applying the above equations. The variable to factor messages µ xi→Ej (y) are initialized with the prior probabilities P A (x i = y). In summary, after an initialization phase, BP works by alternatively applying equations (3.9) then (3.10) for every edge (x i , E j ) in the graph. At the end of the execution, the returned value P P is computed using equation (3.8). The number of iterations depends on the rapidity to converge.

Attack results on simulation

In his thesis, Modou Sarry has developed a generic BP in terms of variable nodes and equations. Thank to this, we have tested BSCA on different AEADs of NIST competition: Elephant [START_REF] Beyne | Dumbo, jumbo, and delirium: Parallel authenticated encryption for the lightweight circus[END_REF] and Sparkle [START_REF] Beierle | Schwaemm and esch: lightweight authenticated encryption and hashing using the sparkle permutation family[END_REF]. For the moment he has some results in simulation and we project to work on the use case Ascon [START_REF] Dobraunig | Ascon[END_REF].

A noisy HW is computed, representing the leakage as described in paragraph 3.2.2.3.2. Different values of the noise σ have been tested.

The initial results focus on the LFSR of Elephant. Table 3 In the case where the correct key is not found, the attacker does not know which byte in LFSR Elephant case or bits in Sparkle are incorrect. Therefore, to execute these attacks properly, a backtracking key algorithm can be used. A smart algorithm takes as input the posterior probabilities returned by BP. Doubt is primarily placed on the nodes with the lowest probabilities. One must note that in the case of Sparkle, even with a traditional brute force algorithm, the attacker can retrieve the correct key because they know that only a few bits are wrong on average.

Experimental implementation in progress

In his PhD, Modou Sarry has begun testing the attacks with real measurements. The target is a microcontroller STM32-F411. He has access to the LHS, including the EMA illustrated in Figure 3.1.

(φ2) B j+20 ← (B j ≪ 3) ⊕ (B j+1 7) ⊕ (B j+11 7) (φ3) B j+20 ← (B j ≪ 3) ⊕ (B j+14 3) ⊕ (B j+17 7) (φ4) B j+20 ← (B j ≪ 1) ⊕ (B j+3 3) ⊕ (B j+13 7) (φ5) B j+20 ← (B j ≪ 1) ⊕ (B j+9 3) ⊕ (B j+15 7) (φ6) B j+20 ← (B j ≪ 3) ⊕ (B j+9 4) ⊕ (B j+19 7) (φ7) B j+20 ← (B j ≪ 3) ⊕ (B j+1 5) ⊕ (B j+3 6) (φ8) B j+20 ← (B j ≪ 1) ⊕ (B j+4 3) ⊕ (B j+19 5) (φ9) B j+20 ← (B j ≪ 1) ⊕ (B j+7 3) ⊕ (B j+18 5) (φ10) B j+20 ← (B j ≪ 1) ⊕ (B j+3 3) ⊕ (B j+9 5) (φ11) B j+20 ← (B j ≪ 3) ⊕ (B j+1 7) ⊕ (B j+17 4) (φ12) B j+20 ← (B j ≪ 3) ⊕ (B j+5 7) ⊕ (B j+19 3) (φ13) B j+20 ← (B j ≪ 1) ⊕ (B j+5 7) ⊕ (B j+16 3) (φ14) B j+20 ← (B j ≪ 1) ⊕ (B j+1 7) ⊕ (B j+9 3) (φ15) B j+20 ← (B j ≪ 1) ⊕ (B j+13 5) ⊕ (B j+19 3) (φ16) B j+20 ← (B j ≪ 3) ⊕ (B j+14 7) ⊕ (B j+17 3) (φ17) B j+20 ← (B j ≪ 3) ⊕ (B j+4 1) ⊕ (B j+5 6) (φ18) B j+20 ← (B j ≪ 1) ⊕ (B j+3 1) ⊕ (B j+9 1) (φ19) B j+20 ← (B j ≪ 1) ⊕ (B j+4 1) ⊕ (B j+5 1) (φ20) B j+20 ← (B j ≪ 3) ⊕ (B j+1 1) ⊕ (B j+8 ≪ 7) (φ21) B j+20 ← (B j ≪ 3) ⊕ (B j+3 5) ⊕ (B j+4 ≪ 5)
We ran 120 times the same experiment, for every considered LFSR. For each LFSR, we noted the proportion of runs finished after two days of computations. Results are summarized in Table 3.5.

From these experiments, it seems that the depth has a much more relevant impact than the type. Yet, this seems to be quite tailored to our particular attack. Changing the generation of the different masks is generally more impactful, as it can reduce the amount of information given to the attacker by up to a factor of three.

Sparkle use case

The impact of this attack path on Alzette is less pertinent than for Elephant. But a minor result is shown by BP. All the factor node E j do not have the same impact to retrieve the secret. Some equations give more information. Indeed, in the following the equation ranked by their order of carried information :

1. the xor with a knowing constant (1.9), (1.12), (1.15) and (1.18).

the

Blind side channel analysis for reverse engineering (BSCARE) [14]

This section presents work with the collaboration of Ronan Lashermes from INRIA. We hope to publish the final results very soon [START_REF] Lashermes | Generic SCARE: reverse engineering without knowing the algorithm nor the machine[END_REF]. This work is a new reverse engineering technique that can reconstruct a procedure from inputs, outputs and traces of execution only. The algorithm and the machine is totally unknown. A complete reverse engineering is proposed. So it is another version of BSCA called blind side channel analysis for reverse engineering (BSCARE).

This work intends to explore some of the limits of SCA: what information can be recovered from traces ? Under assumptions, we show that an unknown algorithm can be totally reverse-engineered even executed on an unknown machine, from noisy and lossy traces of execution as the power consumption, for example.

As a reminder of the importance of Kerchoff's principles, this work gives yet another argument that security by obscurity can be bypassed.

The Table 3 To experiment our attack we have chosen two different block ciphers: AES [START_REF]Specification for the Advanced Encryption Standard[END_REF] described in section 1.2.3.1.1 and Twine [START_REF] Suzaki | TWINE: A Lightweight Block Cipher for Multiple Platforms[END_REF] described in section 1.2.3.1.2.

A simplified description of the attack

The BSCARE technique only relies on the leakage of the data in the targeted algorithm. In this report only a summarised simplification of the easy case without noise is described.

For this work we have the following assumption.

® 8-bit reduced instruction set computer (RISC) software procedure

The attacker can only deal with 8-bit RISC software implementations. It means that only 1-to-1 or 2-to-1 elementary operations are allowed with one input-one output or two inputs-one output, operating on 8-bit data.

® Temporal causality

In one trace, the information is present in chronological order. A byte value at time t 0 can be determined by byte values at times t < t 0 .

® Synchronicity

To perform the analysis, the procedure under test must be repeatedly executed. Traces are required to be synchronous: at the same time (index in the trace), the byte value corresponds to the same underlying procedure sub-operation.

Collected data

The objective is to build a function G that actually computes the same output as the targeted unknown procedure P for any given input. To do that the attacker uses traces: she repeatedly registers trace and output data for several executions of the same procedure P for different input data. In the data generating phase, the procedure is executed n times, with inputs of size S I bytes, outputs of size S O bytes, and traces length of S T bytes. All measured data are sampled, giving only values as unsigned bytes: [[0, 255]]. These experiments give three matrices:

® I is the input matrix.

® O is the output matrix.

® M is the trace matrix.

One row of a matrix corresponds to one execution. For the trace matrix, one column corresponds to all values sampled at the same time t, for all executions. In the rest, it is supposed that inputs and outputs are present in the traces directly, i.e. there is a 1-to-1 function linking an input byte to one trace time etc. A trick to make that assumption hold in all cases is to rewrite M as the concatenation of matrices I, M and O.

Since the traces are synchronous, then ∃ t 1 , t 2 , t 3 , f such that ∀l, M l,t3 = f (M l,t1 , M l,t2 ); there is a function f that links times t 1 and t 2 to t 3 as illustrated on Figure 3.7.

Inputs

Traces Outputs

n S I S M S O t 1 t 2 t 3 t 4 t 5 f 0 f 1 Figure 3.7:
Illustrative recapitulation of our notation. Each square represents a byte. The procedure is executed n times. Inputs, trace of execution and outputs are recorded and correspond to a row in the matrices. A time is the index of the column in the traces matrix M. In the illustration, we have identified relations f 0 and f 1 allowing deducing a column from two others. t 3 = f 0 (t 1 , t 2 ) and t 5 = f 1 (t 3 , t 4 ).

Using fractional added information (f ai) to identify functions

At numerous points, the attacker needs a measure to detect 1-to-1 and 2-to-1 functions by measuring how much information is in the output, knowing the inputs. The measure that is devised is called fractional added information (f ai), it is the estimated normalized conditional entropy.

f ai(t i |t j ) = H(t i |t j ) H(t i ) . (3.11)
where H is the Shannon entropy, t i the output and t j the input of the 1-to-1 or 2-to-1 function (t j can be a vector or a two-column matrix).

A f ai measure of 1 means that t i is independent from t j . If f ai is 0, then t i is totally determined by the knowledge of t j .

Identifying 1-to-1 functions

To identify a 1-to-1 function, the f ai(t 2 |t 1 ) measure for all pairs of time (t 1 , t 2 ) where 0 ≤ t 1 < t 2 < S M , is computed. If f ai(t 2 |t 1 ) = 0, then ∃f such as t 2 = f (t 1 ).

Identifying 2-to-1 functions

To identify 2-to-1 functions, the attacker examines f ai measures for each

(t 1 , t 2 , t 3 ) triplets with 0 ≤ t 1 < t 2 < t 3 < S M . If f ai(t 3 |t 1 , t 2 ) = 0, then ∃ f such that t 3 = f (t 1 , t 2 ).

Generate an information flow hypergraph (IFH)

At this stage the attacker has a complete raw information flow hypergraph (IFH) that should link inputs to outputs. The raw to logic transformation consists in the rewriting of the hypergraph in a simpler one called the logic IFH, while applying corresponding transformations on the raw traces to obtain the logic traces. This hypergraph contains only hyperedges with one destination node, and one or two source nodes, for 1-to-1 and 2-to-1 functions respectively. The Figure 3.8 illustrated an example of IFH part.

The attacker transforms the M matrix into logic traces, a new matrix representing the "ideal" traces that can be extracted from the procedure. From these logic traces, they determine the actual functions linking values between them in the same execution.

The last step is a simplify step. Where the attacker merge 1-to-1 functions in the just one as presented in Figure 3.9.

t 0 t 1 t 2 t 3 f 0 f 1 f 2 f 3 t 0 f ′ Figure 3.9: Example of simplication of 1-to-1 functions:f 0 , f 1 , f 2 , f 3 in just one: f ′ .

Reconstitution of the function

To finish, functions are needed to link procedure inputs and outputs to their corresponding appearance time in the logic traces. This is simply done, for each input/output byte, by finding then extracting the corresponding 1-to-1 function.

At this point the function G is built. To execute it, the attacker has to generate a logic trace corresponding to the provided fresh inputs.

Use cases

Even if the technique is not specifically designed to target symmetric cryptographic primitives, it is particularly interesting to use in this case for an attacker. We have chosen to opt to validate the techniques by applying it to reverse engineer simulations of AES [START_REF]Specification for the Advanced Encryption Standard[END_REF] and Twine [START_REF] Suzaki | TWINE: A Lightweight Block Cipher for Multiple Platforms[END_REF], respectively described in 1.2.3.1.1 and 1.2.3.1.2. This paragraph enumerates potential malicious applications that an attacker could execute with this capacity in symmetric cryptography context.

® Forging encrypted data.

Forging encrypted data can allow the adversary to feed their own information to the system. A man-inthe-middle attack could be mounted using BSCARE by observing the sender's encryption process, and then replacing the encrypted data by the forged ones.

® Decrypting data with specific modes of operation. Many modes of operation most notably counter based such as CTR, use the same block cipher for encryption and decryption. Thus, depending on the precise mode, it becomes possible to use the block cipher learnt with BSCARE to decrypt other data that have been encrypted with the same cipher and key. In this regard, BSCARE it is particularly powerful against these modes.

® Forging message authentication codes.

It may be possible to clone a MAC function using BSCARE in some circumstances. For example, in the case of the Pelican MAC function [START_REF] Daemen | The mac function pelican 2.0[END_REF] described in section 1.2.3.2, there are several possible ways to reverse engineer this function. Either the attacker is able to observe the execution of the Pelican MAC, with the same secret key, numerous times for messages of the same size (respecting the constant-time constraint). Or they can try to reverse engineer subparts of the algorithm if they can observe some intermediate values. For example, since the key is used only at the start and the end of the procedure, if the attacker can observe the inputs and outputs of the last AES application it is enough to reverse engineer the subparts using the secret key. This particular example illustrates that BSCARE can also be used to reverse engineer only unknown parts of otherwise known schemes.

® Getting the decryption from the observation of encryptions.

Similarly to CTR modes being particularly vulnerable, some block cipher structures may increase the power of this technique. In particular, GFN like Twine could be inferred by observing the encryption procedure. But preliminary experiments showed that it implies to modify our structure recovery method to properly deal with reordering. In particular, it is not possible to just switch inputs and outputs and flip the traces. The resulting structure still breaks our temporal causality assumption.

Conclusion

In this chapter, two physical cryptanalysis techniques targeting AEAD have been presented, specifically against Elephant and Sparkle. These attacks, known as blind side channel analysis (BSCA), employ a belief propagation (BP) algorithm, a powerful tool in this context.

Moreover, BSCA is emerging as a compelling tool to evaluate symmetric cryptographic primitives. In the case of Elephant, it highlights that the choice of incrementation in different rounds presents a vulnerability. The results highlight that the selection of LFSRs is far from trivial. Potentially, this approach could be extended to other security algorithms.

Ascon emerged as the winner of the NIST competition, so a future direction of my work involves assessing the resilience of Ascon against BSCA.

Additionally, this chapter introduced the concept of BSCARE. Most work related to SCARE possesses some level of information on the targeted algorithm. The results of BSCARE are significant as they indicate an attacker could potentially use traces from a completely unknown algorithm.

In these attacks, the assumption that an attacker can obtain a HW or noisy HW is substantial. Future experimentation will determine whether we can validate this hypothesis.

To conclude, I believe we are only at the beginning of these novel approaches, namely BSCA and BSCARE.

Chapter 4

Protecting instructions: toward a cryptographic solution.

"En essayant continuellement on finit par réussir. Donc : plus ça rate, plus on a de chance que ça marche."

Les shadocks de Jacques Rouxel.

Introduction

Physical attacks are attacks that rely on the interaction of the computing unit with its physical environment. Side channel analysis (SCA), presented in the previous chapter 3 are based on the observation of the circuit's behaviour during the computation: e.g. the time taken by a computation or the device's power consumption. Fault injection attack (FIA) consists in disturbing the computation in order to alter the correct progress of the application. Clock glitches, power glitches, electromagnetic pulses or laser pulses are commonly used to obtain these perturbations.

Embedded systems are targets of choice for physical attacks since the attacker can get physical access. Unfortunately, most devices are not protected against physical attacks. There are multiple reasons for this: economics since hardened devices are more expensive, technical because the security is achieved at the cost of both performances and energy efficiency. The last barrier is cultural since for a long time such attackers were dismissed as not realistic by all but one industry: the smart card designers. In practice, there is a real need to protect devices against physical attacks.

To protect against the fault injections attacks, the execution of a program must enforce guarantees. We define the following guarantees.

® Control flow integrity (CFI): the control flow cannot be modified (no arbitrary jumps). The control flow follows the valid control flow graph (CFG). One has to remark that while it's possible to prove that a path is one of the possible path in the CFG., until now, it is not possible to definitively prove that it's the correct one.

® Instructions integrity (II): the instruction values must not be altered outside of it.

® Data integrity (DI): the data handled by the program must not be altered.

® State integrity (StI): the processor state (configuration, registers, program counter, . . . ) must not be altered.

Often, DI, II and StI are considered together under the name of system integrity (SI).

Motivation

Ensuring resistance to physical attacks is crucial, and integrity is a prerequisite for many critical infrastructures. A large literature exists on the protection of instructions and the works target predominantly the integrity, rarely confidentiality. One has to remark the major propositions [START_REF] Burow | Control-flow integrity: Precision, security, and performance[END_REF][START_REF] Hiscock | Lightweight instruction-level encryption for embedded processors using stream ciphers[END_REF] protect the control flow against error or code injection attack (CIA) and code-reuse attack (CRA), but not against a hardware attack like fault injection attack (FIA).

In the literature, a countermeasure is developed for each attack on a specific algorithm or device. However, the idea of creating a patch for each new attack is insufficient. There is a real motivation to find general, rather than specific, countermeasures.

The main countermeasures in the literature to resist physical attacks aim at protecting specific computations for some critical algorithms [START_REF] Clavier | Differential power analysis in the presence of hardware countermeasures[END_REF]. For examples, masks are used to protect cryptographic primitives (e.g. AES S-box) or redundancy is used to protect the critical verification (e.g. verify PIN).

But resistance to physical attacks should be ensured in all contexts. For example, a fault in a non-critical part of an application can be enough to allow the attacker to take control of the device, via a return-oriented programming (ROP) attack. In consequence, recently, a new trend appeared where the designers protect all instructions of an application and not only a specific algorithm. This chapter is focused on instructions protection in the context of physical attacks, with specific emphasis on fault injection attacks. Hardware fault injection can modify a program at runtime by skipping arbitrary instructions [START_REF] Sébanjila | title = Let's shock our IoT's heart: ARMv7-M under (fault) attacks[END_REF] or by altering the instruction encoding. Consequently the problem of integrity in the microarchitecture is a rising concern today. When a strong integrity guarantee is needed from a processor, one of the leading solution is to use lockstep processors. Such a processor contains two or more identical cores that reproduce the same computation on each core. Then a monitor ensures that they provide identical results. Lockstep processors are difficult to implement, are not energy efficient and often provide poor performances since we need simple cores in order to synchronize them in the system. Additionally, they do not resist an attacker able to inject identical fault on all the cores with the correct timing. A feat hardly feasible today, but with advancing injection techniques this does not seem too far-fetched in a near future.

Contributions

I have worked on the project Cogito [START_REF] Couroussé | Cogito: Code polymorphism to secure devices[END_REF], which presents a significant improvement to the community by providing automatic countermeasures against various attacks. Cogito implements classical countermeasures through polymorphic code.

After this professional experience, I believe that stronger countermeasures are necessary. One idea to protect instruction integrity against faults was published in HAPEI [START_REF] Lashermes | Hardware-Assisted Program Execution Integrity: HAPEI[END_REF]. While this work has some limitations and practical challenges, it can be considered a starting point. I strongly believe that finding effective and practical cryptographic solutions to defend instructions against physical attacks is a new area of research.

Organization

The context of fault injection attacks is provided in section 4.2. Results of the Cogito solution are presented in section 4.3. The solution HAPEI is presented in section 4.4. Then, section 4.5 discusses new ideas that I want to explore. A conclusion is drawn in section 4.6.

Fault injection attack context 4.2.1 Definition

The concept of injecting physical faults originates from the field of space exploration, where cosmic rays generate errors in the circuits of computers sent into space. A similar problem arises in the context of nuclear technology. As a result, the first physical faults were accidental and not intentional or malicious.

In this manuscript, fault injection attack (FIA) is the idea of disrupting the normal operation of a device, with the aim of obtaining information or hijacking it [START_REF] Dutertre | Review of fault injection mechanisms and consequences on countermeasures design[END_REF][START_REF] Barenghi | Fault injection attacks on cryptographic devices: Theory, practice, and countermeasures[END_REF].

Technical injection

Laser fault injection

Light radiation emitted by a laser or a focused light source can be used to inject faults into a device. Such fault injection devices require the package to be open, these are therefore invasive attacks. This method is a subdomain of fault injection techniques [START_REF] Roscian | Frontside laser fault injection on cryptosystems-Application to the AES'last round[END_REF][START_REF] Lacruche | Laser fault injection into sram cells: Picosecond versus nanosecond pulses[END_REF][START_REF] Agoyan | Single-bit DFA using multiple-byte laser fault injection[END_REF][START_REF] Selmke | On the application of Two-Photon Absorption for Laser Fault Injection attacks: Pushing the physical boundaries for Laser-based Fault Injection[END_REF][START_REF] Dumont | An overview of laser injection against embedded neural network models[END_REF][START_REF] Viera | Permanent Laser Fault Injection into the Flash Memory of a Microcontroller[END_REF]. This method uses the photoelectric effect, which is the emission of electrons when electromagnetic radiation, such as light, hits a material. In practice, the energy of the light radiation used is absorbed by the silicon of the circuit, which induces a voltage spike. The induced voltage spike can cause the appearance of a fault if it is sampled by a memory element such as a register.

Electromagnetic fault injection

Another method is the injection of faults by electromagnetic pulse [START_REF] Dehbaoui | Electromagnetic transient faults injection on a hardware and a software implementations of AES[END_REF][START_REF] Bayon | Contactless electromagnetic active attack on ring oscillator based true random number generator[END_REF][START_REF] Khuat | Multiple and reproducible fault models on micro-controller using electromagnetic fault injection[END_REF]. The circuit attacked is placed under a near-field antenna. The attacker then causes a very strong current to flow for a very short time (the exact parameters depend on the targeted chip). By electromagnetic coupling, part of this energy is transmitted in the metal at the surface of the chip (power supply tracks, clock tracks, data bus, etc.). The current generated in the chip can therefore generate errors. Faustine is made of a Keysight 33509B pulse generator, a Keysight 81160A signal generator and a Milmega 80RF1000-175 power amplifier, connected in sequence to generate a signal. This signal then passes through a Langer RF probe RF B 0.3-3 located on the targeted chip to generate an electromagnetic fault injection. In order to launch a fault injection, a synchronization signal (a trigger) is sent by the targeted chip General-Purpose I/O (controlled from the code) directly to the 33509B pulse generator. This experimental trick, possible when the attacker has control of the code (i.e. only for vulnerability assessment) is not mandatory. Other synchronization possibilities include sniffing communications with the target or measuring its EM to find a relevant pattern. The location of the probe on the chip is chosen after a scan that determined the most sensitive area on the targeted chip.

Clock glitch

A synchronous circuit is composed of one or more logic gates, framed by registers managed by a common internal clock, denoted clk. The logic blocks correspond to the functions computed by the theoretical algorithm. The registers are memory elements of the device. The internal clock gives at regular intervals, an electrical pulse, simultaneously to all processor components. At each rising edge of the clock, data are updated at the output of the registers. The clock period must be long enough to ensure that the calculations run as shown in Figure 4.2. ® t Max : the propagation time of the bit that has the longest path to go from one register to another.

t clk t Max + t s t * clk clk clk *
® t s : the setup time during which the data must remain stable at the input of a register to be sampled correctly.

The following equation must always hold:

t clk > t Max + t s .
In the case of a glitch on the clock, if: t * clk < t Max + t s , an error can appear. This technique can be used to generate errors/faults to build attacks [START_REF] Balasch | An In-depth and Black-box Characterization of the Effects of Clock Glitches on 8-bit MCUs[END_REF][START_REF] Zussa | Power supply glitch induced faults on FPGA: An in-depth analysis of the injection mechanism[END_REF][START_REF] Claudepierre | TRAITOR: a low-cost evaluation platform for multifault injection[END_REF].

Effects

The consequences of a fault injection are multiple. In case of failure, the device can be destroyed. It is the undesirable effect of a bad adjustment parameter for a laser or a electromagnetic pulse. A successful fault disrupts the computation.

As in SCA the process to obtain a fault is a physical experiment thus not a mathematical function. But a mathematical model can be used. The choice of the model depends the chosen different abstraction levels. The different abstraction levels 1 to 5 are presented in chapter 1. In this section, main models at different levels are presented.

Algorithm and software model

The fault can be modelled directly at the algorithm level [START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF]. A classic model in this case is the xor function:

x * = x ⊕ e (4.1)
The faulty value x * is just the correct value x xored with an error value e.

A classical exploitation example in physical cryptanalysis is the differential fault analysis (DFA), which are attacks that exploit faulty results obtained through fault injection. Cryptographic primitives are prime targets for these attacks, as demonstrated by the extensive literature [START_REF] Lashermes | A DFA on AES Based on the Entropy of Error Distributions[END_REF][START_REF] Barenghi | Fault injection attacks on cryptographic devices: Theory, practice, and countermeasures[END_REF][START_REF] Biham | Differential Fault Analysis of Secret Key Cryptosystems[END_REF][START_REF] Dusart | Differential fault analysis on aes[END_REF][START_REF] Piret | A differential fault attack technique against spn structures, with application to the aes and khazad[END_REF][START_REF] Giraud | DFA on AES[END_REF][START_REF] Minier | Improving impossible-differential attacks against rijndael-160 and rijndael-224[END_REF].

At the software level (2), the model is very similar to the algorithm model [START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF]. The model can just be more specific to the language.

Microarchitecture model

This section examines the fault from the processor's perspective: what are the effects of the injection on the operation of the processor and therefore on the software running on it. One has to remark that most of the work characterizing fault models on the targeted microarchitecture focus on microcontrollers. Thus, the details of the effects of a fault injection on a complex architecture are largely unknown. Here is a non-exhaustive list of classic model used:

® Corruption of the cache memory [START_REF] Trouchkine | Electromagnetic fault injection against a complex CPU, toward new microarchitectural fault models[END_REF].

® Instruction skip or no operation (NOP) [START_REF] Moro | Electromagnetic fault injection: towards a fault model on a 32-bit microcontroller[END_REF][START_REF] Breier | Laser profiling for the back-side fault attacks: with a practical laser skip instruction attack on AES[END_REF][START_REF] Dutertre | Experimental analysis of the laser-induced instruction skip fault model[END_REF][START_REF] Menu | Experimental analysis of the electromagnetic instruction skip fault model[END_REF]. This fault model has a direct exploitable impact at algorithm level. For example, the verification of a PIN code can be skipped as in [START_REF] Claudepierre | TRAITOR: a low-cost evaluation platform for multifault injection[END_REF].

® Phantom edges refer to instances of branching or jumping to uncontrolled destinations. The term derives from the effect of the injection adding an edge, which is normally absent, to the CFG.

® The replay is an instruction that is overwritten and replaced by the previous instruction [START_REF] Riviere | High precision fault injections on the instruction cache of ARMv7-M architectures[END_REF][START_REF] Khuat | Analysis of a laser-induced instructions replay fault model in a 32-bit microcontroller[END_REF].

RTL model

The effect from the device's point of view, at the RTL level (4), corresponds to its impact on the logical values of the signals.

® A bit flip is the inversion of a bit value on a wire. Depending on the wire's location in the circuit, this error may be propagated to a register, leading to a fault, i.e., an incorrect result. However, it's also possible that the error is logically absorbed by a combinator circuit: no fault then manifests.

® A stuck at 0 or stuck at 1 fault is the consequence of an induced current having a memory effect due to feedback: a latch-up. The wire then no longer moves for a certain time, remaining at the value 0 or 1. This time may be reduced or infinite: it is then necessary to stop the circuit's power supply to erase the disturbance.

Physical model

The physical models are at the transistor level (5). A timing fault model [START_REF] Dehbaoui | Electromagnetic transient faults injection on a hardware and a software implementations of AES[END_REF] is about a fault generated in a register due to the violation of temporal constraints.

It is also possible to directly influence the sampling process of a register, or by directly disrupting the clock. This is the sampling fault model [START_REF] Ordas | Electromagnetic fault injection: the curse of flip-flops[END_REF]. This is a model that corresponds, in principle, more to EM injection.

In reality, a fault injection by disturbance or EM is likely to cause one of the two models, or both at the same time, depending on the bench and the target.

Countermeasures

Countermeasures such as noise and desynchronisation, which are used against SCA and introduced in section 3.2.3.2, can also be employed against FIA. Indeed, it becomes more challenging for an attacker to target a specific instruction if that instruction doesn't consistently occur at the same moment during execution.

Redundancy

In the case of fault injection attacks, most countermeasures mainly aim to add redundancy to the code to be executed [START_REF] Joshi | Concurrent error detection schemes for involution ciphers[END_REF][START_REF] Karpovsky | Robust protection against fault-injection attacks on smart cards implementing the advanced encryption standard[END_REF][START_REF] Manssour | Processor extensions for hardware instruction replay against fault injection attacks[END_REF]. This redundancy can be implemented at different levels. It can be as follows.

® Spatial redundancy: several distinct part or element perform the same operation in parallel. For example, at the microarchitecture level (3): two cores are placed together, expected to execute the same tasks synchronously. This is called processors in lockstep.

® Temporal redundancy: the same operation is repeated several times; or the inverse of the operation is computed. Sometimes another possibility is to compute the reciprocal of the computation and check the result with the initial input.

One has to remark that today an attacker is able to repeat the same fault several times during the same execution [START_REF] Claudepierre | TRAITOR: a low-cost evaluation platform for multifault injection[END_REF][START_REF] Bartkewitz | Beware of Insufficient Redundancy: An Experimental Evaluation of Code-based FI Countermeasures[END_REF]. So just adding redundancy is not a pertinent countermeasure.

Another form of redundancy is the use of error detecting codes or better error correcting codes (to protect against denial of service) [START_REF] Di Natale | A reliable architecture for parallel implementations of the advanced encryption standard[END_REF][START_REF] Wang | Secure multipliers resilient to strong fault-injection attacks using multilinear arithmetic codes[END_REF][START_REF] Montoya | Dynamic encoding, a lightweight combined countermeasure against hardware attacks[END_REF]. In this case, sometimes, it is a question of modifying the algorithm to integrate these codes. It is for example possible to modify the sub-functions of the AES to calculate the modification of the state in parallel with a parity bit on this state.

Shield

To protect a device at the transistor level (5), it is possible to use a shield. It consists of metal tracks positioned above and below the chip [START_REF] Dutertre | Review of fault injection mechanisms and consequences on countermeasures design[END_REF][START_REF] Gaine | Active Shielding Against Physical Attacks by Observation and Fault Injection: ChaXa[END_REF] These tracks provide passive electromagnetic shielding for the tracks below. Additionally, to prevent attackers from penetrating the shield (e.g., using a focused ion beam), pseudo-random data can be transmitted through the tracks of the shield. The integrity of the shield is ensured by verifying that the data is still present and correct.

Instruction set randomization (ISR): a symmetric cryptography solution

In software and control flow integrity architecture (SOFIA) [START_REF] De Clercq | SOFIA: software and control flow integrity architecture[END_REF], the authors want to ensure CFI with instruction set randomization (ISR). It is one of the first solutions which uses cryptography to protect the instruction at the microarchitectural level.

The proposed solution is to mask the instructions with a key stream depending on the program counter (PC) and the previous PC denoted PC prev (for the previous instruction). Let I be an instruction and I ′ the corresponding encrypted instruction.

I ′ = En(P C prev ||P C, K) ⊕ I
This elegant solution ensures that an instruction can be correctly decrypted only if P C and P C prev are correct. Effectively, it encrypts all the possible successions of instructions and the correct instruction can be decrypted only upon correct P C and P C prev values.

In order to ensure instructions integrity (II), a tag with a MAC is computed and verified per batch of up to 6 instructions. The tag value is stored as two words at the beginning of each block. If an instruction has two predecessors, a special case must be made: the multiplexor block. In this block, the two first words correspond to the MAC values for the two possible predecessors:

T 1 = MAC(P C 1 prev ||P C, K), T 2 = MAC(P C 2 prev ||P C, K).
The tag not used (corresponding to the wrong predecessor) must be skipped in a software transparent way.

In a recent publication [START_REF] Hiscock | Lightweight instruction-level encryption for embedded processors using stream ciphers[END_REF], the authors show how encryption can be achieved at the instruction level using a stream cipher. The decryption is so fast and lightweight that it can be performed very deep within the processor, ensuring that plain instructions remain only within the processor's execution logic. The method requires slight hardware and software modifications.

Instructions randomization by Cogito [15]

Cogito is an ANR project [START_REF]Runtime Code Generation to Secure Devices COGITO[END_REF] that funded my post-doctorate. The coordinator was Damien Couroussé from CEA. The partners were INRIA, ENSMSE and CEA. My use case was to test the countermeasures of Cogito, protecting PIN codes against SCA. Different works have been published [START_REF] Couroussé | All paths lead to rome: Polymorphic runtime code generation for embedded systems[END_REF][START_REF] Couroussé | Cogito: Code polymorphism to secure devices[END_REF][START_REF] Barry | Compilation of a countermeasure against instruction-skip fault attacks[END_REF][START_REF] Couroussé | Runtime code polymorphism as a protection against side channel attacks[END_REF].

It is important to clarify that in Cogito, it is indeed the randomization of the instructions and not the randomization of the instruction set, so it is a software solution.

The project

Security in embedded devices and runtime code generation are, a priori, two technological fields that hardly combine together. On the one hand, secure elements must target small production costs, silicon and energy consumption, and as such, offer very limited computing and memory resources. On the other hand, compilation is a computation-intensive process, and dynamic compilation techniques require a fair amount of computing power and of memory resources at runtime. In Cogito, the authors focused on the use of runtime code generation to introduce behavioural variability in embedded systems. Indeed, behavioural variability is often used as a protection against physical attacks. So, the objective of Cogito is to demonstrate the applicability and the effectiveness of code generation techniques applied at runtime and on board for security purposes in embedded devices.

The Cogito solution is an adaption of deGoal, a technology for runtime code generation, developed by the CEA [START_REF] Charles | degoal a tool to embed dynamic code generators into applications[END_REF]. In deGoal code segments called kernels are generated and tuned at runtime by ad hoc runtime code generators, called compilettes. A compilette is an ad hoc code generator focusing on a single kernel, with the intention of being invoked at runtime. The building and the execution of an application using deGoal, illustrated in Figure 4.3, consist in the following steps :

® writing the source code using a mix of C source code and of a dedicated cdg language;

® compiling the binary code of the application and the binary code of compilettes;

® at runtime, generating the binary code of kernels by compilettes and in the end running the kernels.

At the end of the project, polymorphism is implemented with runtime code generation driven by random data. The main result is to regularly generate new versions of the secured binary code on the target. Each program version is functionally equivalent but has a different implementation, so that each execution would lead to a different observation. The polymorphic code generator is produced by a framework for runtime code generation adapted to the constraints of embedded systems.

How Cogito works

In simple words, Cogito is a way to automatically introduce classical countermeasures against physical attacks. It is a software solution at the level (2).

The idea is to introduce noise, desynchronization and random masks as explained in sections 3.2.3.2 and 3.2.3.1 with a unique tool. Cogito can be summarized as follows.

® Cogito introduces randomness during runtime code generation to produce polymorphic application components.

® Cogito uses semantic equivalences at the instruction level to produce different instances of code sequences.

® Cogito shuffles, at runtime, the machine instructions and randomizes the mapping to physical registers.

® Cogito can be combined with other hardware protections.

® Cogito limits memory consumption and fast code generation, so that it is applicable to very small computing units such as secure elements

The protections are presented in detail in the following.

Register allocator (RA)

The role of the register allocator (RA) is to map the endless number of single static assignment virtual registers to a limited number of physical registers. Thereby the RA attempts to reuse as much as possible each register in order to avoid assigning variables into memory locations (spill slots). For that, the RA implements an analysis pass called liveness analysis. This pass computes for each variable an interval in which the variable is considered alive. The liveness interval is a pair of program points, start and end, which starts when the value of the variable is defined and ends at the last point where the value is used (read). Thus, if two variables have disjoint liveness intervals, it means they can be assigned to the same physical register.

In dynamic compilers, instruction selection and instruction scheduling are usually performed before register allocation [START_REF] Kotzmann | Design of the java hotspot client compiler for java 6[END_REF]. In Cogito, register allocation is done first, before instruction scheduling, by using a greedy algorithm. The purpose is to lighten the pressure on instruction selection and instruction scheduling: if register allocation is done first, it becomes possible to perform instruction scheduling from a much simpler intermediate representation, the allocator simply needs to maintain a list of the free registers available.

With Cogito, the same program changes the register allocation at each execution, which introduces randomness. The idea is to limit the fault injection against a specific register.

Instruction selection

Instruction selection is performed after RA once the runtime constants have been evaluated by the compilette. Instruction selection is done at the level of cdg instructions. Each expression can be mapped to one or more machine instructions depending on the target processor architecture and code generation options. For the purpose of achieving code polymorphism, supplementary variants are introduced to provide more opportunities for polymorphism. The semantic equivalences are used in the context of the experiment.

The semantic equivalences introduce noise and desynchronization.

Instruction scheduling

In traditional compilers, instruction scheduling aims at improving the performance of code execution: machine instructions are ordered in program memory in order to minimize execution time. The difficulty of scheduling lies in finding a possibly optimal ordering of machine instructions without breaking the semantics of the original source program.

In the case of code polymorphism, the aim is to exploit scheduling opportunities to generate many variants of the same source program, all functionally equivalent and semantically correct. Hence, code performance is only a secondary matter, and Cogito project considers resource constraints that impact code correctness, but not those that only impact program performance. Instruction scheduling is performed in one pass: each time a new instruction is inserted in the instruction buffer. First the list of possible insertion slots is computed, by comparing the definitions and uses of the inserted instruction and of the instructions already stored in the buffer. Next, the insertion position is randomly selected among the list of insertion slots previously identified. If no insertion slot was found, the new instruction is appended at the end of the instruction buffer. If the instruction buffer is full, its first instruction is emitted in program memory to free one instruction slot.

The main idea behind this instruction scheduling is to introduce additional desynchronization and redundancy to limit fault injection against a specific instruction.

Insertion of noisy instructions

Noise instructions are appended to the end of the instruction buffer before the insertion of a new instruction. The noise instructions are inserted with a chosen probability. If needed, extra registers are randomly selected in the list of free registers. If no register is available, registers are randomly selected, pushed and popped on the stack before and after use. Several kinds of instructions can be inserted: core arithmetic instructions that execute in one processor cycle (e.g. integer operations add or sub) or in several processor cycles and memory accesses to a data table possibly provided by the user.

Results and limitations

In this section the results and the limitation of this project are presented.

Protection against side channel attacks

The results of Cogito against side-channel attacks are presented in [START_REF] Couroussé | Runtime code polymorphism as a protection against side channel attacks[END_REF]. The main results are:

® the number of side-channel observations necessary to perform a successful attack is increased (50 to 10000 traces);

® polymorphism can reduce information leakage.

The attack tested in [START_REF] Couroussé | Runtime code polymorphism as a protection against side channel attacks[END_REF] was limited to a CPA against unprotected AES. There is no proof that an attacker with greater computing power cannot analyse more traces and successfully launch the CPA.

During my post-doctorate, I was able to execute a successful template attack against Verify PIN even when Cogito was implemented. This implies that Cogito is not effective against template attacks.

The Cogito solution significantly slows down attackers, but does not entirely stop them. While it may be sufficient to deter amateur attackers, it is not a foolproof solution for strong security.

Protection against fault injection attacks

The scheduler rearranges the execution order of instructions to improve execution time while maintaining the original behaviour of the program. An analysis of this protection is presented in [START_REF] Barry | Compilation of a countermeasure against instruction-skip fault attacks[END_REF]. The authors use countermeasures included in Cogito, but not Cogito itself. This countermeasure is designed to defend against fault injection attacks targeting a specific instruction. It could be a good protection against fault injection attacks aimed at skipping the call to compare arrays or the decrement counter in a Verify PIN scenario. However, it may not be effective against the new multi-fault attacks [START_REF] Claudepierre | TRAITOR: a low-cost evaluation platform for multifault injection[END_REF]. In cases where the attack does not target a specific instruction, such as in many DFA attacks, the attacker can simply execute the algorithm multiple times, until a desired fault is achieved.

Limitation of implementation

The problem I encountered with the Cogito solution stems from its conception. It is specifically designed with the idea of protecting symmetric cryptographic algorithms against CPA and DFA. To protect the Verify PIN, the use case slightly differs and two problems occur.

1. In a Verify PIN, an important protection is the constant time execution, independent of the PIN code candidate proposed by the user. Unfortunately, the random noise addition in Cogito does not respect this rule.

2.

In a Verify PIN algorithm different flags are used to the protection of the algorithm. At the end of the computation, all the flags have to be true. The place of the flag is crucial. The idea is to check if all important computation such as, for example the decrement of the trial counter, is made in good time.

Unfortunately, the instruction scheduling of Cogito breaks the semantics of the original flag Verify PIN.

In practice, Cogito mixes the flag instructions with the other ones and thus nullifying their security effect.

A strong implementation of Verify PIN needs flags and a constant time execution. To keep that, two different protection of Cogito: noise insertion and instruction scheduling should turned off.

Conclusion

The Cogito project's best result is the automated inclusion of countermeasures (noise, redundancy, desynchronization, and masking) against physical attacks. The solutions presented in Cogito are intuitive, but they are imperfect patchwork solutions that randomly apply classical countermeasures. In practice, the countermeasures are not always effective at the moment of implementation, and there is no mathematical proof of security.

HAPEI [16]

I have worked with Ronan Lashermes from INRIA and Gaël Thomas from DGA-MI on hardware-assisted program execution integrity (HAPEI) published in [START_REF] Lashermes | Hardware-Assisted Program Execution Integrity: HAPEI[END_REF]. It is important to note that this work was conducted prior to the publication of [START_REF] Hiscock | Lightweight instruction-level encryption for embedded processors using stream ciphers[END_REF].

The main objective is to protect instructions from fault injection attacks by introducing integrity in code execution with a cryptographic tool, rather than relying on redundancy-based countermeasures.

We recognize the effectiveness of the SOFIA [START_REF] De Clercq | SOFIA: software and control flow integrity architecture[END_REF] solution, so we built our own solution based on it. A major issue with SOFIA is the separation between CFI and II. Since the CFI mechanism relies on the PC rather than the instruction value, an additional mechanism is necessary to ensure II. Finally, the multiplexor block must deal with possible predecessors in a non-trivial way. It modifies the control flow according to the actual predecessor where it should be predecessor agnostic (all legitimate predecessors must be dealt with in the same way). HAPEI proposes a solution to these problems, by relaxing the efficiency requirements at a microarchitecture level.

First step

In order to harden the application, a preparatory step is required to encode the instructions. Only then, the application can be executed.

® Packing is required to create the encoded program, enriched with the necessary metadata, following the scheme detailed below. It must be done on the final device, since it requires a device-specific secret key K.

® During execution, the encoded instructions are decoded on-the-fly and executed. The decryption can only occur if the program state is correct.

The program execution integrity (PEI)

Here program execution integrity (PEI) denotes the combination of CFI and II. SOFIA encodes the state of the program as the succession of PC prev and PC. HAPEI proposes instead to encode the state of the program as the history of all previous executed instructions. This proposal does not depend on the PC value (apart when encoded in an instruction value). As such, the machine code is ensured to be executed correctly: instructions integrity is ensured together with CFI.

Secondly, it becomes easy to check at any time during execution that the current state of the program is valid.

It supposes that the CFG of our program is perfectly defined at compile time. There is no ambiguity on the destination address of jumps and calls. This condition is trivially satisfied if there are no indirect jumps or calls in our program. In the other case, it can be trickier.

Let acc j (standing for accumulator) be a value representing the state of the program when instruction I j is about to be executed (j uniquely identify one instruction). I j and acc j can be seen as values in F 2 n and F 2 ν , with n is the instruction size (considered fixed) and ν is the security parameter.

Starting step

To bootstrap the encoding, one has to use an initialization vector IV as input for the first executed instruction.

acc init = HMAC K (IV ) acc init is considered as a predecessor program state to the entry instruction. It may be used in a multipredecessor scheme or in the 1-predecessor one. HMAC is chosen because it is a pertinent cryptographic tool to guarantee the integrity.

1-predecessor

The easy case is the 1-predecessor case. The program snippet is a succession of instructions {I 1 , I 2 , • • • , I j , • • • } where all instructions are executed in order.

The instructions are encoded as

I ′ j = C (acc j ) ⊕ I j , where C is a compression function: a projection from F 2 ν to F 2 n . C must ensure that x cannot be deduced from C(x).
Obviously the state of the program must be updated, using secret key K:

acc j+1 = HMAC K (acc j ||I j ).
The state of the program is encoded with a hash chain depending on all previous instructions. The encoded instruction I ′ j can only be decoded when the previous state of the program acc j is correct. This is possible only when instruction I j is due. Decoding necessitates the same operations:

acc j = HMAC k (acc j-1 ||I j-1 ), I j = C (acc j ) ⊕ I ′ j .

A first solution with p-predecessors

It is possible to generalize in order to allow up to p predecessors for instruction and for a control flow with cycles.

In order to allow cycles, we must "rebase" our program state for all instructions having several predecessors. In this case, the program state is a new uniformly random value. The problem is now to map valid predecessor states to this same new state.

Let σ be a random value in F 2 n . Let acc i j , i ∈ [ [1, p]] be the allowed previous accumulator values for current instruction I j . A polynomial P can be defined such that ∀i ∈ [[1, p]], P (acc i j ) = σ using Lagrange interpolation. Since the generated polynomial is minimal, it is constant if we do not define an additional point. P (0) = α for a random data such as α = σ, ∈ F 2 ν .

The p coefficients of P are stored as program metadata with the corresponding instruction I j . At packing, HAPEI encodes with I ′ j = C(σ) ⊕ I j . To decode instruction Ij, the polynomial evaluation acc j = P (acc j-1 ) is used. Note that the polynomial evaluation replaces the HMAC call. So the strong integrity propriety cannot be guaranteed in a cryptographic definition.

A second solution with p-predecessors

F * 2 ν can be decomposed in different subgroups G p where ∀x ∈ G p , x p = 1.
(subgroup of pth-root of unity). Such subgroups exist for all p such that p | 2 n -1. For all valid p (depending on n), a scheme that allows p predecessors is defined. For example, n = 16 allows a scheme with 5 predecessors (p = 5 divides 65535 = 2 16 -1).

Let acc i j , i ∈ [ [1, p]] be the allowed previous accumulator values for current instruction I j . Let σ be a random value in F 2 ν . Let g ∈ G p be a generator value for the subgroup. We construct a polynomial P (in F 2 ν ) using Lagrange interpolation such that ∀i ∈ [[1, p]], P (acc i j ) = σ • g i . The p -1 coefficients of P are stored as program metadata with the corresponding instruction I j . At packing, HAPEI encodes with I ′ j = C(σ p ) ⊕ I j . To decode instruction I j , acc j = P (acc j-1 ) p is used. Indeed, by construction

∀i ∈ [[1, p]], P (acc i j ) p = σ • g i p = σ p • (g p ) i = σ p .
In this scheme, polynomials have degree p -1 instead of p in first solution 4.4.2.3: the memory overhead is lower.

Ensuring instruction integrity

To verify the II, it is sufficient to compare the value of acc j to a pre-generated truth value during the packing stage. The more often the check is performed, the sooner any tampering is detected, but this requires a larger amount of metadata.

A second strategy is to have valid instructions forming a set I valid ⊂ F 2 ν . If #(I valid ) << #(F 2 ν ) a wrongly decoded instruction has a very low probability of belonging to I valid , of being valid.

Key management

In this scheme, the component responsible for managing the secret key K is critical. In most cases, the binary encoding cannot be performed at compilation on the binary provider machine as it would require shipping the secret (which is then shared) along with the binary. As a result, any ISR scheme using a secret key must have a packing phase that transforms an unmodified binary (or extended with the CFG information) into a hardened one.

The other possibility is for the binary provider to encrypt the application for each intended recipient, then to use public-key cryptography to share the corresponding secret key with the targeted hardware.

Limitations and conclusion

This solution uses the program state, a hash chain of all previously executed instructions, in order to encode the program. Correct decode can only be achieved if the program state is correct. The difficulty lies in the multi-predecessors case. Here, the program state is reinitialized with a random value and a polynomial is computed that maps all previous program states to this new value. Two solutions have been explored 4.4.2.3 and 4.4.2.4.

® The problem with the first solution 4.4.2.3 is that P is constructed in a very specific way: Lagrange interpolation ensures that P (X) -σ has p distinct roots. An attacker can use the peculiarity to gain information on σ and acc i j . Given a random polynomial Q of degree p, the probability that Q has p distinct roots corresponds to the number of combinations to distribute p roots over 2 n values divided by the total number of polynomials of degree p:

2 n p 2 n•(p+1) . (4.2)
Since in our case where p 2 n , equation (4.2) becomes:

1 p! • 2 n•(p+1) (4.3)
As a conclusion, a proportion of p! random polynomials have p roots. The greater the p, the better for the attacker that becomes able to discriminate σ. In most cases, p is low and 2 n is high (n ≥ 128) so the security should not be compromised since the attacker cannot possibly enumerate all possible σ.

® The possibility for the attacker to discriminate σ given P is the main motivation for the alternative solution 4.4.2.4. In this proposition, σ is not a special value with respect to P (X) -σ • g i may have any number of roots (≥ 1). But then, it means that additional roots may be considered valid program states. Some random illegitimate accumulator values could be mapped to the legitimate one. Since the attacker should not be able to control the accumulator value, the security is not compromised.

Thus the choice between solutions proposed in 4.4.2.3 and 4.4.2.4 depends on the attacker model. If they can control acc j , then first solution must be chosen. If not but they have a huge computation power, second solution should be preferred.

Even though HAPEI appears to be an original mathematical concept, it has significant limitations. The first major drawback is that these solutions for p-predecessors, which use a polynomial approach, consequently lose the cryptographic property of integrity that is guaranteed by an HMAC in the solution for a 1-predecessor.

The second major issue with the HAPEI solution is its impracticality. Unfortunately, this solution is utopian. Indeed its polynomial computations cannot be practically implemented. Computing a polynomial at each execution is too time-consuming. The performances are simply too poor.

Moreover, since the CFG must be perfectly known at packing time, indirect jumps and calls should be avoided. In particular, the scheme is not compatible with virtual method tables required for runtime polymorphism in several languages (C++, java, . . . ). Additionally, the scheme is tailored for self-contained applications. If the program must call external code (shared libraries, OS call), things do not play well.

Future works

Definition of the problem

Protecting programs against physical attacks is not trivial. The first question is: what kind of attack does it need to guard against? Previous works such as BSCARE introduced in 3.4 suggest that protecting a program's confidentiality is an extremely challenging problem. The control graph can always be retrieved. On the other hand, the problem of integrity in a program arises because FIA can alter it.

The solutions proposed in the previous sections of this chapter are not satisfactory. Cogito is a solution at software level against all physical attacks. Unfortunately it is not enough to protect correctly against physical attacks. To find a real pertinent solution, it needed to descend into lower levels of abstraction.

HAPEI is a first solution at microarchitecture level. But it suffers from inefficient cryptographic schemes leading to inefficient designs in terms of performances, silicon area and energy consumption. Moreover it is not a protection against SCA.

I want to continue to study the problem of integrity in the microarchitecture. The solution HAPEI is clearly not adapted. But the idea to use cryptography to protect instructions stay pertinent as proven the recent works of Savry et al. [START_REF] Hiscock | Lightweight instruction-level encryption for embedded processors using stream ciphers[END_REF][START_REF] Savry | Confidaent: Control flow protection with instruction and data authenticated encryption[END_REF].

To precise the problem, I have to zoom on the different levels at the pipeline. A basic pipeline is composed of five stages as follows.

1. Fetch the instruction in instruction cache memory I$. ® What is the model of an attacker? Where exactly are they able to induce the fault? Thus where in these stages should a future solution be placed?

® What tools should be used: MAC or encryption?

® Once instructions are encoded (with a cryptographic primitive), when should they be decoded?

I plan to launch a new project with Gaël Thomas from DGA-MI and Ronan Lashermes from INRIA on this subject to try to solve some of these problems.

Ideas

In this section the first research track is presented. In HAPEI, MAC and polynomial functions have been used but they have been shown to be the limiting factor in the applicability of the solution. We want to improve it to make it actually work in a real processor and have cryptographic guaranties. Our objective is to propose suitable solutions to protect the instructions in the aspects of both the control flow graph and the execution cycle.

We need to replace interpolating polynomials with a scheme based on MAC, purposely designed to meet our security (fault attack resilience) and performance criteria. We need a novel cryptographic primitive with a particular constraint: low latency. So we want to examine the different primitives for MAC with low-latency in mind. A first list of algorithms to study can be: Prince [START_REF] Borghoff | PRINCE -A low-latency block cipher for pervasive computing applications -extended abstract[END_REF], Midori [START_REF] Banik | Midori: A block cipher for low energy[END_REF] or Mantis [START_REF] Beierle | The SKINNY family of block ciphers and its low-latency variant MANTIS[END_REF], Orthros [START_REF] Banik | Orthros: A low-latency PRF[END_REF], Qarma [START_REF] Avanzi | The QARMA block cipher family[END_REF] and probably the most pertinent: Speedy [START_REF] Leander | The SPEEDY family of block ciphers engineering an ultra low-latency cipher from gate level for secure processor architectures[END_REF].

The simple case in the control flow graph is when an instruction has just one predecessor. In this simple case, applying a MAC is enough. When an instruction has multiple predecessors, a more complex protocol is required. The previous schemes in the literature [START_REF] Lashermes | Hardware-Assisted Program Execution Integrity: HAPEI[END_REF][START_REF] De Clercq | SOFIA: software and control flow integrity architecture[END_REF][START_REF] Savry | Confidaent: Control flow protection with instruction and data authenticated encryption[END_REF] suffer from inefficient cryptographic schemes leading to inefficient designs in terms of performances, silicon area and energy consumption. Helped with our new custom MAC, we should devise a new scheme relying on it to ensure program execution integrity. It should be an ISR scheme: using a MAC integrity scheme even for multipredecessors instructions. The verification should be possible only when the initial control flow has been respected and if the protected program has not been tampered with.

We will have to integrate the specially crafted MAC and protocol into a hardened processor, starting from an unsecured one for comparison. At first, we will consider that programs have no indirect control flow redirection (indirect jumps) since they are notably hard to protect with an ISR scheme. Several trade-offs have to be explored, between security and performances notably. We project to use the LHS from INRIA to evaluate the resistance of the implementation under clock glitches and electromagnetic fault injection attacks. The solution should have an impact as low as possible on the actual speed of the protected CPU compared to an unprotected one. This is a multidisciplinary project involving both cryptography and microarchitecture. Our solution, by being integrated directly in the pipeline, could be used in complex cores (even Out-of-Order cores), offer a strong, cryptographic, guarantee on the integrity of instructions but also of the control flow. This solution is future proof in the context of injection techniques getting more precise and more powerful.

Conclusion

Protecting devices, especially the instructions in a program, against physical attacks is a crucial necessity. In this chapter, various attempts to tackle this challenge and tracks for a future project are presented. The problem of integrity in the microarchitecture is a rising concern today.

The Cogito project's best outcome is the automation of including countermeasures such as noise and desynchronization against physical attacks. However, this is not an ultimate solution as instructions need real integrity to be protected against faults. Symmetric cryptography can be a viable solution to address this problem to some extent. HAPEI is a work that encodes and decodes instructions on the fly. In practice, only in the case of instructions with just one predecessor, a cryptographic solution is proposed: using an HMAC. In the other cases, polynomial functions have been used.

To make instructions secure, cryptographic integrity is essential. In a future collaboration project, I aim to improve HAPEI solution by using low latency MAC. However, many questions still need to be addressed, and I hope to obtain funding to work on this significant challenge.

Different views of symmetric cryptography

Symmetric cryptography remains a useful tool for security. It must adapt to current needs and constraints as for example in the IoT context. Consequently, the NIST has recently standardized new lightweight AEAD algorithms, which are well-suited for constrained environments where the performance of traditional symmetric cryptographic standards proves to be inadequate. Moreover, AEAD guarantee both confidentiality and integrity, thus replacing both encryption and MAC with just a single tool.

My work in this field is not about classical cryptanalysis or developing new primitives. I study physical cryptanalysis and various other original aspects of symmetric cryptography algorithms.

The chapter 2 presents my work on ransomware. Ransomware uses symmetric cryptography to take user data hostage. So in case of ransomware, symmetric cryptography is a threat. Since the start of the pandemic, there has been an evolution in the use of cryptography by ransomware. Indeed initially, the first ransomware programs did not use the tools correctly, as for example the encryption mode. Then, ransomware utilized the victims' cryptographic tools. Today, ransomware is proficient in cryptography. Ransomware ceased making significant mistakes in cryptography. Ransomware programs employ their own cryptographic protocols, which utilize various standards. Consequently, conducting cryptanalysis on ransomware cryptography is equivalent to performing cryptanalysis on the standards themselves. An alternative solution involves detecting the encryption process. In this approach, Shannon's properties of diffusion and confusion are considered as leakages. Indeed, these properties increase the entropy of data. It is likely that future ransomware will utilize cryptosystems based on the Hilbert matrix to avoid impacting entropy during encryption.

In the chapter 3, physical cryptanalysis targets new lightweight AEAD primitives. This chapter presents two new BSCA for retrieving the secret key. Moreover, these attacks give clues to improve the design of the different primitives. In the case of Elephant, we demonstrated that the different designs of a LFSR are not equivalent. For Sparkle, we highlighted the leakage of different basic functions.

Still within chapter 3, a BSCARE is presented against MAC and decryption primitives. The goal of this attack is to recompute the inputs using only the known entries, while the key and the primitive algorithm remain unknown.

In the final chapter 4, we aim to protect the instructions of security algorithms, such as cryptographic algorithms. To achieve this, various initial approaches have been tested. The results were not significant. However, these efforts have opened doors to a new field of research. How to use cryptography at a microarchitecture level to protect instructions? A future area of study involves examining low-latency primitives for MAC.

Another perspective for physical leakages

With physical attacks, the involuntary physical leakage of a device helps an attacker. However, always with the intention of reversing approaches, these leakages can be viewed as a valuable source of information to verify if a device is performing the computations it is supposed to. Indeed, physical leakages do not lie. I am the advisor for Awaleh Houssein Meraneh's PhD thesis. In his thesis, Awaleh is working to find new supervision tools for industrial cyber-physical systems (ICPS). ICPS are intelligent systems that integrate engineered networks of physical and computational components such as automata, robots, etc. They are the prime targets for cyber attacks.

To counter these threats, proactive measures such as anomaly detection systems are deployed. However, some attacks can bypass network security, necessitating alternative detection methods. In this context, physical leakages are pertinent to detect abnormal behaviour.

More specifically, Awaleh has chosen to focus on sound. Sound-based anomaly detection (SAD) involves determining whether the sound emitted by a target machine deviates from the norm [START_REF] Koizumi | Description and discussion on DCASE2020 challenge task2: Unsupervised anomalous sound detection for machine condition monitoring[END_REF]. This system's sound data can be easily captured using low-cost equipment, only a microphone is needed. Furthermore, the typical behaviour of systems can be accurately fingerprinted using sound.

I plan to recruit another PhD student to cross sound with power consumption information to improve the results obtained during Awaleh thesis.

Just to give another use case, today ransomware does not attack only computer but small devices too. At the crossroads between ransomware detection and side channel analysis, it is possible to detect a ransomware on a device by physical leakage, as shown the recent work of Pham et al. in [START_REF] Pham | Obfuscation revealed: Leveraging electromagnetic signals for obfuscated malware classification[END_REF]. With the same philosophy, others detect hardware trojan or backdoor [START_REF] Ngo | Hardware trojan detection by delay and electromagnetic measurements[END_REF][START_REF] Narasimhan | Hardware trojan detection by multiple-parameter side-channel analysis[END_REF][START_REF] Thomas | Backdoors: Definition, deniability and detection[END_REF].

To finish, in future projects, I would like to explore an intuition. A cryptographic algorithm is a product of rigorous research, and every detail in its design is meticulously considered. It is conceivable that even slight modifications could render these algorithms vulnerable. A properly performed fault injection could trigger a backdoor in a cryptographic primitive. This modification could be performed using a laser or electromagnetic radiation fault injection. Thus, a secure algorithm would become weak under faults. These works would allow collaboration with other research institutes that have laser fault injection benches available, like ENSMSE.

FIPS

Notations

® A denotes data associated.

® A denotes Alzette.

® B denotes a byte.

® B is the better belief.

® b denotes a bit.

® C is a ciphertext.

® C denotes compression function.

® c is a carry.

® clk means clocks.

® Dn means decryption.

® $D is a the data cash.

® E an equation or a factor node in a BP.

® En means encryption.

® e denotes an error.

® F is a distribution function.

® F is a round or Feistel function.

® F is a probability density function.

® f denotes a function.

® GF means Galois field (GF).

® G is a group or subgroup.

® G is function.

® g denotes a group or subgroup generator.

® H is a hash function.

® H is the Shannon entropy.

® H0 is the null hypothesis.

® HW is a Hamming weight (HW).

® HW is a noisy HW.

® I is an input matrix.

® I is an instruction.

® I is a set of instructions.

® $I is a the instruction cache.

® i is used for index.

® IV is an initial vector.

® j is used for index.

® K denotes a key.

® L is for left.

® ℓ is a linear application.

® l is an index ® M is a plaintext or a file.

® M is a trace matrix.

® m is a memory.

® m is a mask.

® N is a nonce.

® N is a Gaussian.

® N denotes a set of neighbours.

® n denotes a size.

® O is an output matrix.

® o is an occurrence count.

® P is a permutation.

® P is a probability.

® P is a procedure.

® P is a polynomial.

® p denotes a number of predecessors.

® R is for right.

® r is a round.

® S is the set of the possible successor s.

® S I , S O and S M are size of respectively matrix I, O and M.

® s is a successor or a sample.

® T is a tag.

® T is a transition matrix.

® t is a time.

® t is a trace.

® v is a binary vector.

® v is model of vector.

® W is a whitening layer.

® x is a value or a variable.

® X denotes a random variable or a Markov chain according to the context. ® X is the set of definition of the variable X.

® y is a random value.

® z is used for index.

® α is a constant.

® β denotes a bloc of bits.

® χ 2 is the test of χ 2 .

® Γ B is the number of hits observed for the byte B.

® γ B is the expected number according to a known distribution function.

® Λ denotes the likelihood ratio.

® ν is a size or a number of bits.

® µ a message in a BP algorithm.

® φ is a LFSR.

® (φ) denotes a retroaction equation of one LFSR.

® σ is a noise or a random data.

® * means faulty.

® ⊕ denotes a xor.

® ⊞ denotes a modular addition.

® ⊥ is returned when the integrity of the message is not guarantee.

® is a shift left.

® ≪ is a rotation left.

® °denotes tested.

® || means concatenation.

® # means cardinal.

IMT Atlantique

Bretagne

Figure 1 . 1 :

 11 Figure 1.1: Scheme of AEAD .

Figure 1 . 3 :

 13 Figure 1.3: scheme of TWINE round

Figure 1 . 4 :

 14 Figure 1.4: Block scheme of Pelican, where AES 4,0 denotes a 4-rounds Rinjdael with round key set to 0.

Figure 1 . 6 : 1 . 2 . 3 . 3 . 3

 1612333 Figure 1.6: Scheme of CBC mode encryption

•Figure 1 . 9 :

 19 Figure 1.9: Elephant plaintext encryption (left), ciphertext authentication (middle), and associated data authentication (end).

Figure 1 .

 1 Figure 1.10: 160-bit LFSR φ Dumbo .

Figure 1 .

 1 Figure 1.12: 200-bit LFSR φ Delirium . The three n-bit LFSRs used for the variants of Elephant are the GF (2)-linear maps given at the byte-level by the equations (1.5), (1.6) and (1.7).

Figure 1 . 13 :

 113 Figure 1.13: Scheme of Schwaemm 256-128

Figure 1 . 14 :

 114 Figure 1.14: The first round of the Sparkle 11 384 permutation Sparkle 11 384 takes as input N and K. So according to the Figure 1.14 N is loaded on the left and the first right branch, and K on the last two branches on the right.The Sparkle 11 384 permutations are built using the following main components :

Figure 1 . 16 :

 116 Figure 1.16: Main characters of the different MOOC design by the MoonCat studio.

Chapter 2 .Figure 2 . 1 :

 221 Figure 2.1: Timeline of pertinent evolution in ransomware.

Figure 2 . 2 ,

 22 user applications start by calling MS CAPI exported Crypt(*) functions through advapi32.dll.inria-beta.dll cryptographic primitives pictures : flaticon.com

Figure 2 . 2 :

 22 Figure 2.2: Windows PE and Crypto API (picture extracted from [18]).

Figure 2 . 3 :

 23 Figure 2.3: ECB mode limitation: all the same plaintext block is encrypted with the same ciphertext block. In consequence: you can still recognize the penguin.

Figure 2 . 4 :

 24 Figure 2.4: An example of Markov chain with m = 2 bits, 2 m states and transition probabilities P(X i = y|X i-1 = x).

Figure 2 . 5 :

 25 Figure 2.5: The file system's traversal velocity of 125 Xorist samples and 57 Bitman samples.

  Today, DaD uses one or two indicators of compromise in the same times. The indicators of compromise developed in DaD are monitoring API windows (section 2.3.1), χ 2 (section 2.3.3.1), Markov chains (section 2.3.3.2), distance metrics (section 2.3.3.3) and the file le system traversal behaviour (section 2.4.1). An important objective is to combine all the different indicators for a same execution in MoM. Another objective is to have the

Figure 2 . 6 :

 26 Figure 2.6: Data aware Defence DaD

Figure 3 . 1 :

 31 Figure 3.1: EMA, side channel platform of LHS INRIA Rennes.

3. 3 . 1 . 1 . 3

 3113 Attack strategy The whole search space corresponding to the initial state of the LFSR is represented as a rooted tree. The nodes of depth j correspond to all possible values for the bytes B 0 to B j of the LFSR. The tested candidates are denoted by (B °0, • • • , B °19 ). The nodes in the graph of the search space are labelled as follows: ® the nodes at depth j correspond to the all possible values of (B °0, • • • , B °j ); ® the children of node (B °0, • • • , B °j ), are the nodes labelled: (B °0, • • • , B °j , B °j+1 ) for all values of B °j+1 .

L

Figure 3 . 3 :

 33 Figure 3.3: Measurement leakage in the first round of Alzette.

Figure 3 . 4 :

 34 Figure 3.4: Example of a Tanner factor graph part. Circles are variable nodes and squares are factor nodes.

Figure 3 . 5 :

 35 Figure 3.5: Tanner factor graph on LFSRs Dumbo of Elephant

Figure 3 . 6 :

 36 Figure 3.6: Tanner factor graph on first round Alzette, thus only equations (1.8) to (1.11) on one bit b are represented. c represents the carry. Other equation are HW equations on a byte.

  y1×y2×...y #(N(E j ))-1 E j (y, y 1 . . . y #(N(Ej ))-1 ) • x l ∈{N(Ej )\xi} µ x l →Ej (y l ) (3.9)

2 Figure 3 . 8 :

 238 Figure 3.8: Illustration of the information flow hypergraph corresponding to Figure 3.7

Figure 4 . 1 :

 41 Figure 4.1: Faustine: fault injection bench of the LHS INRIA Rennes. ©INRIA / Photo C. Morel

Figure 4 .

 4 Figure 4.1 depicts a platform for injecting faults into a device, using electromagnetic radiation. This platform is owned by INRIA Rennes [185]. As I have access to this platform, I can provide additional details about it.Faustine is made of a Keysight 33509B pulse generator, a Keysight 81160A signal generator and a Milmega 80RF1000-175 power amplifier, connected in sequence to generate a signal. This signal then passes through a Langer RF probe RF B 0.3-3 located on the targeted chip to generate an electromagnetic fault injection. In order to launch a fault injection, a synchronization signal (a trigger) is sent by the targeted chip General-Purpose I/O (controlled from the code) directly to the 33509B pulse generator. This experimental trick, possible when the attacker has control of the code (i.e. only for vulnerability assessment) is not mandatory. Other synchronization possibilities include sniffing communications with the target or measuring its EM to find a relevant pattern. The location of the probe on the chip is chosen after a scan that determined the most sensitive area on the targeted chip.

Figure 4 . 2 :

 42 Figure 4.2: Clock glitch

Figure 4 . 3 :

 43 Figure 4.3: deGoal workflow: from the writing of the application's source code to the execution of a kernel generated at runtime. Figure is extracted from [173] HW means hardware.

  The project was carried out by partners including INRIA, ENSMSE, and CEA, each with different responsibilities. As part of my post-doctoral work, INRIA was responsible for testing the countermeasure Cogito in a use case involving Verify PIN.® The CEA was responsible for proposing the solution.® The ENSMSE tested the solution in a use case involving encryption with AES.® As a post-doctoral researcher at INRIA, I tested the Cogito countermeasure in a second use case involving Verify PIN.

2 . 3 .

 23 Decode the instruction I and address the register in the register file; Execute the instruction I with data in the register. Change the PC if necessary (branch).

4 . 5 .Figure 4 . 4 :

 4544 Figure 4.4: 5 stages pipeline

"Contents 5 . 1

 51 Je me demande de quelle façon loufoque nous allons nous en sortir..." Jolly Jumper dans Lucky Luke Le fil qui chante de Morris et René Goscinny. Different views of symmetric cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2 Another perspective for physical leakages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Chapter 1 Introduction and context

  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Professional context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Personal motivation to the HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 Scientific context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.1 Computer security and cryptography . . . . . . . . . . . . . . . . . . . . . 1.1.3.2 IoT and embedded devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.3 Physical attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Scientific challenges with a cryptographer view . . . . . . . . . . . . . . . . . . . . . 1.1.4.1 Ransomware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.2 Physical attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5.1 Ransomware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5.2 Physical attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.6 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Symmetric cryptography prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Teaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

"Victoriae mundis et mundis lacrima. Bon, ça ne veut absolument rien dire, mais je trouve que c'est assez dans le ton."

Le roi Loth dans Kaamelott d'Alexandre Astier. Contents 1.1 1.2.1 Classical and older symmetric cryptography . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 New generation of symmetric cryptography algorithms . . . . . . . . . . . . . . . . . 1.2.3 Algorithms studied in the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.1 Block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.1.1 Advanced encryption standard (AES) . . . . . . . . . . . 1.2.3.1.2 TWINE . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.2 Pelican . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.3 Encryption modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.3.1 Electronic code book (ECB) . . . . . . . . . . . . . . . . 1.2.3.3.2 Cipher block chaining (CBC) . . . . . . . . . . . . . . . 1.2.3.3.3 Counter (CTR) . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.3.4 Galois counter mode (GCM) . . . . . . . . . . . . . . . . 1.2.3.4 AEADs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.4.1 Elephant . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.4.2 Sparkle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3

  In cipher block chaining (CBC) mode, each block of plaintext M is xored with the previous ciphertext block before being encrypted. An initialization vector IV is xored with the first block M 0 . The relation is defined in(1.3).

5: Scheme of ECB mode encryption 1.2.3.3.2 Cipher block chaining (CBC)

  is summarized in 2.3.1.

	® In 2015, ransomware with their own cryptography appeared. In practice, some of them do not use
	cryptography correctly. So classical cryptanalysis can help. More details are presented 2.3.2.
	® The last part is the detection of encryption. The cryptographic properties of diffusion and confusion
	(presented in 1.2 implies a high entropy in the ciphertext. So detecting ciphertext writing is the same
	as detecting random data writing. In this way, two classical statistical tools are exploited: χ 2 test and
	Markov chain. More details are presented 2.3.3.

Table 2 .

 2 It is the work of Alexandre Gonzalvez engineer at INRIA. 2: Summary results of our different countermeasures

	Countermeasures	year success	ransomware detected	ransomware tested but
		rate			not detected
	Crypto API Monitoring [2]	2016 50%	Gpcode,CryptoLocker,	TeslaCrypt, Petya, Gpcode
			CTB-Locker
	Replay attacks [2]	2016 37, 5%	Gpcode, TeslaCrypt	CTB-Locker, Petya, Cryp-
					toLocker
	χ 2 test [3]	2017 99, 37% Teslacrypt, Cerber, Xorist,	Xorist
			Bitman, Deshacop, Yakes,
			Zerber, Locky, Gpcode,
			Gamarue, Shifu, Fsysna,
			Shade, Dalexis, Usteal
	File system traversal [6]	2018 100%	Teslacrypt, Cerber, Xorist,
		(need	Bitman, Deshacop, Zerber,
		learn-	Yakes, Locky, Gpcode
		ing)
	Network level [7]	2019 73, 33% Bitman, Cerber, Shade,	Bitman, TeslaCrypt, Yakes,
			TeslaCrypt, Zerber	Zerber
	χ 2 test + cosine distance [5] 2019 96, 05% Bitman,	Cerber,	Fs-	Xorist
			nyna, Telsacrypt, Xorist,
			Yake,	Zerber,	Crysis,
			CTB-Locker,	Gamarue,
			Graphtor, Locky, Purge,
			Sage
	Markov chain [4]	2021 100%	ransomware tested:	Jigsaw, Eris, Ordinypt,
		on	GlobleImposter, Maoloa, Phobos, Nemsis, Deadmin,
		specific	Seon2, Zeppelin, Paradise, StopDjvuMoka, MegaCor-
		types	tex, NemtyRevenge, Estemani, Sodinokibi, Medusa-
		of files	Locker, Xorist

Table 3 .

 3

	.1.
	HW(B) 0 1 2	3	4	5	6 7 8
	#B	1 8 28 56 70 56 28 8 1

1: Number of possible values for a byte B according its HW.

Table 3 .

 3 3: Rank on the different bytes of the first LFSR of Elephant for 1000 different keys according different values of noise σ.

	10)

Table 3 . 4

 34 .3 presents results for the different 20bytes of the first LFSR of Elephant for 100 different keys. This table provides the rank of the correct value.The second Table3.4 gives results on the attacks on the Sparkle key of 128 bits.

	σ	Mean	Standard deviation Median Min Max	Quartile
	0.1 114.06	4.07	114	89	123 (112, 114, 117)
	0.2 114.26	3.51	114	97	124 (112, 114, 117)
	0.3 113.89	3.67	114	97	125 (112, 114, 116)
	0.4 112.92	3.82	113	95	124 (111, 113, 115)
	0.5 111.345	3.85	111	92	123 (109, 111, 114)
	0.7 108.06	3.85	108	87	120 (106, 108, 110)
	1	105.65	4.65	107	85	115 (105, 107, 108)
	2	96.33	10.44	100	47	111	(89, 100, 105)
	3	88.56	12.54	89	45	111	(82, 89, 100)

: Number of correct Sparkle key bits for 1000 different keys.

Table 3 .

 3 5: Type, depth, proportion of runs finished after two days of computations, for Dumbo (φ1), and LFSRs (φ2) to (φ21).

Table 3 .

 3 .6 illustrates the positioning of our work in the existing literature. To our knowledge, there are no similar works.

	target	knowledge	algorithm family	ture (ISA) instruction set architec-	is a RISC processor
	Instructions		×	[140, 166, 167]	×
	One or several specific		[132-135]	×
	function(s)
	Generic structure		[136-138]	×
	Generic structure + spe-		[139, 168]	×
	cific function
	whole algorithm	×	×	our BSCARE

6: Classification of SCARE techniques according to the target of the attacker and its knowledge.

  federal information processing standard. 31 FP false positive. 35, 38 GCM Galois counter mode. 5, 10, 20, 31, 34 GF Galois field. 16, 92 GFN generalized Feistel network. 17, 66 HAPEI hardware-assisted program execution integrity. 8, 68, 70, 77-82 HD Hamming distance. 51 HDR Habilitation à Diriger des Recherches. 5, 10, 11 HMAC hash-based message authentication code. 15, 78-80, 82 HW Hamming weight. 7, 45, 51, 53-56, 58-60, 66, 92 I/O input/output. 41, 71 ICPS industrial cyber-physical systems. 85 IDS intrusion detection system. 39 IFH information flow hypergraph. 7, 46, 64 II instructions integrity. 69, 73, 77-79 IID independent and identically distributed. 34 INRIA Institut national de recherche en sciences et technologies du numérique. 4, 11, 24, 27, 37, 42, 47-49, 62, 71, 74, 75, 77, 81, 82 IoT internet of things. 11, 12, 24, 50, 85 IRISA Institut de Recherche en Informatique et Systèmes Aléatoires. 4, 11 ISA instruction set architecture. 62 ISR instruction set randomization. 8, 68, 73, 79, 81, 82 LDPC low-density parity-check. 56 LFSR linear feedback shift register. 7, 20, 21, 45, 53-55, 57, 59-62, 66, 85, 94 LHS laboratory high security. 11, 14, 40, 42, 48, 49, 59, 71, 82 MAC message authentication code. 15, 18, 47, 65, 73, 74, 81, 82, 85 OCIF "Objets Communicants pour l'Internet du Futur". 4, 11, 47 OS operating system. 41, 80 PC program counter. 73, 77, 78, 81 PEI program execution integrity. 8, 68, 78 RA register allocator. 8, 68, 75, 76 RISC reduced instruction set computer. 62, 63 ROP return-oriented programming. 69 RTL register transfer logic. 8, 13, 68, 72 SAD sound-based anomaly detection. 85 SB SubBytes. 16 SCA side channel analysis. 6, 13, 14, 45, 47, 48, 50-52, 56, 62, 69, 72-74, 80 SCARE side channel analysis for reverse engineering. 7, 45, 47, 52, 62, 66 SI system integrity. 69 SOFIA software and control flow integrity architecture. 73, 77, 78 SPA simple power analysis. 6, 45, 49

	MC MixColumns. 16
	MoM malware-o-matic. 14, 40, 41, 43
	MOOC massive open online course. 24

MS CAPI

Microsoft's cryptographic application programming interface. 30-32 MSCS Mastère Spécialisé en Cyber-Sécurité. 11, 24 NIDS network intrusion detection systems. 30 NIST national institute of standards and technology. 11, 15, 16, 20, 31, 47, 53, 55, 59, 66, 85 NOP no operation. 72 SR ShiftRow. 16 StI state integrity. 69 TAMIS threat analysis and mitigation for information security. 11 TF-IDF term frequency-inverse document frequency. 6, 26, 38

  -Pays de la Loire École Mines-Télécom IMT Atlantique Bretagne -Pays de la Loire -www.imt-atlantique.fr

	Campus de Brest	Campus de Nantes	Campus de Rennes
	Technopôle Brest-Iroise	4, rue Alfred Kastler -La Chantrerie	2, rue de la Châtaigneraie
	CS 83818	CS 20722	CS 17607
	29238 Brest Cedex 03	44307 Nantes Cedex 03	35576 Cesson Sévigné Cedex
	T +33 (0)2 29 00 11 11	T +33 (0)2 51 85 81 00	T +33 (0)2 99 12 70 00
	F +33 (0)2 29 00 10 00	F +33 (0)2 51 85 81 99	F +33 (0)2 99 12 70 08

® different EM probes from Langer either a RF-R 0.3-3 or a RF-R 400-1 both with a 30MHz to 3GHz bandwidth;

After that, the attack or inference phase starts by obtaining traces on the targeted device. These traces are confronted to the different templates.

Acknowledgements

Firstly, I wish to express my deepest gratitude to my unwavering scientific and emotional support over the years: my sweet Ronan Lashermes.

I then wish to extend my thanks to my reviewers: Marine Minier, Jacques Fournier and Peter Ryan and the other jury members: Sylvain Duquesne, Aurélien Francillon and Arnaud Tisseran for evaluating my work.

I am incredibly grateful to Jean-Louis Lanet, who was first an excellent professor, then a perfect mentor, and a wonderful colleague.

I'd like to extend my thanks to my IRISA mentor, Sophie Pinchinat, for all her relevant advice and encouragement.

I would like to express a heartfelt thank you to my dear colleague and friend Gaël Thomas, for all the projects we have undertaken together.

I am grateful to Nicolas Montavont, the head of the "Objets Communicants pour l'Internet du Futur" (OCIF) team, for his unwavering support and impeccable ethics.

I would like to express my gratitude to my colleagues at IMT-Atlantique campus Rennes, especially Baptiste, Fabien and Renzo, and my favourite support functions colleagues: Nardjes, DelphineS, and Alexis. Their presence has made my work more enjoyable.

I would like to thank Ronan Lashermes, Loutfi Nuaymi, Patrick Maille and Gaël Thomas for their valuable comments to the development of this manuscript.

I would like to recognize the work of all my students and PhD students and remind that students are the future of science.

I'd also like to extend my thanks to women who inspire me, in work: Valérie Viet Triem Tong, Géraldine Texier, Caroline Fontaine and in my personal life: Amanda, Pat, Isabelle, Julie, and Irina. They are strong women, and the world needs more women like them.

I want to extend specific acknowledgments to my fun support network, the climbing team at INRIA, my friends from ice skating, artistic rollers, painting, and geek parties (special dedication to: Artefaritaj, Theudeux, Azura, Bichette, and Titoon).

To conclude, I want to express my gratitude to my entire family, particularly my son Gaston; without forgetting my cute pets: Dune, Pixel, Mariette, and Soupir, who always provide comforting hugs.

In practice, to reduce the number of nodes, only the nodes having the correct HWs are considered. In other words, it suffices to consider nodes with HW(B °j ) = HW(B j ). An example of such tree is given on Figure 3.2.

A backtracking algorithm is used. The tree is traversed in a depth-first manner. For each step, the attacker tests whether the current candidate (B °0, • • • , B °j ) satisfies the different conditions given by the observed HWs.

One important idea is that the attacker can wait to observe a set of bytes with a minimal complexity of the attack before starting their attack.

Results

We have simulated the attack on randomly generated Dumbo keys.

The result is that in three quarters of the cases, the key is retrieved in less than two days with desktop computer. The main idea behind this success is the attacker's ability to wait and choose the optimal time to initiate the attack.

On average, for the runs that finished after two days, the number of nodes traversed is 2 41.92 , and the number of remaining keys is 2 36.52 .

Attack on Alzette of Sparkle

Sparkle is another finalist to the NIST lightweight cryptography competition described in 1.2.3.4.2. We work to test the Alzettes A 4 and A 5 of Sparkle against BSCA. This work is not yet published.

3.3.1.2.1

Attack path K 1 and K 2 from the master key K, are the inputs of A 4 and A 5 respectively.

Therefore, finding the master key K is the same as finding K 1 the input of A 4 and K 2 the input of A 5 . As K 1 and K 2 are 64 bits each, so they are divided into two words of 32 bits (L 0 , R 0 ) 4 and (L 0 , R 0 ) 5 respectively. The method to find (L 0 , R 0 ) 4 from the Alzette A 4 is the same to find (L 0 , R 0 ) 5 from the Azlette A 5 .

It is assumed than the attacker can obtain different leakage measurements on the different internal values L i and R i , linked together. More precisely, the measurements are the results of operations in Azlette: xor, rotation and modular addition.

The Alzette is seen as divided in four rounds, and i denotes the round. Finally, the leaking operations in each round of Alzette constitute the attack path. It is illustrated in the Figure 3.3, where the measurement leakage is in red.

The main question to address is: how can we transform an EM trace into exploitable data, such as noisy HW? It is possible that the leakage follows a different model that is more significant. Further investigation is needed to determine this. We hope to obtain experimental evidence to validate the concept of BSCA. Regardless of the specific leakage model, the fundamental idea is that a generic BP can be adapted for analysis.

Impact on the primitive algorithm

Elephant use case

The natural question is about what could be done to mitigate this attack path. So these results have been computed in a theoretical attack i.e the attacker has HW without noise. Outside of using generic countermeasures, like e.g. boolean masking, there seem to be two possibilities for improvement. Indeed, the attacker gains information from two sources: ® from equations (3.4) and (3.5) used to derive the masks for domain separation;

® from the LFSR state update equation (φ1).

Thus either the mask derivation, or the LFSR can be changed, or both.

Impact of the generation of masks

We ran two experiments. In the first experiment, the attacker only know the values of the HW (B j ), and the HW (B 1 j ) for enough bytes. In other words, compared to the experiments, they lost the knowledge of the HW (B 2 j ). Likewise, in the second experiment, they only know the values of the HW (B j ) for enough bytes. Unfortunately for the attacker, in both cases, none of the 120 runs done has terminated after a week.

From these experiments, it seems that the knowledge of the HW (B j ), HW (B 1 j ), and HW (B 2 j ) contributed heavily on the success of the attack. It would then seem a good idea to tweak the cryptographic mode of operation by finding another way of generating masks for domain separation.

Studying different LFSRs

This paragraph is dedicated to the study of the influence of the choice of the LFSR. To keep the spirit of the original Elephant, only Fibonacci-like LFSRs, at the byte level, are considered. More specifically, considered LFSRs are: LFSRs where a single new byte is computed from a combination of three bytes using byte-wise shifts and rotations. As usual, the associated feedback polynomial must be primitive to ensure only maximum-length sequences can be generated. Among all possible candidates, different behaviours can be triggered.

In this work, the type of an LFSR is defined as the sequence of number of bits unknown to the attacker at each depth in the tree where a new feedback occurs.

Looking at equation (φ1), it can be seen that:

since there are only 2 bits that are modified by:

Thus, if other feedback functions are used, with more bits involved, it can be expected to have an impact on the attack. Later in the attack, when at depth 3 in the tree, the same idea can be applied to check whether:

since now only the single bit B j+10 7 is unknown. In conclusion, the type of the Dumbo LFSR is [2,[START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF]. LFSR with different types can be a first criterion when testing our attack.

A second criterion can be: how far apart the feedback bytes are. Indeed, the tighter they are, the faster the attacker can use equation (φ1) at its full potential. In the case of Dumbo, the feedback bytes are at indices 0, 3, and 13. We call 13 the depth, this is simply the highest index of the feedbacks.

We chose LFSR based on these two criteria. Types is defined from [2,[START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF] to [START_REF] Bukasa | How trustzone could be bypassed: Side-channel attacks on a modern system-on-chip[END_REF][START_REF] Bukasa | How trustzone could be bypassed: Side-channel attacks on a modern system-on-chip[END_REF]. For types [2,[START_REF] Moussaileb | A survey on windows-based ransomware taxonomy and detection mechanisms[END_REF], and [5, -], we looked at all the possible LFSRs in order to study the influence of their depth.

The state update function of the different LFSR tested are given by equations (φ2) to (φ21). Their type and depth are given at the second, respectively third, column of Table 3.5.

Bibliography