The CBCP Capability-Based Command Protocol

Reading time: 4-5 minutes
3 September 2021
Jakob Kjær-Kammersgaard of QuasiOS

In this short article, we introduce the Capability-Based Command Protocol and give some background as to why we created it.

1. Background

When the first computer networks emerged, there was no internet. No one used the word cyber-attack. Generally, everybody knew and trusted whoever connected to the network.

Map of the ARPANET 1973
Figure 1.1. Map of the ARPANET 1973 – ARPANET

Many of the protocols we still use today first appeared during this time. The Simple Mail Transfer Protocol (SMTP) that E-Mail uses, for instance.

Businesses and governments have learned the hard way that today, you shouldn’t trust whoever connects to the network, neither the data they send nor that they are whom they claim. Unfortunately, the hard way is referring to billions of dollars lost to cyber-attacks.

2. The Problem

Imagine a factory. This factory has an abundance of interconnected machinery that must perform complex automated tasks without endangering the people who work there. Factories used to be offline. However, part of the fourth industrial revolution (Industry 4.0) involves factories becoming increasingly internet-connected.

Industrial Revolutions
Figure 2.1. Industrial Revolutions – by Christoph Roser at

The factory is an example. Many businesses rely on large IT systems comprised of several physical machines that must choreograph actions over a network to achieve their goals. It is in these scenarios that IT security has become a big priority, internet connectivity or not.

Ideally, you would want to have fine-grained control over what actions each machine can perform and with whom they are allowed to perform those actions. Once you had configured your network, all communication would be encrypted and every command or message authenticated. No one could make a machine in the network perform an action without explicit permission.

This ideal situation is what we designed CBCP to provide.

3. Enter CBCP

To provide the ideal situation outlined in the previous section, we use capabilities (the first ‘C’ in CBCP), a concept borrowed from permission management in operating systems. Capabilities are what allows us to provide fine-grained control.

Suppose you were to use CBCP. Your first task would be configuring the network.

Each machine in the network has specific actions that it can perform or certain data that others may need. The core idea in CBCP is to associate a capability with each such action or data access.

You group capabilities logically belonging together into capability interfaces – similar to how you would group methods belonging together into an object in object-oriented programming.

Once all interfaces are specified, you explicitly declare them in a shared CBCP network configuration.

CBCP Configuration Format
Figure 3.1. CBCP configuration file (format subject to change) – QuasiOS ApS

This configuration defines the machines (hosts) participating in the communication and their capability interfaces.

Now, for each machine in the network, you state what capabilities of what interfaces it requires to function. This can (and should) be the minimum number of capabilities.

It is likely that multiple hosts in the network offer the same interfaces or require the same capabilities from others. For this reason, you can define host classes, which is a way to group hosts and not have to repeat yourself needlessly.

That concludes the configuration step.

Now the protocol takes over. It first establishes encrypted communication channels between each pair of interacting machines in the network.

After this step, machines in the CBCP network can only perform the actions specified by you.

Should you wish to make changes to the network configuration, CBCP supports incremental updates. Incremental updates ensure that the network does not experience unwarranted downtime.

4. In Summary