Jean-Louis Lanet, Laboratoire XLIM: (near) Fact or fiction?

Introduction

Every type of communication connected by a network suffers attacks.  We are used to protecting our computers, but more recently mobile telephones and tablets are subject to attack. Recently a German researcher managed to execute foreign code in a SIM card via the telecommunications operator. We will present how an element as secure as a pin card can be highly suceptible to such attacks.

PRESENTATION (transcript in English)

My presentation is called, 'Virus in a card - (almost) fact or fiction?'

And so the question is to know if everything that we know in the accepted digital world of networks and systems, is this something that is transferable to a world which is closed, something which is known to be rather resistant

and so finally we're going to try to see that certain things are possible

So my presentation will quickly touch upon the different types of attacks, we're going to show a type of programming, which is rather uncommon

Because the environment is not a healthy one, it's necessarily an environment that is unhealthy

So we're going to have to think not about a traditional programming, but a very defensive programming

they were going to say a few words about chip and pin cards, based on Java which today represents 50% of what is produced

So what we're going to call "open cards", and out of this 50% of "open cards", 90% of them are Java.

The 50% of cards that are not "open", and so these , are cards that we are going to call "native", ones that have been written directly in C, or a system integrator,

are essentially for applications meant for television, that type of thing

so at the end are going to see how it is possible to mount an attack, how it is possible to de-synchronize code, and will have things run which do not in fact exist, basically to show that it is totally usable to create hidden code in something

So, normally when we are thinking about secure systems, we are always going to think about two things

the first is that it will operate according to the function that we expect, so we're going to do everything we can to make sure that this functionality  is obtained

and in particular one of the things that will allow us to do this, will be to prove that the system exhibits the expected behavior

so that is the minimum, what we expect of the functionality, but once we start to talk about the digital world,

the worlds in which we've got money or other things at stake,

we are going to have to ask for more

we're going to have to have an absolute trust that what must not happen doesn't happen

Which is much more difficult to demonstrate 

and so to demonstrate that which must not happen doesn't happen, well we can always try a proof,

very difficult, and we're going to have a number of abilities, to demonstrate and analyze using tools, to have an absolute trust in what we it is we are doing

so the pin card is an object which we refer to as "resistant" - it is certainly not tamperproof, but it is tamper-resistant

and when I say resistant, it means that it will give in at at some point in

so a pin card, like all systems, will succumb to an attacker

the most important is to slow down the amount of time the attacker needs to take over the system as long as possible, 

So a large part of how we are going to program these systems can be found in traditional practices, ways of doing things that card makers know very well,

and which exhibit a significant expertise and how such applications are created

3:36

attacks come in three types

the first type is well we're going to call on "invasive attack"

it is invasive because at the moment the attack is made, the circuit becomes unusable, we're going to physically break into the chip and install probes on the interior of the chip

the layer of silicon will be raised up, and probes will be installed on the internal buses of the chip

so this requires an enormous amount of material that is extremely expensive and currently it is government agencies (that use this technique),

today we know that the DGSFR uses it, a certain number of large organizations, and that's about it

So this type of attack is quite restricted to those that know how to perform reverse engineering, reverse engineering being important in this situation

because it allows for the detection of any trojan horse in the material, 

generally our pin chips, of which we produce few in europe, hardly any anymore, are manufactured in developing countries, and it is very difficult to guarantee that the circuits do exactly what they are supposed to

and so today this is one of the most difficult challenges, is to know whether or a not a material trojan horse has been hidden inside...

well the solution here is to open it up and analyze it, which is very time-consuming and costly

so the first type of attack is generally only found in the large essentially state-run laboratories

the second type of attack is what we will call the 'side-channel' - this is a leak in information

every processor which processes information will actuate transistors

when a transistor is actuated, and only when it is actuated, consumes energy, and will use this energy based on its previous state and the state to which it is actuated

The same can be said for a transistor, when it is actuated, it generates a magnetic field, and so all it takes is to insert an electro-magnetic sensor near the silicon substrate, or to simply measure the electrical consumption

and this can give anyone an idea of what is going on with the processor

so the big attack, the one which is the best known, is called the 'RSA'

