Linux, TRESOR e XTS

Question

Linux, TRESOR e XTS

#1 da (2 voti)

24

Voglio passare dall'uso di LUKS per la crittografia completa del disco a TRESOR . TRESOR tenta di prevenire gli attacchi di avvio a freddo memorizzando la chiave di crittografia nei registri della CPU. Usa l'API crypto del kernel per cose come ottenere IV e usare una modalità come XTS. Tuttavia, la chiave effettiva viene richiesta una volta che il kernel si avvia e tutte le chiavi passate al codice tramite l'API crypto in seguito vengono ignorate.

Quando si utilizza la modalità XTS, la chiave viene solitamente divisa in due metà e una viene utilizzata come chiave effettiva e l'altra per generare IV. Ma poiché TRESOR ignora tutte le chiavi, il kernel finisce usando due chiavi AES identiche. Da ciò che posso raccogliere da questa domanda e i documenti collegati lì, XTS è vulnerabile a un attacco di testo cifrato scelto quando usato in quel modo.

Questo può diventare un problema nella pratica? E quali modalità di funzionamento posso usare invece? Dal punto di vista del codice, sembra che cbc-essiv abbia anche bisogno di fornire la propria chiave.

linux encryption disk-encryption dm-crypt

posta twisted_pear 13.10.2014 - 00:12

fonte

1 risposta

Leggi altre domande sui tag linux encryption disk-encryption dm-crypt

Se DNSSEC è così utile, perché la sua distribuzione non esiste per i domini principali? Come dirottare una sessione?

score 2 · Answer 1

Probabilmente questo diventerà un problema se si tenta semplicemente di usare tresor-xts-plain o tresor-xts-plain64. Anche se non l'ho testato estesamente, anche quando ho provato TRESOR anche con cbc-essiv, è risultato in un sistema non funzionante. Funzionava solo cbc-plain, che usa una sola chiave. Il modo in cui utilizzo personalmente TRESOR è con tresor-cbc-plain incatenato con serpent-xts-plain64. Presumo che se qualcuno esegue un attacco a freddo contro di me e riesca a ottenere la chiave del serpente non sarà in grado di eseguire attacchi di malleabilità contro il cbc-plain, perché gli attacchi a freddo non sono particolarmente invisibili. Mentre ci sono alcuni altri punti deboli con cbc, la riservatezza è in genere ancora mantenuta.

Tuttavia, potrebbero esserci soluzioni alternative. C'è una patch per l'hypervisor BitVisor, chiamata TreVisor che può utilizzare TRESOR con chiavi XTS. Non ho letto la patch estensivamente. Forse esaminare la funzione tresor_xts_crypt() potrebbe fornire alcune informazioni. La sua pagina principale è qui , nel mezzo.

C'è anche RamCrypt , che usa TRESOR per crittografare la memoria pagine di singoli processi. Usa la modalità operativa XEX, che è simile a XTS (usa anche tweak keys, ma il tweak key è lo stesso della chiave dati). La funzione ramcrypt_page_crypt() potrebbe essere un buon punto di partenza. La sua pagina principale è qui .

TreVisor, almeno, ha una soluzione intelligente per questo problema. Poiché la modalità XTS richiede una chiave extra, la chiave tweak, TreVisor utilizza semplicemente una chiave della metà della dimensione (128 bit anziché 256) per la crittografia e utilizza i 128 bit liberi per memorizzare la chiave tweak. Credo che RamCrypt faccia qualcosa di simile. Visualizza le macro read_key_0 e read_key_1 e l'argomento up per le macro encrypt_block e decrypt_block nella patch TreVisor.