Device HealthAttestation CSP

The Device HealthAttestation configuration service provider (DHA-CSP) enables enterprise IT managers to assess if a device is booted to a trusted and compliant state, and take enterprise policy actions.

The following is a list of functions performed by the Device HealthAttestation CSP:

  • Collects device boot logs, TPM audit trails and the TPM certificate (DHA-BootData) from a managed device
  • Forwards DHA-BootData to Device Health Attestation Service (DHA-Service)
  • Receives an encrypted blob (DHA-EncBlob) from DHA-Service, and stores it in a local cache on the device
  • Receives attestation requests (DHA-Requests) from a DHA-Enabled MDM, and replies with Device Health Attestation data (DHA-Data

Terms

TPM (Trusted Platform Module)

TPM is a specialized hardware-protected logic that performs a series of hardware protected security operations including providing protected storage, random number generation, encryption and signing.

DHA (Device HealthAttestation) feature

The Device HealthAttestation (DHA) feature enables enterprise IT administrators to monitor the security posture of managed devices remotely by using hardware (TPM) protected and attested data via a tamper-resistant and tamper-evident communication channel.

DHA-Enabled device (Device HealthAttestation enabled device)

A Device HealthAttestation enabled (DHA-Enabled) device is a computing device (phone, desktop, laptop, tablet, server) that runs Windows 10 and supports TPM version 1.2 or 2.0.

DHA-Session (Device HealthAttestation session)

The Device HealthAttestation session (DHA-Session) describes the end-to-end communication flow that is performed in one device health attestation session.

The following list of transactions are performed in one DHA-Session:

  • DHA-CSP and DHA-Service communication:
    • DHA-CSP forwards device boot data (DHA-BootData) to DHA-Service
    • DHA-Service replies with an encrypted data blob (DHA-EncBlob)
  • DHA-CSP and MDM-Server communication:
    • MDM-Server sends a device health verification request to DHA-CSP
    • DHA-CSP replies with a payload called DHA-Data that includes an encrypted (DHA-EncBlob) and a signed (DHA-SignedBlob) data blob
  • MDM-Server and DHA-Service communication:
    • MDM-Server posts data it receives from devices to DHA-Service
    • DHA-Service reviews the data it receives, and replies with a device health report (DHA-Report)
healthattestation session diagram
DHA session data (Device HealthAttestation session data)

The following list of data is produced or consumed in one DHA-Transaction:

  • DHA-BootData: the device boot data (TCG logs, PCR values, device/TPM certificate, boot and TPM counters) that are required for validating device boot health.
  • DHA-EncBlob: an encrypted summary report that DHA-Service issues to a device after reviewing the DHA-BootData it receives from devices.
  • DHA-SignedBlob: it is a signed snapshot of the current state of a device’s runtime that is captured by DHA-CSP at device health attestation time.
  • DHA-Data: an XML formatted data blob that devices forward for device health validation to DHA-Service via MDM-Server. DHA-Data has 2 parts:
    • DHA-EncBlob: the encrypted data blob that the device receives from DHA-Service
    • DHA-SignedBlob: a current snapshot of the current security state of the device that is generated by DHA-CSP
  • DHA-Report: the report that is issued by DHA-Service to MDM-Server
  • Nonce: a crypto protected number that is generated by MDM-Server, which protects the DHA-Session from man-in-the-middle type attacks
DHA-Enabled MDM (Device HealthAttestation enabled device management solution)

Device HealthAttestation enabled (DHA-Enabled) device management solution is a device management tool that is integrated with the DHA feature.

DHA-Enabled device management solutions enable enterprise IT managers to raise the security protection bar for their managed devices based on hardware (TPM) protected data that can be trusted even if a device is compromized by advanced security threats or running a malicious (jailbroken) operating system.

The following list of operations are performed by DHA-Enabled-MDM:

  • Enables the DHA feature on a DHA-Enabled device
  • Issues device health attestation requests to enrolled/managed devices
  • Collects device health attestation data (DHA-Data), and sends it to Device Health Attestation Service (DHA-Service) for verification
  • Gets the device health report (DHA-Report) from DHA-Service, which triggers compliance action
DHA-CSP (Device HealthAttestation Configuration Service Provider)

The Device HealthAttestation Configuration Service Provider (DHA-CSP) uses a device’s TPM and firmware to measure critical security properties of the device’s BIOS and Windows boot, such that even on a system infected with kernel level malware or a rootkit, these properties cannot be spoofed.

The following list of operations are performed by DHA-CSP:

  • Collects device boot data (DHA-BootData) from a managed device
  • Forwards DHA-BootData to Device Health Attestation Service (DHA-Service)
  • Receives an encrypted blob (DHA-EncBlob) from DHA-Service, and stores it in a local cache on the device
  • Receives attestation requests (DHA-Requests) from a DHA-Enabled MDM, and replies with Device Health Attestation data (DHA-Data)
DHA-Service (Device HealthAttestation Service)

Device HealthAttestation Service (DHA-Service) validates the data it receives from DHA-CSP and issues a highly trusted hardware (TPM) protected report (DHA-Report) to DHA-Enabled device management solutions through a tamper resistant and tamper evident communication channel.

DHA-Service is available in 2 flavors: “DHA-Cloud” and “DHA-Server2016”. DHA-Service supports a variety of implementation scenarios including cloud, on premises, air-gapped, and hybrid scenarios.

The following list of operations are performed by DHA-Service:

  • Receives device boot data (DHA-BootData) from a DHA-Enabled device
  • Forwards DHA-BootData to Device Health Attestation Service (DHA-Service)
  • Receives an encrypted blob (DHA-EncBlob) from DHA-Service, and stores it in a local cache on the device
  • Receives attestation requests (DHA-Requests) from a DHA-Enabled-MDM, and replies with a device health report (DHA-Report)

healthattestation service diagram

DHA-Service type Description Operation cost
Device Health Attestation – Cloud

(DHA-Cloud)

DHA-Cloud is a Microsoft owned and operated DHA-Service that is:

  • Available in Windows for free
  • Running on a high-availability and geo-balanced cloud infrastructure
  • Supported by most DHA-Enabled device management solutions as the default device attestation service provider
  • Accessible to all enterprise managed devices via following:
    • FQDN = has.spserv.microsoft.com) port
    • Port = 443
    • Protocol = TCP
