Device Trust Architecture

About Kolide
Home / About Kolide / Device Trust Architecture

Device Trust Architecture

Kolide has designed its device trust solution so organizations can rely on it to stop untrusted devices from accessing sensitive resources protected by Single Sign-On authentication.

In this article, we enumerate and discuss the components that together, provide the device authentication experience necessary for Zero Trust access.

Technical Definition

Kolide’s device trust is designed to be used as a phishing-resistant possession-based factor within an existing multi-factor authentication flow.

A Note Regarding Phishing Resistance:
Many existing token or push-based possession-based factors can be easily phished by an attacker who can social engineer the user to supply the secret code or approve an authentication attempt.

However, in Kolide device trust, the end-user cannot easily access the secret key material or even the outputs needed to successfully solve the cryptographic challenges presented by the Kolide Service. Since relying on phishing is ineffective, attackers looking to bypass the authentication must take take actions that allow them to compromise the underlying system. Unlike pure phishing techniques, these actions are much more likely to be detected by your organization’s security teams.

Kolide’s device trust solution can be classified as a “Single-Factor Cryptographic Device Verifier” under NIST’s Digital Identity Guidelines, which is defined as follows:

Single-factor cryptographic device verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the device. The authenticator output is highly dependent on the specific cryptographic device and protocol, but it is generally some type of signed message.

The verifier has either symmetric or asymmetric cryptographic keys corresponding to each authenticator. While both types of keys SHALL be protected against modification, symmetric keys SHALL additionally be protected against unauthorized disclosure.

For more information about the cryptographic components of the solution, see the Encryption Technologies section of this document.

Key Components

Kolide’s device trust capabilities are made possible by many components working together:

Kolide SAML IdP

Since Kolide’s device trust authentication flow acts as a single possession factor, it is designed to be integrated within an existing centralized provider solution (currently only Okta is supported). To enable this integration, Kolide acts as a SAML v2.0 protocol-compliant IdP.

In the future, Kolide plans to extend its SAML IdP to serve as a stand-alone IdP that can be used to directly protect SAML-compliant applications.

IdP Integration (SAML and SCIM)

To be a secure device trust solution, Kolide must associate devices with people who work for your organization. Since Kolide has no knowledge of an organization’s employees or contractors, it can only obtain this information by integrating with other IdPs (e.g., Okta via SCIM).

These IdP Integrations allow Kolide to obtain a list of people in-scope for device trust and, if necessary, re-verify their identity with their associated IdP.

Kolide Agent

For Mac, Windows, and Linux devices, Kolide’s Agent provides the client-side code necessary for the Kolide Service to identify devices that are authenticating.

Additionally, the Kolide agent is responsible for continuously sending relevant Device posture telemetry to the service.

Kolide Mobile App

For iOS and Android devices, Kolide’s Mobile app facilitates device registration and subsequent identification of the device during the authentication process. This app also sends device posture telemetry to Kolide whenever it is launched, including during the authentication process.

Architecture Goals

Kolide’s device trust architecture is designed to prevent bad-actors who do not have access to a device Kolide currently trusts, from accessing any resources or apps protected by Kolide.

The architecture is designed to achieve the following technical outcomes:

  1. Establish a reliable communication channel between the device and Kolide’s service during web and SaaS authentication.

  2. Achieve goal #1 without requiring customers to ship secrets to devices in advance and without requiring Kolide to pre-bake secrets into any code it asks the users to download.

  3. Ensure that all device identification attestations are signed with private key material that never leaves the device.

Note:
The primary goal of any device trust system is to make the device’s identity unspoofable. This is only possible by generating secrets and storing them on-device. Outsiders without access to these on-device secrets or the trusted device itself cannot spoof a valid device in Kolide.

That said, like any other system based on secrets, it can be subverted by those who have the means and the opportunity to obtain them (e.g., employees with device administrative access).

It is important that you design your security program and policies to address insider threats who wish to intentionally defeat the security of a device trust system.

Encryption Technologies

