Understanding Device Health Attestation Intune Device Compliance Check

In this post, I will discuss Device Health Attestation (DHA) and its role in the Intune device compliance check. Let’s dive into the Intune Device Compliance Check and DHA.

Intune device compliance is a check mechanism for whether managed devices meet the specified security requirements as per the organization’s security policy. Based on a device’s compliance state, you can enforce an Azure AD Conditional Access policy to restrict access to sensitive data from that device.

For example, say you have a compliance policy deployed that specifies the device must have a 6-digit PIN set to be termed complaint. If the device doesn’t meet the specified requirement, it will just be labelled non-compliant.

However, it won’t force the user to create it. If you want to enforce something to be implemented at the device level, you would require configuring the corresponding Device Configuration policy. Thus in other words, we can say that compliance is just an evaluation of the implementation of configuration policy at the device level. (Well, this is debatable!)

Index
Device Health Attestation – What is it?
Device Health Attestation – Protocol and Implementation
Windows Generalized Boot Flow – Understanding the Necessity for DHA
Device Health Attestation and Intune Compliance – Relation?
Understanding the components of DHA Based on which it functions
Device Health Attestation Dependency – Secure Boot?
Device Health Attestation Dependency – TPM
Device Health Attestation Dependency – Code Integrity
The Device Health Attestation Service and Intune Schema Diagram
DHA Report – What does it contain?
Conclusion – Understanding Device Health Attestation Intune Device Compliance Check

Intune compliance is just an evaluation and not enforcement of the security requirements.

It’s all good until this point. But here is the catch: Intune restriction policies are applied after the device completes boot and Windows is functional.

What if the Windows boot process itself is compromised due to a bootkit/rootkit?

In this scenario, depending on the restrictions you have implied, the device compliance evaluation will return a positive report, and the device will be marked compliant, based on which, if you have CA policy enabled, it will allow access to protected data.

BUT WHAT ABOUT THE BACKDOOR THAT IS ALREADY CREATED DURING THE BOOT PROCESS ? 

Device Health Attestation – What is it?

Here comes the rescue: the Windows Device Health Attestation (DHA), a feature released with the first version of Windows 10 (v1507 or codename TH1), ensures that the device boot phase is not compromised and that the device boots to a trusted state.

DHA in itself does not secure the Windows boot process.

It is a reporting service that considers the OS boot’s conditions to prepare a report. A remote server then attests this report for trust. Based on this, a device management service like Intune can determine if the device is in the trusted state to be marked as compliant.

Device Health Attestation – Protocol and Implementation

DHA is a server-client protocol implemented at the device end in Windows 10 via the Device HealthAttestation-csp.

It enables a device to submit the boot parameters information to a remote reporting service called Device Health Attestation Service (DHA-Service), the server-side implementation of DHA, to get an encrypted BLOB back that is cached to be made available to an MDM service provider.

The DHA protocol integrates with MS-MDM protocol framework and utilises the attestation capability of the device TPM chip. Below is an illustration of the protocol stack underlying the concept.

Windows Generalized Boot Flow – Understanding the Necessity for DHA

• When we power on the device, it conducts a Power On Self-Test (POST)—a diagnostic testing sequence initiated by the firmware to check its components and detect whether the system can continue to the next stage.

• Based on POST evaluation, EFI initializes the hardware components. It next reads the boot information from CMOS and invokes the Windows Boot Manager, which reads the Boot Configuration Data to invoke the Windows Boot Loader. The Boot Loader, in turn, loads the OS kernel to the RAM, and the Kernel takes over from here.

• During initialization, the kernel loads all the system drivers, third-party drivers, and system files. At this point, Windows booting is complete. The in-built/third-party Anti-Malware service is started, and the Windows Login page is displayed.

Studying the above flow lets you understand how insecure the Windows boot process is.

Due to the lack of any security measures in the above flow, it is very easy to modify the boot parameters and run malicious code during the system boot via rootkits/bootkits, which can make the system boot to an unstable state or compromise run-time security. This is a serious threat if we consider the impacts in corporate scenarios.

Device Health Attestation and Intune Compliance – Relation?

This is where Device Health Attestation and Intune integrate to offer a more secure device compliance evaluation. This provides you with the peace of mind that the devices in your organization are compliant with required security and running in a trusted device state.

As you can see from the above snap reference, if your compliance policy requires any of the above parameters to be evaluated, this compliance evaluation will depend on the DHA service.

Code Integrity depends on Secure Boot to work

As such, if you have only marked Code Integrity as Require but not Secure Boot at the device end, you would still need to enable the Secure Boot feature in UEFI for the device evaluation to report as a complaint.

Understanding the components of DHA Based on which it functions

As I have mentioned earlier above, DHA in itself does not secure the boot process. For that, it depends on the below features

Device Health Attestation Dependency – Secure Boot?

Secure Boot is not a component of DHA, but a core dependency of it…

Secure Boot is a Unified Extensible Firmware Interface (UEFI) 2.3.1 specification feature. By validating their digital signatures, it detects tampering with boot loaders, key operating system files, and unauthorized option ROMs. Detections are blocked from execution.

It is based on the Public Key Infrastructure (PKI). Through image authentication before execution, Secure Boot reduces the risk of pre-boot malware attacks such as rootkits and boot kits.

Device Health Attestation Dependency – TPM

A Trusted Platform Module (TPM) is a secure cryptoprocessor implemented in the device hardware as a discrete/integrated chip or as a firmware solution. However, from the security perspective, discrete TPM provides the highest security, which is what we refer to when we mention the TPM 1.2 or TPM 2.0 specification.

TPM contains Platform Configuration Register (PCR) banks, an essential feature that allows it to record (measure) software and hardware state cryptographically.

