Sorry, folks, while experts are saying the encryption checks out in WhatsApp, it looks like the latest version of the app tested leaves forensic trace of all of your chats, even after you’ve deleted, cleared, or archived them… even if you “Clear All Chats”. In fact, the only way to get rid of them appears to be to delete the app entirely.
To test, I installed the app and started a few different threads. I then archived some, cleared, some, and deleted some threads. I made a second backup after running the “Clear All Chats” function in WhatsApp. None of these deletion or archival options made any difference in how deleted records were preserved. In all cases, the deleted SQLite records remained intact in the database.
Just to be clear, WhatsApp is deleting the record (they don’t appear to be trying to intentionally preserve data), however the record itself is not being purged or erased from the database, leaving a forensic artifact that can be recovered and reconstructed back into its original form.
A Common Problem
Forensic trace is common among any application that uses SQLite, because SQLite by default does not vacuum databases on iOS (likely in an effort to prevent wear). When a record is deleted, it is simply added to a “free list”, but free records do not get overwritten until later on when the database needs the extra storage (usually after many more records are created). If you delete large chunks of messages at once, this causes large chunks of records to end up on this “free list”, and ultimately takes even longer for data to be overwritten by new data. There is no guarantee the data will be overwritten by the next set of messages. In other apps, I’ve often seen artifacts remain in the database for months.
The core issue here is that ephemeral communication is not ephemeral on disk. This is a problem that Apple has struggled with as well, which I’ve explained and made design recommendations recently in this blog post.
Apple’s iMessage has this problem and it’s just as bad, if not worse. Your SMS.db is stored in an iCloud backup, but copies of it also exist on your iPad, your desktop, and anywhere else you receive iMessages. Deleted content also suffers the same fate.
The way to measure “better” in this case is by the level of forensics trace an application leaves. Signal leaves virtually nothing, so there’s nothing to worry about. No messy cleanup. Wickr takes advantage of Apple’s CoreData and encrypts their database using keys stored in the keychain (much more secure). Other apps would do well to respect the size of the forensic footprint they’re leaving.
Copied to Backups
Simply preserving deleted data on a secure device is not usually a significant issue, but when that data comes off the device as freely as WhatsApp’s database does, it poses a rather serious risk to privacy. Unfortunately, that’s what’s happening here and why this is something users should be aware of.
The WhatsApp chat database gets copied over from the iPhone during a backup, which means it will show up in your iCloud backup and in a desktop backup. Fortunately, desktop backups can be encrypted by enabling the “Encrypt Backups” option in iTunes. Unfortunately, iCloud backups do not honor this encryption, leaving your WhatsApp database subject to law enforcement warrants.
Turning off iCloud and using encrypted backups for your desktop doesn’t necessarily mean you’re out of the woods. If you used a weak password that can be cracked by popular forensics tools, such as Elcomsoft’s suite of tools, the backup could be decrypted. Other tools can be used to attack your desktop keychain, where many users store their backup password.
What does this mean?
Law enforcement can potentially issue a warrant with Apple to obtain your deleted WhatsApp chat logs, which may include deleted messages. None of your iCloud backup content will be encrypted with your backup password (that’s on Apple, not WhatsApp).
NOTE: This is “iCloud backup” I’m referring to, and is independent of and irrelevant to whether or not you use WhatsApp’s built-in iCloud sync.
Anyone with physical access to your phone could create a backup with it, if access is compelled (e.g. fingerprint, passcode, or simply seizes it unlocked). This content will be encrypted with your backup password (if you’ve set one).
Anyone with physical access to your computer could copy this data from an existing, unencrypted backup, or potentially decrypt it using password breaking tools, or recover the password from your keychain. If passwords are compelled in your country, you may also be forced to assist law enforcement.
Should everybody panic?
Hahaha, no. But you should be aware of WhatsApp’s footprint.
How can you mitigate this as an end-user?
Use iTunes to set a long, complex backup password for your phone. Do NOT store this password in the keychain, otherwise it could potentially be recovered using Mac forensics tools. This will cause the phone to encrypt all desktop backups coming out of it, even if it’s talking to a forensics tool.
NOTE: If passwords are compelled in your country, you may still be forced to provide your backup password to law enforcement.
Consider pair locking your device using Configurator. I’ve written up a howto for this; it will prevent anybody else who steals your passcode, or compels a fingerprint from being able to pair or use forensics tools with your phone. This is irreversible without restoring the phone, so you’ll need to be aware of the risks.
Disable iCloud backups, as these do not honor your backup password, and the clear text database can be obtained, with a warrant, by law enforcement.
Periodically, delete the application from your device and reinstall it to flush out the database. This appears to be the only way to flush out deleted records and start fresh.
NOTE: This will not delete databases from existing iCloud backups from the cloud.
How WhatsApp Can Fix This
Software authors should be sensitive to forensic trace in their coding. The design choices they make when developing a secure messaging app has critical implications for journalists, political dissenters, those in countries that don’t respect free speech, and many others. A poor design choice could quite realistically result in innocent people – sometimes people crucial to liberty – being imprisoned.
There are a number of ways WhatsApp could mitigate this in future versions of their application:
The SQLite database does not need to come off in a backup at all. The file itself can be marked in such a way that it will not be backed up. The manufacturer may have set this behavior so that restoring to a new device will not cause you to lose your message history. Unfortunately, the tradeoff for this feature is that it becomes much easier to obtain a copy of this database.
In my book Hacking and Securing iOS Applications, I outline a technique that can overwrite the SQLite record content “in place” prior to deleting a record. While the record itself will remain on the free list, using this technique will clear the content out.
A better solution is setting PRAGMA secure_delete=ON prior to issuing the delete; this will cause the deleted content to be overwritten automatically. (thanks to Richard Hipp for sending me this information).
Using an alternative storage backing such as raw files, or encrypted CoreData, could be more secure. The file system is easy to implement, and Apple’s encryption scheme would drop the file encryption key whenever a file is deleted. It may not be as pretty as SQLite, but Apple’s file-level encryption is very solid in handling deleted files. Apple uses a binary property list for archival, which is sometimes used to store live message data too on the desktop. Wickr’s encrypted CoreData approach is similarly quite secure, so long as the database keys remain on the phone. Simply using a separate SQLite file for each thread, then deleting it when finished, would be a significant improvement, even if incorporating some of the other techniques described above.