Here you have on the right, what we would call the 'naÏve method' of the RSA, the RSA is an asymmetric-key algorithm,

and by the naïve method, we can imagine that we can take a mutlitplication, either followed by a square root or not, according to the bit key

by simply looking at the electrical consumption, if you square it, or if you were to square it and then multiply it, you wouldn't have the same level of consumption

so you are immediately able to the value of the secret pin code

so that is the type of attack on pin cards that worked very well 10 years ago, and now we see today such attacks are carried out on devices that are even more prevalent, smartphones

and so here we really see the idea that according to the way in which I program someting, that it should be thought out according to the external environment

so last year, at the RSA conference 2012, very simple, we were able to collect any number of SIM codes from Android phones simply by putting an antenna next to them

all that was required was to initiate an HTTPS session, and we did exactly the same type of analysis on the electromagnetic readings and it is very simple to discover the pin codes

So why is that? Those that are responsbile for the crypotography in telephones don't necessarily have the same 'culture' as those who work on pin cards

and so they used algorithms, such as the naïve method algorithm that I showed you, 

or based on the behavior of the key bit, we will see different behaviors

7:35

This type of attack here, is the type of breach that is carried out by university laboratory,

all that's needed is an electromagnetic meter, €800, a rather robust oscilloscope, €20 000

all that's left are things that are quite easy to get one's hands on,

this is the type of attack done by Master's/Graduate students

Now we're going to see about the last type of attack, what we will call an attack by 'harrassing'

These attacks' origins can be found in a paper, from about 15 years ago, where a researcher took flash photography of the interior of their desktop computer

and it turned out that the computer got out of control - what happened?  The photographic flashes were in of course photons, 

the photons penetrated the plastic layers of the inner-components of the computer, came in contact with the silicone substrates, and then once in contact with the silicon transformed into electrons,

which led to the actuation of transistors, etc...made the system break down

so based on this explanation, this attack has been significantly improved upon, and now we have this attack with lasers, fibre-optic lasers

so all it takes is bring one of these lasers close enough to your system's silicon, and fire the laser

this laser shot brings introduces energy into the system, so of course it is important to correctly choose the right type of laser, the right level of energy, at what time, how long to expose the system, etc...

there are many parameters, but it shows that we are capable by introducing energy into a silicone substrate, to change the state of the system memory, change the values which are communicated through the buses, or change the operation of the processor

which means that the attacker has the ability to control the computer system practically from outside of the system

so these are attacks which are very delicate, very difficult to get around, 

we know that today, every bank card, every card put into use by banking institutions, all have laser detectors, which are thus capable of sensing a laser in the interior and immediately self-destruct if such a thing happens

it is still possible that if the laser is outside of the range of the sensor, there can still be unwanted effects

so going from here, about four or five years, a new way of thinking developed,

ideas about changes to the code itself,

to be able to install a secure code into a pin card, and then because of exposure to a laser, this previously secure code becomes unsecure

this was one of the questions that were asked,

and there were certain pin card manufacturers which found that yes, things like this are possible, and so the question then became, how far can we go?

so that is indeed the question; Am I able to hide something in a code which is secure, and then by exposing the system to a laser, activating that which is hidden and destabilizing/compromising the system?

so this is the notion of changing a system, if we could have a look on a Java-based program,

so here you have on the right a program which makes a debit, and if the pin code is validated, the payment is accepted, if not, it's not allowed to make a debit without the right pin code

if we think in terms of binary code, java binary system integrator, my method will result in 8 100, when the return equals 0, it jumps to 59; if not, it continues

what is in binary will translate as the if equivalent will be 60

now if we imagine a laser shot at the system, we can imagine as well the dynamic funcitoning, that is to say what is going to happen in the system on the Java pin

12:00

and so, eventually, there will be a refernce uploaded, when there will be another to replace it, this method will be applied, the reference is removed and a boolean becomes available, and in the if equivalent, the boolean will then be removed, and then it will be empty afterwards

So once it will be empty, now imagine there is a laser shot on the system, the laser will have been able to completely saturate the transistors,

either all of the transistors will go to '1', value FF, or they will all go to '0', value 00

that is going to depend upon the technology used in the silicon

let's imagine hypothetically that the transistors all go to zero, so in the program, the value which corresponded to 'if', if one were able to play on this value here,

