 Hi, welcome to our talk. Today, Hikologa and I are going to present our paper with the title, No Place to Hide, Contactless Probing of Secret Data on FPGAs. Let's start the talk with the security of Sron-based FPGAs. Well, Sron-based FPGAs are really popular for different applications and they are used nowadays in critical applications. But there is a disadvantage of these kind of devices. And the disadvantage is that these devices contain volatile memory, so the configuration actually should be stored in an external non-volatile memory. So, and it raises actually some security issues. Let's first talk about, discuss how this configuration works. In the first phase, the designer actually designed the application, right? And so in a trusted field, in a trusted field, the designer stored this configuration into an NVM. And this configuration is called actually beta stream. So, later in the adversarial field, or in an untrusted field, the configuration of the PGA or the beta stream should be loaded from the NVM to the FPGA to configure the device. So, if the communication is not secured, the if-dropper or some, the attacker can actually if-drop the communication between NVM and FPGA to just clone the design, clone the beta stream. She might be able to reverse engineer the design based on the configuration. She might be able also to just launch some spoofing attack or just do some tampering attack and change the design. So, there is a conventional con temperature for these treats. So, this contain actually the beta stream encryption. In this case, in the trusted field, the designer load a secret red key to the FPGA. This secret red key will be stored in a non-volatile, sorry, battery-baked ramps or if-uses of the FPGA. In the second phase, the designer actually encrypt the design or the beta stream with the red key and AES algorithm. And he is stored the design actually into an NVM. Later in the untrusted field, this encrypted beta stream will be loaded to the FPGA. On the FPGA, we have AES decryptor and then it decrypts the design and finally the device will be configured. So, it seems actually to be secure but it has been shown that this kind of configuration can be broken. It has been shown that for example, using DPA, differential power analysis, you can actually extract the key during decryption of the beta stream. And the solution from different FPGA vendors was, okay, let's first authenticate the beta stream so then the attacker cannot really choose random chosen ciphertext to apply to launch DPA. But recently, we can see that the beta stream itself is itself large enough that the attacker actually can partition the beta stream into different parts and again, just launch the DPA. So, key rolling has been introduced in order to update the key after some few bytes of data in the beta stream. And finally, FPGA vendors started to integrate DPA-resistant AES cores or decryption actually cores into their FPGAs in type of ASICs, heart cores or they give the possibility to the customer to go and buy a DPA-resistant AES decryptor core for example from a third-party developer. But there is a treat also from another type of attacker which is a semi-invasive attacker. So for example, it is known that if you have a scanning electron microscope, you can actually read out the content of the if users. So if the secret rate key is stored on the if users on the FPGA, you're able to extract those keys. So the solution, which is recently introduced to many FPGAs is physically uncolonable functions. Again, you can find those paths in ASICs in many FPGAs or in next models of FPGAs which they come to the market. Or you have still the possibility to go and buy a soft IP core for the path from a third-party developer and integrate it to your device. And for those who are not familiar with the path, path is just a, it creates random keys or generate a random response based on the manufacturing values on the device. And it can also be used for fingerprinting of your device. However, we still don't see any protection for the semi-invasive attacks or fully invasive attacks from the ISI backside, for the FPGA backside, more precisely. So, but before talking about the last, the final point, let's discuss how these countermeasures work in reality. So this solution is, these countermeasures, for example, provided by Xilinx, but different FPGA vendors might have different approaches, but at the end, they are more or less the same. So in this case, in the trusted field, the designer actually load the path configuration into the FPGA and then send the secret red key over JTAG to the FPGA, right? So the path will be configured on the device. It generates its responses or we call it your path key. The path key is actually used to wrap the secret red key to generate a black key. So red, actually in our talk, meant that the key itself is not encrypted, is in plaintext, and now we have a black key which is an encrypted key, actually, on the device. So now the designer has two possibilities. Either he can just store this black key on the device or he sends the black key and the path configuration to the NBM. In the second phase, as we are in the trusted field, the secret red key will be used to encrypt the design. So and the encrypted beta stream is also a sort on the NBM. Finally, the designer maybe wanted to have also a DPA-resistant IP core which is updatable. He also loaded to the NBM. Now in the untrusted field, we need two phases of boot loading. In the first stage boot loading, the path will be configured on the device. The black key will be loaded to the device and the AES decryptor core is also configured on the device. So path generates its responses. It unwraps the black key to generate the red key and of course the encrypted beta stream in the second phase of boot loading will be loaded to the device and will be decrypted with the red key. So here as you see, the secret red key is generated instantly on the device. So it's a volatile key actually and it is undyed only signal only. So there is no way to actually read it out from the FPGA, so from the outside board. The second thing is that the path, although we have seen a lot of path attacks in the literature, so the path here is actually somewhat controlled path. So you don't have really access directly to the challenges of the path. The responses of the path are also just generated instantly on the device. The attacker has not any access to the responses of the path, right? So it's a controlled path and the traditional attacks on paths here, they don't really work. And finally, in order to raise the security, the designer can just remove the black key and the path from the FPGA in order to just don't leave any traces from those keys. Okay, so as Shain said, this red key is on the device, it's volatile, it's undyed only and we wanted to see if we can actually get to that key and the method that we proposed in our paper is a method that is established in failure analysis, which is called optical contactless probing. And this shows a basic setup for optical contactless probing, simplified version. So what you do is you have a laser, it illuminates the device through the backside, hits the transistor, some part gets reflected and then it enters a detector. And what happens is, if you apply different voltages here to this part, this will actually change the refractive index and the absorption coefficient, which means that the light that is incident on this detector, the intensity of this light will actually change. You can very basic terms think of this as transistor on, much light, transistor off, fuel light. Signal's rather small, so you have to average it, but what you then get is basically an oscilloscope which has a laser for a test lead. So you can just point your laser spot anywhere on the device. Usually this is infrared light, so you can just go through the device backside. And this technique is then called laser voltage probing. And in this case, you can just get the waveform of any transistor that you point the laser at. The interesting question for this is you have to know where the transistor actually is. And for this failure analysis has also developed a technique to find nodes of interest, which is called laser voltage imaging. And in this case, you use this signal from the detector, but instead of averaging it to get a waveform trace, you put it into a very narrow frequency filter. And if you set that filter to a certain frequency, for example, in failure analysis to the clock frequency, and then if you scan the laser beam across the device, actually only when you hit a node that carries that frequency or that frequency component, you will get a signal out of the filter. And then if you map that, for example, if you use a clock frequency in that image that you will get from the laser voltage imaging experiment, we'll show you all the clock buffers, for example. So, as I said, this has been used in failure analysis for quite a while. This poses some restrictions to you because you don't really, you have to think in the frequency domain, but we will later see how we can use that for our attack. But you have to keep in mind that it's enough if you have a frequency component that can pass the filter. It doesn't have to be like a pure sine wave. So, first I'll just give you a brief explanation of our setup. We used a TerraCyclone 4 FPGA, which is 16 nanometer technology. Laser wave length is 1.3 micrometer, and we used the proof-of-concept key calculation, which is just a simple XOR of the black key and the puff key, and we used the ring oscillator. And for an optical setup, we used a common failure analysis microscope, which is called Hamamatsu FEMOS 1000. And for the first experiment, we considered parallel implementation of the secret red key calculation. So you just take all the, you have the registers with the black key, you have the registers which contain your puff response, and then you do an XOR and parallel on these, and then they get put into the red key registers, and you want to get these. So, as I said, you probably have to think in the frequency domain to actually see something in your laser voltage imaging map. And we had the idea of the most simple approach to this is to actually induce a frequency. And we thought about this, and we used the most simple example, which is a reset loop. So you put the device in a reset loop, this is the reset signal, and then there are just two cases for the registers. The registers in the red key can either receive a one or a zero. If they receive a one, then there will be some time, for example, register A receives a one. There will be some time that's passing for the calculation, then it will go to one. Then reset is asserted, so it will go low. Then reset is released, calculation will start again, and then this will just repeat. What you can see from this is that the fundamental frequency of this signal, of this waveform, is the same as the reset frequency. So if you set your filter to the reset loop frequency, you will actually see this register in your laser voltage imaging map. The register which receives a zero, on the other hand, there's no activity there, so you shouldn't see it on the laser voltage imaging map. So what you would expect, in very basic terms, is like registers carrying a one to be white, registers carrying a zero to be black, and you get a map for the whole device. So I'm gonna show you the results for this implementation with laser voltage imaging now. These are enlarged laser voltage imaging results, so usually you scan the whole device, but this is just for the register blocks. We used eight-bit keys for our proof of concept, and you can nicely see, okay, there's some activity here, there's none here, there's some here, and you can just directly read the bits from this map. You see this is a one, this is a zero, and so on. There are some funny shapes here, which are because of the way that the transistors are organized in the logic elements inside the FPGA, but as you can see, you actually get all the keys, and this is what you are aiming for, this is a red key. What you also see is that the XOR works, which is also nice because the FPGA is actually doing an XOR, which means we didn't mess up the coding. And for the next case, we consider a different implementation. This time we used the serial implementation, so we connected all these registers and then we shifted these bits through an XOR and then shifted them into the red key registers. In this case, you can't do such a simple black-white distinction because depending on the position of these registers in the shift register for the red key, they have different levels of activity. So you can't say, okay, black means one, and black means zero, and white means one. But if you can somehow find this register, the whole key will get shifted through it, and then if you can probe this with laser voltage probing, you will get the waveform that gets put through that register, and as the whole key has to go through this register, you will then also see the key directly. And what you also have to keep in mind because the device is still in a reset loop, the fundamental frequency of all these registers is still the reset frequency, but they might have a different amount of first harmonic component, which will show up in your laser voltage imaging map. So we did this experiment. So we first did laser voltage imaging to find the registers, and then we went on to probe them. So you can see the laser voltage imaging map over here. You can see there's a familiar shape of the registers and you can see that there's actually some brightness differences, and if you do fast Fourier transform of the signals that you would expect for the registers, you can see that the ones which get more bit shifts, which are potentially more interesting, have a higher first harmonic component. So in this case, you should probably try to probe the brightest registers first, which are the ones at the bottom, and actually in the end, we used these spots over here, not the core register area, and you can see that actually this register is the shift in register, so all the key gets shifted through this and you can read the key from this. And these are registers which are further down the shift register, so they just contain parts of the key. We have seen that how we can extract or how we can directly probe the keys on the PGA, but the attacker might be interested to characterize the path itself. So in this case, we have implemented the ring oscillator path and in order to characterize this kind of path, of course you need to measure precisely the frequency of the individual ring oscillators. So, and then if the attacker has approximate frequency of the ring oscillators, she might be able to do laser voltage imaging to find the ring oscillators on the chip and then go to them and then measure precisely their frequencies. But how the attacker can get actually the estimated frequency. So what we have done, we just connected the power line of the PGA to the spectrum analyzer and then we searched in the frequency space and then we have found energy in some frequencies in, for example, I guess it was 100 megahertz. Then we could found the frequency of the ring oscillators, but because the frequencies were really close together, so the attacker cannot actually differentiate between the frequencies on the power analysis. So therefore just what she need to do is just should set the frequency filter, just run the laser voltage imaging when you find the ring oscillators, you can play with the parameters to find other ring oscillators a little bit different with different frequencies and then you can run, you can launch laser voltage probing to precisely measure the frequency of each individual ring oscillator. So let's conclude the talk. The first lessons that we have learned was that, okay, just replacing the battery backgrounds or if users with physically uncomfortable functions doesn't really increase the security as somebody might first think because if our attacker is a sophisticated attacker, so Puff also cannot prevent him or her to conduct such attack. The Puff can be controlled Puff. Actually, we didn't care how the Puff is implemented at the first place because we could probe directly the keys and if the Puff is, for example, a ring oscillator Puff, we can also characterize it in more detail. The other interesting thing was that for this kind of experiments, actually we required just minutes and hours. So and this is much less time that if you want to conduct such attack with the feet and it might be more expensive to launch it with the feet. And finally, we think that we strongly believe that if no proper countermeasure or protection for the FPGA backside is going to be implemented, the future generation of FPGAs will remain vulnerable to this kind of attack. Thank you.