Most examiners know they can pull an iTunes backup from an iPhone. Fewer know that an unencrypted backup is quietly hiding some of the most valuable evidence in the file.
Health data — step counts, heart rate logs, sleep patterns — is only available in encrypted backups. Keychain entries, including stored Wi-Fi passwords and app credentials, are encrypted-backup-only. Safari saved passwords: same story. If you’ve been doing civil examinations with unencrypted backups, you’ve been leaving a significant slice of the evidence set on the table.
This guide covers what encrypted backups actually contain, how to create one in a forensically sound way, and the limitations you need to communicate to counsel.
Why Apple Designed It This Way
Apple’s backup architecture separates data into protection classes. Some data — like Health records and keychain entries — is classified as highly sensitive. Apple’s design philosophy is that this data should only leave the device if the user explicitly opts into encryption.
When you create an unencrypted backup, iOS strips out everything in the sensitive protection classes before writing to disk. The backup file is technically complete — you won’t see any errors — but it silently omits the sensitive categories.
Enable encryption, set a backup password, and iOS includes those categories in the backup. The password you set encrypts the backup file on disk and is required to restore or parse it.
This matters for civil examiners because opposing parties sometimes argue they “fully cooperated” by producing an iTunes backup. If that backup was unencrypted, the cooperation was incomplete — not through bad faith necessarily, but through ignorance of what was excluded.
What Encrypted Backups Capture That Unencrypted Backups Miss
Here’s the direct comparison of what changes when encryption is enabled:
Health and Activity Data
The full HealthKit database (healthdb_secure.sqlite) is included only in encrypted backups. This contains step counts, workout sessions, heart rate measurements, sleep analysis, and data from connected health devices like Apple Watch. In personal injury litigation, wrongful termination cases involving claimed disability, and ADA compliance matters, this data is often central.
Keychain
Apple’s keychain stores passwords, encryption keys, and authentication tokens across the system and all installed apps. The keychain backup contains Wi-Fi network credentials (which can establish location history), app login credentials, and certificate data. In trade secret or unauthorized access cases, keychain artifacts can reveal which accounts were accessed from the device.
Safari Saved Passwords
Stored separately from the keychain in most analyses, Safari’s saved password database is included in encrypted backups. This can be relevant in any case involving account access.
Wi-Fi Passwords
Each Wi-Fi network the device has connected to, along with its password, is stored in the keychain. This produces a network connection history — which offices, hotels, or homes the device connected to — that can corroborate or contradict location claims.
Voicemail Audio
Visual voicemail audio files are included in encrypted backups but excluded from unencrypted ones in some iOS versions.
HomeKit Data
Smart home device configurations and usage logs. Niche, but relevant in domestic dispute cases where someone claims they weren’t home.
Creating a Forensically Sound Encrypted Backup
The process is straightforward, but the documentation around it is what makes it forensically sound. Here’s the correct procedure:
Step 1: Document the device before connection.
Photograph the device, note the iOS version, model, and any visible lock screen content. Record the time and your identity.
Step 2: Use a write-protected or forensically clean connection.
Connect the device to your examination workstation via a USB cable. If you’re concerned about write operations to the device, use a forensic USB bridge (though iOS backup creation via iTunes/Finder is effectively read-only from the device perspective).
Step 3: Open Finder (macOS Catalina and later) or iTunes (Windows/older macOS).
The device will appear under Locations in Finder’s sidebar or in the iTunes device list. If the device prompts “Trust This Computer,” document that trust prompt — it establishes that the device was in AFU state and the user (or examiner) confirmed the trust relationship.
Step 4: Enable encrypted backup.
In Finder: click the device, select “General” tab, check “Encrypt local backup.” Set a password. Use a password you will document and preserve — if you lose it, the backup is inaccessible. Record the exact password in your case notes under appropriate security.
Step 5: Create the backup.
Click “Back Up Now.” The backup process typically takes 5-30 minutes depending on device storage. Do not interrupt it.
Step 6: Hash the backup immediately.
Navigate to the backup folder: on macOS, ~/Library/Application Support/MobileSync/Backup/. On Windows, %APPDATA%Apple ComputerMobileSyncBackup. The backup will be in a folder named with the device’s UDID. Run SHA-256 on the entire backup folder. Document the hash.
Step 7: Copy to evidence storage.
Move the backup folder to your evidence storage location. Verify the hash on the destination. You now have a forensically documented copy.
Parsing Encrypted Backup Files
An encrypted backup isn’t human-readable out of the box. You need forensic tooling to decrypt and parse it. Options:
Cellebrite UFED
UFED can ingest encrypted iTunes backup files and decrypt them using the backup password you recorded. It will parse and present the data in the standard UFED interface, including the sensitive categories that were excluded from unencrypted backups.
Magnet AXIOM
AXIOM similarly supports encrypted backup ingestion. Its timeline and connection views are particularly useful for Health data analysis.
iBackupBot and similar utilities
Third-party tools like iBackupBot can browse encrypted backup contents after providing the password. These are not forensic-grade tools and should not be used for evidentiary work in litigation. Document everything with tools that produce audit logs.
Open-source: iphone-backup-decrypt
For technical examiners, Python-based tools exist to decrypt backup files and extract specific databases. Appropriate for research or when you need to examine specific artifacts. Not ideal for court-bound work without a documented methodology.
The Keychain Deep Dive: What You Can Actually Extract
The keychain data in an encrypted backup is one of its most powerful features, but it requires careful handling and honest reporting.
The keychain backup includes entries in three classes: kSecAttrAccessibleWhenUnlocked, kSecAttrAccessibleAfterFirstUnlock, and kSecAttrAccessibleAlways. Not all entries are exported to backup. Entries marked as “non-migratable” stay on the device.
What you typically find in a keychain backup:
- App-specific tokens (authentication tokens for apps that allow backup)
- Wi-Fi network credentials
- Safari form autofill data
- Some app login credentials
What you won’t find:
- Apple Pay tokens (these are hardware-bound)
- Private keys from the Secure Enclave
- Many third-party app passwords marked non-migratable
The parsed keychain data will show you that a credential existed and often the account identifier associated with it. Actually using the credentials is outside your scope as an examiner — document their existence and the associated metadata.
Legal Framework: Getting Encrypted Backup Cooperation
In civil discovery, you can request that the custodian create and produce an encrypted backup. A few practical notes:
The backup password issue. If the custodian creates the encrypted backup themselves and produces it, you need the backup password to decrypt it. Build the password production requirement into your discovery request.
Court-ordered cooperation. If the custodian is resistant, a motion to compel can order production of both the encrypted backup and the decryption password. Courts have been increasingly willing to order this, particularly when health data or credential access is material to the claims.
Self-created vs. examiner-created backups. Ideally, you create the backup yourself under a stipulated protocol. A custodian-created backup can be challenged on completeness grounds — you have no way to verify they actually enabled encryption or didn’t manipulate the device before backup.
Verify what you got. When you receive a backup from the opposing party, check the backup’s metadata. The Manifest.db file inside the backup folder records the backup creation date and the iOS version at time of backup. Cross-reference against other records to verify the backup is contemporaneous.
Limitations to Report Honestly
Encrypted backups are more comprehensive than unencrypted ones, but they’re not equivalent to a full file system extraction. Examiners need to communicate this clearly to counsel.
Deleted data is not present. The backup protocol captures current file system state — it doesn’t include SQLite free pages, unallocated space, or previously deleted records. For deleted message recovery, you need a full file system extraction (see iPhone logical vs. full file system acquisition).
Third-party apps may opt out. Apps can mark their data as excluded from backup. Signal does this. Some banking and financial apps do this. A backup absence doesn’t mean the app data doesn’t exist on the device.
iCloud data may not be in the local backup. If the device backs up primarily to iCloud and has iCloud sync enabled for apps, much of the data may reside server-side rather than in the local device backup. The local encrypted backup captures what’s local to the device. See iCloud vs. on-device evidence strategy for the full picture on cloud vs. device evidence.
Timestamps. iTunes backup timestamps reflect backup creation time, not original data creation time. Individual file and database record timestamps inside the backup reflect original creation/modification times. Don’t confuse these.
FAQ
Q: Can I create an encrypted backup if I don’t know the backup password?
If the device was previously configured to encrypt backups, you need the existing password to change it or disable it — you can’t just set a new one. This is a deliberate Apple security design. If the existing backup password is unknown, your options are limited: you can attempt to find the password in keychain data from the custodian’s computer, or you can try forensic password recovery tools. There’s no reliable way to bypass a forgotten backup encryption password.
Q: Does creating an encrypted backup modify the device?
The backup process itself is read-only from the device data perspective. However, enabling encrypted backup for the first time does write a setting to the device (it sets the backup password hash in the device configuration). Document this in your methodology. In most civil contexts this is an acceptable trade-off, but it’s something to disclose.
Q: Will the encrypted backup capture data from apps that use iCloud Drive?
Not fully. Apps that store data in iCloud Drive (rather than local device storage) won’t have that data in the local backup. The backup captures what’s on the device. iCloud Drive data requires separate preservation via Apple’s data request process or legal process directed at Apple.
Q: How do I handle the backup password in my chain of custody documentation?
Document the password in your case notes and secure it appropriately — not in the same file as the backup itself. Many examiners maintain a separate encrypted password log or use their firm’s evidence management system. The password should be producible if required by court order.
Q: What if the device shows a “backup password is required” message before I can disable encryption?
This means a backup password was previously set and you don’t know it. You cannot create a new unencrypted backup without first providing the correct existing password. Your options: find the password in the custodian’s other records, try the device passcode (some users set them the same), or acknowledge that you can only create a backup if the custodian provides the password through discovery.