at value '0', the value zero in Java is 'nope', so the processor will make a 'nope', will then consider that the operand has made an instruction, 

so the destination of the jump becomes an instruction, which will then become a POP instruction,

which will take something from the stack,

and if we finish in this Java reasoning, whether the pin code is validated not, the debit is authorized

so here we can see the possibility of this type of attack

now of course a good pin card manufacturer would never write a code such as this, they would necessarily double the 'if' statements,

that is to say, they would write, 'if pin is validated,' if yes, 'if pin is not validated,' has there been a change in the fundamental state of this system between each evaluation?

if it was validated before, and it became invalid afterwards, it's because there was a laser attack

it has to be validated twice in a row in order to be sure that there was no laser attack

so this means that when you will write Java code in the area of pin cards, you must remember that later on your system will be attacked, and so you need to have a built-in redundancy

you can't just write a simple code; you have to think as though you are under attack

14:20

so now if we are thinking in terms of a stack, that is to say 'will I be able to detect that there was a laser attack by simply visualizing the code?' - well in fact we see that at the end the stack looks as though it did in the beginning

so it is not possible to just think about the execution sequence here, you are going to have to think about it differently

so we see that if you want to write Java code for a pin card, you have to do so with the idea in mind, this will be attacked

and so now we can ask ourselves the question, what will be the effect of the attack on my code?

the effect of the attack on the code could simply be to change a single bit of memory, ROM, where the code for the program is stored

but also the code can be changed during the transfer via the bus,

and in such a case, we're dealing with a transient attack, an attack that will not repeat itself, one which will not be permanent

the consequence of this is that the control flow of my program will be skewed, it will do something else, perhaps it will jump a sequence, it might not evaluate a command, etc...

so we are also used to, when working with pin cards, storing things using RAM, storing things in the memory, and therefore storing things in the execution stack itself,

why do this? simply that, when their is a laser attack, we are going to have position ourselves in terms of X, Y...on a nanometric table, perform laser shots, systematically, until change in the code is obtained

however, if the code is stored within the stack, it will in fact physically change places/move around,

and so any getting any result with a laser attack is much more hit and miss, if you work in the RAM memory

so finally we see that good programming thinking is all about thinking how you can defend your system from an attack

16:39

so now we can think about this; I've got Java card - which is what?  It's Java, and I've got programs that I compile together, and I am left with a binary, which I will classify into a char.

this is the world of Java, but if you want to put this into a pin card, it is very small, has very little memory, and so you will necessarily have to compress information

and this compression will essentially be on character chains, which take up a lot of space for not much,

so we will have a tokenization, a process by which we will replace the character lines with numerical values

so we will have a virtual java engine, separated into two pieces, one part that will be inside the card itself, and the other outside of the card

the exterior component will consist of system verifications, application signature, 

that which will be loaded is qualified with a key,

and then the conversion operation is performed,

in order to have the compact version, what is called a CAT file, which is semantically equivalent to a JAR file, just compressed

and so the CAT file is what is loaded into pin cards

17:57

so this a file that is highly compressed, and which is designed to be loaded, linked, and saved to the memory as simply as possible

so there is an enormous amount of redundant information here to make this go faster,

and particularly with the link, the edtion of the terminal links

the company Oracle designed this format to accelerate the saving of information to the memory

and we see here that there are parts that are relatively easy to attack

so here it is obvious to think, just as any students learning about system security, can I do a buffer overflow?

well that seems quite literally improbable, but in fact yes, it would seem that the buffer overflow, a classic move, we can do it here

that is to say do return-oriented programming, change the return value, to an address which I control, so that when the information exits, it goes where I want it to and not where it is supposed to

if we look closely at how this works in Java,

in Java you've got a zone of variables, local variables, which is the previous stack, and you've got a zone which is unknown,

a system zone, which totally belongs to the system owner/administrator, and over that you've got your stack which is used to push information to the top or back down, etc...

and so when you make a method call, you have the method address and then the parameters, and then you do an invoke, which does at this particular moment, by putting the stack to the method call,

the parameters which were found in the evaluation stack become the locale of the new execution line

so if we look closely here, we have at Locale 0, 1, 2;

