All Collections
Security White Paper
Security White Paper

How Orca's zero-knowledge encryption ensures only you and users you explicitly invite can see your sensitive information

Tomas Hurcik avatar
Written by Tomas Hurcik
Updated over a week ago

Last Updated: 2nd October 2020

Mission - The Right to Absolute Privacy

Orca believes in your right to absolute privacy. 

Orca guarantees your privacy by ensuring 

  1. all of the sensitive data you specifically use Orca to store and protect is encrypted, 

  2. all encryption and decryption of data takes place in the User’s browser,

  3. all encryption and decryption of data is only possible with knowledge of the User’s password, and

  4. the User’s password never leaves their browser unhashed.

This setup guarantees your sensitive data can only be decrypted by you and Users you explicitly invite. Neither Orca or our service providers can decrypt your sensitive information (unless you explicitly invite us to do so).

Orca and our carefully selected service providers do have access to certain information about you, but it is limited to the information we need to provide our services to you (e.g. your billing information). It does NOT include any of the sensitive information you specifically use Orca to store and protect. For an overview of the information Orca and our service providers can access, please see our Privacy Policy

Key Concepts

Orca uses 6 key concepts to ensure your privacy and security: Accounts, Vaults, Users, Groups, Encryption, and Audit Tables. 


An Account is made up of a collection of Vaults and Users.

Each Account is managed by the Admin. The Admin determines

  1. which Vaults exist within an Account and what the name of each Vault is,

  2. which Users exist and which Vaults they can access within the Account, and

  3. what privileges each User has in relation to each Vault (reader or editor).


A Vault is a collection of data that belongs to an Account (this may include contacts, assets and liabilities, files as well as the details and ownership/non-ownership connections between all of them). Each Vault is associated with one and only one Account.

An Account can have multiple Vaults. Vaults are clearly separated from one another (each Vault has its own database) and have no knowledge of one another.


Users are uniquely identified by their email address. Users are independent of Accounts and it is possible for a single User to have access to multiple Accounts. 

A User is assigned a role for every Account it can access. It can either be an Admin or a Collaborator: 

1/ Admin 

  • Can create and manage Vaults within the Account

  • Can access and edit all information within the Vaults for the Account.

  • Can grant/revoke Users access to the Vaults associated with the Account and assign Users privileges per Vault.

2/ Collaborator 

  • Invited by the Admin into the Account.

  • Either given read or edit privileges per Vault.


To efficiently and safely share/unshare information Orca uses Groups. A User can be in multiple Groups at the same time and all members of a Group have access to the same information..

There are 3 types of Groups at Account level:

  • Everyone - Group members have access to meta information about the Account (such as account name, creation date, etc.). All Users in the Account are by default members of this Group.

  • Admin - Group members have access to information about all Users within the Account (such as their email, status, access key, etc). Only the Admin is a member of this Group.

  • Vault - Group members have access to meta information about the Vault (such as Vault Name, creation date, etc)  as well as the Users with access to the Vault and their privileges. There are as many Vault groups as Vaults in the Account. A User with access to a Vault is a member of that Vault group. 

There is only one Group at Vault level: 

  • Admin Vault - Group members have access to all the data within the Vault (contacts, assets and liabilities, files as well as the details and ownership/non-ownership connections between all of them) and to the user identities that have access to the Vault. All Users with access to a Vault are automatically part of this group for the Vault. 


All sensitive information you specifically use Orca to store and protect is encrypted on the client side using AES-256 GCM encryption. The AES keys used to encrypt the data are known only to Users who have been granted access to the data by the Admin User. The sharing of the keys is done using ECDH and P-256 curve. The digital signatures used to verify authenticity of the data are calculated using ECDSA with P-256 curve and SHA-256 as a hash. 

Encrypted data sets include Account, each Vault and part of User data. Some User information, such as email, is not encrypted as it is required for Orca and our service providers to conduct our services. For more details on which data Orca can see, refer to our Privacy Policy.

Audit Tables

An Audit table is a special immutable data structure (hash tree). It is used to store transactions of User activity in a cryptographically verifiable way. The ledger allows Users to verify all activity that happens in the Vault and detect potential tampering either by other Users or malicious entities on the server side.

All Users who are part of the Vault are able to access public parts of the audit table for the purpose of validating consistency and authenticity of data but without actual access to the sensitive data in unencrypted form. 

Each auditing transaction contains 2 hashes and a signature to ensure integrity:

  • Chain hash - protects public fields which every User that has been granted access to the Vault can read (e.g. transaction id, creator and hash).

  • Data hash - protects private fields (e.g. User data) and is itself protected by chain hash.

  • Signature - ECDSA signature of the chain hash created by the User who created the transaction.

Verification and validation of transactions happens both on the server side and the User’s side:

  • Server side - validates hashes and signatures of all data before storing it in the database.

  • User side - performs the same validation of data hashes and signatures before attempting to decrypt and display it to the User.

