1 00:00:00,000 --> 00:00:06,200 Welcome to the Azure Security Podcast, 2 00:00:06,200 --> 00:00:09,360 where we discuss topics relating to security, privacy, 3 00:00:09,360 --> 00:00:13,720 reliability, and compliance on the Microsoft Cloud Platform. 4 00:00:13,720 --> 00:00:17,020 Hey everybody, welcome to Episode 58. 5 00:00:17,020 --> 00:00:19,200 This week, it's a special episode. 6 00:00:19,200 --> 00:00:23,120 It's just myself, Michael, basically Sarah, Mark, and Gladys. 7 00:00:23,120 --> 00:00:26,560 They're all busy, so it's left down to me. 8 00:00:26,560 --> 00:00:27,680 But with that being said, 9 00:00:27,680 --> 00:00:30,680 it's also a, this week is a pet topic of mine. 10 00:00:30,680 --> 00:00:34,400 We're talking about some of the latest advancements 11 00:00:34,400 --> 00:00:36,640 in Azure confidential computing. 12 00:00:36,640 --> 00:00:39,120 With me this week, I have two special guests. 13 00:00:39,120 --> 00:00:42,000 I have Run Kai and Vikas Bhatia, 14 00:00:42,000 --> 00:00:45,440 who are both here from the confidential computing team to talk to us 15 00:00:45,440 --> 00:00:47,480 about some of the latest innovations. 16 00:00:47,480 --> 00:00:50,200 Run and Vikas, welcome to the podcast. 17 00:00:50,200 --> 00:00:52,640 We'd like to take a moment and introduce yourself. 18 00:00:52,640 --> 00:00:54,400 Hi, Michael. This is Run. 19 00:00:54,400 --> 00:00:57,560 I'm coming from Azure Confidential Computing PM team. 20 00:00:57,560 --> 00:01:00,080 I'm leading Azure Confidential Computing 21 00:01:00,080 --> 00:01:01,760 in for a structured PM team. 22 00:01:01,760 --> 00:01:03,280 Nice to be here. 23 00:01:03,280 --> 00:01:06,200 Thanks, Michael, for giving us this opportunity. 24 00:01:06,200 --> 00:01:09,320 Hi, everyone. My name is Vikas Bhatia, 25 00:01:09,320 --> 00:01:11,480 and I'm the head of product 26 00:01:11,480 --> 00:01:14,160 for Azure Confidential Computing here at Microsoft. 27 00:01:14,160 --> 00:01:16,240 Why don't we kick things off with 28 00:01:16,240 --> 00:01:19,000 probably the most obvious of questions? 29 00:01:19,000 --> 00:01:24,400 Could you explain what confidential computing is and why? 30 00:01:24,400 --> 00:01:25,760 Why confidential computing? 31 00:01:25,760 --> 00:01:27,760 Absolutely. That's a great question. 32 00:01:27,760 --> 00:01:29,440 I think that's where we should start. 33 00:01:29,440 --> 00:01:34,120 I think it boils down to customer's desire 34 00:01:34,120 --> 00:01:37,760 to own the data, 35 00:01:37,760 --> 00:01:41,760 have full control over their data during its entire lifecycle. 36 00:01:41,760 --> 00:01:44,840 What that means is data gets created, 37 00:01:44,840 --> 00:01:46,160 data gets transferred, 38 00:01:46,160 --> 00:01:47,640 data gets stored, 39 00:01:47,640 --> 00:01:49,560 data gets computed upon. 40 00:01:49,560 --> 00:01:54,160 Given the elevated privacy and security environment 41 00:01:54,160 --> 00:01:58,520 that we're living in, customers are quite paranoid 42 00:01:58,520 --> 00:02:00,480 and becoming extremely sophisticated 43 00:02:00,480 --> 00:02:03,920 where they want to ensure that they have full control 44 00:02:03,920 --> 00:02:05,800 over their data during its entire lifecycle. 45 00:02:05,800 --> 00:02:10,920 Customers do already do a ton of this protection of the data. 46 00:02:10,920 --> 00:02:14,920 Today, Microsoft spends over $20 billion 47 00:02:14,920 --> 00:02:16,000 over the next five years, 48 00:02:16,000 --> 00:02:18,480 which we've committed to on cybersecurity. 49 00:02:18,480 --> 00:02:22,600 That goes into making Azure the most trusted cloud platform. 50 00:02:22,600 --> 00:02:26,040 It ranges from strict physical data center security, 51 00:02:26,040 --> 00:02:27,800 data privacy, 52 00:02:27,800 --> 00:02:31,480 and even things like novel uses of machine learning 53 00:02:31,480 --> 00:02:32,440 for threat detection. 54 00:02:32,440 --> 00:02:35,920 Microsoft spends a ton of effort in protecting customer data. 55 00:02:35,920 --> 00:02:37,320 Customers as well, 56 00:02:37,320 --> 00:02:40,280 they use the state-of-the-art techniques 57 00:02:40,280 --> 00:02:43,840 with a key that they own to encrypt their data at rest 58 00:02:43,840 --> 00:02:45,600 and encrypt their data in transit. 59 00:02:45,600 --> 00:02:46,680 What does that mean? 60 00:02:46,680 --> 00:02:48,200 When you encrypt your data at rest, 61 00:02:48,200 --> 00:02:49,480 what that means is you can come, 62 00:02:49,480 --> 00:02:51,160 you can take my laptop and run away with it. 63 00:02:51,160 --> 00:02:53,080 You're not going to get anything out of it 64 00:02:53,080 --> 00:02:54,560 because I'm using BitLocker. 65 00:02:54,560 --> 00:02:56,520 So my data is encrypted at rest. 66 00:02:56,520 --> 00:02:58,560 Similarly, data stays encrypted at rest 67 00:02:58,560 --> 00:03:00,520 even when it's in the cloud, 68 00:03:00,520 --> 00:03:02,120 in one of the Azure servers, 69 00:03:02,120 --> 00:03:04,120 with a key that customers own. 70 00:03:04,120 --> 00:03:05,880 Similarly, data in transit. 71 00:03:05,880 --> 00:03:09,760 We don't really send HTTP traffic over the wire anymore. 72 00:03:09,760 --> 00:03:12,520 We do HTTPS, we do TLS. 73 00:03:12,520 --> 00:03:15,200 We do everything possible to make sure our data is protected 74 00:03:15,200 --> 00:03:18,880 while it is moving between two endpoints. 75 00:03:18,880 --> 00:03:20,600 But data in use, 76 00:03:20,600 --> 00:03:23,720 so when data is actually sitting in memory, 77 00:03:23,720 --> 00:03:26,000 when it is actually being computed upon, 78 00:03:26,000 --> 00:03:31,680 that computation happens on data 79 00:03:31,680 --> 00:03:33,040 when it's entirely in the clear 80 00:03:33,040 --> 00:03:35,960 during the existence of our entire industry. 81 00:03:35,960 --> 00:03:39,000 Our technology industry hasn't had a technical solution 82 00:03:39,000 --> 00:03:41,040 to encrypt data when it is in use, 83 00:03:41,040 --> 00:03:42,560 when it is in memory, 84 00:03:42,560 --> 00:03:44,760 when it is actually being computed upon. 85 00:03:44,760 --> 00:03:47,600 And that's where Confidential Computing steps in. 86 00:03:47,600 --> 00:03:50,560 So Confidential Computing is the ability for customers 87 00:03:50,560 --> 00:03:52,960 to protect their data when it is in memory, 88 00:03:52,960 --> 00:03:54,720 when it is in use, 89 00:03:54,720 --> 00:03:57,680 so that their data stays protected 90 00:03:57,680 --> 00:04:00,160 during its entire lifecycle. 91 00:04:00,160 --> 00:04:03,400 So while Confidential Computing is a valuable element 92 00:04:03,400 --> 00:04:05,360 to protect data and use, 93 00:04:05,360 --> 00:04:07,880 the key value of Confidential Computing 94 00:04:07,880 --> 00:04:10,320 is with Confidential Computing now, 95 00:04:10,320 --> 00:04:13,760 data doesn't ever have to be in the clear. 96 00:04:13,760 --> 00:04:15,800 So data is gonna stay encrypted 97 00:04:15,800 --> 00:04:17,080 as it is being generated, 98 00:04:17,080 --> 00:04:20,160 as it is being stored, as it is being transferred. 99 00:04:20,160 --> 00:04:21,600 And now with Confidential Computing, 100 00:04:21,600 --> 00:04:25,360 it is gonna be protected in memory while it is in use. 101 00:04:25,360 --> 00:04:27,400 So that sounds all well and good. 102 00:04:27,400 --> 00:04:30,200 Encryption, protection of data while it's in use, 103 00:04:30,200 --> 00:04:32,840 but technically, how does this even work? 104 00:04:32,840 --> 00:04:34,160 It's a great question. 105 00:04:34,160 --> 00:04:36,240 So the way to kind of think about it, 106 00:04:36,240 --> 00:04:37,360 if you're gonna get technical, 107 00:04:37,360 --> 00:04:38,880 I'm gonna use this word, 108 00:04:38,880 --> 00:04:42,320 trusted execution environment or a TEE. 109 00:04:42,320 --> 00:04:45,640 Another word we use in our circles is an enclave. 110 00:04:45,640 --> 00:04:47,840 But for this question that you asked me, 111 00:04:47,840 --> 00:04:50,360 I'm gonna go like really level 100 and say, 112 00:04:50,360 --> 00:04:51,920 think of a box. 113 00:04:51,920 --> 00:04:54,200 When you have a box with Confidential Computing, 114 00:04:54,200 --> 00:04:55,960 the only thing that you trust 115 00:04:55,960 --> 00:04:58,360 is what is sitting inside that box. 116 00:04:58,360 --> 00:05:00,680 All the computation that is happening inside that box, 117 00:05:00,680 --> 00:05:02,640 that enclave, that TEE, 118 00:05:02,640 --> 00:05:04,800 the trusted execution environment. 119 00:05:04,800 --> 00:05:08,200 And the way it works is for an application, 120 00:05:08,200 --> 00:05:11,880 your application can, in certain use cases, 121 00:05:11,880 --> 00:05:14,320 create a trusted or an untrusted 122 00:05:14,320 --> 00:05:16,720 and an untrusted part of the application 123 00:05:16,720 --> 00:05:18,560 where the trusted part of the application 124 00:05:18,560 --> 00:05:20,880 is running inside the box. 125 00:05:20,880 --> 00:05:25,640 And only the code which has the keys 126 00:05:25,640 --> 00:05:29,200 to access the data sitting inside that box, 127 00:05:29,200 --> 00:05:31,880 only that code will ever get access 128 00:05:31,880 --> 00:05:34,880 to the data inside that box or that enclave. 129 00:05:34,880 --> 00:05:38,480 So now the way this works in this scenario 130 00:05:38,480 --> 00:05:42,280 is a customer might choose to say partition their app 131 00:05:42,280 --> 00:05:45,120 as they do with Intel Software Guard Extensions, 132 00:05:45,120 --> 00:05:49,280 Intel SGX that we've had in Azure for a few years now, 133 00:05:49,280 --> 00:05:51,480 where what they do is they create 134 00:05:51,480 --> 00:05:54,040 a trusted part of their application 135 00:05:54,040 --> 00:05:56,120 and that trusted part of the application 136 00:05:56,120 --> 00:05:57,880 is what runs inside the enclave. 137 00:05:57,880 --> 00:06:00,520 That is the only thing that they trust. 138 00:06:00,520 --> 00:06:03,240 In our circles, we call it the TCB, 139 00:06:03,240 --> 00:06:05,200 the trusted computing base. 140 00:06:05,200 --> 00:06:07,080 So the trusted computing base for the customer 141 00:06:07,080 --> 00:06:09,760 is now whatever's running inside that enclave 142 00:06:09,760 --> 00:06:14,360 protected by a key that the customer owns. 143 00:06:14,360 --> 00:06:16,160 So you know the next question is, don't you? 144 00:06:16,160 --> 00:06:17,640 So where is that key? 145 00:06:17,640 --> 00:06:20,320 And how is it protected and who has access to it? 146 00:06:20,320 --> 00:06:21,680 Well, that's a very good question. 147 00:06:21,680 --> 00:06:23,960 So the way we can think about Confresh Your Computing, 148 00:06:23,960 --> 00:06:26,320 we really think about it completely end to end. 149 00:06:26,320 --> 00:06:28,400 While I mentioned that the computation happens 150 00:06:28,400 --> 00:06:31,560 inside the box, I didn't quite explain 151 00:06:31,560 --> 00:06:33,920 what happens to the keys and how do you trust 152 00:06:33,920 --> 00:06:36,560 what's inside that box, what sits in that enclave? 153 00:06:36,560 --> 00:06:37,800 So before I go into the keys, 154 00:06:37,800 --> 00:06:40,400 let me talk a little bit about attestation. 155 00:06:40,400 --> 00:06:45,400 Attestation is the fundamental concept of Confresh Your Computing. 156 00:06:45,440 --> 00:06:49,240 What attestation basically does is it proves to the customer 157 00:06:49,240 --> 00:06:54,240 that what you think you're running is what is running. 158 00:06:54,560 --> 00:06:58,080 So customers get a cryptographic proof 159 00:06:58,080 --> 00:07:03,080 provided by the CPU that comes from Intel and AMD, 160 00:07:04,560 --> 00:07:06,920 where the computer's happening. 161 00:07:06,920 --> 00:07:10,440 So in this case, the attestation capability 162 00:07:10,440 --> 00:07:13,080 is something that allows customers the verification 163 00:07:13,080 --> 00:07:16,120 that before I release my important data 164 00:07:16,120 --> 00:07:18,360 to that enclave or that box, 165 00:07:18,360 --> 00:07:20,240 is it really what I expect it to be? 166 00:07:20,240 --> 00:07:22,160 So the first element that I think we need to talk about 167 00:07:22,160 --> 00:07:25,880 is remote attestation, where customers can remotely attest 168 00:07:25,880 --> 00:07:27,840 the state of their environment 169 00:07:27,840 --> 00:07:29,400 before they release sensitive data 170 00:07:29,400 --> 00:07:31,640 to that environment or that enclave. 171 00:07:31,640 --> 00:07:34,960 And Microsoft has a service called Microsoft Azure Attestation 172 00:07:34,960 --> 00:07:38,800 or the MAA service that we provide for free for customers 173 00:07:38,800 --> 00:07:43,400 that itself runs inside an Intel SGX enclave, 174 00:07:43,400 --> 00:07:45,280 the Secure Guard Extensions enclave, 175 00:07:45,280 --> 00:07:48,440 where we as Azure do not have access 176 00:07:48,440 --> 00:07:50,960 to anything running inside that attestation service. 177 00:07:50,960 --> 00:07:53,840 So you know that we are prevented 178 00:07:53,840 --> 00:07:57,000 from modifying your attestation report. 179 00:07:57,000 --> 00:07:59,400 Now that you have an attestation report that tells you, 180 00:07:59,400 --> 00:08:01,720 okay, that enclave that I'm running against 181 00:08:01,720 --> 00:08:05,720 is running in this Intel or AMD environment 182 00:08:05,720 --> 00:08:08,120 and it has this version of operating system 183 00:08:08,120 --> 00:08:11,800 and so on, everything that you can do in your policies. 184 00:08:11,800 --> 00:08:14,120 Once that attestation report is with you, 185 00:08:14,120 --> 00:08:15,920 you can take it to a key manager 186 00:08:15,920 --> 00:08:18,400 and that key manager will then give you the keys 187 00:08:18,400 --> 00:08:23,400 that will only be securely released inside that enclave. 188 00:08:24,200 --> 00:08:26,320 So this is a pretty important element here, Michael, 189 00:08:26,320 --> 00:08:29,920 which is we have fundamentally rethought 190 00:08:29,920 --> 00:08:32,120 the ways the keys should be managed. 191 00:08:32,120 --> 00:08:35,360 So we took our Azure Key Vault, AKB, 192 00:08:35,360 --> 00:08:39,640 which everyone loves and uses and it's phenomenal. 193 00:08:39,640 --> 00:08:42,400 It runs ton of customer workloads, 194 00:08:42,400 --> 00:08:44,560 but we took that and refactored it 195 00:08:44,560 --> 00:08:49,560 so that it can now run, it runs inside a enclave as well. 196 00:08:50,920 --> 00:08:54,880 So we as Microsoft are prevented from getting access 197 00:08:54,880 --> 00:08:56,720 to the keys that customers own. 198 00:08:56,720 --> 00:09:00,040 So the way it would work to kind of tie the story together 199 00:09:00,040 --> 00:09:02,680 is customers would create an enclave, 200 00:09:02,680 --> 00:09:04,360 they would get an attestation report, 201 00:09:04,360 --> 00:09:07,080 hey, is this enclave really what I think it is? 202 00:09:07,080 --> 00:09:08,600 And once they get that attestation report, 203 00:09:08,600 --> 00:09:10,960 they go to the confidential key service, 204 00:09:10,960 --> 00:09:13,160 which is ManageHSM, and by the way, 205 00:09:13,160 --> 00:09:17,120 this ManageHSM service is an entire HSM that customers own. 206 00:09:17,120 --> 00:09:19,120 So they get to the ManageHSM service 207 00:09:19,120 --> 00:09:21,440 and only then, based on the policy 208 00:09:21,440 --> 00:09:24,720 that the customer might put in place, is the key released 209 00:09:24,720 --> 00:09:28,720 and the key is securely released only inside the enclave. 210 00:09:28,720 --> 00:09:31,960 So sorry, that was a super long explanation, 211 00:09:31,960 --> 00:09:36,080 but I think what it boils down to is that customers 212 00:09:36,080 --> 00:09:39,800 with confidential computing, with the attestation capability 213 00:09:39,800 --> 00:09:44,800 and a confidential key management service like ManageHSM 214 00:09:44,840 --> 00:09:49,840 have the assurance that their data is exactly running 215 00:09:49,880 --> 00:09:52,800 inside a compute environment that they can trust. 216 00:09:52,800 --> 00:09:56,160 And I think, and I'm running this maybe a question for you. 217 00:09:56,160 --> 00:10:00,800 So we talk about essentially this trust boundary, 218 00:10:00,800 --> 00:10:02,960 and really what we're trying to do is keep that trust boundary 219 00:10:02,960 --> 00:10:05,200 as small as code as possible running inside 220 00:10:05,200 --> 00:10:07,920 of that trusted computing base. 221 00:10:07,920 --> 00:10:11,840 And part of the attestation process, I presume, 222 00:10:11,840 --> 00:10:14,160 could be including like a digital signature 223 00:10:14,160 --> 00:10:16,840 to make sure that the code that is loaded 224 00:10:16,840 --> 00:10:19,520 into the enclave is correct, it's not been tampered with, 225 00:10:19,520 --> 00:10:21,680 because I mean, my guess is you, 226 00:10:21,680 --> 00:10:24,040 at the end of the day, you could load malware 227 00:10:24,040 --> 00:10:26,960 into an enclave, but the whole point 228 00:10:26,960 --> 00:10:28,920 of this attestation process is to make sure 229 00:10:28,920 --> 00:10:30,920 that that kind of thing doesn't happen. 230 00:10:30,920 --> 00:10:33,480 Is that all, are they all fair comments? 231 00:10:33,480 --> 00:10:35,360 Was I fairly accurate there? 232 00:10:35,360 --> 00:10:38,000 Yes, so Michael, that's true. 233 00:10:38,000 --> 00:10:41,920 And also recently, Azure Confidential Computing 234 00:10:41,920 --> 00:10:45,160 introduced a new type of hardware-based 235 00:10:45,160 --> 00:10:47,080 trusted execution environment. 236 00:10:47,080 --> 00:10:49,640 Azure Confidential Virtual Machine actually is built 237 00:10:49,640 --> 00:10:52,880 upon third-generation AMD Epic processor, 238 00:10:52,880 --> 00:10:56,160 leveraging their security feature called SCVSMP, 239 00:10:56,160 --> 00:11:00,040 which stands for Secure Encrypted Virtualization, 240 00:11:00,040 --> 00:11:02,080 Secure Nested Paging. 241 00:11:02,080 --> 00:11:05,560 That is provide the VM memory encryption 242 00:11:05,560 --> 00:11:07,440 with integrity supporting. 243 00:11:07,440 --> 00:11:10,720 So Azure Confidential VM has already been 244 00:11:10,720 --> 00:11:14,480 general available today, which offers a new type 245 00:11:14,480 --> 00:11:17,720 of VM series, which running on top of AMD, 246 00:11:17,720 --> 00:11:20,120 SCVSMP security features. 247 00:11:20,120 --> 00:11:24,880 And with that, that is new hardware-based enclave, 248 00:11:24,880 --> 00:11:26,880 which protect VM memory encryption 249 00:11:26,880 --> 00:11:28,960 and integrity protection. 250 00:11:28,960 --> 00:11:33,240 That is offer the guest protection to deny hypervisor 251 00:11:33,240 --> 00:11:36,680 and also other host management code access 252 00:11:36,680 --> 00:11:40,400 to VM memory and state, and protecting 253 00:11:40,400 --> 00:11:42,560 against operator access. 254 00:11:42,560 --> 00:11:45,080 And most important thing, I think, 255 00:11:45,080 --> 00:11:49,280 we add different layers of protection for confidential VM. 256 00:11:49,280 --> 00:11:52,960 First of all, as we mentioned about the confidential VM 257 00:11:52,960 --> 00:11:56,280 using the SCVSMP, the security feature, 258 00:11:56,280 --> 00:11:58,800 to protect the VM memory encryption. 259 00:11:58,800 --> 00:12:01,800 One thing we need to notice that the VM memory encryption, 260 00:12:01,800 --> 00:12:04,560 the key, previously, Vickers talk about the key 261 00:12:04,560 --> 00:12:05,720 is very essential. 262 00:12:05,720 --> 00:12:09,120 The VM encryption key actually is generated 263 00:12:09,120 --> 00:12:13,160 inside of the AMD processors, and that, well, 264 00:12:13,160 --> 00:12:16,120 software cannot be read directly from that key. 265 00:12:16,120 --> 00:12:19,480 That is fully protected from silicon perspective. 266 00:12:19,480 --> 00:12:22,720 And also, on top of that, we add different layers 267 00:12:22,720 --> 00:12:26,800 of protection, for instance, like OS for disk encryption. 268 00:12:26,800 --> 00:12:29,440 For today, Azure Confidential VM customer, 269 00:12:29,440 --> 00:12:33,880 they can opt in to choose OS for disk encryption. 270 00:12:33,880 --> 00:12:36,600 And the key to encrypt the OS disk 271 00:12:36,600 --> 00:12:38,960 can be either a platform manage key, 272 00:12:38,960 --> 00:12:42,560 which Azure manage key for you, or custom manage key. 273 00:12:42,560 --> 00:12:45,400 And the custom manage key, actually, the customer 274 00:12:45,400 --> 00:12:48,720 can choose whether it is using the Azure Key Vault 275 00:12:48,720 --> 00:12:51,760 or Azure management Key Vault, which 276 00:12:51,760 --> 00:12:54,760 is running inside of SGX Enclave. 277 00:12:54,760 --> 00:12:58,360 And most important thing is these keys actually 278 00:12:58,360 --> 00:13:01,920 is cryptographically bounding with security key release 279 00:13:01,920 --> 00:13:07,080 policy, which means that is associated with attestation. 280 00:13:07,080 --> 00:13:11,320 The key will not be released until the remote attestation 281 00:13:11,320 --> 00:13:14,280 kicked in, and all the code come back 282 00:13:14,280 --> 00:13:17,960 to the attestation result shows all the key release policy 283 00:13:17,960 --> 00:13:18,960 has been met. 284 00:13:18,960 --> 00:13:22,800 Then all the OS disk can be, the key can be released, 285 00:13:22,800 --> 00:13:27,640 and the OS disk can be decrypted, and the VM can be accessed. 286 00:13:27,640 --> 00:13:31,000 And remember, all the OS for disk encryption, 287 00:13:31,000 --> 00:13:34,640 the encryption happens actually before the VM first boot. 288 00:13:34,640 --> 00:13:38,640 So that is very, we are very proud of these features 289 00:13:38,640 --> 00:13:41,280 to be built on the confidential VM. 290 00:13:41,280 --> 00:13:44,440 And lastly, also very important, as B.K.C.E. 291 00:13:44,440 --> 00:13:47,600 mentioned, is remote attestation capability. 292 00:13:47,600 --> 00:13:50,040 For Azure confidential VM, customer actually 293 00:13:50,040 --> 00:13:52,800 can, inside of the confidential VM, 294 00:13:52,800 --> 00:13:56,920 they can initiate the attestation request 295 00:13:56,920 --> 00:14:02,080 to choose to attest whether their VM is actually 296 00:14:02,080 --> 00:14:05,600 running on the AMD powered nodes, which 297 00:14:05,600 --> 00:14:08,960 has SEV SMP security feature turned off. 298 00:14:08,960 --> 00:14:12,680 There are three nuances in what you just said there 299 00:14:12,680 --> 00:14:15,240 that I really want to make sure people understand. 300 00:14:15,240 --> 00:14:16,760 And if I'm wrong here, let me know. 301 00:14:16,760 --> 00:14:19,160 I just want to go through all three of these. 302 00:14:19,160 --> 00:14:21,440 The first one is you said the word operator. 303 00:14:21,440 --> 00:14:24,000 Operators don't have access to this stuff. 304 00:14:24,000 --> 00:14:25,440 That includes Azure operators, right? 305 00:14:25,440 --> 00:14:27,680 That includes the people who are on the management plane, 306 00:14:27,680 --> 00:14:29,000 the back end of Azure. 307 00:14:29,000 --> 00:14:31,080 They don't have access to this stuff either. 308 00:14:31,080 --> 00:14:31,720 Exactly. 309 00:14:31,720 --> 00:14:33,560 That is for the VM memory encryption 310 00:14:33,560 --> 00:14:35,720 that we talk about, all the keys actually 311 00:14:35,720 --> 00:14:38,280 is generated and reside inside of Silicon, 312 00:14:38,280 --> 00:14:40,680 and nobody else can read it directly. 313 00:14:40,680 --> 00:14:41,400 Exactly. 314 00:14:41,400 --> 00:14:43,360 And that's my second point. 315 00:14:43,360 --> 00:14:45,920 The ultimate root of trust here is not Azure. 316 00:14:45,920 --> 00:14:48,880 It is not Microsoft in this example, it's AMD. 317 00:14:48,880 --> 00:14:49,680 Totally. 318 00:14:49,680 --> 00:14:52,160 And also, Azure Confidash Computing 319 00:14:52,160 --> 00:14:56,240 is aligned with definition of Confidash Computing 320 00:14:56,240 --> 00:14:59,640 consumption, that we are building the hardware-based 321 00:14:59,640 --> 00:15:02,000 Confidash Computing, which means customers 322 00:15:02,000 --> 00:15:03,280 do not need to trust Azure. 323 00:15:03,280 --> 00:15:06,000 They all need to trust its Silicon providers, 324 00:15:06,000 --> 00:15:08,200 like AMD, like Intel. 325 00:15:08,200 --> 00:15:08,560 Right. 326 00:15:08,560 --> 00:15:12,560 And then the last one is the attestation service 327 00:15:12,560 --> 00:15:13,840 is not the VM. 328 00:15:13,840 --> 00:15:15,720 It is not SGX. 329 00:15:15,720 --> 00:15:18,040 It is something that is completely separate, 330 00:15:18,040 --> 00:15:21,480 that has no interest whatsoever in what that code is. 331 00:15:21,480 --> 00:15:25,440 But its job is purely to validate that it is correct. 332 00:15:25,440 --> 00:15:26,440 That is all it is. 333 00:15:26,440 --> 00:15:29,480 So this is not a self-policing environment. 334 00:15:29,480 --> 00:15:30,640 This is actually something that's 335 00:15:30,640 --> 00:15:33,240 outside of the environment, outside of this VM, 336 00:15:33,240 --> 00:15:36,720 outside of the SGX enclave that is validating that, yes, 337 00:15:36,720 --> 00:15:39,920 that VM is actually the correct image. 338 00:15:39,920 --> 00:15:43,160 And yes, that code that runs in this SGX enclave 339 00:15:43,160 --> 00:15:44,640 is the correct code. 340 00:15:44,640 --> 00:15:46,400 And I think that's incredibly important, 341 00:15:46,400 --> 00:15:49,000 because without the attestation process, 342 00:15:49,000 --> 00:15:51,320 this whole thing kind of falls over. 343 00:15:51,320 --> 00:15:53,240 I mean, perhaps that's a strong word, 344 00:15:53,240 --> 00:15:55,640 but it's nowhere near as secure if we didn't 345 00:15:55,640 --> 00:15:57,880 have the attestation process. 346 00:15:57,880 --> 00:15:58,440 Yes. 347 00:15:58,440 --> 00:16:00,560 And one of the key differentiation 348 00:16:00,560 --> 00:16:03,320 of the confidential VM that built on in Azure 349 00:16:03,320 --> 00:16:09,080 is we built the capability of the remote attestation. 350 00:16:09,080 --> 00:16:11,840 Actually, we have two different attestation type. 351 00:16:11,840 --> 00:16:13,800 One is platform attestation, which 352 00:16:13,800 --> 00:16:18,600 means even on Azure, we built the background attestation 353 00:16:18,600 --> 00:16:22,600 mechanism to make sure when we launch this confidential VM, 354 00:16:22,600 --> 00:16:27,360 it is really, truly running onto a CVSMP processors 355 00:16:27,360 --> 00:16:28,720 offered by AMD. 356 00:16:28,720 --> 00:16:32,800 But that basically, that process is opaque to the customers. 357 00:16:32,800 --> 00:16:35,680 Another attestation feature we announced 358 00:16:35,680 --> 00:16:37,760 is also the guest attestation, which 359 00:16:37,760 --> 00:16:41,400 means confidential VM customers inside of the VM. 360 00:16:41,400 --> 00:16:45,040 They can challenge whether my VM is really truly running 361 00:16:45,040 --> 00:16:49,640 into the AMD powered CVSMP on silicon. 362 00:16:49,640 --> 00:16:50,760 So this is actually really cool. 363 00:16:50,760 --> 00:16:54,000 I mean, this opens up this whole notion 364 00:16:54,000 --> 00:16:58,000 of having a virtual machine as a trusted execution 365 00:16:58,000 --> 00:17:01,480 environment is really awesome for a number of reasons, 366 00:17:01,480 --> 00:17:01,880 I think. 367 00:17:01,880 --> 00:17:04,480 Number one, I mean, SGX is cool. 368 00:17:04,480 --> 00:17:06,400 Don't get me wrong. 369 00:17:06,400 --> 00:17:08,760 Although my extensive SGX has been writing basically 370 00:17:08,760 --> 00:17:09,840 a version of Hello World. 371 00:17:09,840 --> 00:17:12,680 But anyway, we've got to write custom code, right? 372 00:17:12,680 --> 00:17:15,840 You can't just sort of lift and shift. 373 00:17:15,840 --> 00:17:18,480 If you're going to do SGX eyes something, 374 00:17:18,480 --> 00:17:22,680 you've got to modify the code and run a portion of your code 375 00:17:22,680 --> 00:17:23,560 inside of the SGX. 376 00:17:23,560 --> 00:17:26,400 And a really good example, I guess, is say, for example, 377 00:17:26,400 --> 00:17:30,240 a SQL server using always encrypted with secure enclaves, 378 00:17:30,240 --> 00:17:30,520 right? 379 00:17:30,520 --> 00:17:32,520 So part of the query processor actually 380 00:17:32,520 --> 00:17:35,760 runs in the enclave, which is super nice. 381 00:17:35,760 --> 00:17:37,920 But here what you've got, you've got an entire VM. 382 00:17:37,920 --> 00:17:40,400 So obviously, the trust boundary is a little bit larger, 383 00:17:40,400 --> 00:17:44,120 because it's bigger than just a small enclave. 384 00:17:44,120 --> 00:17:47,120 However, there is a trust boundary around this VM. 385 00:17:47,120 --> 00:17:51,240 So now I can start loading workloads into that 386 00:17:51,240 --> 00:17:53,240 and have all the isolation that I would normally 387 00:17:53,240 --> 00:17:56,280 have using combination computing technologies 388 00:17:56,280 --> 00:17:59,400 like encryption and integrity checks and so on. 389 00:17:59,400 --> 00:18:02,320 But it supports these lift and shift scenarios now, 390 00:18:02,320 --> 00:18:03,920 which is really cool. 391 00:18:03,920 --> 00:18:05,920 I don't need to modify any of my code. 392 00:18:05,920 --> 00:18:08,160 I was working just recently with a health care company, 393 00:18:08,160 --> 00:18:10,880 and they had a third party application 394 00:18:10,880 --> 00:18:12,880 that ran inside of a VM. 395 00:18:12,880 --> 00:18:13,480 And it's health. 396 00:18:13,480 --> 00:18:14,520 I mean, this is health care. 397 00:18:14,520 --> 00:18:16,600 I mean, they're dealing with sensitive health care 398 00:18:16,600 --> 00:18:17,760 information. 399 00:18:17,760 --> 00:18:20,800 And this would have been a perfect scenario, 400 00:18:20,800 --> 00:18:22,480 admittedly, this was a year ago. 401 00:18:22,480 --> 00:18:24,200 But this would have been a perfect example 402 00:18:24,200 --> 00:18:26,920 where they could run the specific workload, which 403 00:18:26,920 --> 00:18:28,200 came from a third party. 404 00:18:28,200 --> 00:18:31,160 They could run it in the VM and have all the benefits 405 00:18:31,160 --> 00:18:35,200 of combination computing with no re-engineering. 406 00:18:35,200 --> 00:18:36,000 Exactly. 407 00:18:36,000 --> 00:18:39,720 And also what we are seeing for the Azure Confidential VM, 408 00:18:39,720 --> 00:18:42,800 which the top two scenarios that we can think about it 409 00:18:42,800 --> 00:18:46,000 for the use case is, number one, for the on-prem customers 410 00:18:46,000 --> 00:18:49,480 that they probably do not want to modify their code. 411 00:18:49,480 --> 00:18:52,960 They can migrate to the Azure Cloud. 412 00:18:52,960 --> 00:18:56,200 And also, if for the super paranoid customers 413 00:18:56,200 --> 00:18:58,520 are very sensitive on the customer data, 414 00:18:58,520 --> 00:19:00,520 they even will give them the tooling 415 00:19:00,520 --> 00:19:03,720 that potentially they can just do every encryption 416 00:19:03,720 --> 00:19:07,680 of their data or OS disk at the on-prem environment. 417 00:19:07,680 --> 00:19:09,920 And then they launch the Confidential VM 418 00:19:09,920 --> 00:19:11,720 with encrypted OS disk. 419 00:19:11,720 --> 00:19:13,520 With that, there you can think about that. 420 00:19:13,520 --> 00:19:17,440 It's even more secure because every encryption environment 421 00:19:17,440 --> 00:19:18,680 happens on-prem. 422 00:19:18,680 --> 00:19:22,800 So that gives on-prem customer can migrate to the Azure Cloud. 423 00:19:22,800 --> 00:19:27,280 Another scenario is for the existing Azure Cloud customers, 424 00:19:27,280 --> 00:19:29,280 they can just simply go to the Azure portal 425 00:19:29,280 --> 00:19:32,120 and double click a few buttons through the portal 426 00:19:32,120 --> 00:19:34,200 and they can launch Confidential VM. 427 00:19:34,200 --> 00:19:38,040 And all the workload previous running into the Cloud 428 00:19:38,040 --> 00:19:41,240 environment, they can just lift a shift to the Confidential VM. 429 00:19:41,240 --> 00:19:44,000 So I know that under Confidential Computing, 430 00:19:44,000 --> 00:19:46,800 we also have this thing called trusted launch. 431 00:19:46,800 --> 00:19:49,560 Does that fit into this in some way? 432 00:19:49,560 --> 00:19:52,080 Trust launch actually provide the secure boot 433 00:19:52,080 --> 00:19:55,680 and also virtual TPM capabilities to customers. 434 00:19:55,680 --> 00:19:58,200 All the trusted launch features actually 435 00:19:58,200 --> 00:20:01,240 has been inherited from Confidential VM. 436 00:20:01,240 --> 00:20:04,080 Every individual Confidential VM from Azure 437 00:20:04,080 --> 00:20:07,360 will has its unique virtual TPM, which 438 00:20:07,360 --> 00:20:10,160 virtual trusted platform module. 439 00:20:10,160 --> 00:20:14,680 And this VTPM actually resides in higher privileged memory 440 00:20:14,680 --> 00:20:20,240 protected by the CPU from AMD, third generation, Epic processors. 441 00:20:20,240 --> 00:20:25,600 And customer can seal their keys or secret into the virtual TPM. 442 00:20:25,600 --> 00:20:27,320 And also secure boot as well, customer 443 00:20:27,320 --> 00:20:29,160 can turn on the secure boot and make sure 444 00:20:29,160 --> 00:20:32,080 that all the drivers, kernels, and also 445 00:20:32,080 --> 00:20:34,880 book-through-kits is measured and also 446 00:20:34,880 --> 00:20:38,280 is meeting their requirement as well during the VM boot. 447 00:20:38,280 --> 00:20:41,960 So the VTPM is essentially the virtualized TPM, 448 00:20:41,960 --> 00:20:46,960 or trusted platform module, is essentially very similar to what 449 00:20:46,960 --> 00:20:51,400 we have in say Windows 11 on a laptop or we have a TPM, 450 00:20:51,400 --> 00:20:54,840 trusted platform modules, to provide all sorts of security 451 00:20:54,840 --> 00:20:57,640 services for making sure that the boot is correct 452 00:20:57,640 --> 00:21:00,120 and making sure there's no bootkits and rootkits. 453 00:21:00,120 --> 00:21:03,000 So it's the same thing, but just in a virtualized environment. 454 00:21:03,000 --> 00:21:04,160 Exactly. 455 00:21:04,160 --> 00:21:04,760 OK. 456 00:21:04,760 --> 00:21:06,440 So Vikas, I have to ask a question. 457 00:21:06,440 --> 00:21:08,800 I mean, what sort of broad offerings 458 00:21:08,800 --> 00:21:12,120 do we have here in the Confidential Computing umbrella? 459 00:21:12,120 --> 00:21:14,000 Yeah, so I think, Michael, like we know 460 00:21:14,000 --> 00:21:18,400 we Azure has been at the forefront of bringing 461 00:21:18,400 --> 00:21:21,560 Confidential Computing to the industry. 462 00:21:21,560 --> 00:21:24,080 We were one of the founding members of the Confidential 463 00:21:24,080 --> 00:21:27,840 Computing Consortium back in September 2019. 464 00:21:27,840 --> 00:21:34,960 And we took the bleeding edge of hardware available, 465 00:21:34,960 --> 00:21:37,200 whatever was available, and we took it to the cloud. 466 00:21:37,200 --> 00:21:40,440 And we got this ecosystem sort of going. 467 00:21:40,440 --> 00:21:42,200 So I think in some ways right now, 468 00:21:42,200 --> 00:21:44,760 Azure has the broadest set of offerings 469 00:21:44,760 --> 00:21:47,600 and the deepest set of offerings for customers, 470 00:21:47,600 --> 00:21:49,040 no matter where they're coming from. 471 00:21:49,040 --> 00:21:51,680 So I talked a little bit about apps 472 00:21:51,680 --> 00:21:53,720 when I was talking about Intel SGX. 473 00:21:53,720 --> 00:21:56,880 And Run talked about confidential VMs 474 00:21:56,880 --> 00:22:00,720 where customers can move their applications 475 00:22:00,720 --> 00:22:04,000 without modification directly into a confidential VM. 476 00:22:04,000 --> 00:22:06,560 But we also have solutions for confidential containers 477 00:22:06,560 --> 00:22:09,720 where customers can make their container confidential 478 00:22:09,720 --> 00:22:12,920 without changing a single line of code in certain cases. 479 00:22:12,920 --> 00:22:14,880 And so the way we got to think about it 480 00:22:14,880 --> 00:22:18,440 is we think about it completely end to end. 481 00:22:18,440 --> 00:22:21,200 We think about it where we are first enabling 482 00:22:21,200 --> 00:22:24,080 a confidential platform, where we are enabling 483 00:22:24,080 --> 00:22:30,480 the basic IaaS layer with VMs, containers, and applications 484 00:22:30,480 --> 00:22:33,520 where customers can take their applications, sometimes 485 00:22:33,520 --> 00:22:35,720 existing, sometimes new ones, and bring them 486 00:22:35,720 --> 00:22:38,000 into a confidential environment to get that assurance, 487 00:22:38,000 --> 00:22:39,880 additional assurance that they need. 488 00:22:39,880 --> 00:22:41,680 But we don't stop there. 489 00:22:41,680 --> 00:22:46,240 So we touched a little bit about the confidential cloud 490 00:22:46,240 --> 00:22:49,800 where we are making the Azure cloud itself 491 00:22:49,800 --> 00:22:51,520 confidential over time. 492 00:22:51,520 --> 00:22:54,120 While today we have infrastructure capabilities 493 00:22:54,120 --> 00:22:56,080 around Microsoft Azure Attestation Service, 494 00:22:56,080 --> 00:22:59,480 the Managed HSM Service, we also have actually 495 00:22:59,480 --> 00:23:03,680 going into general availability right now 496 00:23:03,680 --> 00:23:07,880 is the Azure Confidential Ledger where customers can use 497 00:23:07,880 --> 00:23:11,840 a confidential service for Tampa Proof Audit Logging, which 498 00:23:11,840 --> 00:23:16,680 we are seeing great pickup in compliance and audit related 499 00:23:16,680 --> 00:23:17,920 scenarios. 500 00:23:17,920 --> 00:23:22,880 Additional services that we have in Azure are around Azure SQL 501 00:23:22,880 --> 00:23:26,760 always encrypted that runs in Azure, always encrypted 502 00:23:26,760 --> 00:23:31,080 with secure enclaves that runs inside an enclave environment 503 00:23:31,080 --> 00:23:31,880 itself. 504 00:23:31,880 --> 00:23:36,480 And overall, I think we are making capabilities 505 00:23:36,480 --> 00:23:38,920 that customers really want completely end to end. 506 00:23:38,920 --> 00:23:40,200 And it just doesn't stop there. 507 00:23:40,200 --> 00:23:44,960 We also have a rich and growing ecosystem of partners 508 00:23:44,960 --> 00:23:48,920 who are bringing capabilities that customers 509 00:23:48,920 --> 00:23:52,440 can leverage to make their journey into confidentiality. 510 00:23:52,440 --> 00:23:56,200 In fact, we just released a huge set of webinars 511 00:23:56,200 --> 00:24:00,120 with our partners that customers can start listening to them 512 00:24:00,120 --> 00:24:01,720 on our conference computing website 513 00:24:01,720 --> 00:24:03,160 that I think we'll share later. 514 00:24:03,160 --> 00:24:04,880 But overall, the way to think about it, Michael, 515 00:24:04,880 --> 00:24:07,920 is customers have to decide what their security posture needs 516 00:24:07,920 --> 00:24:10,320 are, what their scale needs are, whether they 517 00:24:10,320 --> 00:24:11,400 have existing workloads. 518 00:24:11,400 --> 00:24:12,880 They want to bring it to confidentiality 519 00:24:12,880 --> 00:24:14,520 or start with new workloads. 520 00:24:14,520 --> 00:24:18,560 I think overall, in Azure, we've given that capability. 521 00:24:18,560 --> 00:24:20,760 And this technology space is rapidly evolving. 522 00:24:20,760 --> 00:24:23,600 We are talking now in six months, if we talk again, 523 00:24:23,600 --> 00:24:25,480 this space is going to be even more different. 524 00:24:25,480 --> 00:24:26,760 I think it's constantly evolving. 525 00:24:26,760 --> 00:24:28,240 And we are pretty excited with what's 526 00:24:28,240 --> 00:24:29,840 coming online as well. 527 00:24:29,840 --> 00:24:32,160 Yeah, I think over the next few months, 528 00:24:32,160 --> 00:24:34,960 we'll certainly see, as we start talking more about, 529 00:24:34,960 --> 00:24:36,760 not just confidential computing, but certainly 530 00:24:36,760 --> 00:24:41,000 the new VMs that have been made available, people moving 531 00:24:41,000 --> 00:24:43,840 some of their more sensitive workloads quickly 532 00:24:43,840 --> 00:24:45,880 to these confidential computing VMs. 533 00:24:45,880 --> 00:24:48,440 I think that's going to be absolutely magnificent 534 00:24:48,440 --> 00:24:49,320 to see that happening. 535 00:24:49,320 --> 00:24:51,520 And perhaps some environments may start 536 00:24:51,520 --> 00:24:55,600 to write their own custom code and use Intel SGX secure 537 00:24:55,600 --> 00:24:56,600 enclaves. 538 00:24:56,600 --> 00:24:57,360 I don't know. 539 00:24:57,360 --> 00:25:00,600 But the key thing there is this whole notion 540 00:25:00,600 --> 00:25:04,080 of having a very tight, trusted execution environment, 541 00:25:04,080 --> 00:25:09,400 where you control the keys, the data is encrypted in memory, 542 00:25:09,400 --> 00:25:11,560 all the memory is encrypted, period. 543 00:25:11,560 --> 00:25:14,200 The keys aren't released until all the lights 544 00:25:14,200 --> 00:25:16,200 are green, that kind of thing. 545 00:25:16,200 --> 00:25:17,960 I think that's absolutely magnificent. 546 00:25:17,960 --> 00:25:20,600 So do we have any examples of how some customers are using, 547 00:25:20,600 --> 00:25:23,320 for example, the new VM types today? 548 00:25:23,320 --> 00:25:23,960 Absolutely. 549 00:25:23,960 --> 00:25:29,800 And I think customers can go to aka.ms.azurecc, 550 00:25:29,800 --> 00:25:32,640 which is our confidential computing website on Azure 551 00:25:32,640 --> 00:25:34,320 to see what's going on. 552 00:25:34,320 --> 00:25:39,600 We also have another short link, aka.ms.accstories, 553 00:25:39,600 --> 00:25:41,880 where we are constantly publishing more customer 554 00:25:41,880 --> 00:25:46,320 stories about how customers are leveraging this technology. 555 00:25:46,320 --> 00:25:49,520 And this technology is maturing pretty fast. 556 00:25:49,520 --> 00:25:54,560 As Run mentioned, customers can essentially 557 00:25:54,560 --> 00:25:57,360 redeploy into a virtual machine. 558 00:25:57,360 --> 00:25:58,800 And suddenly, they're confidential 559 00:25:58,800 --> 00:26:00,120 without changing any source code. 560 00:26:00,120 --> 00:26:02,800 And that, as you can see, is super powerful. 561 00:26:02,800 --> 00:26:05,520 I think by going to this website and checking out 562 00:26:05,520 --> 00:26:08,080 sort of where things our customers can learn a lot more 563 00:26:08,080 --> 00:26:09,400 and also get in touch with us, we're 564 00:26:09,400 --> 00:26:10,800 happy to help them as well. 565 00:26:10,800 --> 00:26:12,960 Well, let's start bringing this thing to a close. 566 00:26:12,960 --> 00:26:15,600 So one question we always ask our guests 567 00:26:15,600 --> 00:26:19,040 is if you had one single thought to leave our listeners with, 568 00:26:19,040 --> 00:26:20,440 what would it be? 569 00:26:20,440 --> 00:26:21,840 So let me take that. 570 00:26:21,840 --> 00:26:23,960 So I think from one final thought, 571 00:26:23,960 --> 00:26:27,760 I think while this podcast may seem pretty technical 572 00:26:27,760 --> 00:26:30,640 and we went into a bunch of technical details, 573 00:26:30,640 --> 00:26:32,720 we have abstracted or we have attempted 574 00:26:32,720 --> 00:26:35,720 to abstract all the technical concepts away from you, 575 00:26:35,720 --> 00:26:39,120 unless we really want you to know them, like attestation. 576 00:26:39,120 --> 00:26:44,920 But I'd encourage the listeners to go to the Azure portal, 577 00:26:44,920 --> 00:26:53,320 go find the confidential VM sizes, which are EASV5 and DASV5. 578 00:26:53,320 --> 00:26:57,080 Go to the Azure portal, select a gen2 image, 579 00:26:57,080 --> 00:27:00,400 select the operating system image that you want, 580 00:27:00,400 --> 00:27:02,400 and boom, review and create and go. 581 00:27:02,400 --> 00:27:03,080 You're good to go. 582 00:27:03,080 --> 00:27:04,520 You suddenly have a confidential VM 583 00:27:04,520 --> 00:27:05,880 that you can deploy into. 584 00:27:05,880 --> 00:27:07,080 It's as simple as that. 585 00:27:07,080 --> 00:27:10,120 So I'd encourage the listeners to go kick the tires, 586 00:27:10,120 --> 00:27:12,280 tell us what you think. 587 00:27:12,280 --> 00:27:14,120 This new technology is rapidly happening, 588 00:27:14,120 --> 00:27:17,440 and the more you get educated, the more beneficial 589 00:27:17,440 --> 00:27:18,600 it will be for you. 590 00:27:18,600 --> 00:27:20,240 I know I just said a final thought, 591 00:27:20,240 --> 00:27:22,040 but I have to leave you with something as well. 592 00:27:22,040 --> 00:27:24,520 I remember talking to a customer, again, in health care. 593 00:27:24,520 --> 00:27:26,240 We're doing some SQL server stuff 594 00:27:26,240 --> 00:27:28,520 with always encrypted with secure enclaves. 595 00:27:28,520 --> 00:27:29,960 I'll show them how to set it up. 596 00:27:29,960 --> 00:27:32,280 I might have you on how it all hangs together. 597 00:27:32,280 --> 00:27:34,520 And then I went over to the Azure Attestation Service, 598 00:27:34,520 --> 00:27:36,160 and he said, what's that? 599 00:27:36,160 --> 00:27:38,080 And I said, that's the Azure Attestation Service. 600 00:27:38,080 --> 00:27:39,800 He says, what's that? 601 00:27:39,800 --> 00:27:40,960 So I explained what it did. 602 00:27:40,960 --> 00:27:41,960 And he's like, you know what? 603 00:27:41,960 --> 00:27:42,960 I didn't even know that existed. 604 00:27:42,960 --> 00:27:46,760 But until you told me that it existed, 605 00:27:46,760 --> 00:27:49,520 the penny has just dropped as to how important 606 00:27:49,520 --> 00:27:51,880 that attestation service is. 607 00:27:51,880 --> 00:27:54,640 He said, he realized that the whole thing really 608 00:27:54,640 --> 00:27:58,400 hinges on making sure that we're dealing with the correct stuff. 609 00:27:58,400 --> 00:28:00,600 And that has to be done by something outside 610 00:28:00,600 --> 00:28:02,640 of the actual process itself. 611 00:28:02,640 --> 00:28:05,080 And that's the role of the attestation process. 612 00:28:05,080 --> 00:28:05,960 So it's interesting. 613 00:28:05,960 --> 00:28:06,840 It's a really good example. 614 00:28:06,840 --> 00:28:08,560 I'm a big fan of explaining things to people 615 00:28:08,560 --> 00:28:11,840 about the stuff you know you know, 616 00:28:11,840 --> 00:28:14,480 the stuff you know you don't know, 617 00:28:14,480 --> 00:28:17,200 and then the stuff you don't know you don't know. 618 00:28:17,200 --> 00:28:21,880 And attestation was a really good example of the last point. 619 00:28:21,880 --> 00:28:22,360 All right, folks. 620 00:28:22,360 --> 00:28:24,600 Well, look, Rune and Vikas, thank you so much 621 00:28:24,600 --> 00:28:25,920 for joining us this week. 622 00:28:25,920 --> 00:28:27,240 You know, I just love this stuff. 623 00:28:27,240 --> 00:28:29,440 I think it's a fantastic technology. 624 00:28:29,440 --> 00:28:31,720 I know a lot of customers that I've worked with in the past 625 00:28:31,720 --> 00:28:33,640 are interested in it. 626 00:28:33,640 --> 00:28:35,480 They were looking primarily at the SGX stuff 627 00:28:35,480 --> 00:28:37,640 because frankly, that's all that was available. 628 00:28:37,640 --> 00:28:40,960 But now that we have these confidential computing 629 00:28:40,960 --> 00:28:43,040 VMs from AMD, I think that is going 630 00:28:43,040 --> 00:28:45,400 to open up so many more workloads. 631 00:28:45,400 --> 00:28:47,560 So with that, let's bring this whole thing to a close. 632 00:28:47,560 --> 00:28:49,600 This has been an awesome conversation. 633 00:28:49,600 --> 00:28:51,480 Thank you so much for joining us this week. 634 00:28:51,480 --> 00:28:53,920 And to our listeners, thank you also for listening. 635 00:28:53,920 --> 00:28:55,560 I hope you learned a lot. 636 00:28:55,560 --> 00:28:57,920 I can almost guarantee you did. 637 00:28:57,920 --> 00:29:00,680 So stay safe, and we'll see you next time. 638 00:29:00,680 --> 00:29:01,840 Thank you, Michael. 639 00:29:01,840 --> 00:29:02,480 Thank you, Michael. 640 00:29:02,480 --> 00:29:03,160 This was great. 641 00:29:03,160 --> 00:29:06,080 Thanks for listening to the Azure Security Podcast. 642 00:29:06,080 --> 00:29:08,600 You can find show notes and other resources 643 00:29:08,600 --> 00:29:12,880 at our website azsecuritypodcast.net. 644 00:29:12,880 --> 00:29:14,720 If you have any questions, please 645 00:29:14,720 --> 00:29:17,640 find us on Twitter at azuresecpod. 646 00:29:17,640 --> 00:29:20,600 Background music is from ccmixter.com 647 00:29:20,600 --> 00:29:24,120 and licensed under the Creative Commons license.