Demystifying iOS Data Security

June 10th, 2020 by James Duffy
Category: «Cryptography», «Mobile», «Security»
  • 18
  • 20
  •  
  •  
  • 3
  •  
  •  
  •  
    41
    Shares

It’s an honor to be given the opportunity to post on the ElcomSoft Blog, and I’d like to thank the ElcomSoft team for supporting my research. Recently I’ve been sent over a few questions from members of the community, such as “Why can’t we decrypt the data from a disabled iPhone over SSH if we know the passcode?” and “I tried to SCP a file from the device to the Mac, but getting permission errors”. Today I’m going to answer these questions in a Q&A format for you all so hopefully we can shed some light on how this works! The article is aimed to be accessible for everybody, including beginners and non-technical users. Without further ado…

Q: “Why can’t we decrypt the data from a disabled iPhone over SSH if we know the passcode?”

That’s a really great question. The answer lies in how SEP is used in the encryption process. Your passcode, in itself, is not the ‘encryption key’ so cannot be used to directly decrypt your data.

The SEP processor will allow the iPhone to transmit the device passcode to the SEP Processor, where if the correct conditions are met, the SEP Processor will release the encryption key used to decrypt your personal data.

Now let’s say your iDevice is disabled. All the SEP Processor has to do, in this case, is ‘stop answering’ transmissions where a passcode is entered, essentially rendering the device useless until it is restored (which in turn is resetting the SEP state and generating new encryption keys).

As we never have direct access to the encryption keys held by the device, once it’s disabled, SEP stops answering these transmissions entirely and we have no way of communicating with SEP. I believe once a device is disabled, SEP entirely discards the encryption key it holds.. meaning the encrypted data is irrecoverable.

Q: “I tried to SCP a file from the device to the Mac, but getting permission errors.. I even tried using chmod to set permissions!”

Nice try! If you type ‘ls -l’ while cd’d into the directory in question you’ll see a little tag appended to the end of the permissions where the particular file is encrypted.

Essentially what you’re seeing in the terminal while a device is Before-First-Unlock (BFU) is mostly just ‘indexed files’ or records of file locations. The data itself is not accessible to neither the user or device in this state. Following the correct pin entry, SEP reveals the keys used to encrypt your data and at that stage, your user data becomes accessible to the device and to us over the SSH connection.

Q: “Based on my searches, I found that there is a tool (called sliver I believe and referred to by appletech) that it can bypass passcode/disabled device in some circumstances. Does this mean the ability to access enter AFU using this method?”

Some data on the device is decrypted at all times, and not protected by the Secure Enclave Processor (SEP). This is data we/the device can access at ALL times, even before the first unlock. ZPET actually takes advantage of the cache files which are a state of being available at all times!

So, maybe we can bypass the lock screen. But this isn’t granting us access to ANY encrypted files. We essentially have to be on-our-toes with every swipe as there will be countless numbers of permission errors in the background and accessing any user-data will be near-impossible. So in conclusion, maybe we can bypass the lock screen, but it won’t let you access anything at all.

The state AFU describes a situation where SEP has revealed the encryption keys to the system and allows for the user data to be decrypted and used, and so this wouldn’t enter that mode!

I hope that was a nice little insight, and if anyone has any questions, please do let me know by @‘ing me on Twitter @J_Duffy01 and hopefully I can make more articles similar to this, directly answering your questions!

I hope you have an amazing day and thanks a lot for reading this article!

–James


  • 18
  • 20
  •  
  •  
  • 3
  •  
  •  
  •  
    41
    Shares