views:

95

answers:

3

I am working on an application which has got some sensitive information. I am aware that it would be difficult for a layman to hack into iphone to get the information. If I use SQLite directly I have something called SQLite Cipher to encrypt / encode the database.

Is there anyway where I can have the same way of encrypting the coredata so it makes it hard for hackers to get into the data.

Can someone shed some light on this?

Thanks in Advance

+1  A: 

The Core Data Programming Guide says explicitly that the SQL store type is a little more secure than XML or binary, but is not inherently secure - it recommends an encrypted disk image. Unfortunately, that's a little hard to manage on the iPhone.

What you might consider, if this is a real concern for you, is to build your own persistent store type - the Guide has a section on creating your own atomic store, and refers you to the Atomic Store Programming Topics document. Build a store that takes some key from a user prompt at startup, then initializes with that key for encryption and decryption purposes. (Note that if you take this route, the NSPersistentStore class reference says that subclassing NSPersistentStore directly is not supported in Core Data - you should subclass NSAtomicStore instead.)

Tim
+1  A: 

If someone is using a jail broken iphone there is absolutely nothing you can do. The functions you are using for encryption and decryption can be hooked to obtain the key/iv used. You can also do nasty things like do full dumps of the flash, keyboard buffer, and other "debug" info.

To make things more difficult you can limit the amount of time a secret is stored on the device. Store secrets on a remote system and transfer them via ssl, delete them when you don't need it. This protects against someone stealing the iphone, jail breaking it, and then dumping the database. I'm not sure if this is an attack that threatens your specific application.

In terms of a "layman" (people who can't read? :) Then you don't have much to worry about. Apple has protection in place to keep installed apps from reading/writing to each others resources.

Rook
A: 

You can add a category for an entity, which overrides reading and writing values to the persistent store. You can then hook into CommonCrypto routines for private- and public-key encryption and decryption of those values as they are stored and retrieved by your application.

Alex Reynolds