 All right. Let's jump into it. So the reason we started this kind of talk is a reason we submitted this talk like an explain it like I'm five is because we're kind of into hardware security for protective purposes. Yeah, we do. Are we up? Okay. No. No, we saw look up. Is there anything you want me to do? Test this. We're in. I could put the seal back up too. Yeah, right? It's on. It's off. It's on. It's off. It's on. It's off. So we saw a couple talks that were kind of really, really deep, right? So you there's a bunch today, there's like four really are not today, four this weekend that are really deep into hardware security, mostly around attacking. This is DEF CON that was black at or about attacking. We like securing things. So we wanted to give kind of like an introduction talk that motivates everyone in the audience to want to learn about hardware security and how they can use that to build and secure mobile devices, the general purpose machines that they have, all this IIT swag. But the main objective was kind of to simplify like this overly somewhat complex explanations of hardware security by defining it in the form of like building blocks. We'll talk about like security primitives hardware security primitives and how each one of those are used to build things like security. Nice. I want to kind of start with our objectives for this presentation. And then we'll start going into those building blocks. So our objective was to map hardware security and the uses of hardware security to something everyone's familiar with, like defending a network service, right? Most of the time we know how to defend a network service. We have authentication, we have confidentiality, we have like trust relationships. Those are the things that we use to kind of protect the services. And when we try to build protections around those services, our goals around like isolating the application that's running the service, reducing the attack surface of the machine, so reducing the number of services, confining those services, and auditing them. So finding whatever logs they produce now, whatever logs the system produces, pulling them back, aggregating them, finding a way to search them. So I really need visualizations for this next one, but I can try to wing it. So when we think about an operating system and privilege, there's really only two privilege domains that you get today. Ring three and ring zero. So that you have a concept of users, you have access controls, you have permissions, bits on files. That's not really anything to do with hardware security. Hardware security comes in when you make a context switch from this user land application, route the user, the web user, so on and so forth into ring zero. And that's implemented kind of at the silicon level, kind of actually, really at the silicon level. So the x86, the ISA that Intel is producing has calls that allow an operating system to implement both of these modes. So then you pick your favorite operating system, slackware, and you run a kernel. That kernel is implementing this ISA to switch between privilege and unprolige mode, right? So we get one little ring. We want to put all of our security aware stuff inside of the privilege mode, the security unaware stuff on the outside. That comes down to implementing all of those access controls, the permissions bits inside the privilege mode. So anytime you need to make every time that you have a question that you want to check a permissions bit, hopefully the enforcement of that is inside that privilege domain. Now on x86, there are a couple other privilege levels too. We kind of canonically call these negative one system management mode, and it works in kind of the same way. In the ISA there is some definition of how you can set up this other privilege mode, load some code into it, and then use it as kind of an oracle. Use it as an oracle in a way that you define an API between the SMM and then hopefully you load your security context aware code inside there. Anytime you need to check a permission, I'm talking in vagueness right now, you will access that SMM. Otherwise the kernel cannot modify anything that's happening in there, right? So take a step back and there are definitely attacks against that. Everything I said right there is not true when these APIs kind of fall apart, but that's the general gist of it, right? That's how we define a privilege service. We come up with two domains. So if we want to think of this in the networking mode, you kind of have a LAN and then you have a service on that LAN running on a machine. The privilege domain is the TCP port that you have open. If you want to communicate with that service, you have to communicate over the protocol that it defined. I mean, we tested it a couple of minutes before. I doubt it's something with my machine. Definitely. It's probably the, but I can definitely rub it if you'd like. Sure. So I'm just going to jump in here. So what Ted's kind of talking about is we're trying to think of how can we take something at the operating system level or a software application layer to sort of make a good analogy for what we're trying to talk about for the separation of trusted execution states or context switching of this idea of escalating your privilege. And one of the ways that you can kind of think about that is sort of how an API exposes internal like infrastructure for a big application to somebody on the outside that wants to leverage it and make use of it, right? And so you can kind of think if you have this like barrier or this bubble inside of this bubble is a lot of, you know, abstract and complex system that you're not necessarily going to need to understand or touch, right? This is kind of like merging into where we got restful APIs type of a thing because we're just going to expose a couple of, you know, pieces to you and say, hey, here's this functionality that'll do this awesome stuff. You take it and kind of run and just go wild and do whatever you think you need to do with it. Well, the way that this is working at the hardware layer is almost, you know, it's a very, very similar way. There's a lot of these building blocks, these little pieces that, you know, developers of things like UIFI and the trust computing group, they're, you know, requiring a standard for having these pieces. And we're going to expose the functionality of these pieces to the people that are writing the firmware for you. So it's kind of an analogy that you can use to sort of help make it make sense if you're coming at this from the software world. Right. So let's talk a little bit about those building blocks too. So the building blocks are that like ISA, it's that API, or it's like the HTTP, you know, one one specification. That's how you use it. Only instead of HTTP one one, this specification, these building blocks are around protecting information. So you'll see a lot of like crypto algorithms implemented here that you can use. You'll see some protected storage that you will have access to. And then you'll have like protected IO. So a network service will have to put the mode into us or put the machine just as their mode before any IO can be directed. They're like kind of difficult concepts to explain. So let's start with and can I have visualizations. Oh, the woes of being the first speakers. I'm definitely picking up your color LCD. All right. So, yeah, right. We'll do this. Okay, okay, building blocks that you so we look at all the kind of hardware security APIs with trust zones, the Intel ISA is the AMD is and we try to boil that down like and that includes like the Qualcomm's. Yeah, everything mobile and like, you know, enterprise level desktop, like all of these different platforms are going to have some variant of these these base building blocks that we're just going to talk about. But it really kind of reduces down to having what have you already talked about getting lost. We need to have some type of dedicated storage. So you need to have some form of a chip that you can burn things into. From that you're going to get the concept of this storage also needs to have some capability for being isolated, right? You want to have the capacity or the capability of burning a cert or some kind of a key or something very sensitive to a chip with some level of assurance that nobody's going to be able to tamper with that, right? So, I don't know what else. Yeah. So from with like this dedicated storage, so something that you can burn in one time, blow any fuse and then it will never be modified, plus some implemented crypto algorithms and this tamper resilience that I mentioned, we can get this concept of like extendable trust. So with a private key with an algorithm implemented on the chip and some reasonable guarantee that you need about $100,000. Sorry, man, fighting the good fight. So we can use those kind of primitives or so with those we can have this concept of extendable trust. So with that and then with that extendable trust we can start taking those primitives up a level. We'll add a couple more to those primitives and that'll be the directed IO that we mentioned. And that might include some, yeah, something on the hardware that allows you to interact with this outside the regular band. So that could be another ethernet port on the device, another ps2 port on the device, something out of the band that you can direct input out to. So with that we can take that up a level and start defining concepts like secure boot and trust zone. So I'll just try to do the best I can. We had some pretty awesome images that kind of helped make these things, these concepts a little clearer. There's this whole thing with Pokemon and Legos and I was just this extended. Like it was great. We'll do the best we can, right? So you, everybody's got it in their mind, right? What Pokey N's in general look like. Here's one. Or like Legos, right? So the concept that we use to construct these really complicated technologies like distributor trust zone, which we'll kind of dive into a lot further, is again using the API analogy. We've been given all of these hardware building blocks and we're going to start to sort of string these pieces together to a point where we have a technology platform that enables us to provide that trust. So you start with these hardware building blocks and you build up the capability, the capability of the UIFE firmware. That's the next piece that we need. So we're shooting for secure boot, right? Or trust zone. But we can't quite get there yet. Before you get to there, you have to have a couple of other pieces like the UIFE secure boot and also the concept of these building blocks that we had before like the TPM or some sort of an isolated storage device. Constructing all of these pieces together gives you the framework with which you could implement your version of secure boot. And the reason that there's so many of these varying technologies is because secure boot is more of just a protocol. It's really just there for you to say, all right, we have all of these different pieces and what you should do is try to take the Legos that you specifically need. Yeah. All right, so now all of this makes sense, right? You guys are good? Like we don't even need to start again. Let's go get some scotch. Um, I don't need, are we just gonna? Yeah, we'll just have to tell them to advance. Okay. Oh, we have the slides down there. Oh, man. Yeah, so this is our goal, right? This is where we're trying to get to. You know the order of these. Um, is that, that's one ahead, right? So we're going to build secure boot. Sorry, we're going to start there and kind of start fresh. So a little, sorry, I'm being a little bit redundant, but we're going to take these concepts of extendable trust, dedicated storage, monitoring, monitoring, algorithm state, and we're going to with it, um, start constructing the UEFI 2 plus firmware, right? So this is kind of block number one that we need to reach our goal. And the UEFI firmware, like I said earlier, is this protocol that's been defined. That's, um, I think the trusted computing group is one of the biggest proponents of, of making this protocol clear and concise and have a good design to it, right? And so that's what we really kind of want to focus on today is the design of these things as opposed to their implementations. We'll talk about their implementations a little bit later, but, um, right. So first, once we've got UEFI 2 plus, go to the next. Um, now we come into probably the, the pinnacle piece, the paramount piece of doing hardware security, which is our trusted certificate stores. So the large majority of how secure boot works, or trust zone works, is through these cryptographic protocols. So a really big cornerstone of this is digital signatures. We have to have some way of verifying that the signature you have that you got from Microsoft that's, you know, been verified from them can be stored on your computer and not tampered with or hijacked at any point in time, right? Um, this also brings up a lot of scary thoughts about like, well, Microsoft's just going to take over the world. We'll talk about that. It's all right. You know, don't get too excited yet. I'm excited. Don't get too excited yet. Um, so once we have, once we have those, the last thing, the last piece that we need, again, this comes from Microsoft, but again, we'll talk about that controversy, is the signed bootloader, which is going to be what, you know, uh, executes the different components that you have at the firmware layer and gets you into your operating system. Okay. And that signed bootloader is just an example of this extendable trust that we talked about. Yeah. It could be assigned to anything, right? But with that, with those couple of building blocks plus the certificate store, you now can extend that trust. Right. You've got all of the components that you need. You as an individual or like a corporate company or a corporation to design your own, you know, hardware security platform that you can deploy on your varying devices. We don't recommend doing that though. We don't, please. Please use already developed things. Um, so let's talk about these individual components and kind of explore a little bit more of like what entails constructing them after I drink some water. Um, so for the, for the, uh, for security to function, we have to be able to verify that the firmware that we're executing was actually given to you from the manufacturer. How do we do that? Well, we have to do digital signatures. Digital signatures work by taking the private or the public key that's stored on disk or somewhere on chip, somewhere immutable and decrypting a hash, like a signed hash that was computed by taking a hash of the firmware that you're currently executing. Okay. And to do this, you have to have that public key, which is stored inside of your, your, uh, platform key key store. So the pk, so you might see that acronym thrown around. And then also we have another key store called the kek and the key enrollment key database. I screwed that one up. And the kek is where you can store any third party drivers or components that you want to also have signed. You take the certificates that were signed by Microsoft and also came from, you know, the developer of those drivers and you put them in your kek and this is just where those things live. So as you're going, as you're going through your execution process of your firmware, you can load these digital signatures of your third party drivers up, verify that they haven't been tampered with and then continue execution after you know, like, yep, I'm good kind of a thing. Um, and then also you need the signature database. I don't really remember how that one comes in. You might have to help me on that one. The two biggest ones are the pk and the kek though. So let's keep moving. Um, not right there. Oh, go back one slide. No, we're ruining everything. Go back to slides right there. We're going to start with here. So we want that when we go into our Pokemon battle, right, and we're getting ready to fight some big fierce opponent, we're going to throw out Gyarados and we want those capabilities, right? And this is sort of a hint to what Secure Boot has the capability of operating. Go to the next slide. And so when you don't have Secure Boot enabled, when you're rolling without it and you're kind of like running around naked, you throw out your Pokeball, go to the next slide, and you might end up with a Magikarp and that's a huge bummer, right? You might find yourself surprised or confused or terrified. I just threw Gyarados, why did Magikarp come out, right? And that's a really huge bummer. Um, this is to kind of just illustrate that like without Secure Boot enabled, you're missing out on a lot of functionality, you're missing out on a lot of security and verification for what this technology has to offer you. So go to the next slide. When you do have Secure Boot, it's pretty awesome, right? Um, when the design of Secure Boot is implemented correctly and we have some assurances that everything we're doing has been signed and there's all of the crypto we need, you have a lot of power in what you're doing, like you now have much more capability at the firmware layer, you can do remote updates, you can do all of these different things because you have crypto kind of backing you up and giving you that validation that you need. Um, so and that analogy is pretty cool only because Pokemon is fucking awesome. Um, but it's very hard to get a Magikarp into a Gyarados, right? The only thing it knows is Flau and that's really not going to win any battles for you. So if you are running an enterprise where you need to run weird drivers or weird firmware edits or booted operating system that has a bootloader that isn't signed and provided so that you can't just download a binary version of grub or binary version of Windows bootloader, you need to do a little bit of work. And that little work involves loading up that kek with your own certificate, managing that CA, whatever sign that certificate, and then distributing it to all the machines that you want to run this firmware, modify firmware on. That is a lot of work. Yes. It's almost almost impossible for a small organization, small or medium organization, right? But fortunately, they're not really doing that, right? You're not usually pushed into a mode where you have to train a Magikarp up to a Gyarados, right? This doesn't really happen. So and just to kind of elaborate further on that note, if you think about it, this is still a really new technology, right? So the capabilities of making this wide scale where you can roll out your own custom firmware that's been signed appropriately that honors all of the protocol is secure boot, there's not a lot there yet, right? But we're getting there. This is a baby technology, and it's still coming around. So that's like just kind of keep that in mind when you're like seeing all of this secure boots off, we'll just turn it off. It's so bad. Kind of bear that in mind. Next slide. Right. So we're going to talk a little bit more about other technologies have been talking have been running on about secure boot a lot. But this is kind of a quick overview of the different types of measured booting that you can do, I'm gonna say measured in a general sense, but there is also something called measured boot. We were just got done talking about secure boot, right, which is verifying that everything has actually been digitally signed before you start actually executing it. There's also know that. Sorry, there's also something called trusted boot, which is much more often talked about in the Windows world. This is actually a trifecta of three different types of boots, secure boot, measured boot, and also verified boot. That's right. Thank you. And trusted boots pretty neat in the sense that if you're just rolling vanilla windows, and that's, you know, what you do in life and you're not looking to customize, which I know everybody in this room, that's how you roll. I know that. That's a good joke. I thought it was good. This is going to give you the opportunity to verify every single operating system driver before it loads before you get into the operating system kind of thing. It's also going to give you something called Elan early launch anti malware, I believe. And what this is doing is trying to find root kits trying to find things that are hiding out in Kerneland that are trying to separate your operating system. So again, you know, try to take away from this the idea of the technology. It's really awesome idea. And we should start seeing more of these types of things deployed. And then lastly, measured boot. This is more along the lines. If you're like, you know what, that's cool that you're trying to protect me and all. But really, I just want to run naked. And how about you just let me know when I'm naked or when something bad might have happened to me. That's where measured boot comes in. It's still going to walk through a lot of these different procedures, but it's just going to do an alerting. It's going to be like, Hey, you're about to load some malware. Just, you know, thanks, you know, you can continue execution. Next slide. Cool. So in those words, secure boot, trusted boot, measured boot, verified boot, most of the time, they're used interchangeably. I know in a couple of the sentences we had, we used the modal incorrectly. But the big differentiation is the measured boot from kind of all the rest. But in every single scenario, you have the opportunity to make a decision. And you can be a piece of software that's running or could be a remote service that's making a yes or no decision, right? And that's what it, that's like the big takeaway. I used it incorrectly. I'm so sorry. I was like, dude, what did I do wrong? It's not yet. Not yet. Okay. But the way that's kind of implemented with those building blocks that we talked about is kind of this little cycle that you see here. So we're going to fetch load code. We're going to measure it in a way, kind of like a hash that's always being added, right? So we call that like extending a hash. So you kind of take the hash from before and the hash is the code that you're going to be now and you get this amalgamation and you load it. The point there being that you can't load code that embraces the hash. And then you're going to apply like an optional signature check. So in the case where you're not worrying about these hashes or like maybe there's a little bit of variance and the hashes are always coming out to something that you can't keep like this big map of. We can attach a little signature to the code that we're about to load, assuming that the code before it knew how to verify that signature and also had some trust extended so that it can check that signature. Finally we have this ability to kind of push those hashes and those signature checks to some remote service that can possibly make a decision, right? And then finally we'll make that decision. With a yes and go forward with a no, we could still go forward or we could abort the whole entire operation, right? We could also set a couple bits that identify that the operation would have been aborted so that you can still continue just in a different mode. And a really good canonical use of that is not decrypting a certain storage device afterwards. So the decision that you make is not to stop booting, it's just to not reveal sensitive contents going forward. So when you think of this kind of like trust chain, like whatever code is coming before the code that you're loading right now has to be aware. The instant that there isn't this awareness of checking or measuring, the whole entire chain is broken. That's what we call like a root of trust measurement or dynamic root of trust measurement. That root is like this establishment of like your foot bone attached to your ankle, attached to your leg, like so on and so forth up the body, right? As soon as you're missing one of those bones, the whole kind of thing starts to fall apart. More so, you can't trust the stuff that goes past it, right? Sorry for that, you know. I just put, I like to put like underwear on slides, just kind of a little bit. Ha ha ha ha! No, I'm sorry. All right. Hey, here we go. I think we have trust on coming up. Can't really see the next slide. Yeah, perfect. This is me. So that was just kind of a reminder of kind of like where we are in the thing, but we didn't start with slides, right? So that doesn't super matter a lot. Um, so nobody really knows where we are at. So we did a big talk about secure boot, and that's great and well. But Nick, I hear you say, what about my phone? Well, you common beliefs, there is an answer to one's phone. Um, and that's trust zone, and this got introduced into the ARM Cortex chips, uh, somewhere within 2003, right? So it's been around for a long time. So I'm talking about baby technologies and really that's not accurate with this at all. Um, but where trust zone comes in is, again, we want to use a similar analogy. We have all of these, but we're using Pokemon this time instead of Legos, just I know you were concerned. Um, we have a lot of different Pokeballs, right? And we have a lot of different types of Pokemon. And so what you want to ensure when you're designing your trust zone setup is that when, you know, you go to the certain region in the Pokemon world, you want to make sure you bring the right Pokeballs to catch the right type of Pokemon that's there, right? But you also want to bring your all star team that's going to do very well against those type of Pokemon. So it's a similar concept with trust zone in that you, you are given a large amount of hardware pieces on the board that you can take advantage of and leverage, but you're also given a lot of like software protocol specifications that you can also make use of, right? And so trust zone varies from secure boot in the sense that oftentimes this is less stuck to as like a constant standard and companies usually just take this spec, this guideline and say we're going to make our own proprietary version of this and that's where you get things like Samsung Knox and also Qualcomm I think has QSE, there was a talk last year at Black Hat about Samsung Knox, Samsung Knox or QSE, one of them and it was, it was silly, so you should go check that talk out, it's pretty cool. Not the talk, the implementation. Yeah, that's what I meant to say. What did I say? Anyway, great. So, so with trust zone too, so ARM kind of has built this API, like the protection domain that we were talking about before and they released it in the form of like the ISA. So here's the manual on how to create a protection domain. Please write me some software that implements this protection domain such that I can load code in kind of a secure mode, a secure world, but also like an unprivileged mode which would be your normal operating system and then Qualcomm and and Samsung Knox will license that spec from ARM and they'll implement what they'll implement this trust zone APIs, right? Next slide. Yeah. I can continue on this. Right. So if we're talking trust zone words, right, this is called like an execution environment, but it is that privilege domain. So anything loading inside the trust zone T, right, the trust zone secure world is the equivalent of that like it's not the actual equivalent, but it's the equivalent in the metaphor of a privilege domain in your operating system and the unprivileged domain in user mode. Same metaphor applies to the privilege service that's running on the network versus the network, the LAN itself, right? So then you can leverage this to build something like secure boot, right? You build secure boot and trust a boot and trust a Me? You did? No. Okay. Right. So the way you get the way you get secure boot with this this kind of capability is you load a small little operating system called like your boot operating system. It knows how to load code into this secure world, right? The ROM on your mobile device, your phone, your ARM platform is measuring that that boot operating system. Once it sets up the secure world, it can now make API calls to that. Hopefully there's some storage in that secure world with some certificate stores. Now that boot can load a normal operating system while the secure mode is auditing it, right? Measuring it and checking additional drivers, additional firmware that it might load. And this is done, right? There is a secure boot for ARM devices, for Android devices, and it's implemented with all these APIs. Yes. I think that's coming later. I don't want to give away spoilers, but we're gonna... Right. Yeah, we kind of skipped like what a TPM is, missing a few of the slides, but the same things that you would use to build a TPM, you could use with these APIs too, and they call it secure core. So both a TPM and whenever incantation it is, whether it's like the new Intel platforms or they have a TPM 2.0 in the silicon, or you have a discrete TPM that you'll add to your motherboard, or secure core, they're all using these primitives that we talked about and they're implementing them. Okay, so this was kind of what we were trying to build up to. Ted already sort of talked about what this slide is kind of illustrating, but it's really just the trust zone is giving you this capability, right? You can in some sense have these two different environments of operation sitting right alongside of each other like on your mobile device. So you could switch into a mode of computing and performing really sensitive operations or having really sensitive data, and then you could jump out of that context and go back into the normal human user mode where you can check Facebook and get on Twitter and do the things that you need to do. Kind of like how Unikitty goes back and forth from being crazy and upset and angry to super happy. Next slide. But yeah, the actual implementation of these things gets really, really complicated really, really quickly, right? The specs that you can read for secure boot or for trust zone, they're huge. They're these massive documents of just constant changes and revisions to the spec. So this is really just to kind of illustrate like, you know, we're trying to make this at a really higher level of design functionality, but you can see how quickly this gets like muddled and very, you know, noisy. Yeah, so one way our kind of analogy between the network service and the operating system, the service ring on the operating system falls apart is I can install a Python module that will implement like a RESTful API and giving a web server. If I wanted to implement UEFI I have to read over 2,500 pages of the spec and then go consult an even larger number over a million lines of code of reference specification. And the same would exist for trust zone too. So there's lots of complications here, lots for rooms of ever. And that's why you see all these great talks about breaking these things is because those implementations were misused or the building blocks weren't used correctly. And this kind of feeds into the old saying, don't roll your own crypto, right? And it's because of reasons like this. It gets very complicated very quickly and one small mess up leads you completely open and totally vulnerable, right? So hopefully this kind of illustrates that complexity factor. Next slide. Again, just, you know, try and keep you where we're at. Next slide. Cool. Do a hardware security tour. So we're going to cruise around the region and talk a bit about these implementations. We'll go to the next slide. So TPMs, if you want to buy a TPM, actually I have a couple of discrete TPMs up here. If anyone's looking to like play around with one and they have little embedded boards that speak I2C, I can give you a couple. Otherwise, if you look for purchasing motherboards that have the Intel Small Business, you'll get a TPM or you'll get some implementation of a TPM might be in the Silicon TPM 2.0. These are really cool. Well, they implement almost all of those building blocks except for kind of the directed IO and execution isolation. So I can't hand off code to the TPM and say, hey, create me a privileged domain and run this code in it and then I'm going to make API calls that you can't really do that. HSMs are kind of like your Pokeball, right? And there was a reason why I had a bunch of these emoticon or emoji poops up there, but I'm not going to explain it now. But HSMs are kind of like your CACs or your smart cards or the UBHSM, and they do implement various parts of those building blocks. So most of the time you're going to have a certificate store on there. You're going to push certificates in there, hopefully, blow an EFU so that those certificates cannot ever change. But on almost every case, you will not be able to read the private key from those cards unless you're using some other directed IO. So you put your HSM into your machine that needs to access the public keys for these certificates and only the software running on that machine or the software on that machine will only be able to access the public keys. The next slide. So trust zone and secure core, right? Implementing this privileged domain and Qualcomm's Cure MSM, right? And like we said before, they license the trust zone spec and they can build towards it, right? And they can call it their own. Same with NOx, right? NOx at the bottom is just this trust zone spec. Cool, going forward. So TXT and IOMMU are a little bit different. We haven't really jumped into this domain. But the IOMMU is going to be an API around isolating devices and memory reads. So when we think back to the primitives that we talked about and the reason we're bringing these things up is if you're interested in IOMMU or building things for TXT, please do. That's going to give you that kind of direct IO plus the isolated execution. So now I can take that isolated execution and extend it to a potentially untrusted driver for like a network card that I'm testing out. Furthermore, I can create that kind of concept of a secure world that trust zone gives me on an Intel platform. So I can take a bit of code, I can push it into a privileged domain, I can define the APIs for it, and I can make calls to it. So if I wanted to bootstrap some protected keying material in there and then launch a web service that's going to negotiate session keys, it can do that to that little isolated environment, right? And it uses TXT for that. So that'll push the code onto a single CPU, set up the IMU for you. You're going to have to do a little bit of that yourself, but at the end of the day, you're going to get this dedicated storage, a dedicated part of DRAM. You're going to get dedicated execution on a single core, and you're also going to get a measurement afterwards. So, and then you can use other measurements that may already exist to kind of come up with a decision of whether you're running in a trusted environment, on a trusted machine or in a trusted state, and then you can make that, you can extend that decision further. So maybe like a remote service. We'll keep going. SGX is kind of this like awesome sauce that's coming out, but it'll take that TXT IMMU concept and push it into your user land apps. So now your user land applications can do the same thing. They can set up their own kind of bastion of isolated execution and then allow other services to make calls to that. So now we take that privilege domain and we pull out of the ring zero and we can push it into like whatever we define. It's very, very, it's a very complicated like concept, but with that, I hope that we can really start taking these like large attack surfaces that we have against both applications running on the host used to escalate privileges, but also applications running as network services and kind of define these APIs between accessing protected material and then serving up that content on a TCP port. Right. So we'll make one aside here and if you wanted to log every execution of a process on OSX, right? You could go into the kernel, write a kernel extension, hook sysent, I don't recommend doing that. So you use OSX the Mac policies or the k-auth APIs and every time one of those syscalls are called, you create a log, create a log, right? So sort of some ring buffer push the some struct into that ring buffer and that becomes your log. So start doing this about 5,000 times an hour for the process that 5,000 times an hour that'll be the process that'll run per hour if you're using your machine hardcore. What do you put that data? So from the privileged domain you audited that requiring an attacker to get into the kernel to bypass that but what do you do with that data? Can you from kernel and start pushing it out to a network service? What kind of what kind of arrows do you need to define? In almost every example you have to go back out of that privileged domain to write that data. That makes a lot of sense too if we're defining reliable services I can't for every exec make a TCP call and throw this or a UDP call and throw this off to the network. I could buffer it there so now I'm taking memory away from the system so if I wanted to compress that I'm implementing all these compression APIs inside the kernel too. It's just it's it's not really a lot of fun. So what we end up with is something called like audit D and we start auditing these events to a file in the unprivileged world and then we put like root access on there. So we're adding these permissions bits that are enforced in the unprivileged world an attacker only needs to go up to root. Well if they went up to root they would just take my kernel extension away or my kernel module away to begin with right. So what we really need and go to the next slide is this concept of SGX or that blue circle is now become purple that is my little privileged mode existing outside of the traditional operating systems privileged land and now I can write directly from the privileged log of the of chaos to that little land that can implement my buffering that can implement my compression and that can choose the schedule in which it pushes data off. So now I get all the advantages of not crashing the kernel if I somehow implemented my compression or my scheduling wrong right but I still can log this from the privileged domain which is the operating system a little deep but just kind of try to isolate just or write an example of how you would do something like this isolated execution right. We're almost finished here we'll a couple more we'll go right past this. Another thing we really didn't get too much time to talk about is these out of band systems which implement these isolated executions IPMI is kind of the equivalent of like the trust zone it's the specification to which like ILO and the things like ILO and DRAC or even like AMT or Intel's management engine or secure engine right and that's kind of another mode outside that has special APIs to run into this this privileged land and those APIs usually are in the form of like accessing or making DRAM calls or having access to some of those memory buses that are otherwise protected otherwise protected by the ISA we'll go one more and we'll go past this right so failures and use cases can you hit the play button there it's worth it you'll dig it yeah right so most of the failures in the hardware security come in the form of like a cat trying to walk a dog where the API wasn't implemented correctly and now you have some unprivileged mode commanding what you thought was the privilege mode because like dogs are the privilege that's your kernel they hurt all the cats right there are the unprivileged people they're us right and one more and so the kind of uses of these the things that we kind of wanted to impress on everyone is one please do not turn off secure boot right if you want to boot your operating system if you want to boot a different operating system different firmware figure out a way there is a way read a little bit more and we'll we'll keep secure boot on and we'll get you executing that something that we didn't quite mention I'm going to jump in really quick is that you know there's a lot of talk about like well if I have secure boot on with my laptop I can only ever use windows at the moment there is currently a lot of support for things like Ubuntu fedora open Susie that will keep secure boot on and actually continue to boot with secure boot enabled so it's still performing all of these integrity checks that you want to have and the way that they're doing that is by having a little boot shim that's still signed by Microsoft they're still going through all of Microsoft certs but they're kind of hijacking that process with their own you know bootloader execution bootstrapping process if that kind of makes sense I know that said that weird but this it's kind of more motivation for why you should leave secure boot on is the functionality is coming like it's there we're building it but please help be part of the the solution not the problem another really cool thing to look forward to which exists right now on in the windows phone and almost there and we got we got four minutes we're 40 yeah we have until 45 so we're getting it out yeah we'll we got like four minutes yeah cool yeah yeah so uh at testing these like mobile app containers so right now isolation happens on mobile devices like it's awesome right there isn't like a mobile platform out there that isn't implementing some form of isolation you're now going to start seeing APIs for letting a remote service make a decision for the user right but it's scary at first but when that decision becomes a remote service saying hey we think your phone booted a different firmware a different operating system would you like to continue yes or no that kind of friction will only end up for people who are running things like cyanogen mod right modding the firmware modding or putting a different operating system and they already kind of understand that there's going to be a little couple hiccups and it should be the owners of them to load like the certificate for that cyanogen mod onto their phone it kind of relates back to like ruining your phone or jailbreaking your iPhone right like you're making the conscious decision to kind of run things as root and remove the security protections that have been placed there in the first place not that there's anything wrong with that but it's just that you've made that conscious decision so having a server kind of like give you the heads up and say hey wait a minute something's different that be kind of a sweet feature even if you still just kind of skip right past it and do it at your own discretion that's a great example of how we're using these like how we all can start using these hardware security primitives to push it into something like a consumer can use they can use that decision hey your phone booted in a different way continue yes or no right and then like more info and then we can kind of deduce that down into a better decision for them they probably don't know whether to hit yes or no so we can have a setting somewhere that says hey if my phone ever boots in a mode that isn't trusted here's the default option right and then we can defaultly set that to please don't continue it's really similar to like the SSL validation right you go to a website and chrome or somebody stops you and says hey wait a minute this search wrong but you just skip right past that right that's what we all do but it's a similar kind of a concept right hopefully we'll get to a point where there's enough indicators to say wait a minute this is potentially very bad are you really sure that you want to go you know it kind of has hints of that to it cool and I think the next slide will kill it done so great please if you're interested in this stuff if this was a little bit too high level or too basic of an explanation for you right there's definitely a lot more to look forward to if this definitely got to your interest please also go and look at these talks or please hit us up afterwards definitely definitely love to to talk to you thank you questions