0

I'm storing some sensitive information like passwords etc. in Core Data. I want that my app encrypts the entire SQLite database (it's not very big, < 1 MB) whenever the apps goes into the background or terminates. I figured out the encryption thing itself, but I'm having problems to correctly 'close' and re-open the Core Data stack with the store.

When my apps terminates/goes into the background I do this now:

  • Save the context
  • Remove the store from the coordinator
  • Encrypt the store and save it
  • Delete the store

When my app comes back, I do the following:

  • Decrypt and save the store file
  • Add the store back to the coordinator
  • Reset the context

From what I understood from the docs this should be sufficient, but it doesn't work, as soon as the main view controller tries to do a fetch on the context again my app crashes.

Does anybody know of what is the best way to temporarily remove a store from core data and then add it again?

el3ktro
  • 167
  • 2
  • 9
  • 1
    Can you use iOS's built-in Data Protection entitlements to protect your app's data? This relies on the user having a passcode though. – Mike Weller Feb 02 '13 at 18:45
  • 1
    As of iOS 5, the core data store is already encrypted until the user first enters their passcode. If that's not sufficient, you can request it be encrypted by the system whenever the device is locked by passing a different value for the NSPersistentStoreFileProtectionKey in the options dictionary when creating your persistent store. – Jesse Rusak Feb 02 '13 at 18:45
  • I know about the hardware encryption. The problem is, the database file I'm talking about will also be accessible through iTunes so the user can back that file up. And THIS file won't be encrypted, so I need to encrypt it on the device. – el3ktro Feb 03 '13 at 13:06
  • Even when not talking about the encryption at all. Shouldn't I still somehow correctly save and 'release' the store when the app goes into background? Or would I just save the context and leave it like that? – el3ktro Feb 03 '13 at 13:07

1 Answers1

1

This isn't an answer to your question, but worth saying:

Your encryption strategy is fatally flawed and I seriously recommend that you think up a different scheme.

If data should be encrypted on disk, and is actually worth encrypting, it should never ever be written to disk in a unencrypted state, for these reasons:

  • If the app forcefully quits, or power is removed from the device, the file remains unencrypted on the disk. And then someone could go poking around the disk and find the unencrypted data.

  • Deleting the plain version of the store file is in all likelihood not securely deleting the file, and hence disk analysis/tools could find an unencrypted version of the file.

If you want to encrypt your data when it is written to disk, you have to write encrypted data to disk every time, no exceptions. "It's encrypted some of the time" is no use.

As an alternative strategy, you might want to consider encrypting the data that is stored in core data itself. For example, you might NSArchive your data and encrypt the resulting data bytes before storing them as BLOBs.

occulus
  • 16,959
  • 6
  • 53
  • 76
  • I appreciate your answer, but I can asure you this is NOT what I'm doing with encryption. My question is really just all about how I correctly "close" a Core Data store when the app goes into background and how I can reopen the store again when the app resumes. Is it necessary at all to "close" the store or the managed object context in this case or can I just leave everything as it is when the app goes into background? – el3ktro Feb 04 '13 at 14:29
  • Oh I see, you mean you have an in-memory store which you later on encrypt before writing to disk? – occulus Feb 06 '13 at 14:31