Security White Paper

Key Messages

1. End-to-end encryption (confidentially via cryptography)

All the Account’s sensitive data is encrypted. All cryptographic keys are generated by the Users on their devices, and all encryption is performed locally. Consequently, only Users in possession of the appropriate keys can decrypt the data. Further details can be found in “Cryptography & Key Handling”.

2. Double-encrypted in transport (confidentially in transit)

When the already encrypted Account’s data travels between the Users’ device and the ORCA servers, it is encrypted and authenticated by Transport Layer Security (TLS). Further details can be found in “Data Transport”.

3. Least privileges access (confidentially via ACL)

Only Users with the appropriate permissions can see and possess the correct keys to decrypt each part of the data. Permissions are managed via the Access Control List (ACL). Further details can be found in “Access Control”.

4. Reliable and unchangeable stored data (integrity, authentication and immutability via Cryptography and Hash Tree)

Every User’s Action leaves a trace, and its authorship can be cryptographically verified. Further details can be found in “Cryptography” under “Security Functionalities”.

5. Users are time-independent (asynchronicity)

Users can perform Actions when other Users are offline.

6. You have secrets. We do not. (zero-trust)

Only Users have access to their data. Users trust the data they read without having to trust the ORCA server. Neither ORCA nor our service providers can access the sensitive data the Users store at ORCA. Further details can be found in “Security Functionalities”.

7. Restore and recover

In case of failure, disaster or data compromise, data can almost always be restored to a certain point in time. Further details can be found in FAQ - 1. How can data be restored?

 

1. Never trust, always verify (“zero trust security model”)

In ORCA’s strategy and design, Users and devices are not trusted by default. This leads to specific implementation decisions such as strong identity verification, validating device compliance and ensuring least privilege access.

2. ORCA’s ignorance

ORCA can never see, access or infer Users’ credentials and secrets.

3. Only users share their data

No other party possesses the keys to share the data.

Additionally, the Users only share data that is not “hidden” (i.e. information not explicitly visible is not shared). Further details can be found in “Sharing data”.

4. Everyone is entitled to security

ORCA is responsible for implementing and offering the highest level of security to their clients, even when the implementation complexity is out of the clients’ knowledge.

ORCA is responsible for informing their Users of any potential security gap in clear and understandable wording (e.g. storage of their Security Key).

5. Transparency

ORCA welcomes external parties to examine our security implementation and commits ongoing efforts to make public our technological designs, together with the decisions and rationale behind the decisions taken. Additionally, any security-related compromise is communicated as soon as possible, where Users are given priority in the chain of communication.

6. Security over functionalities

ORCA does their best to prioritise data security over functionalities. When this is not fully achievable, in rare situations where the data is not protected at all times (e.g. Upload via Email), the Transparency Principle is activated.

ORCA Application

Overview

Main Concepts in ORCA

• ORCA - organisation;

• ORCA App - web application provided by ORCA;

• Account - a workspace where all the Users and data belong to;

• Users - a person identified by a verified unique email address that has access to an Account;

• Vault - subspace of collaboration between Users within one Account. An Account can have multiple Vaults;

• Account Owner - User with all the ultimate rights over one Account and that can not be removed. There is only one Account Owner per Account;

• Admin - a User who has access to all the Vaults and possesses additional rights, such as creating a Vault or inviting Users. One Account can have multiple Admins;

• Member - a User, invited to the Account by an Admin or Account Owner, with permissions to one or multiple Vaults;

• Role - a group of permissions a Member is given to each Vault by the Admin/Account Owner, which can be Edit or Read-only;

• Access Control List (ACL) - the mechanism through which the powers of a User are established. The powers are then enforced cryptographically, by the ORCA front-end or by the ORCA server;

• Cryptographic keys - secret chain of bytes, which when processed through a cryptographic algorithm can encrypt / decrypt data. See section Cryptography;

• Secret Key - a unique access key randomly generated by the User during the registration process which is never shared with anybody else. Without this key the User cannot decrypt any data from the Account. See section Cryptography;

• Action - any granular activity performed within the Account that describes what the Actor (User or ORCA) did, such as uploading a file or inviting a User. See sections Access Control list and ORCA’s Actions;

• Sensitive data - any data that is stored in the Account by its Users, such as Persons, Legal Entities, Assets and Files. A detailed description of Sensitive Data can be found in Privacy Policy;

• Operational data - data stored in the Account by its Users or ORCA that enables the ORCA App to ensure its immutability and to enforce access controls. This data is never sensitive, and examples of those are Vault ID, timestamps and Action types. A detailed description of Operational Data can be found in our Privacy Policy;

