• No se han encontrado resultados

2. TIPO DE CAMBIO REAL

3.1. DISEÑO DE LA METODOLOGIA

. Preliminary work Twinscan

Twinscan is the commercial name that stands in for dual laser sta on, tool set and infrastructure. The two lasers have been fixed to the frame as seen in figure . , while their beams are chirourgically driven by a mirroring system via the same lens. In fact, a dedicated for each laser mirroring system is responsible for steering the beam over a X-Y plane. The mirror can steer the beams with an um precision over an area of x mm. The la er makes the tool capable of achieving an a ack against hardware, that resides in distant ”districts” on the die. The beams can also move rela vely to each other. To the best of our knowledge no

Figure 5.1:Twinscan prototype used from programming

such equipment was used in research so far. A dedicated controller translates a serial input (the command) to signals that are in turn communicated to the four mirrors. These mirrors steer the beams over the two X and two Y axises, one for each laser respec vely. Since the dual laser injec on sta on is a brand-new setup, for the purposes of this thesis we implemented an interface. This interface interconnects the Inspector®

func onality and graphical interface with the new commands that can be interpreted from the controller. The language of coding was Java and the difficulty in this task lies in redesign the moving-the-beams process, as it was in principal different from its predecessors. For more insight on the design choices, implemented func onality, and use-case scenarios please refer to chapter of [ ].

Setup

The setup, as described in chapter and depicted in figure . is modified to provide for the two lasers. In order to split the pulses and send them to the suitable laser, each aims at a different spot and has its own ming, a new component was posi oned between the vc glitcher and the lasers. This integrated circuit, takes the vc glitcher pulses that come at the configured offsets and outputs to each laser based on pa ern that is set by the user. The following example illustrates how the pa ern works. Let’s assume that we want to send the pulses alterna vely to each laser (as in this a ack). Let also assume that the first pulse (odd pulses) must trigger Laser A and the second pulse (even pulses) must trigger the Laser B. Then binary representa on of the sequence for the first laser is and so on. Similarly, for Laser B

the sequence is . Hence, in the spli er’s interface we must type in for laser A,

, and for laser B, AAAA AAAA AAAA AAAA. The extra bits allow for more complex pa erns than the aforemen oned.

Furthermore our setup needs a beam prism. This prism is suitable only for a range of wavelengths. The subsequent experiments were carried out with two nm laser, thus the prism was selected for the range - nm. Its purpose is to facilitate the channeling of the two beams, that are coming from different angles, into the same lens, as well as drive the reflected on the die light to the camera.

. Implemen ng the target

The first step was to implement the countermeasure and the duplica on of the encryp on process. The specifica ons we set from the outset required the comparison of the successive encrypted outputs, as well as retaining it in case the ciphertexts were not iden cal. Hence, in order to bypass the concealment of the subverted ciphertext, not only we need to inject the fault at the right ming during the encryp on process, but it is also required to skip the comparison that hides the output. The logical flow of the so ware is shown here.

c i p h e r t e x t [ ] CRYP_AES_ECB ( MODE_ENCRYPT, keyAES , , r x B u f f e r , ( u i n t _ t ) AES LENGTHINBYTES , r x B u f f e r AES LENGTHINBYTES ) ;

c i p h e r t e x t [ ] CRYP_AES_ECB ( MODE_ENCRYPT, keyAES , , r x B u f f e r , ( u i n t _ t ) AES LENGTHINBYTES , r x B u f f e r AES LENGTHINBYTES ) ;

i f ( c i p h e r t e x t . e q u a l s ( c i p h e r t e x t ) ) then p r i n t c i p h e r t e x t e l s e p r i n t ( r u b b i s h )

From the above snippet we extrapolate that one glitch, will not suffice to break the system. for instance, injec ng a fault in the encryp on but not skipping the ’if’ instruc on will mute the output. Similarly, glich- ing the CPU, thus skipping the ”if” command will not be more successful, as the correct ciphertex will be outpu ed

The implementa on of the countermeasure in C is shown in lis ng . . case ( xCA ) :

g e t _ b y t e s ( , r x B u f f e r ) ;

u i n t _ t * enc_ r x B u f f e r AES LENGTHINBYTES ;

u i n t _ t * enc_ r x B u f f e r AES LENGTHINBYTES AES LENGTHINBYTES ; // T r i g g e r p i n h a n d l i n g moved to CRYP_AES_ECB f u n c t i o n

cryptoCompletedOK CRYP_AES_ECB_no_trigger ( MODE_ENCRYPT, keyAES , , r x B u f f e r , ( u i n t _ t ) AES LENGTHINBYTES , r x B u f f e r AES LENGTHINBYTES ) ;

cryptoCompletedOK CRYP_AES_ECB ( MODE_ENCRYPT, keyAES , , r x B u f f e r , ( u i n t _ t ) AES LENGTHINBYTES , r x B u f f e r AES LENGTHINBYTES AES LENGTHINBYTES ) ;

