 So, this talk is titled Untrustworthy Hardware and How to Fix It, but due to the destination of the project, I think it would be better titled Seeking Hardware Transparency. Uh, I'd like to thank the contributors that made this happen. So, uh, some of the channels on FreeNo were very helpful. Uh, some people in the open-risk community really helped make this happen, as well as Propeller Guy, who worked on the, uh, Propeller, uh, IO interface that we have. Before we get started, I'd like to speak a bit on what I do like in the, uh, computer community. Uh, that is the fact that we are not relying on closed-source black box and known weak algorithms anymore. We have, uh, trusted free and open-source, uh, crypto algorithms that are heavily scrutinized and are readily available and widely deployed. So for this talk, I'd like you to forget about software for a bit. I don't want you to think about any of these, but I do want you to still think about security. So where do we go from here? Uh, right below software, uh, this is found on just about every, uh, computer system we've got firmware, and that sits below the software and interfaces with the hardware. And, uh, firmware is almost exclusively closed-source and controls, controls almost all hardware devices and functions. Uh, and due to its low-level nature, uh, this firmware is, persists across, uh, OS and our, uh, installations if, uh, we ever have, uh, malicious installations. There's a lot of research in this space, and I'm not an expert on it, but I encourage you to check out some of the DEF CON talks on it because they really go into some of the details there. Uh, below that, uh, we have hardware, and this is where we'd be spending a lot of our time. Uh, hardware is almost always absolutely trusted because it's where you run your computations. Unfortunately though, uh, groups like the NSA and other nation states have been caught attacking this space. So we have seen, uh, the NSA attacking Cisco systems. We have the DOD concerned about rival nation states back during their hardware. Even Apple is suspecting that some of their server shipments now are back door. So they're actually looking to get back into the server space. Uh, I think somebody on the internet said it best if the hardware is compromised, then the whole machine is compromised. Now just as an example, we've probably seen this slide a few times before. Uh, the NSA is unpacking, uh, Cisco shipments and they're implanting them with, uh, rogue hardware devices. So hardware back dooring is very real and it is a concern that we need to look at going forward. One thing that really concerns me is, uh, Intel management engine. So this technology is found on just about every Intel system in the last ten years. It's not a straight up back door but it does pose significant threats. So management engine is actually a dedicated logic device that sits on your CPU or on the chipset depending on what, uh, architecture you have and controls a whole bunch of, uh, special features on the system. It's got system access at the lowest level. It's got network access. Uh, it's actually got its own IP address and MAC address to handle everything. And it remains functional in the background even if the system is off. It actually runs on standby power. So if any of you are familiar with lights out management on servers, it's like that. But you can't control it and you can't disable it and you can't turn it off. Uh, this may sound like a server feature of course when I mention lights out management, but as we can see in some of Intel's product slides, this shows up on high end desktops, this shows up in laptops. I've even heard that it shows up in some of their atom tablets, but I can't confirm that. Before we go further though, I think it'd be good to cover what Intel management actually is. So most of this information comes from poorly secured FTP servers. Uh, it runs ThreadX real time operating system which you probably haven't heard of. It's closed source and proprietary of course. It has its own MAC address and IP address for out of band features as I mentioned. Uh, some of the code is found in, uh, inaccessible on-chip ROMs. You'd have to de-cap them somehow to access them. Other, uh, parts of the firmware are found on the motherboard itself in the system firmware. That's what makes it hard to install Libreboot on modern laptops. Uh, it uses compression and encoding to throat reverse engineering. Uh, and it's, uh, found all sorts of different system architectures. So the actual management engine itself, uh, varies between platforms. It's very hard to figure out exactly what's going on because Intel's very secretive about it, but it's, uh, been documented, uh, using Arc, which is very popular and embedded space. Uh, some of them use Spark v8. Why sun Solaris chips are in, uh, Intel processors is beyond me. Uh, Hackaday summarized it best. In short, Intel management engine. It's reverse engineer's worst nightmare. Uh, I like this slide. If it's not a back door already, it's waiting to be a back door. And I think if you've paid attention to, uh, some of the hardware security space in last year, uh, it's getting closer to that every day. Uh, it is effectively the perfect hardware back door in fact, because it's built for IT infrastructure to manage, uh, laptops and hardware in the field and do, uh, updates and repairs to systems without having to reinstall the operating system or work at the operating system level. As I mentioned earlier, it's found in all Intel systems from about 2008 to 2009. And the worst part is, even though you bought your CPU, you paid your money for it and it belongs to you, you don't control it. You can't disable this. It's like, I have this hardware platform, but I don't have control over it. And that was really a lot of the inspiration for this talk. I was tired of seeing hardware where I, I owned it and I was running my code on, I was running my open source software on it, but I couldn't control the system. Uh, some of you may be thinking about Intel's competitor, AMD, which has significantly less market share currently unfortunately. Uh, they also have a similar technology called TrustZone slash, uh, platform security processor. But, uh, given that they haven't made CPUs recently until then, uh, they, this, this technology has not been well documented or researched. Before we go on to the solution though, it's always fun to go over some hypotheticals. So we're going to go do a little bit of speculation. What's the worst we can do to hardware? So what about nation states? These people are always friends. They have tons and tons of money. Uh, hardware backdooring is viewed as a threat by nation states. They see other nation states as a threat. So the DOD is apparently actually looking at bringing and making, uh, bringing chip fabrication back to the US for some of their work because they want to know that the chips that run their systems are secure. Uh, nation states of course could backdoor, uh, product manufacturing with switched additional components. They actually attack them generally at the shipping stage of, uh, of delivering a product, but they could also attack them at the, uh, manufacturing depending on the, uh, situation. Uh, as I mentioned, uh, CPUs, chipsets, uh, network interface cards, ROMs, they could all be backdoored if they wanted. I think what highlights this best is there's a piece of hardware that the NSA has created called FluxBabbit that is built for one specific server that is implanted while in shipment. If the NSA is willing to make a custom chip to attack hardware, why aren't they attacking the fabrication center? So you may think, oh, it's too hard. Well, it's not. Uh, University of Michigan in their paper, uh, A2 analog malicious hardware have documented it is all too easy for a single employee to backdoor a chip at the fabrication center. So there's a slide from them talking about their A2 trigger that causes all sorts of security concerns if implanted. Uh, there's some great articles on that in a white paper if you're interested more. So it's, I believe it's entirely possible for nation states to accomplish. It would lead to widespread, uh, total compromise with, uh, while being virtually undetectable. If you can't trust the manufacturer, what are you going to do? So I was looking at all this. It was actually, uh, I know I was before the Intel management exploits that happened this year, I believe it was a hackaday article where they were summarizing Intel management engine. And I didn't like the state of it because they were, of course, saying, you know, it was very nasty. But the end of the article, uh, was this is in every desktop. You've got it in your system and you're screwed because you can't do anything about it. And I didn't think that was very fun. I wanted to do something else. So I started looking around. So of course, when you start looking up open source hardware, you're going to see, well, open source hardware, you're going to see Libreboot, uh, you're going to see stuff like the Novena hacker laptop, which are very cool. But a lot of these systems still require blobs. So these are pre-compiled pieces of code that you can't inspect. They're basically closed source software that run on the system. And of course, these, all these platforms still require you to use closed source silicon. So you don't know what's under that little plastic package still. As I said, this still leaves the users trusting the chips. So I really like all these projects. They're really cool. Um, I want an Ovena hacker laptop, but they're expensive. Uh, but I wanted to see what could be done for peace of mind private computation for critical situations and what could be done for downright paranoid users like me. What can I do in this situation? Um, can I build a cost-effective low-level solution that offers maximum transparency? So on our system, I, uh, have Linux running on an FPGA along with some other chips. So I know exactly what my CPU is doing. So for those of you who aren't familiar with FPGAs, these are very special pieces of silicon. They're generally used by companies to prototype new chips. They are effectively blank slates of logic. So if I write, uh, software in a hardware description language, which is what you program these in, and then I synthesize them with a bitstream generator, I get a very special piece of code that I can load onto this board that configures one specific type of chip in a very specific way so that emulates the hardware device that I have designed. The hardware description languages that you use to program these FPGAs are also what most companies use for actual chip fabrication nowadays. Uh, as I mentioned earlier, they're, they're right now, these FPGAs are used for a chip prototyping, but sometimes they're also used in special hardware applications where it's just not economic to fabricate chips themselves. So they offer a lot of, uh, opportunities for hobbyists who want to design their own chips and they also offer people like me the opportunity to build a system where I know everything that's going on because I effectively have, uh, processor running on there that acts just like true silicon at a reduced clock rate of course, but I can do all my computations there. So our, our alternative, uh, is built around a cryptographic use case because that's about all I can do with this system. It runs GNU Linux as I mentioned earlier. Uh, you can see the, uh, block diagram of that, uh, board over there. That's the DEO nano that we're using to run the software right now. Uh, it's fully open source hardware and software right down to the chip designs of both major components. Although the board is not actually open source hardware on the DEO nano side. I'm just talking about the chips there. Uh, we're using the parallax propeller for IO. So the parallax propeller acts as a terminal emulator similar to a, an older serial terminal. Uh, and then we have the open risk, uh, CPU design, the MOR 1KX 6 stage risk CPU running on that FPGA, uh, running the OS and operating systems. So we took the open risk CPU standard and we built a system around it. So it's got JTAG, it's got UART, it's got an SD RAM bus. Uh, it's a fully functional processor. I've got a block diagram here to explain this. So you've got the open risk MOR 1KX open source CPU. That's hooked up to FPGA ROM and then it's got the JTAG interface there. We're going to add, uh, parallax propeller over 115 200 board serial. And that's hooked up to the propeller ROM where it stores the spin code. So that's its native language that the propeller understands. You may be familiar with the propeller actually because that was used on many of the DEFCON badges in previous years. I believe the DEFCON 20 and DEFCON 22 badge both use the parallax propeller. And then to actually interact with the system we're going to add a keyboard over PS2, uh, and a TFT LCD over SPI. So Linux's, uh, image is built with muscle tool chains available for open risk. Uh, open ADK actually makes this really nice because you can download it and you can run, make menu config and it's basically a smorgasbord where you get to choose all your Linux tools and, uh, pick your architecture and it just builds a Linux image for you very nicely. You can even do some compression with it. Uh, we're loading it with open on chip debugger and canoe debugger. The propeller is programmed in spin and it's using prop loader of course to load it, which is an open source tool and running open spin. And then the FPGA is programmed with the dot SOF, open risk image that we generated using Fuse SOC and that's loaded onto the board using Intel Quartus, uh, Intel acquired Altera a while back. So now onto the results. The results are a bit complicated. So we have the final product here, uh, in the upper right kind of middle of the, uh, first picture there. You can see the DEO now under those two fans, we have the parallax propeller. The fans are providing some downdraft airflow to cool the thing off. So they look cool, I like fans. Uh, we've got two batteries in there to power the thing that are a bit overkill. Those, those were also fun to get through TSA. Uh, this device does not look suspicious at all. We've got, uh, two power controllers there, so that's making sure the batteries don't blow up, which is very important. Uh, on this, on the picture on the right there, you can see some of the cabling. So that's actually the wiring for the, uh, TFT LCD and, uh, a little wire at the top is the, uh, serial output of the, uh, DEO nanoborne. So this is where it gets a bit weird. So it worked great, but it actually does work in hell. Uh, right before DEF CON, this was the morning before I flew out, the board all of a sudden was giving me, uh, some sort of strange error code. Error code 87 can't scan JTAG chains. That doesn't look good. Let's go to Intel. Uh, let's see. They want me to buy a new USB blaster cable. If you look back here, uh, the USB blaster is actually on the board, so they're asking me to buy another board. Turns out when you're flying out that morning, you can exactly get a DEO nano FPGA board. But I had a backup video. So on this, it's going to play properly. Come on. My bad. We have me holding a camera, looking at a screen, looking at the terminal outputs. This is a serial output running into X term of the processor. And it's going to boot to a busy box console in a moment here. So we'll actually get to see the system running. It runs on the TFT LCD, but for visibility, I had it running back into my laptop. So I should get the busy box shell here. And now I'm going to, with one hand, type, uh, Kat's, uh, PROC CPU Info. So, just give me time. It's, it's harder than it looks. There we go. So you can see the open source CPU there. Now I'm just going to halt the system. Good. Done. So FPGAs are no fun, turns out. Uh, the tools are massive. They are like six gigabytes, uh, compressed to download. Uh, and they're not, no fun to work with because there's a whole bunch of stuff you have to mess around with just to get the board up and running. So, uh, as a result of this project, I put together a thing called Buildscript. I'm probably going to change that name, uh, that takes the suck out of FPGAs, hopefully. So it downloads everything for you, hopefully. It loads the bit stream to the DEO Nano after you've built it so it has, uh, Fuse SoC integration so it can use Fuse SoC to, uh, build that image. Uh, it can write GNU Linux to memory so you don't have to deal with open OCD or, uh, connecting over Telnet. Uh, it can program the propeller and it's going to have a hardware setup guide in a bit because it was actually very hard to find documentation of where the serial output was when you loaded the thing up properly. Uh, it's a fully interactive piece of software. All code of course, 3D models, uh, guides will be available shortly at that link which you can download, uh, from the DEF CONTORN server with this talk. So, I don't think I got to this earlier but this is the actual physical device that I built for myself so you can see everything on the back there. It's got nice splinky lights because that's of course what's important. We all know that's what you're after. Um, and if I had a keyboard with me, I would be able to plug into this thing and, and run it. Before we go, uh, one more things. It's kind of a poor header there. Uh, AMD on Reddit recently has publicly stated they are strongly considering open sourcing their IME equivalent, uh, which is platform security processor slash trust zone. But unfortunately, that was about three months ago and they haven't done anything since but if they find it economically viable, that would be really, really nice. This is an ongoing project. This system is not the final state. This was built, uh, after school was over in about two months before DEF CON. I want to add some RF side channel hardening. Uh, the thing is already battery powered because there's, uh, if any of you are familiar with power-based side channel analysis for, uh, crypto attacks, they're very, very, very effective against FPGAs due to the design of the chip. So, I already addressed that by adding battery, battery powered to this thing so it's not running off AC but I would also like to have it running off of, uh, running with an RF side channel, a hardening system sort of Faraday cage. I'm also looking at increased system independence. You don't have to deal with all that programming stuff. You can, I want to, I want to add U-boot but I haven't gotten there yet. Uh, if you're interested in this space, uh, you should check out some of this stuff so I'm not expecting to copy down links of course. As I said, go to the DEF CON Torrent server and get this talk. I've got stuff in here about firmware, uh, NSA shipment hijacking. Uh, there's some stuff that came out last year with Windows golden keys where, uh, it kind of undermines secure boot when they, when those keys got linked. Uh, there's a lot of articles about Intel management engine and there's a lot of good information out there if you're interested in what's running inside your system. Uh, that's all documented here along with that link to the A2 analog malicious hardware paper. If you're interested in getting into OpenRisk or any open source processor stuff, that is on their, uh, homepage, openrisk.io along with the, uh, other resources. Uh, before we go though I'd like to make some comments. So this device is not meant to be a silver bullet for all hardware concerns. This was a, uh, project I built for myself because I didn't like the state of hardware. What I want you to get out of this talk is that there are some problems with hardware. Uh, there are some problems that people aren't addressing. Uh, I would like more control over my processor and I think there are other people that would like that too. And I think if we start talking about this maybe we can push for more open source hardware and more system transparency. Thank you.