Background

Space and Time provides a few ways for users to secure their data in the platform. At its most basic form, data is secured via encryption (data scrambling). Beyond simple encryption, our solution includes our decentralized authorization solution for fine-grained access control via biscuits. For more details on biscuit authorization, please see the relevant documentation.

Security Models

Security models determine how a database resource (table, view, etc.) is secured within the platform. As part of configuring a new resource, users must select one of the available security models to define how the platform and the wider community may interact with it. By limiting the scope of a security model to a single resource, users are given the freedom to share and/or secure their data as they see fit. An overview of each available security model is presented below:

• Public - data unencrypted, limited to no access control
• Permissioned - data unencrypted, full access control
• Encrypted - data encrypted, full access control

Regardless of security model, you will always need to provide a biscuit public key when creating your table via the public_key parameter:

CREATE TABLE MY_SCHEMA.MY_TABLE(
    id    int,
    name  varchar,
    PRIMARY KEY (id)
) WITH "public_key=<biscuit_pub_key_here>";

This is because DDL operations always require biscuit authorization, so it's necessary to have a public/private key pair configured for each table.

Public tables

This model is the easiest to support at the platform level and requires the least amount of effort from the end user to enable authorization and sharing. It is ideal for datasets designed to be shared (e.g. our blockchain data). It also most easily enables the owner to monetize their data. Public table data is not encrypted and can be accessed by any authenticated user.

Public tables can be configured with one of three access levels:

• public_read - allows table queries (SELECT) by authenticated users; all other operations require authorization
• public_append - allows table queries and appends (SELECT, INSERT) by authenticated users; all other operations require authorization
• public_write - allows table queries and DML (SELECT, INSERT, UPDATE, MERGE, DELETE) by authenticated users; all other operations require authorization

To create a public table, specify the access level in the DDL CREATE command via the access_type parameter:

CREATE TABLE MY_NAMESPACE.MY_TABLE(
    id    int,
    name  varchar,
    PRIMARY KEY (id)
) WITH "access_type=public_read";

One final note about the public model: resource owners always maintain control over DDL (i.e., no user can execute a DDL statement against any resource without explicit authorization).

Permissioned tables

This model is also quite easy to support at the platform level but requires additional effort from the end user to enable authorization and sharing. Permissioned table data is also not encrypted, but it can only be accessed with explicit authorization. In this model, the data stored in clusters is still open to snooping by the operators, but its access is restricted to platform users. To enable authorization and sharing, users must create and share biscuits explicitly.

To create a permissioned table, specify the access level in the DDL CREATE command via the access_type parameter:

CREATE TABLE MY_NAMESPACE.MY_TABLE(
    id    int,
    name  varchar,
    PRIMARY KEY (id)
) WITH "access_type=permissioned";

Encrypted tables

This model requires additional effort by both the platform and the end user to support. Though it does require additional latency and computation, it does provide the strongest security guarantees. Data stored in clusters is encrypted, and encryption/decryption keys remain outside clusters, preventing operators from retrieving the decrypted data. How encrypted data is handled at the platform depends on whether or not users implement their own encryption.

User-Managed Encryption

Users are always able to implement their own encryption schemes. In this scenario, no additional platform interaction or configuration is required, and encryption can be implemented on top of the Public or Permissioned security model (since encryption lives entirely outside the platform). One important note is that users will need to handle the various intricacies involved with SQL conformance on encrypted datasets (e.g., filter clauses will not necessarily work the same). In addition, it is the user’s responsibility to guarantee that all data is encrypted before entering the platform. Sensitive data that is not encrypted can potentially be removed, but there is no guarantee that it will not be captured before that time.

Platform-Managed Encryption

If users want to have encrypted data but do not want to implement it themselves, they can rely on the SxT platform security as an optional service. For platform-managed encryption, users must first create their table via the Permissioned model and may then enable encryption on their table.

📘

We are working on front-end support for encryption configuration. Check back soon for screenshots and an updated walkthrough.

Setup

As a precursor, users should have already created their table(s) and generated appropriate biscuit(s). Using the dapp frontend, users can see the existing encryption configuration for their tables and open a page to begin configuring new tables. After opening the page, users select the table(s) which they want to add encryption, which columns in each table should be encrypted, and what type of encryption they'd like to use for each column. Specifics on column encryption schemes will be added soon.

🚧

Encryption must be set up on a table that doesn't already have encryption. Once encryption is configured, it cannot be changed or removed.

🚧

Data added to a table before encryption is set up will not be encrypted automatically.

📘

Encryption can only be configured on tables in the same namespace/schema. If you wish to support joining on an encrypted column between two tables, make sure both tables are in the same namespace.

Runtime

Once encryption has been configured on the target tables, users can now transparently encrypt their data on the way in and decrypt it on the way out. The only changes needed to standard interaction is altering the SQL API endpoints used.

• For query result decryption, use the /decrypt/dql API
• For data manipulation encryption, use the /encrypt/dml API

📘

Our data encryption/decryption is coming soon! Check back later for API specs