In case any data inconsistency and/or manipulation is detected, the invalid data will be skipped and won’t be displayed to the client. The data displayed in Orca is guaranteed to be valid and verified at all times. In severe cases of detected anomalies, like when a data modification from outside is identified, the access to the Vault or Account will be temporarily blocked and the Orca team will work together with the client to restore the data from the backups. This system ensures the User is always notified immediately upon login of any potential data manipulation.

User Management


To register, a User needs to provide two pieces of information:

  • Email address - used as a username for login.

  • Password - used for login and to protect cryptographic keys.

During the User registration, the following data is generated on the User side to protect the information they will access, create and modify:

  • Unique ECDSA and ECDH key pairs are generated for every User. The ECDSA key pair allows the User to cryptographically sign all their actions on the platform and verify the identities of other Users on the platform. The ECDH key pair is used to encrypt various key material and share data with other Users.

  • A random 256 bit AES key is generated and will be used as Key Encryption Key (KEK) to encrypt the Data Encryption Keys (DEKs) as well as ECDSA and ECDH private keys.

  • The User’s password is used as a seed to derive two important keys:

  • Authentication hash (AUTH) is derived using PBKDF2 from the password with a static salt. This hash is used for authenticating Users on the backend before they can access any data.

  • Key Decryption Key (KDK) is derived using PBKDF2 from the password with a random salt. KDK will allow Users to decrypt their stored cryptographic keys and access data.

After generating the relevant key material on the User’s side the following information is sent to the backend:

  • Public keys for ECDSA and ECDH.

  • Private keys for ECDSA and ECDH encrypted with KEK.

  • KEK encrypted with KDK.

  • Authentication hash.

  • Email address.

After receiving the necessary information, the Orca backend will send an email to the provided email address with a unique link. This link is used to validate the User has access to the provided email address.


To login, the User must provide a valid email and password. 

The Authentication hash (AUTH) is derived from the password and sent to the Orca backend to authenticate the User. 

Upon successful authentication, Key Encryption Key (KEK) is sent to the User from the Orca backend. The KEK is then decrypted on the User’s device using the KDK.

Password Recovery Codes

To ensure a good balance of privacy and usability, Orca provides every User with a Recovery Code. The Recovery Code can be used to regain access to Orca in case the User forgets / loses their Password. 

The Recovery Code is generated during registration. The User is presented with the Recovery Code in the web panel and prompted to store it in a secure location (ideally in a solid password manager, or on a printed document in a physical safe). Where/how the User stores their Recovery Code is at their discretion. Storing the Recovery Code securely is ESSENTIAL. If the User forgets their Password and Recovery Code, they can no longer access Orca.

When the User first registers for Orca or changes their Password, the KEK is stored in two instances in the Orca backend (KEK and RKEK), protected by two different AES-256 keys. One is derived from the User’s primary Password (the KDK) and the second from the Recovery Code (the RKDK). The authentication component AUTH is duplicated in the same way (RAUTH - using a different PBKDF2 setup). This creates a secure mechanism that enables the User to reset the User’s Password using the Recovery Code. The Password can only be reset upon successful authentication with the Username and Recovery Code.

RAUTH hash is derived from the Recovery Code (PBKDF2) and sent to the Orca backend. If successful RKEK is returned to the web panel. 

RKDK is derived from the Recovery Code (PBKDF2 with different salt) and used to decrypt the KEK.

User selects a new primary Password (executes the password reset function) and KEK (that was sent to the web panel) is re-encrypted with the KDK derived (using PBKDF2) from the new Password set by the User.

The AUTH authentication hash (derived from the new Password) is also updated on the server.

Two-factor authentication

Two Factor Authentication (TFA) is optional. It enables Users to add another layer of protection to the login process if they desire.

The Account Admin can determine if TFA is mandatory for all Users in their Account or not. If the Account Admin does not enforce TFA, it is still possible for individual users to opt in to TFA.

To setup TFA the User must install an authentication app from the app store on their phone (example: the Google Authenticator App). Once installed and set up correctly this app will provide the User with a unique and temporary code to use when prompted upon login to Orca.

To generate TFA codes, Orca uses the Time-based One-time Password (TOTP) algorithm.

Orca generates a random “seed” for the algorithm and presents it in the form of a QR code. Once the User scans the QR code with an appropriate authenticator application, the seed, which is considered a secret, is stored on the User's mobile device. By the end of the TFA setup process, the seed is also shared with Orca’s servers and it is stored encrypted in the database.

This process enables Orca’s servers to validate the TFA codes produced by the authenticator application and ensure the User is the one logging in.

Data Sharing

Orca enables data sharing using 

  • Elliptic-Curve Diffie-Hellman (ECDH) to exchange keys between Users and 

  • Elliptic Curve Digital Signature Algorithm (ECDSA) to verify data integrity and User identity and their keys. 

Each individual User, Account and Vault has a dedicated database. This not only adds an extra level of validation during data sharing and a clear separation of responsibilities, but it also enables more efficient access removal and data deletion.

Each User has a unique key to access each database. This method allows encrypted information to be safely shared and unshared (as each of these keys has their own ECDH/ECDSA key pair), whilst still enabling every User to be uniquely identified at any moment of time. 