Kolide uses public-key authenticated encryption to encrypt and sign confidential messages between the Kolide Service and the Kolide Client (any device running our official agent or mobile app). The goals are to achieve privacy and third-party unforgeability inherent to public-key authenticated encryption utilizing securely generated nonces.

The implementation Kolide has chosen to achieve public-key authenticated encryption is called NaCl (specifically crypto_box). NaCl was chosen due to its inherently secure design, the wide availability of mature cross-language libraries, and its emphasis on performance.

For formal definitions see, “Authenticated encryption in the public-key setting: security notions and analyses”.

Bootstrapping

As part of any public-key based auth scheme, bootstrapping trust is a key component of the system. For Kolide, this means defining circumstances when a Kolide Client is allowed to register successfully into the Kolide Service.

When a Kolide Client (any device running our official agent or mobile app) successfully registers, the Kolide Service:

  • Associates it with an existing identity (obtained via its IdP integration),
  • Stores the device’s public key securely in long-term storage,
  • Considers the device’s identity trusted for the purposes of future authentication attempts.

By default, Kolide implicitly trusts the very first device registered by a user who authenticates successfully via your organization’s SSO provider. This method of bootstrapping is also known as the Trust On First Use (TOFU). Subsequent devices must be either manually approved by an organization-appointed Kolide administrator, or, the user must successfully authenticate with a previously trusted device in order to extend that trust to a new device they wish to register.

Kolide offers configuration to adjust bootstrapping behaviors to best meet the organization’s security goals.

Message Exchange Semantics

As mentioned previously, Kolide uses NaCl’s crypto_box to exchange information between the Kolide Service and the Kolide Client. While there are minor implementation differences to account for technological differences inherent to the different supported platforms, the high-level construction and verification of messages adheres to the following protocol:

In response to an authentication request:

  1. The Kolide Service generates and signs a challenge. This challenge will eventually be sent back to the Kolide Service from the Kolide Client, therefore, it is important that it has the following properties:

    • The Kolide Service can read the challenge and convert it to a known user’s identity.
    • The Kolide Service can verify the authenticity of the challenge’s content.
    • The Kolide Service considers the challenge invalid after a short time period has elapsed from initial generation.

  2. The Kolide Service encodes the challenge into a data structure and communicates it with the Kolide Client

  3. The Kolide Client generates ephemeral key and locates the public key material necessary to construct a NaCl crypto box for the Kolide Service. The box is filled with the original challenge sent by the Kolide Service and device identification attestations. The box is signed by the Kolide Client’s long-term public key (previously sent to the Kolide Service during device registration).

  4. The Kolide Service receives the box ciphertext, unseals the NaCl box using its own keys, and obtains the original challenge and the new device identification attestations.

  5. The Kolide Service uses this information to lookup the user and the device and proceeds with verifying the device’s posture.

For the Kolide Launcher agent, this process can be demonstrated in more detail with the following diagram.

  sequenceDiagram
    participant Kolide Service
    participant Kolide Agent
    Kolide Service ->> Kolide Service: 1. Generate k2-ephemeral key pair
    Kolide Service ->> Kolide Agent: 2. [k2-ephemeral.pub, challenge]_K2
    Kolide Agent ->> Kolide Agent: 3. Verify Signature
    Kolide Agent ->> Kolide Agent: 4. Generate agent-ephemeral key pair
    Kolide Agent ->> Kolide Agent: 5. Compute ecdhkey = ECDH(k2-ephemeral.pub, agent-ephemeral.pri)
    Kolide Agent -->> Kolide Service: 6. [{challenge response, data, agent.pub}_ecdhkey, agent-ephemeral.pub]_agent
    Kolide Service ->> Kolide Service: 7. Compute ecdhkey = ECDH(k2-ephemeral.pri, agent-ephemeral.pub)
    Kolide Service ->> Kolide Service: 8. Unseal box using ecdhkey
    Kolide Service ->> Kolide Service: 9. Verify signature using agent.pub from box
    Kolide Service ->> Kolide Service: 10. Verify challenge response and lookup device

An overview of the interactions between the Kolide Service and the Kolide Launcher agent during device authentication.

Additional Resources