The goal of this guide is to utilize Aranya and AQC for sending end-to-end encrypted data between applications. See the core concepts section for more details on the components used in this walkthrough. To see an example implementation with code, see the examples in the Aranya repo. This guide focuses on the high level operations and does not provide code.
This guide assumes the default policy is being used for authorization and key management.
The first step is to create config files for each Aranya daemon and run a daemon for each device that will be part of the team. At startup, the daemon will generate a keybundle containing the device identity and other cryptographic keys, if that information has not already been generated.
Once the device daemons have been started, create a team of devices on the Aranya graph by having the team owner device create the team and add the public key bundles of the other devices to the team. Each device must configure other devices on the network as sync peers in order to receive the latest updates to the Aranya graph as new commands are added to the graph. Each operation such as creating a team, adding a device to a team, assigning permissions to use labels, etc. adds commands to the Aranya graph which peers must sync via the network in order to stay up to date with the state of the team.
Once the team has been created, assign AQC labels to pairs of devices that are allowed to
communicate securely with each other via AQC channels. Pairs of devices with the role of Member
can create AQC channels with a certain AQC label as long as both devices have permission to use the
label assigned to them by the Operator
. Once an AQC channel has been created between two devices,
they can create bidirectional and unidirectional QUIC streams to securely send and receive data
with each other via the QUIC transport.
Pre-built daemon executable for various platforms are attached to the latest release. If there is already an executable available for your architecture, building the daemon is optional.
The following platforms are currently supported:
Other unix-based platforms with matching hardware architectures are likely supported.
Platforms that are not yet supported:
The following dependencies must be present on the machine before building Aranya:
Checkout the aranya repo locally.
To build the daemon, invoke:
$ cargo make build
The daemon executable will be generated at:
<repo>/target/release/aranya-daemon
At runtime, each daemon loads a configuration file. This config file includes syncer network address configuration and a path to non-volatile Aranya graph storage. A complete example of a daemon configuration file can be found here.
Based on this example, create a configuration file for each device daemon. Remember to change the IP addresses, ports, and other device-specific values for each device.
Or, directly use the daemon configuration files from the C example. This example has configs for each device in the tutorial.
Now that the daemons have been configured, we can run them!
Once the daemon has been built, it can be run like this:
$ target/release/aranya-daemon <path to daemon config file>
We are now ready to create an Aranya team and set up AQC channels to communicate between devices on the team. The step-by-step process for each of these portions is listed below, followed by an outline of the relevant APIs and reference documentation needed to do the integration in the desired language.
Once an Aranya team has been created, AQC labels and channels can be created, and data can be sent via those AQC channels:
Client
methods:
create_team()
- Create an Aranya teamadd_team()
- Add an Aranya team to a deviceTeam
methods:
add_device_to_team()
- Add a device to the Aranya teamadd_sync_peer()
- Add peer to sync withassign_aqc_net_identifier()
- Assign an AQC network identifier to a devicecreate_label()
- Create a new AQC labelassign_label()
- Assign an AQC label to a deviceAqcChannels
methods:
create_bidi_channel()
- Create a bidirectional AQC channelAqcBidiChannel
methods:
create_bidi_stream()
- Create a bidirectional AQC streamreceive_stream()
- Receive an AQC streamAqcPeerStream
methods:
into_bidi()
- Tries to convert stream into bidi streaminto_receive()
- Tries to convert stream into receive streamAqcBidiStream
methods:
send()
- Send data via the streamreceive()
- Receive data via the streamtry_receive()
- Try to receive data via the streamAqcReceiveStream
methods:
receive()
- Receive data via the streamtry_receive()
- Try to receive data via the streamaranya_create_team()
- Create an Aranya teamaranya_add_team()
- Add an Aranya team to a devicearanya_add_device_to_team()
- Add a device to the Aranya teamaranya_add_sync_peer()
- Add peer to sync witharanya_aqc_assign_net_identifier()
- Assign an AQC network identifier to a devicearanya_create_label()
- Create a new AQC labelaranya_assign_label()
- Assign an AQC label to a devicearanya_aqc_create_bidi_channel()
- Create a bidirectional AQC channelaranya_aqc_receive_channel()
- Receive an AQC channelaranya_aqc_bidi_create_bidi_stream()
- Create a bidirectional AQC streamaranya_aqc_bidi_stream_send()
- Send data via bidirectional streamaranya_aqc_bidi_stream_try_recv()
- Try to receive data via a bidirectional streamThis getting started guide is intended as an example to be run on a single machine. As such, a single machine is used to generate all key bundles and run all daemons under a single user account.
In production, each Aranya device key bundle should be created under separate user accounts on their respective machines and daemon working directories should only grant read-write access to their respective daemon executable. This avoids a single access point for all Aranya device keys in case a machine or user account is compromised.
Permission for devices to execute the operations outlined in this guide are determined by the implemented policy.