 Hi, my name is Florian Stoltz and in the next 20 minutes I will talk about our paper Lifeline for FPGA protection in which we present a flexible IP protection scheme based on obfuscation and this work was jointly done by the University Bochum, the Max Planck Institute for Cybersecurity and Privacy and the UMass Analyst. Now let's first of all talk about the motivation for our paper and for this we need to look at the current situation and we see that FPGAs are used in many products such as industrial automation or machine learning. Of course when a company creates a new FPGA based product they usually do not create the whole design on their own but they can license pre-made third-party IP cores which of course reduce the development costs and minimize the time to market. We also observed that various security relevant domains use FPGAs for example aviation, medical appliances or the military and all of these designs need some kind of protection because you don't want the attacker to manipulate the design or to copy your design without paying for a license. Now some people suggest that ASICs are an easy solution to this problem because they are harder to reverse engineer but FPGAs are usually preferred because they can be adapted to new requirements on-flight because they can be reprogrammed after manufacturing. So now let's go one step further and look how the FPGA security has been impacted in a negative way in the last few years. So it has been shown various times that the bitstream encryption engine on FPGAs can be vulnerable for example via side channels or implementation attacks. Most recently and I'll show it in the paper the unpatchable silicon. Furthermore projects such as Simbiflow and Xray aim to reverse engineer the exciting bitstream format which of course opens the door for manipulation and reversing. And lastly advances in gate level that this reversing makes it then possible for an attacker who dump the bitstream to understand the design and see what's going on. Such legitimate use of course puts the IP vendor and the user at stake because as I just explained the effort for for example counterfeiting is lowered. Also the attacker might try to manipulate the design and insert faults. This can of course lead to secret keys being leaked and so on and so forth. Now to understand why state of the art solutions might be not sufficient we need to look at what a real world attacker can actually do. So what he can first of all do is perform a static analysis so he dumps the bitstream and then puts it into some kind of tool and looks at the net list. But from such a static design he might not be able to infer all the information he needs. So in the next step he can do some dynamic analysis for example by simulation or by on-chip debugging. In the case of on-chip debugging he can hook a logic analyzer to certain wires and try to understand and see how the modules interact with each other and what values they exchange. Lastly he can try to perform some kind of design manipulation so for example he can cut a wire and he can see how the FPGA for example reacts to such a manipulation. So an ideal solution should provide some protection against all of these techniques which the attacker can perform. To show the ineffectiveness of state of the art solutions we performed a case study on an industrial solution by a large security vendor. And I will now quickly tell you how this solution works and why it doesn't provide sufficient security under our attacker model. So first of all here you see our FPGA and there is an IP core present and it's connected to an authenticator. The authenticator has some secret values spread around the net list and it uses it to calculate a hash. Additionally we have a separate chip on the PCB which also provides a hash. Both of them are fed into a comparator and only if they match the enable line will be pulled high and then the IP core starts working. Now the problem is that both the authenticator and the IP core are already present after the initial configuration. Therefore by dumping the bitstream we can analyze and find the connection between the authenticator and the IP core. By setting the appropriate bits in the bitstream we can cut the wire connection between the authenticator and the IP core. And by doing this the enable input is always automatically pulled high and the IP core starts working even though the authenticating process may fail. Furthermore the secret values which the authenticator uses to calculate its hash are just spread around the net list and we can find them using netlist reversing. We can then modify them and take advantage of this to for example change the hash. Furthermore we looked at academic solutions and found that many of them do not suffice under our real world attacker model. First of all many use fixed decryption keys and as I have just shown you we can extract them using static analysis. Other solutions use weak paths as a unique device identifier however the interaction between the path and the authentication model is not protected. Therefore we can manipulate the wires and perform eavesdropping to find out what values are exchanged and use this to our advantage. Lastly many use commonly used obfuscation schemes such as finite state machine obfuscation. However it has been shown that these kind of obfuscation schemes can easily be circumvented. So with these things in mind let's look what we need to consider when creating an effective IP protection scheme. And first of all we need to consider several facts. In particular we cannot rely on the secrecy of the bitstream format because as I said there have been several projects which for example successfully reverse engineered the silence bitstream format. Secondly we cannot assume that the bitstream encryption engine is flawless so we can also not rely on the encryption. So what we essentially need is some kind of trust anchor which reliably tells us if we are running on a licensed FPGA. However this FPGA might be attacker controlled so we should defend against several kinds of analysis techniques and we should also defend against design manipulations. And we propose that a sound obfuscation scheme can provide such a primitive. And the idea of our scheme lifeline is that we combine hardware obfuscation with a soft core running obfuscated software. Of course lifeline should provide protection against our real world attacker model so we should protect against static analysis, simulation, ownership debugging and of course against design manipulations. And the key idea of our scheme is that we change the static data flow in hardware to a dynamic one and I will tell you a bit later how we do this. And we change the static control flow in software to a dynamic one and you can look into our paper for more information on that. And what we further do is we bind the hardware to the software so we make them depend on each other. Hardware cannot function without software and the software cannot function without hardware. And we show that this provides a real increase in security and protects against a real world attacker. So now let's talk about the obfuscation process that we combine to create lifeline. And we will start with partial reconfiguration which has actually already been around for more than a decade. And this feature allows you to configure parts of your FPGA on the fly and the other parts will just continue working without any interruption. For this you just designate an area on your FPGA referred to as a reconfigurable partition and then you generate a bit stream for this partition. Later you can just load this bit stream on the FPGA and it will configure this part of the FPGA on the fly. So as you might remember we abused the fact in the industrial solution that the IPCore and Authenticator were already present after the initial configuration and that they were connected to each other. We break up this connection. As you can see in the picture the IPCore and the Authenticator are completely separate. Furthermore we make the IPCore a reconfigurable partition and leave it empty after the initial configuration. Therefore the attacker only gets an incomplete netlist and cannot analyze the IPCore. He can only see our Authenticator. And we only configure the IPCore when we are sure that we are on a licensed FPGA. Therefore all interactions between the Authenticator and the IPCore are implicit. Furthermore we can use this feature to transfer data between registers without actually connecting them with wires. And for more information on that you can look into our paper. And with this primitive we achieve anti-static analysis as the attacker only gets an incomplete design as I already said. And in some cases we also defend against simulation in case the vendor does not provide simulation of partial reconfiguration. For example silence does not have the tools for it. But this might vary depending on the vendor. And here you can see again a picture of partial reconfiguration. And as you can see here we have a reconfigurable partition which would be our IPCore. And we have a partial bitstream which will be provided by our Authenticator. And only if all authentication checks passed successfully we will successfully decrypt the partial bitstream. Send it to the configuration port which will then put it into the reconfigurable. Now let's talk about our next obfuscation primitive based on crosstalk. Crosstalk describes an analog effect which can happen when two wires are very close to each other. When this is the case they can influence each other's channel delay. This will lead to setup time violations and so on and so forth. So typically you don't want this in your design. However by creating a transmission wire and a receiver wire we can on purpose induce such delays into the receiver wire and measure them. Thus creating a covered communication channel. And so we don't need any physical connection between two circuits to transmit data. Now for an attacker this is very difficult to reverse engineer by just looking at the gate level netlist. He also requires some routing information to find out what the wires are actually routed in the FPGA. However even then he cannot infer what data we are actually transmitting. So this as I just said defends against static analysis but also against simulation as we cannot simulate such analog effects. And also we defend against on chip debugging as the attacker requires an FPGA from the same family. If he just takes any FPGA and not from the same family and he applies crosstalk to it he will not get the right results. So here you can see our crosstalk circuit. On the upper side you can see the input. So we take our input and put it through an encoder and pattern generator. This will transform our data into a serial stream of bits. These bits are then put on the transmitter wire which you can see there. Then on the lower side we have the receiver side. And as you can see right next to the transmitter wire is the receiver wire which is hooked up to a ring oscillator. And depending on which bit you would transmit this ring oscillator will either be faster or slower. So we hook up this ring oscillator to a binary counter and count the pulses. And if it's faster we have more pulses and if it's slower we have less pulses. So by evaluating the count we can decide what bit was transmitted. So as you can see here in our experiment there's a clear difference between a 1 and a 0. In case we transmit a 1 the ring oscillator oscillates faster. And in case we transmit a 0 the ring oscillator is slower. Of course you can see that there are some outliers here but by appending a check sum to our transmission we can correct errors or we can cause a retransmission to get rid of this error. So now let's talk about our last primitive called BIMAT which stands for Bitstream Manipulation Detection. And with this we implement self-integrity checks in hardware. And what we basically did is we took a concept from software classification and transferred it to hardware. So if you want to know if your configuration was tampered you can perform a readback of an FPGA. However this readback will give you the whole configuration so it will take time and of course it will take space. However in our case we are not interested in manipulations outside of our authenticator. For us the important part of the design is the authenticator. Therefore we only want to analyze it. And with BIMAT we achieve this. And furthermore we can spread out these integrity checks temporally. So we don't do it all at once but we can make it for example dependent on the control flow in software. And with this primitive we defend against on-chip debugging as we can now detect if the attacker eavesdrops on our connection. And we can of course detect design manipulations. And here you can see an overview of a switch matrix. And as you can see the green wire is the original connection. Now what the attacker could do is in the first case he cuts the green wire and connects it somewhere else. And in the second case he doesn't touch the green wire at all but he adds another connection. And with this he can eavesdrop for example on the values we transmit. As an example let's say we want to protect the input to the configuration port from eavesdropping and manipulation. For this we can use Vivado's internal place and route report analysis tool to get a list of inputs which feed into the configuration port and the routing information for the signal. We can then turn this list into frame addresses, word indexes and bit indexes. So on a sidings FPGA a de-configuration is split into different frames. Each frame consists of 101 words and each word is 32 bits wide. And in a simplified view each bit represents a connection. So we can specifically check if some bits are set or not which represent the connections to the configuration port. And can influence the control flow of the authenticator based on this information. Now let's finally talk about live line over flexible IP protection scheme which uses all of the application parameters I explained earlier. And now I will give you a quick overview of how it works. So first of all we have the customer who requests the usage of an IP core and attaches a unique hardware ID to his request. This might be the exciting device in a audio output of a path. The vendor then generates our authenticator and runs the key generation. The key generation includes the unique hardware ID as well as integrity information signals inside the authenticator. He then encrypts the IP core with this key and sends back the authenticator and IP core bit stream back to the customer. Here you can see an overview of live line. On the right side you can see the protected IP core which is left unconfigured after the initial starter. And on the left side you can see the authenticator. The main part is the soft core. In our case a self-written RISC-5 core. It's connected to BRAM which holds the authentication software as well as the encrypted partial bit stream of the IP core. Of course the software is also obfuscated. Now to authenticate the device the software also runs the key generation and for this it queries different peripherals. First it queries the unique device ID and the connection between the device ID and the soft core is protected via BIMAT. And furthermore it's obfuscated using crosstalk. And the soft core is also connected to the reconfiguration controller. And the controller first of all provides the data necessary for BIMAT. And of course it's also responsible for configuring the IP core later. And the connection between the RISC-5 core and the reconfiguration controller is also protected via BIMAT. Now let's look at the security of live line. And first of all let's look at the hardware side. So as I said the IP core is only successfully configured after the authentication. If the attacker performs any design manipulation or eavesdropping the key generation will fail. It will also fail if the device ID doesn't match. In this case the decryption is still run but with a wrong key which results in a broken IP core. And as I said eavesdropping can be detected via BIMAT. Now let's look at the software side. And we use state of the art obfuscation which can withstand automated tools. We also employ cyclic integrity checking to identify if the attacker wants to manipulate the software. This essentially creates a chicken or egg problem for the attacker. Because the attacker cannot analyze the hardware isolated from the software. And he can also not analyze the software without having some kind of simulated hardware. Because they won't function without each other. Now let's analyze the overhead created by live line. And let's start with the hardware. For this we evaluated it on a Cylinx Zynx7000 board. And as you can see we didn't use many resources. We only used around 3000 luts and 3000 flip flops and a few BRAM slices. Let's now look at the time overhead created by the key generation if our soft core is running at 100 MHz. And I want to emphasize that we used a very unoptimized soft core which doesn't have any pipelining. So by using a more efficient core these timings can be minimized. And as you can see after only 560 milliseconds we were able to generate the key which can be used for the decryption of the partial bit stream. After the reconfiguration our solution does not create any further time overhead as the authenticator deactivates itself when the IP core starts working. So in conclusion in our paper we first analyzed the state of the art of IP protection schemes and showed several weaknesses under a real world attacker model. We then defined what an efficient IP protection scheme has to defend against. Next we explained several new obfuscation primitives and then showed how we can combine them to build a flexible and low cost IP protection scheme. Well that was all from me. If you have any questions then feel free to write me an email and thanks for your attention.