About | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange

Keyserver and SROS

Description: This tutorial explains what, why, and how the keyserver is used in SROS.

Keywords: SROS, Keyserver, PKI

Tutorial Level: INTERMEDIATE

Next Tutorial: SROS/Tutorials/RunningKeyserver

Overview

This tutorial will introduce you to how SROS uses a Keyserver. First, let us familiarize ourselves with the Keyserver itself.

What is the Keyserver

The keyserver is what SROS uses to generate and distribute keys and certificates to ROS nodes. The keyserver is not a node itself, nor is it tied to any particular ROS node, like the parameter server is to rosmaster. This allows for the key server to run separately from ROS, be it from a different user process or different machine entirely. In fact, the only time the keyserver should run is upon initial setup, thereafter nodes should have their own keys locally, from their own nodestore, in the respective keystore. In truth, using a keyserver is completely optional if you have your own methods of generating and distributing PKI elements. However, users may appreciate the features and integration that the SROS keyserver provides, of which maybe fully or partially utilized as users see fit.

Why is a Keyserver used in SROS

As mentioned previously, SROS utilizes TLS, and TLS utilizes PKI, ergo SROS needs a way of generating and distributing PKI elements, including: asymmetric keys, certificate authorities (CA), and signed certificates. In practice, this not a simple task, and doing so manually is beyond tedious. Generating and singing X.509 certificates correctly using tools like OpenSSL can be a challenge and barrier for new users. Within the world of cybersecurity, there's a line of thought that proscribes security without usability is essentially insecure in part from the effect that users will avoid using it. With this in mind, SROS was designed with a keyserver to better simplify the use and development of SROS enabled systems for end users. The keyserver in SROS is provides seamless integration with the rest of the SROS work flow, as well as conservative default configurations to smooth the PKI learning curve, yet prevent users from shooting themselves in the foot.

How is a Keyserver used in SROS

Let us explore how the keyserver ineracts with the rest of SROS through a common bootstrapping example. When setting up an existing ROS application to use SROS, lets assume you have no existing PKI, so when nodes start under SROS, they'll have no PKI elements to draw from to connect to rosmaster, let alone each other. In this case we would spawn a SROS keyserver prior, and designated it by setting the environment of the ROS nodes.

1. Upon startup of the keyserver, it will load a designated configuration file, then check the designated keystore for CA's and its own nodesstore. In this case the keyserver would find neither, but was configured to make them if needed. And so the keyserver will first generate the required CA, then generate and sign its own nodestore using those CA's so that it may finally open the keyserver for business.
2. Nodes that start under SROS will first check their local designated keystores for their respective nodestores. If this does not exist, and the node has been enabled to contact the designated keyserver, it will attempt to connect and request for one using TLS's client mode, given the node has no PKI element to work with. It should be noted here that a variety security options are available for this point of the exchange, e.g., a node may also be mandated that the accepting keyserver's certificate be signed by an existing trusted local CA (server authentication), and/or the keyserver may be mandated to do the same for a connecting node that uses a intermediate client cert (client authentication).
3. Once the keyserver and node are securely connected via TLS, the node may, if designated to at runtime, send an XML-RPC request for public certificates for its own keystore's trusted CApath. Next the node will request the PKI elements, including its public certificate and private key, to initialize its own nodestore. This request is done by providing the node's own namespace it has been mapped to by ROS.
4. The keyserver then uses this given namespace and searches for the applicable key recipe specified by the user's keyserver configuration. This helps the keyserver decide on how or if it should respond, what algorithms should be for the keys, what policies should be embedded what policies into the certificate, what CA should issue the signature, if or what cypher should be used to lock the private key, and much more.
5. Once the node receives the PKI elements, it will save them to its own nodestore, then attempt to load it; this may involve deciphering the private key using the local secret provided at the node's runtime.
6. From then on, nodes will attempt to connect to rosmaster, a node itself that went through the above process, and then later nodes via TLS handshakes and scrutinizing peer certificates.

The next few tutorials detail the configuration and use of the SROS keyserver necessary for our later SROS examples.