Knowing that File Protection Works

In one of our business-specific apps we wanted to activate File Protection. But how do you know if its turned on and actually doing its job?

We even spent a tech incident (of two you get from free every year) to inquire how we could be certain if the feature is actually working. Though unfortunately Apple did not have any answer for us because there is no way to actually test this with “legal” means.

Our first thought had been to copy the app documents to the desktop via Xcode organizer. But of course you can only do this while the iDevice is unlocked and thus even file-protected files come across normally.

My associate René Pirringer had the idea to jailbreak on of our test iPads running iOS 5.1.1. This can easily be achieved with a tool called redsn0w. After jailbreaking you install OpenSSH and change the passwords for the root and mobile accounts. Then you’re set to go snooping around in the devices file system. The apps are under /private/var … I don’t remember the rest of the path, but you’ll find it from there if you want to duplicate this test.

At first we couldn’t see any effect from locking and unlocking the device. But closer inspection of the code revealed that we had actually not set the file protection flag on the file we were looking at. You have to be careful that you are actually setting the protection file attribute on the right file.

So we fixed the code so that the right file got the right attribute: NSFileProtectionComplete.

And here’s what we saw in SSH…

If you have the device unlocked and inside the app then you can view the file. In our test we had a simple text file which we output with the Unix cat command.

As soon as you lock the device with a passcode you can still view the file for a duration of approximately 10 seconds. We repeatedly repeated the cat command and the text showed up find. After the time out has elapsed you can no longer do that. I assume that this grace period is meant to enable a process that tries to access this file to quick finish some in progress operation.

If you try to do a cat on the protected file after the grace period has expired you get an “Operation not permitted” error. So we can conclude that this indeed works as designed.

There are a few misconceptions we had about file protection which were cleared up by this Jailbreaking experiment. File protection does not have anything to do whether you app is running or not, it is system-wide. So if the device is unlocked all documents of all apps become accessible. It is of no consequence whether your app is running, backgrounded or even if you kill it.

If an attacker would rip your iPhone from you after you locked the screen would only have 10 seconds to dump the files he’s interested in before losing access to them.

Conclusion

With no Apple-sanctioned way of seeing that File Protection is actually working you have to be extra careful that you are actually applying the correct protection attribute to the files you want to protect. There is an app entitlement to turn on file protection by default for all files that the app creates, but unfortunately this is broken in iOS 5. Because of this you can only enable it for apps that require iOS 6.

Of course file protection is only as good as the strength of your passcode. A simple 4-digit code can be brute forced in about 15 minutes. But the choice of passcode or not is up to the users, we developers should still enable file protection for any data that deserves any level of protection.

Categories: Security