once again a system zone where we will find information that will allow us to use what we had before, to go back, and then we will find ourselves with the new evaluation stack

20:21 

so now if we were to regard this program which is rather simple, here i have a Public Void method, which is not static, of which I have the 'this', with the parameter L0,

I've got one parameter, L1, a second parameter, then two locations, so I have three arguments, plus the 10,

and I have two locations, L4 and L5, in which I use a short, which I put in 'J', which I then copy into 'I'

A very simply program

And now if I start thinking in terms of binary Java, well that gives exactly this,

here I get back 'J', my address, I'm going to store it in Location 5, so that which is at the top of the data I am going to store in Location 5,

I load the contents of 5 and then store them in 4, that's exactly what I'm doing here, the contents of 'J', I am storing them in 'I'

If now, I try to manipulate my binary file and I transform it into this, store L4 in location 7,

what 7?  there is no 7... this doesn't bother the system however, it is going to store it in the seventh location

in most situations that doesn't pose any problems, it stores it in the seventh location

so what is the 7th location?  it is that place which is forbidden, the zone which is unknown, and in most sitiuations, the max + 2, corresponds to the return address

so you can write however you like the return address of your program

if the return address is a table, well then you will jump over to your table

the return will send you to this table, and what do you put into your table? whatever you like...

and you are completely capable to do return-oriented programming in this type of application

so here we see that we are capable, by using a program, to mount an attack by using a shell code in an environment where it is not authorized

perhaps you would ask me, is this really possible?

there are counter measures, most manufacturers install defenses, however quite surprisingly, not a single one of them verifies the locations,

you're allowed the use of three locations, but if you write more than that, it poses no problems,

so here we have to think in terms of cost by calculation, how much would it cost to test the calculation each time a location is evaluated?

it's expensive, it's very expensive, to do such a test

there are others which calculate the return address, they use an X/OR with a constant, which means if you put in your own address, it won't correspond to something and when it performs the return, it will go where you hadn't planned

there are those also that verify that we can't jump outside of a method,

so here we see that certain manufacturers have counter measures, others have fewer, it's going to depend on the nature of the pin card manufacturers

so here what we see is that we are able to direct the flow control where we want, ok but to what end?

well to be able to run a shell code...and what can we do with that, we can push up to the top of the stack, go back down, make additions at the top of the stack,

which is rather meager, that doesn't really allow us to do much; we managed to establish the avenue of attack, but with no teeth,

what would be good, is if I were able to apply a method, to say, run such and such method,

 such that, running a method, it is dynamically resolved by the linker,

and from the outside, it is impossible to know the address of this or that method

so, we are going to ask the card, give me all of your addresses please,

how are we going to do that,

24:35

so I already told you that with the file cap, this is a file that is built to accelerate the addition of links,

so there a number of components, which will be loaded one after the other, and in particular there is one which is very useful,

which is called the reference location, excuse me, so what is going to happen, once I do a static invoke, I've got a token, so invoke method 6,

remember that in Java, 6 is a reference for the constant pool, so this is going to give us, once you will have linked, you will go look for the class in the class method 10, and then you will jump there

and here, this component here, be careful, once you will have loaded the binary at address 8B, you've got a token that needs to be resolved,

the 8A is a static invoke, and 006, is the token,

so the system, the line editor, is simple; it loads this, with the table it goes where it is supposed to, and once it receives this, it will replace it with what it had stored in the physical memory,

very good, so from here, on the inside of the card, the system is going to resolve the address of my token, and will physically place my static invoke at the address 8553, for example, and it will give me the right address after that for my method

so I will actually do a invoke for my method,

so here we have a view related to the inside of the card,

let's imagine the following program, I have done a static invoke of a token, I put at the top of the stack 2A, I do S-return, what does the program do?

once I have loaded it into the card, it sends back 2A,

this is exactly what I have asked, go up to the top at 2A, perform S-return, a short, and it will indeed send back this here

ok so now what I can do is simply this:

put up at the top of the stack not an invoke, but what you are going to resolve and perform a return,

so what the system is going to do is that within its reference location, it is going to find what it is supposed to resolve, it is going to search its value, and resolve it,

