All encryption operations use libsodium’s asymmetric sealed_box primitive through the crypto_box crate. A randomness source is required for sealed boxes to generate ephemeral key pairs for sealing. See Cryptography for more details on the randomness source.
A user may be logged in multiple devices at the same time. When one of the devices syncs a new file, this file needs to be retrieved in the other devices. This cannot be done in the background because for security reasons, the is not authorized to retrieve the user’s backup, nor has any secret material for decryption. The client detects it needs to update its backup using the manifest hashes (see Backup Sync & Internal Structure). When an update is required, the client prompts the user to authenticate with a and download the updated remote backup.Importantly, whenever a client tries to sync, the backup service will help the client ensure it can only perform updates to the backup if it is operating on the latest state. This helps prevent accidental data loss.
At a point in time, it is possible a device becomes unauthorized to manage a user’s backup. This means that the device’s is no longer authorized with either or both Components. With Turnkey, this can be seen when receiving a PUBLIC_KEY_NOT_FOUND error and with the backup service when receiving an unauthorized_factor error (if the right backup_id is provided in the request). This can occur in some edge case scenarios:
The user is authenticated in multiple devices and deletes and recreates the entire backup. Other authenticated devices become unauthorized.
The user loses their .
(Future). The user explicitly removes authorization for a specific device.
The remediation path for this case is to use a to register a new . In particular, there is explicit handling in these scenarios:
When creating a backup if the backup_account_id_already_exists error is received, the client prompts the user to authenticate with a and register a new (see BF-1).
When fetching metadata if the unauthorized_factor error is received, the client prompts the user to authenticate with a and register a new . If on the other hand, a backup_does_not_exist error is received, the client knows the backup has been deleted by the user and will update its local state accordingly.
When deleting a factor if the PUBLIC_KEY_NOT_FOUND error is received from Turnkey, the client prompts the user to authenticate with a to register a new and retry their operation (see BF-7).
It’s not necessary to handle error cases on factor addition/deletion with the backup service because a /retrieve-metadata call always precedes this.
