Decentralized Object Storage

Encryption Keys

How encryption and encryption keys work on Tardigrade

Managing Encryption Keys

One very important design consideration is that data stored on Storj DCS is end-to-end encrypted. That means only you have the encryption keys for your data. The platform doesn't haver have access to or store your encryption keys. If you lose your keys (or lose the Access Grant containing your encryption passphrase), you will be unable to recover your data.

Encryption & Access Grants

Where an Access Grant controls what resources and operations a Satellite will allow a user to access and perform, an HD Encryption Key controls what buckets, path prefixes, and objects a user has the ability to decrypt.

This is done via the EncryptionAccess of the Uplink Client. An EncryptionAccess is a serializable collection of hierarchically-determined encryption keys, where by default the key starts at the root.

At each level of the hierarchy of buckets, path prefixes, and objects, a child HD Encryption Key is derived in essentially the same manner as the Access Grants.

The primary difference is that while a Satellite could generate restricted Access Grants that would be essentially the same artifact as a restricted Access Grant generated by an Uplink Client, a Satellite never has access to Encryption Keys.

Supported Protocols

Out-of-the-box, the Uplink Client supports two encryption standards:

  1. AES 256 GCM

  2. SecretBox

In addition, the Uplink Client is designed to be pluggable so that developers can remove the default encryption standards and replace them with a custom or preferred encryption scheme.

It doesn’t matter what encryption solution you use with your application, but it does matter that you encrypt your data. Remember that your data is erasure coded and distributed across statistically uncorrelated storage nodes that are assumed to be untrusted as they are operated by complete strangers distributed all over the globe.

In addition to not wanting to expose your data to the risk of compromise by byzantine storage nodes, unencrypted data creates a potential insider threat from rogue satellite operators.

During ordinary Satellite file repair operation, file segments are downloaded by Satellites, re-encoded, and redistributed across storage nodes. As long as all data is encrypted client-side, the repair function does not expose the privacy or security of the data.

Allowing Decryption for Shared Access to Objects

The first part of this documentation explains how Access Grants work when access to objects stored on the Tardigrade Platform is to be shared between applications. Encryption keys work in a very similar way.

Each Uplink Client has an Encryption Passphrase that is configured when the Uplink Client is initially set up. This Encryption Passphrase is used to encrypt all objects and metadata stored on the Tardigrade Network.

When an Uplink Client (libuplink, Uplink CLI, or Uplink S3 Gateway) is configured to use an Encryption Passphrase, the Uplink Client automatically creates an HMAC signature that is encoded in the metadata of the object at the time of encryption. At each level of the hierarchy of buckets, path prefixes, and objects, a child HD Encryption Key is derived, and the hierarchy is encoded in the object and object metadata. Based on where an object falls in the hierarchy, if the parent Access Grant is known, an Encryption Key can be derived for any level of the hierarchy that is valid from that point in the hierarchy and below to any child objects below it in the hierarchy.

Similar to the hierarchically derived structure of Access Grants, developers or applications don’t need to worry about the complexity of maintaining a set of keys. Since the hierarchy is encoded into the encryption mechanism, a shareable key can be derived on demand. The shareable HD Encryption Key is described as an EncryptionAccess in the Uplink Client.

Important Design Point

While the Access Grant is intended to be passed from an Uplink Client to a Satellite, the EncryptionAccess is designed to be passed peer to peer, but never to the Satellite. For efficiency and ease of use, the file sharing functions of the Uplink Client constructs a ‘security envelope’ that contains both the Access Grant and the EncryptionAccess, that is passed peer-to-peer. The expected application behavior is then for the receiving peer Client Uplink to separate the Access Grant and the EncryptionAccess, pass the Access Grant to the Satellite to obtain access to the object, and then, as the Object is downloaded, it is decrypted client-side using the HD Key.