and as it is an SS push, push it up to the top of the stack,

now I know that at the end, that this method with this card, has been linked to the address 0539

now I am able to, in a shell code, to perform invoke 0539, if I put in the right parameters beforehand, and bingo it works

and so it rather quite simple, rather realistic, to obtain the complete mapping for each card of these internal addresses

so going from here, we have earned the right to create a relatively elaborate shell code

so here we have also had some fun doing something, this is one of our publications,

this is a dictionary that we have, on side I have a token, on the other side I've got addresses, and so we can imagine a card which attacks itself,

it is essentially a compiler - we have transformed the linker into a compiler, and we can have a reference location with every address lined up one after the other, 

and that we consider that each has its own tokens, and behind that, there is address data, and these addresses are treated as operation code, and it executes this operation code one after the other

so we can see that we are capable of transforming a card into one that attacks itself by generating its own code

28:44

so to come back to the harrassing attacks, so we have seen that these are logical ways of attacking, which every graduate student is capable of doing, it requires practically nothing, a reader which costs €7, a €4 card, so with €11 we can get into this,

so every graduate student at our university knows how to perform this type of operation and run malicious shell codes

so now we are going to come back to the harrassing attacks, which are attacks used on cards/products, 

so we saw earlier that this is possible thanks to the help of a laser which injects energy into a code, and based on where the laser is aimed, well-aimed or not, you have a transformation of the code itself in the program,

the program being attacked has changed, mutated,

so in the industry, it is pretty much accepted today that the model of the attacker, their capacity to harrass; they are capable of firing their laser when they like,

they have the ability to be as precise as they need, as on an X-Y axis, they know how to fire exactly where they like,

30:00

they can even target on single cell, imagine what it is a single cell in a silicon substrate,

it's very small, that is why they have to fire with laser diodes and fiber optics,

and the effect that we will obtain wil either be the restart at 0, a total saturation of the transistors, 0, or FF.

so the memory result will either be 0 or FF, or for the high-end cards, the cards for which the memory is encrypted, so in these cards, it is unknown,

that is to say to fire a laser at such a card, it will definitely set something at zero, but according to the ecryption algorithm, the real value that will be returned will necessarily different

and that, we cannot at all know what it is

