↓Skip to main content

Security

Who do you trust?

Aberto’s Security Architecture #

Aberto’s Security Architecture consists of multiple parts:

  • The User’s Master Password
  • A Secret Key
  • The Master Encryption Key
  • An encryption test in the user’s keychain
  • A vault-specific key

Generating the Master Encryption Key #

Upon initial setup of Aberto, the user is asked to enter a (strong) password for the app. While there is no minimum strength required, most users will understand that they should pick a strong password as their one master password.

Additionally, Aberto generates a Salt, dubbed Secret Key. The salt is a randomly generated 128bit Symmetric Key. Users are also able to enter an existing salt if the app detects that there is a previous installation on this device. The salt is stored in the system’s keychain so that it can accessed during unlock. The user is asked to download an “Emergency Kit” PDF which contains the hexadecimal representation of the Salt Key and store it in a safe place.

Out of the user’s password and the salt, a 256 bit Master Key is constructed during the unlock procedure:

  • Algorithm: pbkdf2
  • HashAlgorithm: Hmac-SHA256
  • Rounds: 310000
  • Used Library: Apple’s Common Crypto

Every device can, in theory, have their own Master Key, unless the Password & Secret Key are shared between devices. Due to the Vault Encryption procedure, data can easily be shared between multiple devices & users.

The Encryption Test #

The Encryption Test is used to determine whether the entered password is correct. For this, a random 32 character string is generated, then encrypted with the Master Encryption Key and stored in the user’s system keychain.

Upon unlock, a Master Encryption Key is generated using the provided password & salt, and then used to decrypt the Encryption Test string. Only if the operation succeeds, the user is shown the content of the app.

The Encryption Algorithm #

Apple provides an AES GCM implementation in the CryptoKit library. This is used by Aberto to encrypt/decrypt content as needed

Vault Encryption #

In order to facilitate sharing of Vaults between devices and/or users, each vault is encrypted using a unique Vault Encryption Key. The algorithm we use is:

  1. Generate a radom, 64 character string
  2. Generate a random, 128Bit Salt
  3. Generate a Symetric Key out of the string & salt using the same algorithm used for the Master Encryption Key
  4. Convert the Key to a Hex String
  5. Encrypt the Hex String using the Master Key
  6. Embed the encrypted data into a VaultKey JSON structure
  7. Encrypt the JSON string using the Master Key
  8. Store the encrypted data in a file within the vault’s storage directory (using the User’s ID hash as filename)

The ID hash is generated by calculating a SHA512 hash of the user’s Secret Key (=Salt), but only using the first 50 characters.

Additionally, the encrypted data (step 5) is stored in the on-device Realm database. After unlock, the key is decrypted and converted back to a Symetric Key and is used by the app to decrypt/encrypt content of the Vault during runtime (after unlock).

Sharing a Vault Key #

When sharing a vault key, a BASE64 representation of the Key is provided to the user as

  • String to copy & share
  • QR Code

This is the real key and should be treated accordingly.

The receiving app encrypts & stores the Vault Key following steps 5 onwards of the above algorithm.

What is encrypted and how #

Encryption is applied to many different items at many different levels:

  1. In the sync directories:
  • ALL files, with the exception of the master vault JSON file (which contains only metadata like the name of the vault) stored in the sync directory are encrypted using either the Vault Key or the user’s Master Key
    • The Vault Key itself is stored encrypted with the Master Encryption Key
    • All other content, e.g. password files and attachments, are encrypted using the Vault Key
  1. Within the on-device Realm database, only specific fields are stored encrypted using the Vault Key:
  • Password and PIN fields (including their history)
  • all fields maked as “Text (Secret)”
  • the TOTP string fields
  • Notes

Attachments are not stored in the Realm database and are decrypted on-the-fly when the user downloads them to a chosen path.

What is NOT encrypted #

Within the on-device Realm database:

  • Titles of Credentials & Vaults
  • Text fields like Username, Bank Name etc.
  • URL and Date Fields

Those fields can be searched for and thus need to be unencrypted on device.

No data leaves the device unencrypted!

↑