i f ( memcmp ( enc_ , enc_ , ) ) {

send_bytes ( , r x B u f f e r AES LENGTHINBYTES AES LENGTHINBYTES ) ; } e l s e {

send_bytes ( , z e r o s ) ; }

break ;

Lis ng 5.1:A so ware implementa on of duplica on

As inferred from the snippet above we instan ate the crypto-core twice (line and ). We store the outputs in adjacent memory spaces by adding an offset of AES LENGTHBYTES ( bytes) for every itera on. The offset is referring to the posi on ofrxBufferthat contains our input, namely the plaintext. The storing in adjacent memory spaces does not have any implica on in the realis c nature of the target, it is done so only for the purpose of easy retrieval. Furthermore, since we only need to glitch one of these processes we slightly modified the second itera on by se ng a trigger only for the second encryp on process. TDuring the first itera on no trigger is raised. We also want to skip the if instruc on in line , thus forcing the target to output the ciphertext, even in the case of not matching results. Otherwise, the output is ascii zeros, or the expected ciphertext. In the following sec on we are se ng the a ack into mo on.

. A ack

The first thing to do, a er having set up the Dual laser sta on and put our board under the gun, was to confirm the first spot. Based on our knowledge of the target (described in chapter ), we have arranged a scan of a small area, with the recommended source power and dura on. We iden fied the exact m- ing from the dissassembly of the if. As show in figure . the ”if” is assembly instruc ons. We aim the branching instruc on underlined with red. The instruc ons previously to the if instruc ons, are the han-

dling the triggering, while the trigger pulse rises at the last instruc on thereof, namely atstrh r2, [r3, #24]. This was figured by connec ng the board to an oscilloscope while stepping each instruc on (de- bugging). Finally, we found the exact spot and mings, once again for the new setup. The experiment was slightly modified. In order to implement it as fast as possible, we subs tuted the line from . with if(memcmp(enc_1,enc_2,16) != 0 ) .. .

Since we were shoo ng only with one laser the ciphertexts would be iden cal, hence, counterintuitevely a successful skip would output the correct ciphertext, in any other case the output is s. The result is shown in figure . .

Figure 5.2:The assembly of our code adjacent to the if instruc on

We injected NOP’s before and a er the if in order to make sure that we do not shoot at any other instruc on with adverse results. A er me culous finetuning of the parameters we managed to raise the rate of successful glitches at %.

Now we needed a second spot where we can create a controlled fault. Looking into the results from the experiments carried out in chapter , we could find some candidates. We agreed on a spot that can produce the ciphertext

7C 66 E0 D9 41 22 88 C6 00 00 00 00 BA 54 83 FE

A er fine tuning the rate can grow up to %- %. The ming that led to the highest ra ngs is between - ns a er the trigger.

Figure 5.3:The assembly of our code adjacent to the if instruc on

The last thing we needed to figure out was the ming for the second laser shot. In the final experiment due to the so ware design we have one trigger in our disposal. Therefrom we need to figure the two offsets. Since we are using the same trigger injected in the encryp on process the first offset does not change. Hence, the offset for the glitch was configured as a random value between ns and ns. In order to find the offset for the second shot that skips the comparison, we injected a trigger into our target immediately before the ”if” we aimed to bypass. Then with the aid of the oscilloscope we measure the delay of the second trigger in comparison to the first. As described earlier the first trigger is raised right before the encryp on procedure. The second trigger would be discarded from the final target, hence we subtracted the clock cycles consumed by it (see fig . ), but also added as many as needed to find the assembly line responsible for jumping. We need to be very precise in me. The second trigger as we see rises ns a er the first trigger, therefore we expect the branch instruc on to come at an offset of ns. Figure . shows the two triggers, as well as when the encryp on and if rou nes are happening.

Having collected all this data we configured every so ware detail and we let the experiment run overnight, over a small area for the CPU region (see . ). Next day we had the objec ve. A controlled fault was in- jected in a part of the die, while the mu ng was bypassed by shoo ng the CPU, thus outpu ng the faulty

Figure 5.4:The me distance between the 2 triggers ciphertext (see figure . .

. Conclusions

In this sec on we combined the previously described single a acks into the dual laser a ack. We lever- aged the poten al that the dual laser sta on offers, to aim two vulnerable posi ons simultaneously. We described two ways on how to find the correct ming for an a ack. Subsequently, we used the previously acquired knowledge a er the characteriza on of the target, to posi on the laser on top of the correct spots. Inevitably, due to switching to the new laser sta on, re-installing so ware with the new module and refix- ing the target, we had to calibrate the coordinates from scratch and perform smaller area scans. A quick ”re-characteriza on” of the target for the correct spots was thus required. The fact that we have success- fully injected the same faults in the new setup corroborates that this approach is reproducible. Moreover, the procedure of characteriza on described in the previous chapters, and subsequently se ng up the dual laser a ack combining the components, can be applied in all commercial targets that implement similar countermeasures. We have shown how we can target these peripherals and test for vulnerabili es that lead to a bit-flip, or a faulty ciphertext. In the next chapter our findings are summed up, and we draw the conclusions that emerged during this research.

Figure 5.5:The exact me when both lasers shoot

6