No cost
Device Health Attestation – On Premise

(DHA-OnPrem)

DHA-OnPrem refers to DHA-Service that is running on premise:

  • Offered to Windows Server 2016 customer (no added licensing cost for enabling/running DHA-Service)
  • Hosted on an enterprise owned and managed server device/hardware
  • Supported by 1st and 3rd party DHA-Enabled device management solution providers that support on premise and hybrid (Cloud + OnPrem) hardware attestation scenarios
  • Accessible to all enterprise managed devices via following:

    • FQDN = (enterprise assigned)
    • Port = (enterprise assigned)
    • Protocol = TCP
The operation cost of running one or more instances of Server 2016 on premise.
Device Health Attestation - Enterprise Managed Cloud

(DHA-EMC)

DHA-EMC refers to an enterprise managed DHA-Service that is running as a virtual host/service on a Windows Server 2016 compatible - enterprise managed cloud service, such as Microsoft Azure.

  • Offered to Windows Server 2016 customers with no additional licensing cost (no added licensing cost for enabling/running DHA-Service)
  • Supported by 1st and 3rd party DHA-Enabled device management solution providers that support on premise and hybrid (Cloud + OnPrem) hardware attestation scenarios
  • Accessible to all enterprise managed devices via following:

    • FQDN = (enterprise assigned)
    • Port = (enterprise assigned)
    • Protocol = TCP
The operation cost of running Server 2016 on a compatible cloud service, such as Microsoft Azure.

CSP diagram and node descriptions

The following diagram shows the Device HealthAttestation configuration service provider in tree format.

healthattestation csp

./Vendor/MSFT/HealthAttestation

The root node for the device HealthAttestation configuration service provider.

VerifyHealth (Required)

Notifies the device to prepare a device health verification request.

The supported operation is Execute.

Status (Required)

Provides the current status of the device health request.

The supported operation is Get.

The following list shows some examples of supported values. For the complete list of status see Device HealthAttestation CSP status and error codes.

  • 0 - (HEALTHATTESTATION_CERT_RETRI_UNINITIALIZED): DHA-CSP is preparing a request to get a new DHA-EncBlob from DHA-Service
  • 1 - (HEALTHATTESTATION_CERT_RETRI_REQUESTED): DHA-CSP is waiting for the DHA-Service to respond back, and issue a DHA-EncBlob to the device
  • 2 - (HEALTHATTESTATION_CERT_RETRIEVAL_FAILED): A valid DHA-EncBlob could not be retrieved from the DHA-Service for reasons other than discussed in the DHA error/status codes
  • 3 - (HEALTHATTESTATION_CERT_RETRI_COMPLETE): DHA-Data is ready for pick up

ForceRetrieve (Optional)

Instructs the client to initiate a new request to DHA-Service, and get a new DHA-EncBlob (a summary of the boot state that is issued by DHA-Service). This option should only be used if the MDM server enforces a certificate freshness policy, which needs to force a device to get a fresh encrypted blob from DHA-Service.

Boolean value. The supported operation is Replace.

Certificate (Required)

Instructs the DHA-CSP to forward DHA-Data to the MDM server.

Value type is b64.The supported operation is Get.

Nonce (Required)

Enables MDMs to protect the device health attestation communications from man-in-the-middle type (MITM) attacks with a crypt-protected random value that is generated by the MDM Server.

The nonce is in hex format, with a minimum size of 8 bytes, and a maximum size of 32 bytes.

The supported operations are Get and Replace.

CorrelationId (Required)

Identifies a unique device health attestation session. CorrelationId is used to correlate DHA-Service logs with the MDM server events and Client event logs for debug and troubleshooting.

Value type is integer, the minimum value is - 2,147,483,648 and the maximun value is 2,147,483,647. The supported operation is Get.

HASEndpoint (Optional)

Identifies the fully qualified domain name (FQDN) of the DHA-Service that is assigned to perform attestation. If an FQDN is not assigned, DHA-Cloud (Microsoft owned and operated cloud service) will be used as the default attestation service.

Value type is string. The supported operations are Get and Replace. The default value is has.spserv.microsoft.com.

TpmReadyStatus (Required)

Added in Windows 10, version 1607 March service release. Returns a bitmask of information describing the state of TPM. It indicates whether the TPM of the device is in a ready and trusted state.

