<  Technical explanations

Operating principles
of PERSO and PRO vaults

You will find the details of the cryptographic algorithms used at the end of this page.

Operating principles of PERSO vaults

Local storage

PERSO vaults are designed as a file stored locally and encrypted on your device. The encryption key used is derived from your master password.

Pairing new devices

In order to get a synchronized copy of your vault on all your devices, you must pair a device where you already have your vault and the new device. It does not work like a web account where you just have to enter your email address and password.

The device from which you created your vault requests a random ID from the server and generates a random secret key. These two pieces of information are saved in the vault and will never be manipulated by the user directly.

Pairing a new device involves transferring this identifier and encryption key securely to the new device. For this transfer to be secure, information is transferred physically from one device to another (either by scanning a QR code, or by manual copying). It is therefore physically impossible for this information to be intercepted (unless being behind your back or having installed a virus on your computer but in this case you have already lost). Furthermore, the information can only be used once. The new device thus obtains an identifier and a secret key in common with the source device.

Syncing between devices

Once the ID and key are shared between the two devices, they can exchange information completely securely over any communication channel (even unsecured ones) by encrypting messages with their secret key. Each device then sends to the server, in an encrypted form, the changes it makes to the vault and conversely, retrieves the changes made by the other devices.

The advantage of this system is that the server does not know any information about you (it does not know your email address for example) and has no way of decrypting your data. If the server is compromised, the hacker does not recover any usable information. If it erases data, the app will automatically recreate it the next time it syncs from the local vault.

Data backup with a trusted contact

The downside (or strength) of this system is that if you lose all your devices, then you lose your vault. To resolve this problem, UpSignOn lets you entrust a backup of your data to one or more trusted contacts (see below).

Technically, your trusted contact will keep a small file in their vault encrypted by your master password containing your username and your secret vault key. So he cannot recover your data himself even if he tried, because he does not know your master password.

Trusted Contacts

A trusted contact is someone you know and with whom you share a secret key (obviously different from your vault’s secret key). This secret key is stored in each of your respective vaults and is initially exchanged according to the same secure principle as for device pairing.

Thanks to this common secret key, you have a secure exchange channel (end-to-end encrypted) with your trusted contacts. This exchange channel allows you to send backups or shared vaults.

Master password backup with a trusted contact

The other strength of the PERSO vault synchronization system is that the server never receives your master password or a derivative thereof. This master password is only used to decrypt your local vault.

If you forget your master password, we have no way to help you reset it. If so, that would mean we would be able to decrypt your PERSO vault, which is not desired.

To solve this problem, we have therefore designed a system for saving your master password with one or more trusted contacts. Concretely, a secret backup key (yet a different one of course) is entrusted to your designated trusted contacts. This key is used on each of your devices to encrypt your master password and store the encrypted result in a local file.

If you forget your master password, one of your trusted contacts can send your key back to you so you can decrypt your master password and then your vault. The security is based on the fact that your contact, because he knows you, is able to identify you and that your encrypted password file is only available on devices that belong to you.

Note that
  • the system for saving your data relies on the fact that only you know your master password;
  • the system for saving your master password relies on you having access to one of your devices.

Therefore, if you forget your master password and have also lost all your devices, your data will be permanently lost.

Password sharing

Sharing passwords in PERSO vaults is only possible with trusted contacts. Technically, a mini vault is created with its own ID and secret key. This information is stored in your vault and also sent to your trusted contacts who are recipients of the sharing via the secure communication channel that you have with each of your contacts (see above).

Please note, once sharing has been completed, deleting a trusted contact does not remove them as recipient of the sharing. This operation must be carried out separately.

Operating principles of PRO vaults

Cloud storage

PRO vaults are designed in the opposite logic to PERSO vaults. The server acts as a single source of truth and stores the user’s encrypted vault. Although some information is transmitted to the server for monitoring purposes, passwords and other secrets stored in the vault remain inaccessible without the user’s master password.

Each vault is also associated with an email address so that its owner can be identified by administrators.

One bank per customer

Each client organization has its own bank (PRO vault storage area) independent of other banks. These banks can even be hosted on different servers (case of self-hosting for example). Each bank is therefore associated with a different URL.

Authorization of new devices

