1 00:00:00,000 --> 00:00:02,999 DAN GRIFFIN: Thank you very much, everyone for coming. 2 00:00:05,459 --> 00:00:08,375 This is a nice, big crowd. 3 00:00:08,459 --> 00:00:10,876 So I'm really grateful for this opportunity. 4 00:00:11,042 --> 00:00:13,042 This presentation is on protecting data 5 00:00:13,042 --> 00:00:17,125 with short lived encryption keys and hardware root of trust. 6 00:00:17,501 --> 00:00:19,459 My name is Dan Griffin. 7 00:00:19,459 --> 00:00:21,250 I am the president of JW secure. 8 00:00:21,292 --> 00:00:26,501 We're a Seattle based company that specializes in software development. 9 00:00:36,334 --> 00:00:38,999 Today a white paper is discussing secure time 10 00:00:38,999 --> 00:00:40,999 and mobile computing. 11 00:00:41,876 --> 00:00:45,792 The tool in white paper are linked in blog posts we put 12 00:00:45,792 --> 00:00:49,999 out this morning and my blog is on this slide. 13 00:00:50,959 --> 00:00:54,083 We will talk about the context of this work 14 00:00:54,083 --> 00:00:57,542 of why we need data protection. 15 00:00:58,209 --> 00:01:01,083 What are the foundations for achieving it and how it can 16 00:01:01,083 --> 00:01:02,918 be undermine. 17 00:01:05,999 --> 00:01:09,542 General Alexander, the has of the security agency was 18 00:01:09,542 --> 00:01:13,667 at DEF CON last year to give a recruiting talk. 19 00:01:13,751 --> 00:01:14,999 Did everyone go to that? 20 00:01:16,417 --> 00:01:18,459 Did everyone sign up? 21 00:01:20,125 --> 00:01:22,542 Are there any feds in the room right now? 22 00:01:24,209 --> 00:01:26,125 I actually don't see any hands. 23 00:01:27,083 --> 00:01:30,542 I guess general Alexander's message was a little too controversial 24 00:01:30,542 --> 00:01:33,584 for DEF CON, which is saying something. 25 00:01:33,999 --> 00:01:36,792 Another more open and accepting venues, 26 00:01:36,792 --> 00:01:39,667 the NSA has discussed being more proactive 27 00:01:39,667 --> 00:01:42,751 about secure mobile computing. 28 00:01:43,250 --> 00:01:46,083 Does that strike anybody else as being hypocritical? 29 00:01:46,792 --> 00:01:48,459 All right. 30 00:01:49,083 --> 00:01:53,542 But the big take away for the rest of us is that the NSA is working 31 00:01:53,542 --> 00:01:56,083 on mechanisms for trusting their content 32 00:01:56,083 --> 00:01:59,334 from the Cloud to mobile devices. 33 00:01:59,334 --> 00:02:00,626 They stated as much. 34 00:02:01,250 --> 00:02:04,999 So there must be ways that the rest of us can do the same thing. 35 00:02:07,584 --> 00:02:10,999 Let's review the checkered history of mobile devices. 36 00:02:11,876 --> 00:02:16,083 When laptop computers first appeared, they were awkward and obviously 37 00:02:16,083 --> 00:02:18,417 from the early '80s. 38 00:02:20,083 --> 00:02:24,501 Early PDAs were also awkward, but the trio was kind of cute. 39 00:02:26,292 --> 00:02:28,542 Now half the people sitting at Starbucks has 40 00:02:28,542 --> 00:02:31,501 a laptop and everyone has a Smartphone. 41 00:02:33,209 --> 00:02:36,667 Now that we can work and play in the digital world anywhere 42 00:02:36,667 --> 00:02:39,125 at any time, we actually do. 43 00:02:39,792 --> 00:02:45,999 But as work moves to less computing areas, hackers 44 00:02:45,999 --> 00:02:51,834 and spies are just like everyone else. 45 00:02:52,125 --> 00:02:55,292 They look for the maximum return for the minimum investment. 46 00:02:55,999 --> 00:02:58,834 So their focus is now on mobile devices. 47 00:02:58,999 --> 00:03:00,999 What can be done about this? 48 00:03:02,999 --> 00:03:06,709 The first thing we want to do is define some characteristics 49 00:03:06,709 --> 00:03:10,167 of a trustworthy machine, but if there's one thing we learn 50 00:03:10,167 --> 00:03:14,083 from department terminator 1 and 2 is that machines are sometimes 51 00:03:14,083 --> 00:03:16,999 trustworthy and sometimes not. 52 00:03:19,167 --> 00:03:22,501 Likewise, people talk about identifying the person 53 00:03:22,501 --> 00:03:26,792 in an internet transaction, but it's not a person. 54 00:03:27,292 --> 00:03:30,584 It's a machine and it may or may not be properly expressing 55 00:03:30,584 --> 00:03:32,834 the user's intentions. 56 00:03:34,667 --> 00:03:36,876 Give everyone all of that, how can we be sure that 57 00:03:36,876 --> 00:03:39,375 a remote party is telling the truth? 58 00:03:42,083 --> 00:03:47,459 Desktop PCs and laptops can be configured to be secure. 59 00:03:47,834 --> 00:03:50,167 And users can be trained. 60 00:03:50,999 --> 00:03:54,334 Some of this applies to phone and tablets and some of it doesn't. 61 00:03:54,834 --> 00:03:58,584 It is hard enough to encode password policy when users 62 00:03:58,584 --> 00:04:01,209 have full size keywords. 63 00:04:03,501 --> 00:04:06,918 The keyboard experience is built around auto complete and 64 00:04:06,918 --> 00:04:10,125 is not consistent around aps and devices. 65 00:04:11,999 --> 00:04:16,999 Many mobile platforms still lack the system level extensibility required 66 00:04:16,999 --> 00:04:20,918 by the good third party anti virus systems. 67 00:04:23,999 --> 00:04:27,292 Still mobile devices have lots of untapped functionality that can be 68 00:04:27,292 --> 00:04:29,792 used for increasing security. 69 00:04:29,999 --> 00:04:31,918 So let's see how to use it. 70 00:04:36,334 --> 00:04:39,959 Relatively low root kit risk is perhaps the only aspect 71 00:04:39,959 --> 00:04:44,626 of the phone that is still more secure than the typical PC. 72 00:04:44,626 --> 00:04:49,999 The application level attacks have become much more prevalent. 73 00:04:50,667 --> 00:04:54,501 About a mobile app or game costs 99 cents or less, 74 00:04:54,501 --> 00:05:00,999 you can bet zero attention has been paid to security and that's a chain. 75 00:05:01,292 --> 00:05:02,751 You get what you pay for. 76 00:05:03,999 --> 00:05:08,125 On a mobile, there's risk from geo location to remote theft 77 00:05:08,125 --> 00:05:11,501 of data, remote theft of service. 78 00:05:17,876 --> 00:05:22,459 In short, it remains difficult to get the device do reliably report 79 00:05:22,459 --> 00:05:25,209 on its current state that. 80 00:05:25,209 --> 00:05:27,083 Presents a risk both do back end services and 81 00:05:27,083 --> 00:05:29,125 to sensitive data. 82 00:05:30,209 --> 00:05:33,751 To get reliable information from the device, we need to get 83 00:05:33,751 --> 00:05:38,209 an authenticated report from a tamper resistant root of trust. 84 00:05:38,292 --> 00:05:41,709 This is the purpose of the trusted module or TPM. 85 00:05:42,876 --> 00:05:47,709 It's a crypto processor implemented a tamper resistant chip 86 00:05:47,709 --> 00:05:52,083 on a mother board or as a secure execution environment 87 00:05:52,083 --> 00:05:55,667 in system on a chip firm ware. 88 00:05:55,959 --> 00:05:57,459 The latter is becoming the norm. 89 00:05:59,918 --> 00:06:02,999 Guys intake gritty is the point of the exercise, 90 00:06:02,999 --> 00:06:06,375 but how can that help protect the user and custodian 91 00:06:06,375 --> 00:06:08,999 of the data care about? 92 00:06:09,999 --> 00:06:12,542 First we want to measure that the device is running 93 00:06:12,542 --> 00:06:16,959 the way that it's supposed to be running is the first consideration. 94 00:06:16,959 --> 00:06:20,792 The second consideration is that we want to insure that only 95 00:06:20,792 --> 00:06:25,542 on a compliant device can I decrypt sensitive data and only while 96 00:06:25,542 --> 00:06:28,709 the device remains compliant. 97 00:06:29,959 --> 00:06:34,542 By issuing encrypted content bound to a specific TPM and 98 00:06:34,542 --> 00:06:39,501 to a specific state of that device as reflected in the TPM, 99 00:06:39,501 --> 00:06:44,999 we can really lock down the lifetime of that content. 100 00:07:09,999 --> 00:07:12,999 I'm not going to go into as much detail this time. 101 00:07:16,667 --> 00:07:21,542 There is probably what this means is that determining the half 102 00:07:21,542 --> 00:07:27,083 of the mobile user device requires some infrastructure and it requires 103 00:07:27,083 --> 00:07:31,918 a little cryptographic dance that's achievable. 104 00:07:32,667 --> 00:07:35,459 Nonetheless, I am not suggesting the techniques be applied 105 00:07:35,459 --> 00:07:37,999 to every internet transaction. 106 00:07:37,999 --> 00:07:40,083 They're too heavyweight for that. 107 00:07:40,375 --> 00:07:44,584 But for securing high value data on consumer class devices that are 108 00:07:44,584 --> 00:07:47,375 sometimes disconnected, this is currently 109 00:07:47,375 --> 00:07:50,334 the best foundation we have. 110 00:07:50,375 --> 00:07:51,834 So let's dig in. 111 00:07:53,250 --> 00:07:58,209 With measure boot starting with the bios before each component 112 00:07:58,209 --> 00:08:03,459 in the boot chain is loaded, the previous component computes it's 113 00:08:03,459 --> 00:08:07,999 hash and sticks it in the registers or PCRs. 114 00:08:09,375 --> 00:08:11,999 After boot, a boot log can be retrieved 115 00:08:11,999 --> 00:08:13,792 from the PTM. 116 00:08:14,083 --> 00:08:15,751 The log includes the boot image hashes that I just 117 00:08:15,751 --> 00:08:17,167 talked about. 118 00:08:17,751 --> 00:08:22,584 It also has code signing information as in who signed the binary. 119 00:08:23,334 --> 00:08:27,542 And also includes other boot metadata that is disk encryption. 120 00:08:27,876 --> 00:08:34,542 The TPM can sign that boot log with a special purpose key that you can 121 00:08:34,542 --> 00:08:38,918 down stream if you trust or not. 122 00:08:39,083 --> 00:08:43,999 The server can then issue content decryption or authorization keys bound 123 00:08:43,999 --> 00:08:46,501 to those measurements. 124 00:08:52,250 --> 00:08:56,959 The server encrypts the key to the endorsement key and it 125 00:08:56,959 --> 00:08:59,667 is unique to each TPM. 126 00:08:59,751 --> 00:09:03,751 So when the device state changes, the measurements change and 127 00:09:03,751 --> 00:09:07,459 the TPM will refuse to use that key after. 128 00:09:07,501 --> 00:09:10,083 We have a pretty powerful mechanism here. 129 00:09:10,250 --> 00:09:11,999 Let's see how to wire it together. 130 00:09:15,626 --> 00:09:20,667 Trust starts with a TPM and the key distributed with it. 131 00:09:20,792 --> 00:09:25,667 This key is set by the manufacturer or the OEM along with a PKI certificate 132 00:09:25,667 --> 00:09:30,209 signed by that manufacturer and it's a short list. 133 00:09:30,626 --> 00:09:32,584 If you keep that set of issuing certificates, 134 00:09:32,584 --> 00:09:37,250 you can determine across a variety of things whether you trust that. 135 00:09:39,999 --> 00:09:46,626 The TPM is as protected as any hardware or firmware can be. 136 00:09:47,167 --> 00:09:53,125 Electron microscopes are a problem as is an insecure supply chain. 137 00:09:54,501 --> 00:09:58,334 Importantly, TPM2.0 includes a secure monetizing 138 00:09:58,334 --> 00:10:00,959 increasing counter. 139 00:10:02,042 --> 00:10:04,876 This at least is a more secure option than 140 00:10:04,876 --> 00:10:07,125 the standard PC block is when it comes 141 00:10:07,125 --> 00:10:11,042 to enforcing policies that are time sensitive. 142 00:10:11,125 --> 00:10:14,292 For example, they need to start now and end at a certain time. 143 00:10:14,292 --> 00:10:16,626 They have a limited window that can only be run 144 00:10:16,626 --> 00:10:20,292 once, various combinations of those things. 145 00:10:20,626 --> 00:10:24,209 This counter is the foundation of our work on short lived keys. 146 00:10:27,999 --> 00:10:31,125 Once the client guys has received a measurement bound key 147 00:10:31,125 --> 00:10:34,876 from a remote service, how can we use that key? 148 00:10:35,751 --> 00:10:41,751 Well, consider that constant reauthorization is expensive 149 00:10:41,751 --> 00:10:46,834 and that users hate it, Curborrows has been able 150 00:10:46,834 --> 00:10:53,999 to mitigate some of the burden of reauthorization that way. 151 00:10:54,999 --> 00:10:59,167 The point is that validity period is a policy setting that can be 152 00:10:59,167 --> 00:11:01,125 ratcheted down. 153 00:11:06,125 --> 00:11:09,876 Why not use the same technique to protect mobile data? 154 00:11:13,209 --> 00:11:17,375 So again, for Gory detail of how to implement a data loss prevention 155 00:11:17,375 --> 00:11:20,999 or digital rights solution, using measurement bound keys, 156 00:11:20,999 --> 00:11:23,167 please see the white paper I mentioned 157 00:11:23,167 --> 00:11:25,999 in the beginning of this talk. 158 00:11:30,083 --> 00:11:32,667 To run your TPM through its paces, please check 159 00:11:32,667 --> 00:11:36,417 is out the timed key tool that I mentioned as well. 160 00:11:37,083 --> 00:11:42,667 I warn you that the prerequisite for running that tool are relatively steep 161 00:11:42,667 --> 00:11:47,751 because unless you have a system on a chip based windows 8 tablet ore 162 00:11:47,751 --> 00:11:52,292 laptop from the past couple of months, you probably do not have 163 00:11:52,292 --> 00:11:55,999 a TPM 2.0 system, which is probably a little lame, 164 00:11:55,999 --> 00:11:58,250 but bear with me. 165 00:11:59,083 --> 00:12:04,209 This is a typical concern if you are building solutions on that 166 00:12:04,209 --> 00:12:06,918 like my company is. 167 00:12:06,918 --> 00:12:09,083 We believe it will make sense in the near term. 168 00:12:09,542 --> 00:12:12,083 Especially for small high value deployments. 169 00:12:13,292 --> 00:12:16,292 Also, if you're serious about developing custom TPM middle 170 00:12:16,292 --> 00:12:19,083 ware, you will want to join the trusted computing group 171 00:12:19,083 --> 00:12:21,959 as specifically the TPM sub group. 172 00:12:24,250 --> 00:12:28,083 Because that's how you can download their full TPM simulator 173 00:12:28,083 --> 00:12:30,626 reference implantation. 174 00:12:30,999 --> 00:12:32,876 That will save you months. 175 00:12:34,083 --> 00:12:36,167 But as an additional warning, the ability 176 00:12:36,167 --> 00:12:38,626 to down load that requires a premium membership 177 00:12:38,626 --> 00:12:41,999 because they know the value they are giving you. 178 00:12:42,250 --> 00:12:43,334 So you won't. 179 00:12:43,876 --> 00:12:46,999 Do that as an individual unless you are a dot com. 180 00:12:50,999 --> 00:12:54,999 My blog provides a trace of providing a demo using this tool. 181 00:12:55,501 --> 00:13:02,751 They are verbose to allow you to infer the TPM command sequence. 182 00:13:03,125 --> 00:13:05,999 In summary, you can use the first three commands listed 183 00:13:05,999 --> 00:13:09,125 on the slide to do the following sequence. 184 00:13:09,209 --> 00:13:10,918 You can do other things as well. 185 00:13:10,999 --> 00:13:12,459 There are a variety of commands, but let me run 186 00:13:12,459 --> 00:13:15,209 through what we consider the default case. 187 00:13:15,999 --> 00:13:20,751 First use the tool to create a 2048 bit RSA key and you have 188 00:13:20,751 --> 00:13:24,876 the lifetime of that key to 60 seconds. 189 00:13:26,125 --> 00:13:30,999 Note that another major improvement in TPM2.0 is a limit curve 190 00:13:30,999 --> 00:13:33,999 and symmetric cryptography. 191 00:13:34,375 --> 00:13:38,292 So that raises interesting scenarios using smaller keys, but also 192 00:13:38,292 --> 00:13:40,999 in doing data streaming. 193 00:13:43,999 --> 00:13:46,292 But there's some opportunities there. 194 00:13:47,125 --> 00:13:51,999 Anyway, TPM only supports RSA and TPM does not support 195 00:13:51,999 --> 00:13:54,792 the time bound keys. 196 00:13:55,125 --> 00:13:57,751 This tool is not going to run on a 2.1 device. 197 00:14:00,834 --> 00:14:04,626 The next step then is running the tool to encrypt sample data. 198 00:14:05,918 --> 00:14:08,459 Third, still within that 60 second window, 199 00:14:08,459 --> 00:14:10,459 decrypting data. 200 00:14:11,792 --> 00:14:14,999 Finally, after 60 seconds, do the decryption again and you'll get 201 00:14:14,999 --> 00:14:18,626 the expected failure saying your key is out of policy. 202 00:14:26,959 --> 00:14:30,375 With these capabilities in mind, again, how can we use measurement bound 203 00:14:30,375 --> 00:14:33,709 keys to protect mobile data in the real world? 204 00:14:33,999 --> 00:14:36,999 Consider data access by trusted insiders. 205 00:14:37,542 --> 00:14:40,918 In this casing, we want to insure that only users 206 00:14:40,918 --> 00:14:44,999 with trusted client machines and incremented disks can download 207 00:14:44,999 --> 00:14:51,167 sensitive files first document repository say such as share point or dox.com. 208 00:14:55,999 --> 00:15:00,542 By using platform, hardware identify and we decrease 209 00:15:00,542 --> 00:15:06,209 the chance that the data can be decreased and stolen. 210 00:15:11,375 --> 00:15:22,626 But before you deploy such a system, you should understand what can 211 00:15:22,626 --> 00:15:25,083 go wrong. 212 00:15:28,209 --> 00:15:34,626 Bio integrity or BIM model to protect computers from root kits. 213 00:15:35,626 --> 00:15:40,999 BIM boils down to measure boot, plus TPM testation. 214 00:15:42,999 --> 00:15:44,375 BIM is the model for everything we have just 215 00:15:44,375 --> 00:15:45,999 been discussing. 216 00:15:47,083 --> 00:15:49,999 Based on, this my company implemented 217 00:15:49,999 --> 00:15:54,417 a solution called BHT or bias integrity measurements tool 218 00:15:54,417 --> 00:15:57,334 for fast track last year. 219 00:15:58,083 --> 00:16:02,709 We included this data flow diagram along with that model. 220 00:16:03,834 --> 00:16:07,375 We like it for shock and awe purposes. 221 00:16:17,083 --> 00:16:18,876 We have the user. 222 00:16:19,209 --> 00:16:23,999 To the right, we have a TPM root of trust produced by the manufacturer. 223 00:16:25,999 --> 00:16:28,501 So insecure, more secure. 224 00:16:29,584 --> 00:16:32,876 Note it is only the two rings on the right. 225 00:16:33,209 --> 00:16:35,542 The TPM and the supply chain that were there 226 00:16:35,542 --> 00:16:38,999 with the trustworthiness of the device. 227 00:16:40,626 --> 00:16:43,501 Your remote solution, your middle ware has been 228 00:16:43,501 --> 00:16:48,959 implemented correctly which ask be a big or small assumption depending. 229 00:16:50,999 --> 00:16:53,751 Given that assumption, two other questions arise. 230 00:16:54,209 --> 00:16:57,083 First, you can trust your supply chain and two, 231 00:16:57,083 --> 00:17:02,876 are your adverse easier sufficiently well funded to attack the TPM directly? 232 00:17:06,667 --> 00:17:10,834 We believe that properly engineered middleware can significantly narrow 233 00:17:10,834 --> 00:17:13,209 the window attack on mobile data, but there 234 00:17:13,209 --> 00:17:17,834 is nothing that middle ware can do if your chip set its own. 235 00:17:18,999 --> 00:17:23,999 In order for users to be able to interact within the policy window, 236 00:17:23,999 --> 00:17:27,584 there is necessarily an increased risks of attack 237 00:17:27,584 --> 00:17:29,876 during that time. 238 00:17:31,667 --> 00:17:34,459 In any case, remember that the goal is to prevent the device 239 00:17:34,459 --> 00:17:36,999 from lying about its integrity. 240 00:17:41,834 --> 00:17:48,209 TPM1.2 is widely available on PCs, but to date, not widely used. 241 00:17:48,918 --> 00:17:53,083 The user experience around initialization and provisioning 242 00:17:53,083 --> 00:17:55,083 is quite poor. 243 00:17:56,083 --> 00:17:59,584 And this ask necessitate short cuts about you're trying to deploy 244 00:17:59,584 --> 00:18:01,584 a solution based on these capabilities 245 00:18:01,584 --> 00:18:04,125 in a hetero genius environment. 246 00:18:08,626 --> 00:18:11,959 This problem is solved on the latest hardware. 247 00:18:12,459 --> 00:18:16,834 So hopefully adoption of TPM2.0 will continue to increase. 248 00:18:19,999 --> 00:18:23,209 As I mentioned a couple times, we recommend that measured boot be 249 00:18:23,209 --> 00:18:25,999 used to enforce disk encryption if possibility as part 250 00:18:25,999 --> 00:18:28,167 of data loss prevention. 251 00:18:28,709 --> 00:18:35,501 But in windows, that implies you will be using their bit locker feature. 252 00:18:36,792 --> 00:18:40,250 Bit locker has been the subject of many numbered published attacks. 253 00:18:41,876 --> 00:18:46,167 When properly configured, we think it is good protection. 254 00:18:47,999 --> 00:18:50,709 Note that for other PMM based encryption 255 00:18:50,709 --> 00:18:53,999 solutions such as those you might implement using 256 00:18:53,999 --> 00:18:58,209 this measurement based keys capability, many of the same types 257 00:18:58,209 --> 00:19:00,751 of attacks may apply. 258 00:19:01,834 --> 00:19:04,667 So you need to do your research and do what you can 259 00:19:04,667 --> 00:19:07,626 to prevent exposure and reduce exposure of your keys 260 00:19:07,626 --> 00:19:09,417 in main memory. 261 00:19:10,667 --> 00:19:12,834 This goes back to the streaming opportunity I talked 262 00:19:12,834 --> 00:19:14,250 about before. 263 00:19:14,501 --> 00:19:17,417 That can be a really compelling way to mitigate the exposure of keys 264 00:19:17,417 --> 00:19:19,125 in main memory. 265 00:19:25,083 --> 00:19:29,542 You can decrypt HD content fast enough on a TPM? 266 00:19:29,876 --> 00:19:31,125 I don't know. 267 00:19:31,125 --> 00:19:33,792 When somebody figures out, it will be cool. 268 00:19:36,626 --> 00:19:38,125 Looking forward from my perspective 269 00:19:38,125 --> 00:19:42,334 as a security software integrator, there are three points to consider. 270 00:19:43,542 --> 00:19:47,667 Intel has excellent developer support for technologies we have been 271 00:19:47,667 --> 00:19:51,417 discussing particularly on that atom chip set. 272 00:19:52,999 --> 00:19:58,876 But with the mobile platform strategy for atom be successful, 273 00:19:58,876 --> 00:20:01,667 ARM has been slower to embrace 274 00:20:01,667 --> 00:20:05,000 because no consumer cares. 275 00:20:06,334 --> 00:20:10,834 But if Intel makes TPM a differentiator, will ARM respond? 276 00:20:11,501 --> 00:20:12,999 I hope they would. 277 00:20:14,209 --> 00:20:18,083 Finally, can software companies successfully integrate 278 00:20:18,083 --> 00:20:22,209 the capabilities in a way that is both secure and usable, 279 00:20:22,209 --> 00:20:25,959 with that being the usual trade off? 280 00:20:25,959 --> 00:20:28,751 Anyway, as a demonstrated, short lived keys are a great tool 281 00:20:28,751 --> 00:20:31,417 for mobile data protection. 282 00:20:31,999 --> 00:20:34,999 And 2.0 is increasing. 283 00:20:36,876 --> 00:20:41,083 So learn to trust machines, if only for short periods of time. 284 00:20:45,999 --> 00:20:47,250 Thanks. 285 00:20:51,999 --> 00:20:54,667 [APPLAUSE] 286 00:20:54,667 --> 00:21:09,709 I left tons of time for questions, if anybody has any. 287 00:21:09,709 --> 00:21:09,709 288 00:21:09,709 --> 00:21:10,083 [INAUDIBLE] 289 00:21:10,083 --> 00:21:14,375 DAN GRIFFIN: I mentioned a prerequisite that our current demo 290 00:21:14,375 --> 00:21:19,083 tool depends on TPM 2.0 as well as 32 bit windows. 291 00:21:19,375 --> 00:21:22,250 The point being that's a rare combination these days. 292 00:21:22,542 --> 00:21:30,375 The one test device is the was the ACER iconia W3 which happens 293 00:21:30,375 --> 00:21:33,876 to only be 32 bit. 294 00:21:33,876 --> 00:21:35,751 That is not going to be the norm. 295 00:21:35,751 --> 00:21:36,751 I can guarantee. 296 00:21:36,999 --> 00:21:37,083 297 00:21:37,083 --> 00:21:37,792 [INAUDIBLE] 298 00:21:37,792 --> 00:21:44,751 DAN GRIFFIN: If anybody else has questions, you're invited to use 299 00:21:44,751 --> 00:21:48,417 the mic or I can repeat it. 300 00:21:51,083 --> 00:21:54,999 I'll go to the Q&A room, which is down the hall. 301 00:21:54,999 --> 00:21:55,999 Thanks, guys.