Value type is integer. The supported operation is Get.

DHA-CSP integration steps

The following list of validation and development tasks are required for integrating the Microsoft Device Health Attestation feature with a Windows Mobile device management solution (MDM):

  1. Verify HTTPS access
  2. Assign an enterprise trusted DHA-Service
  3. Instruct client to prepare DHA-data for verification
  4. Take action based on the clients response
  5. Instruct the client to forward DHA-data for verification
  6. Post DHA-data to DHA-service
  7. Receive response from DHA-service
  8. Parse DHA-Report data. Take appropriate policy action based on evaluation results

Each step is described in detail in the following sections of this topic.

Step 1: Verify HTTPS access

Validate that both the MDM server and the device (MDM client) can access has.spserv.microsoft.com using the TCP protocol over port 443 (HTTPS).

You can use OpenSSL to validate access to DHA-Service. Here is a sample OpenSSL command and the response that was generated by DHA-Service:

PS C:\openssl> ./openssl.exe s_client -connect has.spserv.microsoft.com:443
CONNECTED(000001A8)
---
Certificate chain
 0 s:/CN=*.spserv.microsoft.com
   i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
 1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
   i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGOTCCBCGgAwIBAgITWgAA1KJb40tpukQoewABAADUojANBgkqhkiG9w0BAQsFA4ICAQCJaKewFQuqQwR5fkAr9kZOmtq5fk03p82eHWLaftXlc4RDvVFp4a2ciSjZL8f3f+XWPVdUj9DAi3bCSddlrcNOPRXNepFC1OEmKtE9jM0r7M8qnqFkIfbNrVNUtPxHoraQeMIgbk0SHEOlShY2GXETVBqZdDZ5Rmk4rA+3ggoeV8hNzm2dfNp0iGSrZzawbLzWU1D2Tped1k5IV63yb+cU/TmM ……………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………………………
……………2RXXwogn1UM8TZduCEjz+b05mAkvytugzzaI4wXkCP4OgNyy8gul2z5Gj/51pCTN
-----END CERTIFICATE-----
subject=/CN=*.spserv.microsoft.com
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
---
No client certificate CA names sent
Peer signing digest: SHA1
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 3681 bytes and written 561 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol: TLSv1.2
    Cipher: ECDHE-RSA-AES256-SHA384
    Session-ID: B22300009621370F84A4A3A7D9FC40D584E047C090604E5226083A02ED239C93
    Session-ID-ctx: 
    Master-Key: 9E3F6BE5B3D3B55C070470CA2B62EF59CC1D5ED9187EF5B3D1BBF4C101EE90BEB04F34FFD748A13C92A387104B8D1DE7
    Key-Arg: None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432078420
    Timeout: 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

Step 2: Assign an enterprise trusted DHA-Service

There are three types of DHA-Service:

  • Device Health Attestation – Cloud (owned and operated by Microsoft)
  • Device Health Attestation – On Premise (owned and operated by an enterprise, runs on Windows Server 2016 on premise)
  • Device Health Attestation - Enterprise Managed Cloud (owned and operated by an enterprise, runs on Windows Server 2016 compatible enterprise managed cloud)

DHA-Cloud is the default setting. No further action is required if an enterprise is planning to use Microsoft DHA-Cloud as the trusted DHA-Service provider.

For DHA-OnPrem & DHA-EMC scenarios, send a SyncML command to the HASEndpoint node to instruct a managed device to communicate with the enterprise trusted DHA-Service.

The following example shows a sample call that instructs a managed device to communicate with an enterprise managed DHA-Service.

      <Replace>
         <CmdID>1</CmdID>
         <Item>
            <Target>
               <LocURI>./Vendor/MSFT/HealthAttestation/HASEndpoint</LocURI>
            </Target>
            <Data> www.ContosoDHA-Service</Data>
         </Item>
      </Replace>

Step 3: Instruct client to prepare health data for verification

Send a SyncML call to start collection of the DHA-Data.

The following example shows a sample call that triggers collection and verification of health attestation data from a managed device.

      <Exec>
         <CmdID>1</CmdID>
         <Item>
            <Target>
               <LocURI>./Vendor/MSFT/HealthAttestation/VerifyHealth</LocURI>
            </Target>
         </Item>
      </Exec>

      <Get>
         <CmdID>2</CmdID>
         <Item>
            <Target>
               <LocURI>./Vendor/MSFT/HealthAttestation/Status</LocURI>
            </Target>
         </Item>
      </Get>

Step 4: Take action based on the clients response

After the client receives the health attestation request, it sends a response. The following list describes the responses, along with a recommended action to take.

  • If the response is HEALTHATTESTATION_CERT_RETRI_COMPLETE (3) then proceed to the next section.
  • If the response is HEALTHATTESTATION_CERT_RETRI_REQUESTED (1) or HEALTHATTESTATION_CERT_RETRI_UNINITIALIZED (0) wait for an alert, then proceed to the next section.

Here is a sample alert that is issued by DHA_CSP:

        <Alert>
            <CmdID>1</CmdID>
            <Data>1226</Data>
            <Item>
                <Source>
                    <LocURI>./Vendor/MSFT/HealthAttestation/VerifyHealth</LocURI>
                </Source>
                <Meta>
                    <Type xmlns="syncml:metinf">com.microsoft.mdm:HealthAttestation.Result</Type>
                    <Format xmlns="syncml:metinf">int</Format>
                </Meta>
                <Data>3</Data>
            </Item>
        </Alert>

