Key/Route Discovery, Credential Issuance/Presentation, Secure Channel Handshakes and Message Routing that is decoupled from transport protocols have been our main focus.
We chose to build the more reliable e2ee strategy first - Relays.
UDP hole puncturing is in development right now. However there is extensive research that proves it in only successful in making connections in 60 to 80% of real world networks. This is why Signal does relays for example. Relays provide a highly reliable strategy. So we knew we'll want to support both and give devs and option to choose what is right for their application. Or failover from one to the other.
Store and forward as a first class feature is in development.
Scatter/Gather is a much harder problem since it involves group key agreement and challenges that come with doing that safely. This is in our long term roadmap, but we've not done any development for this yet.
I led the design of Ockam. I am somewhat familiar with Wiregaurd and not at all familiar with OpenZiti. All tools that are helping us build application that have much much smaller vulnerability surfaces are awesome!!
Some things that you can do with Ockam:
1. Create Noise based secure channels all sorts of multi-hop, multi-protocol, network topologies - TCP <> TCP, or TCP <> TCP <> TCP, or UDP <> Kafka <> TCP, or BlueTooth <> TCP <> TCP etc.
2. Move end-to-end encrypted data through Kafka, RabbitMQ, and other messaging and streaming systems.
3. Run on small embedded devices (Rust no_std) or run on large servers.
Checkout this guide I published today. It walks through the code to do the secure tunneling part in ~20 lines of Rust, using Ockam a library to create end-to-end encrypted secure channels
We're thinking about Ockam Routing, Transports, Streams and SecureChannels as composable building blocks for end-to-end encryption. This allows us to provide end-to-end encryption along a route that may look like this:
Alice <=> Bluetooth hop <=> TCP hop <=> Kafka <=> TCP hop <=> Bluetooth hop <=> Bob
Currently One Ockam Stream is backed by one Kafka topic. This is simpler, more composable and easier to think about so we started with this approach. In theory there could be a Bidirectional Stream that is backed by one topic, but we haven't focused on that yet.
Re: "PGP, S/MIME or JWE etc."
A secure channel protocols like Ockam SecureChannel or TLS are more comprehensive and have more security guarantees than simple encryption primitives like PGP or JWE. They provide guarantees like forward secrecy and resistance to Key Compromise Impersonation among other things
Data removal from Kafka for GDPR compliance is trivial in this setting. You just purge your keys. There are also key rotation and revocation protocols that are part of Ockam and we're making them simple to use from our libraries.
The underlying cryptography in Ockam SecureChannels comes from the Noise Protocol Framework (created by one of the authors of Signal Messenger's protocols). The Noise Framework protocols have many published security proofs and is gaining adoption in multiple secure systems. We are proposing an alternative to SSL/TLS but this alternative is well proven/understood in terms of it security guarantees.
Also, about malicious software at the endpoint ... Ockam Vaults can be backed by Hardware and Vault implementations are pluggable. So Key Storage and Cryptographic Operations can be delegated off the primary the processor.
So far we've built vault implementations for the Microchip ATEEC hardware which is popular in IoT circles. We plan to have Vaults for Cloud HSMs, Cloud Secret Stores, ARM TrustZone etc.
That said, if an attacker in the primary processor of an endpoint. We could protect agains key theft (with vault) ... but its very hard (maybe impossible) to protect against the attacker using the key until they are kicked out somehow.
We have a little bit and are watching the development of techniques like computing on Homomorphically Encrypted data, Multi-party Computation and Zero Knowledge Proofs with great interest.
For example, the credentials functionality in Ockam is using BBS+ signatures that enable selective disclosure of attested attributes. This has both privacy and bandwidth benefits when proving possession of a credential.
But we feel end-to-end encrypted communication is a prerequisite to building systems that compute on encrypted data. So we started with a focus on making end-to-end easy.
Some examples would be:
1. Alice is the controller of a machine in a factory, Bob is a remote worker controlling the machine from home. (there could be thousands of Alice, one Bob)
2. Alice is an internal system in Enterprise Data Center 1, Bob is a Microsevice in the Cloud
3. Alice is health monitoring device, Bob is a remote doctor's tablet. (there could be 100s of thousands of Alice. On of Bob)
4. Alice is a connected car, Bob is a service in the cloud, that uses a third party vendor's managed Kafka to communicate with Alice and wants to guarantee secure software updates / machine learning model updates to Alice (there is a fleet of Alice).
etc.
Any use case where you're using third party services/intermediaries and want to keep the vulnerability surface of your application as small as possible.
1. Alice is the controller of a machine in a factory, Bob is a remote worker controlling the machine from home. (there could be thousands of Alice, one Bob)
2. Alice is an internal system in Enterprise Data Center 1, Bob is a Microsevice in the Cloud
3. Alice is health monitoring device, Bob is a remote doctor's tablet. (there could 100s of thousands of Alice. On of Bob)
4. Alice is a connected car, Bob is a service in the cloud, that uses a third party vendor's managed Kafka to communicate with Alice and wants to guarantee secure software updates / machine learning model updates to Alice (there is a fleet of Alice).
etc.
Any use case where you're using third party services/intermediaries and want to keep the vulnerability surface of your application as small as possible.
Hey everyone! Ockam is collection Rust and Elixir libraries for end-to-end encrypted, mutually authenticated communication between edge devices and cloud services.
Ockam Workers and Ockam Routing Protocol are building blocks that help us achieve end-to-end encrypted messaging.
The above hands-on guide shows how you can creates workers and send messages to remote worker over complex routes of multiple transport layer hops.
We are building open source SDKs is multiple languages, for multiple environments to enable the following 3 things:
1. Generate, store & use secret cryptographic keys safely - in hardware or behind a tighter security boundary. There are Add-ons for Crypto Hardware Modules, Secure Enclaves, TPMs, TEEs, HSMs etc.
2. Use the above safely stored keys to establish secure, mutually authenticated, end-to-end encrypted channels. This secure channel protocol is decoupled from the network protocols which allows the secure channels to span across multiple transport layer connections and networks.
This is kinda like an end-to-end encrypted connections that are established when you use signal or whatapp messaging ... but in our case we enable that between IoT devices and services and make it easy for application developers to have granular control on it.
Imagine for example an end to end encrypted connection between your phone and your connected door bell - so the vendor of the door bell can help route the data but cannot see/store/modify/analyze the video data outside your door.
In a hospital, a patient's private data is not exposed to every device or network or vendor in the path of collecting that data (there are typically 100s of such parties), it could instead be revealed only to the patient and their doctor.
In an industrial setting, control commands to a critical machine cannot be compromised by compromising a weak network in the path of the command or business proprietary data is not revealed to every device or network vendor in the path of the data - instead they only get maintenance access to the component they are responsible for.
It's important to note here that confidentiality is only one guarantee that is provided by encryption, the other two guarantees of data integrity and authentication are critical components that are missing in a lot of deployed IoT today.
Our goal here is to give IoT application developers granular control to apply the Principle of Least Privilege to their IoT systems - which usually today have wide open attack surfaces with thin/weak boundaries.
3. Equipped with the above two foundational elements we want to enable easy solutions to scenarios that are very common in IoT. Usually application developers end up having to design ad-hoc solutions for these, our goal is to provide open source, vetted solutions for these common scenarios, for example:
Bootstrapping Trust / Device Enrollment in IoT is very hard at scale - to have cryptographically secured, mutually authenticated channels one has to some how generate unique keys in thousands/millions of devices and bootstrap trust between devices and services without leaking these keys, we are building an enrollment protocol based on Signals X3DH to make this as simple as calling a few functions.
Key Management is very hard at scale - Once you have unique keys provisioned in thousands/millions of devices, this only provides security for a short period of time ... you have to think about secure rotation and revocation of keys without physically touching every devices (which is cost prohibitive)... we are making that as easy as calling a few functions.
Authorization is very hard at scale - IoT systems have a variety authorization use cases .. I might want to authorize a friend to use my car, only for a day, without giving them my cryptographic key forever ... An industrial maintenance engineer may only be authorized to see internal telemetry data of a machine for a day etc.
We are building a general solution of such exchange of credentials and capabilities that is secure, provides granular control and respects privacy.
We chose to build the more reliable e2ee strategy first - Relays. UDP hole puncturing is in development right now. However there is extensive research that proves it in only successful in making connections in 60 to 80% of real world networks. This is why Signal does relays for example. Relays provide a highly reliable strategy. So we knew we'll want to support both and give devs and option to choose what is right for their application. Or failover from one to the other.
In addition, relays also allow store and forward and integration to other enterprise systems like Kafka. This is how we're able to to move end-to-end encrypted data through Kafka https://github.com/build-trust/ockam/tree/develop/documentat...
Store and forward as a first class feature is in development.
Scatter/Gather is a much harder problem since it involves group key agreement and challenges that come with doing that safely. This is in our long term roadmap, but we've not done any development for this yet.