• Binaries - any File and Image uploaded into the Account. See section Data Types;

• ORCA front-end - code that runs in the User's browser. See section Connecting the dots & Security Scenarios;

• ORCA server - code that runs on ORCA App's infrastructure. See section Connecting the dots & Security Scenarios;

• ORCA Console - the first Account which is fully managed by ORCA. This Account enjoys the same security as a standard client Account, with additional functionalities such as overseeing other accounts and allowing new accounts to be created. See section ORCA’s Actions;

• Device - physical electronic equipment that is utilised by the User to access their Account via the browser;

• Trusted Device - a previously configured device where the User can access the ORCA App without inputting the Secret Key.

Security functionalities

Overview

Access Control List: User Permissions, Roles and Actions

• register (after receiving and accepting an invitation),

• log in,

• set up and manage their own two factor-authenticator,

• accept the request to change their email,

• regenerate their own Secret Key,

• manage their trusted devices (with the ability to add and remove),

• manage the data in the Vaults they were given permissions to (when they are given the Edit role to the Vault, instead of the Read-only role).

• their own data,

• the data within the Vaults they were given access to,

• the names and emails of the Users who wrote data in the Vault they have access to.

• everything that a Member is allowed to,

• the basic Account administration, which includes:
• the ability to rename the Account,
• establishing whether two-factor authorisation is mandatory for all Users.

• manage Vaults:
• ability to create, rename and (un)archive (setting the Vault into read-only mode),
• read and write data to all the Vaults within the Account, and
• manage Integrations (see section API Integration: Addepar).

• management of Users, such as:
• ability to invite and delete Members and other Admins,
• ability to give, change or revoke Members’ access to Vaults,
• upgrade permissions from Members to Admins and vice-versa,
• edit any User’s name (excluding the Account Owner’s name - see section FAQ),
• trigger the User’s email change, and
• manage Users' trusted devices.

For further details see the section Handling Access & Sharing.

 

Cryptography

1. sharing keys - asymmetric keys used to share the data between Users;

2. encryption keys - symmetric keys used by Users to encrypt/decrypt the data;

3. identity keys - asymmetric keys used to sign the transactions they write and ensure they are who they state;

4. integrity keys - symmetric keys used to confirm the integrity of the data. This does not require the data to be decrypted, and only a hash is sufficient to validate that the data is not corrupted.

1. When the Admin shares the keys with a User, then the combined user+admin key is derived (DH). When writing the data, the Admin derives the key using the Admin private key and the User’s sharing public key. When reading the data, the User derives (DH) the same key using their sharing private key and the Admin Public key.

2. When the ORCA server is writing information to the account (see section ORCA’s Actions). The ORCA server is considered a special User without access to the Account, but with its own sharing keys. Only the ORCA server knows the private key, and the ORCA front-end knows the public keys. When writing data to the Account, the ORCA server derives (DH) a key using ORCA’s private key and the Account’s public key. The Account Users when reading the data can derive (DH) the same key using the ORCA public key and Account private key.

Data structure architecture

• Transaction (node), and

• Hash Chain (one branch)

1. data - the content (body) of the Action, which consists of two distinct parts:
1. the confidential data (optional): the encrypted version of the sensitive data using one of the symmetric keys, and
2. the plain text: non-sensitive data used to ensure ALC, such as the Action type, the index of the key used, etc. This is available for the ORCA server app to read.

2. timestamp - an unsigned integer milliseconds from epoch, account -unique,

3. Account ID - the unique Account identifier where the action was performed;

4. version - an unsigned integer, used internally to identify the format of the field;

5. appVersion - the internal version of the app which generated the transaction;

6. previousHash - the hash (refer to point J.) of the immediate previous transaction;

7. creatorId - the unique ID of the User who created the transaction,

8. creatorIdentityKeyId - the ID of the Identity key used to sign the transaction. As this is stored, the keys can therefore be rotated in the future (not implemented atm);

9. signature - the cryptographic digital signature (via ECDSA) created by the User based on all of the above fields (see Flow 2);

10. hash - the cryptographic hash-based message authentication code (HMAC) of all of the above fields, using the appropriate keys of the Application Keys as the secret for its generation.

• the creator is the Account, and

• the previousHash is set to an empty value.

1. The User has access to the Vault A;

2. The User reads the ADD_VAULT_DATA hash chain attached to the correct CREATE_VAULT transaction;

3. The User creates some new data for the Vault;

