>> All right.  Let's jump into it.  The reason we started this kind of talk, the reason we submitted this talk like explain it like I'm five is because, we're kind of into hardware security for protective purposes.  Are we up?
  Yay, no?
  We -- anything you want me to do?
  Test this.  We’re in. I can put the seal back up, too.  It's on.  It's off.  It's on.  It's off.  All right.  We saw a couple of talks that are really deep.  There's like four really -- not today four this weekend that are really deep into hardware security.  Mostly around attacking this is DEF CON that was Black Hat we're about attacking we like securing things, so we wanted to give like introduction talk that motivates everyone in the audience to learn about hardware security and use that to build and secure mobile devices, the general purpose machines that they have, all this IoT swag.  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 how each one of those are used to build things like secure boot.
  >> Nice.
  >> Want to start with our objectives for this presentation.  Then we'll start going into those building blocks.
  Our objective was to kind of map hardware security and the uses of hardware security to something everyone is familiar with.  Like defending a network service.  Most of the time we know how to defend this.  We have authentication, confidentiality 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 is running the service, reducing the attacker is fas of the machine, reducing the number of services.  And audited them.  Finding whatever logs they produce, pulling them back, aggregate can them finding way to search them.  Cool
  >> I need visualization for to but I can try to wing it when we think of an operating system and privilege there's really only two privileges you get today.  Ring three and ring zero.  So that you have a concept much users, you have access controls, you have permissions, bits on files, that's not really making -- anything to do with hardware security.  Hardware security comes in when you make context switch from user land application, the web user, so on.  Into ring zero.  That's implemented kind of at the silicon level.  Kind of actually, really at the silicon level.  X86, Intel producing -- allow implement both of these modes.  Then you pick your favorite operating system.  Slackware, and you run a kernel that is implementing this ISA to switch between privilege and unprivileged mode.  We get one little ring.  We want to put all of our security aware stuff inside of the privileged 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.  Any time you need to make -- every time you have a question that you want to check a permissions bit hopefully enforcement of that is inside that privilege domain.
  Now X86 there are couple other privilege levels, too.  Kind of call these negative one.  System management mode.  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 way that you define an API between the SMM then load your security context aware code inside there and any time you need to check the permission, I'm talking in vagueness right now, you'll access the SMM otherwise, the kernel cannot modify anything that's happening in there.  Take a step back, there are definitely attacks against that.  Right there is not true when these APIs fall apart but that is the general gist of it.  That is how we define a privilege service.  We come up with two domains.
  Now think of this in the networking mode, you kind of have a LAN then you have a service on that LAN running on a machine.  The privilege domain is like 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 couple of minutes before, I doubt something with my machine.  Definitely.  It's probably the -- I can definitely reboot if you like.
  >> I'm just going to jump in here.  What Ted is talking about we're trying to think how can we take something like 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 trusted execution states or like context switching, right, 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 it of, right?
  You can think if you have this like barrier, this bubble inside of this bubble is a lot of abstracts and complex systems, not necessarily going to need to understand or touch.  This is kind of like merging into where we got APIs type of thing we're just going to expose a couple of pieces to you say, hey, here is this functionality that will -- 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 this is working at the hardware layer is almost -- very, very similar way.  There's a lot of these -- these little pieces that developers of things like the trusted computing group they're 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.  It's an analogy that you can use to sort of make it make sense if you're coming at this from a software world.
  >> Right.  Let's talk a little bit about those building blocks, too.  The buildings blocks are that ISA, it's that API or it's like the HTTP 11 specification.  That's how you use it.  Only instead of HTTP11 this specification these building blocks are around protecting information.  You'll see a lot of like 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 network service will have to put the mode into -- put the machine into just a mode before any AIO can be detected  -- difficult context to explain.  Let's start with, can I project now?
  If we had visualizations it would be so much better.  How about now?
  Oh, the Woas of being the first speakers.  I'm definitely picking up your color LCD.  All right.  Yeah, right.  We'll do this.  Building blocks that you -- we looked at all the kind of hardware security APIs, the trust zones, Intel ISA as the AMDs we try to boil that down, that includes the Qualcomms, the --
  >> Everything mobile and like, you know, enterprise level desktop like all of these different platforms are going to have some variant of these blocks that we're -- Ted is going to talk about.  It really kind of reduces down to having one -- 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 key or something sensitive to a chip with some level of assurance that nobody is going to be able to tamper that, right?
  >> Yeah.  So, from like this dedicated storage, something that you can burn in one time, blow any fuse then never be modified plus some crypto algorithm this resilience we can get this concept of extendible trust.  With a private key with a algorithm implemented chip and some reasonable guarantee that you need about $100,000 --
  >> Fighting the good fight.
  >> We can use those kind of primitives -- with those we can have this concept of extendible trust.  So, with that, then with that extendible trust we can start taking affirmatives up a level.   Add couple more, the directed IO that we mentioned.  And that might include some -- something on the hardware that allows to you interact with this outside the regular band.  So that could be another Ethernet port on the device another PS2 on the device.  And that you can direct input and output to.  With that we can take that up a level start defining concepts like trust zone.
  >> I'll just try to do the best I can.  We had some pretty awesome images that helped make these things darks darks concepts a little clearer, there this was whole thing with pokeymon and Legos --
  >> You're missing out it was great.  We'll do the best we can.  What pokemon in general looks like.  Or like Legos, right?
  The concept that we use to construct these really complicated technologies like security trust zone which we'll dive into lot further is, again, using the API analogy we've been given all of these hardware building blocks and start to string these pieces together to a point where we have technology platform that enables us to provide that trust.  So, you start with these building blocks you build up the capability with the firmware, that's the next piece that we need.  We're shooting for secure boot 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 secure boot and also the concept of these building blocks that we had before TPM or some sort of isolated storage device.
  Constructing all of these pieces together gives you the framework with which to implement your specs of secure boot.  And the reason that there is so many of these varying technologies because secure boot is more of just a protocol, it's really just there for to you 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 --
  [Applause]
  Now all this makes sense.  You guys are good?
  We don't even need to --
  [ inaudible ]
  Start again.  Let's get some Scotch.  Are we just going to --
  >> We'll just have to tell them to advance.  We have the slides down there.
  >> Advance.
  >> Oh, man.  Yeah, so this is our goal.  This is where we're trying to get to.
  >> There we go.
  >> Even know the order of these.  Is that -- that's one ahead we'll build secure boot.  We'll start there start fresh.  Being a little bit redundant we're going to take these concepts of extendible trust, dedicated storage, monitoring, algorithm, state, we're going to with it start constructing the firmware.
  This is block number one that we need to reach our goal.  And the Uwifi firmware is this protocol that's been defined that is I think trusted computing one of the biggest proponents making this clear and concise and have a good design to, right?
  So that is what we want to focus on today is the design of these things.  As opposed to implementations.
  We'll talk about the implementations later but -- first ones we've got Uwifi 2 plus.  Now the paramount please of doing hardware security is our trusted certificate stores.  The large majority of how secure boot works or trust zone works through cryptographic protocols.  Digital signatures.  We have to have way verifying that the signature that you have that that you got from Microsoft that has been verified from them can be stored on your computer not tampered with or hijacked at any point in time, right?
  This also brings up a lot of scary thoughts about well Microsoft just going to take over the world, we'll talk about.
  That don't get too excited yet.  I'm excited, don't get too excited yet.  Once we have those, the last thing, last piece that we need again this comes from Microsoft but again we'll talk about that controversy is signed letter which -- executes the different components at the firmware layer gets you into your operating system.
  >> That signed boot loader just an example of the extendible trust that we talked about.  It could be assigned to anything.  But with that dash those couple of building blocks plus the certificate store you can now extend that trust.
  >> You've got all of the components that you need, you as individuals are like a company or corporation, to design your own hardware security platform that you can deploy on your varying devices.
  >> Don't recommend doing that, though.
  >> We don't, please.  Please use already developed things.  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.  For the -- secure boot to function we have to be able to verify that 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 -- public key that scored on disk or somewhere on a chip, somewhere immutable, assigned hash that was computed by taking the currently executing.  To do this you have to have that public key, which is stored inside of your platform key, key store, the PK you might see that acronym thrown around.  Then also we have another key store called the KEK.  Key enrollment key database.  I screw that up.  The KEK is where you can store any third party drivers or components that you also have signed you take the certificate, is that ever signed by Microsoft and also came from the developer of those drivers, and you put them in your Kek this is just where those things live so as you're going through your execution process of your firmware you can load these digital signatures of your third party drivers up, verify they haven't been tampered with then, yep, I'm good.
  Then also need signature database, I don't remember how that one comes in.  You might have to help me on that one.
  Two biggest are the PX and KEK.  Let's keep moving.
  Go back one slide.  Go back two slides.  We'll start here.  So, we want that when we go Pokeyman battle we're fighting big fierce opponent we'll throw out those capabilities, right.  This is sort of a hint to what secure has capability of offering you.  Go to the next slide.  So, when you don't have secure boot enables, you're rolling with running around naked, you throw out your woke ball might end up with a magikarp that's a huge bummer.  Might find yourself surprised or confused or care filed.  Why did that come out?
  That's a huge bummer.  This is the kind of illustrate without secure boot enables you're missing out on a lot of functional -- missing out on lot of security and verification for what this technology has to offer you.
  Go to the next slide.  When do you have secure boot it's pretty awesome, right?
  When design of secure boot is implemented correctly and we have some assurances that everything we're doing has been signed 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.
  >> That analogy is pretty cool only because Pokeman is fucking awesome.  But it's very hard to get a magikarp into a -- only thing it knows is Flo.  If you are running an enterprise you need to run weird drivers or weird firmware or boot an operating system that has boot loader that isn't signed and provided and do you understand load binary grub.  You need to do a little bit of work.  That little work involves loading up that Kek with your own certificate, not entering that CA, whatever sign that certificate then distributing it to all the machines that you want to run this firmware, modified firmware on.  That is a lot of work.  It's almost impossible for small organization.  Smaller, medium organization.  But fortunately they're not doing that.  You're not usually pushing to a mode or train magikarp up to a Garados.
  >> So um, just to kind of elaborate on that note, if you think about it this is still a really new technology. The capabilities of making this wide scale where you can roll out your own custom firmware that's been signed appropriately that honors that there is not a lot -- this is baby technology it's still coming around.  So that's like just keep that in mind when you're like seeing this, turn it off, it's so bad.  Bear that in mind.  Next slide.  We're going to talk a little bit more about other technologies I've been droning on about secure boot a lot but this is a quick overview of the different types of -- I'm going to say measured in a general sense but also something called measured boot.  We just got done talking about secure boot which is verifying that everything has actually been digitally signed before you start actually executing it, also -- sorry also something called trusted boot.  Which is much more often talked about in the Windows world, actually a trifecta of three different types of boot, secured boot, measured boot also verified boot.  That's right.  Thank you.  Trusted boot is neat in the tense that if you're just rolling vanilla Windows, that's what you do in life 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 early launch anti-malware.  Is trying to find root kits, things that are hiding out in kernel land trying to subvert your operating system.  Again, try to take away from this the idea of the technology.  It's really awesome idea, we should start seeing more of these types of things deployed.  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 I just want to run naked how about you let know know when I'm naked or when something bad happened to me.  Then still going to walk through a lot of these features but just going to do an alerting, like, hey, you're about to load malware, you can continue execution.  Next slide.
  Cool.
  >> The words secured boot, measured boot, verified boot most of the time they're used interchangeably.  I know in couple of of the sentences we had we used them a little 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 remote service that's making a yes or no decision, right?
  That's what -- like the big take away.  I used it incorrect leave, man, I'm so sorry.
  >> Like, dude, what did I say wrong?
  >> Not yet.  The way that's implemented with those building blocks that we talked about is this little psych they'll you see here.  So, we're going to fetch load code.  Going to measure in a way like a hash that's always being added, right?
  We call that like extending a hash, so you take the hash from before and the hash of the code that you're going to do now you get this amalgamation and you load it.  The point there being that you can't load code that erases the hash.  Then you're going to apply like an optional signature check in the case where you're not worrying about these, there's a little bit of variance in 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?
  Then finally we'll make that decision.  With the go forward with with no still go forward or could abort the whole entire operation.
  We can also set a couple of bits that identify that the operation would have been aborted so that you can still run just in a different mode.  Really good economical use not decrypting a certain storage device afterwards so that the decision that you make is not to stop booting, it's just to not reveal sensitive content 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 like ankle, attached to your leg, so on, so forth up the body.  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 that interlude.  I like to put underwear on slides, too, it's my thing.
  No, sorry.  Can we go?
  I think we have trust zone coming up, I can't really see the next slide.
  >> This is me.  That was reminder of like where we are in the thing but we didn't start with slides, right, it doesn't super matter a lot.  Nobody really knows where we're at.  We did a big talk about secure boot and thats great.  But Nick I hear you say, what about my phone?
  Well, you common pleebs there is an answer to one's phone.
  >> In 2003.  Right.  It's been around for a long time.  So I'm talking about baby technologies and that's not accurate with this fall.  But where trust zone comes in is again we want to use a similar analogy.  We have all of these -- using Pokeman this time instead of Legos I know you were concerned.  We’re using Pokemon this time instead of Legos. We have a lot of different poke balls and different kinds of Pokemon what you want to assure designing your trust zone, when you go to the certain region in the Pokemon world you want to make sure you bring the right poke balls to catch the right Pokemon but also bring your all -- going to do very well against those type of Pokemon.  So, it's a similar concept with trust zone that you were given a large amount of hardware pieces on the board that you can take advantage of and leverage.  But also given a lot of like, software protocol specifications that you can also make use of, right?
  So, trust zone varies from secure boot in the sense that oftentimes this is less stuck to you as like a constant standard.  And companies usually just take the spec, the guideline, make our own proprietary version of this and things like Samsung knox and Qualcomm has QSE.  There was talk at Black Hat about Samsung knox or QSE one of them, it was silly you should check that talk out, pretty cool.
  >> Not the talk.  The implementation.
  >> Yeah.  That's what I meant to say.
  >> What did I say?
  Anyway.
  >> With trust zone 2, arm kind of is built this API like the protection domain that we were talking about before and the ISA.  Here is the manual how to create a protection domain, please write me some software that implements this protection domain, such that I can load code and kind of secure mode, also like unprivileged mode which would be normal operating system.  Then Qualcomm and Samsung knox will license that spec from arm they’ll implement this trust zone APIs, right?
  >> Next slide.  I can continue on this.  If we're talking trust zone, this is called like execution environment.  It is that privilege domain.  Anything loading inside the trust zone T, right, the trust zone secure world, is the equivalent of that like -- not the actual equivalent but equivalent in the metaphor of privilege domain in your operating system and unprivileged domain in the user mode.  Same metaphor applies to priviledge service, versus the network, the LAN itself.  You can leverage this to build something like secure boot.  Right?
  You build secure boot and trusted boot and trust zone.
  >> Me?
  >> You did?
  >> No.  Right, the way you get -- the way you get secure boot with this kind of capability is, you load a small little operating system, like your boot operating system.  It knows how to load code in to this secure world, right?
  The room on your mobile device, your arm, platform is measuring that boot rating 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.  Measuring.  Checking additional drivers, additional firmware that it might load.  This is done, right?
  There is a secure boot for arm devices for android devices, and it's implemented with all these APIs.
  >> I think that's coming later.  I don't want to give away spoilers but we'll --
  >> Right.  We kind of skipped like what a TPM is, missing few of the slides but the same things that you would use to build a TPM you can use with these APIs, too, they call it secure core.  Both a TPM in what incantation it is like new Intel platforms the TPM2.0 in the silicon or add to your motherboard.  Or secure core they're all using these primitives that we talked about and implementing them.
  >> Okay.  So this was kind of what we were trying to build up to.  Ted already talked about what this slide is kind of illustrating, but it's really just the trust zone giving you this capability.  Right?
  You can in some sense have these two different environments of operation sitting right along side of each other like on your mobile device so you can switch into a mode of compute, performing sensitive operations -- data and then you can jump out of that context go back into the normal user mode where you can check Facebook get upon Twitter do the things that you need to do.  Kind of like how goes back and forth from being crazy and upset and angry to super happy.  Next slide.
  But, yeah, implementation of these things gets really complicated really, really quickly.  The spec that you can use they're huge these massive documents of just constant changes and revisions to the spec.  So this is really just illustrate -- trying to make this at really higher level of design functionality but you can see how -- this gets like muddled and very noisy.
  >> One way our analogy between the network service and the operating -- service running on the operating system falls apart sick install a python module implement like a API give me a web server if I wanted to implement UAFI, read over 2,3500 pages of the spec and then go consult even -- over a million lines of code of reference specification.  The same would exist for trust zone, too.  There's lots of applications here, lots for rooms of error that's why you see these great talks about breaking these things because those implementations were misused or the building blocks weren't used correctly.
  >> This kind of feeds into the old, don't write your own crypto.  Very complicated, very quickly, one small mess up leaves you have completely open and totally vulnerable, right?
  Hopefully this illustrates that complexity factor.  Next slide.  Again, just trying to keep where you we're at.  Next slide.
  Cool.
  >> Do hardware security tour.  So we're going to cruise around the region and talk a bit about these implementations.  Go to the next slide.  TPMs, if you want to buy a TPM, actually I have couple of discrete TPMs up here if anyone 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  Intel small business you'll get a TPM or get some implementation might be in the silicon TPM.  These are really cool.  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 say, create me a privilege domain and run this code in it then I'm going to make API calls.  You can't really do that.  Are kind of like your poke ball, there was a reason why I had a bunch of these emoticons  but I'm not going to explain it now.  But like your Keks or UBHSM they do various parts of those building blocks.  You're going to have a certificate store on there, you're going to have a push certificates in there hopefully below E-fuse so the certificates cannot never change.  But on almost every case you will -- read the private key from those -- some other directed IO.  You put your HTM into your machine that needs to access the public keys for these certs and only the software running on that machine or software on that machine will only be able to access the public keys.
  Go to the next slide.  Trust zone and secure core.  Implementing this privilege domain and Qualcomm Secure MSM, right?
  And like we said before they license the trust zone spec they can build towards it and call are the are their own.  Knox at the bottom is just this trust zone spec.  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 talk about and the reason we're bringing these things up is if you're interested in these, in IOMMU or building things for TXT please do.  That is going to give you that kind of directed IO plus the isolated execution.  Now I can take that isolated execution and extend it to 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.
  I can take a bit of code, I can push it into a privileged domain, I can define the APIs for it and make calls it to.  If I wanted to bootstrap some protected key material in there then launch a web service that is going to negotiate session keys, it can do that to that little isolated environment, right?
  And it uses TXT for that.  That will push the code on to a single CPU, set up the IOMMU for you, you're going to have to do a little bit of yourself, but at the end of the day you're going to get this dedicated storage, dedicated part of D RAM and dedicated execution on single core and also going to get a measurement afterwards.  Then you can use other measurements that might already exist to kind of come up with a decision of whether you are running in a trusted environment on trusted machine or in trusted state then you can extend that decision further.  To maybe like remote service.  We'll keep going?
  SGX is this awesome sauce that's coming out.  But it will take that TXT, IOMMU concept push it into your user land apps.  They can do the same thing.
  They can set up their own Bastion of isolated then allow other services to make calls to that.
  We take that privilege domain we pull it out of of the ring zero and push it into like whatever ring we define.  It's very complicated, like concept.  But I hope that we can really start taking things 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 board.
  So, we'll make one aside here.  If you wanted to log every execution of a process on OSX, right?
  You could go into the kernel, write kernel extension, hook SYS, you use OSX the Mac policies or APIs.  Every time one of those are called you create a log right?
  Start up some ring buffer, push the ring buffer that becomes your log.  Start doing this about 5,000 times an hour for every process -- 5,000 times an hour that will be the processes he's that run per hour if you're using your machine hard core. where do you put that data?
  So, from the privilege domain you audited that requiring attacker to get into the kernel so bypass that, what do you do with that data?
  Can you from kernel land start pushing out to network service?
  What kind of like arrows do you need to define.  In almost every example you have to go back out of that privilege domain to write that data.  That makes a lot of sense, too.  If we're defining reliable services, I can't for every Exec TCP call or throw — EDP call 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, just -- it's not really a lot of fun.
  What we end up with something called like -- we start auditing to a file in the unprivileged world then we put like root access on there.  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 just take kernel extension away or module away to begin with.  What we really need and we'll go to the next slide is this concept of SGX where that blue circle I will is now become purple that is my little privileged mode existing outside of the traditional operating systems privilege land I can write directly from the privileged log of the payoff, this that can implement my compression and choose schedule which it pushes data off.  Now I get all the advantages of not crashing the kernel if I somehow implemented my compression or my scheduling wrong.  I still can log this from the privilege domain which is the operating system.  The little deep but just isolates -- or how you would use something like this isolated execution, right?
  >> Yeah.
  >> We're almost finished here.  Another thing we didn't get much time to talk about is this out of band systems which implement these isolated executions.  IPMI is kind of the equivalent of the trust zone, it's the specification to which ILO and Draq or AMT or Intel's management engine or secure engine, right?
  That is another mode outside that has special APIs to run into this privilege LAN.  They are in the form of accessing or making Dram calls or having access to some of the memory buses that are otherwise protected by the ISA.
  We go one more.  We'll go past this.  Failures and use cases.  Hit the play button there.
  >> It's worth it.  You'll dig it.
  >> Great.  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 now you have some unprivileged mode commanding what you thought was the privileged mode.  Dogs are the privileged, that's your kernel, they herd all the cats, right?
  They're the unprivileged people.  They're us.
  One more.  So the kind of uses of these, the things that we 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, figure out a way, there is a way, read a little bit more we'll keep secure boot on we'll get you --
  >> Something that we didn't mention I'm going to jump in real quick 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, Fidora   that will keep secure boot on and actually continue to boot with secure boot enabled.  It's performing all of these integrity checks that you want to have.  They have a little boot shin that still signed by Microsoft, still going through all the Microsoft Certs hijacking that process with their own boot strapping process.  Said that weird.  That's kind of more -- secure boot on is the functionality is there we're building it.  Help be part of the solution not the problem.
  >> Another really cool thing to look forward to which exists right now in Windows almost there in -- we got four minutes.  Right?
  We have until --
  >> We're going to cut it off for questions.
  >> Like four minutes.
  >> Until:45D 45.
  >> Yeah.  Testing these like mobile app containers right now isolation happens on mobile devices like it's awesome, right?
  There is mobile platform that isn't implementing some form much isolation.
  Now going to start seeing APIs for letting remote service make a decision for the user, right?
  It's scary at first when that decision becomes remote service saying, hey, we think you're phone booted a different firmware, different operating system would you like to continue, yes or no.  That kind of friction will end up for people who are running egg things like Cyaongen or booting different operating system.  They already understand that there is going to be couple of hiccups it should be the onerous of them to load like the certificate for that engine model.
  >> Relates back to rooting your phone or jail breaking your iPhone to run things as root, and remove the security protections that have been place there in the first place.  Not that there is anything wrong that you've made that conscious decision.  So having a server end kind of like give you the heads up say, wait a minute, something's different.  That would be a sweet feature even still just kind of skip right past it and do it at your discretion.
  >> 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.  That decision, hey, your phone booted in a different way, continue, yes or no.  Then like more info.  Then we can deduce that down into a better decision for them, probably don't know whether to hit yes or no.  So we can have a setting somewhere that says if my phone boots in a mode that isn't trusted, here is the default option, right?
  Then we can set that to please don't continue.
  >> It's really similar to like the SSL validation, right, you go to a website in chrome or somebody stops you says, wait a minute, this Cert is wrong we skip right past that, similar concept, right?
  Hopefully get to a point where there's enough to say, wait a minute, this is bad or you really sure that you want to go.  Kind of has hints that have to it.
  >> Cool.  I think next slide will kill it.
  >> Done, great.
  >> 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 a lot more to look forward to.  If this definitely got your interest, go look at these talks.  Or please hit us up afterwards, definitely love to talk to you.
  >> Thank you.
  >> Cool.  Questions?
  [Applause]