Features
Account creation
When a user creates an account for the first time, the following steps are taken:
User provides their email address and master password.
Using the email address and master password, the Web UI leverages the PBKDF2 algorithm along with the user's email and master password to create a master key.
The master key is then stretched to 512 bits in length using HMAC Extract-and-Expand Key Derivation Function ( HKDF).
Note
The master key and stretched master key is never transferred to the Bravura Safe servers. These remain resident in the client exclusively.
The Web UI then creates a 512 bit symmetric key and initialization vector using cryptographically secure pseudorandom number generators. This key is then encrypted via AES-256 encryption using the stretched master key and initialization vector.
This encrypted symmetric key is the main data encryption key associated with the user and is transmitted to the server and stored locally. When a user logs in from a different device it is retrieved from the server and given to them.
Due to this overall approach, the master key can be viewed as a "Key encryption key". And this is also why you can quickly and efficiently change all the encrypted content inside Bravura Safe, since you're just re-encrypting the root key using a new key encryption key.
Note
You can also change the root encryption key for your material. This action involves greater cost though, since it requires a decryption and re-encryption of all material stored in your safe.
You also must log out of client applications you are logged in to, to ensure content is not placed in your safe using old encryption keys. You generally only need to change your account's encryption key in the case of a known compromise of your client application security.
As part of the account creation process, an asymmetric (RSA Key Pair) is created for the user. This encryption key is used to allow users to interact with Teams as well as other users securely. We will go through the usage of this key more when we explain how users are invited to Teams and how they decrypt the contents of a Team.
User login
When a user logs in to Bravura Safe, they are prompted for their email address and their master password. The user interface of the client the user is using (web, browser extension, mobile app, native app, CLI) will take the email and password and create the stretched master password using the PBKDF2 algorithm. Then a hash is calculated of the stretched master password. It is this hash that is transferred to the server and used to initiate the identification of the user.
When 2FA is enabled, no encrypted safe material is transferred to the user yet. Instead, they are then prompted to complete their 2FA test. The 2FA test involves submitting a PIN (email, authenticator app) to fully confirm their identity.
Once the user has passed the 2FA checks, their encrypted safe material is then transferred to the client as a single unified response. Then the process of unlocking the user's safe occurs.
Safe unlocking
The process of unlocking a user's safe involves decrypting the returned user-specific, symmetric 512-bit key using the stretched master password. Items stored individually for a person can be immediately decrypted. Items stored in Teams require additional steps to decrypt since those items are stored with Team-specific encryption keys that must first be unwrapped. The general process is as follows:
The user's client decrypts the user's private RSA key using their 512-bit symmetric key.
The user's private key is then used to decrypt the Team's 512-bit symmetric key that was encrypted with the user's RSA Public Key when they accepted the Team invitation.
The user can then use the Team-specific symmetric key to decrypt the contents of the Team.
It is the client's responsibility to encrypt and decrypt all data when needed for operations to occur.
Team membership
Team membership is done through the exchange of symmetric key material through well known public/private encryption techniques that will be explained in this section.
Team creation
When a user creates a Team, the following steps are done:
The user’s client creates a 512-bit symmetric key to be used to encrypt all the contents of the Team.
An initial default collection is created and encrypted with the 512-bit symmetric key.
The user’s client submits the Team content to the server for saving.
The user’s client also encrypts the symmetric key using the user’s public RSA key and then inserts a record into the Team membership tracking table to track that this user is the owner of the Team in question.
Note
It is this action that allows the user to be able to access the content of a Team. The user can decrypt the Team encryption key using their private RSA key that they (and only they) have access to.
Inviting new user to Team
When a user invites a new user to a Team, the following steps are done:
User A invites User B to join the Team. This triggers the addition of a record to the membership database table that tracks that User B has been invited to the Team and User B receives an email notifying them of the invite.
User B then clicks the link in the email, logs in, and accepts their access. This ensures the user has an account and that they have viable public/private RSA keys that will be used in the confirmation step. User B creates an account if they do not already have one. If the Team has master password reset enabled, the user's private encryption key is encrypted with the Team's public key and stored in escrow. User A is then notified that they need to confirm the user.
User A then logs in to Bravura Safe and confirms User B’s access. The act of confirming User B results in the following steps being taken:
User A’s client decrypts the 512-bit encryption key for the Team using User A’s private RSA key.
User A’s client then retrieves the Public RSA key for User B from the database.
User A’s client then encrypts the Team's 512-bit encryption key for the Team using User B’s public encryption key.
Now when User B logs in, they can retrieve the encryption key for the Team and decrypt it with their Private RSA key.
Item encryption
Items are stored in a naturally encrypted way. The following item details are encrypted using either the user or Team symmetric key:
Name of the item
Username
Passwords
Notes
URIs (URLs)
Password history
TOTP seeds
Attachments
All custom attributes
Team encryption
Team attributes in general are not stored encrypted in the database since this data is required for administrative use cases such as:
Observing what Teams exist within a tenant for a company as a whole
Understanding what policies are governing individual Teams
Observing who owns a Team in case administrators need to contact the owner
Administrators are able to adjust the role a user holds within a Team. This field is not encrypted and provides opportunities to promote people into an ownership position when an owner leaves a company.
However, administrators are not able to invite people to a Team. The act of inviting people requires an existing member of the Team to confirm a new user's RSA key pairs in order for that person to be able to decrypt the Team's encrypted material. Administrators do not have access to these RSA Key pairs since they are encrypted with the users private 512-bit encryption key.
Collection encryption
Collections in a Team are fully encrypted since they can contain sensitive information that does not need to be made available to the administrators of an environment. The owners and administrators of a Team can fulfill these actions for a Team.
Group encryption
Administrators are able to see the groups of a Team and to invite/remove people from groups. But administrators cannot confirm a user's access and thereby cannot adjust the scope of access to a Team.
Membership encryption
Administrators are able to see who is a member of a Team and or a group. They can also see the role held by people in the Team. This helps with administrative tasks such as identifying points of contact, promoting people to new roles, and when people leave a company.
But as stated before, administrators cannot add members to a Team, since this requires a Team owner or administrator to undertake necessary cryptographic operations to grant people access.
Admin password reset
Teams with Admin Password Reset enabled create a new RSA Public/Private key combination that is stored for the Team.
When a user joins a Team with Admin Password Reset enabled, the following actions are taken for that user:
The user's stretched encryption key is encrypted with the Team's public key.
This encrypted value is then stored in a table that holds password reset keys for a Team.
When an owner or administrator of a Team triggers an admin password reset operation, the following occurs:
The administrator’s Web UI retrieves the Team’s encrypted private key and decrypts it with the Team's symmetric key.
The target user’s reset password key is decrypted with the now decrypted Team private key.
The user’s encryption key and master password hash are replaced with a new encryption key and a new master password hash seeded from the new master password chosen by the administrator.
The target user’s new encryption key is encrypted with the Team public key and replaces the previous password reset key with the new one.
Note
At no point will anyone know of or be able to regenerate the user's original master password.
Admin Password Reset does not bypass two-step login. Users will still be prompted for 2FA checks and this helps to protect against inappropriate usage of admin password reset.
Admin Password Resets are logged and can be tracked to identify potential inappropriate usage or identify users who are struggling to work with master passwords.
Trusted Emergency Access
Trusted emergency access operates conceptually similar to Admin Password Reset. This strategy can provide a more delegated user experience for emergency scenarios where a person’s safe needs to be accessed for business continuity reasons.
Inviting someone to be your Trusted Emergency Contact
When you invite someone to be your trusted emergency contact, the following steps are taken:
User A invites User B to be their trusted emergency contact through the Bravura Safe web user interface. User B receives an invite to accept the request.
User B logs in and accepts the invitation to be User A’s trusted emergency contact.
User A is notified of User B’s acceptance. Upon acceptance, the user interface of User A encrypts their encryption key using user B’s public encryption key. This encrypted value is then stored in the Bravura Safe server in escrow.
User B is notified of User A’s acceptance.
Using Trusted Emergency Access
When you need to invoke Trusted Emergency Access (to gain access to a safe), the following steps are taken:
User B initiates a trusted emergency access request. This creates a record on the server indicating that User B has started this process. User A receives an email asking if they would like to approve or reject this access.
When User A approves the request or the request times out, User B is notified that they can now gain access.
When User B logs in, they can trigger the access of User A’s access. This involves the server providing User B’s client access to the encrypted encryption key stored in escrow. User B can then decrypt this key and do the actions described in our end user documentation to view or take over User A’s account depending on the policy chosen.
Changing your master password
When you change your master password, you are going through the same general steps for key expansion and generation as when an account is being created.
The key point of change is that your web client will first decrypt your symmetric key using your previous expanded encryption key and will re-encrypt it using the new expanded encryption key. Then this re-encrypted value is stored on the server.
Changing your email
Since your hash is salted with your email, you are — in effect — also changing your password. The series of steps is the same as Changing your master password.
Safe Share
Safe Share files and text messages are securely stored using ephemeral encryption keys. The steps are as follows:
When a share is created, a new 128-bit secret key is generated.
A 512-bit encryption key is derived from the secret key using HKDF-SHA256.
The material of the share is then encrypted with this single use 512-bit encryption key.
The encrypted material and share is then stored on the server.
The server then returns a random URL at which this share can be accessed.
Note
If a password is provided in the share, it does not factor into the encryption algorithms used to secure the data; it is only used to authenticate a user before they are allowed to gain access to the material in the share.