Step 5: Instruct the client to forward health attestation data for verification

Create a call to the Nonce, Certificate and CorrelationId nodes, and pick up an encrypted payload that includes a health certificate and related data from the device.

Here is an example:

<Replace>
           <CmdID>1</CmdID>
           <Item>
               <Target>
                   <LocURI>./Vendor/MSFT/HealthAttestation/Nonce</LocURI>
               </Target>
               <Data>AAAAAAAAAFFFFFFF</Data>
           </Item>
</Replace>

    <Get>
            <CmdID>2</CmdID>
            <Item>
                <Target>
                    <LocURI>./Vendor/MSFT/HealthAttestation/Certificate</LocURI>
                </Target>
            </Item>
        </Get>

     <Get>
            <CmdID>3</CmdID>
            <Item>
                <Target>
                    <LocURI>./Vendor/MSFT/HealthAttestation/CorrelationId </LocURI>
                </Target>
            </Item>
     </Get>

Step 6: Forward device health attestation data to DHA-service

In response to the request that was sent in the previous step, the MDM client forwards an XML formatted blob (response from ./Vendor/MSFT/HealthAttestation/Certificate node) and a call identifier called CorrelationId (response to ./Vendor/MSFT/HealthAttestation/CorrelationId node).

When the MDM-Server receives the above data, it must:

  • Log the CorrelationId it receives from the device (for future troubleshooting/reference), correlated to the call.
  • Decode the XML formatted data blob it receives from the device
  • Append the nonce that was generated by MDM service (add the nonce that was forwarded to the device in Step 5) to the XML structure that was forwarded by the device in following format:
<?xml version='1.0' encoding='utf-8' ?>
<HealthCertificateValidationRequest ProtocolVersion='1' xmlns='http://schemas.microsoft.com/windows/security/healthcertificate/validation/request/v1'>
    <Nonce>[INT]</Nonce>
    <Claims> [base64 blob, eg ‘ABc123+/…==’] </Claims>
    <HealthCertificateBlob> [base64 blob, eg ‘ABc123+/...==’]
    </HealthCertificateBlob>
</HealthCertificateValidationRequest>

Step 7: Receive response from the DHA-service

When the Microsoft Device Health Attestation Service receives a request for verification, it performs the following steps:

  • Decrypts the encrypted data it receives.
  • Validates the data it has received
  • Creates a report, and shares the evaluation results to the MDM server via SSL in XML format

Step 8: Take appropriate policy action based on evaluation results

After the MDM server receives the verified data, the information can be used to make policy decisions by evaluating the data. Some possible actions would be:

  • Allow the device access.
  • Allow the device to access the resources, but flag the device for further investigation.
  • Prevent a device from accessing resources.

The following list of data points are verified by the DHA-Service in DHA-Report version 3:

* TPM 2.0 only
** Reports if Bitlocker was enabled during initial boot.
*** The “Hybrid Resume” must be disabled on the device. Reports 1st party ELAM “Defender” was loaded during boot.

Each of these are described in further detail in the following sections, along with the recommended actions to take.

Issued

The date and time DHA-report was evaluated or issued to MDM.

AIKPresent

When an Attestation Identity Key (AIK) is present on a device, it indicates that the device has an endorsement key (EK) certificate. It can be trusted more than a device that doesn’t have an EK certificate.

If AIKPresent = True (1), then allow access.

If AIKPresent = False (0), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Allow conditional access based on other data points that are present at evaluation time. For example, other attributes on the health certificate, or a devices past activities and trust history.
  • Take one of the previous actions and additionally place the device in a watch list to monitor the device more closely for potential risks.

ResetCount (Reported only for devices that support TPM 2.0)

This attribute reports the number of times a PC device has hibernated or resumed.

RestartCount (Reported only for devices that support TPM 2.0)

This attribute reports the number of times a PC device has rebooted

DEPPolicy

A device can be trusted more if the DEP Policy is enabled on the device.

Data Execution Prevention (DEP) Policy defines is a set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from running on a system. Secure boot allows a limited list on x86/amd64 and on ARM NTOS locks it to on.

DEPPolicy can be disabled or enabled by using the following commands in WMI or a PowerShell script:

  • To disable DEP, type bcdedit.exe /set {current} nx AlwaysOff
  • To enable DEP, type bcdedit.exe /set {current} nx AlwaysOn

If DEPPolicy = 1 (On), then allow access.

If DEPPolicy = 0 (Off), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Allow conditional access based on other data points that are present at evaluation time. For example, other attributes on the health certificate, or a devices past activities and trust history.
  • Take one of the previous actions and additionally place the device in a watch list to monitor the device more closely for potential risks.

BitlockerStatus (at boot time)

When Bitlocker is reported "on" at boot time, the device is able to protect data that is stored on the drive from unauthorized access, when the system is turned off or goes to hibernation.

Windows BitLocker Drive Encryption, encrypts all data stored on the Windows operating system volume. BitLocker uses the TPM to help protect the Windows operating system and user data and helps to ensure that a computer is not tampered with, even if it is left unattended, lost, or stolen.

