[ARTICLE] Tardigrade Thursday - Security Access Part 1

Hey all, its Thursday! Check out our article on concepts and security terms below. This is part 1
Next week we’ll have on John Gleeson for Part 2. It’s a meaty chat about :

  • Security
  • Erasure Codes
  • Macaroons
  • Access
3 Likes

A New Standard in Data Security

Tardigrade is the world’s first enterprise-grade, decentralized cloud storage service—a cloud storage service powered by the Storj open source platform. Through decentralization, Tardigrade is more secure, more performant, more affordable, and more private—all by default.

Privacy and security are critical for distributed and decentralized systems. This is why we implemented technologies in the platform to ensure data remains secure and private in a trustless environment.

A combination of pushing end-to-end encryption client-side, adding macaroon API keys and providing simple, yet granular control to developers reduces the threat surface on your critical data to almost zero. With Tardigrade, developers can move access management from a centralized server to the edge.

The Power Behind Tardigrade Secure Storage

A Multilayered Approach for Secure Encryption

Tardigrade utilizes multiple encryption technologies that work in concert to ensure your data is
secure—giving you absolute control over how your data is accessed.

Tardigrade Encryption Methodology

All data stored on Tardigrade is end-to-end encrypted on the client-side. What this means is users control all encryption keys and the result is an extremely private and secure data store. Both the objects and the associated metadata are encrypted using randomized, salted, path-based encryption keys. The randomized keys are then encrypted with the user’s encryption passphrase. Neither Storj Labs nor any Storage Nodes have access keys, data, or metadata.

Client-Side Encryption

Every object stored on the platform is first split into 64 MB segments, then encrypted using one of
two included encryption schemes, the default AES-GCM 256 CTR, or Secretbox. The encryption scheme is designed to be pluggable, meaning developers may also integrate custom encryption schemes if requirements dictate it.

This encryption is designed to avoid using the same keys for content encryption of different files and different segments of the same file. This is advantageous because it makes sharing of encrypted files more secure and it doesn’t put other segments or files at risk if one of them is compromised.

Path-Based Encryption

Paths are encrypted in a hierarchical and deterministic way using the root encryption key. Each path component is encrypted separately based on information derived from previous path components.

Consider an unencrypted path p made up of path elements p1/p2/…/pn. The end goal is to generate an encrypted path e, which is made up of elements e1/e2/…/en. We achieve this using the process shown.

The order of listed items is determined by the paths stored on the Satellite. Listed items will always be returned in an order based on their encrypted path names, but won’t be ordered alphabetically when the paths are decrypted.

This method of path encryption allows users to share content under their path with another user without revealing anything at a higher level.

Content and Metadata Encryption

When a user uploads a file, it’s read one segment at a time on the client-side. Before each segment is split up, erasure encoded, and stored on remote Storage Nodes, a random
content-encryption key is generated. A starting nonce equal to the segment number is created and used, along with the random key, to encrypt the segment data.

Next, we generate the derived key, dk, which we define with sn+1 = HMAC(sn, “content”), where dk = K(sn+1) and sn is the last secret generated from the file path using the technique detailed
above. We add one more dimension of key derivation for content encryption to ensure a user can’t derive the access key to an unshared file that has the same prefix.

Each segment has metadata associated with it on the Satellite. Segment metadata includes the random key used to encrypt a segment’s content. We encrypt the random key with the derived key (dk) and a randomly generated nonce. The nonce is stored along with the encrypted content
key in the segment metadata. This way, we use a different random encryption key for each segment, but anyone with access to the derived key can decrypt those keys.

The encryption algorithm used for content and metadata is easily configurable between AES-GCM
and Secretbox, which are both authenticated encryption algorithms. This means if any encrypted
data is tampered with, the client downloading the data will know about it once the data is
decrypted. The layers of content encryption mean only you know what you’ve stored on the
platform.

2 Likes

Distributed Data Storage

Privacy and security are further enhanced as the encrypted, erasure-coded pieces of each segment are spread over statistically uncorrelated Storage Nodes. Any effort to compromise a file requires significant coordinated effort beyond the effort to crack a single encryption key.

Take for example a 1GB file stored on Tardigrade. The file is split into 16 different segments, with 16 different randomized, salted path-based segment encryption keys, each segment divided into 80 pieces, with a total of 1,280 pieces stored on 1,280 different Storage Nodes

If an individual Storage Node Operator went rogue, the Node Operator could at most gain access to a single encrypted, erasure-coded piece of a single file; this piece is only one out of twenty-nine pieces of one segment out of sixteen, that comprise the file. No usable information can be derived
and if the piece is deleted, Tardigrade detects this and repairs as necessary.

Encryption Key Ownership

Your encryption keys are your data. Tardigrade never has access to your encryption keys. We provide all the tools to ensure your data security and privacy are protected, along with the ability to share that data when, how, and with whom you allow. If you lose your encryption keys, however, then you’ve lost access to your data. Always make sure you’ve backed up your encryption key and stored it somewhere safe.

1 Like

Sophisticated Access Management with Macaroon-Based API Keys

While encryption is very important to ensure privacy and security for data storage, control over when and how data is shared and accessed is equally important. Tardigrade provides
macaroon-based API keys for managing access to objects.

Hierarchically Derived (HD) API Keys

Similar to hierarchically derived (HD) encryption keys, HD API keys are derived from a parent API key. Unlike the HD encryption keys where the hierarchy is derived from the path prefix structure of the object storage hierarchy, the hierarchy of API keys is derived from the structure and relationship of access restrictions.

