Joye M.Cryptographic hardware and embedded systems.2005

436 P.J. Leadbitter, D. Page, and N.P. Smart

Then we have that where

the following calculation.

From Theorem 1, a useful heuristic for predicting the success of such a lattice attack is to check whether our target vector satisfies

It is easy to see that, for our t

and

Hence, for our lattice based approach to have a chance of succeeding, we must have

In practice is 160 and if is much larger than 300, the computation of LLL reduced bases takes a prohibitively long time. If we assume reduction of 300 dimension lattices is both feasible and results in vectors close to the minimum (which is a very optimistic assumption), we are assuming that We will recover the full secret if

i.e.

Thus we expect 10 equal bits in consecutive positions to be sufficient in our problem.

TEAM LinG

5Experimental Results

In order to get an idea of how successful this sort of attack might be, we ran a large number of experiments. Our initial goal was to sweep a reasonable area of the parameter space and determine a rough success rates for different combinations of window size and number of messages. However, as the number of messages grows the lattice dimensions and hence the time take to perform the attack also grows. This effect means that a great deal of processing time is required to perform attacks with a large number of messages. To enable completion of our experiments within a reasonable time frame, we distributed the workload across a network of around fifty Linux workstations each incorporating 2 GHz Intel Pentium 4 processors and around 512 Mb of memory. Using these machines we conducted one hundred runs of each combination of parameters and quote the success rate of these attacks in Table 1.

Each attack involved two successive LLL reductions. The first LLL application used a floating point implementation of the Schnorr–Euchner algorithm [15] using deep insertions. Due to floating point errors this only provided an approximation to an LLL reduced basis. To obtain a fully reduced basis the version of De Weger [19] was then applied to the output basis from the Schnorr–Euchner algorithm.

There are several interesting features in these results. Firstly, it is clear that window sizes below 9 and number of messages less than 20 yielded no successful attacks. In terms of window size this is unfortunate since we would expect real attack scenarios to utilise small windows, for example window widths of size 4 or

TEAM LinG

438 P.J. Leadbitter, D. Page, and N.P. Smart

5, that correspond to table indices or addresses for example. Secondly, there is a fairly polar behaviour in terms of success in that an attack seems to either work either nearly all of the time or nearly none of the time. Again, this is unfortunate from a practical stand point since as an attacker we can tolerate probabilistic success if the parameters allow more realistic choices.

The polar behaviour is a common feature of LLL experiments. For each lattice we can consider the value

We shall call function D the norm distribution of In out attack, we looked at lattices of a particular form

in which we know the size of one of the non-zero lattice points is small; our target

expect the attack to succeed. Moreover we expect it to succeed for all the other

but larger than 1. Compared to the huge number of lattice points we are dealing with dwarfs the number of experiments we were able to do, we see probabilistic success on only a few of the parameter choices.

Our results only seem to succeed for We believe this to be the limit of attacks using this style of lattice. A different lattice style could have quite a different norm distribution and could respond better to LLL, reducing our error term. This could yield much more favourable results than those presented here and remains an open problem. Indeed in the DSA attacks with several known bits, the success rate has been raised by simply inputting the information in a different way, see [12] and [13].

To get a better idea of how the attack behaves when using parameters that are ideal from an attackers point of view, we started a second set of experiments that focus on a window size of four but with much larger number of messages. We expected this to be more suitable in practice since, as discussed in Section 2, four bit indices are often used in table driven exponentiation. If capturing relations between these indices is possible, we would therefore be interested in knowing their potential for use in an attack. Unfortunately, the results of these experiments were inconclusive due to the length of time and amount of memory required to complete each one. The bottleneck proved to be the efficiency of our LLL implementation which, with a large number of messages, required so much memory to store the lattice that the virtual memory system was unable to maintain an acceptable performance level. Although negative, this second result does provide us some information in the context of our investigation. That is, forcing an attacker to collect many signatures is clearly a good way to foil attack in a practical situation since performing the lattice reduction is too computationally hard.

TEAM LinG

6Conclusions

We have presented an interesting extension of prior work on lattice reduction used in the context of side-channel attacks. We weaken the assumptions of previous work so that it is more probable that the profiling phase of an attack will recover useful information, even when defence measures are deployed against other techniques. By extending prior work that assumes an attack can obtain the value of secret information by allowing them simply to uncover relationships between different parts of said information. This is especially dangerous in the context of signature schemes such as DSA/EC-DSA where such leakage can totally reveal the underlying secret.

