Shielded VM

Shielded VM offers verifiable integrity of your Compute Engine VM instances, so you can be confident your instances haven't been compromised by boot- or kernel-level malware or rootkits. Shielded VM's verifiable integrity is achieved through the use of Secure Boot, virtual trusted platform module (vTPM)-enabled Measured Boot, and integrity monitoring.

Shielded VM is the first offering in the Shielded Cloud initiative. The Shielded Cloud initiative is meant to provide an even more secure foundation for all of Google Cloud Platform (GCP) by providing verifiable integrity and offering features, like vTPM shielding or sealing, that help prevent data exfiltration.

Secure Boot

Secure Boot helps ensure that the system only runs authentic software by verifying the digital signature of all boot components, and halting the boot process if signature verification fails.

Shielded VM instances run firmware which is signed and verified using Google's Certificate Authority, ensuring that the instance's firmware is unmodified and establishing the root of trust for Secure Boot. Secure Boot uses Unified Extensible Firmware Interface (UEFI) 2.3.1 firmware, which securely stores the keys used by the software manufacturers to sign the system firmware, the system boot loader, and any binaries they load. During the boot sequence, the UEFI firmware verifies the digital signature of each boot component against a database of approved keys. Any boot component that isn't properly signed, or isn't signed at all, isn't allowed to run.

If this occurs, the VM instance will show an error state in the GCP console, and the VM instance's serial console log will have an entry containing the strings UEFI: Failed to load image and Status: Security Violation, along with a description of the boot option that failed. To troubleshoot the failure, disable Secure Boot by using the instructions in Modifying Shielded VM Options so that you can boot the VM instance, diagnose and resolve the issue, then re-enable Secure Boot.

Virtual Trusted Platform Module (vTPM)

A vTPM is a virtualized trusted platform module, which is a specialized computer chip you can use to protect objects, like keys and certificates, that you use to authenticate access to your system. The Shielded VM vTPM is fully compatible with the Trusted Computing Group (TPM) library specification 2.0 and uses BoringSSL, which is FIPS 140-2 L1 validated.

The Shielded VM vTPM enables Measured Boot by performing the measurements needed to create a known good boot baseline, called the integrity policy baseline. The integrity policy baseline is used for comparison with measurements from subsequent VM boots to determine if anything has changed.

You can also use the vTPM to protect secrets through shielding or sealing. See the Go-TPM project on GitHub for Go language examples that illustrate how to use a vTPM for this purpose.

To enable shielding, you might want to get the vTPM endorsement key certificates. You can use these certificates to encrypt data so that only the vTPM can read it, and verify signatures that the vTPM makes. For more information, see Getting vTPM Endorsement Key Certificates.

Measured Boot

During Measured Boot, a hash of each component (for example, the firmware, bootloader, or kernel) is created as the component is loaded, and that hash is then concatenated and rehashed with the hashes of any components that have already been loaded, as illustrated below:

Measured Boot process.

This information identifies both the components that were loaded, and their load order.

The first time you boot a VM instance, Measured Boot creates the integrity policy baseline from the first set of these measurements, and securely stores this data. Each time the VM instance boots after that, these measurements are taken again, and stored in secure memory until the next reboot. Having these two sets of measurements enables integrity monitoring, which you can use to determine if there have been changes to a VM instance's boot sequence.

Integrity monitoring

Integrity monitoring helps you understand and make decisions about the state of your VM instances.

Integrity monitoring relies on the measurements created by Measured Boot, which use platform configuration registers (PCRs) to store information about the components and component load order of both the integrity policy baseline (a known good boot sequence), and the most recent boot sequence.

Integrity monitoring compares the most recent boot measurements to the integrity policy baseline and returns a pair of pass/fail results depending on whether they match or not, one for the early boot sequence and one for the late boot sequence. Early boot is the boot sequence from the start of the UEFI firmware until it passes control to the bootloader. Late boot is the boot sequence from the bootloader until it passes control to the operating system kernel. If either part of the most recent boot sequence doesn't match the baseline, you get an integrity validation failure.

If the failure is expected, for example if you applied a system update on that VM instance, you should update the integrity policy baseline. Updating the integrity policy baseline sets the baseline to the measurements captured from the most recent boot sequence. If it is not expected, you should stop that VM instance and investigate the reason for the failure.

You can view integrity reports in Stackdriver Monitoring, and set alerts on integrity failures. You can review the details of integrity monitoring results in Stackdriver Logging. For more information, see Monitoring Integrity on Shielded VM Instances.

Integrity monitoring events

Shielded VM creates log entries for the following types of events:

  • clearTPMEvent: Identifies if the vTPM has been cleared, which deletes any secrets stored in it. This doesn't affect any aspect of Shielded VM, so you will only care about this if you use the vTPM to shield sensitive data as described in Virtual Trusted Platform Module (vTPM).
  • earlyBootReportEvent: Identifies whether the early boot sequence integrity check passed, and provides details on the PCR values from the baseline and the most recent boot sequence that were compared to make that determination.
  • lateBootReportEvent: Identifies whether the late boot sequence integrity check passed, and provides details on the PCR values from the baseline and the most recent boot sequence that were compared to make that determination.
  • setShieldedVmIntegrityPolicy: Logged each time you update the integrity policy baseline.
  • shutdownEvent: Logged each time the VM instance is stopped.
  • startupEvent: Logged each time the VM instance is started. The interesting information in this event is the bootCounter value, which identifies how many times this instance has been restarted.
  • updateShieldedVmConfig: Logged each time you enable or disable one of the Shielded VM options.

