Reinstallare l'OS criptato coprirà i vecchi dati?

[TommyB1992]

Se reinstallo ubuntu criptando l'hd (attualmente non lo è), è assicurato che i vecchi dati non siano più "estraebili"?

[wilecoyote]

Salve, alquanto criptica anche la domanda.

Vediam se ho capito bene, hai un HDD di cui vuoi far sparire i vecchi dati, vuoi riformattarlo per sovrascriverli, però diffidi della sufficienza di ciò, ergo vuoi pure criptarlo.

Col dovuto rispetto la ritengo una paranoia da complottista.

Oltreché inutile, se lo decripti ed accedi, con un appropriato programma di recupero comunque li recuperi.

Molto meglio far tabula rasa col comando dd:

Codice: Seleziona tutto

sudo dd if=0 of=/dev/sdx bs=1

Sostituire la x colla lettera del HDD da trattare.

Codesto comando porrà a zero ogni bit del HDD, letteralmente, mettendoci un tempo mostruoso, non preconizzabile dipendendo dalle dimensioni del HDD e prestazioni del computer, dato che opera bit per bit.

Ciao

P.S. se colla lettera per errore indicherai il HDD di sistema, commetterai Una cagata pazzesca !…

[TommyB1992]

Oltreché inutile, se lo decripti ed accedi, con un appropriato programma di recupero comunque li recuperi.

Tecnicamente come fa qualcuno a decriptarlo ed accedere se io non gli fornisco la password?
Grazie

[DoctorStrange]

A questo scopo, consiglio di studiare ed usare un comando appositamente sviluppato per rendere irrecuperabili file personali. Si chiama shred
Dovrebbe essere incluso nel kernel di base.

[GjMan78]

Se reinstallo ubuntu criptando l'hd (attualmente non lo è), è assicurato che i vecchi dati non siano più "estraebili"?

No, assolutamente.

Inoltre lasciare dati cancellati ma recuperabili sul disco può compromettere la sicurezza della crittografia per questo è buona norma prima di crittografare un disco o una partizione sovrascriverla con dati random anche più di una volta. O come dicono oltreoceano "one or more time as your paranoia require".

In genere si usa dd if=/dev/urandom ... per sovrascrivere i dati prima di una full-disk-encryption.

[TommyB1992]

No, assolutamente.

Inoltre lasciare dati cancellati ma recuperabili sul disco può compromettere la sicurezza della crittografia per questo è buona norma prima di crittografare un disco o una partizione sovrascriverla con dati random anche più di una volta. O come dicono oltreoceano "one or more time as your paranoia require".

In genere si usa dd if=/dev/urandom ... per sovrascrivere i dati prima di una full-disk-encryption.

Quindi come dovrei procedere?
Da cd/usb live mando il comando più volte, e poi reinstallo criptando il tutto, è corretto?

[GjMan78]

Corretto.

Codice: Seleziona tutto

sudo dd if=/dev/urandom of=/dev/sdX bs=8M status=progress

L'opzione status=progress serve ad avere almeno un'idea dell'avanzamento del task e di quanto manca alla fine.

bs=8M imposta il block size a 8 mega, dovrebbe velocizzare il processo quando si lavora con gli hard disk.

Mi raccomando scegli bene il disco di destinazione, altrimenti sono guai.

[Filoteo]

Inoltre lasciare dati cancellati ma recuperabili sul disco può compromettere la sicurezza della crittografia

Mmmmmh, fonte? Come potrebbe? Inoltre sovrascrivere i dati è lento e se trattasi di un SSD sottopone a usura inutilmente (secondo me).

[GjMan78]

Inoltre lasciare dati cancellati ma recuperabili sul disco può compromettere la sicurezza della crittografia

Mmmmmh, fonte? Come potrebbe? Inoltre sovrascrivere i dati è lento e se trattasi di un SSD sottopone a usura inutilmente (secondo me).

https://wiki.archlinux.org/title/Dm-cry ... reparation

Before encrypting a drive, it is recommended to perform a secure erase of the disk by overwriting the entire drive with random data. To prevent cryptographic attacks or unwanted file recovery, this data is ideally indistinguishable from data later written by dm-crypt.

https://wiki.archlinux.org/title/Securely_wipe_disk

To prepare a drive for block device encryption inside the wiped area afterwards, it is recommended to use #Random data generated by a cryptographically strong random number generator (referred to as RNG in this article from now on).

See also Wikipedia:Random number generation.

Warning: If block device encryption is mapped on a partition that contains non-random or unencrypted data, the encryption is weakened and becomes comparable to filesystem-level encryption: disclosure of usage patterns on the encrypted drive becomes possible. Therefore, do not fill space with zeros, simple patterns (like badblocks) or other non-random data before setting up block device encryption if you are serious about it.

Riguardo agli SSD attuali non penso che un ciclo di scrittura di dati ne accorci la vita in maniera drastica, comunque nel link sopra ci sono accorgimenti specifici che non conoscevo.

[Filoteo]

