I am making an iOS application where all data stored in Core Data needs to be encrypted when the app is not in use. I understand that newer iOS devices (and devices running iOS 4 +) have access to hardware encryption and special protection APIs, but to my understanding, these only apply when the device is locked. There is no guarantee that users of my app will have a password lock on their devices, yet I still need to encrypt.
Also, I would prefer not to encrypt every individual core data attribute by using transformable attributes, and I understand this makes querying much more difficult. Preferably, I would like to do something like encrypt the core data file on app-close, and un-encrypt it on app-open (I know this might be slower).
Any solutions?
Related
Apple offers the Data Protection capability to apps which encrypts data stored on the device when the device is locked. The Parse iOS local datastore is apparently stored as an unencrypted sqlite database. Is it possible to apply the required Data Protection attributes to the local datastore, specifically NSFileProtectionComplete? The Parse iOS docs don't say anything about this.
I have already applied the appropriate CLPs and ACLs to my Parse classes/objects. I'm looking into iOS Data Protection so that if a user's phone is lost or stolen and a device passcode is in place, the data inside their local datastore cannot be read.
In my iOS app I encrypted database using SQLCipher. But after encrypting database the performance of the app is degrade. So I want to ask that, is there any other way to encrypt database. Can I use file encryption for this using NSFileProtectionComplete.
OR
There is any other way to encrypt database which does't compromise with the performance of app.
Thank you.
After successful purchase I save receipt+transactionID into NSUserDefaults. Same information is sent to server to keep a record.
Later(on demand) when user want to download content from my own server, my app will send receipt+transactionID to server. It will find stored receipt by transaction ID sent from app, verify both stored and new receipts with Apple. If some of the keys matched then provide downloadable content.
However, nowadays it's not hard to get hold of NSUserDefaults and extract receipt+transactionID. Even if I place information in keychain, it's possible to capture receipt from internet connection.
Now if someone will have receipt+transactionID, can send a request to my server and get content from any PC. How can I patch this logic without using cryptography?
Although you can patch your logic to make it harder to break, if you want real protection you need some kind of cryptography. You do not need to apply it explicitly - something as mainstream as switching from HTTP to HTTPS will often do the trick.
The three places where you need to protect your sensitive data are on the device, on the server, and in transit.
To protect the data on the device, store it in the Keychain: after all, storing small chunks of sensitive data is the main purpose of adding Keychain to the array of storage possibilities on iOS.
Server protection is a large topic that has been treated in numerous online and offline publications; for the purpose of this answer I assume that your server is adequately secured.
What is left is protection of your data in transit between the device and the server, and between your server and the Apple's server. You can use HTTPS for achieving transport-level protection.
Note that adding all these levels of protection does not make your data absolutely secure: an entity with a lot of time and resources (e.g. a government of an unfriendly country) could potentially discover your keys - for example, by disassembling the physical device, and inspecting the data coming out of the CPU with a logic analyzer. However, the point of this exercise is not to achieve the absolute protection, but to make it prohibitively expensive to break your security scheme. To that end, a combination of Keychain and HTTPS should achieve the goal of making it more expensive to break your protection than to buy your content legally.
I need to develop some simple demonstration of an application reading a file over HTTPS and saving it to the local memory (internal or external) of an iOS device (e.g., an iPhone), in a way that it is only accessible to it. So, application-specific file encryption is required.
The "Advanced App Tricks" page of the Apple iOS Developer Library, in the "Protecting Data Using On-Disk Encryption" section, seems to imply that a file encrypted on disk, via either Default (i.e., iOS filesystem) or "Complete" Data Protection, would be accessible by all applications, after the user types the device's lock code.
If that is the case, could someone please suggest the best way of implementing file encryption per-application on an iOS device, with a password request when a user tries to open the file? Any sample code would also be very helpful.
Also, does "software encryption" apply to iOS anymore? Both Default and Data Protection encryption seem to be hardware-based.
Thanks!
Application files are not accessible between Apps. Each App is individually sandboxed.
In all cases the document is talking about the access available to "Your App"/ It is never accessible to another App. But see below. Sone of the protection options help cover what and when "Your App" has access to the file when in the background.
JailBroken iOS devices will have greater file system access so adding "Data Protection" will protect from this vector.
See the document session on The iOS Environment and particularly the section "The App Sandbox" iOS Environment
Hardware encryption: There are a few things that hardware encryption provide. 1. Speed. 2. The encryption method can not be changed, that is as with software encryption there is no code that could be compromised. 3. The key can not be accessed. The key is in some manner placed/created in the hardware and the hardware will does not allow read access (there are occasionally very secure export capabilities). The device is asked to perform crypto functions on data and returns data. Examples of this are smart cards, HSMs, TPMs and TPM Equivalents, the iPhone has a TPM Equivalent and that is used for the Keychain. By chance my wife and I were discussing this very topic yesterday. :-)
As far as I know, for encryption of bulk data, iOS does use special hardware instructions to aid AES encryption for speed but that would not be considered hardware encryption due to the key being available in software. There is a little guessing here due to the lack of information about the Apple A-series ARM chips, it is true of the Intel chips in Macs.
The client is concerned about safety of the data application uses and stores locally on device (e.g. they want to prevent reading our data files even on jailbroken iPhones). So I wonder - what are the possible ways to ensure data safety on iPhone?
Edit:
I'm thinking about 2 ways of storing data - a bunch of xml files (maximum size - about 1MB) or sqlite database. I'm more inclined to the 2nd variant but still not sure
You might want to check out this article - Protecting resources in iPhone and iPad apps. It talks about a scheme to encrypt app resources at build time, which can then be decrypted when needed by your app. Decryption happens in-memory so unprotected temporary files are not left on the filesystem. You can even load encrypted HTML, PDF & images straight into a UIWebView.
For transparency's sake: I wrote that article and it is hosted on my own website.
Any time code is running on physical hardware that's out of your control, it is vulnerable - the iPhone must have the ability to decode the data for it to be usable, and if the iPhone has that ability, so does the user. If the data is valuable enough, someone will break your encryption.
The movie industry spent millions on their DVD DRM. It got cracked in a few weeks.
The commoncrypto library, available on the phone, supports symmetric encryption. You can store the key in the keychain, which is itself asymmetrically encrypted. The key to decrypt the keychain is baked into the hardware so you'd need to go to some lengths to retrieve the data.
(e.g. they want to prevent reading our data files even on jailbroken iPhones). you may use localytics mobile analytics(open source) to find out whether the application has been used in Jail broken iphone or not.. They have premium options also..Lot of mobile analytics are available.you can check..