 Welcome! I'm Max and I will present the main results of our paper Doppelgänger Obfuscation exploring the defensive and offensive aspects of hardware camouflaging. Let's begin. The process of engineering typically describes going from a high-level description to a finished product. And the direction back, going from a finished product to a high-level description, typically referred to as reverse engineering. Applying this to hardware, so hardware reverse engineering, typically means taking a chip, opening it up, delaying it, imaging it, stitching those images together to obtain a net list of the chip and then analyzing this net list to gain an understanding of the hardware design. If I now want to protect against reverse engineering, the main tool at hand is obfuscation. With obfuscation, the engineering part is basically unchanged, but the reverse engineering part, going back from the finished product understanding it, becomes insanely difficult. And the goal of obfuscation is to add a tremendous overhead for a reverse engineer. It's important to note though that it only says insanely difficult and not impossible and we will see in a second why. When I talk about obfuscation, you will most likely think about the traditional logic-level obfuscation first, which takes something like this electric pole and obstructs its functionality. So in both cases, the electric pole will distribute the power, but in the picture on the right, it's much harder to make out where the power goes exactly. And if we now take a look at our big picture of hardware reverse engineering, this traditional logic-level obfuscation impedes the understanding of the hardware design. So in other words, the hardware is correctly analyzed, it's correctly laid out, the net list is there, but understanding the functionality of the net list is now much harder because it's much more difficult to comprehend. In this work, however, we are concerned with low-level obfuscation. And here against the example of the electric pole, a low-level obfuscation leaves the thing unchanged on the outside, as the name suggests. The obfuscation is rather applied to the insides of the thing that is obfuscated. And in the example of this power pole it could, for example, route a power line internally to make it unclear where it's going. And if we apply this now to our big picture, the low-level obfuscation will actually impede the recovery of the net list itself. So the analysis of the components of the chip will actually be wrong or incomplete, resulting in a wrong or incomplete net list, and therefore also the understanding may be wrong. This is exactly what we want to achieve with low-level obfuscation. And in our paper we provide the first generic obfuscation scheme that is based on low-level obfuscation as a building block, and we explore both the defensive potential, but also the offensive potential of low-level obfuscation. So let's jump right in. Doppelgänger in a nutshell creates a design that has a visible functionality and also a different hidden functionality. And the visible functionality is the one that a reverse engineer will eventually recover when analyzing the chip, but the hidden functionality is the one that is actually executed. So we create an asymmetry between what a reverse engineer sees and what is actually computed here. And we can do all kinds of interesting stuff with it. Doppelgänger itself is applicable to arbitrary encoding logic. So some logic, as you can see on the right, that depending on some conditions, outputs a specific symbol. This is a very abstract concept that you can apply, for example, to finite state machines that based on some conditions transition to a different state, bus addresses, counters and so on. All of these things are on a high-level encoding logic. And as I already said, it's based on low-level obfuscation and in this case on the building block of camouflage gates with dummy inputs. So let's take a deeper look on those. This is a normal three-input OR gate. And what a reverse engineer would see is that the output Y is the OR over its inputs A, B and C. But if this was now a camouflage gate with a dummy input, it could actually look like this, that it ignores the input B and only computes the OR over inputs A and C. But to a reverse engineer, it still looks like a very normal perfectly fine three-input OR. And for these camouflage gates with dummy inputs, actually scientific and commercial instantiations are available. So we take those as a given building block and work with them. The only requirement that we have for these camouflage gates is that they are indistinguishable from their genuine counterparts in the standard reversing process. And standard is important here. We specifically say that dedicated deobfuscation methods may exist. This is fine. But they must be too expensive to be applied preemptively. So in other words, without any initial suspicion, nobody would use these techniques just for fun because they are way too expensive in terms of time or money. And if this is given for the obfuscated gates at hand, then they can be used to instantiate the doppelganger technique. So let's talk about the core mechanics here. From a workflow point of view, the designer creates a visible functionality, creates a hidden functionality, and then the doppelganger algorithm will output one design that has both of these functionalities combined. And of course, both functionalities cannot be arbitrarily chosen. They have to be close, in a sense, and details on that are given in the paper. So the main mechanic here on how this works in a simplified way is to cleverly select the encodings for the output symbols. Let's make an example. We have the visible functionality, where we want in some case to output the symbol s, whatever s is now. And in the hidden functionality, so the one that is truly executed, we want to output symbol t. So if we achieve this, a reverse engineer will see, oh, this encoder outputs s, but if we execute or run the chip, then it will actually output t in that condition. And what we require now is that the encodings of s and t overlap. And this overlapping is actually quite intuitive. A overlaps B, if A has a one bit, wherever B has a one bit. Or in our case, we could create an encoding like this, where s is encoded in binary 101 and t in 100. And now s overlaps t, because s has a one bit, wherever t has a one bit. The cool thing is now, we can take the term that computes the additional one bit in the s encoding, so the lowest bit of our encoding, and connect this term to a dummy input of a camouflage gate. And now what will happen in the computation is that this term is completely ignored, because it's connected to a dummy input. And the circuitry looks like it's computing the output 101, but it is actually computing the output 100. So the whole circuitry outputs the symbol t instead of the symbol s. And this is the main mechanic here, but it's more precisely explained in the paper. So the core principle here, the main takeaway is that instead of adding new signals or circuitry s is commonly done in obfuscation, we obfuscate by ignoring existing signals. And this is a very important different co-operating. So now that we know how doppelganger works on a very high level, let's have a look at the defensive potential. So let's now actually apply doppelganger and see how well it works. The scenario we chose here is a cryptographic co-processor. So we have a chip where a user sends a key and plaintext and gets some encrypted cipher text out. And the goal is to protect this hardware design against reverse engineering of its exact functionality. The design is built as follows. We have a random number generator. We have an AS module. Of course, we need a mode of operation. So we chose CBC, but this works for other modes, of course, as well. We have a transmitter and a receiver module and some registers for plaintext, key and output. And the whole state machine looks like this. You don't have to read it completely. Let me just guide you through and you only have to remember like the general functionality here. The chip initializes, of course, and then awaits some control. And if the control command says, I will send you a new key, it will receive the key, will generate an IV accordingly and transmit this IV back to the user. And if it receives a plaintext, it will load the plaintext and the previous output and store the X of them for the CBC mode and then encrypt this combined value and send the output back to the user. So the state machine facilitates a whole ASCBC coprocessor in this case. And what we now did to obfuscate is we chose the hidden functionality, our true encryption in CBC mode. And as the visible functionality, we changed the mode of operation. So we want to have this design appear to a reverse engineer as if it would be an encryption in CFB mode, but it's actually an encryption in CBC mode. And the cool thing is that only four signals have to be connected to dummy inputs to achieve the necessary changes in the state machine. You can see the changes here marked in red where we have several state transitions that were modified and also one bus transmission as you can see in the lower right. And with these changes, the doppelganger technique could be applied here and we have the exact desired functionality. The interesting thing is that the change to the design that was necessary to have both of these in place has no observable overhead. We synthesized the design for several different options and you can see here reported on the y-axis the different area in gate equivalences for several different options without any obfuscation. And with our obfuscation, we are still perfectly within the range of normal designs. Same if we only look at the finite state machine or the bus controller, the two central components that actually were affected by the obfuscation. And you can see that we are still for both components in the range that you would normally observe for these designs. So there is no suspicion raised by our obfuscation here as it does not increase the area at all. Now what we also did is to completely randomize the state transition graph for the obfuscation. What you saw in the previous example is something we would call plausible obfuscation. The resulting functionality, the visible functionality in our case, is still plausible. It's just a different mode of operation. But if plausibility is not important or even better if it cannot be verified whether something is plausible or not, we can also fully randomize the state machine here. And you can see that the plausibly obfuscated state machine on the left and the completely randomly obfuscated state machine on the right resemble only or have only very little resemblance. And the one on the right is even missing some states. So a reverse engineer that only would analyze the state machine on the right would not find any reasonable functionality and would even miss some of the states that are truly in the design. At least when focusing on the state machine alone, again making it much more complex to understand the whole design. So let's suppose that there is now actually a mismatch between the analysis results and the observed functionality. So there is maybe some plausibility check possible or some after the analysis, the analyst finds that this simply does not match some test vectors that they tried out. Well, the source of this mismatch is now still completely unknown to the reverse engineer. It could be like an error in the reverse engineering process that are very common. It could be just a mistake that the analyst made. It's not immediately evident that the mismatch is due to obfuscation. So it's completely unknown where this error was introduced. And now let's go one step further and suppose that the analyst actually identifies the mismatch to be due to camouflaging or to obfuscation. The problem is now that the camouflaging technique itself is yet unknown to the analyst. They don't know how these obfuscated gates were actually built. So the first step would be to identify the exact gates that caused the mismatch, understand the camouflaging technique, partially redo the physical analysis to now get the correct net list, then redo the net list reverse engineering, and in the end gain the correct understanding. But our claim is here that this definitely adds a tremendous overhead for reverse engineer, which was exactly the goal of obfuscation. So we conclude that the defensive potential of this low level obfuscation is enormous. But now we want to also take a look at the offensive potential of low level obfuscation, which is in general not done for obfuscation research to also take a look at what an attacker can do with this. And for this we now take the point of view of a malicious designer, which makes sense since doppelganger is a technique that is used in the design stage by the designer. And the goal here is to insert a stealthy yet exploitable hardware trojan into the ASCBC design we just saw. The possible motivations here include like backdoor for covert access or pressure or bribery by a government agency. So we are not talking about script kiddies here, we are really talking about large scale adversaries. What we want to build here is a design where the visible functionality is the Benin crypto core processor with ASCBC and the hidden functionality houses the same core processor, but also an active trojan. So a reverse engineer would only find the Benin core processor, but when executing it, we have an active trojan. And the active trojan will actually be designed in such a smart way that it is not identifiable that easily. So it will stay hidden. The goal here is that a device that has our trojanized chip can actually work correctly or work fine with non trojanized devices, but that an attacker can just from listening on the conversation on the insecure channel extract the key of the conversation. So how is this done? The idea is to perform an algorithm substitution attack to leak the key. So we replace the genuine algorithm with an algorithm that is kind of indistinguishable in the output, but still vulnerable. The first question here is where can data be leaked? But if we take a look at the mode of operation, so in our case, the CBC mode, we see that we select a random initialization vector, which is part of the plane output. And this will exactly be the part where we can leak data. And this is also why it doesn't only have to be CBC, it can basically be any mode of operation here for this specific trojan that has a random IV, which is output. And this actually means that most modes of operation are affected by this trojan. So we could now of course just copy the user key into the IV or use it as the IV. But this would be screaming at the user, since the IV for several encryptions would be the same or would be the key itself. A much smarter way to do this would be to encrypt the user key with some small random value, small here in a sense of like a 32 bit value, and use this value as the IV. It will still look like a random IV, but it's actually depending or dependent on the key now and some random value. And then if we would build a trojan like this, key recovery can actually be done via a known plain text attack. We just as an attacker, listen to some conversation, and then we guess the random value and decrypt the IV with this random value. Then we get a key candidate and use this key candidate to decrypt the cipher text, get some message out, and then see if our known plain text is in there. In that case, we found the candidate. Since we need two decryptions per guess, we have an average complexity of two to the lambda decryptions until we found the key. The really nice thing is that in our design we only have to modify or modify six signals and connect them to dummy inputs of obfuscated gates to implement the whole trojan. And as you can see here in the image, it's actually interesting that it modifies the state machine that belongs to setting a new key and from there transitions over into the state machine part that is used for encryption. So we do not need any additional hardware modules for this trojan. We just need some modification of the state machine and as you can see also of the bus controller. So now how could we detect this trojan? Let's switch sides again and say that we are now someone who wants to analyze this design and wants to see whether trojan is inside. So in this sense, we are maybe customers evaluation labs. You could think that the malicious designer still wants to get some certification for this chip and sends it to a lab or something. Or even in case of military equipment like a government agency or the military that wants to make sure that there is no trojan inside. So since the designer is malicious, there are basically or the documentation cannot be trusted. It's fake or something is not available. We cannot rely on a golden model here. So we basically just have two ways to detect that something is wrong. We can do some functional testing and we can do reverse engineering. If we do functional testing, that does not really help. The design has correct output and it works correctly with non trojanized chips. As all we did was change the IV generation. And not the encryption algorithm itself. But the IV itself still looks random. And it was shown that the IV stream passes statistical tests if lambda is at least 32. So the only chance that we have left here is to detect that the IVs repeat too soon. Because of course the key that is used, the random key that is used to encrypt the user key, it's very small. It's just a 32-bit key. So we expect collisions with a 50% probability after 2 to the lambda half IVs for the same key. So if we chose, for example, lambda equals 64, then we need to check 2 to the 32 IVs on average to get a 50% probability to get the same IV twice. And the crucial thing here is that typical testing is edge case driven. One would not check for IV collisions. One would check specific test vectors. One would check specific corner cases. But one would not exhaustively check for IV collisions for one specific key. So this test that would actually find our very specific trojan is an unreasonable test without any initial suspicion and would therefore most likely not be applied. So the trojanized output remains indistinguishable, not in a math sense indistinguishable, but in a real world testing sense indistinguishable from genuine output. And so we can conclude that our trojan likely remains undetected during functional testing. And since functional testing now does not help the trojan remains invisible, our only chance is reverse engineering of the IC. But by design and by the guarantees of the doppelgänger technique, the reverse engineer will only find the visible functionality where the trojan is not even part of. So the analyst will analyze a netlist that does not have a trojan inside as long as our camouflaging is effective. So by design, all the netlist based trojan detection schemes out there are ineffective. And no suspicion is raised during the standard analysis approaches. So we can conclude no suspicion is raised during reasonable functional testing, no suspicion is raised in the standard reverse engineering process. And this makes the application of further analysis methods that may be able to uncover the camouflaged gates simply unreasonable and too expensive. So the trojan likely remains completely undetected in this case. And we demonstrated that low level obfuscation has an immense offensive potential. Now bear in mind this was of course just a toy example. And there will be valid points how this trojan could be detected with some specialized technique. But again, is this specialized technique so simple and so cheap that it would be applied to every security critical design? And also the question is whether such an analysis for this specific trojan could be generalized to find other trojans where I highly doubt that this is possible. So yes, this specific trojan might even be detectable with very many with very much effort are very dedicated techniques. But the doppelganger obfuscation technique itself could be used to build much more complex trojans. And here the odds of detection are then much lower. So to conclude our paper, we present the first generic technique that utilizes low obfuscation to obfuscate higher level structures. And we obfuscate by ignoring existing logic instead of adding new. The cool thing is here that the designer has control over both the obfuscation input and the obfuscation output. We can control how the visible functionality will look like and how the hidden functionality will look like. This enables obfuscation output that still appears possible. For most traditional schemes, you can see that something was obfuscated. Or at least you'll run some analysis and find, well, this is really overblown could have been simplified. So it is likely obfuscated, which is not possible for the doppelganger technique. But we also demonstrated that such low level obfuscation enables very dangerous trojans. So we believe that our results are highly relevant to the industry, to academics of multiple disciplines, and even to government agencies. And with that, I thank you for your attention.