Sqlite encyption

[CALL-151]

This is a critical issue for anyone developing medical apps that contain protected health information, and I appreciate the effort to get this working in mobile environments. Unfortunately, a review of the Encrypt/Decrypt entries in the dictionary confirms that mobile platforms are not supported, and the iOS release notes "What doesn't work" section continues to list "industrial strength encryption and public key cryptography (planned for a future release)".

To add to the confusion, those working in iOS might be interested in reading http://images.apple.com/ipad/business/p ... erview.pdf which includes the statement, "iPad offers 256-bit AES encoding hardware-based encryption to protect all data on the device. Encryption is always enabled and cannot be disabled by users."

If I understand this implementation correctly, iTunes decrypts on the fly when syncing. This should mean that if lost of stolen, all data on the device remain inaccessible (except data that you allow the user to see, print, email, etc via your app).

[marksmithhfx]

To add to the confusion, those working in iOS might be interested in reading http://images.apple.com/ipad/business/p ... erview.pdf which includes the statement, "iPad offers 256-bit AES encoding hardware-based encryption to protect all data on the device. Encryption is always enabled and cannot be disabled by users."

If I understand this implementation correctly, iTunes decrypts on the fly when syncing. This should mean that if lost of stolen, all data on the device remain inaccessible (except data that you allow the user to see, print, email, etc via your app).

Hi Call-151,

Your previous post describes my situation exactly; the development of a medical application with sensitive patient related information. In such a scenario I must be assured that any data on the device is encrypted, and remains encrypted, should the device be lost or stolen. It is important to realize some current limitations on the iPad. The hardware based encryption is based on having a password on the device. Without a pw data on the device is not encrypted. Second, jailbreaking an ipad by-passes the pw and therefore allows access to the data (essentially it becomes decrypted once the data is accessed... same as if no password was present.) Third, it is fairly trivial to jailbreak an ipad or ipad2 up to iOS 5. Currently there is no jailbreak solution for iOS5 or higher however I am operating on the assumption that it is only a matter of time before a jb for iOS5 appears, and thus defeats the current pw based encryption.

There is a solution, but it requires some intervention by RunRev. You can further protect a file on an iPad/iPhone by using the Data Protection API and setting the value of the NSFileProtectionKey attribute. By default this attribute is set to None on all files. If instead it is set to NSFileProtectionComplete then the file is only readable when the correct user passcode is entered. In other words jailbreaking, which only by-passes the password, but does not enter it, will not allow the unencrypted files to be read.

From an online source I read here is how it works: when NSFileProtectionComplete is set, the system uses the users password + the built-in hardware based encryption key to encrypt the data. When the device is turned off it throws away the user password component thus making the files that are encrypted permanently unreadable until the user re-enters their password. Since jailbreaking does not reveal any user passwords the data remains locked up on a jail-broken iPad or iPhone.

I don't have the technical knowledge or sophistication to assist RunRev in setting this important file attribute on SQLite files, nor do I know if it is even possible for RunRev to do it independently (knowing that SQLite is a 3rd party application). However, lobbying for support of the Data Protection API with SQLite files in LC might be the easiest route to getting good data security. It would be sufficient for my purposes. PS if you want references to some of the background documents I read let me know as I bookmarked most of them.

-- Mark

[CALL-151]

Yes, links to the docs you mention would be very helpful, thanks. I was not aware that hardware based encryption depended on setting a device password! I thought it depended only on the iTunes account to which the device is registered. I'll try to test this with someone else's device that isn't password protected, but it sounds like I'll be able to plug that device into my computer and use one of the available iOS file browsing apps to read their data. That's a huge problem, and one that extends beyond protecting sqlite files. presumably, it should be possible to craft an external to access the Data Protection API, but I agree that the only real solution is for RunRev to add file encryption capabilities for mobile platforms.

[marksmithhfx]

Hi Call-151,