If the computer is equipped with a compatible TPM, BitLocker uses the TPM to lock the encryption keys that protect the data. As a result, the keys cannot be accessed until the TPM has verified the state of the computer.

If BitLockerStatus = 1 (On), then allow access.

If BitLockerStatus = 0 (Off), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Allow conditional access based on other data points that are present at evaluation time. For example, other attributes on the health certificate, or a devices past activities and trust history.
  • Take one of the previous actions and additionally place the device in a watch list to monitor the device more closely for potential risks.

BootManagerRevListVersion

This attribute indicates the version of the Boot Manager that is running on the device, to allow you to track and manage the security of the boot sequence/environment.

If BootManagerRevListVersion = [CurrentVersion], then allow access.

If BootManagerRevListVersion != [CurrentVersion], then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI and MBI assets
  • Place the device in a watch list to monitor the device more closely for potential risks.
  • Trigger a corrective action, such as such as informing the technical support team to contact the owner investigate the issue.

CodeIntegrityRevListVersion

This attribute indicates the version of the code that is performing integrity checks during the boot sequence. Using this attribute can help you detect if the device is running the latest version of the code that performs integrity checks, or if it is exposed to security risks (revoked) and enforce an appropriate policy action.

If CodeIntegrityRevListVersion = [CurrentVersion], then allow access.

If CodeIntegrityRevListVersion != [CurrentVersion], then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI and MBI assets
  • Place the device in a watch list to monitor the device more closely for potential risks.
  • Trigger a corrective action, such as such as informing the technical support team to contact the owner investigate the issue.

SecureBootEnabled

When Secure Boot is enabled the core components used to boot the machine must have correct cryptographic signatures that are trusted by the organization that manufactured the device. The UEFI firmware verifies this before it lets the machine start. If any files have been tampered with, breaking their signature, the system will not boot.

If SecureBootEnabled = 1 (True), then allow access.

If SecurebootEnabled = 0 (False), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Allow conditional access based on other data points that are present at evaluation time. For example, other attributes on the health certificate, or a devices past activities and trust history.
  • Take one of the previous actions and additionally place the device in a watch list to monitor the device more closely for potential risks.

BootDebuggingEnabled

Boot debug enabled points to a device that is used in development and testing. Devices that are used for test and development typically are less secure: the device may run unstable code, or be configured with fewer security restrictions that is required for testing and development.

Boot debugging can be disabled or enabled by using the following commands in WMI or a PowerShell script:

  • To disable boot debugging, type bcdedit.exe /set {current} bootdebug off
  • To enable boot debugging, type bcdedit.exe /set {current} bootdebug on

If BootdebuggingEnabled = 0 (False), then allow access.

If BootDebuggingEnabled = 1 (True), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Place the device in a watch list to monitor the device more closely for potential risks.
  • Trigger a corrective action, such as enabling VSM using WMI or a Powershell script.

OSKernelDebuggingEnabled

OSKernelDebuggingEnabled points to a device that is used in development and testing. Devices that are used for test and development typically are less secure: they may run unstable code, or be configured with fewer security restrictions required for testing and development.

If OSKernelDebuggingEnabled = 0 (False), then allow access.

If OSKernelDebuggingEnabled = 1 (True), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Place the device in a watch list to monitor the device more closely for potential risks.
  • Trigger a corrective action, such as such as informing the technical support team to contact the owner investigate the issue.

CodeIntegrityEnabled

When code integrity is enabled, code execution is restricted to integrity verified code.

Code integrity is a feature that validates the integrity of a driver or system file each time it is loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrator privileges.

On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.

If CodeIntegrityEnabled = 1 (True), then allow access.

If CodeIntegrityEnabled = 0 (False), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Allow conditional access based on other data points that are present at evaluation time. For example, other attributes on the health certificate, or a devices past activities and trust history.
  • Take one of the previous actions and additionally place the device in a watch list to monitor the device more closely for potential risks.

TestSigningEnabled

When test signing is enabled, the device does not enforce signature validation during boot, and allows the unsigned drivers (such as unsigned UEFI modules) to load during boot.

Test signing can be disabled or enabled by using the following commands in WMI or a PowerShell script:

  • To disable boot debugging, type bcdedit.exe /set {current} testsigning off
  • To enable boot debugging, type bcdedit.exe /set {current} testsigning on

If TestSigningEnabled = 0 (False), then allow access.

If TestSigningEnabled = 1 (True), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI and MBI assets
  • Place the device in a watch list to monitor the device more closely for potential risks.
  • Trigger a corrective action, such as enabling test signing using WMI or a Powershell script.

SafeMode

Safe mode is a troubleshooting option for Windows that starts your computer in a limited state. Only the basic files and drivers necessary to run Windows are started.

If SafeMode = 0 (False), then allow access.

If SafeMode = 1 (True), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Trigger a corrective action, such as informing the technical support team to contact the owner investigate the issue.

WinPE

Windows pre-installation Environment (Windows PE) is a minimal operating system with limited services that is used to prepare a computer for Windows installation, to copy disk images from a network file server, and to initiate Windows Setup.

If WinPE = 0 (False), then allow access.

If WinPE = 1 (True), then limit access to remote resources that are required for Windows OS installation.

ELAMDriverLoaded (Windows Defender)