The typical event progression you see in the logs is startupEvent, earlyBootReportEvent, lateBootReportEvent, and eventually shutdownEvent, all with the same bootCounter value to identify them as describing the same VM instance boot sequence.

If you update the integrity policy baseline in response to an expected integrity failure on a VM instance, you will see additional earlyBootReportEvent and lateBootReportEvent events that describe the new integrity policy baseline measurements. The following example shows the expected sequence:

  • startupEvent
  • earlyBootReportEvent that compares original baseline to latest boot sequence (passes)
  • lateBootReportEvent that compares original baseline to latest boot sequence (fails)
  • setShieldedVmIntegrityPolicy when you update the integrity policy baseline, which sets the baseline to the measurements captured from the latest boot sequence
  • earlyBootReportEvent that compares new baseline to latest boot sequence (passes)
  • lateBootReportEvent that compares new baseline to latest boot sequence (passes)

Windows

earlyBootReportEvent

The important information in earlyBootReportEvent is in the earlyBootReportEvent section, which contains the following sections and elements:

  • actualMeasurements: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are capture in the policyMeasurements section) to determine if there has been any change in the VM instance boot sequence. The actualMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts.
    • 2: Contains the value for PCR5, which contains information about the disk's GUID partition table. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 3: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
  • policyEvaluationPassed: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.

  • policyMeasurements: Contains the PCR values for the integrity policy baseline The policyMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts.
    • 2: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.

To learn how to use earlyBootReportEvent PCR values to diagnose a boot integrity validation failure, see Determining the cause of boot integrity validation failure.

lateBootReportEvent

The important information in lateBootReportEvent is in the lateBootReportEventsection, which contains the following sections and elements:

  • actualMeasurements: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are capture in the policyMeasurements section) to determine if there has been any change in the VM instance boot sequence. The actualMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts.
    • 2: Contains the value for PCR5, which contains information about the disk's GUID partition table. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 3: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
    • 4: Contains the value for PCR11, which contains information about BitLocker Drive Encryption access control.
    • 5: Contains the value for PCR12, which contains information about data events. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 6: Contains the value for PCR13, which contains information about Windows kernel and boot drivers.
    • 7: Contains the value for PCR14, which contains information about Windows boot authorities.
  • policyEvaluationPassed: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.

  • policyMeasurements: Contains the PCR values for the integrity policy baseline The policyMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the UEFI boot manager code and boot attempts.
    • 2: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
    • 3: Contains the value for PCR11, which contains information about BitLocker Drive Encryption access control.
    • 4: Contains the value for PCR13, which contains information about Windows kernel and boot drivers.
    • 5: Contains the value for PCR14, which contains information about Windows boot authorities.

To learn how to use lateBootReportEvent PCR values to diagnose a boot integrity validation failure, see Determining the cause of boot integrity validation failure.

Linux

earlyBootReportEvent

The important information in earlyBootReportEvent is in the earlyBootReportEvent section, which contains the following sections and elements:

  • actualMeasurements: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are capture in the policyMeasurements section) to determine if there has been any change in the VM instance boot sequence. The actualMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the operating system shim.
    • 2: Contains the value for PCR5, which contains information about the disk's GUID partition table. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 3: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
  • policyEvaluationPassed: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.

  • policyMeasurements: Contains the PCR values for the integrity policy baseline The policyMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the operating system shim.
    • 2: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.

To learn how to use earlyBootReportEvent PCR values to diagnose a boot integrity validation failure, see Determining the cause of boot integrity validation failure.

lateBootReportEvent

The important information in lateBootReportEvent is in the lateBootReportEventsection, which contains the following sections and elements:

  • actualMeasurements: Contains the platform configuration register (PCR) values for the latest boot sequence. The PCR values are what identify the boot components and component load order used by the latest boot sequence, and are what are compared to the integrity policy baseline (whose values are capture in the policyMeasurements section) to determine if there has been any change in the VM instance boot sequence. The actualMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the second stage boot loader and the kernel.
    • 2: Contains the value for PCR5, which contains information about the disk's GUID partition table. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 3: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.
  • policyEvaluationPassed: Identifies whether the given section of the boot sequence passed verification against the integrity policy baseline.

  • policyMeasurements: Contains the PCR values for the integrity policy baseline The policyMeasurements section contains the following elements:

    • 0: Contains the value for PCR0, which contains information about firmware components. This PCR is not implemented and instead contains a static value. It is not used when validating the latest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about the second stage boot loader and the kernel.
    • 2: Contains the value for PCR7, which contains information about the instance's Secure Boot policy.

To learn how to use lateBootReportEvent PCR values to diagnose a boot integrity validation failure, see Determining the cause of boot integrity validation failure.

Cloud Identity and Access Management authorization

Shielded VM uses Cloud IAM for authorization.

Shielded VM operations use the following Compute Engine permissions:

  • compute.instances.updateShieldedVmConfig: Allows the user to change the Shielded VM options on a VM instance.
  • compute.instances.setShieldedVmIntegrityPolicy: Allows the user to update the integrity policy baseline on a VM instance.

Shielded VM permissions are granted to the following Compute Engine roles:

  • roles/compute.instanceAdmin.v1
  • roles/compute.securityAdmin

You can also grant Shielded VM permissions to custom roles.

Was this page helpful? Let us know how we did:

Send feedback about...

Documentation