Device Health Attestation: Age of Compliance

Device Health Attestation: Age of Compliance

Some time ago I wrote a blog about conditional access, the PRT, the “DeviceID” and the “iscompliant” attribute… That blog triggered me somehow, even more, to learn the whole “being compliant” process. While reading and learning the flows I decided to create a separate blog about the Device Health Attestation and this time with all strings attached.. I need to warn you, this blog will be a little bit more technical than I first wanted it to be but I needed to explain it all!.

And another warning… while writing this blog, I got addicted to TPM attestation and white-glove issues!

I am going to divide this blog into multiple parts

  1. The Issue
  2. The Compliance Policies
  3. Device Health Attestation (DHA)
  4. DHA Components
  5. DHA Flow’s
  6. DHA Logs
  7. A Reboot to fix it all?

1.The Issue

Before I am going to show you all the information we need to have to get a good understanding of how Health Attestation works, we need to take a look at the issue first to connect all the strings.. ehhh dots later on.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

As shown above, the device is not compliant with the compliance policies we configured. Our device does not have encryption turned on. Let’s take a look at the MS docs…

Afbeelding met tekst  Automatisch gegenereerde beschrijving

So let’s check if that’s the cause

Afbeelding met tekst  Automatisch gegenereerde beschrijving

As shown below the protection is on and fully encrypted! ( I know what the issue is of course, but I guess we need to keep reading to get to the flow)

2.The Compliance Policies

Let’s check the Intune Compliance policy! We are trying to divide each compliance setting into a different policy so troubleshooting it or changing one is somehow easier (in my opinion.. don’t hate me for it)

But that’s not the only reason, want to know why else we have multiple policies? Please stick with me and read further.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

After we have opened the Compliance policies pane, let’s open the “RequireDeviceHealth” Policy. We notice 2 things:

“Windows Health Attestation Service evaluation rules” and “Require Bitlocker”

Instead of only “encryption” ?

Why should we choose the “Require Bitlocker” option? That’s easy because using the “Require Bitlocker” options is way more robust as it leverages the Device Health Attestation to validate the Bitlocker status at the TPM level.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Open Intune and let’s take a look at the Intune Devices Monitor to determine if the device is compliant with the Bitlocker Compliance policies we configured. Did you notice that name again? Windows Health Attestation report!

3.The Device Health Attestation (DHA)

So device health attestation it is! And nothing more… Guess I am done writing?….

Let’s focus on the word “Attestation” first. It’s all about trust. Attestation is a critical component for establishing trust and trust is necessary. Attestation runs at the TPM level and will make sure that the information is secured, is verified and has not been tampered with.

Now let’s add the word Remote to Attestation. When a client’s needs to authenticate and verify its hardware and software to a remote server to be a trustworthy client, the Remote Attestation method is used.

Now we know what (remote)attestation is, shall we take a good look at DHA to determine how it works?

It’s very important to understand that the options you have to protect your device against malware attacks are focused on prevention.

Of course, prevention is a good thing, but how are we going to monitor if all the security measures are still in place and doing some prevention? To make sure the devices are compliant with the (BitLocker) settings we configured, we can create compliance policies. Those compliance policies must be compared/checked from the device by some remote service.

That’s where Device Health Attestation kicks in. With the use of DHA, you can monitor / report device compliance and take corrective actions when the device is not compliant. This whole process is based on TPM protected data.

Let’s briefly explain how this happens. When a device is booting Information about the firmware, boot process, and software measurements are logged inside the TPM. This information *TCG log and PCRs values are sent to the Device Health Attestation Service. The DHA-Service will determine what changes have occurred on the device and if the device is still in a healthy state and has not been tampered with.

*TCG log (AKA Windows Boot Configuration Logs. These Logs contain all the measurements throughout the whole OS boot process)

But if we want to enforce some rules (Conditional Access) we need to have an MDM solution (like Intune). Otherwise, we only have some health information and nothing more! Please read my blog about when and how you could make sure your AADJ or AADR devices can be compliant!

