This article is presented at CansecWest 2019 by Ejin Kim and Prof. Choi. The technical details of the attack are available in our slides.

Introduction to Windows Hello

Windows Hello is a new login mechanism for Windows 10. Windows Hello has replaced a password-based login by using a PIN or a biometric, called a gesture. In the front end, a user uses a few digits of the number as a PIN. But in the backend, an asymmetric key is used to verify the user’s credentials to Microsoft ID servers. Besides, Windows Hello provides a single sign-on service to users for accessing Microsoft services such as MS store, OneDrive, Outlook and so on.

This new login mechanism has many advantages.
First, Windows Hello is user-friendly. Its PIN is easy and simple to remember without sacrificing security. In case a biometric is used as a login material, you do not need to remember anything.
Second, Windows Hello enhances the security of Windows authentication. A security level of Windows has been raised by multi-way authentication in that the first authentication with a PIN and the second with a private key. The PIN is tied to a specific device and a user so that an attacker must steal the device, too. Authentication data is securely saved in a trusted platform module(TPM).

In this post, deployment of Windows Hello and security based on the above observations. Is the PIN, in fact, secure in the real world where we cannot assume most PCs have the TPM, yet? If that is the case where those authentication data are stored and how they are handled inside the kernel?
We barely found official documentation for Windows Hello internals. Some documentations found were quite abstract. We thought it would be beneficial for security researchers and engineers to have one good documentation about Windows Hellos in detail.

We tackle the fundamental questions regarding how Windows Hello works: 1) What data is exchanged and how are they exchanged between a PC and a server for authentication in Windows Hello?
2) Where in a PC are those authentication data stored?
3) Is it possible to migrate those data to another PC by manipulating those authentication data?
We address these questions through an analysis of network protocol and client-side procedures.

Windows Hello Basics

Windows Hello is set up in two phases: Registration and login phase.

Registration phase

For an account in a PC where Windows is running, a user has an option to create a local account or to associate an MS account with the local PC. A user may choose the second option for synchronizing multiple PCs he or she owns.

If the user wants to register Windows Hello using the local account, choose a PIN option in the “Sign-in options” menu in Control Panel. By default, a PIN is only a number and its length is 6 digits although a user has an option to choose it between 4 to 127 digits. In the background, Windows generates a public and private key pair for a user and encrypts a private key with a user’s gesture, in this case, it is a PIN. This is the Windows Hello registration for a local account.

For an MS account, a user must select a “Sign in with a Microsoft account instead” option. The registration for an MS account is the same as a local account except for the extra two steps. As the fourth step, the PC registers the user’s public key at the Microsoft ID server. The ID server returns the Key ID if the registration is successful.

Login phase

A local account is used for unlocking a PC. An MS account is used not only for unlocking a PC but also for accessing MS services as well as unlocking a PC. In other words, two login types are using Windows Hello: PC login and MS service login.

Network Protocol Analysis

The goal of protocol analysis is to figure out what data is transferred to prove a user, an account, and a PC. To do this, we analyzed the data exchanged with the server when Microsoft’s account was registered.  During the analysis, we found that various tokens were used to authenticate the user, the account and the PC. For accurate analysis, we analyzed from the point of installation of the Windows operating system.

Considerations

Windows Hello is based on legacy systems that have been used for over 20 years. For backward compatibility, the mix of old technologies to the latest standards has made it difficult to analyze. And a protection technique with transport layer security(TLS) is applied to all data packets. Additionally, the data associated with authentication tokens sent by the server was double-encrypted with XML encryption.

We used a man-in-the-middle tool for bypass TLS for all data packets. This allows us to sniff all HTTPS packets that are communicated with the server. As shown in the figure on the above, the server transfers some of the data by XML encryption. Windows live id service(WlidSvc), which performs parsing of XML, is responsible for handling XML encryption. WlidSvc is a service that performs an operation related to the Microsoft account login. To figure out how it handles XML encryption, we performed dynamic debugging of that service. As a result, the ngcdecryptwithsymmetricpopkey() function decrypts XML encryption.

Details

The analysis was conducted on the following four steps: 1) Install Windows operating system, 2) register the Microsoft account, 3) setup the gesture and 4) login to the services with the gesture.

1) Install Windows Operating System

First, when a client connects to the Internet after installing Windows, the Microsoft Account Service sends device information to the ID server. The ID server registers the information and forwards DeviceToken to the client. The DeviceToken is used for verifying that the device is registered with the Microsoft server. This token is not related to the Microsoft account.

2) Register Microsoft Account

Later, when a user switches a local account to a Microsoft account using “sign in with a Microsoft account instead” option, the ID, the password, and the previously received DeviceToken are sent to the ID server. The ID server then returns AccountToken, which will be used for proving the account. This token is onetime, so it is renewed each time used.

3) Setup Gesture

Next are the details of the gesture setup phase. First, when the user clicks the “set up the gesture” button, the client sends AccountToken and DeviceToken to the ID server for issuing a temporary login token. Then the ID server returns the double encrypted user information, the temporary token, called LoginProofToken and the renewed AccountToken. When the user enters a new gesture, the client generates a key pair and sends the public key with LoginProofToken to the ID server. If the dependency between the account and the public key is successfully created, the ID server returns the key ID.

4) Login to Services with Gesture

This is the last protocol for Windows Hello, login services with the gesture. When the user requests the login, the ID server returns the challenge. At this point, a popup window for gesture entry is displayed, and the private key is used to sign the challenge. The signature and previously received AccountToken and DeviceToken are sent to the ID server. The signature value is verified by the user’s registered public key and the ID server issues an AccessToken for the service requested to login. The user who wants to access the service sends this token to the service provider for authorization.

Change and Delete Gesture

When the user changes or removes the gesture, the device does not communicate with the ID server. If the user changes the gesture, the existing private key is re-encrypted with the new gesture. If the user removes the gesture, the private key is removed together.

Please contact author if you have any questions.
ejin@o365.skku.edu