In no particular order, although some of these will seem to contradict one another and discerning the truth can be difficult at times. I'm still not sure I'm there yet

http://ipadlawyer.co.uk/when-is-encrypt ... encryption

http://anthonyvance.com/blog/forensics/ ... rotection/

http://foleypod.com/how-to-use-your-ipad-securely/

A description of the Data Protection API:

http://www.goodreader.net/gr-man-general.html#dataprot

Here are some important quotes from the next article:

"Anything stored in the clear will be accessible when a device is jailbroken. Anything written using Data Protection APIs will remain encrypted. Only by entering the passcode can that encrypted data become available. This is an important distinction that needs to be understood. Jailbreaking/bypassing the passcode DOES NOT BREAK iOS ENCRYPTION - it merely bypasses the basic protection on the device. Anything stored using Data Protection APIs WILL REMAIN ENCRYPTED EVEN FOLLOWING JAILBREAK."

Note: it can be difficult for me sometimes to decipher what this author really means. What I think he is saying is, if you depend on the built in interface and 256 bit AES encryption, you are out of luck. There are so many holes and backdoors into that data that its not even funny. However, if you application takes control and implements the features in the Data Protection API (which I described earlier) then you are good to go. Your data stays encrypted.
http://www.nsslabs.com/blog/2011/10/why ... e-use.html


The next one is very technical, and way over my head, but I learned lots, particularly in the data protection section.

http://media.blackhat.com/bh-us-11/DaiZ ... ity_WP.pdf

Good hunting, hopefully we can get this sorted in the next little while. It would be fun to write and deploy a secure LC app on the iPad.

-- Mark

[marksmithhfx]

I took another look at this material and if I had to summarize, here is what I think I understand. Yes, data on an iPad is encrypted 256 bit AES. But if you hook up iTunes (and do not have a provisioning profile which enforces encryption on backups) then iTunes will un-encrypt the files on the fly, without prompting for a password (this is for its original backup machine... if it is a new pairing, it will prompt for a password). If you do have a provisioning profile then the files remain encrypted.

