đEncryption protocol
Coretex 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 Coretex servers. This is achieved by using multiple military-grade encryption techniques and SOTA (state-of-the-art) algorithms for encryption.
To fully show the power of User-Owned AI on Coretex we will go through multiple steps on how to make sure that everything is safely encrypted:
Setting up the Master key which will be used for encryption
Creating encrypted Project
Using Coretex Secrets to store sensitive data
Authorizing Node to access encrypting data by using end-to-end encryption
This is a technical documentation about how Coretex implements encryption protocols. If you need a documentation about using the Coretex encryption features visit this page.
Setting up the Master key
Master key is used for encryption of everything on Coretex. User generates a Master key by entering a secret (password) which is used as a seed to derive a RSA key-pair. The RSA key length currently supported by Coretex 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 Coretex server as well as a randomly generated 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.
Using Coretex Secrets to store sensitive data
There are multiple types of secrets supported by Coretex:
Credentials (ex. database, accounts, etc...)
AWS (ex. s3 access token)
Git (access token)
Leaking any of the data stored in Coretex Secrets can have catastrophic consequences. To securely store that data on Coretex an encryption is performed using user's public 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.
The encryption is performed client-side not server-side. This means that the unencrypted data never leaves the user's machine.
Secure data storage in Coretex
Coretex is built as a Project-centric platform, meaning that everything that gets uploaded is stored inside an Project. If you want to encrypt everything before uploading it to Coretex all you need to do is enable encryption when creating a Project.
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.
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.
Collaborating on an encrypted Project is as simple as collaborating on a standard Project. When adding a member to 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. 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.
If a user with whom Project is being shared did not initialize their Master key at least once you will not be able to add them as a member to an encrypted Project.
Authorizing Node to acces your encrypted data
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 an RSA key-pair for Node. Derived public key is sent to Coretex to be used for Node authorization operations. This is identical to the Master Key flow for user.
If a Node has a public key associated with it user can authorize that Node to access the 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.
All of this applies to authorizing Node to access Coretex Secrets as well, the flow is identical, but instead of authorizing the Node to access the Project encryption key, Node is being authorized to access contents of the Secret.
Only trusted Nodes should be authorized to access sensitive data.
All of the encryption code is publicly available inside of Coretex Python library. You can check out the cryptography module here for more details regarding the implementation.
Last updated
