Managing the Device's Secure Clock

3.2.5.5.1 Initializing Secure Clock

If a secure clock is unset on a device, or has not been yet been verified via the secure clock protocol, the device MUST attempt to set the clock using the secure clock protocol.

3.2.5.5.2 Issuing a Petition for a Secure Clock Challenge

The client MUST issue a new petition for each new secure clock challenge. The secure clock server MAY deny a secure clock challenge that has not been petitioned. Therefore, it is important that the client does not cache petitions.

The client obtains the petition URL from stored device configuration. In typical DRM-CD

implementations, the URL is stored in the device certificate, and is retrieved by parsing the device certificate's SECURECLOCK XML node. The petition URL is located in the URL tag under the SECURECLOCK XML node.

The client submits a petition request to the petition URL and waits for the server's response. The petition request is a plain HTTP/1.0 GET request, as specified in section 2.2.2.1.

If the petition URL contains "https", the client SHOULD use SSL for the connection. If SSL is used, the client SHOULD check the server's certificate to ensure it is current, matches the domain, and is properly signed by a trusted authority.

The client MUST be prepared to follow HTTP [RFC2616] redirections during the petition. If the secure clock server responds with "HTTP 301 (Moved)" or "302 (Redirect)", the client MUST use this

redirect URL as the new petition URL and start again by submitting the petition request to the redirect URL.

If the secure clock server responds with "HTTP 200 (OK)", the client reads the entire body of the response for the secure clock challenge URL. If successful, the client proceeds to the next step, submitting the secure clock challenge.

A valid petition response has the format as specified in section 2.2.2.2.

3.2.5.5.3 Submitting a Secure Clock Challenge

The client MUST then submit the secure clock challenge to the secure clock server. To generate the secure clock challenge, use the DRM_MGR_ClkGenerateChallenge function. Then, the client receives a secure clock response message.

3.2.5.5.4 Posting request to the secure clock challenge URL

The client submits a secure clock challenge request to the secure clock challenge URL and waits for the server's response. The secure clock challenge request is an HTTP/1.0 POST request as shown in section 2.2.2.3.

The client obtains the secure clock challenge URL from the petition. There MUST be one petition for each secure clock challenge.

Typically, SSL is not used in this step, but the client MUST be prepared to handle SSL if the secure clock challenge URL uses it. If SSL is used, the client SHOULD check the secure clock server's certificate to ensure it is current, matches the domain, and is properly signed by a trusted authority.

Optionally, the client can verify that the certificate belongs to a known Microsoft secure clock server.

3.2.5.5.5 Setting a Secure Clock

A secure clock on a device is one that is set by accessing a web-based secure clock server and cannot be changed by the end user. The secure clock protocol uses a public-private key pair for communication between the server and the device.

On those devices that support a secure clock, the process of setting the clock is as follows:

1. For devices that are not web-enabled, when the device connects to a computer, the media player retrieves the version and device certificate to determine whether the device has a secure clock.

Then, the media player requests the device clock status to determine whether the clock needs to be set.

2. For devices that are web-enabled, the device determines whether its clock requires setting.

3. If the device has a secure clock that needs to be set, the device sends a secure clock challenge (directly, or indirectly through the media player on the computer) to the secure clock server.

1. The secure clock server sends a secure time response, signed with a secure clock private key, to the device, directly or indirectly through the media player on the computer.

2. The device verifies the signature on the secure time response by using the secure clock public key and sets its clock.

The following diagram shows the keys that are used when setting the device's secure clock.

Figure 3: Keys used on the devices secure clock submitting the secure clock challenge 3.2.5.5.6 Create a Secure Clock Challenge

Once a petition URL has been retrieved, the client builds a secure clock challenge message. To compose the message, a randomly generated, unique TID is created, and the petition URL is copied into the message. The message type is set to "challenge".

Finally, the entire message is base64-encoded as documented in [MS-DRM] section 2.2.1.1, and sent to the secure clock server.

3.2.5.5.7 Posting a Secure Clock Challenge

The client posts a secure clock challenge as specified in section 2.2.2.3.

The client MUST be prepared to follow HTTP [RFC2616] redirections during the petition. If the secure clock server responds with "HTTP 301 (Moved)" or "302 (Redirect)", the client MUST use this

redirect URL as the new secure clock challenge URL and start again by submitting the secure clock challenge to the redirected URL.

If the secure clock server responds with "HTTP 200 (OK)", the client reads the entire body of the response for the secure clock challenge URL. If successful, the client follows the procedure as documented in the section 3.2.5.5.5.

Upon receiving a secure clock response message, the device first base64-decodes the response as documented in [MS-DRM] section 2.2.1.1, putting the message into its raw XML format.

It then verifies the SIGNATURE element over the DATA element using the accompanying CERTIFICATECHAIN. The device MAY also verify that the certificates in the CERTIFICATECHAIN validate to a trusted certificate root for secure clock processing.

The SIGNATURE element MAY subsequently be validated against its own configuration data, which contains the public key of its configured secure clock server. In typical Windows Media Digital Rights Management (WMDRM): MTP Command Extension implementations, the secure clock server's public key is stored in the device certificate, and is retrieved by parsing the device certificate's

SECURECLOCK XML node. The public key is located in the PUBLICKEY tag under the SECURECLOCK XML node.

Once the DATA element has been validated, the TID is validated against the TIDs of secure clock challenges previously issued by the device. If the TID cannot be located, the device MUST stop processing the secure clock response message.

Upon validating the TID, the device SHOULD synchronize its internal clock to the value in the

GMTTIME element. The device SHOULD also store the time value from the REFRESHDATE element to indicate the time a new secure clock challenge should be sent.