To use this reporting feature you must disable "Hybrid Resume" on the device. Early launch anti-malware (ELAM) provides protection for the computers in your network when they start up and before third-party drivers initialize.

In the current release, this attribute only monitors/reports if a Microsoft 1st party ELAM (Windows Defender) was loaded during initial boot.

If a device is expected to use a 3rd party antivirus program, ignore the reported state.

If a device is expected to use Windows Defender and ELAMDriverLoaded = 1 (True), then allow access.

If a device is expected to use Windows Defender and ELAMDriverLoaded = 0 (False), then take one of the following actions that align with your enterprise policies, also accounting for whether it is a desktop or mobile device:

  • Disallow all access
  • Disallow access to HBI assets
  • Trigger a corrective action, such as informing the technical support team to contact the owner investigate the issue.

Bcdedit.exe /set {current} vsmlaunchtype auto

If ELAMDriverLoaded = 1 (True), then allow access.

If ELAMDriverLoaded = 0 (False), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Trigger a corrective action, such as informing the technical support team to contact the owner investigate the issue.

VSMEnabled

Virtual Secure Mode (VSM) is a container that protects high value assets from a compromised kernel. VSM requires about 1GB of memory – it has just enough capability to run the LSA service that is used for all authentication brokering.

VSM can be enabled by using the following command in WMI or a PowerShell script:

bcdedit.exe /set {current} vsmlaunchtype auto

If VSMEnabled = 1 (True), then allow access.

If VSMEnabled = 0 (False), then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Disallow access to HBI assets
  • Trigger a corrective action, such as informing the technical support team to contact the owner investigate the issue

PCRHashAlgorithmID

This attribute is an informational attribute that identifies the HASH algorithm that was used by TPM; no compliance action required.

BootAppSVN

This attribute identifies the security version number of the Boot Application that was loaded during initial boot on the attested device

If reported BootAppSVN equals an accepted value, then allow access.

If reported BootAppSVN does not equal an accepted value, then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Direct the device to an enterprise honeypot, to further monitor the device's activities.

BootManagerSVN

This attribute identifies the security version number of the Boot Manager that was loaded during initial boot on the attested device.

If reported BootManagerSVN equals an accepted value, then allow access.

If reported BootManagerSVN does not equal an accepted value, then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Direct the device to an enterprise honeypot, to further monitor the device's activities.

TPMVersion

This attribute identifies the version of the TPM that is running on the attested device.

TPMVersion node provides to replies "1" and "2":

  • 1 means TPM specification version 1.2
  • 2 means TPM specification version 2.0

Based on the reply you receive from TPMVersion node:

  • If reported TPMVersion equals an accepted value, then allow access.
  • If reported TPMVersion does not equal an accepted value, then take one of the following actions that align with your enterprise policies:
    • Disallow all access
    • Direct the device to an enterprise honeypot, to further monitor the device's activities.

PCR0

The measurement that is captured in PCR[0] typically represents a consistent view of the Host Platform between boot cycles. It contains a measurement of components that are provided by the host platform manufacturer.

Enterprise managers can create a whitelist of trusted PCR[0] values, compare the PCR[0] value of the managed devices (the value that is verified and reported by HAS) with the whitelist, and then make a trust decision based on the result of the comparison.

If your enterprise does not have a whitelist of accepted PCR[0] values, then take no action.

If PCR[0] equals an accepted whitelisted value, then allow access.

If PCR[0] does not equal any accepted whitelisted value, then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Direct the device to an enterprise honeypot, to further monitor the device's activities.

SBCPHash

SBCPHash is the finger print of the Custom Secure Boot Configuration Policy (SBCP) that was loaded during boot in Windows devices, except PCs.

If SBCPHash is not present, or is an accepted (whitelisted) value, then allow access.

If SBCPHash is present in DHA-Report, and is not a whitelisted value, then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Place the device in a watch list to monitor the device more closely for potential risks.

CIPolicy

This attribute indicates the Code Integrity policy that is controlling the security of the boot environment.

If CIPolicy is not present, or is an accepted (whitelisted) value, then allow access.

If CIPolicy is present and is not a whitelisted value, then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Place the device in a watch list to monitor the device more closely for potential risks.

BootRevListInfo

This attribute identifies the Boot Revision List that was loaded during initial boot on the attested device.

If reported BootRevListInfo version equals an accepted value, then allow access.

If reported BootRevListInfo version does not equal an accepted value, then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Direct the device to an enterprise honeypot, to further monitor the device's activities.

OSRevListInfo

This attribute identifies the Operating System Revision List that was loaded during initial boot on the attested device.

If reported OSRevListInfo version equals an accepted value, then allow access.

If reported OSRevListInfo version does not equal an accepted value, then take one of the following actions that align with your enterprise policies:

  • Disallow all access
  • Direct the device to an enterprise honeypot, to further monitor the device's activities.

HealthStatusMismatchFlags

HealthStatusMismatchFlags attribute appears if DHA-Service detects an integrity issue (mismatch) in the DHA-Data it receives from device management solutions, for validation.

In case of a detected issue a list of impacted DHA-report elements will be listed under the HealthStatusMismatchFlags attribute.

Device HealthAttestation CSP status and error codes

