Router Security

Security and encryption model of the Keeper Router

Overview

Keeper Router ("Router") is a cloud service hosted in Keeper's Amazon AWS environment which facilitates communications between the Keeper backend API, end-user applications (Web Vault, Desktop App, etc.), and Keeper Gateways installed in the user’s environment. The Router is responsible for communications that perform resource discovery, password rotation, timed access, and privileged connection management.

How does Keeper Router work?

In traditional or legacy privileged access products, the customer is responsible for installing on-prem software which is difficult to manage and configure in a cloud environment. In Keeper's model, a small service (called a Gateway) is installed into the customer's environment which establishes an outbound secure connection to the Keeper Router, enabling bi-directional communication to the Keeper cloud without any network configuration. Keeper Router makes cloud access to on-prem infrastructure easy and secure by utilizing WebSockets for the inbound requests.

With Keeper, WebSockets are established between the end-user device (e.g. Web Vault) and the Keeper Router using the user's current session token. The session token is verified by the Keeper Router to authenticate the session. All encrypted payloads sent to the Keeper Router are wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the end-user device and transferred to the server using ECIES encryption via the Router's public EC key.

When a user on their Web Vault or Desktop App triggers a password rotation, discovery job or remote connection, the message flow is the following:

• Upon installation of the Gateway, it authenticates with the Keeper Cloud using a hashed One Time Access Token one time. The client signs the payload and registers a Client Device Public Key with the server on the first authentication. After the first authentication, subsequent requests are sent to the Keeper Router and signed with the Client Device Private Key.

• The Gateway establishes an authenticated WebSocket connection using the Client Device Private Key and ECDSA signature.

• The Vault sends a message to the Keeper Router with a command to execute (rotation, discovery, connection) and authenticates the command using the user's active session token.

• The Vault only transmits command and control messages, for example: Rotate UID XXX. No secret information is communicated between Vault and Router. The Router authenticates the command using the session token of the record's rotation configuration to validate the user's request.

• The Router relays the command to the destination gateway through the existing WebSocket connection.

• The Gateway retrieves secrets, admin credentials, record details and other private data by using Keeper Secrets Manager APIs. API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device. The Client Device decrypts the ciphertext response from the server with the Application Private Key, which decrypts the Record Keys and Shared Folder Keys. The Shared Folder Keys decrypt the Record Keys, and the Record Keys decrypt the individual Record secrets.

• The Gateway uses Keeper Secrets Manager "update" commands to update the user's vault with any password or discovery job updates.

• After a rotation or discovery job is complete, the Gateway informs the Router that the job is complete. ARAM event logs are triggered by the Router.

The Keeper Router architecture is Zero Knowledge, and Keeper's infrastructure never has the ability to access or decrypt any of the customer's stored vault data.

Keeper Router Architecture

The Router consists of two logical deployments that work together - the Head and the Workers.

The Router is hosted in Keeper’s AWS cloud environment, isolated to each of the global regions (US, EU, CA, AUS, JP, and US Gov).

The Head is not exposed to the internet, and performs the following functions:

• Synchronization of global state between Workers

• Inter-worker communication

• Scheduling of events (e.g. rotation, discovery and connection requests)

The Workers connect to the Head via WebSocket and also use REST API calls to retrieve information. The Workers perform the following functions:

• Communication with Gateways

• Communication with Keeper end-user applications

• Communication with Keeper backend API

• Communication with Head

Workers are scaled and load balanced in each Keeper environment. Access to the Keeper Router is established through a common URL pattern in each region:

US: https://connect.keepersecurity.com

EU: https://connect.keepersecurity.eu

AU: https://connect.keepersecurity.com.au

CA: https://connect.keepersecurity.ca

JP: https://connect.keepersecurity.jp

US GOV: https://connect.keepersecurity.us

The end-user device will always communicate through the same Router instance. When the end-user vault connects to the Router system, a communication exchange is performed to ensure that the vault is communicating to the desired gateway. Once the Gateway communication is established, a Cookie is stored locally on the user's browser which expires automatically in 7 days. This Cookie is only used to establish a sticky session with the target Router instance, and does not contain any secret information.

Each Gateway device is associated with a unique UID. The Gateway UID is stored within an encrypted “PAM Configuration” record in the user's vault. This way, the Keeper vault record knows which Gateway must be used to perform the requested rotation, discovery or connection features.