TouchDB-iOS security

[dyowee]

Good day,

 

I'm working on a simple app for healthcare, so there is a need to secure the data to accomodate regulations. Does TouchDB iOS support this?

 

Thanks,

Joey

[Jens Alfke]

On Aug 6, 2012, at 3:51 AM, dyowee <csharpen...@gmail.com> wrote:

I'm working on a simple app for healthcare, so there is a need to secure the data to accomodate regulations. Does TouchDB iOS support this?

I looked into this a while ago — app files on iOS (including the TouchDB SQLite database files and attachments) are encrypted by default. It's done transparently by the OS, and the decryption key is tied to the user's passcode.

If more encryption is needed, there is an SQLite extension that provides database encryption, but I *think* you'd need to build your own copy of SQLite with the extension, and link TouchDB with that instead of the built-in iOS SQLite.

There's more discussion of this in the issue tracker. It's one of the earliest issues filed; I'd look up the link but I'm offline now as I write this. Shouldn't be hard to find.

—Jens

[Sebastian]

I'm not quite sure if they are encrypted by default. Apple write in their doc: "To protect a file, your app must add an extended attribute to the file indicating the level of desired protection. Add this attribute using either the NSData class or the NSFileManager class."

You can find it here in the chapter Protecting Data Using On-Disk Encryption.

Where did you get this information from?

[Jens Alfke]

From an email earlier this year from someone who doesn't want his name made public:

I'm a forensics researcher and am familiar with the encryption. The encryption happens within the file system, but it is transparent to reading/writing the file system, similar to full-disk encryption. Every file in the user data partition is encrypted; the data protection APIs let you specify whether the key to decrypt the file is available whenever the file system is mounted (basically, whenever the device is booted normally) or only when the user has unlocked the device.

I assume you are reading the section fro the iOS 5 library's "iOS App Programming Guide". That document understates the level of protection. All files are encrypted and get a unique key when created, assuming have the new file system (a 3GS has be restored from iOS 3, not just updated. iOS 4 uses the new fie system by default), even if no passcode is set. When a remote wipe is requested, the device simply discards the keys that protect the file keys (the key bag), so if every file wasn't encrypted, that wouldn't be possible. If a passcode is set and you select NSFileProtectionComplete, then the file key is protected with a key derived from the passcode, and that key is discarded when the device is locked.

[…] This was covered thoroughly in Session 209 at WWDC 2010, if you are interested.

—Jens

[Sebastian]

I looked a little deeper into this topic. Yes, the files are by default encrypted. The problem is that they are only encrypted with the device key which can be retrieved from the device even when the device is locked. If you apply the setting NSFileProtectionComplete the files are encrypted with the device key and the unlock passphrase. This way if the device is lost and locked an attacker cannot encrypt the files unless he has the unlock passphrase. There is a similar setting for the kaychain.

Frauenhofer institute invested this and published there results:
http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords.pdf
http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-faq.pdf

[Jens Alfke]

On Aug 14, 2012, at 11:32 AM, Sebastian <fwpb...@web.de> wrote:

I looked a little deeper into this topic. Yes, the files are by default encrypted. The problem is that they are only encrypted with the device key which can be retrieved from the device even when the device is locked. If you apply the settingNSFileProtectionComplete the files are encrypted with the device key and the unlock passphrase. This way if the device is lost and locked an attacker cannot encrypt the files unless he has the unlock passphrase. There is a similar setting for the kaychain.

Interesting! Thanks for the links to the Fraunhofer papers — I hadn't seen those before, and they look very authoritative, especially since the first author's name is Jens. That's a name I can trust. The papers only describe the security of secrets stored in keychains, though, not of application files, although of course they're related since the file decryption keys are stored in the keychain.

It sounds as though:

• All files/keys are secure against remote attacks (malware) that don't compromise the OS kernel itself.

• The attacks Fraunhofer performed required physical access to the device, in order to jailbreak it and run their forensic app on it. In this case keys protected only by the device key can be retrieved. It looks like these tend to be system keys that need to be available even when the device is locked.

• Keys and passwords in application keychains are safe, because the default settings prevent access to them without having the user's passcode.

• Application files are by default not safe against a jailbreaking attack because their encryption is based only on the device key.

• Setting any of the non-default NSFileProtection attributes makes files safe — I don't see a great deal of difference between the levels, because they all protect files until the device is first unlocked with the user passcode, and jailbreaking requires rebooting the device.

The resolution seems to be that we should apply a file protection attribute to TouchDB database and attachment files. The best attribute seems to be (deep breath) NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication, because it allows access to the file after the device is locked. That way if a push replication is active when the device locks, it can keep working without running into file access problems.

I've added the links and my analysis to the TouchDB issue.

—Jens

[Sebastian]

The security classes apply both for the keychain and for the files. They are just called different. For the kaychain it's kSecAttrAccessibleWhenUnlocked for files it's NSFileProtectionComplete. Both keychain and files are only protected if they use this security classes (in the lost device scenario Frauenhofer used). Otherwise even the keychain entries are only encrypted with the device key. The deveice key can be calculated by the hardware of the device or can even be bypassed when you use the API of the device. This way the device itself decrypts the files and keys. This assumes that the device is not jailbreaked otherwise it's wide open for any malware such as accessing different sandboxes or memory.

There are big differences in the security classes for example for the keychain:


kSecAttrAccessibleAlways allways accessible - locked or unlocked
kSecAttrAccessibleAfterFirstUnlock accessible after first unlock - so in fact if you haven't shut down the device allways
kSecAttrAccessibleWhenUnlocked only when the device is unlocked

My understanding is that every TouchDB fileoperation stops when the device is locked as all sockets are shut down and the app isn't allowed to stay active for a long time. So it would be the best solution to choose the WhenUnlocked or Complete setting as it gives you the highest possible security. When the replication naturally needs to stop when the device is locked there is no need to use the AfterFirstUnlock security level. If you use this level you assume an attacker needs to restart the device. Maybe there is a way in the future where you don't need to restart the device.

So my suggestion would be to use the highest possible security level when you don't use fileoperations when the device is locked. There is even an app delegate so you can stop all fileoperations when the device becomes locked:

The app delegate can implement the applicationProtectedDataWillBecomeUnavailable: and applicationProtectedDataDidBecomeAvailable: methods. 

[Sebastian]

Hmm...I somehow broke the formatting after the security classes here is a reformated version :)

[Sebastian]

If you allready wrote the file you can set the attribute with NSFilemaneger. You can set the NSFileProtectionKey property with the NSFilemanager method:

- (BOOL)setAttributes:(NSDictionary *)attributes ofItemAtPath:(NSString *)path error:(NSError **)error

I have seen a similar example for files. You just need to do a Back-Up when the device is jailbroken (and still locked) and then rename the not encrypted files with a script.