When you want to access data from an MS365 App, the device could contact Intune through the MDM agent with the use of the Device Health Attestation Configuration Service Provider (DHA-CSP)

Intune then will inspect the health XML report (DHA-Report) generated by the DHA-Service for that device (Which the device had to send earlier to the DHA-Service itself) and can determine if the device is healthy (compliant).

After Intune has made its decision it will update the “iscompliant” attribute in Azure Ad. If you want to read some more on this topic please visit another blog from me

4.Device Health Attestation Components:

Now we have discussed/introduced the DHA a little bit, let’s take another good look at what’s inside. I will divide this part up into multiple subparts to give you a better understanding.

4.1 TPM, PCR, EK, SRK and A(I)K 

4.2 Device Health Attestation CSP (DHA-CSP)

4.3 Device Health Attestation Service (DHA-Service)

4.1 TPM, EK, PCR, STORAGE Root Key and AIK (QUOTE) 

As mentioned earlier the DHA logs the measurements in various sections. During each step of the boot process, all these measurements are stored inside the PCR’s ( Platform Configuration Registers). What do we need for this to happen? Let’s explain it a little bit more and take a look at the first flow.

Process to Create Evidence of Boot Software and Configuration Using TPM.

TPM

A Trusted Platform Module (TPM) is a hardware component that provides unique security features. It’s an international standard for a secure cryptographic coprocessor. The TPM will protect your device against unwanted tampering.

Windows 10 makes use of the security characteristics of the TPM for measuring the boot integrity sequence. With that information, the TPM could unlock the BitLocker protected drives automatically. The TPM is also used for protecting credentials (Like example the PRT) or for Health Attestation.

When your TPM enabled device is booting, a measurement of different components is performed. A few examples, it will check the firmware, UEFI drivers, CPU microcode, and also all the Windows 10 drivers whose type is Boot Start. When it’s done checking, the measurements are stored in the TPM PCR registers, while the details of all events (executable path, authority certification, and so on) are available in the TCG log.

Let’s also take a look at a nice picture of what’s inside the measured boot.

So to resume, the TPM stores measured boot information in a secure way but you will need something else to deliver the judgment if the measurements are evil (not compliant)

EK

The Endorsement Key (EK) is one of the three types of keys which can be used by the TPM. It can be best described as an Encryption (RSA) key that is permanently stored in the TPM when the device is being manufactured.

The EK’s function is to prove you are communicating to a real identity, the TPM. So you could say the EK is the root of the TPM’s identity, without it the TPM could not operate. 

When there is a TPM operation that involves sending sensitive parameters, it can make use of the public part of the EK (EKPub).

When there is a TPM operation that involves data decryption the private part of the EK (EKpriv). The private part (EKPriv) never leaves the chip. The EKPriv is also used to create secondary keys, just like the AIK key!

It’s also good to know that the EK contains 1 or 2 certificates.

The first one: is the endorsement certificate and is burned to the device when it’s manufactured or when the device first reaches out to the online service (OOBE).

The second one: is the Platform Certificate. This certificate will be supplied by the hardware vendor to show the TPM belongs to a specific device

You can check out the Public Key with this PowerShell command

PCR

PCRs (Set of registers) are a key ingredient of the TPM. The PCR’s are primarily used to cryptographically measure the software and hardware state when booting the device. The PCR Banks will represent the platform software state and the history of the configurations that have run on the device until now.

So in some simple words: PCR are a part of the memory in the TPM, used to store sensitive information about the measurements. This information will be reset when the device reboots

Windows uses these PCR banks to measure the boot parameters. When the device is booting it starts with a zero (hash value), that “object zero” is totally/absolutely trusted and becomes the Core root of trust for measurement (CRTM)

Every next step/component the boot process goes to is cumulative and will be measured by taking the hash and recording/extending it in the PCR’s with. This is done by this TPM command  

EXTEND: PCR[n] = Hash { PCR[n] || data }

As mentioned earlier the PCR’s job is to ensure that no one manipulated the TCG log. Let’s take a look at some PCR’s that will be measured during boot

