Skip to content

Latest commit

 

History

History
290 lines (178 loc) · 34.9 KB

Overview.md

File metadata and controls

290 lines (178 loc) · 34.9 KB
Raw

Device Bound Session Credentials for Enterprise - explainer

This is the repository for Device Bound Session Credentials for Enterprise. You're welcome to contribute!

Authors

Contributors

Participate (TBD links)

Table of Contents

Overview

Device Bound Session Credentials for Enterprise - DBSC(E), is an enhancement to the existing DBSC proposal. It refines the key generation mechanism resulting in additional security for enterprise use cases. It aims to provide a mechanism for enterprise customers to be able to deploy enhanced/customised device binding for any browser session, hence protecting against session hijacking and cookie theft.

Why DBSC(E)?

While the original DBSC proposal enables browsers to bind session cookies to a device providing protection from network based attacks, it still remains vulnerable to "on device" malware. Temporary malware on the device can inject its own binding keys when the DBSC session is being established during any signin operaton. If a DBSC session is already established when the malware gains access to the system, the malware can force a new signin operation, and potentially hijack all subsequent sessions.

DBSC(E) aims to mitigate this risk by introducing the concept of one-time protected device registration operation and binds all the future sessions to binding keys that can be cryptographically proven to be on the same device. DBSC(E) is able to provide this risk mitigation if the device registration is a protected operation, meaning it is performed in a "clean room") enviroment e.g. an organization registering a device before giving a device to an employee. As device registration is expected to be a one-time operation, the user will not be required to perform this operation again, reducing opportunities for malware to compromise a user session.

If device registration is executed in a clean room and precedes any sign in sessions, malware would not be able to bind session cookies to malicious binding keys during a sign in operation that implements DBSC(E).

Note: While DBSC(E) hardens security against temporary malware attacks, if the malware is persistent on the device, the malware can still exfiltrate data.

How does it integrate with DBSC?

DBSC(E) is not intended to be a separate proposal from DBSC, it is rather building on existing DBSC, and adds the binding specific details to the protocol. It is expected that the DBSC(E) proposal will be integrated into the DBSC proposal in the specification. In the high-level design, we have folded the DBSC proposal into the end to end flow. Please read the DBSC proposal before you proceed.

Before we get into the specifics, we will introduce the terminology and design specifics for the key generation and validation below.

Terminology

Browser

In this document, "Browser" refers to the functionality in a web browser that is responsible for the DBSC protocol. This functionality will be implemented by Edge, Chrome (or their common engine), and other browsers that choose to implement DBSC/DBSC(E).

Relying Party (RP)

A web application that uses DBSC(E) protocol for cookie binding. This is referred to as server in the original DBSC design.

Identity Provider (IdP)

IdP is an authentication server that can be either external to the Relying Party or part of the Relying Party. Eg: Office.com authenticating with Microsoft Entra ID (external IDP) or google.com authenticating with google (no separate IDP). Note: The protocol doesn't change if the IDP is part of the Relying Party, except that some redirects between the IdP and the RP can be skipped or implemented by other means. In the original DBSC design, IDP and RP are the same entity, and referred to as server.

Device Registration Client

This is a pre-requisite for DBSC(E) to work.

Device Registration is a process where the user or administrator registers the device with the IdP and is expected to be a one time protected operation.

The device registration establishes trust between the device and a service that maintains a directory of all devices. This document does not cover the protocol of device registration, but it assumes that during device registration, some asymmetric keys are shared between the client and the service, typically a device key, attestation key and some other keys necessary for the secure device communication. A client software component that performs the device registration is called a device registration client. As mentioned above, the key assumption in DBSC(E) is that device registration happened in a clean room environment, and it is the responsibility of the device owner to ensure this.

A clean room enviroment is a reliable, malware and exploit free state of a system. Examples can be:

  • New device from the factory connected to a secure network during registration.
  • Company issued devices configured by admin for the employees.
  • A malware free device installing browser in a secure network.

One device registration client can manage multiple devices on the same physical device. There also can be multiple device registration clients on the same device. For example, a user can register a device to their organization as an employee and can simultaneously register the same device for a vendor organization. Both these registrations can either be managed by a single device registration client or through separate device registration clients depending on the implementation and separation between these organizations.

The device registration client can be owned and supported by:

  • Operating system - the device gets registered when the OS is installed.
  • Browser - the device gets registered when the browser is installed.
  • Device management software (MDM provider) - the device gets registered when the MDM is enrolled.
  • Third-party software vendor - the device gets registered according to the vendor rules.

