Dichiarazione di non responsabilità: poiché non conosco bene l'architettura della mela, non risponderò al "come potrebbe", solo alla domanda "potrebbe qualcuno" e aggiungerò alcune idee su come dovresti creare un'app che usi la crittografia.
Trovato in link :
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.
Fondamentalmente, non puoi (e non dovresti) fidarti che i dati di base siano sicuri.
Ciò significa che dovresti aspettarti che qualcuno possa modificare e accedere al tuo testo cifrato.
Inoltre, se non ti affidi a nessuno che scopre il tuo algoritmo (sicurezza attraverso l'oscurità) per proteggere qualcosa, avrai un brutto momento.
Infine, suggerirei di utilizzare un metodo provato e vero:
- l'utente inserisce una password
- prendi lo sha 256 checksum di [password + qualche numero pseudo-casuale (chiamato salt)]
- usa questo come chiave
- (de / en) crypt il testo con AES, usando la chiave che hai generato.
Convenientemente sha256 ci dà 256 bit, e AES ha bisogno di una chiave di 128, 192 o 256 bit.
Il sale dovrebbe essere qualcosa che puoi facilmente calcolare, come un altro hash della password o che è memorizzato insieme al file. (rende un po 'più fastidioso il bruteforce)
Voilà, i tuoi dati sono protetti, l'unico * modo per decifrarlo è quello di crackare AES (probabilmente non molto presto), o conoscere / bruteforce la password.
Un modo per rallentare bruteforce è usare un pepe, un piccolo numero generato casualmente ogni volta che l'utente usa la sua password, viene aggiunto al sale.
Il modo in cui funziona è che provi ogni pepe finché non trovi quello che sblocca il file, cioè "lento" (se hai 16 possibili peperoni, provi in media 8 volte prima di aprire il file, ma con la password sbagliata, provi tutti e 16 prima di capire) ma abbastanza veloce in modo che l'utente non se ne accorga, con qualcosa come una dimensione del pepe di 8 bit (0-255) potrebbe richiedere 1/10, che è davvero doloroso per un attacco bruteforce sulla password, ma non molto lento per l'utente.
per rallentare di nuovo, puoi usare più turni dell'algoritmo di hash che hai scelto. per esempio. hash (hash (hash (password + sale)))
Non sono sicuro che sia importante in questo caso, ma per sicurezza usa sha256 invece di md5.
Invece di eseguire il rollover della propria versione di una funzione di derivazione della chiave concatenando un salt con la password e applicando più volte l'hash, usa uno già creato come PBKDF2. per farlo, usa PBKDF (password, sale, numero di iterazioni), maggiore è la dimensione e l'entropia del sale, e maggiore è il numero di iterazioni, meglio è.