Se inserisco dati crittografati nei dati di base su iOS o macOS, come potrebbe un hacker decifrarlo?

2

Supponiamo di aver creato un'app che consenta a un utente di immettere testo semplice e crittografarlo con una password. Quindi l'app memorizza il testo cifrato nei dati principali. L'utente può selezionare un "file", inserire la stessa password per decodificarlo, quindi visualizzare il testo semplice (ma si spera non sia il testo cifrato). Se viene inserita la password errata, l'app non tenterà di decodificare il testo cifrato.

  1. Come potrebbe uno acquisire e visualizzare il testo cifrato? È possibile? Mi aspetto che questo sia di grande aiuto per chi cerca di scoprire l'algoritmo o decodificare il testo cifrato.
  2. Come è possibile alterare il testo cifrato in modo che possano tentare di decrittografarlo per saperne di più sull'algoritmo? È possibile modificare i dati di base di un'app senza utilizzare le funzioni di aggiornamento integrate dell'app?

Supponiamo che né la password, né il testo normale né il testo cifrato siano inviati su una rete.

Mi aspetto che dovrei fornire maggiori dettagli. Fammelo sapere.

    
posta twharmon 10.01.2017 - 15:35
fonte

3 risposte

1

La crittografia può essere utilizzata per proteggere dalla manomissione anche con attacchi offline . La crittografia moderna che non rileva la manomissione e si basa sulla segretezza dei suoi algoritmi dovrebbe essere considerata interrotta ed è essenzialmente inutile. Un moderno crittosistema (ad esempio, AES-GCM) utilizza algoritmi completamente pubblici, è resistente alla crittanalisi differenziale e a prova di manomissione con accesso offline al testo cifrato.

    
risposta data 12.04.2017 - 13:24
fonte
-1

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 è.

    
risposta data 11.01.2017 - 14:34
fonte
-1

È possibile utilizzare solo la crittografia che controlli completamente. Tutto ciò che è "memorizzato" sul computer è in pericolo, quindi il metodo logico consiste nell'utilizzare la crittografia che non è connessa a Internet. Gli strumenti di cifratura della vecchia scuola ora stanno tornando a causa del fatto che i comunicatori controllano ogni aspetto del processo.

Il Galaxy Cipher Instrument è un esempio: Forum di crittografia, Topix.

Gli schemi dovrebbero anche essere schemi non logici come la forma di un filo trovato in un deposito di spazzatura, la linea contorta di un fiume su una mappa, qualsiasi cosa.

C'è un punto su ciascun disco da qualche parte tra i numeri che vengono usati come riferimento per spostare il prossimo disco lontano da. Questo strumento è sicuro anche dalla NSA.

    
risposta data 02.06.2017 - 17:01
fonte

Leggi altre domande sui tag