DBSC(E) aims to support most of these scenarios. DBSC(E) does not define the device registration protocol, but is only concerned that the device registration is executed in a "clean room" and the management of the generated keys to prove device binding.

DeviceRegistration

Link to editable diagram

Local Key Helper

DBSC(E) introduces the concept of Local Key Helper.

Local Key Helper is an integral part of the the Device Registration Client, and is a software interface responsible for the DBSC Key management. Local key helper can be public or private and is expected to be either shipped as a part of a given enterprise framework (with the IDP/OS) or can be installed by a provider in compliance with the protocol expanded below. DBSC(E) defines browser interaction with Local key helpers for each platform below.

There are two types of local key helpers: private and public

  • Public local key helper: Expected to have a well-documented API and can be used by any Identity Provider (IdP). Typically owned by a provider different from the IdP, communicates with the IdP as defined in DBSC(E) protocol.
  • Private local key helper : Is specific to an IdP. Can be only used by a specific IDP that owns the implementation and will have a private protocol to communicate with the IdP.

The Local Key Helper is responsible for:

  • Generation of the binding key and producing binding statements (see below).
  • Producing signatures with the binding key.
  • Cleanup of the binding key and its artifacts (when the user clears the browser session or the key is unused for a long time).

Platform Requirements

This section prescribes the browser discovery process of a given local key helper for a few well known platforms:

Note: Above are platform specifications for Local Key Helpers that can be used for DBSC(E) key generation. Any vendor can ship their local key helper in compliance with the DBSC(E).

Attestation Service

Attestation service is responsible for providing the attestation statement for the binding key. DBSC(E) relies on the attestation service to enable the IDP to validate the binding statement and ensure that the binding key and the attestation key belong to the same device. An attestation service can be part of the IdP, or a separate service.

This document does not define the implementation details of the Attestation Service. It defines the artifacts which are generated during the Device Registration and are necessary to validate the binding statement.

Key Generation Specifics

There are three artifacts that are generated during/after the device registration process, which are used to prove the device binding. These are the attestation key, the binding key, and the binding statement.

Attestation Key

An attestation key is generated during the device registration process and has the following properties:

1. It signs only the private/other keys that reside in the same secure enclave as the attestation key.
2. It cannot sign any external payload, or if it signs, it cannot generate an output that can be interpreted as an attestation statement.

In addition, the attestation key can be uploaded only once to the backend at the moment of device registration, in the clean room, and is seldom changed unless the device loses it.

The attestation key, hence, can be used to attest that the binding key belongs to the same device as the attestation key by signing the public part of the binding key (with the attestation key) if it finds a corresponding private key in the same secure enclave, and generating an attestation statement. Depending on the specific implementation, this attestation statement itself can be a binding statement, or it can be sent to an attestation service to produce the final binding statement.

Note: Attestation Key is also referred as AIK in the document in some of the flow diagrams below.

Binding Key

A binding key is an asymmetric key pair that is used to bind an auth cookie. It is identified by a KeyId and it is the responsibility of the browser to remember the KeyId mapping to Local Key Helper and RP. The Local Key helper uses the KeyId for DBSC signatures and key management.