4. The data is encrypted and stored inside a new ADD_VAULT_DATA transaction;

5. The new ADD_VAULT_DATA transaction is attached to the end of the hash chain.

ORCA server controls

• the latest Keys are used, such as Vault Keys;

• the parent transaction exists;

• the timestamp matches the real timestamp;

• the transaction type is allowed to be saved in that specific place of the chain;

• the transaction type is allowed to be saved by that User.

ORCA front-end controls

• Read-only mode

A User with read-only privileges will not have the options in the user interface to add, edit or modify the data. This is additionally enforced by the ORCA server.

• Hidden actions

There is a small number of actions and information that can be concealed from some Users, depending on their role. For example, whilst a User is granted access to visualise the data, the download buttons could be disabled, or the total number of Users within the Account is not displayed in the ORCA front-end.

• Invalid data

The ORCA front-end is also responsible for validating the information being read and written by the User. In every User’s logging, the ORCA front-end checks both for data integrity (for example that a new transaction was not injected in the data) and correctness (that the business logic was not bypassed).

 

Connecting the dots & Security Scenarios

1. The ORCA server is not able to read certain sensitive data within an Action;

2. The ORCA server is not able to write data to the Account that is not allowed (see section ORCA’s Actions);

3. The ORCA server is not able to write or manipulate data to the Account without the Users detecting it;

4. Only Users with permission to a Vault can read its data;

