[TIMOB-3076] iOS - File encryption feature request
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | Trivial |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2011-09-01T13:09:16.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Sprint 2011-32 |
Components | iOS |
Labels | encryption, feature, ios, request |
Reporter | Pedro Enrique |
Assignee | Reggie Seagraves |
Created | 2011-04-15T03:36:12.000+0000 |
Updated | 2011-12-13T09:51:10.000+0000 |
Description
A HD ticket is asking to implement the encryption recommended by
Apple to protect sensitive data.
This is described in the following https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/iPhoneAppProgrammingGuide.pdf">
Apple Programming Guide page 15 and 53.
Helpdesk ticket:
http://developer.appcelerator.com/helpdesk/view/71581">http://developer.appcelerator.com/helpdesk/view/71581
Any updates / ETA on this? Have a client who is very insistent on having their app data encrypted. Hopefully it's not too much work to implement?
I would be interested in this as well. Any info?
Another customer is asking for this feature. The feature request is specifically File Protection found on page 15 of the PDF in the link above. Possible, would be nice to also have the Keychain Data, also found in that page from the PDF
Associated Helpdesk Ticket
http://appc.me/c/APP-134761Time spent reviewing. Solves the customer issue. However, see TIMOB-4840, companion bug which details other fixes necessary for our API.
More info: when the iOS passcode lock enabled, that it only encrypts data for the built-in apps like Mail, etc. but not 3rd party apps. Specifically, I'm referring to the iOS "Data Protection APIs" as mentioned here: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/iPhoneAppProgrammingGuide.pdf Pages 15, 53
Reopening this issue to provide QE with additional test plans that will show that encryption is taking place. Previous tests only proved that existing file i/o continued to work.
Testing; The way this works is according to the Apple documentation. Protected files are stored on disk in an encrypted format at all times. While the user’s device is locked, not even the owning application can access the data in the encrypted files. The user must explicitly unlock the device (by entering the appropriate passcode) before the application can retrieve the decrypted data from the files. The user’s device must have the passcode lock setting enabled and a valid passcode set. Currently, all data files written using our File APIs are protected. Essentially what this means is that when you try to use Xcode's Organizer or the iPhone Configuration Utility to copy the application's data off the device when the device is locked with a passcode, it should fail. Once the passcode is entered, the data can be copied off just fine. Once the data is copied off in this manner, it will not be encrypted, and this is the expected behavior.
Tested with iphone 4.3.3 and iPad 4.3 with version=1.8.0 timestamp=08/28/11 13:14 githash=9c8f107...
I'm not sure what I'm doing wrong, but the files I write are not encrypted. If I lock the iPad and break into it through SSH, I can still read the said protected files (simple PDFs in the applicationDirectory).
Alberto - Please read the following document, page 94 (Protecting Data Using On-Disk Encryption) https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/iPhoneAppProgrammingGuide.pdf There are some preconditions for being able to enable secure locking. If files remain unencrypted with these preconditions met, and the correct properties set in Titanium, please report this to us with instructions on how to reproduce the issue on a device which is *not* jailbroken.
The precondictions are satisfied (iOS 4/5 and passcode lock activated). I'm trying to reproduce a scenario where my customers lose their devices and someone tries to gain access to their confidential documents. In that case the first step would be to jailbreak them. And if I browse the filesystem like I said before with ssh the files are totally readable. So, when would this kind of encryption be useful otherwise?
You'll also note that the document mentions hardware preconditions; we need to know what hardware you're testing on as well, and whether or not it was reformatted/erased/backed up before attempting this test. That could make a determining factor. Internally, we cannot officially test any fixes against jailbroken devices due to them being an unsupported platform with unpredictable behavior.