by Mark Smith
Mark Smith manages the data repository at the Manitoba Centre for Health Policy and conducts health research. In his spare time he codes medical and other kinds of applications using LiveCode.
______________________________________________________________________________________________
If you have sensitive information that needs to be secured on an iOS platform then you may find the following discussion useful. Such was the case for a hospital application I was developing that required the collection of personal health information. Not surprisingly the client was only willing to consider a mobile option if the information could be securely stored and managed on the device as well as off. And, unfortunately, storage on the device was the only option since the hospital had neither 3G nor wireless available (which would have allowed a mobile client/server solution).
Securing data on iOS is not as easy as it sounds. If you provide no more protection than a simple 4-digit numeric passcode, then this can easily be defeated. There are desktop applications that can be downloaded that can brute-force discover any 4-digit numeric code in under 20 minutes. Things get a little better if you use a more complex passcode and you can enforce the requirement of a complex passcode by creating a configuration profile for your device (more on that in a bit).
So I was really pleased to see that RunRev had implemented support for the hardware based encryption that is built into iOS through the Data Protection API in version 5.5 of Livecode. As noted in the LiveCode documentation, there are four options available for the iphoneSetFileDataProtection command:
- none – No protection
- complete – The file is not accessible, for reading or writing, while the device is locked.
- complete unless open – The file is fully protected when the device is locked, unless it was already open.
- complete until first user authentication – The file is fully protected until the user unlocks the device for the first time.
You should also be aware that this additional level of security is enabled by having a user passcode installed on the device. No passcode, no protection. That is the critical first step in enabling all of the above options. Also, the documentation leaves lots of questions as to what state a file will be in during the course of its life, and certainly what state it will be in when it leaves the device. To answer some of these questions I constructed a few tests. You may find the results surprising.
To begin with I created an SQlite database file and added a few records. I set the file protection level on this file to “complete” and then I locked the device.
Next I used Xcode to transfer the file to my desktop. I was expecting to see an encrypted file but was surprised to see a blank one. Well, from a security perspective blank is good. No brute force attempts to decrypt it are possible. (Note: I have gotten different results using different versions of Xcode. Some return no file at all when the file is protected and the device is locked).
Then I unlocked the device and again transferred the file using Xcode, and as the documentation suggests, this file was completely readable. This is fine if you think no one can spy on your device while it’s unlocked, but what happens if the file is inadvertently backed up to iTunes or iCloud while the device is unlocked? Is the file protected in that case?
Well, in the case of iTunes the answer is “No”. The file is completely readable regardless of whether the device is locked or unlocked when the backup is made. Now, I was expecting the file to be readable when backed up from an unlocked device, but I was not expecting it to be readable when backed up from a locked device as well.
I suspect what is going on is that Apple treats a backup to a known trustworthy device the same as unlocking the device. You may recall when you first attempted to backup your device Apple asked you to enter the passcode. It probably stored it somewhere, and whenever the file is backed up again it uses that copy to decrypt the backup files.
In the case of backing up to iCloud, the Apple documentation says that all files backed up to iCloud are encrypted but my understanding is that the encryption is done with keys that are stored on the server side, so there is still a very small risk that someone hacking into Apple’s servers could discover both the keys and the files. However, given the sheer volume of backups that Apple maintains, there is some protection from the anonymity of being in such a large crowd.
So what have we learned? First, the iphoneSetFileDataProtection “complete” option appears to work to encrypt and secure the file when it is not being accessed. It is likely that the file is adequately protected until an authorized user (one who knows your passcode) requests access to the file. Second, it is not protected at all when backed up to iTunes. If that situation concerns you (or you don’t want the file backed up to iCloud), you have several options:
- Set the don’t backup flag on the file
- Put the file in a location that iTunes won’t back up
- Set iTunes to create encrypted backups (this is the only option for iCloud)
- Turn off iCloud backups
- Encrypt the file yourself
To set the file so it won’t be backed up use the iphoneSetDoNotBackupFile command with thedoNotBackup Boolean option (where true = do not backup):
To put the file in a location that iTunes won’t back up use either the /Library/Caches directory or the /Library/tmp directory. However, both of these locations can have files periodically removed by iOS to free up space, so they do not provide a solution for long term storage. The Apple recommended strategy is to mark the files as “do not backup”.
To create encrypted backups using iTunes, select the devices tab in iTunes and select your device. Then check the “Encrypt local backup option”. While you are there, you can also turn off iCloud backups by unchecking the “iCloud” option. Also, on your iOS device, using the “Settings” app you can disable iCloud backups under the iCloud/Storage and Backup option.
Of course there are other options as well. One is offered by Monte Goulding with his mergAES external for Livecode. I bought a copy of this to try out and I must say it has worked remarkably well for encrypting and decrypting the file on the fly on the iPad as well as ensuring that once the file leaves the iPad it remains encrypted (an added bonus frankly!). There is also an option in mergAES to encrypt the file in a format that is compatible with Livecode’s decryption routines (you need to use the OpenSSL format in mergAES).
Click image to zoom
Just don’t expect iphoneSetFileDataProtection to solve all of your security concerns unless you are only interested in protecting your files while they are “at rest” and you use a complex password on the device. If you really want the data to be secure you will probably have to double encrypt the file using something like mergAES. That way, if someone is really determined to get at your data they will find that after circumventing the first hurdle (your passcode) they are still left with a securely encrypted file.
Of course there is lots more to iOS file and application security than what I’ve covered here. Recently I ran across a new publication by Apple that appears to cover the iOS security issues in much more detail than has previously been reported (it’s 20 pages in length). As of Dec 8th, 2012 you could find the document here.
(NOTE: as of January 4, 2013 this document is no longer available or is encrypted. If anyone wants a copy please request in the comment box below).
Finally, if you are handing out iOS devices, you may want to consider enforcing the use of a complex passcode as well as other security settings. You can do this by creating a configuration profile for the device. I don’t have the space here to go into this in any detail but luckily Apple has a tool you can use (the iPhone Configuration Utility) that will work on any iOS device and it has excellent documentation.
Click image to zoom
The Configuration Utility is available here.
The only solution I can think of that would be better is to have encryption built right in to the SQlite library (there is such a package, but it is not licensed by Runrev. If you think you would use this you might want to send RunRev a note sometime to let them know). Well, that’s it for me. As you travel down your “mobile” path in life may your data always be secure.
Join the conversation