However, the results from our experimentation are not as positive as the initial attack scenario. We found that the attacker would need to collect relationships about a large number of bits in contrast with knowing the value of a small number of bits in previous work. Such large relationships would be difficult to collect with existing side-channel analytic techniques and, in this respect, further work is needed to extend the attack. We expect that continued research into physically obtaining bit relationships from a target device and more efficient implementations of the lattice reduction stage might make our attacker more feasible in the future.

References

1.M. Bellare and S. Goldwasser and D. Micciancio. “Pseudo-Random” Number Generation Within Cryptographic Algorithms: The DSS Case. In Advances in

Cryptology – EUROCRYPT ’97, Springer-Verlag LKNCS 1233, 277–291, 1997.

2.D. Bleichenbacher. On the generation of DSS one-time keys. Preprint, 2001.

3.D. Boneh and D. Brumley. Remote Timing Attacks Are Practical. To appear in

12th USENIX Security Symposium, USENIX Press, 2003.

4.N. Howgrave-Graham and N.P. Smart. Lattice attacks on digital signature schemes. Designs, Codes and Cryptography, 23, 283–290, 2001.

5.K. Itoh, T. Izu and M. Takenaka. Address-Bit Differential Power Analysis of Cryptographic Schemes OK-ECDH and OK-ECDSA. In Workshop on Cryptographic Hardware and Embedded Systems (CHES), Springer-Verlag LNCS 2523, 129–143, 2002.

6.K. Itoh, T. Izu and M. Takenaka. A Practical Countermeasure Against AddressBit Differential Power Analysis. In Workshop on Cryptographic Hardware and Embedded Systems (CHES), Springer-Verlag LNCS 2779, 382–396, 2003.

7.P.C. Kocher. Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. In Advances in Cryptology – CRYPTO ’96, Springer-Verlag LNCS 1109, 104–113, 1996.

8.P.C. Kocher, J. Jaffe and B. Jun. Differential Power Analysis. In Advances in Cryptology – CRYPTO ’99, Springer-Verlag LNCS 2139, 388–397, 1999.

9.A.K. Lenstra, H.W. Lenstra and L. Lovász. Factoring polynomials with rational coefficients. Math. Ann., 261, 515–534, 1982.

10.T.S. Messerges. Using Second-Order Power Analysis to Attack DPA Resistant Software. In Workshop on Cryptographic Hardware and Embedded Systems (CHES),

Springer-Verlag LNCS 1965, 238–251, 2000.

TEAM LinG

440 P.J. Leadbitter, D. Page, and N.P. Smart

11.B. Möller. Parallelizable Elliptic Curve Point Multiplication Method with Resistance against Side-Channel Attacks. In Information Security (ISC), SpringerVerlag LNCS 2433, 402–413, 2002.

12.P.Q. Nguyen and I.E. Shparlinski. The insecurity of the Digital Signature Algorithm with partially known nonces. J. Cryptology, 15, 151–176, 2002.

13.P.Q. Nguyen and I.E. Shparlinski. On the insecurity of the elliptic curve digital signature algorithm with partially known nonces. Designs, Codes and Cryptography, To appear.

14.W. Schindler. A Combined Timing and Power Attack. In 5th Workshop on Practice and Theory in Public Key Cryptosystems (PKC), Springer-Verlag LNCS 2274, 263–279, 2002.

15.C.P. Schnorr and M. Euchner. Lattice basis reduction: improved practical algorithms and solving subset sum problems. In Proc. FCT 1991, Springer-Verlag LNCS 529, 68–85, 1991.

16.Y. Tsunoo, E. Tsujihara, K. Minematsu and H. Miyauchi. Cryptanalysis of Block Ciphers Implemented on Computers with Cache. In International Symposium on Information Theory and Its Applications (ISITA), 2002.

17.Y. Tsunoo, T. Saito, T. Suzaki, M. Shigeri and H. Miyauchi. Cryptanalysis of DES Implemented on Computers with Cache. In Workshop on Cryptographic Hardware and Embedded Systems (CHES), Springer-Verlag LNCS 2779, 62–76, 2003.

18.C.D. Walter and S. Thompson. Distinguishing Exponent Digits by Observing Modular Subtractions. In Topics in Cryptology (CT-RSA), Springer-Verlag LNCS 2020, 192–207, 2001.

19.B.M.M. de Weger. Solving exponential diophantine equations using lattice basis reduction. J. Number Theory, 26, 325–367, 1987.

TEAM LinG

How to Disembed a Program?

(Extended Abstract*)

Benoît Chevallier-Mames1, David Naccache1, Pascal Paillier1, and

David Pointcheval2

1 Gemplus/Applied Research and Security Center

{benoit.chevallier-mames,david.naccache,pascal.paillier}@gemplus.com

2 Ecole Normale Supérieure/CNRS

david.pointcheval@ens.fr