Well, this deserves an explanation of its own…

Let’s say that there are three processes (code blocks) – A, B and C. This is like a trust building. C is trusted to be executed if B is trusted, and B is trusted to be executed if A is trusted. But A is the root, who will measure it for trust. Thus A becomes implicitly trusted to form the Root of Trust for Measurement (RTM).

For a device with TPM, the TPM code, usually the first code executed on the main processor, becomes the Core Root of Trust for Measurment (CRTM), implicitly trusted to bootstrap the process of building a measurement chain for subsequent attestation of other firmware and software executed on the computer system.

The TPM Boot measurement process in a nutshell…

As we power on a system, CRTM initiates the measurement to measure a digitally signed module called ACM (Auth’ed Code Module) which is provided directly by the chipset manufacturer. The processor validates the signature and integrity of the signed module, and if it is valid, it starts executing it. The ACM then measures the first UEFI code module, which can make various additional measurements.

The ACM and BIOS code module measurements are extended to PCR 0. Then the BIOS measures additional components into PCRs, from PCR-0 to PCR-7, as per the TCG PC Client PCR Bank specification as shown below

Windows uses these PCR banks to measure boot parameters. The PCR 0- 7 banks have well defined values for the boot process against which the boot is measured.

The PCR update calculation is a one-way hash. Cryptographically, a PCR value can be extended as below, but once extended can never be rolled back to the previous value.

 PCR new value = SHA Digest of (PCR old value || data to extend)

Sample PCR7 contents as extracted from my system.

These PCRs can then be read to report their state or can be signed to return a more secure report, called an attestation.

The TPM never passes judgment on the measurements. Internally, it doesn’t know which measurements are good or bad, more or less secure.

At the time of measurement, TPM PCRs just record values. Security or trust comes later, when a remote party asks for a signed attestation (quote) of the values and judges their trustworthiness. 

PCRs can also be used in an extended authorization policy to restrict the use of other objects. Well yes, this is going towards Bitlocker encryption as enforced from Intune – I will cover it in a seperate post some other day!

Device Health Attestation Dependency – Code Integrity

Code Integrity, implemented in Windows 10 via DeviceGuard-CSP, is the continuation of Secure Boot as it conitnues to measure driver images and any other software application as loaded by the OS kernel as the Boot phase moves from UEFI to Kernel Initialization.

It is a Virtualization-Based Security (VBS) Local Security Authority(LSA) function using Hypervisor Code Integrity (HVCI) drivers and compliant UEFI in conjunction with the Windows 10 Professional/Enterprise/Education Edition operating system.

With appropriate hardware, Device Guard can use the new virtualization-based security introduced with Windows 10 v1709 (available in Enterprise and Education desktop SKUs and in all Server SKUs) to isolate the Code Integrity service from the Microsoft Windows kernel itself. In this case, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.

The Device Health Attestation Service and Intune Schema Diagram

The above shows the High Level Schematic representation of the DHA service and Intune working in conjunction. Lets break it down to understand the flow in details below

Device – DHA Service – Intune Compliance Evaluation

1. MDM service initiates the DHA Validation Session
2. Device alerts MDM service that DHA-Validation-Data is ready for pickup
3. The MDM service sends get request to retrieve the DHA-Validation-Data
4. Device sends the requested data to MDM service
5. The MDM service adds a “nonce” to the payload and forwards the DHA-Validation-Data as retrieved to Health Attestation Service
6. The HAS evaluates the DHA-Validation-Data and sends DHA-Report back to MDM service

If the device do not have the DHA-Validation-Data ready, it sends a Not Ready response to the MDM service alerting that the requested data is not available. Synchronoulsy, it starts a session with the DHA service to get the data to be provided to the MDM service at later stage.

Device – DHA Service Flow

• Device sends DHA-Boot-Data to DHA Service when it boots or reboots
• DHA Service returns an encrypted blob DHA-Validation-Data to the device.

NOTE:

A device is deemed compliant by an MDM service based on the DHA-Report as obtained from DHA service. This DHA-Report is dependent on DHA-Validation-Data which the device obtains from the DHA service by sending the DHA-Boot-Data.

The DHA-Boot-Data is collected during the initial system boot. So any changes made to boot parameters post system boot won’t be captured to be sent to DHA service.

As such, if any changes are made, especially when it comes to

• Code Integrity
• Bitlocker
• Secure Boot

The end user needs to restart the system to initiate a new DHA-Boot-Data capture to be sent to the DHA Service.

In Windows 10, in general, the shutdown as performed actually puts the system in an advanced sleep state. This is the secret behind the super fast boot times we get, but the tradeoff is that this does not actually boot the system from the beginning to initiate a new capture.

DHA Report – What does it contain?

The report contains the state/status of the below device parameters

• AIK Present
• Bit Locker Status
• Boot Debugging Enabled
• Boot Manager Rev List Version
• Code Integrity Enabled
• Code Integrity Rev List Version
• DEP Policy
• ELAM Driver Loaded
• Issued At
• Kernel Debugging Enabled
• PCR
• Reset Count
• Restart Count
• Safe Mode Enabled
• SBCP Hash
• Secure Boot Enabled
• Test Signing Enabled
• VSM Enabled
• WinPE Enabled

Conclusion – Understanding Device Health Attestation Intune Device Compliance Check

If you have read to this point, you should now have a better and clearer understanding of the Device Health Attestation service and its usage with Intune for compliance evaluation.

If you like this, you will likely like my other articles on Intune. Please do check them out if and when your time permits.

Till then, read something every day, learn something every day!

Resources

• Device Health Attestation (Microsoft Docs)
• Learn Intune Beginners Guide MDM MAM MIM

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Joymalya Basu Roy is an experienced professional in the IT services field with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He is awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com