Security and privacy

About the design of 1Password Device Trust (Kolide)

Learn how 1Password’s device trust solution is designed for Zero Trust security.

1Password Device Trust (Kolide) helps organizations make sure only known, secure, and compliant devices can access sensitive resources protected by single sign-on (SSO) authentication.

Kolide includes several components that help align the device authentication experience with Zero Trust principles.

Security model

Kolide is designed to prevent bad actors from accessing protected resources and apps, by only allowing a person with a trusted device to authenticate. Kolide’s design achieves the following technical outcomes:

  • Establishes a reliable communication channel between a trusted device and Kolide’s service during web and SaaS authentication, without embedding secrets into any code users download or requiring customers to ship secrets to devices in advance.
  • Makes sure that all device identification attestations are signed with private key material that never leaves the device.

By generating and storing secrets on the trusted device, Kolide makes the device’s identity unforgeable. People who don’t have access to the on-device secrets or the trusted device can’t impersonate a valid device in Kolide.

Important

Kolide can be comprised by anyone with the access and ability to obtain on-device secrets, like employees with administrative rights on a trusted device.

Design your security program and policies to address insider threats that wish to intentionally defeat the security of a device trust system.

Technical design

1Password’s device trust solution is classified as a Single-Factor Cryptographic Device Verifier under NIST’s Digital Identity Guidelines. In this method, cryptographic challenges are used to verify device possession through a signed message response. Symmetric or asymmetric cryptographic keys are used to secure the authentication process, with both types of keys protected against modification and unauthorized access. This approach makes device authentication resistant to phishing attacks, as attackers would need to bypass the device’s cryptographic protections, which is much harder to do without detection.

1Password SAML IdP

1Password’s device trust authentication model serves as a phishing-resistant, single possession factor, and is designed to integrate with a centralized identity provider (IdP). For this integration, Kolide operates as a SAML v2.0 compliant IdP.

IdP integration (SAML and SCIM)

To serve as a secure device trust solution, Kolide must link devices to employees within an organization. Because 1Password doesn’t have insight into an organization’s employees or contractors, Kolide relies on integrations with IdPs, such as Okta through SCIM, for this information.

These IdP integrations allow Kolide to retrieve a list of users eligible for device trust and, if needed, re-verify their identities with the connected IdP.

Kolide Agent

For Mac, Windows, and Linux devices, the Kolide agent provides the client-side code necessary for Kolide’s service to identify devices during the authentication process.

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’s opened, including during the authentication process.

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 the Kolide agent or mobile app). By using securely generated nonces, Kolide achieves privacy and third-party unforgeability through public-key authenticated encryption.

Kolide uses NaCL (specifically crypto_box) to implement public-key authenticated encryption. 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

Bootstrapping trust is a key component of any public-key based authentication scheme. For 1Password, this means defining circumstances when a Kolide client is allowed to register successfully into the Kolide service.

When a Kolide client successfully registers, the Kolide service:

  • Associates it with an existing identity, obtained through 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 treats the very first device registered by a user through an organization’s SSO provider as trusted. This method of bootstrapping is known as Trust On First Use (TOFU). For any additional devices, either an organization-appointed Kolide administrator must manually approve them, or the user must authenticate with an already trusted device to extend that trust to the new device they wish to register.

Kolide offers configuration to adjust bootstrapping behaviors to best meet an organization’s security goals. Learn how to configure your organization’s registration requirements.

Message exchange semantics

Kolide uses NaCl’s crypto_box to exchange information between the Kolide service and Kolide client. Although there are slight implementation adjustments to accommodate platform-specific differences, the overall method for constructing and verifying messages follows this protocol.

In response to an authentication request:

  • The Kolide service generates and signs a challenge, which the Kolide client will send back. The challenge must have 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.
  • The Kolide service encodes the challenge into a data structure and communicates it with the Kolide client.

  • The Kolide client generates an 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).

  • 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.

  • The Kolide service uses this information to look up 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:

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

Learn more

Published: