End-to-end encryption and mutual authentication for distributed applications.

Overview

Ockam

Rust and Elixir libraries for end-to-end encrypted, mutually authenticated, secure communication.

Data, within modern distributed applications, are rarely exchanged over a single point-to-point transport connection. Application messages routinely flow over complex, multi-hop, multi-protocol routes — across data centers, through queues and caches, via gateways and brokers — before reaching their end destination.

Transport layer security protocols are unable to protect application messages because their protection is constrained by the length and duration of the underlying transport connection.

Ockam is a suite of programming libraries and infrastructure that makes it simple for our applications to guarantee end-to-end integrity, authenticity, and confidentiality of data.

We no longer have to implicitly depend on the defenses of every machine or application within the same, usually porous, network boundary. Our application's messages don't have to be vulnerable at every point, along their journey, where a transport connection terminates.

Instead, our application can have a strikingly smaller vulnerability surface and easily make granular authorization decisions about all incoming information and commands.


Features

  • End-to-end encrypted, mutually authenticated secure channels.
  • Key establishment, rotation, and revocation - for fleets, at scale.
  • Identity profiles isolated by privacy contexts.
  • Attribute-based Access Control - credentials with selective disclosure.
  • Add-ons for a variety of operating environments, transport protocols, and cryptographic hardware.
  • Libraries for multiple languages - Rust, Elixir (more on the roadmap).

Hello Ockam

Let's write a simple example to create an encrypted secure channel between Alice and Bob. When a message is sent through this channel it will be encrypted when it enters the channel and decrypted just before it exits the channel.

For the purpose of our first example, we'll create a local channel within one program. In later examples, you'll see that it's just as easy to create end-to-end protected channels over multi-hop, multi-protocol transport routes:

  1. Install Rust

    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
    
  2. Setup a new cargo project to get started.

    cargo new --lib hello_ockam && cd hello_ockam && mkdir examples &&
      echo 'ockam = "*"' >> Cargo.toml && cargo build
    

    If the above instructions don't work on your machine, please post a question, we would love to help.

  3. Create a file at examples/hello.rs and copy the below code snippet to it.

    // examples/hello.rs
    
    use ockam::{route, Context, Entity, Result, TrustEveryonePolicy, Vault};
    
    #[ockam::node]
    async fn main(mut ctx: Context) -> Result<()> {
        // Create a Vault to safely store secret keys for Alice and Bob.
        let vault = Vault::create(&ctx).await?;
    
        // Create an Entity to represent Bob.
        let mut bob = Entity::create(&ctx, &vault).await?;
    
        // Create a secure channel listener for Bob that will wait for requests to
        // initiate an Authenticated Key Exchange.
        bob.create_secure_channel_listener("bob", TrustEveryonePolicy).await?;
    
        // Create an entity to represent Alice.
        let mut alice = Entity::create(&ctx, &vault).await?;
    
        // As Alice, connect to Bob's secure channel listener and perform an
        // Authenticated Key Exchange to establish an encrypted secure channel with Bob.
        let channel = alice.create_secure_channel("bob", TrustEveryonePolicy).await?;
    
        // Send a message, ** THROUGH ** the secure channel,
        // to the "app" worker on the other side.
        //
        // This message will automatically get encrypted when it enters the channel
        // and decrypted just before it exits the channel.
        ctx.send(route![channel, "app"], "Hello Ockam!".to_string()).await?;
    
        // Wait to receive a message for the "app" worker and print it.
        let message = ctx.receive::<String>().await?;
        println!("App Received: {}", message); // should print "Hello Ockam!"
    
        // Stop all workers, stop the node, cleanup and return.
        ctx.stop().await
    }
    
  4. Run the example

    cargo run --example hello
    

Congratulations on running your first Ockam program 🥳 .

A lot happened when you ran this small example. It created a secure vault, spawned workers to represent entities, established a mutually authenticated channel and then routed a message through that channel. This involved running cryptographic protocols for generating keys, authenticating as an entity, performing an authenticated key exchange and exchanging messages with authenticated encryption.

