Secure Channels
Ockam Secure Channels are mutually authenticated and end-to-end encrypted messaging channels that guarantee data authenticity, integrity, and confidentiality.
Last updated
Ockam Secure Channels are mutually authenticated and end-to-end encrypted messaging channels that guarantee data authenticity, integrity, and confidentiality.
Last updated
To trust data-in-motion, applications need end-to-end guarantees of data authenticity, integrity, and confidentiality.
In previous sections, we saw how Ockam Routing and Transports, when combined with the ability to model Bridges and Relays, make it possible to create end-to-end, application layer protocols in any communication topology - across networks, clouds, and protocols over many transport layer hops.
Ockam Secure Channels is an end-to-end protocol built on top of Ockam Routing. This cryptographic protocol guarantees data authenticity, integrity, and confidentiality over any communication topology that can be traversed with Ockam Routing.
Distributed applications that are connected in this way can communicate without the risk of spoofing, tampering, or eavesdropping attacks, irrespective of transport protocols, communication topologies, and network configuration. As application data flows across data centers, through queues and caches, via gateways and brokers - these intermediaries, like the relay in the above picture, can facilitate communication but cannot eavesdrop or tamper data.
In contrast, traditional secure communication implementations are typically tightly coupled with transport protocols in a way that all their security is limited to the length and duration of one underlying transport connection.
For example, most TLS implementations are tightly coupled with the underlying TCP connection. If your applications data and requests travel over two TCP connection hops TCP -> TCP then all TLS guarantees break at the bridge between the two networks. This bridge, gateway or load balancer then becomes a point of weakness for application data.
To make matters worse, if you don't set up another mutually authenticated TLS connection on the second hop between the gateway and your destination server, then the entire second hop network – which may have thousands of applications and machines within it – becomes an attack vector to your application and its data. If any of these neighboring applications or machines are compromised, then your application and its data can also be easily compromised.
Traditional secure communication protocols are also unable to protect your application's data if it travels over multiple different transport protocols. They can't guarantee data authenticity or data integrity if your application's communication path is UDP -> TCP or BLE -> TCP.
Ockam Routing and Transports, when combined with the ability to model Bridges and Relays make it possible to bidirectionally exchange messages over a large variety of communication topologies: TCP -> TCP or TCP -> TCP -> TCP or BLE -> UDP -> TCP or BLE -> TCP -> TCP or TCP -> Kafka -> TCP, etc.
By layering Ockam Secure Channels over Ockam Routing, it becomes simple to provide end-to-end, application layer guarantees of data authenticity, integrity, and confidentiality in any communication topology.
Ockam Secure Channels provides the following end-to-end guarantees:
Authenticity: Each end of the channel knows that messages received on the channel must have been sent by someone who possesses the secret keys of a specific Ockam Identifier.
Integrity: Each end of the channel knows that the messages received on the channel could not have been tampered en route and are exactly what was sent by the authenticated sender at the other end of the channel.
Confidentiality: Each end of the channel knows that the contents of messages received on the channel could not have been observed en route between the sender and the receiver.
To establish the secure channel, the two ends run an authenticated key establishment protocol and then authenticate each other's Ockam Identifier by signing the transcript hash of the key establishment protocol. The cryptographic key establishment safely derives shared secrets without transporting these secrets on the wire.
Once the shared secrets are established, they are used for authenticated encryption that ensures data integrity and confidentiality of application data.
Our secure channel protocol is based on a handshake design pattern described in the Noise Protocol Framework. Designs based on this framework are widely deployed and the described patterns have formal security proofs. The specific pattern that we use in Ockam Secure Channels provides sender and receiver authentication and is resistant to key compromise impersonation attacks. It also ensures the integrity and secrecy of application data and provides strong forward secrecy.
Now that you're familiar with the basics let's create some secure channels. If you haven't already, install ockam command, run ockam enroll, and delete any nodes from previous examples.
In this example, we'll create a secure channel from Node a to node b. Every node, created with Ockam Command, starts a secure channel listener at address /service/api.
In the above example, a and b mutually authenticate using the default Ockam Identity that is generated when we create the first node. Both nodes, in this case, are using the same identity.
Once the channel is created, note above how we used the service address of the channel on a to send messages through the channel. This can be shortened to the one-liner:
The first command writes /service/d92ef0aea946ec01cdbccc5b9d3f2e16, the address of a new secure channel on a, to standard output and the second command replaces the - in the to argument with the value from standard input. Everything else works the same.
In a previous section, we learned that Bridges enable end-to-end protocols between applications in separate networks in cases where we have a bridge node that is connected to both networks. Since Ockam Secure Channels are built on top of Ockam Routing, we can establish end-to-end secure channels over a route that may include one or more bridges.
Delete any existing nodes and then try this example:
In a previous section, we also saw how Relays make it possible to establish end-to-end protocols with services operating in a remote private network without requiring a remote service to expose listening ports on an outside hostile network like the Internet.
Since Ockam Secure Channels are built on top of Ockam Routing, we can establish end-to-end secure channels over a route that may include one or more relays.
Delete any existing nodes and then try this example:
Ockam Secure Channels are built on top of Ockam Routing. But they also carry Ockam Routing messages.
Any protocol that is implemented in this way melds with and becomes a seamless part of Ockam Routing. This means that we can run any Ockam Routing based protocol through Secure Channels. This also means that we can create Secure Channels that pass through other Secure Channels.
The on-the-wire overhead of a new secure channel is only 20 bytes per message. This makes passing secure channels though other secure channels a powerful tool in many real world topologies.
Ockam Orchestrator can create and manage Elastic Encrypted Relays in the cloud within your Orchestrator project. These managed relays are designed for high availability, high throughput, and low latency.
Let's create an end-to-end secure channel through an elastic relay in your Orchestrator project.
The Project that was created when you ran ockam enroll offers an Elastic Relay Service. Delete any existing nodes and then try this new example:
Nodes a and b (the two ends) are mutually authenticated and are cryptographically guaranteed data authenticity, integrity, and confidentiality - even though their messages are traveling over the public Internet over two different TCP connections.
In a previous section, we saw how Portals make existing application protocols work over Ockam Routing without changing any code in the existing applications.
We can combine Secure Channels with Portals to create Secure Portals.
Continuing from the above example on Elastic Encrypted Relays create a Python-based web server to represent a sample web service. This web service is listening on 127.0.0.1:9000.
Then create a TCP Portal Outlet that makes 127.0.0.1:9000 available on worker address /service/outlet on b. We already have a forwarding relay for b on orchestrator /project/default at /service/forward_to_b.
We then create a TCP Portal Inlet on a that will listen for TCP connections to 127.0.0.1:6000. For every new connection, the inlet creates a portal following the --to route all the way to the outlet. As it receives TCP data, it chunks and wraps them into Ockam Routing messages and sends them along the supplied route. The outlet receives Ockam Routing messages, unwraps them to extract TCP data, and send that data along to the target web service on 127.0.0.1:9000. It all just seamlessly works.
The HTTP requests from curl, enter the inlet on a, travel to the orchestrator project node and are relayed back to b via it's forwarding relay to reach the outlet and onward to the Python-based web service. Responses take the same return route back to curl.
The TCP Inlet/Outlet works for a large number of TCP based protocols like HTTP. It is also simple to implement portals for other transport protocols. There is a growing base of Ockam Portal Add-Ons in our GitHub Repository.
Trust and authorization decisions must be anchored in some pre-existing knowledge.
Delete any existing nodes and then try this new example:
To clean up and delete all nodes, run: ockam node delete --all
Ockam Secure Channels is an end-to-end protocol built on top of Ockam Routing. This cryptographic protocol guarantees data authenticity, integrity, and confidentiality over any communication topology that can be traversed with Ockam Routing.
If you're stuck or have questions at any point, please reach out to us.
Next, let's explore how we can scale mutual authentication with Ockam Credentials.
%20(1)%20(1).svg?alt=media)