Chiave crittografica Archiviazione e crittografia a virgola mobile

1

Sto lavorando su un'applicazione web in cui ho bisogno di crittografare alcuni campi in base alla configurazione dell'utente e visualizzare le informazioni decodificate. I valori dei campi possono essere di testo o interi o float.

Stiamo pianificando di utilizzare AES-128 ma non sono sicuro del numero di chiavi da utilizzare. Ciò che intendo è che l'applicazione ha attività che possono contenere dati sensibili che devono essere crittografati. È meglio avere una singola chiave per l'intera applicazione o generare chiavi per attività? Inoltre, qual è la migliore pratica per la memorizzazione delle chiavi? Dovrebbero essere memorizzati nello stesso database o in un archivio di valori-chiave dedicato?

A livello di proof of concept, come gestire la crittografia per i numeri in virgola mobile? Ho provato a convertire in stringhe e riconvertirle in float, ma i database danno problemi di precisione.

    
posta Avnish 17.03.2015 - 13:32
fonte

1 risposta

3

La crittografia funziona su sequenze di bit. Può crittografare tutto ciò che può essere rappresentato come bit. Non può crittografare tutto ciò che non è stato convertito in bit. Fortunatamente, qualsiasi cosa in un computer, per definizione, è, a un certo livello, una sequenza di bit.

La conversione di interi in virgola mobile in bit e viceversa è una cosa comune da fare, soggetta ad alcuni standard come IEEE 754 . Alcuni linguaggi di programmazione offrono già funzioni per effettuare tale conversione in un modo deterministico e ben definito che massimizza l'interoperabilità; per esempio. in Java .

Per quanto riguarda la gestione delle chiavi ... il punto più importante da comprendere è che la crittografia non è una sorta di salsa di sicurezza magica che migliora la sicurezza semplicemente applicandola più o meno generosamente. La crittografia non crea crea riservatezza; si concentra . Supponiamo che tu abbia una parte (forse grande) di dati D , che vuoi mantenere riservata anche contro le persone che possono sbirciare i dati in cui sono archiviati. Criptando D (se fatto correttamente) con un tasto K , hai ridotto il problema di riservatezza a quello di K : se gli attaccanti non possono vedi K , quindi non saranno in grado di vedere D anche se vedono la versione criptata di D . Ma devi ancora pensare a come mantenere K fuori dalla portata di questi aggressori.

Ad esempio, se i tuoi attaccanti possono fare un dump del tuo database, pieno di dati che sono stati crittografati con K , e K è anche memorizzati nel database, quindi la crittografia era totalmente inutile. La crittografia può avere senso solo nella misura in cui la chiave può essere mantenuta fuori dalla portata degli aggressori attraverso altri metodi (ovviamente, essendo la chiave piccola e non cambiando spesso, rende più semplice tale compito). Altrimenti, la crittografia di tutti i dati diventa, in effetti, una danza elaborata che trascorrerà i cicli della CPU, aumenterà i costi di sviluppo e accontenterà i revisori dei conti, senza in effetti rendere le cose più sicure.

La crittografia è uno strumento, non un obiettivo. Non crittografare perché vuoi crittografare (beh, sfortunatamente, la crittografia viene spesso applicata per quella ragione esatta). Si crittografa perché, all'interno di un determinato modello di sicurezza , si è determinato che esiste un problema di riservatezza per i dati archiviati o trasferiti e la crittografia può aiutare a ridurre tale rischio spostando matematicamente grandi blocchi di hardware e software fuori dalla finestra di esposizione. Il modello e l'architettura del sistema diranno chi (in termini sia di persone che di componenti di sistema) accederà ai dati e chi no; in altre parole, dove la chiave di crittografia / decrittografia dovrà essere conosciuta; questo, a sua volta, implica quale tipo di gestione delle chiavi è necessario (numero di chiavi, ciclo di vita delle chiavi ...).

    
risposta data 17.03.2015 - 13:56
fonte

Leggi altre domande sui tag