To prevent cryptographic attacks or unwanted file recovery, this data is ideally indistinguishable from data later written by dm-crypt.

A meno che l'utente non sia Snowden o un dirigente di multinazionale, non vedo alcun rischio concreto nel poter distinguere blocchi di dati criptati con chiave nuova piuttosto che precedente. Se la chiave era robusta in principio, il recupero dei file è già da escludere. Oltremodo su un SSD una volta attivato il TRIM la posizione dei blocchi criptati diventa subito evidente, vanificando del tutto la cancellazione preparatoria https://asalor.blogspot.com/2011/08/tri ... blems.html

[GjMan78]

To prevent cryptographic attacks or unwanted file recovery, this data is ideally indistinguishable from data later written by dm-crypt.

A meno che l'utente non sia Snowden o un dirigente di multinazionale, non vedo alcun rischio concreto nel poter distinguere blocchi di dati criptati con chiave nuova piuttosto che precedente. Se la chiave era robusta in principio, il recupero dei file è già da escludere. Oltremodo su un SSD una volta attivato il TRIM la posizione dei blocchi criptati diventa subito evidente, vanificando del tutto la cancellazione preparatoria https://asalor.blogspot.com/2011/08/tri ... blems.html

Traduco la tua citazione

Per prevenire attacchi crittografici o recupero di file indesiderati, questi dati [sovrascritti con dati random] sono idealmente indistinguibili dai dati scritti successivamente da dm-crypt.

Quanto citato risponde esattamente al quesito di apertura della discussione: criptare il sistema è sufficiente ad impedire il recupero dei dati?
No, non lo è. Perché non parliamo di sovrascrivere dati criptati, ma dati ancora in chiaro che potrebbero essere facilmente recuperati.

Che poi sovrascrivere i dati con pattern random renda o meno la crittografia più robusta è un bonus in più rispetto al quesito originario.

Concordo sul fatto che al 99% dell'utenza basti criptare la partizione per essere al sicuro, ma se qualcuno vuole un layer di sicurezza in più perché è paranoico oltre la media non vedo perché non lo si debba informare sui metodi utilizzabili.

[Filoteo]

dati ancora in chiaro che potrebbero essere facilmente recuperati.

Oops, avevo accidentalmente letto come se l'OS precedente fosse anch'esso criptato.

[GjMan78]

dati ancora in chiaro che potrebbero essere facilmente recuperati.

Oops, avevo accidentalmente letto come se l'OS precedente fosse anch'esso criptato.

[TommyB1992]

Ok ho seguito il comando, e poi reinstallato il tutto.

Sfortunatamente ho visto che però per USB non funziona:

Codice: Seleziona tutto

tomas@tomas-tobefilledbyoem:~$ sudo dd if=/dev/urandom of="/media/tomas/LUBUNTU 20_" bs=8M status=progress
dd: apertura di '/media/tomas/LUBUNTU 20_' non riuscita: È una directory

In questo caso come procedo?

[GjMan78]

Nel campo of non devi mettere il punto di mount, ma quello del dispositivo o della partizione.

Per capire quale sia il device giusto puoi usare il comando

Codice: Seleziona tutto

lsblk -e7

Mettiamo che ad esempio volessi scegliere la partizione sdb3 il parametro of corretto sarebbe of=/dev/sdb3

Se volessi sovrascrivere tutto il disco invece userei of=/dev/sdb

[Darren]

DD sovrascrive i dati come qualunque altro software.
Quello che fa aumentare la “Sicurezza” è il numero di passaggi.

Piu volte sovrascrivi il disco e minore è la possibilità che i dati si riescano a recuperare.

Ovviamente il tempo richiesto è maggiore, e dipende da cosa davvero vuoi non fare trovare…

Lo Standard DoD stabilisce in 7 passaggi per una cancellazione sicura

Ormai peró con gli SSD si è dovuto creare altri metodi per “Sanificare” i dischi.

[kessler]

Sovrascrivere un SSD con dd equivale a ridurre i cicli di scrittura delle celle, e quindi la vita utile del supporto.

C'è una paginetta sul wiki di Arch che spiega come comportarsi per "sanitizzare" un SSD Sata e Nvme:

https://wiki.archlinux.org/title/Solid_ ... l_clearing

Raccomando di leggerla bene tutta, specialmente i warning, prima di passare all'azione...

[woddy68]

Ho letto tutto e mi sembra corretto ma credo che quell'operazione abbia senso quando devi buttare il disco o venderlo ovviamente , oppure se hai commesso reati e quindi paura della polizia informatica (solo un' ipotesi), altrimenti si è proprio ai limiti della paranoia.

[wilecoyote]

Salve, e se l'eliminazione dei dati è così fondamentale pella tua sicurezza, puoi sempre dissolvere il HDD/SSD coll'Acqua Regia.

Ciao

[tokijin]

Salve, e se l'eliminazione dei dati è così fondamentale pella tua sicurezza, puoi sempre dissolvere il HDD/SSD coll'Acqua Regia.

Ciao

viewtopic.php?p=5352620#p5352620