Sponsored by
Sponsored by
Aranya Fast Channels (AFC) is an an implementation of an Aranya data plane that provides effecient buffer-based encryption API.
An application can use AFC to encrypt/decrypt data using the authority from the graph while implementing its own custom transport. Aranya provides a mechanism for key agreement and segmentation.
AFC is designed in a transport agnostic way to allow applications to have full control over how data is transmitted while relying on Aranya for its encryption and security properties. This makes AFC extremely versatile because it can be deployed anywhere. These are some examples of places that AFC could be deployed (it’s not an exhaustive list):
This flexibility means that AFC is a powerful tool for securing communications in heterogenous networks with different hardware and protocols operating at each link. AFC can be adopted into existing, complex networks with minimal computational and bandwidth overhead without changing the existing network transports that have already been implemented.
Off-Graph data refers to information that interacts with Aranya but is not stored within the graph structure itself. Off-graph data is distinct from on-graph data. This data:
In AFC, ephemeral commands (see the relevant spec here: aranya sessions note ) are used to establish channels and agree on encryption/decryption keys, while the data sent through those channels does not need to interact with Aranya. Once the ephemeral command is processed against the policy, it will be dropped and not added to the graph.
AFC only supports unidirectional channels. This means one of the two peers is the writer/sender while the other is the reader/receiver.
If data needs to be sent both ways, create an AFC channel for each direction data should be sent in.
The creator of the channel is automatically designated as the writer/sender while the receiver of the channel control message is automatically designated as the reader/receiver.
The sender can only perform encryption operations on plaintext data with seal().
The receiver can only perform decryption operations on ciphertext data with open().
A channel is used to group together two devices based on specific roles, permissions or attributes. Device IDs identify the endpoints of the channel, and the topic label is an additional attribute available to manage the access and permissions for channels.
In order to create an AFC channel:
CanUseAfc permissionOnce the participants have permission, they can open any number of channels on a given label.
To create a channel, a device will generate an ephemeral command and transfer it to the peer. An ephemeral command is one that utilizes the same policy as all other commands, but which is never added to the DAG for persistent storage. The command is given to the Aranya runtime and produces effects based on the state of the factdb, but does not modify the state of the system. Due to the fact that ephemeral commands are not stored on the graph, devices need to transmit the command through an external transport mechanism. The ephemeral command used for creating a channel includes the information required for the peers to set up the encryption keys that will be used for the channel. This command used to establish the channel contains encapsulated keys for the peer and metadata about the channel.
Figure 5: Workflow when creating a Channel. In this case, the channel transport is handled by the application.
After processing the ephemeral create channel command, the Aranya daemon loads the encryption key into the shared memory along with the channel metadata for the client to utilize.
Once the serialized control message has been received by the peer, the peer is able to set up the channel decryption key and complete
the channel setup. With the completed channel, the seal() function is used to encrypt the data. From there, the application
can move the data using the preferred transport. On the receiving side, the application uses the open() function on the corresponding
channel to decrypt the data. The API also includes sequence numbers in the authenticated data header, allowing devices to check for
replayed messages.
The AFC client API stores metadata about the channel in the channel object, so the application just has to ensure it is passing the ciphertext to the correct channel. Its the responsibility of the application to track the relationship between ciphertext and channels.
Once a channel is no longer in use, it can be deleted. Deleting a channel involves one or both of the participants invoking the delete channel method. The local state of the channel is removed and that participant will no longer be able to send or receive data on the channel.
Whenever the policy emits a CheckValidAfcChannels effect, the daemon runs the query_afc_channel_is_valid() query on each channel stored in the shared-memory, deleting any channels that are no longer valid. Examples of events that can cause channels to be deleted:
CanUseAfc permission)CanUseAfc permission from the role of a device in the channelIf a channel is no longer valid for either peer according to the policy, the channel will be deleted by both peers.