 understanding millions of gates, introduction to IC reverse engineering for non-chip reverse engineers. Our speaker Kitty will provide a summary of methods and counter methods for integrated circuit reverse engineering and why you should care and what you can do at home. Our speaker Kitty is a researcher at the university and likes reverse engineering and cats. Please welcome her with your round of applause. So, hi. Thanks for the intro. I hope you like my pink cats. I tried to match them with my hair. It didn't quite work, but I'm getting there. I like to talk about understanding millions of gates, also known as how I learned to love looking at gates all day. Quickly, just for you, we had had a talk just before mine, which has some basics to reverse engineering, so I will try to build on that. I may repeat myself, I may repeat the other talk a little bit, so don't mind that. What I won't talk about, any kind of PCB reverse engineering or any kind of process teardown, I don't do that, unfortunately. I also don't do any kind of probing, so that's out of my expertise. I can duck-duck-go, but I don't do it for any kind of data sheet. I also don't do any kind of process analysis, so I don't actually use any SEMs to figure out how chips are made, and I don't care very much about side channel-based reverse engineering. There is a whole heap of research out there, which is really interesting. I don't do that, unfortunately. What do I do? So what I'm interested in is what the hell is this chip, and some of you may recognize it's an open titan chip, so it's actually even going to be open source. Does that mean we actually know exactly what's on there? Well, we have a bit of a gap right here, so that's a bit of a problem. We do know the RTL description, and apparently, from the packaging, it's all going to be open source as well, but any kind of fabrication data we just don't get told about. So that's where I kind of come in and go, look, I really would like to know everything about this chip. That'd be pretty cool, so let's try to reverse engineer it. So we've had this motivation before, right? So if you start googling software reverse engineering, you get told these are the top 12 tools, these are your best 10 tools. If you do the same thing for hardware reverse engineering, you get the Wikipedia entry for reverse engineering, which is not so helpful, and maybe kind of a couple of maybe talks or some kind of academic research, but you don't really get given any tools, you don't really get given any methods. So that's a pretty big problem for me, and that's what we're trying to change. We've had this introduction of the life of a chip, of how a chip is made. Usually you have some kind of design that's made, you know, you have like design house or IP vendor, you write your RTL description. That gets verified, synthesized, placed in route, you eventually have some kind of layout right here, and it goes off into the foundry, wherever that may be in the whole entire world. You get some kind of wafer back, you test it, and you have a chip, and then you have sort of your life cycle management back here, where you basically figure out, is that chip now done and dead? You know, do I recycle it and all that. Why do we care about reverse engineering? Well, what is a company worried about when it comes to chips? They don't want the foundry stealing that design, so the foundry goes cool. Thanks for your design. I'll produce the 2 million you wanted. I'll also produce 20 million that I can sell, so that's pretty cool. They don't want that happening. They also don't want out of spec or badly tested chips to be going anywhere, so basically the foundry says, look, we tested it, we tested it, and 90% are okay, and we'll keep the 10%, and we'll definitely get rid of them. Yeah, yeah, sure. They don't want any kind of out of spec chips to get back in the market, and they don't want any kind of recycle chips to get back in the market because they're losing money. So that's why a company generally cares about reverse engineering, about chip security. Why do you care? It's a little bit different, so you don't want any IP to be bad. What does bad mean? Well, it might have a Trojan in there, so some kind of malicious hardware. What could that be? Well, we have chips pretty much anywhere, so maybe in your car, and all of a sudden your car starts stopping and everyone else is two, or in your nuclear power station, I won't go on. It could also be that maybe the in-house design team made a mistake or decided to hide something in there which is not in the specification. We all know how that goes when we start finding random things that never got documented anywhere, when we bought a chip and are using it. We're also worried about the foundry putting into something in there that not even the company knows about, so we stand up buying chips and the foundry in wherever this chip was produced starts doing bad things. So we very much care about the use, right? We want chips that are working and not evil. That's kind of why we care. Obviously, that also means we don't want failed tested chips in our product. So let's have a look what the life of a test chip is like. We've also seen this, so usually we come out of the foundry, we have our lovely little chip, and we start de-packaging the poor thing. We delay it, we image, we have to stitch all that, so that's very much kind of an image processing kind of topic and before that a physical processing kind of topic, and eventually we have some kind of interconnect identification so that might look something like this, but you start finding pictures and then you have to do image processing to figure out where exactly the connections are, or some kind of standard cell identification, so you go through and you have some poor guy reverse engineer or 300 cells, and then you find them again with pattern matching, the rest 2 million minus 300. So that's pretty much not trivial, it's complex, but we know how to do it. We know how to image processing, that's kind of easy. We kind of have the, what the hell do we do now? Topic, we have this net list, what does it actually mean? And I certainly hope you have these at home to do kind of reverse engineering, so maybe they're standing out in your garage, if they are, call me. And I'm obviously just kidding, you don't actually need any of these as we've heard before, companies do do these kinds of things for you, and for the interesting part, the actual what comes after I have a net list part, you don't need any of this, so that's quite nice, usually this kind of laptop I have here is enough. Let's talk about the problems we're actually looking into. So what is the really interesting part of net list reverse engineering, we also call it abstraction, trying to get these maybe millions of gates into something that you can understand. So what we have is some kind of images, some kind of net list. And the first thing we do, and we've had this in previous talks, is to figure out what the hell is the hierarchy, right? So what modules do we even have on there? What do they look like? Where are the borders to these modules? And this would be kind of the topic partitioning. So in synthesis, we partition to do good layouting and reverse engineering, we partition to figure out where the modules are. That's kind of our first step. And we actually already failed pretty badly there as a spoiler. The second thing we do is then to actually identify what those modules are, right? So now we know, hey, we have ABC. What is that? So maybe we have something like, that's a crypto core. And this is actually coming back to the point of the previous talk that graphical analysis of net list is not so great. That's 250,000 gates of a risk five. And you can see quite easily if you do present it as a graphical thing, at least we can kind of figure out maybe where the modules are. So I'll do some more of that in a little while. So we have these two main problems. We first want to find the modules, then we want to identify them. How do we do that? I'll give you a quick overview of what we do in academia now. By the way, in big companies, we usually just have like 200 EDA specialists who look at the design and go, yeah, look, I wrote this design in 1980. So maybe it's probably that thing again. So the HR costs are actually quite big for this. And as we've heard in previous talk, there is no automation here as of the time being. Okay. So let's talk about partitioning methods. The first idea that we have is generally in a chip. We do any kind of work usually on a data path. So maybe you have a 32-bit multiplier and what actually happens is that you have two 32-bit inputs. And every input has the same thing happen to them 32 times. So every bit basically has the same thing happen to it. And that's duplicated 32 times. And we classify something like that as a word. So a data word. And we can try to figure out where these words lie and then propagate them through the whole entire design. So we hopefully come from input to output. And then say, look, these are probably at the boundaries of modules. So in particular, when new words are starting to be combined in different ways or maybe words are being split up, that's probably a new module. So if you go through a bus to your multiplier, all of a sudden you're now working on 32-bit architectures, you can say, look, beginning word and word, everything in between is probably my module. The other thing you can again do is graphic analysis. So this is actually a fully paralyzed AES implementation, which you can tell by the fact that it has 200 S boxes. Please don't write your IS like this unless you really have to. Because it's very easy for us to find it looks exactly like this. The 200 spots you can see are exactly these S boxes. And if you do graphical analysis, you will find that they're more densely interconnected and you can get these kind of images, which are actually, yeah, pretty easy for you to see. So if you ever start clustering a design and it looks like this, that's probably an IS. So those are kind of two different ways of trying to petition things. It tends to be quite difficult. We would like to be able to petition each cell specifically into one design. That's not usually possible. So we fail at that quite valid time being. We can usually get like 80, 90%, which would be pretty cool and a normal sort of thing. But here it's not really enough, unfortunately. The second part, so we have now got our module. We would like to know what is it and what we usually do is comparison. So hopefully we have somewhere a database with all known designs. So this would be our database. And we compare our unknown design to a known design in this database. We've had the topic of trying to figure out or trying to get lots of samples. That might be, for example, a design library. You could also use something like OpenCourse or LibreCourse. And maybe as a company, you also probably have access to some kind of IP that you can use here. And the idea is, look, I've got an unknown net list. It's the same as a known net list. Let's get some inputs. Let's get all the inputs and let's connect them together and let's get our outputs and see are they the same. So if for every single input that we can put into both designs, the output is always exactly the same, it's probably functionally exactly the same thing. Which is quite nice. We have a couple of problems here. So we actually need a perfect functional match which requires a perfect net list extraction. So while we're de-packaging, while we're de-layering and imaging, you better not have any dust on your pictures because all of a sudden you might be missing a connection or a gate and this doesn't work anymore. When you have two million gates and that's a pretty high number of polygons in your image, the chances of there being no problems with your image are pretty minuscule. So this is going to fail. Let's say you do have your perfect net list extraction, maybe you're working on FPGA, so that's easier to get there, we don't get errors. You also need a perfect partition. So this step I just described, you also need to perfectly in order for this to work. And you also need a known net list. Obviously, if you don't have that, that's going to be a problem. You can tell why this stayed in academia and never went out into the real world kind of thing. The second thing we can do is kind of more graph-based. So we can use some kind of fuzzy methods. I have nine designs here. You might be able to tell that three are kind of similar and two others are kind of similar. So we can do some kind of graph analysis and have a look at this kind of fingerprint of what it looks like. And spoiler, it's these three. These are all IS rounds or IS implementations. And these two, these are both catch-back implementations. So SHA3. And you can try to do some kind of fuzzy matching based on this. So if you're interested in graph theory, this is now your part right here. And figure out what could be a structural similarity. And the first question I always get asked here, well, you don't know what kind of optimization tool or synthesis tool the other people used. You don't know what kind of cell library they use. You know, how are you going to be able to compare that kind of stuff? So what we actually did is we had a look at three different cell libraries and two different synthesis tools. And we had a look at the same design. So this is actually an IS round. And how to look how they actually turn out at the end. And I would say that's kind of pretty similar. At least with your eyes, you should be able to match it. Teaching an AI to do it does require a lot of data. Spoiler, we have done it. So that's regarding the topic machine learning. That's actually possible if you have enough samples. Cool. So we have some kind of output, hopefully. We have some kind of hierarchy. We figured out our modules are these bits. And we've also figured out what they do. And that's pretty cool. So yeah, we can reverse engineer all the things. Great. I mean, regarding without, you know, the problems that we face. What's our problem? Attackers can do it too. Well, that's kind of shit, right? We don't want attackers to reverse engineer our stuff. They might be able to put hardware trojans in there. They might steal IP. We don't care so much. We care probably more about the hardware trojans. We don't really want that happening, though. So there are a couple of countermeasures that people have thought about. The first one has kind of been mentioned a little bit, logic locking. There's also split manufacturing, camouflaging. I'll go into those three. There's a couple of more. Spoiler, they're all pretty broken. So the first thing we did, not me. This is research I'm presenting now from other people. Please do note that. It's to say, hey, let's do it like in software. Let's encrypt the functionality, right? So we add some kind of key. And we do that by adding key gates. So if you have, for example, this lovely little net list, we might add two more gates with some key inputs. And if you don't apply the right key, the functionality is not there. So your chip doesn't really do what it's supposed to do. So that's quite nice. We've actually had quite a different few different ways of doing this. So for example, the first idea was we just add key gates everywhere randomly. You know, it'll be good enough for the functionality and eventually that got broken. So we kind of had a smarter method used on fault analysis. That got broken. So we started doing something called strong logic locking, which got broken. So we started doing something called sat resistant logic locking, which also got broken and so on. So it's a bit of a cat and mouse game that we have going on there. I'll get back to that in just a minute. Let's have a look why it does fail. So the first thing is that these key gates are pretty easy to find. There's actually a nice paper which says, look, these are the key gates that we put up in here. First thing, first, they're usually XNOR gates or XOR gates. Yeah, let's look at all the XOR gates. These are pretty easy to find. And even if we do do some kind of optimization afterwards, to try to sort of hide those XOR XNOR gates, it's still able to reverse engineer it because it's very local and very deterministic of how our synthesis tool might do this. So we can actually find all those locations pretty easily and maybe even cut out the key gates if we're trying to redesign it or get the right functionality if we're trying to add in the Trojan. Furthermore, the structure doesn't really change. So if we're doing any kind of fuzzy analysis like structural stuff, we have, again, an IS round here. And if we do, like, 20% key gates in there, well, it doesn't change that much. So if I ask you, is it still an IS round? And you said, no, I'd probably, yeah, wonder if your AI is broken, maybe, or something. I don't know. So we can still do functional or structural analysis quite easily with these key gates. So that kind of sucks. We also have a lot of attacks on specific schemes. So this is the current landscape of logic locking schemes. In blue, we have our schemes. In red, we have everything that's breaking them. And I think there is only a few which are currently not broken. Those are generally the ones with a really high overhead. So that kind of sucks, which leads me to the next problem. We have practical difficulties, right? We have to have some kind of key in there. We always hate having to securely store keys. We need some kind of secure storage, or maybe some other way to do it. We also have overhead that we have to kind of look into. And finally, the verification team is going to hate you. I've actually talked to someone who said for the NASA, they don't do any kind of logic locking because it just sucks too much to verify. So this kind of fails quite badly. Okay. We actually kind of get to this kind of situation where if someone says let's do chip security, everyone's like, yeah, let's do logic locking instead of actually putting some thought into it. We have had some information on a FSM or sequential type of logic locking scheme in the previous talk. I would just quickly like to introduce that also other schemes is broken. This is a scheme based on black box. FSMs. So the idea is that you have in the middle your original FSM, and from each state you can get into these black box states. So those are like your evil states where you can't get back out of. And those happen if you apply the wrong key. To get into this original, I'm going too fast, into this original thing here, you actually have to apply the correct key. As soon as you take it away, you have a wrong FSM. And that's actually also broken because as we've seen in previous talks, if you actually look into that, this is the reverse engineered FSM. It's visually possible to identify all our black box states here. And you can even figure out what the key is supposed to be. So you buy the chip, you apply your own key. There you go. Good. Let's get to something a little bit different. So logic locking is pretty broken encryption on hardware. It doesn't work. We don't have one-way functions. So that sucks. Let's do something different. Let's say in Germany we can maybe fabricate 45 nanometers. That's pretty cool. We want to do 8, though, right? And 8 doesn't work in Germany. Okay. So we're scared that the foundry is going to do something with our design that we're doing the 8 nanometers at. So we only give them the most bottom layer, the one where it's actually important, the one that needs the 8 nanometer technology. And we give that to them. They fabricate that and we get it back. And in our own foundry we do all the rest. We do all the wiring and the upper metal layers, and all the connections. And the idea is like here, without the connections we won't know the functionality because we can't actually reverse engineer the whole entire net list. That also fails pretty badly. Why? Well, first things first, we usually have some kind of physical proximity. If we design stuff, gate A at the top is usually not going to be connected to gate B at the bottom of this trip. So if you consider this gate, it's probably connected to this one or this one. We also don't usually have that many loops. So the chances of stuff going back on itself are pretty low except in FSMs or maybe for flip flops. And these gates can only drive a specific amount of other cells. So we have some load capacitance constraints that we can also basically throw into our attacker model or attack a model, attack a type or attack a scheme. And we can figure out pretty quickly what the connections are actually supposed to be by brute forcing. The next thing is that we also have sometimes bad designers who don't do this very well. So they just design usually and like normally and then take away the top metal layers and you get something like this. So you have your source gate and you have a unconnected connection. And then you sit there and go, I wonder if it's connected to gate A or gate B. And I think spoiler should probably be gate A, right? So that is also part of why it's really broken. Yeah. Good. The final kind of counter measure I'd like to talk about is something called cell camouflaging. If we can't hide the connections, let's at least hide the functionality of the cells. The idea is that if you consider these two cells here, it's a nanonore cell, they look visually different. So the metal actually looks different or maybe the dopant looks different. We can design cells where the metal doesn't look different. So for example, these are two obfuscated nanonore cells. Visually they look the same. So if you reverse engineer it on the picture, they should look exactly the same, but they are different functionalities. With the idea being, if you don't know what the actual functionality is, you can't reverse engineer the chip. We have quite a lot of problems here. The first thing is those cells are huge, right? So the area overhead is going to be pretty big, means your chips are going to cost more, you're going to have some kind of heating problems eventually. You also need to find a manufacturer willing to actually produce these because you do need special tech to actually do this. You need a whole entire new cell library and we all know how tech companies are with the cell libraries. In the past, they've now also been published some decamouflaging attacks, so they're also based on what would be normal to have in a kind of chip and to try to reverse engineer the function. They're even to brute force it because you know this can only be a nanonore. Well, that's two options. Let's brute force that. Finally, we have the problem that our SCM, so our scanning electron microscopes can actually distinguish between some dopant changes. So if it's only, if the only difference is, maybe the metal looks the same, but the dopants are different, we can actually see that. So if you have a look here at these dots, the optical microscope can't distinguish between those two, but the SCM, we have the lighter and darker dots and the same thing with the fib as well. So we can actually see the changes depending on our tech anyway. For very small dopants, this won't work, but for very big dopant changes or dopant differences, you will actually be able to see the camouflage gates again as well. Okay, reverse engineering is pretty cool, right? So we have some kind of IP protection for the companies. We can try to figure out is there something in our design we didn't want there, some kind of malicious logic. We don't want nuclear power stations blowing up because we designed our chip here and then sent it off to wherever. However, foundries use this kind of stuff to figure out where to place hardware trojans, at least that's the fear. If they know the functionality, they can figure out, look, let's place it right in the crypto core. That's what we want this thing to be. If they don't know the functionality, they won't actually know where to place the hardware trojan. And any kind of countermeasures we have are broken. So we don't really have anything very good working for us here to actually prevent some reverse engineer chips. The ugly, we don't really have any tools. I know we've previously had some discussion or some talk on the tool. We've actually found that we haven't really found anything that can be used commercially for an actual chip. So it's all very nice if you have your 6000 gates and then you get your actual chip and has 2 million gates and nothing works. So there's that. We also don't have any formal methods. So that kind of sucks because we can't actually prove anything or it's not provably secure. And sometimes it feels a little bit like no one cares, right? We all kind of go, oh, shit, meltdown is really, really bad. And yeah, it is. But if your chips are insecure from the hardware point of view, you're going to have a bit of a bigger problem. And it's going to be a bit more difficult to replace those. So that's kind of sad sometimes. What can you do? So those two main problems I mentioned right now, the petitioning and the identification. You don't need any kind of specific hardware for that. You don't need any kind of specific tools for that. Any kind of designs you can use here are open source. So I mentioned open cores and Libre cores. Feel free to download everything there. Feel free to synthesize everything there with wonderful open source tools you can get. So you also have Qflow, all that kind of stuff. So that's something you can do. And you can find new methods to petition, to identify, maybe to counteract everything here with a normal kind of laptop, for example, this laptop which I work on. And you don't actually really need anything else. So that's quite nice. In particular, it would have been good if you had some interest in graph theory, if you had some interest in functional analysis. So I think the previous talk mentioned that they're looking for software engineers. We would like your sort of research expertise here. Maybe have some ideas of how graphs could maybe have some other functionalities to figure out how to petition better or maybe how to fix some errors there. So that's quite nice. And for that, please do feel free to contact me. I mean, if you have the SCM in your garage, also contact me. I'd love to see it. But if you have any kind of ideas of how to do this better, do let us know. And thanks so much. And I hope you have maybe some questions. Thank you very much for your talk. If you do have questions, please line up, add the microphones in the room. If you have questions from the internet, just keep asking. Signal Angel, do you have a question? What awesome software do you use to visualize such graphs? Okay. So we use a couple of different ones. We're big fans of GIFI graph tool. And we sometimes use graph viz. So those are all you can look into. With the extremely big graphs, we've had really good, good stuff going with GIFI. So even so we've had this problem with HAL, where you can't visualize stuff on the go. GIFI is able to actually run different kind of graph algorithms on your graph in real time. You may need to up the memory a little bit sometimes, but it does, I think we've done up to one million gates in there, which is quite cool. Graph tool is awesome as well, though. Microphone number four, your question. Hello. I have two questions. The first one was with the scanning electron microscope. To my knowledge, you can actually see the chip working when you are using an SEM because you can see the loads of the electrons and the transistors themselves. Why do you even need all this camouflage? Because you can see it working. Why do you need all this camouflage? This is regarding the camouflage in chips. Yeah. Well, this is the question I asked myself as well. Sometimes it becomes so small that you can't see it working anymore. So if you're camouflaging in a really small technology, we actually start getting troubles to be able to properly visualize that. So it's actually difficult enough to get pictures to reverse engineer, to actually have it functioning and to see that what's happening inside is becomes difficult. 429 minutes, yeah, feel free to just see what it does. My next question is, isn't there like, of course, this wouldn't work with the foundry, but are there like physical methods, for example, special coating, which you cannot remove without destroying the silicon? Yeah. So there have been ideas in that direction also to try to, so one of them is a coating. The other one is to try to put into the metal layer something that will, if you start physically removing them to sort of, which will scratch up the surface, there is ways to that. That is very much a physical problem though. So that's what the material guys do. And as of now, as far as I'm aware, they haven't found anything where that's really been a problem. Right. Signal Angel, do you have more questions from that? You're good. And I don't see anyone else being lined up. All right. We have microphone one. Sorry. Hello. Just a small question. Do you know a tool to do, let's see, to recover clock groups out of an at least because you mentioned the partitioning problem. I would say if they are clock gating and all the stuff, you get the function as one clock group. Yeah. So actually clock grouping is probably the first thing you would do when you start partitioning any kind of design. So your first step would always to be to have a look at the clock tree and see which parts are clocked by the same design. And then you go from there and try to sort of divide and conquer some more. As far as I'm aware, HAL does do that. I'm not sure if there's any other tools out there which specifically do that. It would be nice just to have a tool with weed in the net list showing the placement and say this flip flops belongs to this clock group just by coloring or something like that. So I think this is something that HAL does do. So that is possible with HAL. Yeah. My phone number four, your question. Yes, thanks. Can you tell me how much overhead do you add if you use this obfuscating and how often is actually used because it seems that it's quite easily broken? So is this really a thing that's widely used? Okay. So what happens with chip design is that people start designing now for chips which we've done in like three years time. And when this was the hot shit, people decided let's the logic obfuscation right before our chip in three years time. So there's chips on the market which do have some kind of logic locking on there. The overhead depends on how you implement it. You're not going to put in 100% key gates. You usually only do it for the parts that are important to you. So for example, for crypto modules or for your CPU. And so the overhead depends. Are we talking about the logic encryption or the obfuscation or the camouflaging? Because that's a little bit different. So the one depends very much on the cell library you end up using for this camouflaging stuff. There is a lot of different ideas of how to do it well. The more difficult it comes to for us engineer, the bigger the cells are going to be and you have overhead to two, so 1.5 to five times as big in your chip for the part that you camouflage. Again, that's not going to be your whole entire chip. That's going to be the part that's of interest for you. For the logic locking, you can usually choose a little bit more, you know, maybe you have some space left in your chip. You go, let's do 20% logic locking on this one part and that's just enough to fill it in perfectly. So you have a little bit more possibility to choose there. Thank you. On microphone number one, your question. Hello, thanks a lot for the talk. I was just wondering with the potential evolution of packaging technologies, like 3D stacking, how do you perceive the future of your field with that? Okay, so we've actually worked in the past with some people who are trying to do 3D printing and so try to integrate more in there. Again, that is kind of a physical process that has to be done. My research very much does this high level. I would assume that as long as we have to test chips, we're always going to have the tools to be able to analyze them. And even with 3D stacking, we're going to have to be able to have tools to be able to actually get in the chip and do take the images. So for fault analysis we need it, we can use reverse engineering. And the same thing goes for low-anameter sizes. Thank you. Microphone number two, your question, please. FPGA. Can you do this also with FPGAs? Okay, so I'm not an FPGA person. That would have been the guys from Bochum, they do that. As far as I'm aware, this whole clustering stuff, so this first kind of stuff, that's exactly the same for FPGAs. I am not sure how camouflaging works for FPGAs. I don't think it does. Logic locking you can do. So that's fine. Thanks. Microphone number four, your question. Yes, hi. Regarding the problem of sending your designs to the foundry and getting it back modified. So I'm asking, what's the status of this in the real world? So is it a real problem? Can companies actually verify quite well that they received what they sent? Or is it you have to trust them blindly? How much is it actually possible? Okay, so there's two parts of this. And this is a typical do hardware choices really exist problem. As far as I'm aware, it hasn't been seen in the industry. But again, they probably wouldn't tell me if it had been. The overhead to actually get something in there in the foundry is quite large. So this is not going to be something that one single person does. This would need a probably some kind of state actor to do this. The problem is that our foundries do lie in countries where we have maybe that kind of problem. At the moment, I know companies are working on checking their own product. So I am aware of big chip companies that do do this kind of thing where they get their chips back and reverse engineered. It feels like it's very much in its baby steps. I do hope eventually we're going to get some kind of certification. So we have certification now for chips. And I hope eventually they'll have some kind of we reverse engineered it when it came back and it was fine kind of certification. That's where I hope it would go in the future. But I think it's a long way off. If you had to guess, so if let's say if a state entity sends out a design to a foundry and then a state operator there makes a modification. So who wins? Kind of depends on the state I would say. So in America, all the big research and this is founded by DARPA and they have a lot of money. I'm going to leave it at that. All right. Thank you very much for your talkity and for answering all the questions.