5. Users are not able to read data from a Vault and/or Account once their access is revoked (see flow “Revoke Vault Access” under section User Flows;

6. Users are not able to add a transaction on another User's behalf (no impersonation);

7. No data can be modified without Users detecting it.

• Quantum computers Depending on future technology breakthroughs, such as quantum computers, the current encryption algorithms might be broken. ORCA does their best to remain updated with the latest news on the industry, so Users can be informed accordingly.

• Impersonation Whilst no User can ever impersonate another User on their own, if the ORCA server and a certain User work together, this is possible, breaking the triangle of trust. For example, with the support of the ORCA server, an Admin could impersonate a user invited by this Admin.

• Deleting Data (Last transaction) Given a Malicious Actor gets on hold of the database, while they can not change the stored transactions or delete some transactions in the middle of the Hash Tree without being noticed, they can delete an arbitrary number of transactions in the chain as long as the transactions are at the end of the chain (not in the middle) without leaving a trace.

• Malicious User / Client From ORCA’s perspective, there is nothing that ORCA can do to prevent a malicious User that can access, modify, and share the data with third parties. Suggested mitigations to the Users: Be cautious about who you invite to the Account. If you ever face the situation of a malicious User, contact ORCA who can support you in the steps towards restoring the data to an uncorrupted state.

• Malicious actor in the possession of the User’s device When Eve is in possession of the User's device (either physically or by exploiting a browser or operating system vulnerability) while the ORCA App session is running, they can perform any action the User could. Suggested mitigations to the Users: Do not leave your device unattended and implement the appropriate mechanisms in your organisation to ensure your colleagues do the same. If you ever face the situation of a malicious Actor, contact ORCA who can support you in the steps towards restoring the data to an uncorrupted state. Observation: ORCA is nevertheless responsible for ensuring the appropriate session termination and enforcing mechanisms are in place.

• Limited re-encryption in revocation Revoking access from a Vault or an Account prevents them from accessing future data, but the keys stored are not changed for stored data. So when the User makes a copy of the data, they are able to decrypt it with their old keys. Suggested mitigations to the Users: Be cautious about who you invite to the Account.

• Malicious actor injecting code in the ORCA App When Eve successfully executes a malicious action such as hijacking ORCA’s development pipeline, changing the network configuration to serve different content or attacking a provider in ORCA’s vendors' list, she can deliver malicious front-end code to the users, and as a consequence gets a hold of the keys and/or sensitive data. Observation: ORCA follows the most up-to-date industry practices in the development of ORCA App.

• Vulnerability of server data Our data hosting provider can leak or share the stored data. However, as the sensitive data is encrypted, the consequences of such an event are significantly reduced. See more in our Privacy Policy on which data is not encrypted.

User Flows

Accessing ORCA as a User (Authentication User Flow)

1. Via the ORCA console, the ORCA team enables the email address of the Account Owner to create an Account. A transaction is written in the ORCA Console by the ORCA server;

2. The ORCA server sends an email with a validation link to the Account Owner’s email address. The validation link is valid for 15 days and contains an OTP;

3. The Account Owner clicks on the validation link from the email;

4. The Account Owner inputs the name of the Account;

5. The Secret Key is generated and displayed to the Account Owner;

6. Other initial keys i.e. Account key and Admin key are generated and saved;

7. The Account and the Account Owner are created.

1. The User initiates the login flow in the ORCA front-end, as described in Flow: Login;

2. During the login flow, the User is prompted to save the device as “trusted”. If the User agrees, the Device Key pair is generated, and the public key is stored in the ORCA server;

3. The User is prompted to define the PIN Code;

4. The Device Private Key and Access Key are stored on the device (encrypted with a Key generated based on PIN Code);

5. The Public key is stored in the ORCA server.

1. The ORCA front-end identifies that there are one or multiple devices stored;

2. The ORCA front-end prompts the User to select the Account and asks for PIN Code, to be able to decrypt stored keys;

3. The User inputs the PIN Code;

4. From the PIN Code, the symmetric key is generated (PBKDF2);

5. The ORCA front-end fetches the stored keys from on-device storage, and decrypts them;

6. The ORCA front-end makes a request to the ORCA server to initiate the session claiming possession of a certain private key;

7. The ORCA server generates a random challenge, saves it and sends it to the device;

8. The Trusted Device signs the challenge using the Identity Private Key, and sends it to the ORCA server;

9. The ORCA server validates the signature against the stored public key;

10. If validation passes, a transaction containing the other User’s secrets encrypted is sent to the ORCA front-end.

1. The User initiates the two-factor setup;

2. The ORCA front-end generates the authenticator secret and displays it to the user in a QR code form;

3. The User scans the QR code using their authenticator application;

4. The User inputs the time-based one-time password (TOTP) provided by the authentication application and submits it;

5. The ORCA front-end verifies that the code provided is valid - meaning user has successfully set up their authenticator application;

6. The authenticator secret is encrypted with the Combined Account and ORCA Sharing keys and stored in the ORCA server, so it can be read and used to verify the TOTP during the login process.

Handling Access & Sharing

1. Alice specifies Bob’s identity, by setting the email and additional information such as the name;

2. Alice generates the initial Sharing Keypair for Bob;

3. Alice generates (and signs) Bob’s Identity Keypair.

4. The Invitation Code is generated and the Invitation Key is derived;

5. The Initial Sharing Private Key and Identity Private Key are encrypted using the Invitation key;

6. The Invitation Access Key (HMAC) is derived and stored in the ORCA server;

7. The ORCA server sees Bob is invited and then generates and saves the email confirmation code (OTP);

8. An email is sent to Bob with the email confirmation code where the Account ID, Bob’s ID and the confirmation code are encoded into the registration link;

9. Alice shares the Invitation Code with Bob using a different communication channel (i.e. phone/text);

10. Bob opens the email, clicks on the registration link;

11. The ORCA front-end is launched in the browser and a request containing OTP is made to the ORCA server to access the invitation;

12. ORCA server validates the OTP, and creates a signature confirming that this email address is used by the specific user. Additionally, it generates and saves an access challenge (random 128 bits Challenge and signature are sent back together to ORCA front-end;

13. The ORCA front-end requests Bob to input the Invitation Code shared by Alice;

14. Using keys derived from the Invitation Code, Bob signs a challenge and sends it to the ORCA server. By doing so, Bob proves to the ORCA server the possession of the Invitation code, without disclosing it;

15. The ORCA server sends the invitation transaction, and Bob can decrypt it using the Invitation Key derived from the Invitation code;

16. Bob has now access to the Account!

17. Bob rotates his Sharing Keypair, so the Private Sharing Key is known only to him.

1. Alice and Bob have a shared secret (invitation code);

2. Bob confirms to the ORCA server that he has access to the email account; ORCA server generates a signature stating this fact, which can be verified by other users;

3. The Account Owner is the root of trust: the Users can always trust who invited them and the Account Owner (this is a similar approach to the root certificate authority in Public Key Infrastructure - PIK).

1. Alice specifies Bob's role in the Vault, which can be an Editor or Reader;

2. Alice updates the ACL accordingly;

3. Alice shares all Private Vault Keys with Bob.

1. Alice updates the ACL accordingly;

2. Alice generates a new Vault Key and encrypts it with the Admin Key such that all Admins can read it;

3. Alice shares that new Vault Key with all the existing Vault Members (and not with Bob);

4. Alice informs all Admins and Users with access to that Vault that Bob’s access to the Vault has been revoked.

1. Alice updates the ACL accordingly by deleting Bob;

2. Alice generates a new Account Key, new Vault Keys for the Vaults Bob had access to and in case Bob is an Admin a new Admin Key is also generated;

3. Alice shares those Keys with the relevant Users;

4. Alice informs all Users that Bob has been removed from the Account.

1. Alice selects which data is to be shared with Bob e.g. file with ID = 1, entities with ID=2 and 3 and ownership transaction with entity ID = 4;

2. The Sharing Keypair is generated, such that the private key is encrypted with a Vault Key, the public key stays in plain text, and both are then stored in the ORCA server;

3. The shared data is encrypted with a key derived from the Sharing Keypair,

4. The Private key is stringified in the URL, shared with Bob by Alice;

5. Bob accesses that URL;

6. The ORCA front-end makes a request to the ORCA server to start a session claiming the possession of the private key;

7. The ORCA server generates a random challenge, saves it and sends it back;

8. The User signs the challenge using the private key and sends it to the ORCA server;

9. The ORCA server validates the signature against the stored Public Key;

10. If validation passes, a transaction containing shared data is sent;

11. Bob decrypts the data using a symmetric key derived (DH) from the private and public keys.

1. Alice selects which data is to be shared with Bob e.g. file with ID = 1, entities with ID=2 and 3 and ownership transaction with entity ID = 4;

2. Alice defines a password (with a minimum and max length of 4 and 255 respectively), and the random PBKDF2 parameters are generated;

3. From the password, a Sharing Access Key (HMAC) is derived (PBKDF2, then HDKF);

4. The Sharing Keypair is generated. The Sharing private key and password are encrypted with a Vault Key. The Sharing public key, the password derivation parameters and the Sharing Access Key stay in plain text. Everything is stored in the ORCA server;

5. The private key is stringified in the URL, shared with Bob by Alice, Bob accesses that URL;

6. Alice shares the password with Bob outside ORCA;

7. The ORCA front-end makes a request to the ORCA server to start a session claiming the possession of the private key and password;

8. The ORCA server generates a random challenge, saves it, and sends it back together with the password derivation params;

9. The User signs the challenge two times (once by using the private key, and a second time by using the HMAC derived from the password) and sends it to the ORCA server;

10. The ORCA server validates the first signature against the stored Public Key and the second against the stored HMAC;

11. If the validation passes, a transaction containing the shared data is sent;

12. Bob decrypts the data using a symmetric key produced from a hashed key material from:
1. Symmetric key derived (DH) private key and public key, and
2. Symmetric key derived (PBKDF2) from password.

ORCA’s Actions

• Attempts before login

Whenever a user tries to log into the ORCA the information is saved - including login, trusted device access, and session renewal.

• Inactivate the Account

Via the ORCA Console, the ORCA team can manage the Accounts, such as setting an Account to inactive. Once this Action is performed, a transaction is written both in the ORCA Console and the Account with Account keys and the Users are prevented from accessing the Account.

• Deleting all data within an Account

On request by the Account Owner and/or upon the cancellation of the subscription, ORCA can delete the Account information, by deleting the appropriate chains. This process follows strict controls and it can only be triggered for Accounts that have been inactive for longer than 15 days.

• Manage the two-factor authentication setting in an Account

Via the ORCA Console, the ORCA team can de/activate the two-factor authentication from being mandatory in an Account. This does not impact the already established two-factor configurations of the Users in the Account. Once this Action is performed, a transaction is written both in the ORCA Console and the Account.

• Remove a User’s two-factor authenticator within an Account

Via the ORCA Console, the ORCA team can remove the two-factor authentication configured by a User in the Account. Once this Action is performed, a transaction is written both in the ORCA Console and the Account.

• User email confirmation During the registration process, when the invited User clicks on the registration link (see section Handling Access & Sharing) the email is confirmed. Additionally, via the ORCA Console, the ORCA team can confirm the User’s email as well. Once this Action is performed, a transaction is written both in the ORCA Console and the Account.

• Ability to de/activate available functionalities in the Vaults Via the ORCA Console, the ORCA team can establish which functionalities are available in each Vault per Account, such as Integrations, Cash Flows, Automatic Completeness Checks, etc. Once this Action is performed, a transaction is written both in the ORCA Console and the Account.

• Billing information

Whenever a transaction is written by the User in a Vault, the ORCA front-end calculates the information required for billing (such as the number of Persons within a Vault, for complete details please refer to our Privacy Policy) and stores this information. ORCA server copies that information later to the ORCA Console account.

Data Types

1. The Binary is loaded in the ORCA front-end;

2. The ORCA front-end encrypts the Binary with the appropriate Binary Key;

3. A random UUID is generated by the ORCA front-end;

4. The upload starts and the ORCA server validates if the User has access to the Vault;

5. The upload finishes and a transaction ("upload done") is saved to the chain, with the Binary’s metadata.

Addendums

Upload via Email

1. An Admin in the Vault requests the functionality to be activated;

2. Before activation, the User is prompted with a description of the potential security risks;

3. The User is prompted with a unique email address e.g. orca-vault1-aed@withorca.com.

1. The ORCA server establishes a long-living connection with the mail server via Internet Message Access Protocol (IMAP) checking for new emails every five minutes;

2. When an email arrives in the inbox, the ORCA server matches the Account ID and the Vault identifier parameters;

3. ORCA server validates whether the sender’s email address is allowed to send emails in this Vault

4. The ORCA server downloads the Files from the mail server;

5. The downloaded File is uploaded to the specific Vault, where the transaction is encrypted using the Ephemeral Key, based on Vault's latest public key;

6. The email (with all the attachments and content) is deleted;

7. All Vault Users can see the File as "Uploaded by ORCA" and the sender's email address.

• ORCA has the means to see the contents of the email sent, while it is not yet processed. ORCA immediately deletes the emails and their content once they are processed ;

• the security of the Users’ email provider is not ORCA's responsibility;

• the security of the Users’ email while being transferred in the Internet is not ORCA's responsibility;

• ORCA, together with our service partners, is responsible for ensuring the connection between ORCA’s email and ORCA is secured.

• when the User is not allowed to send emails to that Vault / dedicated email address;

• when the Vault dedicated email address does not exist;

• when the email content contains no attachments;

• unknown error for any other situation e.g. ORCA server is not available, email parsing failed, etc.

• The ORCA server (and/or its partner) performs all the possible checks against email sender impersonation i.e. SPF, DKIM and DMARC;

• By default, only Vault Users with Editor rights (including Admins) are allowed to upload Files by email. It is however possible to develop a dedicated allowed list of emails for non-Users managed by the Account Admins;

• ORCA does not investigate the contents of the uploaded files, i.e. against viruses.

API Integration: Addepar

1. The Admin chooses a Vault and initiates the integration flow;

2. The Integration ID is generated and saved with integration meta information;

3. A Challenge is created by signing the Integration ID using the User’s Identity Private Key;

4. A new browser tab is opened using the Addepar OAuth flow URL together with a pre-established ORCA state (which includes for example the accountId, the vaultId, the challenge, etc.);

5. After the User logs in into Addepar, reviews and confirms the integration all in the Addepar browser tab, Addepar calls the ORCA server with the previously passed state;

6. The ORCA server finishes the OAuth flow by retrieving a refresh token and also verifying the challenge and additional parameters;

7. The ORCA server stores the encrypted refresh token to the Vault, but using a combined key. The refresh token will later onwards be decrypted by the ORCA server to perform updates.

1. The ORCA server validates the integration is enabled;

2. The ORCA server reads the refresh token from the database and uses it to obtain an access token for the Addepar API;

3. By using the access token, the ORCA server fetches the relevant data from the Addepar API and processes it;

4. The ORCA server saves the data into a vault using a Vault Ephemeral Key.

FAQ

1. How can data be restored? There are two different approaches to restoring data in case of failure or inconsistency which are to be used in distinct scenarios:
1. data backups: occur every night and are kept for 7 days

Our backups are fully and automatically managed by our hosting provider, which has a disaster recovery plan. The backups are created within a 24h interval, therefore any data added in between will not be recovered.

2. data rollback: in case of a malicious user, there is a possibility to remove all Vault transactions saved after a certain moment in time.

2. Who can edit the username of a User? Any Admin or Account Owner can edit the username of a User, including other Admins. Only the Account Owner can edit their own username.

3. How can the User keep the Safety Kit secure? Refer to the article here.

4. Which vendors are used? For the whole list of our vendors, such as hosting or file storage, please refer to our Privacy Policy.

5. Does ORCA use encryption on transport? ORCA uses industry-standard Transport Layer Security (TLS), for any data transported from/to the ORCA server and to/from the ORCA client. The ORCA server is configured to redirect all insecure HTTP requests to HTTPS (HTTP over SSL/TLS). Some examples of usage are when:
1. Fetching ORCA client code by the browser;
2. Fetching data from ORCA server;
3. Sending data to ORCA server.
 

Changelog