HD API keys embed the logic for the access it allows and can be restricted, simply by embedding the path restrictions and any additional restrictions within the string that represents the
macaroon. Unlike a typical API key, a macaroon isn’t a random string of bytes, but rather an envelope with access logic encoded in it.

Benefits of Hierarchically Derived (HD) API Keys

#1 No Centralized Access Control Lists - Access controls are generated client-side then verified and interpreted server-side, eliminating the need for centralized access control lists.
#2 More Secure Identity & Access Management (IAM) - By tying access to HD API keys, rather than a centralized control system, capability-based models push security to the edge, creating a more secure IAM system.
#3 Full Control Over Data Management - Key-based ownership of object data enables users to intuitively control their data as a first principle, and then delegate it as they see fit.
#4 No Risk of Data Loss or Extortion - The decentralized cloud eliminates the increasingly apparent risk of data loss/extortion due to holding data on one single centralized provider.

Supported Caveats for HD API Keys

API keys delegate access to a bearer token that can only be used in specific circumstances
through HMAC chained ‘caveats’ (i.e. restrictions on IP, time-server parameters, and third- party
auth discharges). These caveats can be extended and chained, but not overwritten.
The specific caveats supported by Tardigrade are as follows:
Specific Operations: Caveats can restrict whether an API Key can perform any of the following operations: Read, Write, Delete, List.
Bucket: Caveats can restrict whether an API Key can perform operations on one or more Buckets.
Path and Path Prefix: Caveats can restrict whether an API Key can perform operations on objects within a specific path in the object hierarchy.
Time Window: Caveats can restrict when an API Key can perform operations on objects stored on the platform, either before or after a specified date/time or between to
dates/times.

From a developer standpoint, HD API keys make it very easy to write code that granularly defines security privileges. Once baked, the rules within the HD API key can’t be changed, without reissuing the key itself.

Best-In-Class Developer Controls

As a developer platform, client-side encryption, erasure coding, and distributed storage ensure your application data is extremely secure. We don’t stop there, however, we also provide simple to use access management controls so your users can manage access to their data.

A Simple Command for Access Management: The “Access”

Access management on Tardigrade requires coordination of the two parallel constructs—encryption and authorization. Both of these constructs work together to provide a
client-side access management framework that’s secure and private, as well as extremely flexible for application developers.

When sharing access to objects, Tardigrade requires sending encryption and authorization information about an object from one client to another. The information is sent in a construct called an Access. An Access is a security envelope that contains a path, a restricted HD API
key, and an HD encryption key—everything an application needs to locate an object on the network, access that object, and decrypt it.

To make the implementation of these constructs as easy as possible for developers, the Tardigrade developer tools abstract the complexity of encoding objects for access management and encryption/decryption. A simple share command encapsulates both an encryption key and
a macaroon into an Access in the format of an encoded string that can be easily imported into an uplink client. Imported Accesses are managed client-side and may be leveraged in applications via the uplink client library.

Designed for Efficient File Sharing

While the API key is intended to be passed from an Uplink Client to a Satellite, the encryption key 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 the Access that contains both the API key and the encryption key that’s passed peer-to-peer. An application that receives an Access and imports it then passes the API key to the appropriate Satellite to obtain access to the object, , and then, as the object is downloaded, it’s decrypted client-side using the HD
encryption key.

2 Likes

Access Management at the Edge Delivers Differentiated Value

Tardigrade’s distributed cloud storage and edge-based security model provides easy tools for
building applications that are more private, more secure, and less susceptible to the range of
common attacks. With this approach, no incompetent or malicious operator can undermine
security. And unlike other cloud storage providers, Tardigrade security features are enabled by
default—at no extra cost.

Tardigrade Security Features Deliver:

● Significantly Reduced Risk of Common Attacks - Common attacks (misconfigured access control lists, leaky buckets, insider threats, honeypots, man-in-the-middle attacks, etc.) depend for their success on breaching a central repository of access controls or gaining access to a treasure trove of data. Tardigrade’s security model eliminates whole categories of typical application attack vectors.

● Reduced or Eliminated Typical Threat Surfaces - By separating trust boundaries and distributing access management and storage functions, a significant percentage of the typical application threat surfaces is either eliminated or made orders of magnitude more
complex to attack.

● Enhanced Data Privacy - With access managed peer-to-peer, the platform provides the tools to separate responsibilities for creating bearer tokens for access management from encryption for use of the data. Separation of these concerns enables decoupling storage, access management, and the use of data, ensuring greater privacy with greater transparency.

● Delegated Authorization to the Edge - Authorization delegation is decentralized and managed at the edge, but derived based on a common, transparent trust framework.
This means access tokens generated at the edge can be efficiently interpreted centrally, but without access to the underlying encrypted data. This maximizes privacy and
security at scale.

● No Added Cost for Security Features - Other cloud storage providers have a separate product and associated cost for security features. For instance, the AWS Detective
solution. Even with the additional cost, the security capabilities don’t match up to the power and control of the Tardigrade platform—which includes these capabilities
out-of-the-box.

Tardigrade is Purpose-Built for Distributed Data

Distributed data storage architecture combined with edge-based encryption and access management stores your data as if it were encrypted and stored on an encrypted beach. The combination of client-side HD Encryption keys and HD API keys in an easy-to-use platform enables application developers to leverage the capability-based security model to build applications that provide superior privacy and security

1 Like