Abstract. This paper presents the theoretical blueprint of a new secure token called the Externalized Microprocessor Unlike a smartcard, the contains no ROM at all.

While exporting all the device’s executable code to potentially untrustworthy terminals poses formidable security problems, the advantages of ROM-less secure tokens are numerous: chip masking time disappears, bug patching becomes a mere terminal update and hence does not imply any roll-out of cards in the field. Most importantly, code size ceases to be a limiting factor. This is particularly significant given the steady increase in on-board software complexity.

After describing the machine’s instruction-set we introduce a public-key oriented architecture design which relies on a new RSA screening scheme and features a relatively low communication overhead. We propose two protocols that execute and dynamically authenticate arbitrary programs, provide a strong security model for these protocols and prove their security under appropriate complexity assumptions.

Keywords: Embedded cryptography, RSA screening schemes, ROMless smart cards, program authentication, compilation theory, provable security, mobile code.

1Introduction

The idea of inserting a chip into a plastic card is as old as public-key cryptography. The first patents are now 25 years old but mass applications emerged only a decade ago because of limitations in the storage and processing capacities of circuit technology. More recently new silicon geometries and cryptographic processing refinements led the industry to new generations of cards and more complex applications such as multi-applicative cards [7].

Over the last decade, there has been an increasing demand for more and more complex smart-cards from national administrations, telephone operators

* The full version of this work can be found at [6].

442 B. Chevallier-Mames et al.

and banks. Complexity grew to the point where current cards are nothing but miniature computers embarking a linker, a loader, a Java virtual machine, remote method invocation modules, a bytecode verifier, an applet firewall, a garbage collector, cryptographic libraries, a complex protocol stack plus numerous other clumsy OS components.

This paper ambitions to propose a disruptive secure-token model that tames this complexity explosion in a flexible and secure manner. From a theoretical standpoint, we look back to von Neumann’s computing model wherein a processing unit operates on volatile and nonvolatile memories, generates random numbers, exchanges data via a communication tape and receives instructions from a program memory. We revisit this model by alleviating the integrity assumption on the executed program, explicitly allowing malevolent and arbitrary modifications of its contents. Assuming a cryptographic key is stored in nonvolatile memory, the property we achieve is that no chosen-program attack can actually infer information on this key or modify its value: only authentic programs, the ones written by the genuine issuer of the architecture, may do so.