Afbeelding met tekst  Automatisch gegenereerde beschrijving

So, PCR 11 is used for BitLocker. You could check it out yourself by opening a “cmd” and execute this command: manage-bde -protectors -get c:

Afbeelding met tekst  Automatisch gegenereerde beschrijving

AK (AIK) 

Before we can use TPM attestation, we need to have the AIK. This certificate will be delivered by an online CA( TPM entity) As told in the TPM and PCR parts, all of the information is stored inside the TPM. But how are we going to make sure the information inside the TPM is not tampered with when it’s being copied from the TPM to the CPU. Just like always, we need to sign the PCRs! (data/measures) 

Before the TPM sends the data to the CPU the TPM provides this TPM command.

(TPM_Quote)

QUOTE: S = Signkey { PCR[n], nonce, …}

It will request the “operation of signing”(quote) of the PCR data. I guess it’s all in the name because we need a special key to sign the data. Unfortunately, the Endorsement Key (EK) can’t sign it. Because as we noticed earlier, the EK can only encrypt data, not sign it.

Luckily we have the Attestation ‘Identity Keys’ (AK/AIK). Their dedicated purpose is, is to sign the information/quote. This will prove the data was coming from inside the TPM and is not tempered with.

But I am not done yet, because you still want to be sure the AIK belongs to the same TPM as the EK, this process is done by the credential activation protocol. Credential activation makes sure the EK is on the same device as the AK.

So the resume. A signed report can be created of the PCR’s values. With this report (DHA-Report) a remote server like Intune could determine the trust state of the device.

STORAGE Root Key (SRK)

There isn’t much to tell about the storage root key (SRK) except that it is also an asymmetric key pair (RSA with a minimum of 2048 bits length). This SRK has one big job to do, it needs to make sure those RSA keys can’t be used without the TPM itself. You could say the SRK is the mother of protection i guess.

4.2 Device Health Attestation CSP (DHA-CSP)

First, let me explain what a Configuration Service Provider (CSP) is. A CSP is a component that has a connection with the Windows Intune client and provides a published protocol for how Intune can configure settings (set/get/delete etc) and manage Windows-based devices. Of course, other MDM systems are making use of these CSP as well.

The Device Health Attestation configuration service provider (DHA-CSP) gives you the possibility to check if a device is booted to a trusted and compliant state. The DHA-CSP also gives you the power to take actions when the device does not fit in with the compliance policies

Let’s take look at what the Device HealthAttestation CSP is responsible for:

  • It will collects device boot logs, TPM audit trails and the TPM certificate (DHA-BootData) from a managed device
  • It will forward the DHA-BootData to the DHA-Service
  • The DHA-CSP can receive an encrypted blob (DHA-EncBlob) from DHA-Service
  • The DHA-CSP will also receive attestation requests (DHA-Requests) from Intune and replies with Device Health Attestation data (DHA-Data)

During a health attestation session, the Health Attestation CSP forwards the TCG logs and PCRs values that are measured during the boot, by using a secure communication channel (SSL/TLS) to the Health Attestation Service.

4.3 Device Health Attestation Service (DHA-Service)

The core purpose of the DHA-Service is to evaluate the set of health data (TCG log and PCR values) it received. When this data is received it also needs to check if the reports are signed by an (again) trustworthy AIK. Based on that health data it will determine what changes have occurred on the device. When it’s done it will generate an encrypted health blob and sends it back to the device

Afbeelding met tekst  Automatisch gegenereerde beschrijving

So resume the DHA-service(has.spserv.microsoft.com) is the remote reporting server side and the DHA is the client side

The DHA-Service provides the following information to Intune about the health of the device:

  • Secure Boot enablement
  • Boot and kernel debug enablement
  • BitLocker enablement
  • VSM enabled
  • Signed or unsigned Device Guard Code Integrity policy measurement
  • ELAM loaded
  • Safe Mode boot, DEP enablement, test signing enablement
  • Device TPM has been provisioned with a trusted endorsement certificate