Error code Error name Description
0 HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED This is the initial state for devices that have never participated in a DHA-Session.
1 HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED This state signifies that MDM client’s Exec call on the node VerifyHealth has been triggered and now the OS is trying to retrieve DHA-EncBlob from DHA-Server.
2 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED This state signifies that the device failed to retrieve DHA-EncBlob from DHA-Server.
3 HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE This state signifies that the device failed to retrieve DHA-EncBlob from DHA-Server.
4 HEALTHATTESTATION_CERT_RETRIEVAL_PCR_FAIL Deprecated in Windows 10, version 1607.
5 HEALTHATTESTATION_CERT_RETRIEVAL_GETQUOTE_FAIL DHA-CSP failed to get a claim quote.
6 HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY DHA-CSP failed in opening a handle to Microsoft Platform Crypto Provider.
7 HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL DHA-CSP failed in retrieving Windows AIK
8 HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL Deprecated in Windows 10, version 1607.
9 HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION Invalid TPM version (TPM version is not 1.2 or 2.0)
10 HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL Nonce was not found in the registry.
11 HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL Correlation ID was not found in the registry.
12 HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL Deprecated in Windows 10, version 1607.
13 HEALTHATTESTATION_CERT_RETRIEVAL_GETCLAIM_FAIL Deprecated in Windows 10, version 1607.
14 HEALTHATTESTATION_CERT_RETRIEVAL_ENCODING_FAIL Failure in Encoding functions. (Extremely unlikely scenario)
15 HEALTHATTESTATION_CERT_RETRIEVAL_ENDPOINTOVERRIDE_FAIL Deprecated in Windows 10, version 1607.
16 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_LOAD_XML DHA-CSP failed to load the payload it received from DHA-Service
17 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML DHA-CSP received a corrupted response from DHA-Service.
18 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_XML DHA-CSP received an empty response from DHA-Service.
19 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_AES_EK DHA-CSP failed in decrypting the AES key from the EK challenge.
20 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK DHA-CSP failed in decrypting the health cert with the AES key.
21 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB DHA-CSP failed in exporting the AIK Public Key.
22 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY DHA-CSP failed in trying to create a claim with AIK attestation data.
23 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB DHA-CSP failed in appending the AIK Pub to the request blob.
24 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT DHA-CSP failed in appending the AIK Cert to the request blob.
25 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE DHA-CSP failed to obtain a Session handle.
26 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE DHA-CSP failed to connect to the DHA-Service.
27 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHANDLE DHA-CSP failed to create a HTTP request handle.
28 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION DHA-CSP failed to set options.
29 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS DHA-CSP failed to add request headers.
30 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST DHA-CSP failed to send the HTTP request.
31 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE DHA-CSP failed to receive a response from the DHA-Service.
32 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS DHA-CSP failed to query headers when trying to get HTTP status code.
33 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE DHA-CSP received an empty response from DHA-Service even though HTTP status was OK.
34 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE DHA-CSP received an empty response along with a HTTP error code from DHA-Service.
35 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER DHA-CSP failed to impersonate user.
36 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR DHA-CSP failed to acquire the PDC activators that are needed for network communication when the device is in Connected standby mode.
0xFFFF HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN DHA-CSP failed due to an unknown reason, this error is highly unlikely to occur.
400 Bad_Request_From_Client DHA-CSP has received a bad (malformed) attestation request.
404 Endpoint_Not_Reachable DHA-Service is not reachable by DHA-CSP

DHA-Report V3 schema

 <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://schemas.microsoft.com/windows/security/healthcertificate/validation/response/v3"
           targetNamespace="http://schemas.microsoft.com/windows/security/healthcertificate/validation/response/v3"
           elementFormDefault="qualified">

    <xs:element name="HealthCertificateValidationResponse" type="HealthCertificateValidationResponse_T"/>
    <xs:complexType name="ResponseCommon_T">
        <xs:attribute name="ErrorCode" type="xs:int" use="required"/>
        <xs:attribute name="ErrorMessage" type="xs:string" use="required"/>
        <xs:attribute name="ProtocolVersion" use="required">
          <xs:simpleType>
            <xs:restriction base="xs:int">
              <xs:minInclusive value="3"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:attribute>
    </xs:complexType>
    <xs:complexType name="HealthCertificatePublicProperties_T">
        <xs:annotation>
            <xs:documentation>Health certificate non machine identifiable properties </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="Issued"                       type="xs:dateTime"/>
            <xs:element name="AIKPresent"                   type="Boolean_T" />
            <xs:element name="ResetCount"                   type="xs:unsignedInt"/>
            <xs:element name="RestartCount"                 type="xs:unsignedInt"/>
            <xs:element name="DEPPolicy"                    type="xs:unsignedInt"/>
            <xs:element name="BitlockerStatus"              type="xs:unsignedInt"/>
            <xs:element name="BootManagerRevListVersion"    type="xs:unsignedInt"/>
            <xs:element name="CodeIntegrityRevListVersion"  type="xs:unsignedInt"/>
            <xs:element name="SecureBootEnabled"            type="Boolean_T"/>
            <xs:element name="BootDebuggingEnabled"         type="Boolean_T"/>
            <xs:element name="OSKernelDebuggingEnabled"     type="Boolean_T"/>
            <xs:element name="CodeIntegrityEnabled"         type="Boolean_T"/>
            <xs:element name="TestSigningEnabled"           type="Boolean_T"/>
            <xs:element name="SafeMode"                     type="Boolean_T"/>
            <xs:element name="WinPE"                        type="Boolean_T"/>
            <xs:element name="ELAMDriverLoaded"             type="Boolean_T"/>
            <xs:element name="VSMEnabled"                   type="Boolean_T"/>
            <xs:element name="PCRHashAlgorithmID"           type="xs:unsignedInt"/>
            <xs:element name="BootAppSVN"                   type="xs:unsignedInt"/>
            <xs:element name="BootManagerSVN"               type="xs:unsignedInt"/>
            <xs:element name="TpmVersion"                   type="xs:unsignedInt"/>
            <xs:element name="PCR0"                         type="xs:hexBinary"/>
            <xs:element name="CIPolicy"                     type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>
            <xs:element name="SBCPHash"                     type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>
            <xs:element name="BootRevListInfo"              type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>
            <xs:element name="OSRevListInfo"                type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>

          <!--
