SSD + TrueCrypt

[tropicana]

Ciao a tutti, scrivo in questa sezione perchè le informazioni che vorrete condividere con me riguardano espressamente l'uso di SSD in generale e non genericamente la criptatura, quindi chiedo ai mod di non spostare in sezione "AV e sicurezza".

PREMESSA:

Vorrei acquistare il mio primo SSD da usare come disco di sistema (Windows 7), ma ho necessità di criptarlo e vorrei usare TrueCript.

Farei un'unica partizione di sistema grande quanto tutta la dimensione dell'HD e vorrei quindi criptare l'intero sistema operativo/volume.

Ho letto le info nella discussione sugli SSD quindi ho capito con gli SSD bisogna tenere sotto controllo Garbage Collection, TRIM, Wear Leveling, Over-Provisioning e Write Amplification.

Che, per garantire una buona durata di vita dell'SSD, è importante non riempirlo troppo per evitare troppe riscritture sempre sulle stesse poche celle libere e, soprattutto con prodotti SANDFORCE, anche una significativa perdita di prestazioni.

DOMANDE:

1- C'è qualcuno che usa un SSD di sistema criptato con TrueCrypt e mi può confermare che non ci sono problemi?

2- Sul sito di TrueCrypt è scritto esplicitamente che non blocca il TRIM, e questo è un bene, ma per tutte le altre funzioni, qualcuno sa se TrueCrypt potrebbe generare problemi sugli SSD?

3- Io vorrei criptare l'intero volume e non creare un container criptato grande quanto il volume (che verrebbe visto come un unico file che riempie tutto l'HD, cosa negativa per gli SSD, oltre a non permettere poi di potervi installare all'interno un SO).
Nella mia situazione, quindi, l'SSD sarà considerato da subito tutto riempito come nel caso di container criptato, oppure lo spazio vuoto verrà correttamente individuato e quindi utilizzato per la Garbage Collection, Trim, ecc...?

4- Eventualmente, ci sono SSD che soffrono meno in caso di riempimento "importante"?

Ringrazio per tutti i contributi che darete a questa discussione.

P.S. Preciso che non sono interessato a sfruttare sistemi di criptatura proprietaria come BitLocker, eventuali sistemi HW presenti negli SSD o prodotti a pagamento, ma solo software open proprio come TrueCrypt.

[tropicana]

Possibile che non ci sia nessuno che ha l'esigenza di proteggere i dati per esempio di un portatile usato per lavoro?

[zio.luciano]

Originariamente inviato da tropicana

Possibile che non ci sia nessuno che ha l'esigenza di proteggere i dati per esempio di un portatile usato per lavoro?

Eccomi.
L'esigenza di criptare dati o disco di sistema c'è, soprattutto da quando un caro amico mi ha spiegato come funziona BitLocker sul suo notebook aziendale con Win7_Enterprise.
Ho intuito subito che poteva essere una buona cosa da implementare sul mio portatile (lo uso per lavorare, e spesso lo porto in giro), ma su Win7pro non c'è modo di attivare BitLocker; quindi sono alla ricerca di una "soluzione accettabile" (open source preferibilmente, di semplice utilizzo per me e soprattutto robusta) ma al momento non ho trovato nulla.

Criptare l'intero disco con Truecrypt potrebbe essere una buona soluzione; c'è solo da verificare l'impatto reale sulle prestazioni generali e sull'usura dell'SSD.

[bio.hazard]

Originariamente inviato da tropicana

Possibile che non ci sia nessuno che ha l'esigenza di proteggere i dati per esempio di un portatile usato per lavoro?

si certo, solo che sul mio portatile c'è Linux, che in fase di installazione mi fa scegliere, se lo desidero, di criptare la sola home oppure l'intero disco, quindi non mi sono mai dovuto porre il problema di quale software utilizzare, dato che l'opzione di cifratura del disco è già presente di default nel sistema operativo.

[tropicana]

Intanto grazie ad entrambi.

@zio.luciano

Per la questione prestazioni, trattandosi di SSD, qualsiasi degrado porterà a valori sempre di granlunga maggiori rispetto a qualsiasi disco meccanico, quindi non mi preoccuperei di questo aspetto.

@bio.hazard