5.Device Health Attestation Flow

Now we have a good understanding of each part that is required to report the device as compliant, first, take a look at an easy flow to begin with… to get a feel for it.

The health attestation protocol can be initiated asynchronously after boot once the TPM has been provisioned or it can be initiated as a part of a service request by Intune (synchronous).

figure 10.

When you want to read more about this flow, please visit my blog I also mentioned earlier.

The Death of Compliance – Call4Cloud

It will show you a more detailed approach to how this flow works and what it requires.

Now let’s step it up a notch and take a look at a more detailed approach.

Windows 10 Device Health Attestation (DHA) and MS365

And some information that goes with the flow. As mentioned earlier It depends on if the flow is Asynchronous or Synchronous.

Please beware!: When a user wants to access data from the Office 365 apps the process will be initiated by Intune. (Synchronous). When this happens the first parts (1.1 and 1.2) are taking place after 2.2 and 2.3 will be initiated from the device instead from Intune

Asynchronous Flow

1.1 After the device boots a task will be triggered (TPM-HASCertRetr) and it will forward the *DHA-Boot-Data to the DHA-Service. 

* DHA-Boot-Data: TCG Log (Windows Boot Configuration Logs: WBCL), the related boot state Data, the AIK Certificate and the PCR Bank values

1.2 After the TCG, the AIK certificate and the boot state are received by the DHA-Service, the DHA-Service will validate the data and checks if it is signed by a valid and trustworthy AIK certificate. After the DHA-service has validated it, it will also check if the TCG logs correspond with the reported PCR values.

After everything is validated it will send back an encrypted summary report *blob to the device (DHA-CSP) together with a Device Health Certificate.

*DHA-encBlob –> Device Health Status, Boot Counter and the Device ID

2.1 When Intune needs to get the *DHA-Report it will initiate the DHA Data validation Session to start querying the health state of the device. 

*DHA-Report: It’s a XML report with the Bitlocker status/Secureboot/PCR[0] etc in it
 

2.2 The device (MDM Client) will inform Intune that the DHA-Validation-Data is ready for transport.

2.3 After Intune is informed that the data is ready, Intune will send a *Nonce and a request to the device to get collect the health data. 

*Nonce: It’s a random number used in cryptographic communication. It makes sure Intune protects the device health attestation communications from man-in-the-middle type (MITM) attacks)
 

2.4 The device will send the DHA validation Data (Health Data) to Intune
 

3.1 Intune will forward the data to the DHA-Service, but while forwarding it will also add a Nonce. 
 

3.2 The DHA-Service will review and validate the Health data and will send back the DHA-report to the MDM. 

4.1 After MDM receives the report, MDM will evaluate the compliance based on the configured compliance policies and will decide if the device is healthy (or not). 
 

4.2 Depending on the outcome, Intune will set the “iscompliant” device attribute in AAD to True or False 
 

5.1 If the user wants to open an Office 365 app it will trigger a token acquisition. 
 

5.2 After the token acquisition it will request an access token for the specific service by using the PRT. 
 

5.3 Azure / Conditional access will check if the device is who it says it is by checking the “deviceid” and will validate the device compliance state (iscompliant attribute) and will issue an office 365 access token if the user is authorized and of course only when the device is compliant. 
 

5.4 The Device will forward/use the token for the Office Apps. 
 

6   The Office App will present the token to the Office 365 Service to get access and trusted communication is born. 

Synchronous Flow

2.1 Intune send a request to the device to get the *DHA-Report it will initiate the DHA Data validation Session to start querying the health state of the device. 

*DHA-Report: It’s a XML report with the Bitlocker status/Secureboot/PCR[0] etc in it
 

2.2 The device (MDM Client) will inform the MDM that the DHA-Validation-Data is NOT ready for transport. The MDM will ask the client to send the DHA-boot data to the DHA-Service

1.1 The device will be forced to forward the *DHA-Boot-Data to the DHA-Service. 

* DHA-Boot-Data: TCG Log (Windows Boot Configuration Logs: WBCL), the related boot state Data, the AIK Certificate and the PCR Bank values

