# Cloud Backup

This document contains an overview of cloud backup options on iOS and our chosen solution, the SealVault iCloud Backup.

## iCloud Device Backup

When a user enables iCloud backups for their device, their local keychain and all app data including the SealVault database gets backed up as part of that. However, items stored on the local keychain can be only restored on the same device as their encryption key is tangled with the root key of the device's hardware security module.1 Since the SK-KEK is stored on the local keychain, this means a user will be only able to restore SealVault to full functionality from an iCloud device backup on the same device where it was created.

## iCloud Keychain

In order to support recovering from an iCloud device backup on other devices, we could store the SK-KEK on the iCloud Keychain.

The iCloud Keychain allows users to securely sync their passwords between Apple devices. The iCloud Keychain and the recovery process (in case a user loses all their devices) are designed to protect a user's passwords under the following conditions:2

• A user’s iCloud account is compromised.
• iCloud is compromised by an external attacker or employee.
• A third party accesses user accounts.

In order to provide these guarantees for recovery, the iCloud Keychain relies on the following mechanisms:3

• The user's device passcode.
• A cloud hardware security module (HSM) with an embedded secure remote password protocol.
• Limiting the number of passcode tries to fetch the backup key from the HSM within the HSM.

We believe these controls are sufficient to protect passwords that are typically used in conjunction with a second factor for sensitive accounts. However, for blockchain secret keys, the key compromise by itself can have disastrous effects, therefore the iCloud Keychain security controls are insufficient for Sealvault due to a combination of the following factors:

• Device passcodes often have very low entropy, e.g. repeating the same number is a common device passcode.
• Users sometimes use the same 6-digit code across services which makes the device passcode susceptible to phishing or leakage through non-Apple services.
• New vulnerabilities are routinely founds in HSMs.4
• Apple has a history of failing to properly enforce limit type security controls (to be fair other companies struggle with this as well).5
• It's unlikely that there is an undisclosed law enforcement backdoor in iCloud Keychain, but given that it's the highest value target globally, it shouldn't be discarded entirely that it exists or that it will be added in the future. And of course such a backdoor would greatly weaken defenses against crooks as well.

## SealVault iCloud Backup

When users enable iCloud backups in the SealVault app settings, they can recover their data if they lose access to her device or delete the app.10 Once we support syncing, users will be able to recover from other devices as well and iCloud backups will be only necessary to recover in case all devices are lost.

SealVault stores the cloud backup in app-specific iCloud storage in a device specific folder. New backups are created when a new asymmetric key is saved in the database. SealVault keeps at most two backups in iCloud Storage to keep the storage size low.

Why don't we store the active SQLite DB in iCloud Storage?

There are two reasons. The first is that SQLite database files shouldn't be opened from synced cloud storage as that may lead to data loss. The second is that if the user is logged out of iCloud, then the app would stop working.

### Backup Contents

The backup is a ZIP file that consists of a SQLite backup file encrypted on the device and metadata about the backup in a JSON file. The metadata is stored in plaintext, but it's authenticated with our chosen AEAD construct. The metadata consists of:

• device identifier,
• timestamp when the backup was created,
• backup scheme version,
• KDF nonce,
• encryption nonce.

The backup scheme version is org.sealvault.ios.backup.v0 initially.

The purpose of the backup password is to protect the backup if the user's iCloud Storage and Keychain are compromised. The backup password should be easy to write down on paper, but it should be strong enough that, if all other measures fail, it's impossible to decrypt the backup without the backup password on classical computers.

A 20 character long backup password using Crockford's base32 alphabet is generated with the CSPRNG on the device when the app is installed and stored on the local (device only) keychain. This is an example backup password: 8FD93-EYWZR-GB7HX-QAVNS.

The backup password has 100-bit entropy, and it is autogenerated to ensure this level of entropy. 100-bit entropy is a good balance between not being too annoying to write down and having a wide margin of safety in case an unforeseen vulnerability is discovered in the password-based KDF.

#### Base32

The backup password uses the base32 alphabet instead of a word-based scheme that would be easier to write down with integrity due to phishing concerns. Blockchain users are conditioned to enter seed phrases into applications and if a user confused a word-based backup password with a seed phrase, they could be easily tricked into entering it in a malicious application.

Among non-word-based encoding schemes, Crockford's base32 alphabet finds the best balance between being easy to write down with integrity while producing high entropy passwords with relatively short length. When decoding the user input, we use Crockford's decoding scheme that doesn't differentiate between upper and lower case and maps ambiguous characters that are not part of the alphabet to their counterpart that is in the alphabet (e.g. the letter O is mapped to the number 0).

The user is advised to write the backup password down on paper and store it in a secure location, or if that's not feasible, to store it in a password manager like 1Password or Bitwarden.

The user can view and copy the backup password any time in the application settings on the device after biometric authentication in order to

1. Let them store it securely at their convenience, instead of forcing them to confirm it when they enable the feature as it's unlikely that they are in a position to store it securely at that time.
2. Let them verify that the password that they stored is the correct backup password (especially important since we support password rotation).

Viewing and copying the backup password opens up side-channel attacks on the password, but since the password is just one factor among the backup defenses, we believe that the above considerations trump side-channel concerns.

