Last Updated: 25th May 2018

 

The right to absolute privacy

Orca believes in the right to absolute privacy.

Orca guarantees privacy by ensuring

  1. all encryption and decryption of data takes place in the User’s browser
  2. all encryption and decryption of data is only possible with knowledge of the User’s password, and
  3. the User’s password never leaves their browser.

This setup means only the User can access their data. Neither Orca, nor any 3rd party can access User data.

Key components

Username

A valid email address.

Used to:

  • Identify the User.
  • Enables the User to log-in to Orca (in combination with their Password).

Password

A strong password created and managed by the User.

Used to:

  • Enable strong protection for the end-to-end encryption.
  • Provide strong authentication for the Orca backend. 

AUTH / RAUTH

An authentication hash derived from the User’s password using a PBKDF2 (Password-Based Key Derivation Function 2) key stretching algorithm with 10.000 iterations.

These frontend and backend security measures give us very effective protection from potential brute-force password attacks mounted on the authentication hash should it be compromised during the transfer or from our infrastructure.

Because AUTH and KDK are both derived using the same algorithm and input and parameters, both use different salts. That ensures that both tokens will be different.

Note: On the server-side, the AUTH and RAUTH tokens are furthermore protected with Bcrypt password hashing function for its storage.

Used to

  • Provides the basis for authenticating vs the Orca backend. We do not use the Password for this as it would expose the KDK (defined below).
  • RAUTH serves the same purpose in password recovery process. It authenticates the user for successful initiation of password recovery process.

Recovery Code

A randomly generated code (20 alphanumeric characters). Each User is presented with a Recovery Code within the application. It is the responsibility of the User to store their Recovery Code in a secure location out-of-bounds.

Used to: Allow the User to reset their Password and regain access to Orca. 

KDK (Key Decryption Key) / RKDK (Recovery Key Decryption Key)

A AES-256 key derived from the Password using PBKDF2 (Password-Based Key Derivation Function 2) key stretching algorithm.

Because AUTH and KDK are both derived using the same algorithm and input and parameters (10.000 iterations of the algorithm), both have different salts. That assures that both of these element will be different.

RKDK is derived in the same way as KDK, but from the Recovery Code.

Used to:

  • The KDK is used to encrypt the KEK (defined below).
  • The RKDK is used to encrypt KEK using a Recovery Code, forming a RKEK.

KEK (Key Encryption Key) / RKEK (Recovery Key Encryption Key)

A AES-256 key randomly generated in the browser, as part of the registration process.

Used to:

  • Used to encrypt every DEK (defined below). The KEK is stored in the Orca backend (protected by the KDK).
  • RKEK holds the same KEK value, but is encrypted using the Recovery Code. Its purpose is to provide recovery option in case the Password is forgotten.

DEK (Data Encryption Key)

A AES-256 key randomly generated in the browser.

Used to: Encrypt confidential User data.

Entity

A unified object type used to store all data entered in Orca (i.e. Assets, Contacts, Files). The information stored in Entities is protected by end-to-end encryption.

Used to: Store and organise data in the required structure in the Orca backend.

General Principles

AES-256 encryption keys

Orca uses a 256 bit Advanced Encryption Standard (AES) encryption key as the basis for all encryption.
 

Web panel based encryption/decryption

Orca’s web panel runs client side (in the User’s web browser). The web panel only uses crypto functions and routines built into the User’s browser: the JavaScript implementation of the W3C Web Cryptography API. These crypto functions and routines undergo thorough quality assurance and security testing by the producers and community.

Asset, Contact and File data encrypted in transit and at rest

Every Entity stored on the Orca backend is protected with separate (entity based) 256 bit AES key (DEK) randomly generated when the Entity is first created in the User’s browser. The encrypted blobs of data are stored in the Orca backend in a dedicated database service. The database is not aware of the contents of any Entity. The Orca backend can only access control metadata required to define User access levels.

If an Entity stores file data, the contents of the data are stored in the dynamic cloud storage (not in the database). The file contents are encrypted (on the client side) with the DEK of the Entity associated with the file before the file is stored in the cloud storage. The same mechanics (AES-GCM) as for the Entity itself are used for encrypting the file contents.

HTTPS

Orca uses HTTPS (TLS) for all data transfers to and from the Orca backend. TLS is applied as an extra layer on top of the 256 bit AES encryption used to encrypt each Entity. This ensures that in the event that HTTPS transport security is compromised (e.g. a new TLS protocol vulnerability), the transferred data remains encrypted and can NOT be accessed by anyone other than the User.

Orca scores A+ on the Qualys SSL Server Test and configuration inspection scanner.

 

Ensuring end-to-end encryption

The following processes ensure that ONLY Users can access their data. They guarantee that neither Orca, nor any 3rd party can access User data.

 

Registration

When the User registers and sets their Password for the first time, the KDK and AUTH are derived (both have different salts).

After the KDK is derived, the KEK is generated and encrypted with the KDK. The encrypted KEK and AUTH are then sent to the Orca backend.

Orca never stores the KDK. The KDK is only ever available in the User’s browser for the time needed to encrypt/decrypt the KEK.

 

Recovery Code

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 safe). Where/how the User stores their Recovery Code is at their discretion. Storing the Recovery Code securely is ESSENTIAL.

The principle behind the Recovery Code is: 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 can be used to reset 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 authentication attempt 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 Password (executes the password reset function) and the 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.

When this flow is finished, the User is forced to log-in back to the Web panel using their newly set Password.  

 

Login

To login, the Users must provide a valid Username and Password.

The Password is used to derive the KDK and AUTH (both have different salts).

The AUTH is sent to the Orca backend to authenticate the User.

Upon successful authentication the KEK is sent to the User from the Orca backend and the KEK is then decrypted on the User’s device using the KDK.

 

Entity Storage

The decrypted KEK provides the basis for end-to-end encryption during entity storage.

The KEK is decrypted using four steps:  

  1. the Password is used to derive the KDK,
  2. the AUTH is sent to the Orca backend for authentication,
  3. the Orca backend sends the User the encrypted KEK (upon successful authentication), and
  4. the KDK (derived from the Password) is used to decrypted the KEK (sent from the Orca backend).

Every Entity the User creates is encrypted with its own unique DEK before being transferred to the Orca backend. A new DEK is generated in the web panel every time an Entity is created. The DEK itself is encrypted with the KEK.

The KEK protects all DEKs used for end-to-end encryption. The KEK is stored on the Orca backend, but is always protected with the short-lived KDK, which only ever exists in the User’s browser.

 

Entity Retrieval

The decrypted KEK provides the basis for end-to-end encryption during entity retrieval.

The KEK is decrypted using four steps:  

  1. the Password is used to derive the KDK,
  2. the AUTH is sent to the Orca backend for authentication,
  3. the Orca backend sends the User the encrypted KEK (upon successful authentication), and
  4. the KDK (derived from the Password) is used to decrypted the KEK (sent from the Orca backend).

Whenever the User queries an Entity from the Orca backend, the Entity is sent to the User’s browser as an encrypted object.

To decrypt an Entity, the User’s browser must extract an object specific DEK from the Entity. The DEK is decrypted using the KEK.

The DEK is used to decrypt the raw data within the Entity.

Using the KEK, DEKs and the KDK enables Orca to provide true end-to-end encryption (“zero-knowledge”). The fact that Orca NEVER has the Password and can therefore NEVER derive the KDK, means we can NOT access User data. Only Users can access it.

Did this answer your question?