To learn more about how we make these powerful cryptographic protocols simple to use, please have a look at our step-by-step guide where we introduce the building blocks in Ockam.


Concepts

Here's a high-level view of the core ideas in Ockam.

Ockam

To learn more please see our step-by-step guide.

Next Steps

  • Build End-to-End Encryption with Rust: In this hands-on guide, we create two small Rust programs called Alice and Bob. Alice and Bob send each other messages, over the network, via a cloud service. They mutually authenticate each other and have a cryptographic guarantee that the integrity, authenticity, and confidentiality of their messages is protected end-to-end. 👉

  • Build End-to-End Encryption through Kafka: In this guide, we show two programs called Alice and Bob. Alice and Bob send each other messages, over the network, via a cloud service, through Kafka. They mutually authenticate each other and have a cryptographic guarantee that the integrity, authenticity, and confidentiality of their messages is protected end-to-end. The Kafka instance, the intermediary cloud service and attackers on the network are not be able to see or change the contents of en-route messages. The application data in Kafka is encrypted. 👉

  • How to end-to-end encrypt all application layer communication: In this hands-on guide, we'll create two simple Rust programs to transparently tunnel arbitrary application layer communication through Ockam's end-to-end encrypted, mutually authenticated secure channels. These example programs are also available in a docker image so you can try them without setting up a rust toolchain. 👉

  • Build a secure access tunnel to a service in a remote private network: In this guide, we'll write a few simple Rust programs to programmatically create secure access tunnels to remote services and devices that are running in a private network, behind a NAT. We'll then tunnel arbitrary communication protocols through these secure tunnels. 👉

  • Step-by-Step Deep Dive: In this step-by-step guide we write many small rust programs to understand the various building blocks that make up Ockam. We dive into Node, Workers, Routing, Transport, Secure Channels and more. 👉

License

The code in this repository is licensed under the terms of the Apache License 2.0.


Continuous Integration Contributor Covenant


