User Owned AI supports User-owned AI through multiple layers of end-to-end encryption which guarantees that no one except the user can read that data - not even the ones with access to servers. This is achieved by using multiple military-grade encryption techniques and SOTA (state-of-the-art) algorithms for encryption.

Master Key

A first step to User-owned AI on is to generate an RSA key-pair for user. This key is generated using a secret (Master Key) which is provided by the user. Once the user has entered the Master Key an RSA key-pair is derived from the provided value. The RSA key length currently supported by is 2048 bits.

User-specified key sizes (2048, 4096, 8192, etc...) coming soon.

If it is the first time the key-pair gets generated then the public key gets uploaded to server as well as a value which is signed by user's private key. That signature is used to verify that the correct key-pair is generated next time the user enters their secret.

To make sure that the private key cannot be reverse engineered based on the signature PKCS#1v15 padding is used.

Coretex Secrets

Coretex Secrets are used to store sensitive data like:

  • Git access token

  • AWS secret

  • Credentials (username and password)

  • etc...

Leaking any of the data stored in Coretex Secrets can have catastrophic consequences. To securly store that data on server an encryption is performed using user's public key derived from Master Key. This way even if someone was to gain access to that data; it is encrypted and cannot be decrypted without access to user's Master key, whose contents are only know by the user.

Secure data storage in

When creating a Coretex Project it is possible to enable encryption for it. Enabling encryption for a Project means that everything inside of that Project will first be encrypted on the client side and only then uploaded to Server.

Project data is encrypted using AES with a key length of 256 bits. AES key is randomly generated when creating a encrypted Project and it is stored in Coretex Secrets encrypted using user's public key derived from Master Key.

Collaborating on an encrypted Project is as simple as collaborating on a standard Project. The only thing that needs to be done is to share your Project with a teammate. When sharing an encrypted Project the key for encrypting that Project needs to be shared with the teammate as well. This is done automatically by leveraging the asymmteric encryption key exchange.

Coretex Secret which contains the key for encrypting Projects is retreived and decrypted using the user's private key derived from Master Key. Public key of the teammate with whom Project is being shared is retreived as well and that key is used to encrypt the Project encryption key and submit that as the Coretex Secret of the teammate.

Project data which is encrypted before being uploaded to includes:

  • Datasets

  • Models

  • Tasks

  • Artifacts

  • Runs

  • etc...

AES is used in CBC (Cipher Block Chaining) mode meaning that a random IV (Initialization Vector) is generated for every single encryption operation to make the resulting ciphertext fully random even if the same data was encrypted multiple times.

Node Authorization

Before a Coretex Node can executa a Workflow started from inside an encrypted Project, that Node must first be authorized to access that data by a user who has access to that data. This flow is almost identical to sharing an encrypted Project with another user (collaborator).

When a Node is configured user can optionally input a secret which is used to derive RSA key-pair for Node. Derived public key is uploaded to server to be used for Node authorization operations. This is identical to generating a Master Key for user, but it is generated for Node instead.

If a Node has a public key associated with it user can authorize that Node to access data contained inside an encrypted Project. This is done by sharing the Project encryption key with Node by using RSA keys to perform key exchange between the user and the Node.

Only trusted Nodes should be authorized to access sensitive data.

Last updated