Disclaimer: as I don't know apple architecture well, I won't answer the "how could", only the "could someone" question and add some ideas about how you should make an app that uses encryption.
Found in https://stackoverflow.com/questions/25747327/securing-data-using-core-data-in-ios :
Core Data makes no guarantees regarding the security of persistent
stores from untrusted sources and cannot detect whether files have been
maliciously modified. The SQLite store offers slightly better security than
the XML and binary stores, but it should not be considered inherently
secure. Note that you should also consider the security of store
metadata since it is possible for data archived in the metadata to be
tampered with independently of the store data. If you want to ensure
data security, you should use a technology such as an encrypted disk image.
Basically, you can't (and shouldn't) trust that core data is secure.
That means that you should expect someone could both modify and access your ciphered text.
Also, if you rely on no one discovering your algorithm (security through obscurity) to secure something, you'll have a bad time.
Finally, I would suggest using a tried-and-true method:
- user enters a password
- you take the sha 256 checksum of [password + some pseudo-random number (called salt)]
- use this as your key
- (de/en)crypt the text with AES, using the key you generated.
Conveniently sha256 gives us 256bits, and AES needs a key of 128, 192 or 256bits.
The salt should be something you can easily calculate, like another hash of the password or that is stored alongside the file. (makes it a bit more annoying to bruteforce)
Voila, your data is secured, the only* way to decypher it is to either crack AES (probably not anytime soon), or know/bruteforce the password.
A way to slow down bruteforce is to use a pepper, a small number randomly generated each time the user uses his password, it is added to the salt.
The way it works is that you try every pepper until you find the one that unlocks the file, that is "slow" (if you have 16 possible peppers, you try on average 8 times before getting the file open, but with the wrong password, you try all 16 before figuring out) but fast enough so that the user doesn't notice, with something like a pepper size of 8bits (0-255) it may take 1/10s, that is really painful for a bruteforce attack on the password, but not really slow for the user.
to slow down again, you can use multiple rounds of the hash algorithm you chose. e.g. hash(hash(hash(password+salt)))
I'm not sure if it matters in this case, but just to be sure use sha256 instead of md5.
Instead of rolling your own version of a Key derivation function by concatenating a salt with the password and applying multiple times the hash, use an already made one such as PBKDF2. to do that, use PBKDF(password,salt,Number of iterations), the greater the size and entropy of the salt, and the greater the number of iterations, the better.
