Descargo de responsabilidad: como no conozco bien la arquitectura de Apple, no responderé la pregunta "cómo podría", solo la pregunta "podría alguien" y agregaré algunas ideas sobre cómo debería crear una aplicación que use cifrado.
Se encuentra en enlace :
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.
Básicamente, no puedes (y no debes) confiar en que los datos centrales están seguros.
Eso significa que debes esperar que alguien pueda modificar y acceder a tu texto cifrado.
Además, si no confías en que nadie descubra tu algoritmo (seguridad a través de la oscuridad) para asegurar algo, tendrás un mal momento.
Finalmente, sugeriría usar un método probado y verdadero:
- el usuario ingresa una contraseña
- toma la suma de comprobación sha 256 de [contraseña + algún número pseudoaleatorio (llamado sal)]
- usa esto como tu clave
- (de / en) crypt el texto con AES, usando la clave que generó.
Convenientemente, sha256 nos da 256 bits, y AES necesita una clave de 128, 192 o 256 bits.
La sal debe ser algo que pueda calcularse fácilmente, como otro hash de la contraseña o que se almacena junto con el archivo. (hace que sea un poco más molesto para la fuerza bruta)
Voila, sus datos están protegidos, la única * manera de descifrarlos es descifrar AES (probablemente no en el futuro) o saber / forzar la contraseña.
Una forma de reducir la fuerza bruta es usar un pimiento, un pequeño número generado aleatoriamente cada vez que el usuario usa su contraseña, se agrega a la sal.
La forma en que funciona es que usted prueba todos los pimientos hasta que encuentre el que abre el archivo, que es "lento" (si tiene 16 pimientos posibles, lo hace en promedio 8 veces antes de abrir el archivo, pero con la contraseña equivocada, intente con los 16 antes de descifrar) pero lo suficientemente rápido para que el usuario no se dé cuenta, con algo así como un tamaño de pimienta de 8 bits (0-255) puede tardar 1 / 10s, que es realmente doloroso para un ataque de fuerza bruta en la contraseña, pero no es realmente lento para el usuario.
para reducir la velocidad nuevamente, puedes usar varias rondas del algoritmo hash que elegiste. p.ej. hash (hash (hash (contraseña + sal)))
No estoy seguro de si es importante en este caso, pero solo para estar seguro de usar sha256 en lugar de md5.
En lugar de rodar su propia versión de una función de derivación de clave concatenando un salt con la contraseña y aplicando el hash varias veces, use uno ya hecho como PBKDF2. para hacer eso, use PBKDF (contraseña, sal, número de iteraciones), cuanto mayor sea el tamaño y la entropía de la sal, y cuanto mayor sea el número de iteraciones, mejor.