<xs:element name="PCRCount"                     type="xs:unsignedInt"/>
<xs:element name="PCRSize"                      type="xs:unsignedShort"/>
<xs:element name="PCRHashAlgorithmID"           type="xs:unsignedShort"/>

<xs:element name="PCR"                          type="xs:hexBinary"/>
            -->
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="HealthStatusMismatchFlags_T">
        <xs:annotation>
            <xs:documentation>If there's a status mismatch, these flags will be set</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <!-- Hibernate/Resume count -->
            <xs:element name="ResumeCount"                   type="Boolean_T"/>
            <!-- Reboot count -->
            <xs:element name="RebootCount"                   type="Boolean_T"/> 
            <xs:element name="PCR"                           type="Boolean_T"/>
            <xs:element name="BootAppSVN"                   type="Boolean_T"/>
            <xs:element name="BootManagerSVNChain"           type="Boolean_T"/>
            <xs:element name="BootAppSVNChain"              type="Boolean_T"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="HealthCertificateValidationResponse_T" >
        <xs:annotation>
            <xs:documentation>Health certificate validation response </xs:documentation>
        </xs:annotation>
        <xs:complexContent>
            <xs:extension base="ResponseCommon_T">
<xs:sequence>
    <!--Optional element, present only when the certificate can be verified and decrypted-->
    <xs:element name="HealthCertificateProperties"  type="HealthCertificatePublicProperties_T"  minOccurs="0"/>
    <!--Optional element, present only when the reason for a validation failure is a mismatch between the 
                    current health state and the certificate health state-->
    <xs:element name="HealthStatusMismatchFlags"       type="HealthStatusMismatchFlags_T"             minOccurs="0"/>
</xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:simpleType name="Boolean_T">
        <xs:restriction base="xs:boolean">
            <xs:pattern value="true|false"/>
        </xs:restriction>
    </xs:simpleType>
</xs:schema>

DHA-Report example

<?xml version="1.0" encoding="utf-8"?>
<HealthCertificateValidationResponse xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ErrorCode="0" ProtocolVersion="0"
xmlns="http://schemas.microsoft.com/windows/security/healthcertificate/validation/response/v3">
<HealthCertificateProperties>
     <Issued>2016-10-21T02:12:58.6656577Z</Issued>
     <AIKPresent>false</AIKPresent>
     <ResetCount>2107533174</ResetCount>
     <RestartCount>2749041230</RestartCount>
     <DEPPolicy>0</DEPPolicy>
     <BitlockerStatus>0</BitlockerStatus>
     <BootManagerRevListVersion>0</BootManagerRevListVersion>
     <CodeIntegrityRevListVersion>0</CodeIntegrityRevListVersion>
     <SecureBootEnabled>false</SecureBootEnabled>
     <BootDebuggingEnabled>false</BootDebuggingEnabled>
     <OSKernelDebuggingEnabled>false</OSKernelDebuggingEnabled>
     <CodeIntegrityEnabled>true</CodeIntegrityEnabled>
     <TestSigningEnabled>true</TestSigningEnabled>
     <SafeMode>false</SafeMode>
     <WinPE>false</WinPE>
     <ELAMDriverLoaded>true</ELAMDriverLoaded>
     <VSMEnabled>false</VSMEnabled>
     <PCRHashAlgorithmID>0</PCRHashAlgorithmID>
     <BootAppSVN>1</BootAppSVN>
     <BootManagerSVN>1</BootManagerSVN>
     <TpmVersion>2</TpmVersion>
     <PCR0>4ACCBE0ADB9627FFD6285C2E06EC5AC59ABF62C7</PCR0> 
     <CIPolicy>00000000000001001A000B00200000005300690050006F006C006900630079002E007000370062000000A4BF7EF05585876A61CBFF7CAE8123BE756D58B1BBE04F9719D15D6271514CF5</CIPolicy>
     <BootRevListInfo>005D447A7CC6D101200000000B00CBB56E8B19267E24A2986C4A616CCB58B4D53F6020AC8FD5FC205C20F2AB00BC</BootRevListInfo>
     <OSRevListInfo>8073EEA7F8FAD001200000000B00A8285B04DE618ACF4174C59F07AECC002D11DD7D97FA5D464F190C9D9E3479BA</OSRevListInfo>
 </HealthCertificateProperties>
</HealthCertificateValidationResponse>

Configuration service provider reference