Guidance on using the App Specific Hardware ID (ASHWID) to implement per-device app logic

This topic shows how an app with a cloud component may use the Application Specific Hardware Identifier (ASHWID for short) in conjunction with its back-end service to implement per-device logic. Apps that employ per-device licensing policies are examples of apps that belong to this category.

Note  This topic assumes a thorough understanding of cryptology and experience with content licensing.

Introduction

Windows Store apps are designed to easily share data and content across multiple devices. While consumers enjoy these experiences, content licensors often need a mechanism to limit content distribution to a fixed number of devices. Some apps such as content licensing apps need to conform to per-device licensing policies. In conjunction with a back-end cloud service, the Application Specific Hardware Identifier (ASHWID for short) provides a solution. The ASHWID provides a strong binding between the app/package and the device by representing several individual hardware characteristics. In order to protect user privacy, the ASHWID varies from app to app. Unless the underlying hardware has changed, two calls from the same app will result in identical ASHWIDs. However, the ASHWID changes if the hardware profile of the device changes, such as when the user unplugs a USB Bluetooth adapter. The back-end cloud service can verify the ASHWID and compare it with previously reported values. Though the ASHWID varies, it can be parsed to detect if the variance was simply due to a minor change such as an addition of memory to the system. The level of tolerance for variance is up to the implementation of the back-end cloud service. The specific elements that constitute the ASHWID and guidance on how to parse them is provided in subsequent sections.

At a high-level, an app can follow these steps:

1. In the app, the client code calls the HardwareIdentification.GetPackageSpecificToken method and returns the ASHWID to the server back-end for the app.
2. The cloud service verifies whether the value came from Windows and can be trusted.
3. The cloud service compares the obtained ASHWID to previously recorded values provided by this user to determine whether they match and decides whether the device falls within the degree of tolerance allowed by the service.
4. The cloud service either allows or disallows the use of its content on the particular device.

Useful terms

Structure of an ASHWID

An ASHWID encapsulates several individual hardware characteristics of the particular device on which an app is running. The ASHWID is deliberately designed to be different for each app/package so as to prevent system wide behavior targeting and to protect the user’s privacy. The ASHWID is not designed to enable platform wide advertising scenarios.

An ASHWID is generated using the components that make up the device. Each component, when present, contributes to a section of the returned ASHIWD byte stream. Nine components are listed below:

1. CPU ID of the processor
2. Size of the memory
3. Serial number of the disk device
4. Network adapter (such as NIC MAC address)
5. Audio adapter
6. Docking station
7. Bluetooth address
8. Mobile broadband device ID
9. BIOS

An ASHWID may not comprise of exactly nine component IDs. Possible reasons include:

• The target hardware may not have exactly nine individual components. For example, your desktop is unlikely to have a docking station.
• The device may have multiple components of the same type. For example, there may be two audio adapters.
• Each physical disk drive contributes a component ID. A desktop system with 3 physical disk drives returns 3 component IDs.
• When connected to a docking station, a tablet returns the component IDs for the additional network (Ethernet) adapter and the audio adapter (from HDMI or the analog audio out port).

As shown below, you can identify the section of the byte stream that represents each component.

The byte stream consists of multiple groups of four bytes. The first two bytes contain the type of the component and the next two bytes contain the value. Use the table below to identify the type of each component:

Sample ASHWIDS

The order of enumeration of the different component IDs is not necessarily sequential. The following streams show a few sample ASHWIDs. Note that in the stream the number of component IDs as well as their order can vary.

• 7,0,124,215,3,0,206,143,8,0,128,55,5,0,12,222,5,0,128,255,6,0,1,0,4,0,20,22,4,0,48,155,1,0,250,155,2,0,162,217,9,0,92,101

  Mobile Broadband found on Samsung Intel Core i5 slate.

• 7,0,124,215,3,0,206,143,8,0,128,55,5,0,126,129,5,0,12,222,5,0,128,255,6,0,1,0,4,0,20,22,4,0,48,155,4,0,178,193 ,1,0,250,155,2,0,162,217,9,0,92,101

  Three different audio adapters on the same device when docked and three different network adapters when docked.

• 3,0,188,97,3,0,76,128,3,0,250,138,5,0,220,130,6,0,1,0,4,0,20,164,1,0,204,49,2,0,226,37,9,0,22,72

  Three different disks found on a desktop.

• 3,0,24,211 ,5,0,182,46,5,0,54,49,6,0,1,0,4,0,203,9,1,0,148,99,2,0,162,255,9,0,140,234

  Nvidia Tegra 3 device. You may notice that the stream " 6,0,1,0" corresponds to the docking station, regardless of device or form factor.

Generating the ASHWID on the client

Using the API

HardwareIdentification.GetPackageSpecificToken method provides a means for Windows Store apps to generate an ASHWID of the device they are running on. Two apps calling this API return different ASHWIDs on the same device. For a given app/package, the ASHWID is not affected by:

• OS re-installs
• A push button reset
• OS SKU upgrade
• Version updates for an app
• Changing users on the same device