Quite customizable and generic in several ways, our execution protocols are directly applicable to the context of a ROM-less smart card (called the Externalized Microprocessor or interacting with a powerful terminal (Externalized Terminal or XT). The executes and dynamically authenticates external programs of arbitrary size without intricate code-caching mechanisms. This approach not only simplifies current smart-card-based applications but also presents immense advantages over state-of-the-art technologies on the security marketplace. Notable features of the are further discussed in Section 7 and in the full version of this work [6]. We start by introducing the architecture and programming language of the in the next section. After describing our execution protocols in Sections 4 and 5, Section 6 establishes a well-defined adversarial model and assesses their security under the RSA assumption and the collision-intractability of a hash function.

2The Architecture and Instruction Set

An executable program is modeled as a sequence of instructions where is located at address for off-board. These instructions are in essence similar to instruction codes executed by any traditional microprocessor. Although the instruction set could be similar to that of a 68HC05, MIPS32 or a MIX processor [10], we choose to model it as a JVML0-like machine [13], extending this language into XJVML as follows. XJVML is a basic virtual processor operating on a volatile memory RAM, a non-volatile memory NVM, classical I/O ports denoted IO (for data) and XIO (for instructions) , an internal random number generator denoted RNG and an operand stack S T , in which we distinguish

transfer instructions: load pushes the current value of (i.e. the memory cell at immediate address in RAM) onto the operand stack. store

TEAM LinG

pops the top value off the operand stack and stores it at address in RAM. Similarly, load IO captures the value presented at the I/O port and pushes it onto the operand stack whereas store IO pops the top value off the operand stack and sends it to the external world. load RNG generates a random number and pushes it onto the operand stack (the instruction store RNG does not exist). getstatic pushes onto the operand stack and putstatic pops the top value off the operand stack and stores it into the nonvolatile memory at address

arithmetic and logical operations: inc increments the value on the top of the operand stack. pop pops the top of the operand stack. push0 pushes the integer zero onto the operand stack. xor pops the two topmost values of the operand stack, exclusive-ors them and pushes the result onto the operand stack. dec’s effect on the topmost stack element is the exact opposite of inc. mul pops the two topmost values off the operand stack, multiplies them and pushes the result (two values representing the result’s MSB and LSB parts) onto the operand stack;

control flow instructions: letting be an instruction’s index, goto L is a simple jump to program address L. Instruction if L pops the top value off the operand stack and either falls through when that value is the integer zero or jumps to L otherwise. The halt instruction halts execution.

Note that no program memory appears in our architecture: instructions are simply sent to the microprocessor which executes them in real time. To this end, a program counter is maintained by the is set to 1 upon reset and is updated by instructions themselves. Most of them simply increment but control flow instructions may set to arbitrary values in the range To request instruction the simply sends to the XT and receives via the specifically dedicated communication port XIO.

SECURITY-CRITICAL INSTRUCTIONS. While executing instructions, the device may be fed with misbehaving code crafted so as to read-out secrets from the NVM or even update the NVM at wish (for instance, illegally credit the balance of an e-Purse). It follows that the execution of instructions that have an irreversible effect on the device’s NVM or on the external world must be authenticated in some way so as to validate their genuineness. For this reason we single-out the very few machine instructions that send signals out of the 1 and those instructions that modify the state of the non-volatile memory2. These instructions will be called security-critical in the following sections and are defined as follows.

Definition 1. A microprocessor instruction is security-critical if it might trigger the emission of an electrical signal to the external world or if it causes a

1 Typically the instruction allowing a data I/O port to toggle.

2 Typically the latching of the control bit that triggers EEPROM/Flash update or erasure.

TEAM LinG

444 B. Chevallier-Mames et al.

modification of the microprocessor’s internal nonvolatile memory. We denote by the set of security-critical instructions.

As we now see, posing is not enough. Indeed, there exist subtle attacks that exploit as a side channel. Consider the example below where denotes the NVM address of a secret key byte

The will require from the XT a continuous sequence of instructions

followed by a sudden request of and the value of has hence leaked-out.

Let us precisely formalize the problem: a microprocessor instruction is called leaky if it might cause a physically observable variable (e.g. the program counter) to take one of several possible values, depending on the data (RAM, NVM or ST element) handled by the instruction. The opposite notion is the one of data indistinguishability that characterizes those instructions for which the processed data have no influence whatsoever on environmental variables. Executing a xor, typically, does not reveal information (about the two topmost stack elements) which could be monitored from the outside of the As the execution of leaky instructions may reveal information about internal program variables, they fall under the definition of security-criticality and we therefore include them in Following our instruction set, we have

3Ensuring Program Authenticity

VERIFICATION PER INSTRUCTION. To ascertain that the instructions executed by the device are indeed those crafted by the code’s author, a naive approach consists in associating a signature to each instruction e.g. with RSA3. The program’s author generates a public and private RSA signature key-pair and embeds into the The code is enhanced with signatures where denotes a deterministic RSA padding function4 and ID is a unique program identifier.

Note that the instruction address appears in the padding function to avoid interchanging instructions in a program. The role of ID is to guard against code mixture attacks in which the instructions of two programs are interchanged. The keeps the ID of all authorized programs in nonvolatile memory. We consider the straightforward protocol shown on Figure 1.

3 Any other signature scheme featuring high-speed verification could be used here.

4 Note that if a message-recovery enabling padding is used, the storage of P can be reduced.

TEAM LinG

How to Disembed a Program? 445

Fig. 1. The Authenticated (inefficient)

This protocol is quite inefficient because, although verifying RSA signatures can be relatively easy with the help of a cryptocoprocessor, verifying one RSA signature per instruction remains resource-consuming.

RSA-BASED SCREENING SCHEMES. We resort to the screening technique de-

vised by Bellare, Garay and Rabin in [4]. Unlike verification, screening ascertains that a batch of messages has been signed instead of checking that each and every signature in the batch is individually correct. More technically, the RSAscreening algorithm proposed in [4] works as follows. Given a list of messagesignature pairs one screens this list by simply checking that

At a first glance, this primitive seems to perfectly suit our code externalization problem where one does not necessarily need to ascertain that all the signatures are individually correct, but rather control that all the code seen by the has indeed been signed by the program’s author at some point in time.

Unfortunately the restriction has a very important drawback as loops are extremely frequent in executable code (in other words, the may repeatedly require the same while executing a given program)5. To overcome this limitation, we introduce a new screening variant where, instead of checking that each message appears only once in the list, the screener controls that the number of elements in the list is strictly smaller than (we assume throughout the paper that is a prime number) i.e. :

This screening scheme is referred to as The security of for where is a full domain hash function, is guaranteed in the random oracle model [5] by the following theorem.

5Historically, [4] proposed only the criterion This version was broken by Coron and Naccache in [9]. Bellare et al. subsequently repaired the

scheme but the fix introduced the restriction that any message can appear at most once in the list.

TEAM LinG