When the User logs into an Account, they load all the public keys from other Users in the same Vault and use them for identity validation. 

When the User shares data with another User the following steps are performed:

  1. A new DEK is generated and the data to be shared is encrypted with it.

  2. A new ephemeral ECDH key pair is generated which is used to share the AES key with the User the data is being shared with. 

  3. The shared AES key is used to encrypt the DEK so that both parties can decrypt and access the shared data.

  4. The encrypted DEK along with the public part of the ephemeral ECDH key is stored in the database and shared with the other User. Having access to these keys enables them to derive the same AES key used to encrypt DEK by using the public part of the ephemeral key and their own private key.

  5. Each transaction is signed with the ECDSA and logged in the audit table. In this way, the User have the proof of whom performed the change and that was not manipulated.

Sharing Information with new users

When a new User is invited to an Account, the Admin creates a temporary User (along with ECDH/ECDSA key pair) to bridge the gap between the point in time the new User is invited and the point in time that they accept the invitation and create their own User. These temporary keys are protected by a random Access Key which acts the same way as the User password (e.g. to derive authentication hash, decrypt KEK etc.).

This temporary key material is necessary to address the following issues:

  • to securely share data with Users who can not yet access the Account, and

  • to allow existing Vault members to share data with the recently invited User before they log in into the Account so that once they do, all previously shared data is readily available to them.

When information is shared before the User accepted the invitation, the temporary access and its keys are used to share the information.

Once the recently invited User has accepted the invitation, they will recreate their own access and generate new keys inside the Account. All actions after that will use the normal flow with the newly created keys to encrypt data for the User.

Un-sharing information with a User

When information is unshared with a User their access to the relevant group is revoked.  A new group identity is then created with a new ECDH key pair. This new key pair is shared via ECDH with all existing members of the group. From the moment the User is removed onwards, everything shared with the group will use the new key pair. Data shared prior to the User’s removal will *not* be re-encrypted. However, due to the updated access control, the User will no longer have access to this data.

Additionally, when something is unshared with a User, all the DEKs the User directly had access to are marked as “needs-to-change”. When anything marked with “needs-to-change” is modified, it will be encrypted with a new DEK and that new DEK will be shared with the Users who have access to it.

When a User is removed from a Vault or Account, they are removed from all the groups and all the keys they had access to are marked as “needs-to-change”.

Key Rotation

Each User has a User identity: a set of information used to identify them in each of the required databases, (such as the Vault or Account databases). The User has distinct a User identity in each User, Account and Vault databases.

Every User’s identity inside a Vault or Account can re-generate the ECDH, ECDSA and KEK keys. Everything shared with the Users from a certain point onwards is encrypted with the new keys e.g when the information is shared with a User. Along with the new keys, the old keys are stored (encrypted with the new keys). 

Note: Historical data is *not* re-encrypted as the blockchain is immutable. Old data will still use the old keys to decrypt them.

Functionality: Upload via Email

Upload via Email is an optional feature. The Account Admin can determine if they would like to activate this feature in any/all Vaults.

Upload via Email enables Users to send emails with attachments to a dedicated Orca email address from which the files will be automatically uploaded into a designated Vault. The goal of this feature is to save time uploading documents. If the User however prefers to upload files directly in Orca (i.e. not via email) they can, of course, do so.

When information is sent via email, it is still a long journey until it reaches Orca. It is worth highlighting that:

  • the security of the User’s email provider is not Orca's responsibility,

  • the security of the User’s email while being transferred in the Internet is not Orca's responsibility,

  • Orca, together with our service partners, is responsible to ensure the connection between Orca’s email and Orca is secured,

  • Orca has the means to see the contents of the email sent, while it is not yet processed,

  • Orca immediately deletes the emails once they are processed,

  • Orca creates a user that can upload files into the Vault, but can not access any information.

When the Upload via Email functionality is enabled in a Vault, a User is created: the Orca-Vault-User. The Orca-Vault-User only has the privilege to create certain types of information (files and related contents) in the Vault only via Email, without ever accessing it again. The Orca-Vault-User's access information is stored in the code base and it is NOT encrypted.

During the whole email journey, starting when the email leaves the User’s device and/or the User’s email service provider until it is stored in Orca, the information is NOT encrypted. Before the information arrives into Orca email account, Orca has no responsibility over its protection.

Once the email reaches the Orca email account, a secure connection (IMAP) fetches the email’s content and stores it into Orca in an encrypted format. Once the process is finalised, the email is fully deleted from the Orca's email account. If for any reason the email can not be processed, then it is immediately deleted.

Depending on the email queue, the email can be in Orca's inbox up to a maximum of 48h.

Orca's email service provider is G-Suite located in Europe. G-Suite is GDPR compliant.

Only the Users with access to the vault can send information via Email. All of the other email addresses are blacklisted.

Note: ​The Orca email account that receives the User’s emails can only be accessed in one extreme situation: when the connection to the Orca's email account was lost. To access Orca's email account, two senior officers from two different departments are required to sign off.

If this happens and any of the information might be compromised, the User is informed within 24h.

Until today, this process was never triggered. ​

Did this answer your question?