Come implementare correttamente AES in un'applicazione di backup

Naviga le tue risposte
4

Sto scrivendo un'applicazione di backup che dovrebbe avere la caratteristica di crittografare il back-up. Deve crittografare i dati dei file, i percorsi e i nomi dei file. L'applicazione viene scritta in C # (.NET). L'obiettivo sono i sistemi Windows, ma potenzialmente anche altre piattaforme sotto Mono.

Sembra che AES dovrebbe essere usato con un'istanza della classe RijndaelManaged. Le funzioni di crittografia e decrittografia possono essere fornite con un IV, una chiave segreta e, naturalmente, i dati.

L'utente immetterà una password o una passphrase di qualsiasi lunghezza. Saranno avvisati di scegliere qualcosa di ragionevole, come tra 8 e 50 caratteri. La password verrà memorizzata sotto forma di hash. Non sono ancora sicuro se questo sarà scrypt o bcrypt o qualcosa del genere. Anche se il back-up può essere decodificato con questo, almeno la password originale non sarà conosciuta.

  1. Qualsiasi espansione necessaria per ottenere una chiave con cui AES può lavorare è fatta da AES stesso, giusto? O devo espandere l'input (con qualche funzione sicura?) Ad una lunghezza della chiave che AES accetta da solo?
  2. Sia la versione IV che la chiave devono essere uguali durante la crittografia e la decrittografia per decrittografare i dati con successo. La chiave è sempre la stessa. Cosa dovrebbe essere l'IV?
    Immagino che l'IV potrebbe essere un numero progressivo, il che farebbe sembrare la crittografia casuale anche quando i dati e la chiave sono identici, in modo che trapelino meno informazioni possibili. Questa affermazione è giusta? Ciò significa che una buona IV sarebbe l'ID del file (tutti otterranno un numero univoco, o almeno che potrebbe essere generato)?
  3. Viene mantenuto un metafile che associa il percorso e gli ID del file al percorso e al nome file originali. Ad esempio il percorso 1, il file 3 potrebbe espandersi in C: \ Windows \ explorer.exe. Questo metafile sarà probabilmente in chiaro, solo i valori (percorso e nomi di file) verranno crittografati. Quale dovrebbe essere l'IV per i valori? Il loro id numerico? O un valore casuale che viene memorizzato da qualche parte in testo normale? Oppure posso usare un IV fisso (con hard-coding)?
  4. C'è qualcosa che dovrei sapere quando si esegue (o si tenta di eseguire) l'applicazione in Mono? Posso contare su qualsiasi fonte di pseudo-casualità per avere abbastanza entropia?
  5. AES fornisce l'integrità per impostazione predefinita o devo memorizzare un MAC (o qualcosa) di ogni pezzo di dati crittografato (metadati e dati di file)?

Se conosci la risposta a una di queste domande, qualsiasi aiuto è molto apprezzato!

    
posta Luc 27.01.2013 - 23:03
fonte

2 risposte

4

Questo ... non lo farà. AES è un mattone. Vuoi una casa completa. Non saprai se la costruzione è robusta finché il tetto non cade sulla tua testa.

Risponderò alle tue domande per motivi di conoscenza, ma, in realtà, non progettare la tua crittografia personale:

  1. AES funziona con chiavi di 128, 192 o 256 bit. Tutte le lunghezze chiave sono equivalenti (ad esempio "non possono essere infranti con la tecnologia esistente"). Scegli 128 bit se sei intelligente, 256 bit se hai bisogno di placare le persone, 192 bit se vuoi sembrare un coglione.

  2. I requisiti su IV dipendono dal modo in cui utilizzi AES - la modalità di funzionamento che trasforma AES in qualcosa di utile Di norma, mai riutilizzare un IV con la stessa chiave. Mai. Alcuni modi solo bisogno di (IV unico), altri hanno bisogno di IV casuale, uniforme.

  3. Hai usato "fixed" e "IV" nella stessa frase. Per questo sarai frustato nella piazza della città.

  4. .NET include System.Security.Cryptography.RNGCryptoServiceProvider , che va bene per produrre casualità di cripto-qualità. Anche Mono ce l'ha. La documentazione di Mono afferma che verrà utilizzata su Linux /dev/random , con un fallback su /dev/urandom se il primo non è disponibile; fortunatamente, il codice sorgente Mono fa la cosa intelligente e non implementa ciò che dice la documentazione: invece, Mono usa /dev/urandom e passa a /dev/random solo come fallback.

  5. AES è un algoritmo di crittografia; ha riservatezza , non integrità . Alcune modalità di funzionamento fanno entrambe le cose. Altri no.

Naturalmente, qualsiasi sistema di backup sufficientemente grande e complesso perde molte informazioni ovunque (dimensione dei file, dimensione del file nomi , date e modelli di modifica ...) a meno che non venga gestito con un molta cura Questo è un problema difficile. Creando un volume crittografato (ad es. Con TrueCrypt ) e scrivendo file su quel volume, avresti almeno una possibilità non microscopica di eludere i problemi più comuni. E ti farebbe risparmiare anche molto tempo di sviluppo.

    
risposta data 30.01.2013 - 01:20
fonte
4

Prima di tutto; non dovresti implementare i tuoi schemi crittografici. Sì, stai utilizzando AES, ma AES è un primitivo crittografico crittografico. Prova a trovare una soluzione esistente, ben collaudata e revisionata. Probabilmente non sei un crittografo esperto e in quanto tale probabilmente commetterai degli errori. Alla luce di questo disclaimer, ecco cosa posso ricordare su AES:

  1. Se ricordo bene, dovrai lavorare per far sì che la chiave sia 128, 192 o 256b. Solitamente sotto forma di hashing, ma dovrei controllarlo.
  2. L'IV dovrebbe essere crittograficamente casuale.
  3. Genera un IV univoco per ogni nuova crittografia e memorizzalo da qualche parte.
  4. Pass, il sistema operativo dovrebbe essere in grado di fornire entropia ragionevole - Linux di solito ha / dev / random per questo scopo.
  5. AES non fornisce alcun controllo di integrità da solo; in quanto tale, dovrai implementare il tuo controllo di integrità.
risposta data 28.01.2013 - 00:54
fonte

Leggi altre domande sui tag

Progettazione concettuale del programma di scansione delle vulnerabilità nella rete di vendita globale (PCI DSS) I backup di volumi TrueCrypt con frasi di passaggio diverse rappresentano un rischio per la sicurezza?