Understanding Device Health Attestation Intune Device Compliance Check

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

Introduction

Intune device compliance is a check mechanism – whether the managed devices meets the specified security requirements as per organization security policy. Based on the compliance state of a device, you can have an Azure AD Conditional Access policy enforced to restrict access to sensitive data from that device.

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

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

However, it won’t be enforcing the user to create the same.If you want to enforce something to be implemented at the device level, you would require to configure 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!)

It’s all good till this point. But here is the catch. Intune restriction policies get applied post 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 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 to rescue, the Windows Device Health Attestation (DHA), a feature that was released with the first version of Windows 10 (v1507 or codename TH1), with the sole purpose of ensuring that the device boot phase is not compromised and the device boots to a trusted state.

DHA in itself does not secures the Windows boot process.

It is a reporting service which takes into consideration, the conditions of OS boot which is used to prepare a report. This report is then attested by a remote server for trust. Based on this, a device management service like Intune can determine if the device is in 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 a MDM service provider.

The DHA protocol integrates with MS-MDM protocol framework and works by utilizing 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…

• As we power on the device and it conducts a Power On Self-Test (POST) – a diagnostic testing sequence as initiated by the firmware to check the components of the system and detect if 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, which in turn loads the OS kernel to the RAM and the Kernel takes over from here.

• The Kernel during initialization loads all the system drivers, 3rd party drivers and the system files. At this point, the Windows booting is complete. In-built/3rd party Anti-Malware service are started and Windows Login page is displayed.

If you study the above flow, you can understand how unsecure 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 DHA and Intune integrates to offer a more secured device compliance evaluation to provide you with the peace of mind that the devices in your organization are not only compliant with required security but are also running on a trusted device state.

As you can see on the above snap referenece, if you have a compliance policy which requires any of the above parameters to be evaluated, this compliance evaluation will be dependent on the DHA service.

Code Integrity depends on Secure Boot to work

As such, if you have only marked Code Inetgrity as Require but not Secure Boot, at the device end you would still require the Secure Boot feature to be enabled in UEFI for the device evaluation to report as complaint.

Understanding the components of DHA Based on which it functions…

As I have mentioned earlier above, DHA in itself does not secures 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 feature of the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification. It detects tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures. 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 bootkits.

Device Health Attestation Dependency – TPM?

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

TPM contains Platform Configuration Regsiter (PCR) banks – essential feature of TPM which allows it to cryptographically record (measure) software and hardware state.

Well this deserves an explanation of its own…

Lets 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 excuted if A is trusted. But A being 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 that gets 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 that is 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 measurements of the ACM and BIOS code modules 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

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, this does not actually boots the system from the beginning to initiate a new capture.

DHA Report – What it contains?

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

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

If you like this, there is a high chance that you will like my other articles on Intune. Do check it out if and when your time permits.

Till then, read something everyday, learn something everyday!

Resources

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