When an iOS backup file is created, the state of the keychain depends on the user/examiner. The keychain for the iOS device is designed to protect the key files. When a backup is initiated, the keychain can be captured. The “level of security” of the keychain then falls on the user/examiner and their elected settings. If the user elects to “encrypt” the backup file using iTunes, they must set a password to access the encrypted backup file. This password is then backed up with the backup file and is available for password cracking, as shown in previous slides. This method, even though the user believes they are encrypting their data, is less secure because the keychain file containing the password is backed up and accessible.
For iOS 13+ devices, if the backup is not encrypted, the backup will NOT contain the keychain, health, native calls, safari history, and possibly Apple Maps. Backup encryption is so important! We need it to gain a full picture of the user activity.
The other option for security occurs when the user decides to create a backup without utilizing the encryption offered by Apple. When this occurs, Apple intervenes and protects the user by not allowing the backup file to capture the keychain file. This means that the backup itself is parsable by forensic tools without prompting for a password; however, the backup does not contain valid user information, as mentioned above.
In summary, the backup file is more secure if the user can set a password during the “encrypt backup file” selection that cannot be cracked by a forensic tool. However, most users select simple passcodes that are easily cracked. If a simple passcode is used, the method of not encrypting the backup file at all provides the most secure solution. iTunes now warns users of this vulnerability in their sensitive data.