Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
66 lines (44 sloc) 4.04 KB

Windows IoT Device Health Attestation Architecture


Windows IoT Device Health Attestation enables the operator to assess if a device is booted to a trusted and compliant state, and take appropriate remedial actions if necessary through Azure IoT Hub Device Management.


  • Device with Trusted Platform Module (TPM) 2.0
  • Endorsement Key Certificate (EK certificate) issued by the TPM vendor

Data Flow Overview

Here's a diagram of the basic data flow.

This is divided into 3 parts:

  1. Device sends boot data DHA-BootData to DHA-Server. DHA Server replies with an encrypted data blob DHA-EncBlob
  2. Azure IotHub sends a Nonce to Device. Device sends encrypted data blob DHA-EncBlob and a signed DHA-SignedBlob data blob to Azure IotHub
  3. Azure IotHub posts data it received from device to DHA Server. DHA Server reviews the data it receives, and replies with a device health report DHA-Report.


  • 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-Report: the report that is issued by DHA-Service
  • Nonce: a crypto protected number that is generated by MDM-Server, which protects the DHA-Session from man-in-the-middle type attacks

Data Flow Detailed

The following breaks down each of the three steps in detail:

  1. On device boot, DM-client retrieve the DHA-server endpoint from the device twin.
  2. DM-client sets the endpoints in the HASCSP using SyncML ./Vendor/MSFT/HealthAttestation/HASEndpoint
  3. DM-client tells HASCSP to send a health verification request to DHA-service using SyncML ./Vendor/MSFT/HealthAttestation/VerifyHealth
  4. Device sends boot data (DHA-BootData) to DHA-Service
  5. DHA-Service replies with an encrypted data blob (DHA-EncBlob)
  6. DM-client gets status of the current health verification request using SyncML ./Vendor/MSFT/HealthAttestation/Status

  1. When DM-client wants report health status to Azure-DM-server, the DM-client will send a device-to-cloud message to request a nonce from Azure-DM-server.
    • To separate this health attestation message from other telemetry messages, the message will have the property MessageType=DHA-* And a routing rule will redirect these messages to an azure service bus.
    • The service bus, upon receiving a message, will trigger the execution of DHA-Azure-Functions.
  2. DHA-Azure-Functions generates a random nonce and store the nonce along with the device name into the Azure-Table-Storage.
  3. DHA-Azure-Functions invoke a direct method (with nonce as a parameter) on the DM client.
  4. DM-client passes the nonce to HASCSP using SyncML ./Vendor/MSFT/HealthAttestation/Nonce
  5. DM-client gets the DHA-EncBlob and DHA-SignedBlob from HASCSP using SyncML ./Vendor/MSFT/HealthAttestation/Certificate
  6. DM-client sends DHA-EncBlob and DHA-SignedBlob via device-to-cloud message.

  1. Since azure functions are stateless, DHA-Azure-Functions needs to retrieve the nonce generated for that device in step 8 from the Azure-Table-Storage.
  2. DHA-Azure-Functions sends the nonce, DHA-EncBlob, and DHA-SignedBlob to the DHA-service.
  3. DHA-Service reviews the data and replies with a device health report (DHA-Report).
  4. DHA-Azure-Functions stores the DHA-Report in the Azure-Table-Storage.

Home Page | Library Reference

You can’t perform that action at this time.