At the Microsoft Ignite conference this week, there are several sessions covering Windows 10 features. One of biggest changes in Windows 10 is the new credential management method and the related “Next Generation Credential”, now named Microsoft Passport.
There hasn’t been much information on how the new credential system works, so I challenged myself to gather as much information and understand it as best as possible before the Microsoft Ignite conference ends this week. This post covers my understanding of this (still beta) technology.
Note that the information in this post is subject to change (& my misunderstanding). As I gain clarification, I will update this post.
1/28/2016 Update: Microsoft published a whitepaper on Microsoft Passport and Windows Hello. This post will soon incorporate this information.
Microsoft has resurrected the Passport moniker for a new PKI credential system that requires multi-factor authentication.Most interesting about Microsoft Passport is that it fully supports the Fast IDentity Online (FIDO) Alliance standards which means it will work with many web/cloud services without modification. The plan is that users of cloud services supporting FIDO is that there will no longer be passwords associated with the user’s account.
Microsoft Passport involves a user logging onto the Windows 10 computer with multi-factor (PIN, face, iris, fingerprint, etc) and either creating a new account or associating an existing account with an IDentity Provider (IDP). Windows generates a public/private key pair with the private key stored securely outside of the Windows 10 OS. The public key is associated with the account so that a challenge can be sent that can only correctly respond to the IDP. Another key point to the Microsoft Passport credential system is that the user needs to enroll every device used to access the service (IDP).
Microsoft Hello provides simple multi-factor authentication using facial recognition (or iris, or fingerprints) that is used to access the Microsoft Passport private key stored in the secure TPM chip. For the first time, Microsoft has included the biometric software (middleware) in Windows 10 to support biometrics for authentication. In previous versions of Windows, the OEM (HP, Dell, Lenovo, etc) needed to add its own biometric middleware to support biometric authentication.
Traditional Windows Credential Management
Up until Windows 10, when a user logs on, the user’s credentials are verified, hashed, and loaded into LSASS (Local Security Authority Subsystem Service), a process in protected memory. The user credential data is stored in LSASS for authenticating the user to network resources without having to prompt the user for their password. The issue is that up until Windows 8.1, the user’s clear-text password (reversible encryption) is no longer placed in LSASS, though the user’s NTLM password hash, among others, are still stored in LSASS. When using Kerberos, the user’s Kerberos tickets are stored in LSASS.
Virtual Secure Mode (VSM)
Windows 10 leverages a new Hyper-V component called Virtual Secure Mode (VSM) which is a protected VM that sits directly on the hypervisor and is separated from the Windows 10 OS (& kernel). This architecture protects the VSM even if the Windows 10 OS kernel is compromised since the kernel doesn’t have direct access to VSM. The VSM wasn’t designed exclusively for protecting Windows 10 credentials, it is a key component in Windows 2016 Hyper-V for supporting “Shielded VMs”. The goal behind Shielded VMs is to provide the ability to protect a VM’s data and configuration from the Hyper-V admin. Shielded VMs greatly mitigates security concerns surrounding virtualizing sensitive servers, such as Domain Controllers. The architecture enables true separation of the virtual host from VSM since both run on the hypervisor.
With Windows 10, the OS is effectively split between what is called the “High Level OS (HLOS)” and the “Isolated User Mode (IUM)” with HLOS being the what we are traditionally used to as the OS (LSASS runs here). The IUM is the new VSM component that hosts a new secure process called LSAlso that stores the credential secrets. Credential secrets are no longer stored in LSASS. Request for credential data goes through a special API that queries LSAlso in IUM.
A simple visualization of this structure:
| IUM | HLOS |
| HYPERVISOR |
VSM (IUM) runs a small, secure, proxy kernel called SKERNEL or SMART which has no GUI or ability to logon. No third party code can connect to this kernel including drivers. Microsoft effectively moved the LSASS process which is where all credential data is held for logged on users (& running service accounts) into the VSM protected environment in order to protect credentials from being dumped by an attacker with admin rights on the system. LSASS is still in the Windows OS, though there are not credential secrets in this process. A new LSASS type process called “LSAlso” is now in VSM and separated from the Windows 10 OS kernel. The only way for Windows 10 to communicate with LSAlso is via a new API through new special code called “trustlets”. LSASS sends the credential request through a trustlet to LSAlso (in VSM) and receives an answer, though not the secrets behind them. This is why Microsoft refers to LSAlso as the “oracle”.
Microsoft Passport operates a lot likes smart cards do and is, in effect, a virtual smart card. A smart card has to be registered with an IDentity Provider (IDP) and has a private key locked within it that can’t be extracted. There is a challenge sent to the smart card that only the private key can respond to properly. The Microsoft Passport credential works in a similar manner
Microsoft Passport requires a TPM v2 for hardware assurance. The TPM space has a Default Container which contains consumer identities (from IDentity Providers) and an Enterprise Container for work identities. When a new user is enrolled on a Windows 10 device for a Microsoft Passport account, a public/private key pair is generated with the private key stored in the appropriate TPM container. Access to the private key is controlled by the user’s PIN and/or face, iris, or fingerprint. The keys are encrypted and protected by the TPM.
Active Directory Passport User Enrollment
When an Active Directory user is enrolled on a Windows 10 device, the user’s public key for that device is added to an attribute on the user account in AD (requires Windows Server 2016 schema). Note that each Windows 10 device the user logs onto will generate its own public/private key pair and that public key is added.
As I understand it today, SCCM and Group Policy are used to ease the enrollment process.
Standard AD User Kerberos Authentication
When a standard AD user logs on to Active Directory (using Kerberos), the user’s long term key (derived from the NTLM password hash) is used to encrypt a time stamp (nonce) as part of the authentication process. Once the requester has proven knowledge of the user’s username & password (really the password hash) the user is authenticated (AS-REQ). The DC generates the authentication ticket (TGT) for the user encrypted & signed with the domain Kerberos service account’s password hash (KRBTGT) – the user can’t view the contents of their TGT ticket. When the user needs to access a Kerberos enabled service on the network (Exchange mailbox, share, etc), the user’s TGT is sent to a Domain Controller as part of the service ticket request (TGS-REQ). The DC opens the TGT, copies the data into a new ticket, service ticket (TGS), which effectively has two parts, on which is encrypted with the user’s encryption key (NTLM password hash) and the other which is ultimately delivered to the resource to authenticate the user to the service (encrypted by the service’s account’s NTLM password hash).
Microsoft Passport & Active Directory
With Microsoft Passport in an on-premises Active Directory environment. The user’s public key which matches the device the user logged onto, is used as the user’s Kerberos long term key (or at least a derivative of it). This means that two things have to happen first: 1) the user’s public key for every device they use needs to be associated with the user’s AD account, and 2) the DC has to quickly identify which public key to use for the user which means that either the AD user account stores a mapping from the computer name to the associated public key or the user identifies the public key to use during the session. My understanding is that the public key in use is identified during the initial communication with the DC. Regardless, it needs to work within the Kerberos protocol and be very fast.
There are several new attributes for the user object class in the Windows Server 2016 (TP2) which may be related to the new Microsoft Passport (MS Schema Attribute Documentation, attributes are for “Windows Server vNext” & subject to change):
- The approximate time this key was last used in a logon operation.
- This attribute contains key material and usage information.
- This attribute is the backlink for msDS-KeyCredentialLink.
- This attribute contains a key identifier.
- This attribute contains key material.
- This attribute specifies the principal to which a key object applies.
- This attribute is the backlink for msDS-KeyPrincipal.
- This attribute identifies the usage scenario for the key.
Continuing the scenario, the Microsoft Passport AD user sends an AS-REQ request to the DC to get a TGT (authentication key) with the nonce encrypted with the user’s long term key – the user’s Passport private key on that device (which is decrypted using the associated public key). The DC challenges the user to confirm the user has knowledge of the private key for that device (Note: not sure if the nonce is enough, or if there’s a separate challenge).
Resulting TGS components that are encrypted for the user are encrypted with the user’s Passport public key for the device the user is logged onto.
According to Microsoft sources at Ignite, the user’s TGT is stored in LSASS within VSM, though I don’t have a definitive answer on the TGS location.
Microsoft Passport and NTLM Authentication
When a NTLM password hash is required, such as when a user connects to a resource that doesn’t support Kerberos, the hash is generated and stored in LSASSwithin VSM. Windows 10 doesn’t “leak” this password hash. VSM generates an NTLM “token” derived from the user’s NTLM password hash. This NTLM session token is effectively locked to the device the user is logged onto and is only active while the user is logged on (though it’s possible it could be tied to the user’s session with the NTLM service). This NTLM session token is used to authenticate the user which is passed from the resource to the DC. The Domain Controller validates the NTLM authentication request and replies back to the resource. The Domain Controller has to have the same method for generating the NTLM session token from the user’s NTLM password hash. This ensures that the DC and the Windows 10 computer both achieve the same result, the generated NTLM session token.
The primary question still outstanding (for me) relates to device-locking the user’s Kerberos long term key. This doesn’t affect TGT usage since the DC accepts it as is assuming it can open the ticket; however, if the user’s long term key is tracked in the TGT and used to encrypt the user’s portion of the TGS, does that prevent reuse of the user’s TGT by an attacker to get new TGS tickets on other devices? Realistically, use of the TGT would result in valid TGS tickets, but the attacker on another device wouldn’t have the user’s long term key to decrypt the user component of the TGS to have the session key. But does that even matter? This wasn’t a question before because with the user’s NTLM hash, the attacker has access to this ticket data.
Also, until an organization upgrades to an all Windows 10 environment, probably with Windows 2016 on all resource servers, it seems like the support would have to still exist for NTLM password hashes as the user’s Kerberos key. Hopefully Microsoft enables the ability to enforce Microsoft Passport authentication by user group.
- PKI Authentication (On Premises Active Directory)
- Windows Server 2016 schema update
- Windows Server 2012 R2 Domain Controllers
- Windows Server 2016 ADFS for enrolling the Windows 10 devices.
- Key-based Authentication (On Premises Active Directory)
- Windows Server 2016 schema update
- Windows Server 2016 Domain Controllers
- Windows Server 2016 ADFS for enrolling the Windows 10 devices.
- User credential secrets (NTLM password hash, Kerberos TGT, etc) are stored in LSAlso within VSM which means that traditional methods for dumping system credentials will not work using the same techniques.
- Windows 10 & Windows Server 2016 need to be deployed for the security benefits.
“Microsoft Passport consists of three sets of keys:
- KNGC pair of asymmetric keys
- Always require a user gesture (pin or bio) for an authentication operation
- HW attested, SW as a last resort
- KIDP key(s) (symmetric or asymmetric)
- Delegated by KNGC keys
- Do not require a user gesture
- long lived
- If symmetric, wrapped with a transport key (transport key is attested)
- KRP, used to access RP resources
- Delegated by KIDP key
- Do not require user gesture
- Symmetric and short lived”
“The private key is made available solely through a “user gesture” like a PIN, biometrics, remote device like a smart card that the user used to log on to the device and this information is linked to a certificate or an asymmetrical key pair. This private-key is hardware attested if device has a Trusted Platform Module (TPM) chip. The private key never leaves the device.
The public key is registered with Azure Active Directory and Windows Server Active Directory (for On-Premises). The Identity Providers (IDPs) validate the user by mapping the public key of the user to the private key and provides log on information through One Time Password (OTP), Phonefactor or a different notification mechanism. “