Back That Data Up
Security design
Describes version 1.2. Updated: September 13, 2026
Status, stated plainly. Back That Data Up has not had an independent third-party security audit. It has had internal security reviews (four passes between June and August 2026) whose findings were tracked and fixed; the code references those reviews in its own comments. We will not call that an audit. This page exists so that anyone who wants to evaluate the design can do so without taking our word for it. If you find a problem, security.txt says how to reach us.
1. Principles
- No cryptography written in house. Every primitive comes from Apple frameworks: CryptoKit for ChaCha20-Poly1305, HKDF, X25519, ML-KEM-768 and the X-Wing combiner; CommonCrypto for PBKDF2; the Secure Enclave and AuthenticationServices for hardware-backed unlock.
- Keys never leave your Mac. We operate no storage servers and hold no keys. Backups go to drives you own and cloud accounts you already have.
- Fail loud. When something cannot be done safely (a snapshot is not possible, a cloud copy fails verification, a file cannot be read), the app records it and tells you rather than silently continuing.
- Independent snapshots. Local snapshots are plain files with unchanged files hardlinked between them. There is no chain that can corrupt. Losing one snapshot does not affect the others.
2. Key hierarchy
One master key, a random 256-bit secret, is generated on your Mac during onboarding. It is never written to disk in plaintext. In memory it lives in a locked allocation that cannot be paged to swap and is scrubbed when released.
Every feature that needs a key derives its own from the master with HKDF-SHA256 under a distinct label (local destination encryption and Cloud Vault encryption get different subkeys from the same master). Compromise of one subkey does not reveal another.
The master key is stored only in wrapped form in the macOS data-protection Keychain, once per enabled unlock method. Any wrapped copy is useless without the factor that wrapped it.
3. Unlock methods
| Method | How it wraps the master key | Role |
|---|---|---|
| Touch ID | Secure Enclave key agreement (ECDH) plus HKDF. The private key never leaves the Secure Enclave. | Primary |
| Passkey or FIDO2 key with PRF | WebAuthn PRF extension output feeds the wrapping key. | Primary |
| Passphrase | PBKDF2-HMAC-SHA512, 3,000,000 iterations, random salt, 256-bit output. Minimum passphrase length enforced. Envelopes created with older parameters upgrade the next time you unlock. | Primary |
| Hardware security key (YubiKey, SoloKey, Titan, and others) | Signature-only WebAuthn assertion, verified at the crypto envelope rather than at a login screen. | Second factor |
| TOTP authenticator app | Standard time-based code. | Second factor |
| Recovery key | Printed once at setup. Derives a wrapping key directly with PBKDF2-HMAC-SHA512 at 3,000,000 iterations. | Single-factor escape, by design |
You can enroll several primary methods; any one opens the vault. When a second factor is enabled, the master key is split so that no primary method alone can reconstruct it: both the primary and the second factor are required. The recovery key intentionally bypasses the second factor, because its job is to get you back in when everything else is lost. Guard it accordingly.
4. Cloud Vault: what is uploaded
Each file version becomes one opaque blob. Nothing about the file is uploaded in the clear.
| Layer | Detail |
|---|---|
| Cipher | ChaCha20-Poly1305 AEAD with a 256-bit key. Stored blob is nonce (12 bytes) ‖ ciphertext ‖ tag (16 bytes). |
| Associated data | The AEAD is bound to the file's logical ID and a stable per-version UUID (btdu.vault.v1|fileId|versionId). A blob copied from the cloud cannot be replayed as a different file or a different version; decryption fails. |
| Container (inside the encryption) | Magic BTDUCV02, compression flag, original size, body length, body, then zero padding to a size bucket. Because the header and padding are inside the AEAD, they cannot be read, stripped, or altered from the cloud side. |
| Compression | Optional LZFSE, applied before encryption. |
| Size padding | Blobs under 4 KiB pad to 4 KiB. Larger blobs round up to a multiple of max(4 KiB, 2⌊log₂ n⌋ / 16), at most 6.25% overhead. A cloud observer sees a small set of size classes instead of exact byte counts, so a known document cannot be identified by its length. |
5. Post-quantum upload keys
Each vault has an upload keypair using X-Wing, the hybrid of X25519 and ML-KEM-768 (the NIST post-quantum standard, FIPS 203), as implemented in Apple CryptoKit. New uploads are sealed to the vault's public key. This has two consequences: uploads can continue while the vault is locked, because encrypting needs only the public key; and material captured from the cloud today stays protected against a future quantum computer, because the classical and post-quantum layers must both be broken. Decryption requires the private key, which is available only after unlock.
6. Integrity and verified restores
- A SHA-256 fingerprint of every file is recorded at upload. Before a restore writes anything to disk, the decrypted content is checked against that fingerprint. A cloud copy that has been altered is refused, not restored.
- The vault index (the list of what is protected) and the activity log are encrypted at rest. A provider looking at your vault sees opaque blobs, not a file listing.
- Self-healing: if the app's folder is deleted or damaged in your cloud storage, the app notices, re-encrypts and re-uploads from your local files, and tells you what it did. It never prunes history on a failed check.
- Local backups can optionally byte-compare every copied file against the original after each run.
7. Recovery from a dead Mac
Every cloud blob is bound to identifiers that live in the index, and every unlock envelope lives in the Keychain, so a dead Mac would normally strand the vault. To prevent that, the app publishes one additional encrypted object per cloud backend at a fixed path: the recovery bundle (magic BTDURB01). It contains the vault index, the master key, and the upload keypair seed, sealed under a key derived directly from your recovery key with PBKDF2-HMAC-SHA512 at 3,000,000 iterations and a random 16-byte salt. Recovery therefore needs exactly two things: access to the cloud account, and the recovery key. Nothing from the old machine.
Optionally, and off by default, the derived bundle key can also be stored in iCloud Keychain (Apple's end-to-end encrypted sync) so a new Mac signed into the same Apple ID can recover without typing the key. That is an availability-versus-security trade you make explicitly in Settings.
8. Local destinations
Local snapshots are plain files, so they need no software to read. Encryption for a local destination is therefore done at the volume level, not per file: the app can set up the destination as an APFS-encrypted volume whose key is wrapped by the Secure Enclave with Touch ID, by a FIDO2 hardware key, or by a passphrase (escrowed with PBKDF2-HMAC-SHA512 at 1,500,000 iterations). If you choose no encryption for a local drive, the files on it are readable by anyone who has the drive. The app says so when you choose that option.
9. Crash-consistent snapshots
Before each backup the app freezes the source in an APFS snapshot and copies from the frozen view, so a file edited mid-backup can never land half old and half new. This uses an entitlement Apple grants to individual apps on request. The rules Apple attached are enforced in code: snapshots are never created on system-role volumes, every snapshot carries a reverse-DNS name attributable to this app, and the app never deletes a snapshot it did not create. When a snapshot is not possible, the run says so in the activity log instead of quietly copying live files.
10. Privileged helper
Work that needs elevated rights runs in a separate helper registered through Apple's SMAppService. The app checks the helper's code-signing designated requirement at runtime before trusting it, and repairs its own helper installation at launch if it has drifted.
11. Ransomware and anomaly detection
The engine watches the file change stream for the uniform, rapid rewrite pattern that mass encryption or mass deletion produces. When it fires, backups pause so clean snapshots are not overwritten by poisoned data. This is a heuristic, not a guarantee; its purpose is to buy time before a ransom note appears.
12. What your cloud provider can see
Honest accounting of metadata that encryption does not hide:
- That you use Back That Data Up (the folder name and blob naming scheme).
- The number of blobs, their bucketed sizes, and when uploads happen.
- The recovery bundle's existence and its size.
Not visible: file names, folder structure, contents, exact sizes, or which blob belongs to which file.
13. Threat model
Designed to protect against
- A cloud provider, or anyone who obtains your cloud data, reading your files.
- Fingerprinting files by size.
- Substituting or replaying blobs, or tampering with a cloud copy.
- Harvest-now-decrypt-later attacks by a future quantum computer.
- Theft of a Mac or a drive while the vault is locked.
- Ransomware silently overwriting good backups.
- Loss of the Mac, given the recovery key.
Not designed to protect against
- Malware running on your Mac while the vault is unlocked. Anything with your session can read what you can read.
- Anyone who has your passphrase, your recovery key, or an enrolled hardware key together with its PIN.
- A weak passphrase. Three million PBKDF2 iterations slow an attacker; they do not rescue a short passphrase.
- Losing every enrolled unlock method and the recovery key. In that case the data is gone. We cannot recover it, by design.
- An unencrypted local drive in someone else's hands.
- The metadata listed in section 12.
14. Licensing and network
License activation sends your license key and a one-way hashed device identifier (not your device name or serial) to our licensing service, and periodically re-validates. Standard server logs (IP address) are retained briefly. Nothing about your files, destinations, or backup activity is sent. Updates are delivered through Sparkle, the one third-party dependency in the app. Everything else is Apple frameworks.
15. Disclosure
Vulnerabilities: security@backthatdataup.app, details in security.txt. We aim to acknowledge within three business days. Security-relevant changes are recorded in the release notes.