142,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: ISTE Invoiced
- Sprache: Englisch
Embedded Cryptography provides a comprehensive exploration of cryptographic techniques tailored for embedded systems, addressing the growing importance of security in devices such as mobile systems and IoT. The books explore the evolution of embedded cryptography since its inception in the mid-90s and cover both theoretical and practical aspects, as well as discussing the implementation of cryptographic algorithms such as AES, RSA, ECC and post-quantum algorithms.
The work is structured into three volumes, spanning forty chapters and nine parts, and is enriched with pedagogical materials and real-world case studies, designed for researchers, professionals, and students alike, offering insights into both foundational and advanced topics in the field.
Embedded Cryptography 3 is dedicated to white-box cryptography, randomness and key generation, as well as real world applications and attacks in the wild.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 563
Veröffentlichungsjahr: 2025
Ähnliche
Table of Contents
Cover
Table of Contents
Title Page
Copyright Page
Preface
Part 1. White-Box Cryptography
Chapter 1. Introduction to White-Box Cryptography
1.1. Introductory remarks
1.2. Basic notions for white-box cryptography
1.3. Proposed (and broken) solutions
1.4. Generic strategies to build white-box implementations
1.5. Applications of white-box cryptography
1.6. Notes and further references
1.7. References
Chapter 2. Gray-Box Attacks against White-Box Implementations
2.1. Introduction
2.2. Specifics of white-box side-channels
2.3. Fault injections
2.4. Exact matching attack
2.5. Linear decoding analysis/algebraic attacks
2.6. Countermeasures against the algebraic attack
2.7. Conclusions
2.8. Notes and further references
2.9. References
Chapter 3. Tools for White-Box Cryptanalysis
3.1. Introduction
3.2. Tracing programs
3.3. Target recognition
3.4. Acquiring traces for side-channel analysis
3.5. Preprocessing traces
3.6. Differential computation analysis
3.7. Linear decoding analysis also known as algebraic attack
3.8. Injecting faults
3.9. Differential fault analysis
3.10. Coping with external encodings
3.11. Conclusion
3.12. Notes and further references
3.13. References
Chapter 4. Code Obfuscation
4.1. Introduction
4.2. Obfuscation methods
4.3. Attacks against obfuscation
4.4. Application of code obfuscation
4.5. Conclusions
4.6. Notes and further references
4.7. References
Part 2. Randomness and Key Generation
Chapter 5. True Random Number Generation
5.1. Introduction
5.2. TRNG design
5.3. Randomness and sources of randomness
5.4. Randomness extraction and digitization
5.5. Post-processing of the raw binary signal
5.6. Stochastic modeling and entropy rate management of the TRNG
5.7. TRNG testing and testing strategies
5.8. Conclusion
5.9. Notes and further references
5.10. References
Chapter 6. Pseudorandom Number Generation
6.1. Introduction
6.2. PRNG with ideal noise source
6.3. PRNG with imperfect noise sources
6.4. Standard PRNG with inputs
6.5. Notes and further references
6.6. References
Chapter 7. Prime Number Generation and RSA Keys
7.1. Introduction
7.2. Primality testing methods
7.3. Generation of random units
7.4. Generation of random primes
7.5. RSA key generation
7.6. Exercises
7.7. Notes and further references
7.8. References
Chapter 8. Nonce Generation for Discrete Logarithm-Based Signatures
8.1. Introduction
8.2. The hidden number problem and randomness failures
8.3. Lattice attacks
8.4. Fourier transform attack
8.5. Preventing randomness failures
8.6. Notes and further references
8.7. Acknowledgment
8.8. References
Chapter 9. Random Error Distributions in Post-Quantum Schemes
9.1. Introduction
9.2. Why post-quantum schemes need random errors
9.3. Distributions for random errors
9.4. Sampling algorithms
9.5. Notes and further references
9.6. References
Part 3. Real-World Applications
Chapter 10. ROCA and Minerva Vulnerabilities
10.1. The Return of Coppersmith’s Attack
10.2. Minerva
10.3. References
Chapter 11. Security of Automotive Systems
11.1. Introduction
11.2. The embedded automotive attacker
11.3. An overview of automotive attacks
11.4. Application of physical attacks in automotive security
11.5. Case study: Tesla Model X keyless entry system
11.6. Conclusion
11.7. References
Chapter 12. Practical Full Key Recovery on a Google Titan Security Key
12.1. Introduction
12.2. Preliminaries
12.3. Reverse-engineering and vulnerability of the ECDSA algorithm
12.4. A key-recovery attack
12.5. Take-home message
12.6. References
Chapter 13. An Introduction to Intentional Electromagnetic Interference Exploitation
13.1. IEMI: history and definition
13.2. Information security threats related to electromagnetic susceptibility
13.3. Electromagnetic fault injection
13.4. Destruction, denial of service
13.5. Denial of service on radio front-ends
13.6. Signal injection in communication interfaces
13.7. Signal injection attacks on sensors and actuators
13.8. IEMI-covert channel
13.9. Electromagnetic watermarking
13.10. Conclusion
13.11. References
Chapter 14. Attacking IoT Light Bulbs
14.1. Introduction
14.2. Preliminaries
14.3. Hardware AES and AES-CTR attacks
14.4. AES-CCM bootloader attack
14.5. Application of attack
14.6. Notes and further references
14.7. References
List of Authors
Index
Summary of Volume 1
Summary of Volume 2
End User License Agreement
List of Tables
Chapter 2
Table 2.1.
Summary of attacks described in the chapter
Table 2.2.
Time complexities of the exact matching attack for...
Chapter 5
Table 5.1.
Overview of types of errors in statistical tests...
Chapter 7
Table 7.1.
Lower bounds for
− log
2
...
Chapter 10
Table 10.1.
An estimation of entropy loss and factorization...
Table 10.2.
The summary of the impact of key factorization in...
Table 10.3.
Libraries and devices analyzed in Jancar et al...
Chapter 12
Table 12.1.
SCA acquisition parameters for Rhea
List of Figures
Chapter 2
Figure 2.1.
Example of a Boolean circuit for computing the 3-...
Figure 2.2.
Dummy shuffling. The notation
$
stands for...
Chapter 3
Figure 3.1.
RHme3
: software execution trace overview...
Chapter 5
Figure 5.1.
Block diagram of a contemporary TRNG aimed at cry...
Figure 5.2.
Noise sources in logic devices
Figure 5.3.
Principle of the ring oscillator (left panel) and...
Figure 5.4.
Randomness extraction from a jittered clock signa...
Figure 5.5.
Randomness extraction from a jittered clock signa...
Figure 5.6.
Multi-oscillator-based TRNG (MO-TRNG)
Chapter 6
Figure 6.1.
Procedures in security game
PR
Figure 6.2.
Stateful pseudorandom number generator
Figure 6.3.
Procedures in security game
SPR
Figure 6.4.
Procedures in security game
FWD
Figure 6.5.
PRNG with inputs (Barak and Halevi 2005)
Figure 6.6.
Procedures in security game
ROB
Figure 6.7.
PRNG with inputs (Coretti et al. 2019)
Figure 6.8.
Procedures in Security Game
ROB...
Figure 6.9.
Update function of HMAC-DRBG. When no additional...
Chapter 7
Figure 7.1.
Output domain
Chapter 8
Figure 8.1.
Comparison of two elliptic curve-based signature...
Figure 8.2.
Overview of key recovery attacks against Schnorr...
Figure 8.3.
Behavior of the bias function outputs. Gray arrow...
Figure 8.4.
Plotted sampled bias
|
B
q
...
Chapter 9
Figure 9.1.
Plan of this chapter.
Figure 9.2.
Noisy ElGamal encryption
Figure 9.3.
Post-quantum signatures in the “hash-then...
Figure 9.4.
Post-quantum signatures in the “Fiat-Shami...
Figure 9.5.
The main distributions for random errors. Distrib...
Figure 9.6.
On the left
,
an algorithm for sampling from...
Figure 9.7.
Two table-based sampling algorithms:...
Figure 9.8.
Applying the sorting strategy to sample
...
Figure 9.9.
Two sorting algorithms:
MERGESORT
(non-obl...
Figure 9.10.
On the left
,
a Beneš network with...
Figure 9.11.
Relationships between classes of algorithms for...
Chapter 10
Figure 10.1.
Complexity of ROCA attack with respect to key le...
Figure 10.2.
The number of certified items under Common Crite...
Figure 10.3.
The visible leakage of nonce’s bit-length...
Figure 10.4.
The leakage of nonce bit-length on a power consu...
Chapter 11
Figure 11.1.
The Model X key fob PCB (top side). The main com...
Figure 11.2.
The PoC device consists of a battery and a DC-DC...
Chapter 12
Figure 12.1.
Left: Google Titan Security Key USB type C versi...
Figure 12.2.
EM probe positions on Titan (left) and Rhea (right)
Figure 12.3.
Rhea EM Trace - ECDSA Signature (P-256, SHA-256).
Figure 12.4.
Rhea EM Trace - ECDSA Signature (P-256, SHA-256)...
Chapter 13
Figure 13.1.
Interaction model for IEMI (adapted from Lee (1986)).
Figure 13.2.
Threats exploiting the electromagnetic susceptib...
Figure 13.3.
IEMI-covert channel threat model
.
Figure 13.4.
IEMI-covert channel characterization setup
.
Figure 13.5.
Relationship between electric-field magnitude...
Figure 13.6.
An example 4-ASK frame as received by the covert...
Figure 13.7.
Modeling of EMW as the combination of an IEMI-co...
Figure 13.8.
Experimental setup for EMW on a UAV
...
Figure 13.9.
Example EMW channel on the vertical acceleration...
Chapter 14
Figure 14.1.
The ZLL architecture.
Figure 14.2.
The MegaRF-based bulb.
Figure 14.3.
Correlation peaks for byte j
= 1...
Figure 14.4.
Power analysis on the ATMega2564RFR2 from a Phil...
Figure 14.5.
CCM encryption mode.
Figure 14.6.
Power analysis of processing a single 16-byte bl...
Figure 14.7.
Bitwise DPA attack on AES-CTR “pad”,.
Guide
Cover Page
Table of Contents
Title Page
Copyright Page
Preface
Begin Reading
List of Authors
Index
Summary of Volume 1
Summary of Volume 2
Pages
iii
iv
xiii
xiv
xv
xvi
xvii
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
93
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
297
298
299
301
302
303
304
305
306
307
308
309
310
311
313
314
315
316
317
318
319
320
321
SCIENCES
Computer Science,Field Directors – Jean-Charles Pomerol
Cryptography, Data Security,Subject Head – Damien Vergnaud
Embedded Cryptography 3
Coordinated by
Emmanuel Prouff
Guénaël Renault
Matthieu Rivain
Colin O’Flynn
First published 2025 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the under mentioned address:
ISTE Ltd27-37 St George’s RoadLondon SW19 4EUUKwww.iste.co.uk
John Wiley & Sons, Inc.111 River StreetHoboken, NJ 07030USAwww.wiley.com
© ISTE Ltd 2025The rights of Emmanuel Prouff, Guénaël Renault, Matthieu Rivain and Colin O’Flynn to be identified as the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s), contributor(s) or editor(s) and do not necessarily reflect the views of ISTE Group.
Library of Congress Control Number: 2024945144
British Library Cataloguing-in-Publication DataA CIP record for this book is available from the British LibraryISBN 978-1-78945-215-0
ERC code:PE6 Computer Science and InformaticsPE6_5 Security, privacy, cryptology, quantum cryptography
Preface
Emmanuel PROUFF1, Guénaël RENAULT2, Matthieu RIVAIN3 and Colin O’FLYNN4,5
1LIP6, Sorbonne Université, Paris, France
2Agence nationale de la sécurité des systèmes d’information, Paris, France
3CryptoExperts, Paris, France
4Dalhousie University, Halifax, Canada
5NewAE Technology Inc, Halifax, Canadas
The idea for this project was born during a discussion with Damien Vergnaud. Damien had been asked to propose a series of volumes covering the different domains of modern cryptography for the SCIENCES series. He offered us the opportunity to take charge of the Embedded Cryptography books, which sounded like a great challenge to take on. In particular, we thought it was perfectly timely as the field was gaining increasing importance with the growing development of complex mobile systems and the internet of things.
The field of embedded cryptography, as a research domain, was born in the mid-1990s. Until that time, the evaluation of a cryptosystem and the underlying attacker model were usually agnostic of implementation aspects whether the cryptosystem was deployed on a computer or on some embedded hardware like a smart card. Indeed, the attacker was assumed to have no other information than the final results of a computation and, possibly, the corresponding inputs. In this black-box context, defining a cryptanalytic attack and evaluating resistance to it essentially consisted of finding flaws in the abstract definition of the cryptosystem.
In the 1990s, teams of researchers published the first academic results highlighting very effective means of attack against embedded systems. These attacks were based on the observation that a system’s behavior during a computation strongly depends on the values of the data manipulated (which was previously known and exploited by intelligence services). Consequently, a device performing cryptographic computation does not behave like a black box whose inputs and outputs are the only known factors. The power consumption of the device, its electromagnetic radiation and its running time are indeed other sources that provide the observer with information on the intermediate results of the computation. Teams of researchers have also shown that it was possible to disrupt a computation using external energy sources such as lasers or electromagnetic pulses.
Among these so-called physical attacks, two main families emerge. The first gathers the (passive) side-channel attacks, including timing attacks proposed by Kocher in 1996 and power analysis attacks proposed by Kocher et al. in 1999, as well as the microarchitectural attacks that have considerably developed after the publication of the Spectre and Meltdown attacks in 2018. This first family of attacks focuses on the impact that the data manipulated by the system have on measurable physical quantities such as time, current consumption or energy dissipation related to state changes in memories. The second family gathers the (active) fault injection attacks, whose first principles were introduced by Boneh et al. in 1997. These attacks aim to put the targeted system into an abnormal state of functioning. They consist, for example, of ensuring that certain parts of a code are not executed or that operations are replaced by others. Using attacks from either of these families, an adversary might learn sensitive information by exploiting the physical leakage or the faulted output of the system.
Since their inception, side-channel attacks and fault injection attacks, along with their countermeasures, have significantly evolved. Initially, the embedded systems industry and a limited number of academic labs responded with ad-hoc countermeasures. Given the urgency of responding to the newly published attacks, these countermeasures were reasonably adequate at the time. Subsequently, the invalidation of many of these countermeasures and the increasing sophistication of attack techniques highlighted the need for a more formalized approach to security in embedded cryptography. A community was born from this observation in the late 1990s and gathered around a dedicated conference known as cryptographic hardware and embedded systems (CHES). Since then, the growth of this research domain has been very significant, resulting from the strong stake of the industrial players and the scientific interest of the open security issues. Nowadays, physical attacks involve state-of-the-art equipment capable of targeting nanoscale technologies used in the semiconductor industry. The attackers routinely use advanced statistical analyses or signal processing, while the defenders designing countermeasures calls on concepts from algebra, probability theory, or formal methods. More recently, and notably with the publication of the Spectre and Meltdown attacks, side-channel attacks have extended to so-called microarchitectural attacks, exploiting very common optimization techniques in modern CPUs such as out-of-order execution or speculative execution. Twenty-five years after the foundational work, there is now a large community of academic and industrial scientists dedicated to these problems. Embedded cryptography has gradually become a classic topic in cryptography and computer security, as illustrated by the increasing importance of this field in major cryptography and security conferences besides CHES, such as CRYPTO, Eurocrypt, Asiacrypt, Usenix Security, IEEE S&P or ACM CCS.
Pedagogical material
For this work, it seemed important to us to have both scientifically ambitious and pedagogical content. We indeed wanted this book to appeal not only to researchers in embedded cryptography but also to Master’s students interested in the subject and curious to take their first steps. It was also important to us that the concepts and notions developed in the book be as illustrated as possible and therefore accompanied by a pedagogical base. In addition to the numerous illustrations proposed in the chapters, we have made pedagogical material available (attack scripts, implementation examples, etc.) to test and deepen the various concepts. These can be found on the following GitHub organization: https://github.com/embeddedcryptobook.
Content
This book provides a comprehensive exploration of embedded cryptography. It comprises 40 chapters grouped into nine main parts, and spanning three volumes. The book primarily addresses side-channel and fault injection attacks as well as their countermeasures. Part 1 of Volume 1 is dedicated to Software Side-Channel Attacks, namely, timing attacks and microarchitectural attacks, primarily affecting software; whereas Part 2 is dedicated to Hardware Side-Channel Attacks, which exploit hardware physical leakages, like power consumption and electromagnetic emanations. Part 3 focuses on the second crucial family of physical attacks against embedded systems, namely, Fault Injection Attacks.
A full part of the book is dedicated to Masking in Part 1 of Volume 2, which is a widely used countermeasure against side-channel attacks and which has become an important research topic since their introduction in 1999. This part covers a variety of masking techniques, their security proofs and their formal verification. Besides general masking techniques, efficient and secure embedded cryptographic implementations are very dependent on the underlying algorithm. Consequently, Part 2, Cryptographic Implementations, is dedicated to the implementation of specific cryptographic algorithm families, namely, AES, RSA, ECC and post-quantum cryptography. This part also covers hardware acceleration and constant-time implementations. Secure embedded cryptography needs to rely on secure hardware and secure randomness generation. In cases where hardware alone is insufficient for security, we must rely on additional software techniques to protect cryptographic keys. The latter is known as white-box cryptography. The next three parts of the book address those aspects. Part 3, Volume 2, Hardware Security, covers invasive attacks, hardware countermeasures and physically unclonable functions (PUF).
Part 1 of this volume is dedicated to White-Box Cryptography: it covers general concepts, practical attack tools, automatic (gray-box) attacks and countermeasures as well as code obfuscation, which is often considered as a complementary measure to white-box cryptography. Part 2 is dedicated to Randomness and Key Generation in embedded cryptography. It covers both true and pseudo randomness generation as well as randomness generation for specific cryptographic algorithms (prime numbers for RSA, random nonces for ECC signatures and random errors for post-quantum schemes).
Finally, we wanted to include concrete examples of real-world attacks against embedded cryptosystems. The final part of this series of books contains those examples of Real World Applications. While not exhaustive, we selected representative examples illustrating the practical exploitation of the attacks presented in this book, hence demonstrating the necessity of the science of embedded cryptography.
Acknowledgments
This series of books results from a collaborative work and many persons from the embedded cryptography community have contributed to its development. We have tried to cover (as broadly as possible) the field of embedded cryptography and the many research directions related to this field. This has not been an easy task given the dynamism and growth of the field over the past 25 years. Some experts from the community kindly shared their insights on the preliminary plan of the book, namely Sonia Belaïd, Pierre-Alain Fouque, Marc Joye, Victor Lomné and Yannick Sierra. We would like to thank them for their insightful comments.
For each of the identified topics, we wanted the book to cover, we have called upon expert researchers from the community, who have honored us by joining this project. The essence of this work is theirs. Dear Guillaume Barbu, Lejla Batina, Sonia Belaïd, Davide Bellizia, Florent Bernard, Begül Bilgin, Eleonora Cagli, Łukasz Chmielewski, Jessy Clédière, Brice Colombier, Jean-Sébastien Coron, Jean-Luc Danger, Lauren De Meyer, Cécile Dumas, Jean-Max Dutertre, Viktor Fischer, Pierre Galissant, Benedikt Gierlichs, Louis Goubin, Vincent Grosso, Sylvain Guilley, Patrick Haddad, Laurent Imbert, Ján Jančár, Marc Joye, Matthias Kannwischer, Stefan Katzenbeisser, Victor Lomné, José Lopes-Esteves, Ange Martinelli, Pedro Massolino, Loïc Masure, Nele Mentens, Debdeep Mukhopadhyay, Camille Mutschler, Ruben Niederhagen, Colin O’Flynn, Elisabeth Oswald, Dan Page, Pascal Paillier, Louisa Papachristodoulou, Thomas Peeters, Olivier Peirera, Thomas Pornin, Bart Preneel, Thomas Prest, Jean-René Reinhard, Thomas Roche, Francisco Rodríguez-Henríquez, Franck Rondepierre, Eyal Ronen, Melissa Rossi, Mylene Rousselet, Sylvain Ruhault, Ulrich Ruhrmair, Sayandeep Saha, Patrick Schaumont, Sebastian Schrittwieser, Peter Schwabe, Richa Singh, Sergei Skorobogatov, François-Xavier Standaert, Petr Svenda, Marek Sys, Akira Takahashi, Abdul Rahman Taleb, Yannick Teglia, Philippe Teuwen, Adrian Thillard, Medhi Tibouchi, Mike Tunstall, Aleksei Udovenko, David Vigilant, Lennert Wouters, Yuval Yarom and Rina Zeitoun: thank you so much for the hard work!
To accompany these authors, we also relied on numerous reviewers who kindly shared their remarks on the preliminary versions of the chapters. Their behind-the-scenes work allowed us to greatly improve the technical and editorial quality of the books. We express our gratitude to them, namely, Davide Alessio, Sébastien Bardin, Sonia Belaïd, Eloi Benoist-Vanderbeken, Gaëtan Cassiers, Jean-Sebastien Coron, Debayan Das, Cécile Dumas, Julien Eynard, Wieland Fischer, Thomas Fuhr, Daniel Genkin, Dahmun Goudarzi, Eliane Jaulmes, Victor Lomné, Loïc Masure, Bart Mennink, Stjepan Picek, Thomas Pornin, Thomas Prest, Jurgen Pulkus, Michaël Quisquater, Thomas Roche, Franck Rondepierre, Franck Salvador, Tobias Schneider, Okan Seker, Pierre-Yves Strub, Akira Takahashi, Abdul Rahman Taleb, Mehdi Tibouchi, Aleksei Udovenko, Gilles Van Assche, Damien Vergnaud, Vincent Verneuil and Gabriel Zaid.
October 2024
PART 1White-Box Cryptography
1Introduction to White-Box Cryptography
Pierre GALISSANT and Louis GOUBIN
Laboratoire de Mathématiques de Versailles, UVSQ, CNRS, Université Paris-Saclay, France
1.1. Introductory remarks
In 1883, Auguste Kerckhoffs’ article, La cryptographie militaire, was published in the Journal des sciences militaires, in which he stated six design rules for military ciphers. Here they are, translated from French:
The system must be practically, if not mathematically, indecipherable.
It should not require secrecy, and it should not be a problem if it falls into enemy hands.
It must be possible to communicate and remember the key without using written notes, and correspondents must be able to change or modify it at will.
It must be applicable to telegraph communications.
It must be portable and should not require several persons to handle or operate.
Lastly, given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules.
The second rule, now known as Kerckhoffs’s principle, has been completely taken into account in the modern cryptography concepts. More precisely, it is usually assumed, in most security models, that the attacker has a complete knowledge of the formal specifications of the cryptographic algorithms that are used to secure the communications or the storage of sensitive data.
On top of that, to make security possible, we must assume that the legitimate users (traditionally called Alice and Bob in the two-party scenarios) know a secret data which gives them an advantage over a potential adversary (usually called Charlie). Since this secret key has to be involved in the cryptographic computations, and must still remain hidden from the attacker, the classical security model in cryptography makes the assumption that it is not only the key but also the explicit implementation of the algorithm (which includes the key) which cannot be accessed by the attacker. This is the black-box model.
Nevertheless, cryptographic algorithms are increasingly deployed in various applications embedded on connected devices, such as smartphones and tablets. In this environment, the capabilities of the adversary can be greatly enhanced, and we should consider an adversary who can access the binary code, modify its execution, tamper with the memory and use existing reverse engineering tools such as debuggers to recover the hidden secrets. This white-box model is of course more demanding, and white-box cryptography aims at providing the same security guarantees as in the black-box model, despite this huge new advantage given to the adversary.
In the following sections, we will be able to provide precise security notions that capture this idea of cryptographic security in a white-box model. However, we give here some preliminary remarks to highlight the subtleties which can arise when trying to formalize white-box cryptography.
As a first tentative goal, let us consider the problem of providing an implementation of a block cipher algorithm EK for which the secret key K is computationally difficult to extract from the given implementation.
If no further constraints are given, it is not difficult to build such a block cipher algorithm, together with a white-box implementation. Indeed, we can choose E defined by:
where E′ is a standard block cipher (for instance, AES) and h is a one-way function (for instance, h can be built with a standard hash function). It is obviously easy to build an implementation such that h(K) is easy to recover, but not K. This shows that the difficulty of extracting the key does not completely capture the intuitive notion we have for white-box cryptography.
Another natural idea follows from this first remark: Can we make it computationally difficult, from the implementation of EK (i.e. the code of the function x ↦ EK(x)), to find a decomposition of the form:
for which we can explicitly obtain the code of F and the code of G? Note that in this framework, G can contain several elements. For instance, block ciphers typically use a key schedule mechanism such as G(K) = (K1, …, Kr), with subkeys Ki(1 ≤ i ≤ r), so that we have:
A typical example that would not satisfy this definition is a “one-way” key schedule:
where h is a one-way function (that can easily be built from a standard hash function).
In summary, it seems a good definition of white-box cryptography should forbid the following situation: “the code is independent of K, except constants which depend on K in a deterministic way”.
At first sight, we could fear all cryptographic implementations would therefore be forbidden! Fortunately, the possibility remains that G has, among its inputs, an external value r:
This construction is reminiscent of the randomness used in side-channel countermeasures and historically appeared to be a key idea in the seminal proposals of white-box DES and AES implementations (Chow et al. 2002), where:
Note that this also opens the way to a useful application: traitor tracing. If someone reveals G(K, r), we can recover r (in the extreme case, by exhaustive search on r). This relies on the assumption that it is difficult to deduce G(K, r′) from G(K, r) (and a fortiori K from G(K, r)).
We can also remark that such a construction can be done in the context of the RSA primitive. The fundamental idea is the following: if the encryption function is built upon x ↦ y = xe mod n, the decryption function is based on y ↦ x = yd mod n (where d is the inverse of e modulo φ(n)) and can be implemented as mod n, where d′ is an arbitrary large integer such that d′ ≡ d mod φ(n), namely, d′ = d + rφ(n). For this construction to make sense, we have to assume that e is also a secret exponent (if not, a well-known argument can be used to deduce the factorization of n from d′), so that what we obtain is an example of white-box symmetric algorithm:
Here, which instructions are executed (or not) may depend on K (typically in the case of square and multiply: “if then x := x × y mod n”). However, the knowledge of these executed instructions is equivalent to the knowledge of n and d′, which does not allow us to recover K = (e, d, p, q).
1.2. Basic notions for white-box cryptography
The basic security requirement for a white-box implementation is to resist key extraction. However, we should expect more from white-box cryptography and consider various security properties for the white-box implementations; and hopefully we provide formal definitions and security notions for white-box cryptography. In particular, Delerablée et al. (2014) defined some concrete white-box security notions for symmetric encryption schemes. For example, unbreakability, one-wayness, incompressibility and traceability are derived from folklore intuitions behind white-box cryptography.
1.2.1. Unbreakability
The notion of unbreakability is a very intuitive security notion for white-box cryptography and has been studied since the seminal paper of Chow et al. (2002).
Let us describe the game for unbreakability of a white-box compiler corresponding to a given cryptographic algorithm :
draw at random key
k
in private keyspace ;
the adversary gets the program from the compiler;
the adversary returns a key guess in time, and
τ
knows ;
the adversary succeeds if .
DEFINITION 1.1.–
Let be a cryptographic algorithm, a white-box compiler for this algorithm and let be any adversary. We define the probability of the adversary to succeed in the unbreakability game by:
We say that is (τ, ϵ)-unbreakable if for any adversary running in time τ, .
1.2.2. Incompressibility
The notion of incompressibility is a stronger security notion, first formally defined by Delerablée et al. (2014), where the study of this notion is motivated as a software countermeasure against code-lifting attacks.
We now describe, for any σ > 0, the game for incompressibility for a white-box compiler corresponding to a given cryptographic algorithm :
draw at random a key
k
in private keyspace ;
the adversary gets the program from the compiler;
the adversary returns a program knowing ;
the adversary succeeds if and .
DEFINITION 1.2.–
Let be a cryptographic algorithm, a white-box compiler for this algorithm and let be any adversary. We define the probability of the adversary to succeed in the σ-incompressibility game by:
Moreover, we say that is (σ, τ, ϵ)-incompressible if for any adversary , implies .
REMARK 1.1.–
In a more general case, the definition can include a parameter δ that allows the program to agree with the targeted function with probability δ.
REMARK 1.2.–
Note that if a compiler is incompressible, then it is unbreakable for reasonable security levels: the key-recovery is indeed an extreme compression of a white-box implementation.
The definition of incompressibility we state here is a slightly modified version from the initial definition of Delerablée et al. (2014). Indeed, the latter does not constrain the running time of the program , which leaves the possibility of a trivial way of compressing any white-box algorithm, namely, by using brute force: an attacker can compute a few (plaintext, ciphertext) pairs and code the brute-force attack on the primitives that are white-boxed, and then code the computation of the primitive, including the obtained key. This program can be made with few lines of code and is functionally equivalent to the initial white-box implementation, but has an unreasonable running time. The definition above makes use of a new time constraint: the sum of the running time of the attacker and the produced program must be less than a constant τ representing the whole computation time allowed.
REMARK 1.3.–
The previous modification does not necessarily invalidate all the proofs found in the literature for incompressibility. Indeed, in some of these proofs, the programs produced by the attacker are restrained by a model (for example, Ideal Group Model), whereas the program we mentioned here does not fit into this kind of model.
1.2.3. One-wayness
Let us describe the game for one-wayness of a white-box compiler corresponding to a given symmetric encryption algorithm :
draw at random a key
k
in private keyspace ;
the adversary gets the program from the compiler;
the adversary gets the ciphertext
c
corresponding to a randomly selected plaintext
m
;
the adversary returns a guess in time
τ
knowing ;
the adversary succeeds if .
DEFINITION 1.3.–
Let be a symmetric encryption algorithm, a white-box compiler for this algorithm and let be any adversary. We define the probability of the adversary to succeed in the one-wayness game by:
We say that is (τ, ϵ)-one-way if for any adversary running in time τ, .
REMARK 1.4.–
This one-wayness has the following consequence: the cryptographic algorithm can be used as a public-key cryptosystem. It is indeed possible to see the obtained white-box implementation as a public key, and the key K of the algorithm as the private key. The one-wayness property implies that the public key can only be used to encrypt messages, whereas the decryption requires the knowledge of the private key. This illustrates the power of this security notion.
1.3. Proposed (and broken) solutions
1.3.1. Block ciphers
Many attempts have been made to construct white-box implementations for standard block ciphers in recent years.
DES obfuscation methods were first proposed by Chow et al. (2002) at the DRM 2002 workshop. The simplest method (“naked DES”) was cryptanalyzed by Chow et al. (2003) themselves at the SAC 2002 conference; an improved method was also cryptanalyzed by Jacob et al. (2002) and by Link and Neuman (2004); the strongest known method (“nonstandard-DES”) was also cryptanalyzed independently by Wyseur et al. (2007) and by Goubin et al. (2007) at the SAC 2007 conference.
A specific obfuscation method for AES was proposed by Chow et al. (2002) at SAC 2002, and later cryptanalyzed by Billet et al. (2004) at SAC 2004 (see also Billet (2005); PhD Thesis, defended in December 2005).
Further construction attempts followed, for instance, by Link and Neumann (2004), Bringer et al. (2006), Xiao and Lai (2009), and by Karroumi (2010), but they were also shown to be insecure sooner or later, by De Mulder et al. (2010) at INDOCRYPT, De Mulder et al. (2012) at SAC, Lepoint et al. (2013) at SAC, De Mulder et al. (2013), and Lepoint and Rivain (2013). The WhibOx 2017 and 2019 contests showed that even with hidden designs, producing unbreakable and one-way AES implementations in pure software is a difficult open problem.
This illustrates that reaching the unbreakability property – and a fortiori the incompressibility property – are already difficult when implementing standard block ciphers such as 3DES or AES.
Concerning the one-wayness security notion, we already mentioned that it allows us to tranform a (symmetric) block cipher into a public-key cryptosystem, which gives a first hint that it is probably even more difficult to obtain than unbreakability.
More precisely, for usual block ciphers, the one-wayness problem appears to have a close relationship with the problem of “functional decomposition”. Standard block ciphers are indeed built from several rounds (for instance, 16 rounds for DES or 10 rounds for AES), which leads to typical implementations as a loop corresponding to a functional decomposition:
Hence, inverting EK boils down to inverting each fi, which is likely to be an easy task.
REMARK 1.5.–
A natural idea would be to compute functional compositions of the type fi ∘ fj, such that the “functional decomposition” is computationally hard. However, the problem for classical block ciphers is that the algebraic degree of such compositions grows quickly. This can even be seen as an unavoidable consequence of the fundamental principle stated by Shannon (1949) paper: breaking a “good” cipher should require “as much work as solving a system of simultaneous equations in a large number of unknowns of a complex type”. Therefore, the composition cannot be done via the representation as polynomial systems, and new strategies seem to be required here.
REMARK 1.6.–
White-box constructions (with the unbreakability and one-wayness properties) are possible if we are allowed to choose an (ad hoc) block cipher. This is reminiscent of public-key cryptography and can easily be illustrated in the context of multivariate cryptography. In a nutshell, a multivariate algorithm makes use of a function A that can be represented as a system of n multivariate polynomials in n variables and can be easily inverted. In the asymmetric setting, the secret key comprises two secret invertible linear (of affine) functions s and t, and the corresponding public key is obtained as t ∘ A ∘ s, one of the security assumptions being that recovering A from this public key in computationally difficult (this is usually called the “Isomorphism of polynomials with two secrets” problem).
This construction can be converted into a symmetric block cipher:
In summary, the idea here is that multivariate cryptography can make K difficult to extract from the implementation of EK, without having a huge algebraic degree for the “global” (and public) description of EK.
1.3.2. Asymmetric algorithms
While many candidates have been publicly proposed to construct white-box implementations of block ciphers, almost no white-box implementations for public-key algorithms have been published up to now, in spite of numerous research efforts.
In their works, Feng et al. (2020) and Zhang et al. (2020), claim to achieve unbreakability for asymmetric cryptosystems. However, their proposals require a non-standard verification process, which makes them irrelevant for genuine public-key applications.
To the best of our knowledge, the first candidate that does not change the underlying scheme is due to Barthelemy (2020a, 2020b), who proposed a white-box implementation of a scheme suggested by Aguilar Melchior et al. (2016) whose (black-box) security is based on the computational difficulty of the RLWE (ring learning with errors) problem over the cyclotomic ring .
Lucas Barthelemy’s implementation of the decryption algorithm makes use of the NTT transformation and RNS representations to reduce the computation to small look-up tables, which can in turn be transformed using ideas dating back to the SAC 2002 seminal paper of Chow et al. (2020), together with additive of multiplicative masking based on homomorphic properties of the cryptographic scheme. However, a fatal flaw was found (and acknowledged by Lucas Barthelemy in his PhD thesis): the core part of the white-box implementation consists of trying to prevent the key extraction for a function of the form α2 − α1 · sk, where (α1, α2) is the ciphertext we want to decrypt, and sk is the secret key. This function is linear in α1 and α2, and this linear dependence on the elements coming from the ciphertext remains true, even after applying the NTT transformations and using the representations RNS. It is therefore very easy for an attacker to find the coefficients of these linear transformations (which depend on sk), then sk itself.
The WhibOx 2021 contest showed that for the ECDSA algorithm, even with hidden design, getting an unbreakable implementation is out of reach: all the implementations proposed were quickly broken. In-depth analyses of the generic attacks and problems these implementations suffered were provided by Barbu et al. (2022) and Bauer et al. (2022).
Galissant and Goubin (2022) proposed a concrete white-box implementation for the well-known hidden field equations (HFE) signature algorithm (a signature algorithm belonging to the multivariate family of public key algorithms) for a specific set of internal polynomials, providing the first white-box implementation of a public key algorithm, together with an extensive security analysis providing strong arguments for both unbreakability and incompressibility. For a security level 280, the public key size is approximately 62.5 MB and the white-box implementation of the signature algorithm has a size of approximately 256 GB.
This is a promising research direction and some variants are currently being investigated to improve the size of the white-box implementation and adapt it to various security levels.
1.4. Generic strategies to build white-box implementations
1.4.1. DCA and countermeasures
In the white-box model, the attacker has access all the details of the implementation of a (known) cryptographic algorithm, including a given secret key, and the goal of the attacker is to recover the secret key. Up to now, most candidate implementations (of DES, AES, substitution linear-transformation ciphers, etc.) have been broken. Most of the time, the attacks use various cryptanalytic techniques, which require knowledge and understanding of all the implementation principles and details.
In the past years, generic attacks have emerged that apply to white-box implementations, irrespective of their (secret) designs and which consist of translating usual hardware attacks to the white-box setting. In particular, Sanfelix et al. (2015), Bos et al. (2016) at CHES, described differential computational analysis (DCA), whose principle is to apply side-channel analysis (SCA) techniques to so-called computational traces composed of all the intermediate results of the computation (bus transfers, register allocations, memory addresses, etc.). More precisely, a dynamic binary instrumentation (DBI) framework can be used to build software traces and then mount an analogue of differential power attack (DPA) on these software traces. The advantage of this technique is that – as DPA in the case of smart card implementations – the attacker does not need to know (and to analyze) the very details of the implementation. The attack can be launched in an automated way on candidate white-box implementations.
For instance, Bos et al. (2016) describe several examples illustrating the power of this DCA: the authors show that their method can break many challenge implementations, which utilize many of the ideas used up to now to build white-box implementations. This shows that an already stated principle (namely, a whitebox implementation must in particular resist all kinds of side-channel attacks) had probably not been considered seriously enough.
The lack of random source in a white-box implementation (at run-time) is a reason for the weakness against DCA, but theoretically this does not rule out the possibility of resistant white-box implementations. Therefore, a first challenge is to provide a theoretical explanation of the fact that white-box implementations, based on look-up tables, can be attacked by SCA, even when they are “hidden” by randomly chosen bijections (e.g. in DES and AES implementation by Chow et al. (2002)).
A second challenge consists of elaborating specific countermeasures against this new kind of attack.
REMARK 1.7.–
As noted by Jacob et al. (2002), and Sanfelix et al. (2015), differential fault analysis (DFA) can also be directly applied to the white-box setting, so that resisting these attacks is also a challenge for future research.
1.4.2. Using fully homomorphic encryption (FHE)
When considering DCA, we have to limit the power of the attacker, usually by bounding the “order” of such attacks. Classical ways of protecting the key are making use of the secret sharing principle, leading to so-called masking countermeasures.
In the white-box setting, such a limit is less relevant. We cannot expect noise to make the complexity of the attack grow exponentially with the DCA order. Is it therefore natural to push DCA to its limits, and try to obtain “infinite order” countermeasures? The intuition can be viewed as follows. DCA-type masking countermeasures of order n are based on the idea that the attacker cannot control more than n values, so that computing the algorithm with a “multiparty computation”-like implementation can prevent the attack. In the context of delegated computations, when no limit is assumed about the number of parties controlled by the attacker, multiparty computation is not sufficient any more, and has to be replaced by FHE.
For the more general problem of obfuscation, methods based on hard computational problems have indeed been derived from fully homomorphic encryption and the universal oblivious Turing machine. Pippenger and Fischer (1979) proved that a two-tape oblivious Turing machine can simulate any non-oblivious Turing machine with only logarithmic slowdown. The idea is then to homomorphically run the universal oblivious Turing machine, with two inputs:
where Prog is the program to be computed in an obfuscated way. Of course, the program does not appear in the form Prog but only in the form Prog′, pre-computed during the creation of the obfuscated software.
where x is the input of Prog.
To resist partial evaluation attacks and mixed input attacks, as noticed by Garg et al. (2013), the final decryption of the result has to be conditional. The condition is twofold:
Check the proof of computation of the universal oblivious Turing machine that testifies that the program
Prog
′ was indeed run (in an FHE way) on the input
x
′, and also that
x
′ =
FHE.Encrypt
(
x
) was correctly computed.
Verify a digital signature of
Prog
′, so as to authentify the executed program.
This idea can directly be adapted to the white-box context by using FHE to encrypt only K instead of the whole program Prog. For the conditional decryption, two possibilities arise. Conditional decryption can be executed within a dedicated tamper-resistant hardware, as illustrated by Bitansky et al. (2011) and Döttling et al. (2011). One more challenging direction consists of replacing this hardware part by an obfuscated (software) program. To achieve this, a line of research – starting from a paper by Garg et al. (2013) that develops a complex design based on branching programs and multilinear maps – aims at obtaining generic obfuscation methods (which here would only use the fact that the conditional decryption can be written as a NC1 circuit). However, they are still highly non-practical.
1.4.3. White-box solutions with the help of a (small) tamper-resistant hardware
Alpirez Bock et al. (2020) considered (at ASIACRYPT) an alternative use of such a tamper-resistant hardware. They build a hardware-bound white-box key derivation function (WKDF) on top of a standard (black-box) key derivation function (KDF). In a nutshell, if the adversary uses its hardware access, they are able to evaluate the WKDF, but if they have no access to the relevant hardware values, for example, in case of a code-lifting attack, then they learn nothing about the WKDF values. The design, based on techniques published by Sahai and Waters (2014), requires puncturable pseudorandom functions (PRFs, which are equivalent to one-way functions) and indistinguishability obfuscation (iO). Although interesting from a theoretical point of view, the current state of the art of iO makes the construction highly impractical.
In comparison, as described in section 1.4.2, white-box resistance can be achieved using FHE together with a (relatively small) tamper-resistant hardware that computes the conditional decryption operation. The performance overhead due to FHE is rather high, but the solution remains realistic in case we really need a single call to the hardware at the end of the computation.
Other ways of using a secure hardware component have been considered in the context of white-box cryptography (seen as a particular case of software obfuscation). For instance, Anderson (2008) described the following idea. The program to be obfuscated can be written on the encrypted memory tape of a Turing machine. Each time an operation has to be executed, the whole tape is sent to the hardware component, which decrypts it, executes the next instruction, reencrypts the tape and sends it back to the software part. This is of course very time consuming and requires a huge number of exchanges between the software and the hardware token.
A more efficient solution was described by Goyal et al. (2010). By building on techniques from resettably secure computation (due to Goyal and Sahai (2009)), they gave a general positive result for stateless oblivious reactive functionalities under standard cryptographic assumption. This result also provides the first general feasibility result for program obfuscation using stateless tokens. As a side result, they also propose constructions of non-interactive secure computation for general reactive functionalities with stateful tokens, which can be adapted to hardware-aided white-box constructions.
1.5. Applications of white-box cryptography
Real-world applications of white-box cryptography are numerous. Below are some typical examples illustrating potential use cases of white-box cryptography, either in a symmetric model or in a public key setting.
1.5.1. EMV payments on NFC-enabled smartphones without secure element
In recent years, the payment industry has shown great interest in the extension of the EMV specifications to mobile transactions via near field communication (NFC). In that scenario, the usual contactless smart card is emulated by an NFC-compliant mobile phone or wearable device such as a smart watch. This is referred to as host card emulation (HCE). Unfortunately, however, mobile platforms do not provide access to a secure element to third-party applications: the SIM card belongs to the telecommunication operator and handset manufacturers keep any form of trusted hardware for their own needs. These emerging applications are therefore facing the challenge of being as secure as a tamper-resistant hardware, although being totally based on software. White-box cryptography is currently the only approach to secure these applications and compensate the security risks inherent to common embedded operating systems such as Android. By hard-coding the EMV keys into the application code itself, as suggested in the EMVCo requirements documentation in 2019, white-box cryptography tries to achieve a notion of tamper-resistant software. Similarly, Mastercard Cloud-Based Payments (MCBP) is a secure and scalable software-based solution developed to digitize card credentials and enable both contactless and remote payment transactions. In this context, in 2017, Mastercard specifically recommended the use of white-box implementation for the secure storage of payment tokens.
1.5.2. Software DRM mechanisms for digital contents
Digital right management (DRM) is a set of techniques whereby subscribers get access to protected content under a number of conditions (access rights). Video on-demand and mobile TV are typical examples of DRM-protected services. Here again, in the absence of a hardware cryptographic module, a white-box implementation of the content decryption algorithm under an individual user key prevents the key from being recovered and re-used by third-parties (piracy based on key sharing and redistribution).
1.5.3. Mobile contract signing
The eIDAS regulation (EU Reg. No. 910/2014) came into force on July 1, 2016 in the 28 member states of the EU, and introduced the end of the smart card dogma, in the sense that the signing capability can now be implemented by purely software means as long as they fulfill specific requirements through a qualification procedure. Electronic signatures also become legal evidence that cannot be denied by sovereign authorities or in court. By relaxing constraints on the signing utility, the eIDAS regulation opens the way to software-only solutions for digital signatures. As a result, a rapid emergence of mobile contract signing is anticipated in the near future. The user experience is straightforward: a contract (or any form of document in that respect) is downloaded on the mobile device, reviewed by the human user, digitally signed locally and the legally binding signature is returned to a back-end server in the cloud, where it is validated and archived. Now, the need for the signing application to be eIDAS-qualified imposes (depending on the qualification level) resisting security threats pertaining to mobile platforms and most particularly logical attacks where some form of external control is exerted through malware, typically in an attempt to steal the signing key(s) stored on the device. White-box cryptography is the only approach that effectively puts the signing key(s) out of reach of logical attacks on the operating system. Combined with countermeasures against code lifting, white-box cryptography is expected to take a major role in the adoption and deployment of eIDAS-based services in the EU.
1.5.4. Cryptocurrencies and blockchain technologies
Most solutions to store cryptocurrencies and perform transactions on the blockchain are today based on a hardware token (USB stick, smart card) or on a mobile application. While the former provide adequate security, it is inconvenient for the wider usage. For the latter case on the other hand, the security often relies on the operating system of the mobile device and the principle of application sandboxing. Given the wide variety of mobile OS versions on the field, strictly relying on the operating system to protect critical assets (such as money) is very hazardous and should always be avoided. This raises a strong need for the design of security solutions for pure-software cryptocurrency wallet against all kind of threats such as stealing malwares. In order to protect the cryptographic keys intrinsically involved in cryptocurrencies and blockchain technologies, white-box cryptography is essential. As concerns digital signatures, ECDSA is currently the most used algorithm (for instance, Bitcoin and Ethereum), but alternatives are considered, either for other cryptocurrencies or to prepare for the post-quantum era.
1.6. Notes and further references
From a historical perspective, the term “white-box cryptography” was introduced by Chow et al. (2002, 2003) in their seminal papers in relation to the following situation: “When the attacker has internal information about a cryptographic implementation, choice of implementation is the sole remaining line of defense” (Chow et al. 2003).
Section 1.1
. Auguste Kerckhoffs published his seminal paper in Kerckhoffs (
1883a
). See also Kerckhoffs (
1883b
), entitled
La cryptographie militaire, ou les chiffres usités en temps de guerre, avec un nouveau procédé de déchiffrement applicable aux systèmes à double clef
.
Section 1.2
. The paper by Delerablée et al. (
2014
) about white-box definitions was published in 2013 in the procedings of the SAC conference. The seminal paper of Chow et al. (
2002
) was published in the proceedings of the DRM 2002 workshop; see also their paper at SAC 2002 (Chow et al.
2003
).
Section 1.3
. DES obfuscation methods, first proposed by Chow et al. (
2002
), were cryptanalyzed by Chow et al. (
2003
), Jacob et al. (
2002
), Link and Neumann (
2004
), Goubin et al. (
2007
) and Wyseur et al. (
2007
).
The white-box implemention for AES by Chow et al. (2003) was later cryptanalyzed by Billet et al. (2004) (see also Billet (2005)). Other constructions were proposed by Link and Neumann (2004), Bringer et al. (2006), Xiao and Lai (2009) and Karroumi (2011), but were all broken by De Mulder et al. (2010, 2013a, 2013b), Lepoint and Rivain (2013); Lepoint et al. (2014), Lepoint and Rivain (2013); Lepoint et al. (2014). During the WhibOx Organizing Committee (2017) and WhibOx Organizing Committee (2019) contests, all the AES proposals were eventually broken.
In his famous paper “Communication theory of secrecy systems” (Shannon 1949), Claude Shannon discussed cryptography from an information theory point of view, thus providing foundations of modern cryptography.
In the asymmetric context, white-box implementations were claimed by Feng et al. (2020) and Zhang et al. (2020), but they have to modify the verification process, so that the cryptosystem does not fit the original public key framework. Lucas Barthelemy’s candidate (Barthelemy 2020b) is a white-box implementation of a public key encryption scheme, a variant of a scheme suggested by Aguilar Melchor et al. (2016). The white-box implementation uses ideas from Chow et al. (2003), but flaws were acknowledged by Barthelemy in his PhD thesis (Barthelemy 2020a): the linear dependences allowing us to recover the secret key can be seen in the equations in section 4.2.
During the WhibOx Organizing Committee (2021) contest, all of the proposed ECDSA white-box implementations were eventually broken. Detailed analyses of the attacks were given by Barbu et al. (2022) and Bauer et al. (2022).
The recent proposal by Galissant and Goubin (2022) is a white-box implementation of a variant of HFE, a signature algorithm belonging to the multivariate family of public key algorithms.
Section 1.4
. The idea of differential computational analysis (DCA) was introduced by Sanfelix et al. (
2015
) and Bos et al. (
2016
). Its principle originates in side-channel analysis (SCA) techniques (see, for instance, Kocher et al. (
1999
) or Brier et al. (
2004
)), applied to computational traces, instead of power (or electro-magnetic) traces.
The idea of using differential fault analysis (DFA) in the context of white-box implementations was mentioned by Jacob et al. (2002) and Sanfelix et al. (2015). Basic notions about DFA can be found in the well-known papers of Boneh et al. (1997) and Biham and Shamir (1997).
A detailed survey of fully homomorphic encryption can be found in Marcolla et al. (2022). The property that a two-tape oblivious Turing machine can simulate any non-oblivious Turing machine with only logarithmic slowdown is due to Pippenger and Fischer (1979).
The idea of using a conditional decryption operation to resist partial evaluation attacks and mixed input attacks was described by Garg et al. (2013) at FOCS. This operation can in turn be executed either in a tamper-resistant hardware, as illustrated by Bitansky et al. (2011) and Döttling et al. (2011), or in an obfuscated way, following a line of research initiated by Garg et al. (2013).
A construction of a hardware-bound white-box key derivation function (WKDF) was proposed at ASIACRYPT 2020 by Alpirez Bock et al. (2020). It is based on an idea of Sahai and Waters (2014), according to which white-box can be obtained from puncturable pseudorandom functions (PRFs) and indistinguishability obfuscation (iO).
Other constructions using a secure hardware component to obtain obfuscation properties were proposed by Anderson (2008) and at TCC 2010 by Goyal et al. (2010). The latter is based on techniques from resettably secure computation, due to Goyal and Sahai (2009) at EUROCRYPT.
Section 1.5
. The extension of the EMV specifications to mobile transactions via near field communication (NFC) was specified in EMVCo (
2008
). In 2019, the EMVCo requirements documentation (EMVCo
2019
) suggested to hard-code the EMV keys into the application code itself. In the same spirit, Mastercard Cloud-Based Payments (MCBP) (Mastercard
2014
) aims at digitizing card credentials, and Mastercard has specifically recommended the use of white-box implementation for the secure storage of payment tokens (Mastercard
2017
).
1.7. References
Aguilar Melchor, C., Barrier, J., Guelton, S., Guinet, A., Killijian, M.-O., Lepoint, T. (2016). NFLlib: NTT-based fast lattice library. In
CT-RSA 2016
, Sako, K. (ed.). Springer, Heidelberg.
Alpirez Bock, E., Brzuska, C., Fischlin, M., Janson, C., Michiels, W. (2020). Security reductions for white-box key-storage in mobile payments. In
ASIACRYPT 2020
, Moriai, S. and Wang, H. (eds). Springer, Heidelberg.
Anderson, W.E. (2008). On the secure obfuscation of deterministic finite automata. Cryptology ePrint Archive, Report 2008/184 [Online]. Available at:
https://eprint.iacr.org/2008/184
.
Barbu, G., Beullens, W., Dottax, E., Giraud, C., Houzelot, A., Li, C., Mahzoun, M., Ranea, A., Xie, J. (2022). ECDSA white-box implementations: Attacks and designs from WhibOx 2021 contest. Report 2022/385, Cryptology ePrint Archive [Online]. Available at:
https://eprint.iacr.org/2022/385
.
Barthelemy, L. (2020a). A first approach to asymmetric white-box cryptography and a study of permutation polynomials modulo 2
n
in obfuscation. PhD Thesis, Sorbonne Université, Paris.
Barthelemy, L. (2020b). Toward an asymmetric white-box proposal. Cryptology ePrint Archive, Report 2020/893 [Online]. Available at:
https://eprint.iacr.org/2020/893
.
Bauer, S., Drexler, H., Gebhardt, M., Klein, D., Laus, F., Mittmann, J. (2022). Attacks against white-box ECDSA and discussion of countermeasures – A report on the WhibOx contest 2021. Report 2022/448, Cryptology ePrint Archive [Online]. Available at:
https://eprint.iacr.org/2022/448
.
Biham, E. and Shamir, A. (1997). Differential fault analysis of secret key cryptosystems. In
CRYPTO’97
