 Thank you all for joining today. Today we're going to be talking about a new at Google OS image that leverages Windows Server 2025 and the resilient file system for confidential VMs. So a little bit about who is speaking today. So my name is Simran. I am a product manager on the Azure Confidential Computing team and I've been working at Microsoft for two years now. Hi, my name is Tina and I am a product manager on the Windows Storage team. I work mainly on the resilient file system and another storage technology called Storage Spaces. Hi, I'm Vikas, like Simran, I'm also part of the Azure Confidential Computing team. I worked on confidential technologies like SGX in the past and recently on disk integrity for confidential VMs. So a little bit about how our agenda is going to be looking for today. So we're going to start off with a little bit of background on confidential computing and confidential VMs. Then we're going to go into our EFS booth for confidential VMs, talking about the problem space, the new features that we're adding, and go through a couple of demos as well. Then finally, we'll wrap up with a call to action, as well as a forum to ask some questions and show some interest in this feature. So starting off with a little bit of background on confidential computing. So starting with what is confidential computing? So today as a standard, we encrypt data at rest and in transit using mature technologies like BitLocker and TLS. You can do this in all clouds and do this on-prem. But the missing piece of the puzzle is when data is in use. Data has to be decrypted for the CPU to process it and organizations have expressed concern about data being in the clear and unencrypted when in computation. So confidential computing is a maturing technology to help us better protect data in use by processing it in third-party hardware-based trusted execution environments. So today we work with hardware providers such as NVIDIA, AMD and Intel, who are building these protections into the Silicon. And this technology basically helps to protect against many attack factors, such as insider threats does not allow the customer to trust that Microsoft hypervisor or the OS and it helps to secure customer data throughout the lifecycle of the VM. In addition, we are also part of the confidential computing consortium which defines confidential computing as the protection of data in use by performing computation in a hardware-based attested trusted execution environment. This means that customers will be able to obtain a verifiable insurance for data integrity, code integrity and data confidentiality for their customer workloads. So within confidential computing, we have many offerings at the infrastructure layer, the container layer and the pass and sass surfaces as well. One of our most popular infrastructure offerings is the confidential VM, which allows customers to seamlessly lift and shift their workloads to confidential computing. So here on this slide, I'm gonna walk through the provisioning and deployment flows of a confidential VM with OS disk encryption enabled. Confidential OS disk encryption is a security measure that makes sure that the OS disk and customer workload will not be decrypted until the entire boot flow has been measured and is as expected. Only then will the keys be released from the VTPM to decrypt the OS disk and start running the customer workloads. So to walk through this flow, first the customer will make a request to deploy a CVM and we'll ramp up the hardware, the BIOS and the hypervisor. And then the first step from there would be to load the guest firmware and initialize. So this is the host compatibility layer that we load in and this is known as the HCL. After checking that the CVM has launched on an Azure host with a genuine AMD or Intel CPU and is running with good initial boot components, the HCL will then make a call to request the attestation token and the VMGS key to decrypt the VMGS disk. So this contains the initial firmware state, also known as UV and the initial state of the VTPM as well. Next, we will load the guest boot manager and during the boot process, measured boot measures various components and these measurements are stored in platform configuration registers, also known as PCRs. The boot process uses a chain of trust where each component in the boot sequence verifies the integrity of the next component before handing over control to the next layer. Once these hashes are stored in the PCRs and are compared with known good values, the TPM will then unseal and decrypt and boot the OS disk. And last customers can run their applications and attest to the entire flow of their confidential VM by retrieving the attestation report from the VTPM. So this attestation report includes many claims about the hardware as well as PCR events, which can help to drive certain policies that they want to set for their virtual machines. So next, we're going to be talking about RUS boot for confidential VMs and we'll start by going through a little bit of the problem space. So confidential VMs offer a couple of features to provide certain security guarantees. One is secure boot that verifies the startup components checking their signatures before they're loaded. And in addition to this, thanks to measured boot as the startup components are loaded, the firmware UV accumulates their measurements into the VTPM. If the OS disk is encrypted, the VTPM will only release the key to decrypt the OS disk if the VMs from work code, configuration, original boot sequence and boot components are unaltered. But the security guarantees of encryption vary compared to the rest of the boot flow. So I will now pass it over to the cost to kind of go through OS disk encryption and some of its security guarantees. Thanks, Amrin. So OS disk encryption does improve the security posture for CVMs. So the disk data is only in the clear within the CVM trust boundary, but there's still some attacks, mostly tampering attacks, which encryption does not help us with. So in spite of encryption attacker without knowing the disk encryption key could modify portions of the encrypted disk outside of the trust boundary. So they could do it either with random values or conduct a replay attack. And the OS or file system layer, they are not providing any protection against this. And so the detection of these attacks is left to the application. And usually applications are not written with these considerations in mind. A more sophisticated attack is a replay attack where the attacker can capture a ciphertext at a certain point of time in the disk and later replace that with the earlier capture data. And if the attacker has some knowledge about the plain text, they could use this to their advantage. So these attacks are not solved via encryption alone and there is need for integrity here. The other issue is also that there's no attestation for the OS disk components. Major boot in its current form is only covering the initial boot components. So, yeah, I'll hand it over to Tina to talk about how REFS can help us here. Yeah, so our solution for this problem space is REFS booted systems, which will be available on Windows Server 2025 exclusively for CVM customers. The Brazilian file system, otherwise known as REFS, is Microsoft's newest file system and it is designed for high availability scale and to provide data integrity. It is most frequently used as a default file system for on-premises customers and now we've enabled booting from REFS for CVM customers. There are three main capabilities of REFS boot. The first is data integrity interaction where a SHA-256 checksums are applied to all metadata and file data by default. This will bring data integrity and temper protection. Secondly, REFS boot can protect against rollback attacks. This occurs when an attacker rolls back to a stale copy or contaminated copy of the operating system, thus by exposing security vulnerabilities. The solution is to use REFS's internal clock and the secured VM state to detect and prevent rollback attempts. Lastly, the rollback protection is integrated with measured boot, allowing for users to attest and attest to the identity and state for further protection. Next, the cost will go through a few demos of this capability. So we have a couple of demos. The first one is the workflow for deploying these REFS-based images as confidential VMs in Azure. And we also have a demo about rollback protection scenario. In this demo, we'll create an Azure confidential VM leveraging OS disk integrity and rollback protection capabilities of Windows REFS. So I have here a Windows Server 2025 OS Phd formatted with REFS and OS version with the latest rollback protection capabilities. Enabling rollback protection can be thought of as setting a starting point for the image and ensuring that the image cannot be swapped or rollback beyond that point. So before locking down the image, user can do any hardening and specialization of the image. Next, we enable rollback protection on the image by issuing the freeze command. There are a couple of options here. So the user can configure with it to allow or prevent boot in case of rollback and also provide a user payload, which is data identifying the image. This data will be extended as a tamper-proof TPMPCR event which can be used as attestation evidence. Freeze stamps the user-provided data and current Mercury root hash onto the image. The Mercury root hash is essentially a single hash value representing the entire disk. Freeze also starts tracking the volume identity and REFS's internal logical clock to detect volume swap and rollback respectively. To protect disclosure of the logical clock and volume identity information, we need to enable BitLockConnect. I'm doing so using CPT tooling and a customer-managed Azure Key Vault Bag Key. And we are ready to deploy the encrypted image as an Azure Confidential VM. Now let's RDP into the Confidential VM and check the OS disk integrity-related TPMPCR events. At the top, I have the TPMPCR event logs and below is the output of the freeze command issue during image provisioning. User can verify that the frozen root checks matches, which means that the OS disk started at a known point. REFS logs the result of rollback checks on OS disk mount in the verification succeeded event. Lastly, the user can also verify that the user-provided payload matches. So the next demo is a rollback protection scenario. Hi, this is Freddie from the REFS team. I'm going to give you a quick demo of REFS rollback protection for boot volumes. First, let's demonstrate a rollback attack. Here we have an REFS boot VM that has a test file with a string old value in it. We're going to take a snapshot of the VM disk and copy it out. This is happening without the VM knowing. So while this copying is happening, let's go back to the VM and change the test file to say new value. Now that's changed, let's turn off the machine and replace the drive with a snapshot that we took. When the machine comes back up, we see the old value as expected. Now let's enable rollback protection. This feature stores REFS state into view fee variables, allowing us to detect if a volume has been rolled back. This works by checking values such as a GUID and the virtual clock and not allowing mount during boot if we see that any of these values are not what we expected. After rebooting the machine to enable rollback protection, let's take a snapshot of the drive again and change the file contents. We also flush a couple of times so that the virtual clock advances. Now let's turn off the machine and replace the drive with a snapshot we stored as we did last time. The machine fails to boot and goes to recovery instead. This completes the demo. Yes, thank you for prospecting through the demos. So with the combination of Windows REFS images, OS disk encryption and confidential VMs, all components of the VM flow are measured and can be attested to to provide customers with strong security guarantees. With REFS and Windows Server 2025, we're able to add certain features such as data entirety protection for the OS disk, provide rollback protection using UV and REFS, as well as providing application support for the OS disk, meaning that the CVM will only be allowed to boot if the OS disk and applications have the correct hash value in the corresponding PCR. So with this, we're able to measure every layer and a component of this confidential VM. And that marks the end of our presentation. So REFS booted images for CVMs will be available in fall of 2025. We have this interest form. Please fill it out if you're interested in preview and want to stay up to date with our latest features and kind of what we're doing. And if you have any feedback for us or any questions, we'll have that on the feedback form as well. So thank you guys all for joining.