1.2 After the TCG, the AIK certificate and the boot state are received by the DHA-Service, the DHA-Service will validate the data and checks if it is signed by a valid and trustworthy AIK certificate. After the DHA-service has validated it, it will also check if the TCG logs correspond with the reported PCR values.

After everything is validated it will send back an encrypted summary report *blob to the device (DHA-CSP) together with a Device Health Certificate.

*DHA-encBlob –> Device Health Status, Boot Counter and the Device ID

2.3 The device will inform Intune that the data is ready for pickup. Now Intune knows the data is ready for pickup it will send a *Nonce and a request to the device to get collect the health data. 

*Nonce: It’s a random number used in cryptographic communication. It makes sure Intune protects the device health attestation communications from man-in-the-middle type (MITM) attacks)
 

2.4 The device will send the DHA validation Data (Health Data) to the MDM 
 

3.1 The MDM will forward the data to the DHA-Service, but while forwarding it will also add a Nonce. 
 

3.2 The DHA-Service will review and validate the Health data and will send back the DHA-report to the MDM. 


4.1 After MDM receives the report, MDM will evaluates the compliance based on the configured compliance policies and will decide if the device is healthy (or not). 
 

4.2 Depending on the outcome, Intune will set the “iscompliant” device attribute in AAD to True or False 
 

5.1 If the user wants to open an Office 365 app it will trigger a token acquisition. 
 

5.2 After the token acquisition it will request access token for the specific service by using the PRT. 
 

5.3 Azure / Conditional access will check if the device is who it says it is by checking the deviceid and will validate the device compliance state (iscompliant attribute) and will issue an office 365 access token if the user is authorized and of course only when the device is compliant. 
 

5.4 The Device will forward/use the token for the Office Apps. 
 

6   The Office App will present the token to the Office 365 Service to get access and trusted communication is born. 

6.Device Health Attestation event log

IF you are interested in some event logs go, you will find them in (of course) the measured boot log folder. These logs can be used to decode the measured boot logs to track PCR changes

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Please note: When there aren’t any log files in the above folder, please check out this registry key: PlatformLogRetention in the registry: HKLM\SYSTEM\CurrentControlSet\Services\TPM . If it’s set to zero, I guess you know what that means…it’s off. If you want to enable it, change it back to 0xffffffff

But the logs are pretty useless, except if you download this PowerShell module and convert them. Please visit this Github website and download the Module and take a look for yourself

TCGLogTools/README.md at master · mattifestation/TCGLogTools · GitHub

7.A Reboot to fix it all?

I guess after reading how the DHA works, we also know that the BitLocker compliance state is captured during boot. When you enable BitLocker after the first boot, the device will still not be compliant as the measured boot state (DHA-Boot-Data) does not have the knowledge that Bitlocker was enabled.

So the only thing left to fix it all, to make sure Bitlocker is enabled is just to reboot your device to initiate the measurement. After the device has reported that BitLocker is enabled from the measured boot date, you are good to go!

Or????????

Like I showed in the beginning we are making use of multiple compliance policies. Maybe changing the Bitlocker Compliance policy to mark the device not compliant after 1 or 2 days?

Conclusion 

First a small resume about compliancy and the DHA:

Intune determines if the device is Compliant by using the DHA-Report which Intune received from the DHA-Service. When the device is Compliant Intune will change the “iscompliant” attribute to “true”. The DHA-Report which Intune received is leaning on the DHA-Validation-Data which the device received from the DHA-Service when it transferred the DHA-Boot-Data.

Now that’s clear, let’s finish this blog

It was pretty fun to get a good and full understanding of how DHA works and every step it goes through.  I hoped it wasn’t too much information and you liked reading it just as much as I did while writing it…  Now I need to rest

That Avengers Post-Credit Shawarma Scene Was Somehow Inspired By An 'Angel'  Death

*Source used: [MS-DHA]: Device Health Attestation Protocol | Microsoft Docs

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  19  =  21