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 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.