### KDF Secret

A 256-bit KDF secret (KDF-S) is generated on the device with the CSPRNG and stored on the user's iCloud Keychain. The KDF-S is transparent to the user.

The KDF-S serves as a defense-in-depth measure against lax treatment of the backup password as iCloud Keychain items have stronger protection than iCloud Storage items. For example, if a user stores the backup password in the Notes app and iCloud Storage is compromised (but not the iCloud Keychain), then the KDF-S keeps the user safe.

### Backup Encryption Keys

There are two 256-bit backup encryption keys:

• The database backup encryption key (DB-BK).
• The secret key backup key (SK-BK) which can be used to decrypt SK-DEK that is stored encrypted inside the database.

### Key Derivation Functions

Argon2id is used to derive the root backup key (ROOT-BK) from the backup password and the KDF-S. BLAKE3 is used to derive DB-BK and SK-BK from the ROOT-BK with unique static context strings.

The backup password and the DB-BK are stored in the local iOS keychain (not iCloud Keychain). The backup password is stored so that we can display it to the user and derive other keys in the future if necessary. The DB-BK is stored to avoid having to recompute the expensive Argon2id function for every backup.

Users may choose to rotate their backup password any time by generating a new one on the device. When a new backup password is generated, a new KDF-S is generated first transparently to the user. The old KDF-S is deleted. Then a new backup is generated, encrypted with the new keys and uploaded to iCloud Storage. Backups created with the keys derived from the old backup password are deleted from iCloud Storage.

While the old backups are deleted from the application's perspective, we cannot guarantee that all copies are deleted by the cloud storage provider. The KDF-S serves as a defense in-depth measure here as well, since it's less likely that both the deleted KDF-S and the corresponding deleted encrypted backup are preserved than just the encrypted backup being preserved.

### Recovery

#### Reinstalling

Info

As noted above, SealVault cannot be recovered from iCloud Device Backups.

When reinstalling the SealVault app on the same device, the application automatically recovers from last SealVault iCloud Backup that was created on the device if it exists. This is possible, because local keychain items are not deleted on iOS when the user uninstalls the app. After reinstalling, the app continues to make cloud backups with the same backup password that was previously used on the device.

#### New device

When installing the SealVault app on a new iOS device, users may choose to recover from a backup if there are any. The user has to enter their recovery phrase via the device keyboard. Users may choose which device to recover if there are backups available from more than one device. Once recovered, the old backup password is discarded and the user is prompted to create a new one if they wish to store cloud backups of the data on the new device.

### Post-Quantum Security

It seems likely that quantum computers will be built in the future that can brute force an N-bit key space of a symmetric encryption algorithm in $$O(2^{0.5N})$$ time using Grover's algorithm. For this reason it is recommended to switch from 128-bit to 256-bit symmetric encryption algorithms to render such attacks unfeasible due to $$2^{128}$$ theoretical time cost.6

Our chosen AEAD construct has 256-bit keys, but the backup password has only 100-bit entropy. Does this make our cloud backups vulnerable to quantum attacks?

We think not, because in order to make use of Grover's algorithm, the target function has to be implemented in a quantum circuit. Since the backup keys are derived with KDFs, in order to attack backup passwords, the memory-hard Argon2id KDF, the BLAKE3 KDF and the XChaCha20 cipher have to be implemented in a single quantum circuit.7 If such a complex circuit can be designed at all, it's unlikely that currently envisioned quantum computers would have the capacity to execute it. And even if they do, it's unclear whether the theoretical asymptotic speed up would result in more cost-efficient attacks than those with classical computers due to a high constant factor.8

#### What if We Are Wrong?

Long before attacking our 100-bit entropy backup passwords with Grover's algorithm could become feasible, quantum computers running Shor's algorithm would break elliptic curve signatures used by all blockchains today. This will necessitate a blockchain keypair migration in SealVault. At that point we will have a much better understanding of quantum computers' capabilities and we can reassess our choice of 100-bit entropy backup passwords and migrate to a stronger solution if necessary.

This leaves open the possibility that,

1. if we are wrong in our current confidence about the post-quantum security provided by the Argon2, AND
2. an attacker with unexpected quantum capabilities gains access to legacy cloud backups that are somehow preserved in spite of deleting them,

some user's dapp usage metadata9 could become compromised decades from now. We think this is an acceptable risk.

1. See Anderson, Security Engineering, 3rd ed. Chapter 18.3 for a history of HSM attacks or CryptoSense Blog: How Ledger Hacked an HSM, June 2019 for a recent high profile example.

2. Public limit bypass vulnerabilities at Apple from the past decade:

3. A potential weakness of our choice of KDFs and AEAD is that they're all built on the ChaCha permutation, and it's possible that this could be exploited in the design of a quantum circuit targeting our backup scheme. We've considered switching one of the components to a construct that isn't built on the ChaCha permutation, but decided against it as any cleverness in this regard is more likely to introduce vulnerabilities than solve the extremely unlikely and low impact quantum problem.

4. Remember, the blockchain key pairs would be long broken at this point by Shor's algorithm. See what we store in the data section.

5. Implementation is WIP.