Il problema degli SSD è dovuto al fatto che in essi agiscono Garbage Collection, TRIM e Wear Leveling, che di fatto spostano i dati in modo assolutamente trasparente all'utente.

Senza dilugarmi troppo, negli SSD non vi è corrispondenza FISICA tra il VOLUME, CRIPTATO o meno che sia, e le celle SCRITTE, come accade invece nei dischi meccanici.

Accade quindi che, nelle varie operazioni svolte automaticamente dal controller per garantire la massima vita a tutte le celle di memoria, parte di dati presenti nel volume criptato verrebbero periodicamente spostati da celle vecchie in celle nuove (per i motivi e il funzionamento di questi spostamenti consultate le specifiche discussioni sull'argomento).

Le nuove celle risulteranno sempre correttamente all'interno del volume criptato, mentre quelle vecchie, che contengono ancora parte dei dati precedentemente criptati, saranno "liberamente" visibili fino a che non verranno realmente riscritte (e, se vogliamo essere proprio precisi, anche dopo essere state riscritte).

Pertanto, l'unico modo per avere realmente un SSD criptato sarebbe:

1- usare un'unica partizione grande quanto tutto lo spazio fisico a disposizione, quindi niente Over-Provisioning manuale

2- criptare l'intero volume

SOLO in questo modo tutte le celle saranno sempre all'interno dello spazio criptato e quindi, anche durante le operazioni di salvaguardia del controller/SO, tutti i dati rimarranno sempre al sicuro.

Criptare solo una partizione dell'SSD, invece, lascerà costantemente parte dei dati criptati (in attesa di riscrittura) liberamente/facilmente visibili.

Questo è solo un accenno del problema che sta alla base della criptatura di un SSD.

Il mio dubbio è:

ammesso che si faccia una sola partizione e che si cripti questa intera partizione, essa viene gestita correttamente?
Cioè vengono correttamente individuate le celle vuote come vuote, e quindi la gestione delle operazioni di salvaguardia della vita dell'SSD funzionano?

Oppure il volume criptato viene visto come un file unico, tipo un file ZIP, e quindi le eventuali riscritture al suo interno avverrebbero fisicamente sempre sulle stesse celle proprio come nei dischi meccanici, portando ad una rapida morte l'SSD?

Capisco che si tratta di un discorso particolarmente settoriale, ma possibile che io sia il primo da tanti anni che ci sono SSD in giro che mi sia posto il problema?

[s12a]

Se con TrueCrypt il trim passa (a detta dei suoi creatori; a me non è mai capitato di verificare) quando lo si usa come soluzione di criptaggio di terze parti per l'intero volume (e non solo come encrypter per file contenitore), non dovrebbero esserci problemi per il wear leveling. Quello che fa il trim è contrassegnare un settore come "non valido", e quindi libero di essere usato dall'SSD per il wear leveling a sua discrezione (in aggiunta allo spazio di overprovisioning di serie). Per convenzione un settore trimmato dal punto di vista del sistema operativo contiene zeri, ma leggendo le memorie in maniera diretta (via hardware) se ne può leggere il contenuto. Tuttavia, se esso è criptato, non se ne può ricavare nulla di utile.

Criptando un volume al limite penso che il garbage collection possa essere meno efficiente in quanto non sarà in grado di determinare in maniera approfondita il contenuto dei settori memorizzati, a differenza di quanto può fare con il criptaggio hardware dell'SSD.

Sarebbe anche da vedere come i dati vengono passati all'SSD dopo che vengono criptati in tempo reale. E' possibile che il processo effettui più scritture di quanto i dati effettivamente inviati occupino, dunque decretando una sorta di aumento della write amplification, ma a livello software, prima che essi arrivino all'SSD.

Per sicurezza personale sarebbe probabilmente meglio criptare l'SSD dopo un secure erase in quanto nella zona dedicata all'overprovisioning e lo spazio libero rimanente potrebbero potenzialmente rimanere dati non criptati. Il secure erase dovrebbe eliminare fisicamente i dati riazzerando le celle e resettando la chiave di cifratura interna dell'SSD, ma a dire il vero non ci sono garanzie che questo effettivamente accada. Solo un SSD nuovo, vergine, mai usato prima, può garantire che tutte le celle di memoria siano veramente vuote.

SOLO in questo modo tutte le celle saranno sempre all'interno dello spazio criptato e quindi, anche durante le operazioni di salvaguardia del controller/SO, tutti i dati rimarranno sempre al sicuro.

I settori criptati rimangono criptati a prescindere dalla loro effettiva locazione all'interno delle celle di memoria.

ammesso che si faccia una sola partizione e che si cripti questa intera partizione, essa viene gestita correttamente?
Cioè vengono correttamente individuate le celle vuote come vuote, e quindi la gestione delle operazioni di salvaguardia della vita dell'SSD funzionano?

I dati corrispondenti a questa partizione e memorizzati lì rimarranno criptati, non è che per il wear leveling "escono" da essa e diventino non-criptati.

Il problema (molto potenziale, ma probabilmente reale se ci sono vite o milioni/miliardi in gioco) dal punto di vista della sicurezza del criptaggio è che usare il TRIM rende visibile a possibili attacker quali settori sono considerati "spazio vuoto" (trimmati) e quali no. Con un hard disk non c'è questo problema in quanto tutto è criptato e rimane tale senza indicazione successiva di quali settori corrispondono allo spazio libero e quali ai dati in uso.

[tropicana]

Originariamente inviato da s12a

Per sicurezza personale sarebbe probabilmente meglio criptare l'SSD dopo un secure erase in quanto nella zona dedicata all'overprovisioning e lo spazio libero rimanente potrebbero potenzialmente rimanere dati non criptati. Il secure erase dovrebbe eliminare fisicamente i dati riazzerando le celle e resettando la chiave di cifratura interna dell'SSD, ma a dire il vero non ci sono garanzie che questo effettivamente accada. Solo un SSD nuovo, vergine, mai usato prima, può garantire che tutte le celle di memoria siano veramente vuote.

Proprio perchè pare che recuperare dati da un SSD, anche dopo un secure erase, sia molto più facile di quanto sembri, ovviamente non con prodotti consumer ma forensic (ci sono numerosi articoli sull'argomento anche se non mi sono soffermato più di tanto), mi è bastato per capire che criptare è l'unica soluzione per mettere davvero al sicuro i dati.

Ovviamente la criptazione è anche l'unica soluzione possibile se bisogna proteggere i dati da possibili furti del supporto fisico su cui sono immagazzinati (es. notebook) e naturalmente va fatta a disco vergine o comunque prima di cominiciare ad archiviare i dati da proteggere.

Parrebbe un controsenso, ma criptazione proprietaria e HW, per loro natura (esistono dei codici), sono meno sicuri di prodotti open.

Originariamente inviato da s12a

I settori criptati rimangono criptati a prescindere dalla loro effettiva locazione all'interno delle celle di memoria.

I dati corrispondenti a questa partizione e memorizzati lì rimarranno criptati, non è che per il wear leveling "escono" da essa e diventino non-criptati.

Il problema (molto potenziale, ma probabilmente reale se ci sono vite o milioni/miliardi in gioco) dal punto di vista della sicurezza del criptaggio è che usare il TRIM rende visibile a possibili attacker quali settori sono considerati "spazio vuoto" (trimmati) e quali no. Con un hard disk non c'è questo problema in quanto tutto è criptato e rimane tale senza indicazione successiva di quali settori corrispondono allo spazio libero e quali ai dati in uso.

E' esattamente quello che dicevo io con terminologie grezze , i dati spostati restano ancora criptati, sono le "vecchie copie" che invece finirebbero fuori dal "recinto" e quindi sarebbero recuperabili.

Per ovviare a questo rischio bisogna criptare l'intero disco in tutto il suo spazio possibile.

Originariamente inviato da s12a

Se con TrueCrypt il trim passa (a detta dei suoi creatori; a me non è mai capitato di verificare) quando lo si usa come soluzione di criptaggio di terze parti per l'intero volume (e non solo come encrypter per file contenitore), non dovrebbero esserci problemi per il wear leveling. Quello che fa il trim è contrassegnare un settore come "non valido", e quindi libero di essere usato dall'SSD per il wear leveling a sua discrezione (in aggiunta allo spazio di overprovisioning di serie). Per convenzione un settore trimmato dal punto di vista del sistema operativo contiene zeri, ma leggendo le memorie in maniera diretta (via hardware) se ne può leggere il contenuto. Tuttavia, se esso è criptato, non se ne può ricavare nulla di utile.

Quindi mi confermi è che basta il TRIM per garantire una corretta gestione del disco SSD?

Cioè se passa, come dicono i creatori del software, è sufficiente a poter usare con tranquillità un SSD più o meno quanto lo si sarebbe con un SSD usato normalmente?

Originariamente inviato da s12a

Criptando un volume al limite penso che il garbage collection possa essere meno efficiente in quanto non sarà in grado di determinare in maniera approfondita il contenuto dei settori memorizzati, a differenza di quanto può fare con il criptaggio hardware dell'SSD.

Scusa, per quale motivo? Il controller non capisce mica che tipo di dati ci sono, vede solo che c'è un dato. Se questo è open o criptato al controller non vedo cosa possa interessare, lui vede sempre e comunque 1 e/o 0.

Cioè non è che identifica per esempio una immagine .jpeg normale e sa gestirla ed invece una .jpeg criptata non sa come gestirla, oppure che se si tratta di file .txt deve intervenire, mentre se si tratta di file .dat no.

Dico male?

Originariamente inviato da s12a

Sarebbe anche da vedere come i dati vengono passati all'SSD dopo che vengono criptati in tempo reale. E' possibile che il processo effettui più scritture di quanto i dati effettivamente inviati occupino, dunque decretando una sorta di aumento della write amplification, ma a livello software, prima che essi arrivino all'SSD.

Che senso avrebbe riscrivere più volte un dato? Soprattutto per un software che lavora on-the-fly?
Il dato viene criptato e scritto (criptato) sul disco, dopo questo non c'è altra necessità di intervenire.


Sul discorso SSD io parlo da profano e ho aperto questa discussione proprio per approfondire e mettere insieme le varie informazioni che si conoscono sull'argomento, quindi le mie domande sono fatte con curiosità sincera.

[s12a]

Originariamente inviato da tropicana

Proprio perchè...

Scusa se salto, ma altrimenti la risposta diventa troppo lunga.

E' esattamente quello che dicevo io con terminologie grezze , i dati spostati restano ancora criptati, sono le "vecchie copie" che invece finirebbero fuori dal "recinto" e quindi sarebbero recuperabili.

Se per "vecchie copie" indendi i dati che esistevano nel drive prima di criptarlo, allora sì, è così.

Per ovviare a questo rischio bisogna criptare l'intero disco in tutto il suo spazio possibile.

Questo è certamente vero per un hard disk, ma con un SSD c'è lo spazio di overprovisioning dove l'SSD effettua le sue operazioni di wear leveling e criptare solo lo spazio utente non va a toccare questo. Per farlo occorre effettuare un secure erase, ma nessuno garantisce che esso elimini completamente i dati lì presenti, anche se dovrebbe farlo.

Alla lunga in ogni caso, i dati presenti nello spazio riservato/di overprovisioning verrebbero irrimediabilmente sovrascritti da dati criptati.

Quindi mi confermi è che basta il TRIM per garantire una corretta gestione del disco SSD?

In realtà basterebbe anche lo spazio di overprovisioning di fabbrica. Il TRIM fa in modo che tale spazio non sia fisso, ma si estenda anche a quello libero rilevato dal sistema operativo, in maniera dinamica con l'uso. In tale modo l'SSD può usare più spazio per il wear leveling.

Cioè se passa, come dicono i creatori del software, è sufficiente a poter usare con tranquillità un SSD più o meno quanto lo si sarebbe con un SSD usato normalmente?

L'SSD si può usare con tranquillità anche senza TRIM, ma si usurerà più velocemente. Gli SSD con più spazio di overprovisioning si usurano più lentamente a parità di scritture in assenza di TRIM rispetto a quelli che ne hanno di meno.

Ad esempio alcuni SSD enterprise da 200GB (equivalenti a 186.3 GiB) in realtà hanno tipicamente 256 GiB di memoria NAND. Questa differenza non disponibile all'utente è lo spazio di overprovisioning di fabbrica.

Scusa, per quale motivo? Il controller non capisce mica che tipo di dati ci sono, vede solo che c'è un dato. Se questo è open o criptato al controller non vedo cosa possa interessare, lui vede sempre e comunque 1 e/o 0.

Gli algoritmi di garbage collection dei moderni SSD sono piuttosto sofisticati ed sono in certi casi in grado di determinare la natura dei dati memorizzati ed agire di conseguenza per migliorare l'efficienza del wear leveling in assenza di TRIM.

Cioè non è che identifica per esempio una immagine .jpeg normale e sa gestirla ed invece una .jpeg criptata non sa come gestirla, oppure che se si tratta di file .txt deve intervenire, mentre se si tratta di file .dat no.

Potrebbe farlo, ma non so molto più di questo. Non so quali SSD effettuino tale tipo di analisi. Considerato però che alcuni SSD come il mio (Sandisk Extreme II, controller Marvell come sul Crucial M500) non sembrano risentire praticamente per nulla dell'assenza di TRIM in condizioni d'uso normali direi che il garbage collection degli SSD moderni sia effettivamente più intelligente di quanto si pensasse (od almeno di quanto pensavo io).

Che senso avrebbe riscrivere più volte un dato? Soprattutto per un software che lavora on-the-fly?
Il dato viene criptato e scritto (criptato) sul disco, dopo questo non c'è altra necessità di intervenire.

Se ad esempio per scrivere 500 byte TrueCrypt fa inviare all'SSD 8000 byte criptati, questo determina per forza di cose un aumento dell'usura a parità di scritture richieste dall'utente. Parlo per ipotesi, perché non ho idea di come funzioni di fatto questo programma.

Sul discorso SSD io parlo da profano e ho aperto questa discussione proprio per approfondire e mettere insieme le varie informazioni che si conoscono sull'argomento, quindi le mie domande sono fatte con curiosità sincera.

Io però non ho competenze specifiche in campo crittografico, purtroppo.

[tropicana]

Originariamente inviato da s12a

Scusa se salto, ma altrimenti la risposta diventa troppo lunga.

Ma figurati, è già un piacere potersi confrontare.

Originariamente inviato da s12a

Se per "vecchie copie" indendi i dati che esistevano nel drive prima di criptarlo, allora sì, è così.

In realtà intendevo i dati trimmati e quelli oggetto di GC.
Se è vero che sono facilmente identificabili quelli che hanno subito anche un secure erase, figuriamoci questi.

In ogni caso io parlo sempre di criptatura da SSD vergine, quindi almeno per ora mi limiterei a questo caso.

Originariamente inviato da s12a

Questo è certamente vero per un hard disk, ma con un SSD c'è lo spazio di overprovisioning dove l'SSD effettua le sue operazioni di wear leveling e criptare solo lo spazio utente non va a toccare questo. Per farlo occorre effettuare un secure erase, ma nessuno garantisce che esso elimini completamente i dati lì presenti, anche se dovrebbe farlo.

Alla lunga in ogni caso, i dati presenti nello spazio riservato/di overprovisioning verrebbero irrimediabilmente sovrascritti da dati criptati.

In realtà basterebbe anche lo spazio di overprovisioning di fabbrica. Il TRIM fa in modo che tale spazio non sia fisso, ma si estenda anche a quello libero rilevato dal sistema operativo, in maniera dinamica con l'uso. In tale modo l'SSD può usare più spazio per il wear leveling.


L'SSD si può usare con tranquillità anche senza TRIM, ma si usurerà più velocemente. Gli SSD con più spazio di overprovisioning si usurano più lentamente a parità di scritture in assenza di TRIM rispetto a quelli che ne hanno di meno.

Ad esempio alcuni SSD enterprise da 200GB (equivalenti a 186.3 GiB) in realtà hanno tipicamente 256 GiB di memoria NAND. Questa differenza non disponibile all'utente è lo spazio di overprovisioning di fabbrica.

Guada, forse avrò capito male io, ma lo spazio di OP, è di fatto non utilizzabile in modo diretto, ma usato dal controller per sostituire celle rovinate o comunque per attenuare il loro "invecchiamento".

Se il disco è completamente criptato (fin da vergine), anche i dati che finiranno in quello spazio saranno sempre e comunque criptati, quindi non è un problema la sua presenza.

L'importante è che tutto il disco sia completamente criptato, come detto più volte, questa è l'unica certezza che ho potuto appurare sull'intera questione.

Originariamente inviato da s12a

Gli algoritmi di garbage collection dei moderni SSD sono piuttosto sofisticati ed sono in certi casi in grado di determinare la natura dei dati memorizzati ed agire di conseguenza per migliorare l'efficienza del wear leveling in assenza di TRIM.


Potrebbe farlo, ma non so molto più di questo. Non so quali SSD effettuino tale tipo di analisi. Considerato però che alcuni SSD come il mio (Sandisk Extreme II, controller Marvell come sul Crucial M500) non sembrano risentire praticamente per nulla dell'assenza di TRIM in condizioni d'uso normali direi che il garbage collection degli SSD moderni sia effettivamente più intelligente di quanto si pensasse (od almeno di quanto pensavo io).

Su questo argomento sarebbe necessario trovare qualche info in più, di sicuro è interessante approfondire.

Quando dici che forse sono più intelligenti a cosa ti riferisci?

Ad ogni modo sarebbe almeno necessario capire se e quanto una criptatura possa disturbare questa funzione.

C'è qualche software che permette di monitorare questo aspetto e magari anche il funzionamento del TRIM?

Originariamente inviato da s12a

Se ad esempio per scrivere 500 byte TrueCrypt fa inviare all'SSD 8000 byte criptati, questo determina per forza di cose un aumento dell'usura a parità di scritture richieste dall'utente. Parlo per ipotesi, perché non ho idea di come funzioni di fatto questo programma.


Io però non ho competenze specifiche in campo crittografico, purtroppo.

Anche io non ho competenze specifiche nel campo crittografico, ma non credo vari la dimensione del file.

Stay tuned

[s12a]

Originariamente inviato da tropicana

In realtà intendevo i dati trimmati e quelli oggetto di GC.

Allora, se entrambi erano criptati prima, rimangono criptati anche dopo, a prescindere da dove vengono riallocati all'interno delle celle di memoria.

Se è vero che sono facilmente identificabili quelli che hanno subito anche un secure erase, figuriamoci questi.

Non è che sono identificabili dopo un secure erase tout court. Lo sono negli SSD in cui il secure erase non viene eseguito correttamente dal controller. Non so dirti quali modelli in particolare si comportano così, ma so che è una cosa possibile e che è già successa (presumo con SSD di generazioni passate magari di marche minori).

Guada, forse avrò capito male io, ma lo spazio di OP, è di fatto non utilizzabile in modo diretto, ma usato dal controller per sostituire celle rovinate o comunque per attenuare il loro "invecchiamento".

Quella di sostituire celle rovinate in realtà è una funzionalità minore; solo una piccolissima parte della memoria NAND installata nell'SSD è dedicata a tale scopo.

L'OP serve principalmente per effettuarci sopra il wear leveling e mantenere quindi prestazioni stabili ed usura bassa.

Il TRIM permette al sistema operativo di estendere la possibilità dell'SSD di effettuare il wear leveling anche su spazio non strettamente di OP, indicando in maniera esplicita quali settori logici non contengono più dati validi. I settori logici liberati con il TRIM possono essere usati dall'SSD come meglio ritiene opportuno e questo è principalmente il wear leveling.

Il Garbage Collection è la funzionalità/insieme di algoritmi dell'SSD che permette ad esso di - letteralmente - deframmentare le pagine di programmazione dei blocchi di memoria in cui i dati sono memorizzati, migliorando l'efficienza del wear leveling ed abbassando la write amplification. La sua forma base (per così dire, accademica), che implica solo il compattamento delle pagine di programmazione delle memorie NAND, non coinvolge l'analisi attiva dell'effettivo contenuto dei dati memorizzati, opera praticamente a livello fisico.

Se il disco è completamente criptato (fin da vergine), anche i dati che finiranno in quello spazio saranno sempre e comunque criptati, quindi non è un problema la sua presenza.

In tal caso non è un problema.

L'importante è che tutto il disco sia completamente criptato, come detto più volte, questa è l'unica certezza che ho potuto appurare sull'intera questione.

L'importante è che i dati siano criptati fin dall'inizio, ma se l'SSD è vergine non è che ci sia bisogno di criptare lo spazio libero già disponibile, in particolar modo se si usa il TRIM, visto che esso rende comunque visibile all'esterno quali settori sono considerati "spazio vuoto".

Su questo argomento sarebbe necessario trovare qualche info in più, di sicuro è interessante approfondire.

Credo sia difficile trovare informazioni specifiche in giro. Probabilmente è tutto a livello di brevetti, se non segreti industriali.

Quando dici che forse sono più intelligenti a cosa ti riferisci?

Ad esempio qui:
http://en.wikipedia.org/wiki/Garbage...age_collection

Originariamente inviato da Wikipedia

Filesystem-aware garbage collection

In 2010, some manufacturers (notably Samsung) introduced SSD controllers that extended the concept of BGC to analyze the file system used on the SSD, to identify recently deleted files and unpartitioned space. The manufacturer claimed that this would ensure that even systems (operating systems and SATA controller hardware) which do not support TRIM could achieve similar performance. The operation of the Samsung implementation appeared to assume and require an NTFS file system.[18] It is not clear if this feature is still available in currently shipping SSDs from these manufacturers. Systematic data corruption has been reported on these drives if they are not formatted properly using MBR and NTFS.[19]

Dal 2010 ad oggi di tempo ne è passato e gli SSD si sono evoluti molto. E' possibile che siano diventati molto più sofisticati a tal merito.

Ad ogni modo sarebbe almeno necessario capire se e quanto una criptatura possa disturbare questa funzione.

Se i dati sono criptati prima di arrivare all'SSD, qualsiasi funzionalità di riconoscimento attivo programmata per il Garbage Collection non può funzionare in quanto figurerebbero come una sequenza di dati casuali.

C'è qualche software che permette di monitorare questo aspetto e magari anche il funzionamento del TRIM?

Non in maniera diretta. Lo si può fare in maniera indiretta monitorando i parametri di usura dai dati SMART del drive, ma non tutti gli SSD permettono di farlo bene in quanto non forniscono tutti gli stessi dati e con la stessa precisione/granularità.

[il_nick]

Mi era sfuggita questa non recente ma interessante discussione, trovandomi nel caso analogo avevo aperto questa simile, ma ovviamente lascio ai moderatori la facoltà di chiuderne una per proseguire sull'altra.

Tornando in tema, mi chiedevo se l'autore del thread abbia avuto modo di testare il comportamento del suo SSD dopo la cifratura con TrueCrypt o se abbia reperito maggiori info circa il corretto funzionamento e l'eventuale usura accentuata dalla cifratura.

Originariamente inviato da s12a

Allora, se entrambi erano criptati prima, rimangono criptati anche dopo, a prescindere da dove vengono riallocati all'interno delle celle di memoria.

Originariamente inviato da s12a

L'importante è che i dati siano criptati fin dall'inizio, ma se l'SSD è vergine non è che ci sia bisogno di criptare lo spazio libero già disponibile, in particolar modo se si usa il TRIM, visto che esso rende comunque visibile all'esterno quali settori sono considerati "spazio vuoto".

Non mi è molto chiaro il motivo di questa precisazione.
Con TrueCrypt (e suoi successivi fork) cifrare un disco (o una partizione) già scritto comporta molto più tempo (per un disco o partizione vuoti la procedura impiega appena qualche istante) e, soprattutto, la perdita (leaks) di informazioni sensibili se queste non vengono opportunamente sovrascritte prima della cifratura degli stessi dati; TrueCrypt ha anche questa opzione aggiuntiva al processo di cifratura, che per questo rende lo stesso ancora più lungo ma assicura la totale privacy. Ovviamente parliamo di hard disk meccanici, in quanto il sistema di sovrascrittura non sarebbe utile o efficace per gli ssd.
Ciò premesso, se si cifra un disco vuoto/vergine (indipendentemente che sia meccanico o solido), ovviamente non viene cifrato lo spazio vuoto ma - suppongo - il programma fa in modo che ogni dato scritto in tale spazio venga preventivamente cifrato. Pertanto, in accordo con quanto osservato dall'autore del thread, la totale cifratura da disco vergine o azzerato renderebbe inutili attacchi mirati a scovare posizioni di memoria libere, in quanto i dati sarebbero poi scritti comunque in modo cifrato... ho capito bene oppure ho detto una castroneria?