KeyChest has started as an easy to use HTTPS monitoring service. What we are aiming for is a general purpose key management service, which can look after your public as well as internal web encryption keys.

Ever since KeyChest got its first users, we were asked if it can be used for internal keys. Our initial approach was to provide on-premise instances, which gave potential users a complete autonomy in terms of separate database and dedicated processing power. This is what we still offer as the Enterprise option. But this option asks a lot from users as they have to, at least to some degree, look after their KeyChest.

As we developed new features it became obvious that we need another option – more flexible, lightweight, low-maintenance. That’s where independent agents, extending the reach of KeyChest audit engines, come from. As we are close to launching KeyChest agents, here’s an introduction.

Agents will be generally available from the beginning of July 2019.

Proxy Agent

We wanted agents to be as small and platform-independent as possible. The smaller they are, the easier they are to install, maintain, and update. The platform independence means there is almost no encryption inside (except for an ability to create a secure encrypted channel). Neither there can be any low-level networking or other platform-dependent support. Agents will still have to be able to read / write to files and connect to the main KeyChest service, but even file-system access has to be limited to common functionality.

The core of KeyChest agents comprises the following 3 subsystems:

1. Logging – a robust logging, which stores activity logs locally as well as posts them to the KeyChest service is simply a must for efficient management. Detailed information is what you need when in trouble – whether it’s for KeyChest users or for our support helping you out.

2. Proxy operation – the actual audit of secure services requires a strong control over the networking, something that is platform dependent and we are regularly updating it. It means agents must work as transparent proxies for traffic generated by the KeyChest Audit Engines.

3. Local control – agents are gateways into your internal networks and we want to give you as much control as possible over what they can be used for. We are putting restrictions on the ports they can connect to, the address ranges they can use, and so on. This information is in local configuration files, which can be locked-down so only you can change them. We also plan to give as wide access to the source codes of agents as possible.

Logging

We see logging and ability to audit collected logs as one of the most important aspect of any software and network services. When we started implementing the agents, the first thing we did was a robust logging framework.

Logging produces JSON formatted messages that provide much better quality of “raw” data. This has massive implications on log audits as all the parameter values from logs are natively stored as separate indexed items. (Internally, we use Splunk for audits. Since we started using JSON logs, visualization and inspection of tens or hundreds of thousands log records were actually fun. The simplicity of selecting any of the log parameters and focus analysis around them gives you a good chance to spot irregularities and issues to look into.)

The success of any audit of logs depends on the quality of the data and being able to quickly identify where the data came from. Each log entry therefore contains:

• time of logging

• time of event

• event code – severity of the message and a unique code (e.g., ERR0043)

• host machine – name and its IP address

• version of the software (agent); and

• process – if the software uses multiprocessing.

Proxy Operation

This is possibly a more interesting part of KeyChest agents and it still amazes me how simple can it look from outside.

Each agent controls the traffic and any requests coming from the KeyChest.net service. Details of audit requests are sent to agents so they can block those not complying with agent’s local configuration file.

Agents regularly connect to keychest.net to request audit “jobs”. When they receive a valid description of an audit job, they will launch a proxy, which connects to the audit target (downstream) and to KeyChest (upstream). Once the audit is completed, the proxy is terminated and the agent can re-use its port.

Internal network discovery is treated separately. We plan to implement a range of discovery methods based either on:

• internal database of certificates (e.g., LDAP storage of your PKI system); or

• internal DNS zone.

Discovered services are sent to the KeyChest service so it can start scheduling regular audits.

Agent Installation

Agents are provided as one-file packages. You can run them by hand or invoke them with a scheduler like Linux cron. When it’s started for the first time, it will create an initial configuration and will try to register with KeyChest. Once completed, the agent will have its own unique API key and ID, which is in the form of an email address.

It will occasionally push its configuration to the KeyChest service, but nothing else will happen until it is associated with a KeyChest account. Once that happens, the service discovery and regular audits will commence automatically.