This binding key for DBSC(E) is similar to the artifact defined in the DBSC proposal here. It is expected to be cryptographically attested by the attestation key where the attestation key is expected to be created in a secure enclave (TPM or Keyguard) on the same device. The original DBSC proposal(https://github/wicg/dbsc) does not guarantee the binding key validation to be attack free, as it can be generated by a malware if the malware is present on the device and used on a different device. In DBSC(E), if device registration process is executed with a clean room environment, the binding key is ensured to be generated and used in the same device.

Binding Statement

Additional to the binding key, the local key helper also generates a binding statement, a statement that asserts the binding key was generated on the same device as the attestation key. Details on how this statement is issued and its format is specific to each local key helper.

  • For a public local key helper, the binding statement must be signed by an asymmetric key from the attestation service, and should not include any device identifying information, like device id etc. The validation of the binding statement is a simple signature validation that ensures that it is signed by the same key from the attestation service.
  • For a private local key helper, The binding statement must be signed by the attestation key. During the validation of the binding statement, the IDP authenticates the device to find the deviceId, and uses the deviceId to find the corresponding attestation key which helps with the validation. Device authentication with the IDP is out of scope of this protocol.

The validation component verifies the binding statement, and it can understand that such a statement cannot be generated unless the private key resides in the same secure enclave when signed by the attestation key. Hence, a valid binding statement means that both the attestation key and the binding key belong to the same device.

Binding statements can be long-lived or short-lived.

  • If an IdP performs fresh device authentication outside of DBSC(E) integration at the time of binding key validation, then the binding statement can be long lived, as the IdP ensures the device identity through other mechanisms.
  • IdPs that do not perform proof of possession of the device, the ones that use public local key helpers, must use short-lived binding statements. Otherwise, the attacker will be able to bind the victim's cookies to malicious keys from a different machine. A short-lived binding statement must have an embedded nonce sent by the IdP to validate that it is a fresh binding statement, minimizing the attack window.

Since there could be multiple devices supported by a device registration client and since it is possible for a device to be unknown when the local key helper is invoked during authentication, multiple binding statements can be issued for a single binding key. This is especially true for private local key helpers.

High-Level Design

DBSC(E), if enabled for a given enterprise, specifies the generation of the cryptographic artifacts (keys and binding info) before a sign in session is established. By enabling the browser to invoke specific APIs based on an enterprise policy, it allows enterprises to add to the existing key generation. It also allows them to place stricter restrictions on specific sessions, hence providing the flexibility to secure a session appropriately.

The high-level design is divided into two parts:

  1. Key generation and validation before the session starts (DBSC(E) is focused on this part).
  2. DBSC protocol applied with the generated keys (DBSC is focused on this part).

Since we want to integrate DBSC(E) with the original design and make it as widely applicable as possible for all enterprise users, we are adding high-level design for the most possible combinations in this document. The intent is to have a specification that can be implemented by any browser vendor, and can be used by any IdP, and any Local Key Helper. As we cover different use cases DBSC(E) can be applied for, we differentiate between private and public local key helpers, since there are implications to the protocol based on the type of local key helper. For example, we expect well establised IdPs like Microsoft, Github to ship their own private local key helpers. DBSC(E) protocol also provides multiple extension points that simplify and improve performance for specific scenarios. The DBSC(E) use cases section expands on some of these scenarios.

DBSC(E) (in contrast with DBSC):

Note: In this case, IDP is same as RP, calls a Public Local Key Helper.

DBSC(E) Highlevel Design

Link to editable diagram

Highlights:

Note: All references to RP, IDP are equivalent to server in the original DBSC design.

  1. Pre-Session initiation with special headers (steps 1-2): When a user starts a sign-in process, or initiates a session, the webpage initiating the session sends special headers Sec-Session-GenerateKey and Sec-Session-HelperIdList to the browser in response, to indicate that the session is expected to be DBSC(E) compliant.

    • The Sec-Session-GenerateKey header contains the URL of the server(RP), the URL of the IdP (authentication service in most cases - which is optional for consumer use cases), a nonce and any extra parameters that the IdP wants to send to the Local Key Helper. nonce is essential to prevent replay of cached binding key/binding statements from a different device (proof of possession) and to prevent the clock-skew between the IdP and the Local Key Helper.
      • For all public local key helpers, e.g., Contoso's IDP calling Fabrikam's Local key helper, nonce must be short lived. If binding statement is not shortlived, it is possible for the attacker to generate the binding statement and the binding key from a device controlled by the attacker and use them to bind the victim's cookies to the malicious binding key. The enforcement of a shortlived binding statement is achieved through nonce.
      • The allowance for long lived binding statement is possible with private local key helpers where the IDP can use other means to establish fresh proof of possession of the device. This is covered in detail in later sections.
      • nonce also helps prevent the clock skew between servers where IDP and Attestation servers are from different vendors. Since the nonce sent by the IDP is embedded in the binding statement, the IDP will be able to validate nonce to ensure the binding statement is issued recently.
      • nonce is generated by the IdP/RP as a part of the request, is a random number that MUST be unique, MUST be time sensitive and MUST be verifiable by the issuer.
    • The Sec-Session-HelperIdList header contains an ordered list of helper IDs that the browser can use to generate the key. The browser must prefer the first available and enabled HelperId from the list. The browser will then call the Local Key Helper with the HelperId to generate the key. There is also an optional HelperCacheTime which can cache a HelperIdList for the IDP in the browser for a given time.

  2. Key and Binding Statement Generation (steps 3-7): The Local Key Helper generates the key and the binding statement. AIK refers to the Attestation Key described above. The binding statement is expected to contain nonce(challenge) sent by the IdP, the thumbprint(a cryptographic hash digest) of the publicKey(public part of the binding key), and any extra claims that the IdP wants to send.

    • The attestation service is also separate from the IDP in this diagram.
    • The extra claims is a provision added for specific IdPs or Local Key Helper vendors to add any additional information to the binding statement. It is intentionally left undefined, and can be customized.

  3. Sign In/Session Initiation (steps 8-9): The binding statement, with the KeyId is expected to be returned to the IdP with a new header, Sec-Session-Keys. The IdP validates the signature on the binding statement, nonce and stores the thumbprint of the publicKey. Once the validation succeeds, the IdP will proceed with the sign-in ceremony. It can optionally generate auth tokens as illustrated below, that embed the publicKey or a thumbprint of the publicKey.

  4. SignIn Succeeds with binding (steps 10-14): At this point, all DBSC(E) specific steps are completed. The server returns signed in content with a special header response to the browser: Sec-Session-Registration indicated the session is expected to be DBSC compliant. All steps further are as per the original DBSC proposal with two caveats: The local key helper is called for JWT generation and the additional params introduced for DBSC(E) customization can be optionally added.

DBSC(E) additional use cases

This section expands on the generic design to address different enterprise use cases:

IDP Calls Public Local Key Helper

In many use cases, it is also a valid to have separate servers as RP and IdP. We address the use case where the IdP calls a public Local Key Helper and is a separate service from the RP below.

For easy mapping with the existing DBSC proposal, please note:

  • Steps 1-16 specify the key generation process for a public local key helper. The binding statement is expected to be short lived as elaborated in the high level design.
  • Steps 17-29 are DBSC with additional parameters introduced with DBSC(E).

IDPCallsPublicLocalKeyHelper

Link to editable diagram

Highlights:

  • The binding statement is expected to be short lived as elaborated in the high level design.
  • Auth tokens are not mentioned in the DBSC(E) high level design to simplify the over all scenario. However, most signin/access operations will often make use of auth tokens and issue cookies based on those tokens. In such case, the IdP can generate the auth tokens and embed the thumbprint of the publicKey in the token.
  • The tokens also contain the thumbprint of the publicKey, and the RP must validate the thumbprint from the token against the thumbprint from the JWT. The RP will also embed the thumbprint in the cookie for subsequent session validation.

IDP Calls Private Local Key Helper

As referred in Local Key Helper section, it is possible for an IdP to implement a private local key helper and establish a private protocol to communicate. Any such private local key helper can only be used by the specific IDP that owns its implementation.

In DBSC(E), the use of private local key helper for specific IDPs enables the below optimizations:

  • An IDP can specify its preferred ordered list of HelperIds in any response, and can request the browser to cache its preference for a specific duration (HelperCacheTime). The IDP which is capable of DBSC(E) can specify its HelperIdList in any communication(request/response) within the browser context.
  • The caching of HelperId is more beneficial for private local key helper for two reasons:
    • Since the IDP is associated mostly with the same local key helper, it is unlikely to change often.
    • long lived binding statements are possible with private key local helper (more below), eliminating the need for an additional redirect to fetch the IDP nonce for the binding statement.
  • The IDP and the private local key helper can also leverage long lived binding statements. If the IdP can establish the proof of possession of the device by its own proprietary mechanism for a given request, then it can accept binding statements without requiring fresh nonce challenge for those. Once the device authentication is complete, the IDP can use the long lived binding statements for binding proof. Browser can cache those binding statements for further performance optimization with an optional signal from the local key helper.
  • RP can combine the request for a DBSC(E) startsession as a part of the IDP redirection during sign-in. If the key generation and sign in are successful, the browser must intercept the response for the sign-in flow and append the new JWT proof (which is generated by the local key helper) on navigation to the RP. This allows the RP to avoid an additional round trip to initiate the DBSC(E) session, based on the URL (and optionally KeyId).

IDPCallsPrivateLocalKeyHelper

Link to editable diagram

Cleanup of the binding keys and their artifacts

For the health of the operating system and user privacy, it is important to clean up binding keys and their artifacts. If the number of keys grows too high, the performance of the OS can degrade.

The cleanup can occur:

  • When cookies are expired.
  • On demand, when the user decides to clear browser cookies.

Appendix

IDP is RP and Calls Public Local Key Helper

This is the similar use case elaborated in the high level design above. This use case covers where an IDP/RP calls a public Local Key Helper. The binding statement is expected to be short lived as elaborated in the high level design.

Link to editable diagram