

Securing Data in iOS  - twelsonrossman
http://blog.chariotsolutions.com/2012/04/securing-data-in-ios.html

======
DenisM
If you're rolling your own you still need to solve the problem of key
management, which is not mentioned in the article. Simply storing they key
next to data will accomplish nothing. For that I would recommend one of few
approaches:

1\. Using iOS keychain. The nice thing about it is that it's transparent to
the user and easy to explain - "we store it he same way Mail app stores your
email password".

2\. Asking the user to enter a pass phrase and use it as an encryption key.
The key here is to resist the urge to hash the phrase to turn it into a key,
and instead use a well known key derivation function for the same purpose.

~~~
sjlo
The keychain is really great for convenience, though it is dependent on the
iOS passcode. Users are free to setup their phones without one, use a weak
pin, etc. It's exceedingly rare to see an iOS user with a strong multi-
character passphrase. For enhanced security there is really no substitue for a
suitably long/strong passphrase.

With regard to the second point, one added benefit of SQLCipher over a roll-
your-own solution is that SQLCipher automatically applies PBKDF2 derivation.
It handles most of the security under the hood so that the application doesn't
need to worry about it.

~~~
brettm
On iOS keychain access is not dependent on the passcode. Each application has
access to its own keychain and cannot access the keychain for other
applications. The keychain will still be encrypted even if there is no
passcode set.

~~~
sjlo
Perhaps my comment wasn't clear. I agree that its not possible for one
application to access another's keychain items. However, this isn't the only
attack risk, and access to keychain items in general is based on the passcode.
This can be a problem if weak passcodes are used and an attacker can get
access to the device. There are some relevant comments in this paper:
[http://sit.sit.fraunhofer.de/studies/en/sc-iphone-
passwords-...](http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-
faq.pdf)

~~~
brettm
I agree that this could be a problem but in this paper in order for the attack
method to work the developer of the App would need to explicitly set the
keychain attribute with the flag "kSecAttrAccessibleAlways", making the
keychain data available even when the device is locked, "Otherwise the
credentials of the app are not affected by the attack method."

~~~
sjlo
Section 2.15 deals with the conditions under which the Keychain should be
considered secure:

 _\- Items are stored with a protection class that makes them only available
when the device is unlocked. (see Section 2.14) \- A strong passcode of 6
alphanumeric digits is enforced (reduces the risk of brute-force attacks)_

The second point is as relevant as the first. The paper goes on to say:

 _according to [App10b]: ... The standard simple code of 4 numeric digits
would be brute-forced in less than 9 minutes. Based on the assumption that the
counter for wrong tries in the iOS can be bypassed, as it is not hardware-
based. [BS11b] provides a tool for passcode bruteforce attacks._

Forensic toolkits, like the one from Elcomsoft
(<http://www.elcomsoft.com/eift.html>), are able to recover numeric pass codes
and extract data in less than an hour, even on newer devices.

With a weak passcode, which most people use, the keychain does not offer much
protection against dedicated attackers with device access.

