Skip to content
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity

Calendar

March 2023
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  
« Feb    

Archives

  • February 2023
  • December 2022
  • November 2022
  • July 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • November 2018
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security











ZdziarskiDFIR, security, reverse engineering, photography, theology, funky bass guitar. All opinions are my own.
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity
Apple . Forensics . Security

iOS / OS X and Forensics Trace Leakage

On March 22, 2016 by Jonathan Zdziarski

As I sit here, trying to be the good parent in reviewing my daughter’s text messages, I have to assume that I’ve made my kids miserable by having a father with DFIR skills. I’m able to dump her device wirelessly using a pairing record and a tool I designed to talk to the phone. I generate a wireless desktop backup, decrypt it, and this somehow makes my kids safer. What bothers me, as a parent, is the incredible trove of forensic artifacts that I find in my children’s data every month. Deleted messages, geolocation information, even drafts and thumbnails that had all been deleted months ago. Thousands of messages sometimes. In 2008, I wrote a small book with O’Reilly named iPhone Forensics that detailed this forensic mess. Apple has made some improvements, but the overall situation has gotten worse since then. The biggest reason the iPhone is so heavily targeted for forensics and intelligence is because of the very wide data recovery surface it provides: it’s a forensics gold mine.

To Apple’s credit, they’ve done a stellar job of improving the security of iOS devices in general (e.g. the “front door”), but we know that they, just like every other manufacturer, is still dancing on the lip of the volcano. Aside from the risk of my device being hacked, there’s a much greater issue at work here. Whether it’s a search warrant, an unlawful traffic stop in Michigan, someone stealing my backups, an ex-lover, or just leaving my phone unlocked on accident at my desk, it only takes a single violation of the user’s privacy to obtain an entire lengthy history of private information that was thought deleted. This problem is also prevalent in desktop OS X.

While Apple’s file system encryption does a good job of ensuring that deleted files actually get deleted (with only a few minor exceptions), most of your private data lives in databases that are never deleted (unless you blow away your device’s data). Your iMessage content, notes, WiFi, location history, call list, contacts, and a lot of the data stored in your third party apps are all kept in a “records” on the device, inside a container (a SQLite database) that doesn’t get deleted. When you delete that iMessage, the message is only flagged for deletion and it hangs out on a free list inside the database – sometimes for months. Even worse, deleting an entire conversation has proven to actually insert new record data leaving forensic trace showing that the conversation was deleted. In short, there’s a big problem with forensics exposure in iOS, and it’s not the file system; it’s the database storage.

This is a problem Apple should address, especially as popular as the iPhone has become, and especially with as much content as is being shoved into these databases by both Apple and third party application manufacturers. So how can Apple fix this? They already invented the solution! The file system encryption in iOS creates a random key for every file on the device, then wraps that key (using something called an aes key wrap) to protect the file record. Those wrapped keys are encrypted with class keys from the device’s keybag, which are controlled by device policies and protected by the user’s passcode. This same design can be ported to SQLite databases in a way that doesn’t chew up the NAND anymore than the file system does. Here’s how it would work:

  • Whenever a new record is inserted into a SQLite database, a new record key is generated.
  • The record is encrypted with this unique record key.
  • The record key is encrypted with a class key and then wrapped. This could be done with a master records key table, abusing xattrs, or integrated directly into the data by adding a hidden column to every table created.
  • Whenever a file is deleted, the record key itself is overwritten with padded zeroes, leaving the record’s content unrecoverable.

This allows for SQLite to work the same way it always has, and doesn’t force you to vacuum or overwrite every deleted record: all you have to do is overwrite the key. This is an easy process with SQLite, and could protect every single database record on the device.

Such a technique could be made completely transparent to third party apps, or at least to Apple apps, by integrating it within libsqlite, or it could be made available easily through the iOS SDK. The former would benefit the user’s privacy the most, but may present backward compatibility issues as third party apps don’t have data migrators like Apple apps do. Either way, it’s doable and necessary.

Apple has worked very hard to reduce the iPhone’s attack surface, but they haven’t yet fully addressed the underlying motivations of an attacker (specifically, the device’s forensic value), and that’s left the iPhone a very high value target. This is the oldest, and hardest challenge in the book: making sure that deleted data actually gets deleted. Conversations are ephemeral, but the traces of these conversations are not; this directly impacts how and why search warrants are executed and why mobile devices are targeted by attackers. If the user of the device believes their conversation to be deleted, it’s breaking their trust by keeping forensic traces of those conversations, and ultimately the device’s design can lead to a betrayal of the user’s privacy if data is stolen or a forensic image is made. Ephemeral conversations (or other exchanges) should also mean ephemeral data. This is not a strength of iOS in general.

Shoring up privacy on the iPhone would certainly make my job harder as a parent… but I’d be happy to see that my child’s past conversations, location information, and other private data also isn’t subject to a stalker or a hacker if the information got out. I think that’s a very reasonable trade-off.

 

Archives

  • February 2023
  • December 2022
  • November 2022
  • July 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • November 2018
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Calendar

March 2023
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  
« Feb    

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security

All Content Copyright (c) 2000-2022 by Jonathan Zdziarski, All Rights Reserved