The cloud service component of a Windows Store app can validate that the ASHWID is genuine by using an optional nonce, the signature and the certificate. This WinRT API is available via a projection in every supported programming language.

Using an optional nonce

An app has the option to pass in a cryptographic nonce as an input to theGetPackageSpecificToken method. By providing a different nonce every time, the cloud has the ability to verify that the returned ASHWID actually came from Windows and was not replayed by the user. A nonce helps to validate the freshness of the ASHWID and provides mitigation against replay attacks. If a cloud service makes use of a nonce, it has a way to check whether the ASHWID was generated after the cloud service had sent the nonce. Passing in a null nonce is not recommended unless your cloud service is not concerned about replay attacks.

Sample client side code

See HardwareIdentification.GetPackageSpecificToken for examples of client side code to create an ASHWID.

Processing the ASHWID in the cloud

Accounting for hardware drift

The components that make up a device can change. This change is referred to as ‘hardware drift’. The ASHWID from a given device may change for a variety of reasons depending on when it is queried:

• Users may decide to upgrade or augment their existing devices resulting in a change in the components that affect the ASHWID.
• Users may temporarily connect peripherals to their devices that add to the list of components.
• Power management devices (for slates and devices running on ARM processors) might switch off certain hardware components to conserve battery life.

Hardware drift is the reason why the app should not consume the ASHWID byte stream as is. If a few hardware components change or are switched off, the API returns a different ASHWID. The app risks the possibility of incorrectly identifying the same device as a new device. Here are some plausible scenarios that may cause hardware drift:

• Towards the end of the day, a user wants to make the battery last until she gets home, so she switches off Bluetooth and Wi-Fi, while keeping 3G/4G on for connectivity with the cloud.
• A user plugs in a USB 3G data card.
• The underlying OS/System on Chip power management may switch off certain cores.

In each situation, one of the ways the app can account for hardware drift is to compute a score by attaching weights to each of the returned component IDs based on its business logic. The computed score must pass the threshold set by the cloud component to be identified as the same device.

Below is a simple illustration for just one way you can handle hardware drift within the cloud service:

If  [(Component_1_previous == Component_1_current) x Weight_1 + 
(Component_2_previous == Component_2_current) x Weight_2 + 
(Component_3_previous == Component_3_current) x Weight_3 + ……..
(Component_n_previous == Component_n_current) x Weight_n]  
>= [Threshold_for_being_the_same_device]
Then It_is_the_same_device  

Using relative weights in device identification

Relative weights depend on your business logic and what you determine to be an acceptable hardware drift. No explicit recommendations are made for the value of the weights. Some components are less likely to vary than others and deserve higher weights. For example, the BIOS is less likely to change than the audio adapter. Multiple disk drives may show up depending on the number of drives connected to the system. The component ID for the drive that the OS is installed on is less likely to change. The processor component ID on most x86/x86-64 systems is pretty stable. If you find that the docking station component returns the same component ID, it would make sense to assign a zero weight to it.

Authenticating the ASHWID in the cloud

The returned ASHWID is signed. This provides a means for the app to verify that the returned ASHWID came from Windows. Passing in a shifting nonce as input protects against replay attacks.

The ASHWID is hashed using a private key in the client. The diagram below shows the format of the signature.

Certificate Revocation lists

There is a remote possibility that the private key is compromised. If this happens, your app (client or cloud) does not need to have extra code to update the key as long as you enable revocation checking for all certificates in the chain.

Guidance for the cloud side workflow

Here is a workflow that the developer of the cloud side component may follow. Upon receiving the certificate, signature and the hardware ID , these steps verify the authenticity of the ASHWID:

1. Verify the trustworthiness and the validity of the certificate. This step assumes that the “Microsoft Assurance Designation Root 2011” root certificate is trusted on the cloud system. The root certificate needs to be manually added to the trusted root store on Windows-based servers.
   1. Certificate blob has the PKCS#7 formatted certificate chain. Build and verify that the cert chain is trusted. Trust chain verification failures due to expired leaf cert should be ignored.
   2. Make sure the certificate chain is checked against revocation failures. It is recommended to ignore the revocation failures due to offline CDPs.
   3. Check to make sure the leaf certificate has the “1.3.6.1.4.1.311.10.5.40” EKU.
   4. Query the public key for the root certificate in the cert chain, and check it against the public key of the “Microsoft Assurance Designation Root 2011” root certificate to make sure they match.
2. Verify that the ASHWID is genuinely produced by trusted Windows code.

   1. Signature blob is the signed blob of the SHA1 hash of the concatenation of the nonce (when present) and the ASHWID.

   2. Use the leaf certificate to verify that the signed hash signature matches the original nonce that was sent from the cloud service and the received hardware byte stream.

Related topics

App Specific Hardware ID (ASHWID) cloud component

HardwareToken

HardwareToken.Certificate

HardwareToken.Signature

HardwareIdentification

HardwareIdentification.GetPackageSpecificToken