so considering this type of attack, there is a French card manufacturer, called Oberthur, based in Bordeaux, which published 4 years ago (generally card manufacturers don't cause their own attacks, they really know how to do everything, but they publish very little), 

here everyone was rather startled to see a card manufacturer publish something that said 'we are able to attack our own cards, and here we have published the results...
and so, the idea here is to show that we are capable of causing a transient error, that is to say attack the bus, and to create typical confusion in the Java,

what is a typical confusion in the Java? recall the inheritance tree in Java, you've got an object, you derive a type T1, T2, T3, and you must respect this hierarchy,

however, you can completely declare a pointer on T1, T2, and you want to say that your T1 is a type of T2, restricted to a part of T1

this is totally allowed, these are the parts of T2 which are inherited by T1, that you are allowed to write into the code,

and in terms of code, this will appear as a check cast

you load a sort of T2, you load a sort of T1, and you check to see that T2 is indeed in the tree of T1

so dynamically, there is a check cast that happens at this moment, as T2 is a sort of T1

but you also could write in a pointer T3, and you can say that your T3 is a type of T2 which is brought to the shared aspects of T3

which is false, but you can still write it

so here, your check cast won't work, and dynamically you'll have at the time of execution, a class cast exception,

which is to be expected, T3 is not in fact a sort of T2,

so the company worked from here, and what they did was to define the first class, which only had one field,

a short size, and then a second class, which was a table, of a dozen or octets,

and then inside this you can say that your A, in fact is a B,

my class is a table, evidently, dynamically, this will never work, but you can still write it in the code,

simply you will just have afterwards a check cast,

which is going to hit a wall,

and you can also say however that your A size, your field A, you can give it a large value,

so now dynamically what will happen is once the check cast is executed, is the table a sort of object, it will be refused at the time of execution

33:45

if we look now at the execution in terms of electrical consumption, here is the command that is sent to the pin card, it performs a certain number of operations, but at the end it responds, there was a Java exception, your check cast hit a snag, you are not allowed to perform such a conversion , it is totally forbidden

and so the following operation will consist of verifying at what moment the check cast is performed, and so after a few manipulations, you are able to verify that the check cast was performed at this moment here,

this here has the pattern, the electrical signature, of a check cast, and you fire a laser at this moment here, and the result is 90 00, which in the world of cards says, everything went fine, 

if you fire this laser here during this pattern, which we know very well how to measure based on the beginning, it took place in the processor, and so if you fire the laser for the right amount of time starting from this point here, the check cast is not executed

well you might say 'ok, but what does that do for us?'

that gives us the fact that we can say that we have two pointers, one pointer which will point to a table, and the same which will point you to your object, but this will be the same thing, we are in fact going to point to the same thing

on the one hand I consider that it's an object, on the other that it's a table

if here you change the first field, the only field in fact of object A, and that is to say physically, that is going to be the meta-data of your table,

and the company Oberthur is demonstrating that this meta-data is in fact the size of your table

so a little later when I will perform the A=0XFFFF, I am going to dynamically change the size of my table

and therefore every object that would have been allocated by the system, I can quite simply read them

I am able to read the contents of the memory

so here we see the power of this attack by Oberthur,

which they took even a little further, saying,

we've got here two objects, if one of the objects is a short and the other is a pointer which is worth 0, on the one hand you can write a short as how you like, and on the other you can write it like an address,

you are capable to manipulate your system as you want,

and by reading the contents of your object, you utlimately manipulate the entirety of your memory mapping,

of course there exist run-time checks which will prevent one from mapping out the entire memory, despite all of this, the attack by way of the table is an attack that will function perfectly well,

so you might ask yourselves, why on Earth would a manufacturer publish something like this?

in fact there were two competing manufacturers, one was thinking to put in a bi-code verification system, which the other said wouldn't help at all,

because the other claims that you are loading something into the card which is right, and then you execute something which isn't,

so whatever you do beforehand, whether it be an audit, a code revision, no matter what, whatever it is that you load, it's clean, you can do nothing,

this is indeed the power of the attack, you are dynamically changing the code of your program,

so we continued to work on this angle here, and then we worked on changing the flow control,

so in card Java, in order to avoid having codes that are too long, all of the jumps are either going to be with a small offset, 127, or in a large offset, which explains the instructions, 'goto', 'goto wide', 'if', 'if wide', etc...

and the 'wide' is going to offer 2 bites which will allow you to jump farther than what was planned,

and so this is very simple to attack - you've got to make a loop, with enough elements so that the compiler generates a 'goto wide', the 'goto wide' is going to give you a jump backwards,

so, remember that in Java everything is signed, so you are going to do a jump of FF17, that is to say 223 bakcwards,

let's imagine that there is a laser fired at this octet here, you go by a jump forward, if you manage to completely nullify your octet, you've got a forward jump, 

of which I have complete control over,

if the card memory is encrypted, what does that give me - a probability of 1 out of 2 to change the direction of the jump, a probability of 1 out of 2 by laser shot to change the jump,

and so you can do whatever you like,

and so here instead of jumping backwards you are able to julp forwards, all that's needed is to put your shell code behind this code here,

so in order to put this code, there are many ways to do it, either you put in a static table, or you put in dead code, which will then jump into the code, and you would then be able to execute your shell code,

so now the question becomes, if you don't jump on an opcode, but on an operand, well this is even more interesting,

which means that we will be able to hide things within for example,

39:56

so here we have seen that we were able to create the shell code that we wanted, and in particuler call the API method, there are certain API methods which are extremely sensitive,

for example, Get Key, Get Key is 'give me clearly the content of the key which is stored and numbered in secure container,

go ahead and map the memory, you'll never find a thing, because it is encrypted,

now the method Get Key is the one where you give soemthing numbered and it gives it back to in clear text, 

so it is a very sensitive method, all rules today say that you should never use the method Get Key in any Java card application,

so what we are going to do is to hide this method here within our code,

and in order to do so, we are going to use a code 'lambda', the part B1 is the part 'lambda' in our method, the part B3 is the part with which I am going to make my information come back out,

and the part B2 is the code that I want to hide, which is a call for Get Key, and I'm going to put in the key content, as well as the exit buffer,

and in order to do this, it is enough to think about, I am hiding code which must be linked beforehand, when I perform a Get Key, it is the linker which is going to tell you where it is,

as are going to hide it, we've got to hide a code which is linked,

so at the beginning the compiler is going to give me an invoke interface, without performing the resolution,

and like the previous method, I have obtained all of the addresses, and so now I am able to do the work of the linker,

I resolve the addresses, so now I have indicated the addresses, so I now obtain the card code in the state it would be in if it were linked,

that would be this one here,

now I insert an instruction by making everything come back up, and it is an 'if' instruction, without giving it an argument,

it doesn't have an argument, the jump destination is not given, 

and if I ask it to execute this, my program will become this; if lower or equal, and if my interface instruction becomes the operand of this instruction here,

the operands invoke the interface, and will be treated like operators,

so here I have code which no longer corresponds to what I had before, which is completely clean, which if ever audited, would show nothing,

so, I am able to load this, give this to someone, have them evaluate it, perform any static analysis, the code is clean, and undetectable,

at the time of execution, perhaps that won't do much, but you can hide it,

if at the time of execution a few weeks later, it is put into the card, there it goes out into the world, you get back the card, you fire a laser at the 'if lower or equal',

this will transform into a 'nope',

conclusion; the processor will run operand 8-1, and I find the code which I wanted to hide,

43:31

Ok so we have found at least one, at least one way to do this, and behind this what is there,

well it's just a problem of resolving the constraints, you've got code, you've got the memory in its state at a given moment, until the end of your first block, what is the following code that you should put between the first and the end of your clean code, such that your code is correct based on a certain number of constraints,

which will be, there is no stack underflow, there is no stack overflow, you've put the right number of elements, etc...

it's just a question of resolving the constraints, no more and no less,

perhaps you're going to tell me, wait wait, we can hide malicious code, give it to an operator, who is going to put it into real SIM cards, and then it cannot be detected?

Well yes you can detect it, because if you were just to do a brute analysis, you would verify that if each opcode, that if they were changed and you could see what they become afterwards, with a strong-handed analysis you would be able to detect this attack,

so that means that 2 days will be needed using a good machine, with a reasonable code, in order to verifiy any potential mutation,    

44:59

since 2011, the German certification group says that one laser shot is two laser shots; today attackers know how to perform two laser shots using the same execution line,

so now we are dealing with an unaffordable complexity in terms of brute analysis,

so if the attacker model is in fact a double laser shot, it is undetectable,

the good news here, the only good news here is that one's capacity to insert instructions diminshes with each laser shot, 

that is to say that, each time a attacker wants to shoot into a system, they will have to resynchronize based on the original code, and their ability to add instructions, in fact the breadth of instructions will decrease, very quickly,

and when we are talking about 4 laser shots, they can only insert 2 instructions,

and so the language which one is able to hide is relatively weak,

so there is a small area on which we don't really have any solution, between 2 and 3 laser shots, we don't really know how to handle it,

but that means that the attacker has mastered the technology of two consecutive laser shots in the same command line,

so what did we see today?

we saw that, on cards, no matter what level of student is able to write shell codes and execute arbitrary shell codes, we are able to collect the part of the pin card by the entirety of its API addresses, 

so we can write relatively elaborate shell codes with which we run invokes,

we have seen that with these shell codes, we are able to have them put into products, and hoping that a laser shot will activate this code,

we have seen that it is totally reasonable to supposed that we can even hide a particular code within another, because I don't want it to be visible,

so today the people that work on this type of subject, so first it's us in Limoges, there is Telecom Paris Tech in Paris, they are very good at this,

also very good at this is the Ecole des Mines St Etienne at Gardanne, there they have perfectly mastered the laser technology,

and abroad, we'll see a little in Europe, this one in the Netherlands, and the Royal Holloway in London,

and that's about it,

few people, it's really a field that is small, few people are interested in this type of thing, apart from TGA, ANSSI, the Centre for Certification, the Labos des Vals, etc...

and the card manufacturers, obviously,

so this is essentially research in the private domain, apart from a handful of academics that are interested by this type of problem,

so there you have it, I am free for any questions you might have on the topic