First of all, let me start by saying that I have read the VeraCrypt documentation regarding this issue. I just want to make sure that I actually understand what I'm reading.
As most SSDs use some form of wear leveling VeraCrypt cannot actually "in place" encrypt a system partition, because the controller decides where to write the data. On an HDD we would have block-level access that enables us to write exactly where we want to, but SSD controllers don't allow for that.
Since I want to install an encrypted version of Windows, I have no other choice than to install a fresh copy of Windows on my SSD like normal and then encrypt it in place with VeraCrypt. There is no way to encrypt the entire drive first and THEN install Windows, right?
So if I understand the worst-case scenario right, this would leave a copy of my original Windows installation unencrypted somewhere on the drive and VeraCrypt will "in-place encrypt" a copy of my operating system somewhere else on the drive since the SSD controller will decide where this new data goes.
In the worst-case scenario, this would be no issue from a security viewpoint IF the original fresh Windows installation does not contain any sensitive data, because as soon as the VeraCrypt encryption is done, any NEW data will only be saved encrypted. Is that right?
So the fact that I may have a copy of the original, unencrypted Windows installation somewhere on my drive is not a attack point? The only information an attacker may gain from that is that there probably is an encrypted Windows OS somewhere on the drive?
My goal is not plausible deniability or to hide my operating system. The only goal in this case is to protect my data from access.
Is this an accurate take on the problem and are there any security concerns that I am missing?
Thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you encrypt a new, unused drive using system level encryption, you're most assured if you use the entire drive as one large partition, so it doesn't matter what wear leveling does as once encryption is complete, the SSD firmware writes encrypted clusters to the encrypted portions of the drive, which have been wiped clean with random data during formatting, at the physical level. But there is a catch, see TRIM, below.
If you only use part of an SSD, by partitioning it into more than 1 drive, the other being unencrypted, there is higher chance of a data leak; what wear leveling does is vendor dependent, for example, you cannot be sure it will write physical Veracrypt clusters to the unencrypted partition. Regardless, what is physically there is a string of encrypted characters that is mapped logically to the Veracrypt partition, and will appear as random characters , potentially in a background of 'zero characters' caused by the TRIM function, for a forensic expert to decipher.
The data leak is similar to the issue of undeclared 'extra capacity' in some SSDs, as raised by Mounir, which is an added problem is you are encrypting an SSD in-place that has already been used to store sensitive data and that wiping clean beforehand cannot be certain to leak unencrypted data:
Regardless, TRIM and/or garbage collection in an SSD will over time reclaim unused clusters, including the unreported capacities areas, and wipe them clean, as they are all marked unused but have not been erased. So over some period that is unknown, as it depends on the firmware and when these automated functions run, the SSD will eventually have only encrypted clusters, scattered throughout the drive. With TRIM, the 'wiped clean' areas of the drive supposed with 'random data' could be marked with physical zeros and thus, negate its effect and no longer appear random. The encrypted clusters would appear similar to how as a Veracrypt encrypted container would appear on an unencrypted SSD or thumb drive, when using a disk analyzer.
Know both TRIM and wear leveling, common to all SSD, are considered problematic issues when encrypting with Veracrypt, and an old style hard drive remains a more secure bet over an SSD.
on older ssds, is best to encrypt them when they are new so they won't have old sensitive files on them and any new data written on them would be encrypted
however this is not the case for new ssds that come hardware encrypted ( with blank default password)
for example with samsung nvme 970,980 etc you can make a bootable usb drive through samsung magician to wipe the drive, all it does it wipes their hardware encryption keys and replace them with another so it takes only few seconds, it doesn't lower the ssd life by filling it with unncessary data and you are assured that any old sensitive data is unrecoverable
pretty sure there are other ssds models that can be securely erased in a simillar way.
but i wouldn't stress too much about it, realistically speaking unless you will have an adversary with a big budget willing to spend it on you is unlikely to recover any data even with an old ssd if you had sensitive data on it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A problem with SSD vendor based "SED" encryption is validation. This is a third party evaluation of the SSD security, from its hardware, software and firmware, and preferably, the system it will be installed in.
That said, an academic survey of SSD from various manufacturers extending from Year 2014-18 found many security holes, as well as master passwords, in many commercial implementation of proprietary encryption or standard encryption specifications such as by TCG, Opal. See Attached.
A similar evaluation was made of hardware encryption of HD years ago, but its obsolete as most manufacturers are moving away from proprietary encryption methods, to implementing the Opal scheme.
A partial solution is to choose a US FIPS 140-2 validated SSD, or one that has International "common criteria" or its equivalent in your country. However, this only validates the cryptographic module, not the entire SSD itself: there can be flaws in the implementation of the hardware or firmware that use the module.
Until any SSD SED is evaluated as thoroughly as Veracrypt 1.24 was on 30.11.2020, the true security of an SSD SED relative to Veracrypt, is unknown and with the above study,must be presumed qualitatively lower than that of Veracrypt 1.24.
y'all too paranoid
once you wipe the hardware encryption keys there is NOTHING that can retrieve your data, the vulnerabilities that you are talking work only if you actively use the hardware encryption and rely on it.
i had tons of sensitive data before encrypting samsung ssd, did a secure erase with their soft to change hardware encryption keys and encrypted with vera crypt the system drive while leaving about 300 gb unallocated space to improve drive performance.
I've been working with sensitive data for almost on year in this encrypted drive while keeping the unallocated space.
So just to prove you are wrong I did a full forensic scan on the unallocated space that is left uncrypted with a strong commercially widely used tool and found ZERO artifacts, not even a picture, not even a word from a text document, NOTHING.
Looking with HEX most of that space were bunch of zeros and everything else was just cypher data so quit being so paranoid, ssds are safe to encrypt even if you leave extra uncrypted space.
I know that some ssds keep an extra hidden partition for cache that is accessible only with advanced hardware tools from the manufacturer directly to access but when you wipe the hardware encryption keys that data becomes junk as well but who do you think it will go to that much trouble for you anyway ?
Even if you use an old ssd, doing a traditional wipe will make it extremely unlikely for someone to retrieve any sensitive data and using it actively afterwards will just eventually overwrite your sensitive data(if any left).
Last edit: hiddengod 2022-02-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's not for you to decide, especially after reviewing all the nonsense below:
once you wipe the hardware encryption keys there is NOTHING that can retrieve your data, the vulnerabilities that you are talking work only if you actively use the hardware encryption and rely on it.
There's no way for you to securely wipe the SSD's encryption keys. All you can do is taking the vendor of the SSD for their word, that the key is REALLY deleted. There is no (simple) way for you to prove that true.
i had tons of sensitive data before encrypting samsung ssd, did a secure erase with their soft to change hardware encryption keys and encrypted with vera crypt the system drive while leaving about 300 gb unallocated space to improve drive performance.
I've been working with sensitive data for almost on year in this encrypted drive while keeping the unallocated space.
If you trust your SSD vendor, then this is fine for you, but seemingly not for everyone.
So just to prove you are wrong I did a full forensic scan on the unallocated space that is left uncrypted with a strong commercially widely used tool and found ZERO artifacts, not even a picture, not even a word from a text document, NOTHING.
No matter what software you use, it can only read the data provided by the SSD's memory controller. That's the critical part, where output manipulation could be done. After a "secure" wipe, it's possible that only a flag is set, indicating that a wipe was performed. But in reality, all data could still reside on the SSD. The memory controller only returns zeros, bogus data or whatever to make it look like the SSD was wiped.
You proved absolutely nothing here.
Looking with HEX most of that space were bunch of zeros and everything else was just cypher data so quit being so paranoid, ssds are safe to encrypt even if you leave extra uncrypted space.
Same as above.
I know that some ssds keep an extra hidden partition for cache that is accessible only with advanced hardware tools from the manufacturer directly to access but when you wipe the hardware encryption keys that data becomes junk as well [...]
As stated before, you can never be sure that the encryption key was actually wiped.
[...] but who do you think it will go to that much trouble for you anyway ?
If this was a fair point, no one would have to encrypt data in the first place. Ever thought of politicians, journalists, sensitive development data, lists with names of undercover agents? I bet there are people who would go to extends to get their hands on such data.
Even if you use an old ssd, doing a traditional wipe will make it extremely unlikely for someone to retrieve any sensitive data and using it actively afterwards will just eventually overwrite your sensitive data(if any left).
That's not exactly true. It depends on how the wipe is performed. Just wiping by writing zeros could possibly give you nothing due to wear leveling and possible memory controller interference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a similar question to Tim's. I have also read the Veracrypt documentation and came across the parts about TRIM and wear-leveling. I am unsure, however, if I properly understand the security implications of this.
What I have read was similar to what Robert wrote in this thread:
"If you only use part of an SSD, by partitioning it into more than 1 drive, the other being unencrypted, there is higher chance of a data leak; what wear leveling does is vendor dependent, for example, you cannot be sure it will write physical Veracrypt clusters to the unencrypted partition. Regardless, what is physically there is a string of encrypted characters that is mapped logically to the Veracrypt partition, and will appear as random characters , potentially in a background of 'zero characters' caused by the TRIM function, for a forensic expert to decipher."
For using encrypted containers on non-encrypted SSDs, I understand the implications as follows: with wear-leveling and TRIM, (1) veracrypt clusters can be (partially) written to non-encrypted partitions, and (2) it is possible that an attackers can identify the location of veracrypt containers because of a background of zero characters. However, in both cases, the 'leak' remains limited to exposing the existence of encrypted data and does in no way involve access to the unencrypted contents of the container. Would I, for example, not care about people knowing about the existence of the container, have an extremely strong password, and not be afraid of extortion of any kind, there is no reason for me to care. The contents of the sensitive data container would remain encrypted and safe, assuming the password is strong enough and close to impossible to guess within a million years.
My aimed-at application: I am planning on putting an encrypted container on a non-encrypted SSD. The SSD drive has never had unencrypted versions of the data on it before. I am also never planning on decrypting/opening the data on the drive in question (or the associated system). It's just for long-term storage. So I think there is also no way for unencrypted data to end up in paging files or become accessible due to bad sector remapping etc.
Is my understanding correct, or do I miss certain security implications of encrypted containers on non-encrypted SSDs, and could the contents of the container be exposed in some way?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, let me start by saying that I have read the VeraCrypt documentation regarding this issue. I just want to make sure that I actually understand what I'm reading.
As most SSDs use some form of wear leveling VeraCrypt cannot actually "in place" encrypt a system partition, because the controller decides where to write the data. On an HDD we would have block-level access that enables us to write exactly where we want to, but SSD controllers don't allow for that.
Since I want to install an encrypted version of Windows, I have no other choice than to install a fresh copy of Windows on my SSD like normal and then encrypt it in place with VeraCrypt. There is no way to encrypt the entire drive first and THEN install Windows, right?
So if I understand the worst-case scenario right, this would leave a copy of my original Windows installation unencrypted somewhere on the drive and VeraCrypt will "in-place encrypt" a copy of my operating system somewhere else on the drive since the SSD controller will decide where this new data goes.
In the worst-case scenario, this would be no issue from a security viewpoint IF the original fresh Windows installation does not contain any sensitive data, because as soon as the VeraCrypt encryption is done, any NEW data will only be saved encrypted. Is that right?
So the fact that I may have a copy of the original, unencrypted Windows installation somewhere on my drive is not a attack point? The only information an attacker may gain from that is that there probably is an encrypted Windows OS somewhere on the drive?
My goal is not plausible deniability or to hide my operating system. The only goal in this case is to protect my data from access.
Is this an accurate take on the problem and are there any security concerns that I am missing?
Thank you!
When you encrypt a new, unused drive using system level encryption, you're most assured if you use the entire drive as one large partition, so it doesn't matter what wear leveling does as once encryption is complete, the SSD firmware writes encrypted clusters to the encrypted portions of the drive, which have been wiped clean with random data during formatting, at the physical level. But there is a catch, see TRIM, below.
If you only use part of an SSD, by partitioning it into more than 1 drive, the other being unencrypted, there is higher chance of a data leak; what wear leveling does is vendor dependent, for example, you cannot be sure it will write physical Veracrypt clusters to the unencrypted partition. Regardless, what is physically there is a string of encrypted characters that is mapped logically to the Veracrypt partition, and will appear as random characters , potentially in a background of 'zero characters' caused by the TRIM function, for a forensic expert to decipher.
The data leak is similar to the issue of undeclared 'extra capacity' in some SSDs, as raised by Mounir, which is an added problem is you are encrypting an SSD in-place that has already been used to store sensitive data and that wiping clean beforehand cannot be certain to leak unencrypted data:
https://sourceforge.net/p/veracrypt/discussion/technical/thread/88cef61b/
Regardless, TRIM and/or garbage collection in an SSD will over time reclaim unused clusters, including the unreported capacities areas, and wipe them clean, as they are all marked unused but have not been erased. So over some period that is unknown, as it depends on the firmware and when these automated functions run, the SSD will eventually have only encrypted clusters, scattered throughout the drive. With TRIM, the 'wiped clean' areas of the drive supposed with 'random data' could be marked with physical zeros and thus, negate its effect and no longer appear random. The encrypted clusters would appear similar to how as a Veracrypt encrypted container would appear on an unencrypted SSD or thumb drive, when using a disk analyzer.
Know both TRIM and wear leveling, common to all SSD, are considered problematic issues when encrypting with Veracrypt, and an old style hard drive remains a more secure bet over an SSD.
https://veracrypt.fr/en/Trim%20Operation.html
Last edit: Robert iXj Smith 2022-02-20
on older ssds, is best to encrypt them when they are new so they won't have old sensitive files on them and any new data written on them would be encrypted
however this is not the case for new ssds that come hardware encrypted ( with blank default password)
for example with samsung nvme 970,980 etc you can make a bootable usb drive through samsung magician to wipe the drive, all it does it wipes their hardware encryption keys and replace them with another so it takes only few seconds, it doesn't lower the ssd life by filling it with unncessary data and you are assured that any old sensitive data is unrecoverable
pretty sure there are other ssds models that can be securely erased in a simillar way.
but i wouldn't stress too much about it, realistically speaking unless you will have an adversary with a big budget willing to spend it on you is unlikely to recover any data even with an old ssd if you had sensitive data on it.
A problem with SSD vendor based "SED" encryption is validation. This is a third party evaluation of the SSD security, from its hardware, software and firmware, and preferably, the system it will be installed in.
That said, an academic survey of SSD from various manufacturers extending from Year 2014-18 found many security holes, as well as master passwords, in many commercial implementation of proprietary encryption or standard encryption specifications such as by TCG, Opal. See Attached.
A similar evaluation was made of hardware encryption of HD years ago, but its obsolete as most manufacturers are moving away from proprietary encryption methods, to implementing the Opal scheme.
A partial solution is to choose a US FIPS 140-2 validated SSD, or one that has International "common criteria" or its equivalent in your country. However, this only validates the cryptographic module, not the entire SSD itself: there can be flaws in the implementation of the hardware or firmware that use the module.
As example.
https://www.amazon.com/Micron-512GB-2280SS-Client-MTFDDAV512TBN-1AR15FCYY/dp/B07PQMH83Z/ref=sr_1_6?crid=2R37MCDTJIGBG&keywords=FIPS+Validated%2C+SSD&qid=1645379862&s=electronics&sprefix=fips+validated%2C+ssd+%2Celectronics%2C110&sr=1-6
For details on the above product, you can query NIST for its validation certificate:
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2848
For what FIPS is, you can see:
https://en.wikipedia.org/wiki/FIPS_140
Until any SSD SED is evaluated as thoroughly as Veracrypt 1.24 was on 30.11.2020, the true security of an SSD SED relative to Veracrypt, is unknown and with the above study,must be presumed qualitatively lower than that of Veracrypt 1.24.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Veracrypt/Veracrypt.html
Last edit: Robert iXj Smith 2022-02-20
y'all too paranoid
once you wipe the hardware encryption keys there is NOTHING that can retrieve your data, the vulnerabilities that you are talking work only if you actively use the hardware encryption and rely on it.
i had tons of sensitive data before encrypting samsung ssd, did a secure erase with their soft to change hardware encryption keys and encrypted with vera crypt the system drive while leaving about 300 gb unallocated space to improve drive performance.
I've been working with sensitive data for almost on year in this encrypted drive while keeping the unallocated space.
So just to prove you are wrong I did a full forensic scan on the unallocated space that is left uncrypted with a strong commercially widely used tool and found ZERO artifacts, not even a picture, not even a word from a text document, NOTHING.
Looking with HEX most of that space were bunch of zeros and everything else was just cypher data so quit being so paranoid, ssds are safe to encrypt even if you leave extra uncrypted space.
I know that some ssds keep an extra hidden partition for cache that is accessible only with advanced hardware tools from the manufacturer directly to access but when you wipe the hardware encryption keys that data becomes junk as well but who do you think it will go to that much trouble for you anyway ?
Even if you use an old ssd, doing a traditional wipe will make it extremely unlikely for someone to retrieve any sensitive data and using it actively afterwards will just eventually overwrite your sensitive data(if any left).
Last edit: hiddengod 2022-02-24
That's not for you to decide, especially after reviewing all the nonsense below:
There's no way for you to securely wipe the SSD's encryption keys. All you can do is taking the vendor of the SSD for their word, that the key is REALLY deleted. There is no (simple) way for you to prove that true.
If you trust your SSD vendor, then this is fine for you, but seemingly not for everyone.
No matter what software you use, it can only read the data provided by the SSD's memory controller. That's the critical part, where output manipulation could be done. After a "secure" wipe, it's possible that only a flag is set, indicating that a wipe was performed. But in reality, all data could still reside on the SSD. The memory controller only returns zeros, bogus data or whatever to make it look like the SSD was wiped.
You proved absolutely nothing here.
Same as above.
As stated before, you can never be sure that the encryption key was actually wiped.
If this was a fair point, no one would have to encrypt data in the first place. Ever thought of politicians, journalists, sensitive development data, lists with names of undercover agents? I bet there are people who would go to extends to get their hands on such data.
That's not exactly true. It depends on how the wipe is performed. Just wiping by writing zeros could possibly give you nothing due to wear leveling and possible memory controller interference.
Hi everyone,
I have a similar question to Tim's. I have also read the Veracrypt documentation and came across the parts about TRIM and wear-leveling. I am unsure, however, if I properly understand the security implications of this.
What I have read was similar to what Robert wrote in this thread:
"If you only use part of an SSD, by partitioning it into more than 1 drive, the other being unencrypted, there is higher chance of a data leak; what wear leveling does is vendor dependent, for example, you cannot be sure it will write physical Veracrypt clusters to the unencrypted partition. Regardless, what is physically there is a string of encrypted characters that is mapped logically to the Veracrypt partition, and will appear as random characters , potentially in a background of 'zero characters' caused by the TRIM function, for a forensic expert to decipher."
For using encrypted containers on non-encrypted SSDs, I understand the implications as follows: with wear-leveling and TRIM, (1) veracrypt clusters can be (partially) written to non-encrypted partitions, and (2) it is possible that an attackers can identify the location of veracrypt containers because of a background of zero characters. However, in both cases, the 'leak' remains limited to exposing the existence of encrypted data and does in no way involve access to the unencrypted contents of the container. Would I, for example, not care about people knowing about the existence of the container, have an extremely strong password, and not be afraid of extortion of any kind, there is no reason for me to care. The contents of the sensitive data container would remain encrypted and safe, assuming the password is strong enough and close to impossible to guess within a million years.
My aimed-at application: I am planning on putting an encrypted container on a non-encrypted SSD. The SSD drive has never had unencrypted versions of the data on it before. I am also never planning on decrypting/opening the data on the drive in question (or the associated system). It's just for long-term storage. So I think there is also no way for unencrypted data to end up in paging files or become accessible due to bad sector remapping etc.
Is my understanding correct, or do I miss certain security implications of encrypted containers on non-encrypted SSDs, and could the contents of the container be exposed in some way?