Non crittografare il disco rigido, ma rendere impossibile modificare le cose senza una password?

1

Recentemente ho acquistato un'unità SSD e mi sono reso conto che la mia CPU (Celeron 1007U - non ha istruzioni AES) non può continuare a crittografarla e l'SSD non ha la crittografia hardware integrata. Questo mi ha fatto capire che se volevo utilizzare tutta la potenza disponibile, ho bisogno di rinunciare alla crittografia di ogni blocco HDD.

Dopo un po 'di riflessione, mi sono reso conto che avrei potuto mantenere la mia partizione "a prova di manomissione" se mantenesse i dati di integrità (checksum) su un volume separato che è crittografato - in quel caso i dati sarebbero comunque visibili ma l'attaccante non sarebbe in grado di cambiarlo Escludendo i problemi relativi alla memorizzazione del bootloader, il mio pensiero è corretto? Avrebbe davvero la possibilità di farmi utilizzare 500MiB / s su questo processore se l'SSD lo supporta? Se sì, conosci qualche progetto Linux che mi consenta di farlo (filesystem, plug-in di mappatura dei dispositivi o funzioni LVM)?

    
posta d33tah 01.03.2016 - 10:34
fonte

2 risposte

2

Ciò che stai chiedendo non è raggiungibile per diversi motivi.

Problema 1: quale dimensione dei blocchi dei dati corrisponderebbe a un singolo tag di autenticazione?

  • La dimensione del blocco è la più piccola per SSD che è 4K. I tag sono più piccoli, 256 bit o giù di lì e si presume che vengano memorizzati anche su SSD. Ciò porta alla scrittura dell'amplificazione sul lato di SSD contenente i tag di autenticazione, a meno che le scritture non siano entro i limiti di 512 K (mezzo megabyte). Il numero deriva dal fatto che un blocco 4K può contenere 128 tag, quindi un blocco 4K pieno di tag corrisponde a 128 blocchi di dati, ciascuno di 4K.
  • Le dimensioni dei blocchi sono nuovamente 4K, ma ogni tag di autenticazione occupa anche 4K. Ciò annulla l'amplificazione della scrittura, ma la memorizzazione richiesta per i tag è la stessa dei dati, il rapporto è 1: 1. Terabyte di dati viene fornito con un terabyte di tag di autenticazione.
  • La dimensione del blocco è più grande. Ciò comporta meno spazio necessario per i tag di autenticazione. Il blocco dati più grande diventa il minor spazio utilizzato per l'autenticazione, ma allo stesso tempo è necessario elaborare più dati per calcolare i tag. Ciò porta ad un effetto simile all'amplificazione della scrittura.

Problema 2: l'hash è più costoso dal punto di vista computazionale della crittografia.

  • Gli algoritmi di hash utilizzati in crittografia in passato come SHA1 erano molto più costosi in termini di cpb. L'hashing moderno come SipHash e un altro russo che non posso nominare dalla memoria stanno diventando molto vicini ai flussi di codice ma sono ancora al di sopra di essi. Non diventeranno più economici di cifre.
  • I codici a blocchi potrebbero essere utilizzati per l'autenticazione. Ad esempio, è possibile utilizzare la modalità LRW, ma in tale schema ogni blocco di dati passa attraverso due operazioni di crittografia a blocchi. Quindi non sarà "più economico della crittografia".
  • I codici di streaming non possono essere utilizzati per l'autenticazione.
risposta data 05.03.2016 - 02:17
fonte
0

Come puoi essere sicuro che l'integrità dei dati sia effettivamente utilizzata?

Se un utente malintenzionato può scrivere su dati arbitrari e ottenerne la lettura, come puoi essere sicuro che l'autore dell'attacco non abbia modificato il tuo kernel per ignorare semplicemente l'assenza di corrispondenza dei dati?

Non ho una conoscenza approfondita del controllo dell'integrità dei dati del kernel, ma se l'utente malintenzionato potrebbe in qualche modo disattivare il controllo dell'integrità dei dati, o modificarlo in qualche modo, il controllo non avrebbe importanza.

    
risposta data 01.03.2016 - 17:23
fonte

Leggi altre domande sui tag