 Welcome to my presentation on measured boot and UEFI and thank you very much for coming and also I want to thank DEF CON. It's a great honor to be up here and this is a big crowd to be presenting to so that's pretty cool. My name is Dan Griffin. I'm the president of JW Secure. We're a Seattle based company that specializes in custom security software. So we've done a little bit of work in this space. Mostly what I'm talking about here is just kind of based on our experience on some recent projects that we've done for the past 12 to 18 months. Before we talk about measured boot and UEFI in terms of technical details, I hope you'll excuse me to go into a brief digression. I want to try to motivate these subjects with not quite a real world example but anyway what I thought was a cool one. Did everyone see James Bond Casino Royale, not the spoof from way back but the one with the newest James Bond with Daniel Craig that came out in about 2006? Yeah, he's hot. So and actually supposedly my wife just told me that he was in they did something with him in the Olympics opening ceremony. It's not a bad ass. I didn't get to catch it anyway. So if you didn't see Casino Royale or if you did a reminder the premise is that James Bond has to play a high stakes poker game to try to lure a financier of terrorism to the table. And so the idea is that if Bond can or I should say when Bond outwits the terrorist they'll be able to, you know MI6 will be able to bring in the terrorist and interrogate him for all the information he has about other terrorists. So here's the thing though. Before the game this guy on the right here in this picture, he's a Swiss banker. He shows up with this mobile banking kiosk. You can probably see where I'm going to go here. So you can kind of see, apologies I couldn't find a great picture of it without going through the movie and taking a screenshot which I didn't want to do. Anyway it's just this stainless steel thing that you can see. Surely it's just a laptop, you know. Anyway each player has to pick a pin code and they use that pin for securing their winnings if any. But what we subsequently learn is that James Bond uses his new girlfriend's name as his pin code. So does that bother anybody else in this room? So I can think of just a few concerns off the top of my head. Even just a few, and by the way the girlfriend's name is Vesper, V-E-S-P-E-R, okay? So not as bad a double entendre as like you know Pussy Galore or anything like that. But still fairly obvious, right? So even just a few socially engineered guesses on that pin, you're going to find it. And of course a brute force attack is going to find it trivially. Second, even if Bond had chosen a better pin, what if there had been a root kit on that mobile kiosk? Right, came over, right? And most of all, if Bond's account had been compromised before the end of the game, do for example the poor password policy enforcement? Or poor end point security enforcement by the bank? Do we really think he still would have gotten the girl? No chance. Now of course if you remember the movie you know that it didn't go down quite that simply. Turned it out the girl had some issues. I will remind you though that she's an accountant and so she surely would have cared. Anyway, obviously you know it's one of those things where it doesn't quite fit the plot for a real world security concern to come in. But that's the kind of thing that affects the rest of us, affects you and I. And it is very much a real world issue. So the question is, what can we do to improve end point security in scenarios such as mobile banking, not just for James Bond but for everybody? And with that in mind, UEFI is an important technology for protecting devices against root kits. Now there's some tradeoffs which I'll get to. And I also want to point out that the TPM chip can be used for protecting remote systems against compromised clients. So that kind of works the other end of the story and I'll talk in detail about that as well. So let's look at how these two technologies work. UEFI is the unified extensible firmware interface, kind of just rolls off the tongue. For the purpose of this discussion, UEFI is a programmable boot environment that is gradually replacing, let's call it just old school BIOS. TPM stands for the trusted platform module. It's a crypto processor typically implemented either as its own chip on the motherboard or as part of a secure execution environment and of course this is the direction that we're more commonly going now in system on a chip firmware. Secure boot is a feature of UEFI by which OEMs can control what boot images can be executed. Typically secure boot includes support both for whitelisting and blacklisting of code signing keys as well as of the boot binders themselves. So you can whitelist or blacklist a certificate or a public key and you can whitelist or blacklist, you know, the hash of the image itself, either one. On the other hand, measured boot is a boot loader and operating system feature and it uses the TPM to keep a record of early boot components as they load. Now a TPM chip isn't the only way that you can do something like measured boot. You could also implement something like this in UEFI. But for the purposes of what's available today and what's well supported in developer kits and stuff like that, I'm going to just kind of draw that distinction between what's being done with UEFI and what's being done with TPM. Remote attestation is another TPM based feature. It allows a boot log to be evaluated by a remote system and for trust and policy decisions to be made based on the contents of that log. So you've got kind of two client pieces and one remote piece. You've got secure boot, the boot loader checker thing in UEFI. You've got measured boot, which is the boot loader and boot binary thing in TPM. And then you've got remote attestation, which allows you to take that boot log from the TPM, ship it off to a remote system and for that remote system to be able to decide whether to trust it or not. Support for UEFI and TPM is spotty in legacy hardware. But it is growing particularly on the PC side. Support for these technologies in the mobile side, which I think you probably agree is probably the relevant conversation right now, is still pretty difficult to predict. Microsoft is pushing them, for example. Support for TPM in Windows 8 is, I believe it was publicly announced in, you know, the Windows 8 executive blog or whatever several months ago. I believe it's going to be standard. So that's good news if you're someone like me who works in this space and you want to be able to provide these services as an integrator to a lot of different companies and customers. But the jury is still out on whether software developers and startups in general can count on having these capabilities in the top to your mobile devices. And for that, I'm basically kind of lumping in a lot of different devices, you know, including like the tablets, you know, the new tablets coming out, the Windows side, as well as the Android side and of course the mobile phones. And the iPad. Nevertheless, given the bring your own device trend, the BYOD in enterprise IT, employers are pushing for new capabilities that allow them to protect corporate data while lowering hardware support costs. So I do believe that this stuff is very relevant. Complicating the fact is this whole consumerization trend is kind of throwing a whole wrench in the works about trying to do enterprise stuff on what is essentially designed to be consumer hardware. So that's kind of the gap that we're in right now. Microsoft has announced as part of their Windows 8 hardware certification requirement for the ARM platform that UAFI Secure Boot is required, that it cannot be disabled, and that all bootloaders must be signed by a certificate chain that they control with VeriSign. Are there any theories about why Microsoft has chosen to go that route? I actually don't know. I used to work at Microsoft several years ago. Really I kind of wanted to get you guys riled up a little bit. I could speculate a little bit, and I will. I think that Microsoft's gamble on the Windows 8 tablet, particularly on the ARM side, is kind of a long shot for them to break into the consumer space in that way. It's clearly a space that's dominated by some other players. Apple comes to mind. Microsoft is way out of their element in that space. And nevertheless it's something that the company really has to be successful in. And so should I be surprised that they're trying to lock down the hardware to control the experience as much as they can, to control the whole app store story and all this, you know, all the spaces that they're trying to play catch up in? No, I don't think we should be surprised. Furthermore, I think the Linux community and Microsoft are kind of like this old married couple that they can't live without each other, but they really don't like each other. And I think that that's kind of what we're seeing playing out right now. I think that if you're an integrator in this space, you're going to find that the UEFI boot lockdown really isn't much of an issue. It's something you're going to be able to work with and work around. If you're a kernel developer on the Linux side, it's going to be kind of a pain in the butt. But, you know, you can buy certificate and you can work around it. That's kind of my take on the situation right now. If you want to experiment with UEFI, check out the open source Tiana Core project sponsored by Intel. There are others. Actually, if you saw Jonathan's session before this, he gave several examples of UEFI and BIOS toolkits. Anyway, the Tiana Core guys have provided lots of helpful introductory documentation and it allows you to skip having to read hundreds of pages of UEFI standardization documents, which of course is very welcome. Microsoft has provided some documentation as well, particularly talking about the new Windows 8 hardware certification kit and that explains the new bootloader signing process. And I also want to point out that the major Linux distros have done a great job of coming forth, you know, with kind of their rationale about how they're planning to play in this new world order with OEMs, particularly on the arm side, having locked down bootloaders. You know, the Linux guys have really explained very clearly how they're going to provide distributions that work and how the community as a whole can still work within that framework. So it's an unfortunate speed bump that affects everyone, quite frankly. But nevertheless, you know, you can still play ball. So I've already alluded to this several times. The big drama about Windows 8 and UEFI secure boot is that Microsoft has stated that OEMs must configure secure boot as mandatory on ARM devices and that it cannot be disabled by users. Even on X86 platforms, UEFI secure boot is expected to be on by default. So a legitimate, another legitimate concern that's been voiced is that, okay, X86, we can still turn it off, but geez, have you ever tried to navigate the BIOS prompts on a typical laptop, for example? And that's assuming you can figure out the key to get to the BIOS, you know, at boot to get the BIOS in first place. I was trying to set up my HP laptop to do some UEFI demos. Honestly, God, I work in this space and it was very challenging. It's just a real pain. In fact, when I finally got Windows 8 booting on that machine in UEFI boot mode, the TPM wasn't even visible anymore because there was a conflict in the BIOS driver. So let's hope that the newer systems have this worked out both in terms of support for the devices, but also in terms of maybe some more user-friendly prompts at the BIOS level. Fingers crossed. As I pointed out, the major Linux distributions have announced that they'll be providing signed bootloaders. Unless you plan on doing custom kernel work, I think this is really going to be a non-issue. If you are going to be working in that space or if you do work in that space, you're going to have to evaluate these options that I've listed here. So switching gears. In review, UEFI secure boot allows you to control at the firmware level what bootloaders are allowed, but what if you want to make more nuanced policy decisions and extend them higher up the boot stack? So for UEFI, we're basically talking about the BIOS and we're talking about the bootloader and that's it. Even better, what if we want to make authorization decisions on a remote banking service to return to the James Bond example based on boot measurements made on the client? What level of trust can that service place in those measurements? Oops. There we go. With measured boot, starting at the BIOS, and by BIOS I mean UEFI or legacy, before each next component in the boot chain is loaded and executed, the previous component computes the hash of the next component on disk and stores that hash in the TPM. Data is stored in the TPM in these platform configuration registers or PCRs. So if you see on the left-hand side of the diagram there, starting with the BIOS, takes a hash of the bootloader, which in Windows is for example bootmanager.exe. So it hashes bootmanager.exe, I should say Windows 8 specifically, sorry, hashes bootmanager.exe sticks that hash in the TPM, then it hands off control to bootmanager.exe. Bootmanager.exe launches either win load if it's a clean boot or win resume if you're coming out of hibernate. And then those launch the kernel. Each one along the chain is storing the hash of the next. The kernel then does something a little bit special and fancy in Windows 8. Before it initializes the early boot drivers, it loads them into memory and then it initializes a special new anti-mower driver called eLAM, early load anti-mower, that basically is an opportunity for your anti-mower solution to have a hook very early in the boot process. It can look at the hashes of all those drivers that have been loaded but not executed yet and determine if it doesn't like any of them. And if it doesn't like any of them, it can either you know, break your machine, which probably aren't going to do, or it'll let you boot and then for example invalidate the trusted boot signature. And we would also hope that assuming it hasn't been totally owned, which if it's a bad driver, it probably has been, anyway hopefully provide some sort of notification to the user via the user mode component of the anti-mower solution that you know, they need to take some action, which unfortunately probably boils down to flashing the machine. But anyway, at least this is forward progress so to speak. After boot, and I'll go into a bit more detail about how that works. After boot, a boot log can be retrieved from the TPM. The log includes the boot image hashes. It includes code signing information. So you don't have to just trust and for example keep a white list of hashes. You can also for example track cert chains. So you can decide, okay, well I trust the Microsoft certificate chain. I trust the OEM certificate chains for the machines that we use, you know, the HP one, the Intel one, et cetera, et cetera, et cetera. At least it's a slightly smaller list than of course the hash of every possible early boot driver. And there are probably going to be thousands of them. And the log includes other boot metadata. I'll give some examples shortly. Importantly, the TPM can also sign the log with a special purpose attestation identity key or AIK. So then remote attestation builds on measured boot. Remote attestation works like this. The client device shown on the left hand side of the diagram here gets turned on and it runs through the TPM based measured boot procedure that I just described. Then some client application that wants to perform remote attestation retrieves the signed boot log from the TPM and sends it to the remote server for verification. The remote server verifies that it trusts the TPM key that signed the log, that the log hasn't been tampered with, in other words that the signature checks out with the hash of the log, and then it trusts each of the boot binaries in the log. So for example, it either whitelists those hashes or it checks the signer of each binary and makes sure that it trusts those signers. Then again, in taking a typical line of business scenario, the remote server sends back some sort of signed token. Then the client uses that signed token to, for example, in the mobile banking service, for example, the client would then send that token to the mobile banking server and then the server would make authorization decisions based on what's in that token. So the assessment could be low, medium, or high security or just yes it checked out or no it didn't check out. As a result of which you can or can't download the sensitive data, you can or can't make a funds transfer, etc. So obviously there's a fair amount of complexity here. And there's plenty of things that can go wrong and I'll talk about several of those things that towards the end of the talk. In the meantime, I think that some demonstrations about how this can be used in real applications will help make it a little bit more concrete. First, I'm releasing my new measure boot tool which allows you to view the trusted platform module boot data and identify risks such as, for example, unsigned early boot drivers. The tool implements basically the following. It establishes a new attestation key based on a simulated database of trusted TPMs using the endorsement key which is the permanent encryption key stored on the TPM. So when you get a new machine, you know, you go to Best Buy, you buy a new Sony laptop. That laptop, assuming it does have a TPM, it's one of the enterprise class laptops, it already has a key burned on to it. And with most but not all of the OEMs, that key also has a certificate associated with it. And so you can decide, well, we trust the Sony endorsement key certificate and therefore we trust that this is in fact a TPM based key. So again, measure boot tool kind of shows you how to do that within the Windows 8 API that supports this stuff. The tool then produces signed log using this new key and it will format the boot data for human consumption, basically dumps it out in XML. And then it flags certain risks just kind of as some examples of how to parse that XML. It flags risks such as unsigned early boot drivers. So I'm not sure how illegible that is on the big screen, but anyway this is some sample output from the measured boot tool. I ran it on that HP laptop I just mentioned with the Windows 8 release preview build. And there are several things to note in the output of the tool. First, there are two items at the beginning of the output extracted from the boot log metadata. Actually, I guess you probably can't see my pointer on the screen. Anyway, the first thing is that disk encryption is enabled with a hardware based key. That's important because, for example, you could make with high assurance decisions based on whether you should allow sensitive data to be released to this machine because it does or does not have an encrypted disk. I'll give a more concrete example of that in a moment. The second thing is that the latest boot integrity features in the boot loader have been enabled. This is really important if you want to use this scenario on Windows 8. You want to enable these new integrity features otherwise you basically don't get anything in the log. You just get the TPM stuff, which is pretty terse. The second thing to note is that there's a really long list of early boot drivers. Keep in mind this is not all of the kernel drivers that boot with my laptop. This is just the early boot drivers. There's like 50 of them. This is a significant attack surface. We'll get back to that. The final thing to note is that if you see, let's see, well unfortunately I can't see that far, but anyway about a third of the way down you see this wdboot.sys. It's marked with elam and it says signed. That's the built-in elam driver that Microsoft is providing. WD probably stands for Windows Defender. That's their free antivirus solution. So anyway, as the other antivirus vendors start to provide these drivers, here's an example of how you can look for those in the tool output and again perhaps make decisions on whether you trust that this machine is secure based on the fact that the antivirus solution is up to date. In introducing measured boot tool I mentioned that it creates a new trusted attestation key on the TPM before extracting and parsing the log. Creating the attestation key and establishing that the TPM is trusted is a foundation of remote attestation because without that the remote server can't trust that the boot data it receives from the client is secure. So that's part of the boot strapping. We have to make sure that we trust this key. It's a new key. It's bound to the TPM otherwise everything that happens thereafter is suspect. Measured Boot Tool demonstrates this kind of whole crypto song and dance feature that I'll show a diagram of in just a second. Basically it entails establishing remote trust and simulating the data exchange between a measured boot client and attestation server. So instead of having a real client server I just kind of do you know client call, server call, client call, server call in the code. So this diagram shows the client and server messages that are used in TPM remote attestation. In other words this is what the client device does in order to transmit a boot log to the attestation service in a trusted way. First the client requests an attestation knots. The sequence assumes that the server already has that database of TPM and door stamp keys or you've gone through the trouble of you know making sure that you know all of the OEM certificate chains. So you have the Sony chain you know the HP chain etc. That way you can determine that the endorsement key public that you're receiving from the client is trusted that you know that's actually a TPM base key and not just something that the client created in software. Next the client requests an encrypted challenge. This request includes some binding information from the TPM regarding the new AIK. What the client receives from the server is an AIK certificate sorry yes an AIK certificate with an encrypted signature. So again this is kind of some of the crypto voodoo where the endorsement key can only be used for decrypting another key. And so the way that the server is going to ensure that a this is a new attestation key and b that it actually is an attestation key bound to this TPM and not in software somewhere is it's going to encrypt the certificate for the attestation key this new certificate that the service is sending back. It's going to encrypt it so that only a TPM can decrypt it using its endorsement key. So in the next step when the server sees a request coming with that new certificate it knows that the client decrypted that certificate and therefore it knows that it used a TPM to do so. If the client doesn't come back with a valid certificate then you know can't play ball not secure. So finally the client requests an attestation knots this knots like the previous knots is used to ensure that it's a new attestation key this knots is used to ensure that the previous boot log isn't being replayed. Finally the client uses the agreed attestation key and the attestation knots to produce a signed boot log that is sent to the server for verification. So again there's some complexity here obviously including some cryptographic steps that are easy to get wrong in fact several that I did get wrong and I need to fix in the tool. Nevertheless remote attestation gives us a powerful tool to ensure that the compromised client devices can't access sensitive network resources. I should clarify the previous comment. What I got wrong in the tool is I don't actually show the step of encrypting the certificate. There's no like PKI part component of the pool of the tool right now. It just kind of the low level symmetric key crypto so there's some additional steps that you'd have to do to integrate this into an existing enterprise PKI I think is how it would typically be done. Okay so back to the mobile banking example again let's look at the current state of affairs for performing security checks on remote devices and identify where there's some gaps that we can start to fill in with these technologies. The question is how can we use technologies such as remote attestation to raise the security bar in the bring your own device scenarios. Doing it in a standards-based way without imposing too much of a burden on the user. In addition we also want to demonstrate that devices can be authenticated using hardware based trust in a way that is seamless to the user. Otherwise let's be honest nobody's going to use it in particular when we're in this kind of consumerization shift here. OEMs, hardware manufacturers, handset carriers are going to be super super sensitive about anything that you know scares off users and of course security bars have a reputation for scaring off users. So what we wanted to show in this demo is a way that you can really raise the security bar on a mobile device without any additional hurdle for the user so to speak. This demonstration starts with a mobile banking application. Unfortunately I couldn't get access to the kiosk from Casino Royale but at least this application is real. In this screen notice that the bank is able to present the user with promotional offers before there's been any sign-in experience. So again this is kind of talking about well what can we do to make security convenient in a sense. This is important because it actually helps to maximize revenue opportunities. So I think this is a way to kind of sneak some of this stuff in so to speak and make it palatable to the people that we're going to be dependent on to get these technologies into users hands. After the user clicks the sign-in button they're asked for the existing logon information for online checking. Since this is the first time the app has run we want to bind the device to the user. For this demo we assume that the bank already has the user's mobile phone number from the initial in-person proofing when the account was set up. What we'd like to be able to do is bind the device to a known TPM, specifically the endorsement key like I was just discussing, as shown in the remote attestation flow that you saw previously. Unfortunately few smartphones have TPMs. Still there's an opportunity here for OEMs to raise the bar. I think partially depending on for example how Windows 8 does with their tablets we could see that change sooner rather than later. If they don't do well it's going to be later. In order to bind the device to the user the bank sends a text message with a one-time pin. The user enters that pin along with their existing username and password. And again this is kind of for the one-time device setup. Now the user has read-only access to their checking account. The account balance information is visible. However in order to transfer money we want to do this additional security checking. Namely behind the scenes we're going to gather information about the device and send it to the back end, in this case in the form of SAML claims. We did this as a demo for RSA this year. So we kind of wanted to get as many you know standard security grab bag three-letter acronyms as we possibly could. In the version of the in this version of the demo the device firmware is out of date. Therefore the banking web service doesn't trust that the device is operating correctly on behalf of the user. So this risky transit transaction namely funds transfer is denied. And of course this is the part where the user does start to get a little bit frustrated. But again you know there's a trade-off to be made. Can the bank you know reduce fraud as a trade-off of you know affording a little bit of user annoyance. The challenge is though is that without the hardware root of trust provided by a technology such as TPM remote attestation the banking web service can't trust the client application, can't trust the operating system, can't trust the device itself that they're really acting on behalf of the user and haven't been compromised. So now I'm going to demonstrate a real line of business application with measured boot and remote attestation integrated. So this example deviates somewhat from mobile banking. Instead it shows a purchase order application. Basically a purchase order approval system. When the app launches in the background a boot log is being generated and signed using the hardware protected key stored on the client device. So it's doing TPM remote attestation in the background. The signed boot log is sent to a web service for verification. Device integrity information is then available to the purchase order web service in the form of again SAML claims. So in this scenario that I'm showing here in this screenshot boot log verification was successful. So the next step is to authenticate the user. This is again being done you know we're going for kind of this grab bag of standard security technologies here. We're using an X509 certificate with a private key protected by the same hardware chip that signs the boot log. So there's no separate credential to carry. It's kind of like a virtual smart card that's bound to the TPM on the device which I thought was actually kind of another cool technology to show off here. Device and user authentication both succeeded so purchase orders can now be submitted and approved. Okay so this is the good sequence. But now suppose that the user gets fired. We want to ensure that this device can't make another request to the web service until the device is reprovisioned for another user. Thus not only do we want to revoke the user credential when an employee is terminated for example we want to revoke the device itself. And we can do that because we have this database of endorsement keys. So for example in the SAP job that kills a user account that terminates a user sends their last check etc. It calls over to the other system where our endorsement key trust is maintained. And it says this endorsement key is no longer trusted. So the next time this machine regardless of who's logged on to it tries to connect to our service it's not going to be trusted. Rote attestation is going to fail. We're not going to trust the boot log. Similarly of course if a trusted key but a tampered uh you know a tampered with boot log showed up you know we wouldn't allow the authentication there either. And importantly of course the user would have to be given remediation instructions. Uh again remediation when you have a root kit installed has become a little bit of a tough one these days. Cause um yeah reflash the machine is one thing but now we're not even sure if that's going to do it. Anyway I don't have the answer to that one yet. So recall that I just mentioned that the measured boot log includes additional boot metadata beyond just the list of early boot drivers. Want to give an example of how you can use some of that other metadata. A third scenario that really motivates then the use of remote attestation is access to corporate and government data by trusted insiders. In this case we want to ensure that only users with trusted client machines and encrypted disks can download sensitive files from the document repository. Sharepoint. By enforcing disk encryption and hardware identity we help decrease the chance that data can be recovered from a lost or stolen device. So again I think that this is a classic uh you know bring your own device scenario where you know your executive goes and buys a new iPad or Vio or whatever at Best Buy. And uh he or she's traveling right now so she you know she can't go into the office for provisioning and she needs access to the Sharepoint. So we can do all this bootstrapping based on a priori knowledge um you know again of the of the Sony signing key or of the Apple signing key. And um you know we can get her up and running. From the boot log we receive from that device we ensure that when she downloads um you know the financial predictions for next quarter or you know whatever sensitive data and then she leaves that brand new machine in the back of the taxi cause she's in a hurry she gets out that we know with high assurance that that machine had hardware protected disk encryption enabled. And so at least we are reasonably certain that without cracking the disk the disk encryption that document is protected even though the device has been lost. And again we can do that without that user even having to come into the office. So that's why I think that some of these technologies are really compelling if we can get them integrated in a kind of user friendly way. Okay so let's talk about the weaknesses. TPM measured boot and UEFI secure boot are important endpoint security technologies but there are weaknesses. I've already alluded to several of them. Still at a high level I think that there are two important things to keep in mind that kind of summarize the rest of the weaknesses so to speak. First we're still generally assuming that the user is an ally. For example that the user won't go out of his or her way to physically compromise the device. Your body like mine may be like rejecting that concept that we still have to trust that the user doesn't want to compromise the device. Unfortunately if you saw Jonathan's talk before mine he made it fairly clear why we still have to trust the user not to compromise the device. Because for example the user could cut the chip off of one device and wire it on to another one. And you know what does that mean now? It's still a trusted TPM but it's not the same computer. Do we care? I don't know. Secondly as I've demonstrated there's complexity here and in software increased complexity means increased bugs. That's just the way it is. So with these two things in mind this slide lists some other specific weaknesses to be aware of. First the UEFI on the UEFI side the toolkits are evolving rapidly. Lots of changes being made to the sample code for example in Tiena core. Again you know just from somebody who's done software for a long time you just kind of become nervous when you see a lot of changes that just generally means bugs so you just got to be careful. No different on the TPM side you know there's plenty of complexity and risk there as well. I talked about the risk on the TPM side of initial bootstrapping and provisioning unless you can for example get a database of known TPM keys of known endorsement keys from every OEM whose hardware you're going to support then you have this problem of determining upfront the first time you see that device do we trust that it's a real TPM that we're talking to. What we've actually done for a recent project since we haven't been able to count on the OEMs for on all of the OEMs to support that is for example in deployment where you've got a higher value user credential already deployed like for example you know OTP fob or a smart card you kind of have this moment of trust transaction where the user signs the device into the system for the first time and you say okay Mr. User under penalty of a slap on the wrist you know does this machine still seems secure to you and I admit that that is totally weak but again it's just kind of until we can get to the point of having a trust chain from all the OEMs we're kind of just kind of doing the best we can. Integrity of the TPM hardware I mentioned that of course you can there's no way to know that the user doesn't have a TPM for example instead of attached to the motherboard that is just hanging off you know the USB port or that it wasn't cut from some of the devices soldered into this one we just can't know that. Kind of a big one that that I didn't realize until I'd been working with this technology for a while is that the hibernate file is unprotected so to clarify that measured boot only happens when the device is doing a clean boot. Keep in mind that when you're doing a hibernate you're basically the kernel is basically taking this whole image of memory of all the drivers and it's just copying on a disk and when you do a resume just copies that whole memory image that whole image back into memory and then presses the big green go button so it doesn't reinitialize the drivers. Drivers can be notified of a hibernate but it's not the same as being reloaded and re-initialized because they're already loaded. So what that means is that if you have a malicious admin on the other side the admin could for example inject drivers into the hibernate file or it could modify images in the hibernate file. The only way to protect against that is A trust the user and B we would recommend of course using disk encryption because again disk encryption at least prevents the hibernate file from being modified offline. Let's say it reduces the chance. The other thing I wanted to mention two more weaknesses I wanted to mention. There's a trend of migration from hardware to firmware. I mentioned at the beginning the system on a chip approach that basically most of the tablets are using. I can't necessarily say that it's more secure to have a TPM and a separate chip than it is to have it integrated as a secure execution environment with everything else going on in a single chip. My gut reaction is that it raises a few concerns that you know that code would be accessible from other less trusted code running in that same environment. Again just something to think about. And the final item is that you still have the inevitable zero day patching delay and you know the whitelist maintenance even if you're going the route of you know just checking the certificate chains for each of the binaries. You know in a remote attestation scenario. You still have this issue of well you could have a signed binary out there that hasn't been revoked yet. You know because somebody just said this system doesn't take away that zero day risk. Looking forward from my perspective as a security software integrator there are two questions. First Windows 8 has excellent developer support for the technologies we've been discussing. And you see similar in you know SDKs for on the link side as well. But I'm particularly interested in you know will the Microsoft tablet strategy be successful because I think it's a bell weather for whether a lot of these technologies will be adoptable. And second will similar features become more widely supported on the top smartphones and tablets. Either way as I've demonstrated capabilities such as measured boot are already present in most enterprise class PCs. So my recommendation is don't be like James Bond. Protect the endpoint, choose a strong password and get the girl. I think I do have time for questions. Yeah I have five minutes for questions so I'm happy to if you don't mind voicing them out loud in front of the whole world I can take them now. Joan in the green shirt I think. Yeah so planned obsolescence about mobile devices in the in the firmware version check that we had in that in that mobile that mobile application. Yeah and in fact I particularly sensitive that because I'm the kind of person who uses a thick case when I buy a phone and so my phones last forever. And yeah this is clearly something where there could be a disconnect I think I'm getting at your point there could be a disconnect between the phone and the phone. Yeah so the phone has their own life cycle. The producer of that application which probably isn't the bank and has their own life cycle and the carriers and the operating system manufacturer none of those four entities are whatever are going to be on the same timeline. Yeah I don't have a good a good answer for that. I think that there definitely would be some issues there. In the front please. Yes thank you for being used. When you're doing remote attestation you're using the attestation identity key to sign the boot log. Typically you'll be using the endorsement key to establish a new attestation identity key every time you do that. Thank you. Right here? Yes yeah thank you. So question about denial of service so I think that there are a couple of issues to consider there I think it's a great point in general to use kind of the enterprise scenarios most enterprise systems are not robust against denial of service so that's pretty much the answer to your question there I just want to point out attestation is something that we're proposing would be layered on top of an existing authentication solution an authorization solution so you wouldn't be preventing the machine from booting and you wouldn't be preventing the user from say opening up their browser and going to google what you would be preventing is in the current flow where the user tries to log on that we're going to be doing before we let them log on to their SharePoint server so you could DOS SharePoint you could DOS whatever our logon solution is and yeah now you could DOS the attestation server as well that's absolutely true yep please yeah yeah great question question about and I should have mentioned I should have referenced this question about ARM trust zone being adopted as kind of the mobile right now the direction seems to point to arm trust zone for for you know my company does about 90 percent of our work on windows if that wasn't already obvious we have some important revenue that comes from interop between windows and linux though which is why I'd like to see a variety of devices and solutions be available it's inconvenient if you have to do the same thing twice to get it to working on arm trust zone is equivalent to TPM in terms of the capabilities I've just been describing thank you okay great thanks a lot guys