What year is it?

<Insert Robin Williams’ Jumanji meme here>

(http://i1.kym-cdn.com/entries/icons/original/000/007/784/what-year-is-it-robin-williams.jpg)

Most network security protocols rely on the use of keys that expire after a certain amount of time. This appears to be a plain vanilla statement until you think more about it. Timekeeping over long periods of time is a critical for tracking lifetime and expiry of security keys. We innately understand the passage of time and take it for granted that our computers and devices will automatically do this for us with reasonable accuracy and certainty required for key rollover.

Computers have to keep track of time when they are running and even when they are turned off. The latter functionality is the only way to know what time it is when they are turned back on again (and thus which keys are valid and what are not).

PCs and big form-factor hardware have a dedicated battery to power the clock and we barely notice anything is amiss when we power-cycle them. Miniaturization of consumer devices has led to the elimination of the on-board dedicated CMOS battery, whose function is now delegated to the main device battery.

One of the annoying things about batteries is that they run out of power, almost always when we need it most. As the battery depletes and then drains completely, the time keeping function it supports also stops. The devices powered up from this state typically start up with their clock set to a random time value. This presents a little problem in keeping track of the keys use in network security protocols – i.e. the device cannot connect securely to the outside world without intervention to correct its clock.

You may ask – why doesn’t the device ask the nearest time server for the time over the network? Unless you choose to ignore network security or at least punch some holes into it by making exceptions, communicating securely over the network is a nonstarter.

To summarize the issue, grossly incorrect system time can cause network security to be impaired, which in turn prevents obtaining the current time over the network. This is a classic circular dependency.

You may have experienced this problem on your tablet or mobile device in the form of connectivity issues to secure services. Increasing use of sleeker/smaller devices means this issue is bound to occur widely, impacting the users of these devices. Devices with aging batteries will start to experience this problem more often, contributing to the frequency of occurrence of this issue. It could also occur on PCs and servers when their CMOS battery drains (a rare event, but a certain event nonetheless).

Asking the users to check their system time when they cannot get their emails or when they cannot sign on to their websites or when they cannot sign into their AD domains will get old really fast. We had to address and solve this problem at a system level.

Solutions to this problem

Hosting a custom “Secure” Time Service:

A solution is for the client to obtain current time from a server over a protocol like SSL, ignoring errors in time-related protocol validations on the client. Any exceptions to the security validations requires thorough scrutiny since we are opening the client to potential attacks, which in part makes this an unfavorable solution. Additionally, we have to maintain a server available at all times and the clients may or may not be able to reach said server from the network they are on – additional challenges that reduces the effectiveness of this solution.

Secure Time Seeding – a client-side solution:

We started looking for solutions that would not require us to make security exceptions and SSL protocol contained the solution we were looking for. We decided to take an approach to only trust the SSL connections that can be established based on the certificates installed on the client, with no new update mechanisms for the certificates – i.e. a mechanism that is not very different from the one we had before.

SSL protocol allows a client to securely participate in a handshake with a server and perform time-related validation towards the end of the handshake (certificate validity using the local clock). Essentially the client trusts the certificates installed locally to perform the handshake, but it may not trust the server enough to establish the connection because its local system time indicates the server’s certificate chain is invalid.

The SSL handshake contains encrypted/signed time metadata that can be used by the client to determine the current time. This secure metadata will help us to break the cyclical dependency between system time and secure protocols including SSL.

We are interested in the following two pieces of metadata from the SSL handshake:

1. ServerUnixTime, an informational field.
2. OCSP validity period, which is part of the cryptographically signed data obtained from optional stapled OCSP packet that has been tacked on to the SSL certificate chain presented by the server to the client.

The ServerUnixTime is supposed to be the current system time on the server, but it can also be set to a random value by some SSL implementations. We have observed that a majority of servers provide a fairly accurate value in this field and the rest provide random values. We use this data field assuming it is somewhat accurate but can also be incorrect.

Stapled OCSP packets provide a very reliable time range, but it has low adoption on the internet and the time range can be as long as a week, making it not very suitable for use by the system clock. However, in case where the system clock is off by weeks/months/years, setting the system clock to within a week’s accuracy is certainly a huge improvement. This time range data can be used by itself or combined with the ServerUnixTime to improve the accuracy of the time range.

We have taken the approach to not trust a lone server providing us with encrypted or signed metadata, irrespective of who the server identifies itself as. We rely on corroborating information from other servers and use that to arrive at a common truth about the current time.

The SSL connections made from the client are randomly interspersed in time and the metadata they provide follows suit as well. Our algorithms corroborate the data and determine reliable range for the current time. The information from ServerUnixTime and OCSP validity periods are merged to produce the smallest possible reliable time range value along with a confidence score. When the confidence score is sufficiently high, this data becomes information.  We are calling this as Secure Time Seed of High Confidence (STSHC).

STSHC is actionable information and it is used to correct grossly incorrect system clocks (i.e. seed them with a good value). After this occurs, a more accurate time synchronization is expected to be carried out using NTP (secured or unsecured) to bring the system clock close to the current time. In fact, both of the clock correction functions are performed by the Windows Time Service (W32Time).

A grossly incorrect system clock may cause the initial few SSL connections to fail, but the calling client applications tend to retry the calls after a short time. STSHC may have been established and the system clock corrected when the retry occurs and the retried SSL calls would likely succeed. This provides a very seamless experience for the end users, instead of them having to diagnose errors originating from SSL certificate validation failures due to incorrect system time. This is a big win for the overall user experience with SSL.

STSHC is also used to monitor the system clock for gross errors and correct those at the next chance. This adds another obstacle to tampering the system clock or even flaky clock hardware.

Does this work?

The Secure Time Seeding feature was shipped in the Windows 10 November release and it is turned on by default. You may have seen the improvements in timekeeping on your Windows tablets and other Windows devices running this version of the OS. We have seen it work time and again given the prerequisites are met.

I want to see this in action

This feature requires W32time Service to be enabled (“Set Time Automatically” Date-Time UI setting enabled), internet connectivity and outgoing SSL traffic from your machine or device in order to function. Assuming you have the above prerequisites met, you can watch this feature in action by moving your system clock forward or backward by a week or longer and watch it get corrected after a short duration.

I trust my hardware clock and time synchronization mechanisms. I don’t want this!

If you would rather trust your system clock than time data generated from your SSL traffic and want to forgo any benefit this feature gives you, we got your back. Set the following registry value to 0 and reboot your machine and the Secure Time Seeding feature will be disabled. (Standard warning about exercising care while modifying registry applies here).

Registry Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig

Value Name: UtilizeSslData

Value Type: REG_DWORD

I changed my mind and want the feature back on.

Just set the above registry value to 1 and reboot your machine. Please remember that W32time service must also be enabled (“Set Time Automatically” setting in the Date-Time UI). (Standard warning about exercising care while modifying registry applies here as well).

Feature Availability

This feature was first introduced in Windows 10 Client November release (November 2015 release). It is available in both Windows Server 2016 and Windows 10 Client Anneversary releases. The feature is turned on by default in all these versions of the OS.

Known Issues

We have a known issue related to this feature in the Windows 10 Client November Release.  This issue has been fixed in the Windows 10 Anneversary Release.  Refer to KB article 3160312 for more details.