But, if you jailbreak the iPad (note, not currently possible on iOS 5, but on versions below) then you can BYPASS (important word) the password, and the iPad will provide unencrypted access to the data (I would like independent confirmation of this because it doesn't sound right to me). Apparently jailbreaking will provide a backdoor into the data. But as I say, we should seek some independent confirmation.

However, if you use the Data Protection API to set the NSFileProtectionKey attribute to NSFileProtectionComplete (discussed in the last article I posted a link to) then encrypted files remain encrypted even if the password is bypassed through jailbreaking or through trying to backup through iTunes (when the users passcode has not been entered).

I think

Finally, I think it is way to hard to find reliable information on how secure data is on an iPad/iPhone. There should be some sort of user friendly readable description of how good the security features are, how they can be compromised, and what can be done (if anything) to mitigate risk. After all of this reading my brain hurts

-- Mark

[CALL-151]

Thanks. Now my brain hurts too. I asked RunRev about encryption support for mobile and received the following from a RunRev project manager:

"I can confirm that Encryption support is
planned for both iOS and Android. However, it is still quite a few months
away. We may get to it sooner but the project is complicated by the Encryption
libraries we use. We use OpenSSL and the mobile versions of this library are
not directly compatible with the desktop variants. As a result, a number of
engine changes as well as standalone builder changes will need to be made.
It is planned but I could not promise to have it delivered before the summer."

[paul_gr]

Before you decide you need to use encryption in an app, see these links to see the extra hoops you might have to jump through to get your app approved....

http://stackoverflow.com/questions/2128 ... compliance
http://tigelane.blogspot.com/2011/01/ap ... ns-on.html

Paul

[marksmithhfx]

Before you decide you need to use encryption in an app, see these links to see the extra hoops you might have to jump through to get your app approved....

http://stackoverflow.com/questions/2128 ... compliance
http://tigelane.blogspot.com/2011/01/ap ... ns-on.html

Paul

Paul, thanks for the links (especially the 2nd one... great site). This won't be an issue in my case as I plan to deploy directly ie. not through the app store.

-- Mark

[marksmithhfx]

File protection on iOS: there is an easier way.

I have just come across a 1 hour presentation by Apple on how to secure data on iOS and it is presented here:

http://developer.apple.com/videos/wwdc/2010/

The title of the presentation is "Securing Application Data" (and the presentations are listed alphabetically so it should be easy to find).

Bottom line of this presentation: Apple wants programs like LC to protect users data and they provide the tools to do so in the Data Protection API. They even go so far as to say, unless you have a compelling reason to do otherwise, always set the NSFileProtectKey to NSFileProtectionComplete (its at about 46:30 in the presentation). Its a simple file attribute and the OS does the rest. There is no overhead, there is no performance penalty. (and they provide code examples)

I am not sure if RunRev is setting this file attribute or not, but I sent tech support a query to find out. If they are then yippee, we have nothing to worry about as the data is already protected all of the time and cannot be accessed if the system is "compromised" (by jail breaking or any other means). If they are not, I've asked if they could please consider making this change. BTW, this would extend to ALL files created by LC on iOS, not just SQLite files. So that would mean no matter where you put your data it would be protected by industry standard encryption 24/7.

BTW, if you want a pretty comprehensive explanation of all of the data protection schemes and mechanisms on iOS, this video is highly recommended and is as close to user-friendly as you are likely to find.

Cheers,

-- Mark

[CALL-151]

This is great news, thanks. Hopefully, there's a simple way for LC to allow us to set this attribute when building iOS standalone apps.

[marksmithhfx]

This is great news, thanks. Hopefully, there's a simple way for LC to allow us to set this attribute when building iOS standalone apps.

This is an old thread but I wanted to revive it for those who are still interested in the topic of the NSFileProtectionKey. Monte Goulding has developed an external that is part of his mergEXT package called mergXattr (it is described on this page: http://mergext.com/home/mergxattr/

The second syntax example provides an example of setting the NSFile Attribute to NSFileProtectionComplete, which is exactly what we need in order to secure our data against jailbreaking and other system compromises. Way to go Monte. Such a small thing and yet it enables so many possibilities. I will definitely be getting a copy of mergEXT.

-- Mark

[CALL-151]

Yes, this and Monte's other externals are fantastic. Go buy mergEXT! But it's important to understand that setting the file protection attribute does not protect data that you need to send elsewhere (e.g. as an email attachment, to a server, to another app, etc) because files are decrypted as soon as the device is unlocked. Great safeguard against a stolen device, but protecting data in motion still requires encryption. I've discussed an AES-256 external solution with Monte, and it's not worth his while to do this, particularly since it's on RunRev's list of features to implement.

[marksmithhfx]

Yes, this and Monte's other externals are fantastic. Go buy mergEXT! But it's important to understand that setting the file protection attribute does not protect data that you need to send elsewhere (e.g. as an email attachment, to a server, to another app, etc) because files are decrypted as soon as the device is unlocked. Great safeguard against a stolen device, but protecting data in motion still requires encryption. I've discussed an AES-256 external solution with Monte, and it's not worth his while to do this, particularly since it's on RunRev's list of features to implement.

Except for iTunes backups, which you can require remain encrypted. Just thought I should mention that 1 exception to the rule.

-- Mark

[n00b3]

CALL-151 wrote/quoted on Jan 5th:

"...It is planned but I could not promise to have it delivered before the summer."

Has there been any more news as to progress/ship date for encryption?

I realize it is not summer yet but thought I would ask

Cheers

[CALL-151]

I've heard nothing more about iOS encryption efforts from RunRev, but I've been testing a 3rd party encryption external that's in development and works well. I'm not sure what the release timeline is, but I'll contact the developer to let him know that there's continued interest.