Comments
  • Diagnose `Cannot drop a runtime ...` error in rust nodes

    Diagnose `Cannot drop a runtime ...` error in rust nodes

    This error shows up often

    thread 'tokio-runtime-worker' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.', /Users/mrinal/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/runtime/blocking/shutdown.rs:51:21
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    

    We love helping new contributors! If you have questions or need help as you work on your first Ockam contribution, please leave a comment on this discussion. If you're looking for other issues to contribute to, checkout issues labeled - https://github.com/build-trust/ockam/labels/good%20first%20issue or https://github.com/build-trust/ockam/labels/help%20wanted

    Type: Bug help wanted Component: Core 
    opened by mrinalwadhwa 43
  • add `no_main` arg support in ockam::node macro

    add `no_main` arg support in ockam::node macro

    opened by pro465 30
  • fix(rust): Check address before creating stuff

    fix(rust): Check address before creating stuff

    Current Behavior

    described in #3061

    Proposed Changes

    fixes #3061.

    Checks

    auto-merge 
    opened by pro465 21
  • Implement the `ockam secure-channel show` command

    Implement the `ockam secure-channel show` command

    Currently:

    > ockam node create n1 --tcp-listener-address 127.0.0.1:6001
    > ockam node create n2 --tcp-listener-address 127.0.0.1:6002
    
    Node:
      Name: n2
      ...
        Service:
          Type: Secure Channel Listener
          Address: /service/api
          Route: /ip4/127.0.0.1/tcp/6002/service/api
          Identity: P7dc502c795201c2d816749ea45ff51a416dce16ef0fe1b65ab4a642899e3b4d8
          Authorized Identities:
            - P7dc502c795201c2d816749ea45ff51a416dce16ef0fe1b65ab4a642899e3b4d8
      ...
    

    Since n2 gets a secure channel listener at /ip4/127.0.0.1/tcp/6002/service/api We can create secure channels from n1 to this listener

    > ockam secure-channel create --from n1 --to /ip4/127.0.0.1/tcp/6002/service/api \
         --authorized-identifier P7dc502c795201c2d816749ea45ff51a416dce16ef0fe1b65ab4a642899e3b4d8
    /service/9a87006896ec1920da7fdbb233449d24
    

    The created secure channel has the following properties:

    1. an address /service/9a87006896ec1920da7fdbb233449d24
    2. a route to the secure channel listener that it connects to /ip4/127.0.0.1/tcp/6002/service/api
    3. the identifier it uses for itself
    4. a list of identifiers that are authorized to be presented by the secure channel listener.

    Some of this secure channel info is stored in a service registry when they are created. Some of it is not. https://github.com/build-trust/ockam/blob/c397c97078dc4962d29d0180d32e579d3ca633c3/implementations/rust/ockam/ockam_api/src/nodes/service/secure_channel.rs#L42-L46

    The command to create the secure channels is defined here https://github.com/build-trust/ockam/tree/develop/implementations/rust/ockam/ockam_command/src/secure_channel

    Desired:

    We want to add a ockam secure-channel show command that would show info of a secure channel given its address with all of the above details.

    Related #3188


    We love helping new contributors! If you have questions or need help as you work on your first Ockam contribution, please leave a comment on this discussion. If you're looking for other issues to contribute to, checkout issues labeled - https://github.com/build-trust/ockam/labels/good%20first%20issue or https://github.com/build-trust/ockam/labels/help%20wanted

    good first issue help wanted Implementation: Rust Component: Command 
    opened by mrinalwadhwa 20
  • Add unit test coverage to entity package

    Add unit test coverage to entity package

    Thank you for sending a pull request :heart:

    Checklist

    Please review the guidelines for contributing code to this repository. And check [x] all the boxes that apply:

    • [x] This request pulls a feature/bugfix branch (right side) from my fork. Not my master.
    • [ ] This request pulls against ockam-network/ockam’s develop branch (left side).
    • [x] Build succeeds ./build with no linter warnings or test failures.
    • [x] All code matched our code formatting conventions.
    • [x] Commit messages match our conventions and all commits are signed.
    • [x] This request includes tests and documentation for all new code.

    Proposed Changes

    Please describe the changes in your pull request.

    If this pull request resolves an already recorded bug or a feature request, be sure to link to that issue.

    opened by malnick 18
  • Support DID Auth

    Support DID Auth

    DID Auth: https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md https://www.slideshare.net/SSIMeetup/introduction-to-did-auth-with-markus-sabadello

    Status: Abandoned Priority: Medium Status: In Progress Type: Enhancement 
    opened by mrinalwadhwa 15
  • feat(rust): add examples section to ockam message send command's help

    feat(rust): add examples section to ockam message send command's help

    PR purpose: Address issue #3257

    Current Behaviour

    ockam message send --help

    does not display any examples.

    Desired Behaviour

    As part of the help, the following examples section should be shown:

    EXAMPLES
    
        # Create two nodes
        > ockam node create n1
        > ockam node create n2
    
        # Send a message to the uppercase service on node n1
        > ockam message send hello --to /node/n1/service/uppercase
        HELLO
    
        # Send a message to the uppercase service on node n1 from node n1
        > ockam message send hello --from /node/n2 --to /node/n1/service/uppercase
        HELLO
    
        # Create a secure channel from node n1 to the api service on node n1
        # Send a message through this encrypted channel to the uppercase service
        > ockam secure-channel create --from /node/n1 --to /node/n2/service/api \
            | ockam message send hello --from /node/n1 --to -/service/uppercase
        HELLO
    
    LEARN MORE
    
    auto-merge 
    opened by chrischiedo 14
  • Example - Node and Workers

    Example - Node and Workers

    HELLO NODE AND WORKERS

    Create a local Ockam Node - A

    • Create a local "echoer" Worker on A
    • Send the local "echoer" Worker a message
    • Receive a reply from the local "echoer"
    opened by mrinalwadhwa 14
  • github - shellcheck workflow

    github - shellcheck workflow

    Resolves #3489

    Checks

    hacktoberfest-accepted 
    opened by elpiel 13
  • Refactor `tcp connection delete` command to use `rpc` abstraction and to stop mapping errors manually

    Refactor `tcp connection delete` command to use `rpc` abstraction and to stop mapping errors manually

    Command: tcp connection delete

    Current

    The current implementation is calling std::process::exit, which is something we want to stop using to handle errors properly and give the user a better-formatted output when a command fails.

    It's also using the connect_to function, which can be simplified by using the Rpc utils. Check out how this is done in the subscription commands, for example.

    Desired

    • run method (main entry point of the subcommand) should contain a single line of code calling a function (run_impl/rpc/...) that returns a crate::Result<()>
    • std::process::exit should not be used to manually map the errors of the command's logic
    • run method will return (). The error will be internally handled within the node_rpc function
    • If you need to replace an std::process::exit by an actual error, you can use something like Err(crate::error::Error::new(exitcode::..., anyhow!(...))
    • Use rpc abstraction instead of connect_to

    You can take the subscription commands as a reference.


    We love helping new contributors! If you have questions or need help as you work on your first Ockam contribution, please leave a comment on this discussion. If you're looking for other issues to contribute to, checkout this discussion and labels - https://github.com/build-trust/ockam/labels/good%20first%20issue or https://github.com/build-trust/ockam/labels/help%20wanted

    good first issue help wanted Implementation: Rust Component: Command hacktoberfest 
    opened by adrianbenavides 13
  • Refactor `ockam transport ...` commands into `ockam tcp-...` commands

    Refactor `ockam transport ...` commands into `ockam tcp-...` commands

    Create

    We currently have

    ockam transport create tcp-connector ...
    ockam transport create tcp-listener ...
    

    We want to change to:

    ockam tcp-connection create ...
    ockam tcp-listener create ...
    

    Without changing their behavior.

    List

    We currently have

    ockam transport list --node n1
    

    This will list both tcp listeners and tcp connection.

    We want to change it to

    ockam tcp-connection list --node n1
    

    to list connections, and

    ockam tcp-listener list --node n1
    

    to list listeners

    Delete

    We currently have

    ockam transport delete --node n1 <TRANSPORT_ID>
    

    which will delete either connections or listeners.

    We want to change it to:

    ockam tcp-listener delete --node n1 <TRANSPORT_ID>
    

    and

    ockam tcp-connection delete --node n1 <TRANSPORT_ID>
    

    Code

    The code for these commands is here: https://github.com/build-trust/ockam/tree/develop/implementations/rust/ockam/ockam_command/src/transport


    Related: #3077 #3078

    good first issue help wanted Implementation: Rust Component: CLI Component: Command 
    opened by mrinalwadhwa 13
  • set default shell to bash in shft workflow

    set default shell to bash in shft workflow

    Current Behavior

    Currently the shft workflow doesn't have a default shell option at job level

    Proposed Changes

    set default shell to bash in publish crates workflow

    Checks

    opened by RishiKumarRay 0
  • Kafka portals commands/service

    Kafka portals commands/service

    In order to enable kafka portals https://github.com/build-trust/ockam/issues/3963 there needs to be a CLI command OR a service to start consumer and producer sides of the kafka portal.

    It should be configured with:

    Consumer:

    • IP to listen on
    • Port (or port range) to listen on, port range is used for broker port mapping
    • Forwarding address of the consumer on the project node (may use project prefix)
    • (optional) route to tunnel client listener service, could use default if project is configured

    Producer:

    • IP to listen on
    • Port (or port range) to listen on, port range is used for broker port mapping
    • Forwarding address of the consumer on the project node (may use project prefix)
    • (optional) route to tunnel client listener service, could use default if project is configured
    opened by hairyhum 0
  • Kafka portals broker mapping

    Kafka portals broker mapping

    Kafka binary protocol instructs clients to connect to different brokers (kafka servers) to address different topic partitions. In order to discover which broker is used for which partition, the metadata request is used: https://kafka.apache.org/24/protocol.html#The_Messages_Metadata

    This protocol response assigns a node_id to each broker and uses it as a reference in the partitions information.

    Since application client cannot connect directly to kafka brokers, kafka portal should replace them in the metadata response with local addresses (with different ports) and save the mapping between local ports (which application client is going to connect to) and remote brokers. Then it needs to add information about which remote broker it's addressing in every request using Wrapped kafka request/response format described in https://github.com/build-trust/ockam/issues/3963

    Metadata request: Kafka end-to-end - Broker mapping metadata

    After metadata request: Kafka end-to-end - Broker mapping request

    opened by hairyhum 0
  • Use global default shell in `shfmt.yml` workflow

    Use global default shell in `shfmt.yml` workflow

    To remove the need to repeat default shell declaration in our workflow, we should set a global default so that it is available across all jobs in https://github.com/build-trust/ockam/blob/cdf925aa2adb4439061449e5ea5f9ad774833e20/.github/workflows/shfmt.yml#L1 More here https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults

    good first issue help wanted Component: CI/CD 
    opened by metaclips 2
  • Use global default shell in `shellcheck.yml` workflow

    Use global default shell in `shellcheck.yml` workflow

    To remove the need to repeat default shell declaration in our workflow, we should set a global default so that it is available across all jobs in https://github.com/build-trust/ockam/blob/cdf925aa2adb4439061449e5ea5f9ad774833e20/.github/workflows/shellcheck.yml#L1 More here https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults

    good first issue help wanted Component: CI/CD 
    opened by metaclips 0
  • Use global default shell in `semgrep.yml` workflow

    Use global default shell in `semgrep.yml` workflow

    To remove the need to repeat default shell declaration in our workflow, we should set a global default so that it is available across all jobs in https://github.com/build-trust/ockam/blob/cdf925aa2adb4439061449e5ea5f9ad774833e20/.github/workflows/semgrep.yml#L1 More here https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults

    good first issue help wanted Component: CI/CD 
    opened by metaclips 0
Releases(ockam_v0.77.0)
Owner
Ockam | Trust for Data-in-Motion
Tools for mutual authentication and end-to-end encrypted messaging between distributed applications, in any environment, anywhere.
Ockam | Trust for Data-in-Motion
Rust encryption library for practical time-lock encryption.

tlock_age: Hybrid Timelock Encryption/Decryption in Rust tlock_age is a library to encrypt and decrypt age filekey using tlock scheme. It provides an

Thibault 5 Mar 29, 2023
Nym provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous transactions using blinded, re-randomizable, decentralized credentials.

The Nym Privacy Platform The platform is composed of multiple Rust crates. Top-level executable binary crates include: nym-mixnode - shuffles Sphinx p

Nym 653 Dec 26, 2022
An open source desktop wallet for nano and banano with end-to-end encrypted, on chain messaging using the dagchat protocol.

An open source wallet with end-to-end encrypted, on chain messaging for nano and banano using the dagchat protocol.

derfarctor 22 Nov 6, 2022
NymDrive is a complete, end-to-end encrypted file syncing daemon that runs over the Nym network.

NymDrive NymDrive is a complete, end-to-end encrypted file syncing daemon that runs over the Nym network. Features Active file monitoring of changes i

Hans Bricks 16 Jul 12, 2022
CLI password manager with encryption: AES256, Salsa20 and Chacha20, with cross platform and exclusive features

Keep My House (CLI) CLI password manager with encryption: AES256, Salsa20 and Chacha20, with cross platform and exclusive features Features AES256 GCM

null 4 Sep 7, 2023
🔐 UPLINK is a Rust lightweight (2MB) tool for file transfer and remote management that uses AES-GCM and Envelope Encryption over WebSockets.

UPLINK ░▒▓█▓▒░░▒▓█▓▒░▒▓███████▓▒░░▒▓█▓▒░ ░▒▓█▓▒░▒▓███████▓▒░░▒▓█▓▒░░▒▓█▓▒░ ░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░ ░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█

Krystian Bajno 5 Sep 28, 2024
A safe implementation of the secure remote password authentication and key-exchange protocol (SRP), SRP6a and legacy are as features available.

Secure Remote Password (SRP 6 / 6a) A safe implementation of the secure remote password authentication and key-exchange protocol (SRP version 6a). Ver

Sven Assmann 10 Nov 3, 2022
Meta-repository for Miscreant: misuse-resistant symmetric encryption library with AES-SIV (RFC 5297) and AES-PMAC-SIV support

The best crypto you've never heard of, brought to you by Phil Rogaway A misuse resistant symmetric encryption library designed to support authenticate

miscreant. 480 Dec 8, 2022
DexiosGUI - Simple cross-platform drag-and-drop Dexios file encryption

DexiosGUI Simple cross-platform drag-and-drop Dexios file encryption. Latest Windows x64 release is here. DexiosGUI is a Qt/C++ app for encrypt and de

Fabrice Corraire 4 Jul 25, 2022
Chargo is a tool for file encryption/decryption. It's based on Argon2 and ChaCha20Poly1305 algorithms.

| Documentation Chargo is a tool for file encryption/decryption with password. It's based on Argon2 and ChaCha20Poly1305 algorithms. From arg2u with ♥

Airat Galiullin 7 Jan 1, 2023
rabe is an Attribute Based Encryption library, written in Rust

Rabe rabe is a rust library implementing several Attribute Based Encryption (ABE) schemes using a modified version of the bn library of zcash (type-3

Fraunhofer AISEC 52 Dec 15, 2022
WebAssembly wrapper of the rage encryption library

rage-wasm: WebAssembly wrapper of rage rage is a simple, modern, and secure file encryption tool, using the age format. It features small explicit key

Kan-Ru Chen 35 Dec 16, 2022
A Rust library for lattice-based additive homomorphic encryption.

Cupcake Cupcake is an efficient Rust library for the (additive version of) Fan-Vercauteren homomorphic encryption scheme, offering capabilities to enc

Facebook Research 365 Dec 11, 2022
A Rust binary for file encryption to multiple participants.

Kaspa-miner A Rust binary for file encryption to multiple participants. Installation From Sources With Rust's package manager cargo, you can install k

Elichai Turkel 31 Dec 30, 2022
A Rust Library of China's Standards of Encryption Algorithms (SM2/3/4)

Libsm Libsm is an open source pure rust library of China Cryptographic Algorithm Standards. It is completed by a collaborative effort between the Cryp

CITAHub 149 Dec 23, 2022
In addition to encryption library, pure RUST implementation of SSH-2.0 client protocol

In addition to encryption library, pure RUST implementation of SSH-2.0 client protocol

陈年旧事。 73 Jan 1, 2023
A secure file encryption utility, written in rust.

Dexios Dexios What is it? Building notes Checksums Performance Output file sizes Environment Variables Key Inputs Usage Examples To Do What is it? Dex

brxken 156 Dec 22, 2022
The Hybrid Public Key Encryption (HPKE) standard in Python

Hybrid PKE The Hybrid Public Key Encryption (HPKE) standard in Python. hybrid_pke = hpke-rs ➕ PyO3 This library provides Python bindings to the hpke-r

Cape Privacy 4 Nov 7, 2022
Project Masterpass is a deterministic databaseless key management algorithm, aimed to help those who cannot protect their encryption keys in storage

Project Masterpass (working title) Attention! This project is still under heavy development, and SHOULD NOT be used in practice, as the algorithms cou

Gyorgy Wang 2 Sep 11, 2022