To add a new device, the user will start by entering the URL of the bank corresponding to their company. Then he will enter his email address on which he will receive a one-time authorization code. By entering this code in the application, the user confirms their ownership of the email address in question, which allows the server to recognize the legitimacy of the device.

Technically, an asymmetric key pair is generated and stored on the device. The public part of this key is sent to the server. This key is then used at each connection to prove the identity of the device via a challenge-response protocol.

Unlocking the vault

To unlock their vault, the user will then need to enter their master password.

This master password serves here not only for data decryption, but also as a second factor for authentication with the server.

The master password is not simply sent to the server as for traditional password authentication. It is used as part of a challenge-response protocol so that it is never sent to the server.

Device synchronization

In this system, there is no real sense in talking about synchronization between devices as with PERSO vaults. Indeed, each time the vault is opened, after authentication of the device and the user, the entire encrypted vault is retrieved from the server.

When the user makes changes to their vault, the entire vault is re-encrypted and then sent to the server for storage. (NB, modifying the vault simultaneously on two devices is perfectly managed by the application).

Offline mode

When the user does not have access to the internet, he can consult the contents of his vault via a local copy of his data (which must still be decrypted with the master password) but not cannot make changes to their vault.

This functionality can be deactivated in the supervision console settings by the administrator.

Transparent data backup for the user

This design means that even if all their devices are lost, a user can recover their vault simply by authorizing a new device and retrieving their vault from the server. As with PERSO vaults, this nevertheless assumes that the user has not forgotten their master password.

No concept of trusted contact

PRO vaults do not offer the concept of trusted contact because it is not useful. The backup and sharing features are managed differently, which makes them simpler.

Automatic master password backup to server

The master password reset function works in a fairly traditional way by sending an email.

Each device generates and locally stores an asymmetric key pair dedicated to the forgotten password functionality. The private key is stored on the device only, while the public key is saved in the vault.

When the user changes their master password, it is encrypted by the public keys of all authorized devices and the results are sent to the server for storage.

If the master password is forgotten, the user requests the sending of a one-time code by email. This code allows the server to temporarily authenticate it and allow the encrypted backup of the master password to be sent to the application. The application can then decrypt this backup with its locally stored private key to recover the user’s master password and ask them to choose a new one.

If your phone is hacked, the thief could try to use the forgotten password function and check your emails which are often synchronized on your phone. To counter this attack, sending the reset email is by default subject to manual validation by an administrator.

Note that, as with PERSO vaults, since the backup system for your master password relies on you having access to one of your authorized devices, the same constraint applies: if you forget your master password and you have also lost all your devices, your data will be permanently lost.

Password sharing

In the case of PRO vaults, to make password sharing more fluid and more suitable for large teams, we do not use the concept of trusted contacts (see PERSO vaults). In the application, all you have to do is enter the email addresses of colleagues with whom you want to share secrets.

Technically, each PRO vault is associated with an asymmetric key pair dedicated to sharing: the secret key is kept secure in the vault, while the public key is stored by the server.

When sharing, a mini vault is created with its own identifier and secret key. This secret key is encrypted by the public key of each sharing recipient and then the results are sent to the server for storage.

To display the contents of a shared vault, the application retrieves the encrypted secret key from the server, decrypts it with the user’s private sharing key (retrieved from the user’s main vault), and finally uses it to decrypt the contents of the shared vault.

Details of the cryptographic algorithms used

Library used: libsodium

  • Password derivation: ARGON2ID
    • derivation of PRO and PERSO master password
  • Authenticated symmetric encryption: libsodium secret box (XSalsa20 + Poly1305 MAC)
    • encryption of PRO and PERSO vaults after derivation of the master password
    • encryption of PRO and PERSO shared vaults
    • zero-trust PERSO synchronization
    • zero-trust data exchange (end-to-end encrypted) between PERSO trusted contacts
    • encryption of PERSO data backups after derivation of the master password
    • encryption of PERSO master password backups
  • Asymmetric encryption: libsodium sealed box (X25519 + XSalsa20-Poly1305)
    • encryption of PRO shared vault secret keys
    • PRO master password backup
  • Signature: Ed25519
    • strong PRO device authentication
  • Challenge authentication: HMAC-SHA-256
    • PRO master password authentication by challenge-response (so that the master password is verified without ever being sent to the server)
<  Technical explanations