3 min read

Demystifying iOS Data Security

Demystifying iOS Data Security

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 only value that forms 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, upon verification of other unique system identifiers, allow for the decryption of user 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 're-setting' 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 (to my knowledge) 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 available in this BFU state!

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 of the home-screen 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. 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