>To capture an image of the computer’s RAM, run EFDD on the computer on which the VeraCrypt disk is currently mounted.
This seems like a pointless exercise. If the disk is already decrypted and mounted, plus you have access to the computer, why not just... directly read the disk? Or initiate the decryption routine?
On most hosts you can but I believe AMDs EPYC processor support hypervisors where the host cannot access the memory via a feature called Secure Encrypted Virtualisation (SEV).
Yeah there is SEV support, but I tried to find whatever e.g Oracle Cloud utilize it and found nothing. It's also require SEV support in both hypervisor and guest OS.
PS: you can check whatever SEV enabled this way in the guest. It's suppose to say "AMD Secure Encrypted Virtualization (SEV) active":
I would be interested to know if VPS providers actually go as far as dumping and snapshoting RAM (most of them claim they don’t even access disk or monitor traffic). It would be big deal for systems such as EC2.
The advantage isn't huge but it does exist. Stealing encryption keys out of memory is a reasonably common thing for more sophisticated malware to do, because if you can opportunistically do it once it generally confers permanent access to the encrypted data whenever you want.
Copying the contents out isn't very desirable because 1) it is slow and bandwidth intensive which means it is less likely to succeed opportunistically and more detectable, 2) you will not be able to examine the data again in the future (including changes) without finding an opportunity to copy it out again. It is also often just easier for someone with malicious intent to subtly capture the encrypted volume (can be sent out very slowly without worrying about user behavior) and then examine it remotely (easier and safer to use/iterate on custom tools when you're not shipping them to the compromised machine).
This way malware, especially like a plugin-based botnet, can continuously check for the key and grab it whenever it's in memory. Then later on, as convenient, plugins can search the encrypted volume for specific signatures whenever they want. That includes loading more signatures in the future, rescanning for changes, etc. All in all, the ability to extract the key from memory violates the fundamental assumption of the user that the data is not accessible when they have not mounted the volume... it means that if the volume has ever been mounted, unauthorized software might have captured the information necessary to examine it as desired, in a subtle way.
Elcomsoft is also principally a forensic vendor, and this kind of thing is very useful in forensics scenarios when you encounter a live machine (e.g. law enforcement seizure). If you can capture the key from the live machine quickly, you can do your analysis later at leisure and with less risk of contamination of the evidence. This minimizes the need for complex and risky methods like transporting the machine without power interruption.
Obviously this kind of problem is not necessarily completely solvable... if the data was decrypted then there was, at some point, the material to decrypt it present on the system. But more modern disk and file encryption solutions tend to use various solutions like the TPM and operating system features to avoid the key being available in memory.
Finally, as always, password reuse is an issue here. If you can get the key material there's a good bet it might work on other volumes as well if you can recompute for whatever the volume salt is... this may be more or less practical depending on how TrueCrypt/VeraCrypt derives the key which I don't remember well.
This is a non-issue for most users. If you're part of the users who need fast dismount then an additional hardware can be deployed, as paranoid as turning your back to a camera and the eyes reading very primitive algorithm will shut down your PC.
If I understood correctly he means that you can write a simple tool that reads input from the camera, capture the eyes and as soon as you turn away the pc will shutdown.
You mean a very simple algorithm to detect eyes using the OpenCV (https://en.wikipedia.org/wiki/OpenCV) written on a RaspberryPi that has a tiny camera which connects to your desired computer via network (be it WiFi or cable) and sends a shutdown command once it no longer detects them? I am pretty sure you can find on SlackOverflow (pun intended) / RaspberryPi forums desired bits of software and make do in maximum one day.
Can I just complain for a moment about this site's popup with two buttons labeled, "Subscribe" and "Keep Receiving our News" with no close button or deny available.
That is just one of many annoyances that are a total non-issue if you have JS off by default, and of which I am painfully reminded whenever I see or need to use someone else's computer.
I guess the interesting thing for a VeraCrypt user is that Elcomsoft can't grab keys from memory if RAM encryption of keys and passwords is turned on. So that means such a user is immune to Elcomsoft forensics software if they have a strong passphrase.
I am not sure why Elcomsoft would want to write a blog article informing the world of this fact...
Anyway, here is the direct link to how VeraCrypt does their RAM encryption:
That doesn't prevent extraction by someone with supervisor/hypervisor access (so if Elcomsoft can't extract it it's only because they are lazy), it just tries to make it less likely that an attacker can extract it from a locked machine they have physical access to (by rebooting into a boot image of their choice and reading the RAM, the so-called "cold boot" attack).
It's mathematically impossible to prevent key extraction unless you put the key in an HSM (the TPM might function as such, but it may not have good performance) and use that for decryption (the most you can do is make the key larger up to the amount of RAM you have, at the costing of wasting RAM).
Even if you use an HSM, the malware can just extract the data itself or even on-the-fly decrypt the disk with the HSM and re-encrypt with a known key and then exfiltrate the known key, so all this does is make the attack slower since you need to read/write the whole disk.
This is just a software limitation, you can't turn the option on and trust that they can't work around it next month. As the article says, RAM encryption is obfuscation more than really doing anything. It would be rather impressive if you could encrypt the key necessary to decrypt your RAM yet continue to use the computer.
That isn't to say RAM encryption doesn't have other benefits, but if your computer is unlocked and unattended, then yeah someone is going to be able to dump those keys one way or another especially if the system isn't tamper-safe (like a smart card aims to be).
This is such a weird article. It's basically an ad for software that claims to "break" VeraCrypt by extracting encryption keys from a memory dump. And apparently it doesn't even work if you set VeraCrypt to encrypt keys in memory.
Note that this is just a software limitation, you can't turn it on and trust that they can't break it next month. As the article quotes, it's more obfuscation (that they haven't yet worked around, apparently) than doing anything. It would be rather impressive if you could encrypt the key necessary to decrypt your RAM yet continue to use the computer, i.e. this will always be just obfuscation.
The title (breaking veracrypt) is misleading (and probably a click bait).
Any mounted encrypted data has keys in RAM or an HSM. If you have access to inside of those, you have access to keys. This is not breaking anything.
You can encrypt or obfuscate data in RAM, but then the keys should be stored in disk, ram or HSM, which is subject to the same problem. Actually, TPM/secure enclave merely binds the key to the device, and doesn’t help with key extraction, since it trusts the root, unless you set a PIN, which makes automated access impractical, or a max number of trials.
I liked some posts in this blog, particularly the one on synology which turned out to be consequential, but I think the authors should title their posts more modestly.
—————————————————-
VeraCrypt FAQ answers a question on root privilege, reading RAM and support for TPM:
“No. Those programs use TPM to protect against attacks that require the attacker to have administrator privileges, or physical access to the computer, and the attacker needs you to use the computer after such an access. However, if any of these conditions is met, it is actually impossible to secure the computer (see below) and, therefore, you must stop using it (instead of relying on TPM).
If the attacker has administrator privileges, he can, for example, reset the TPM, capture the content of RAM (containing master keys) or content of files stored on mounted VeraCrypt volumes (decrypted on the fly), which can then be sent to the attacker over the Internet or saved to an unencrypted local drive (from which the attacker might be able to read it later, when he gains physical access to the computer).”
“We’ve supported this workflow for years for multiple disk encryption packages, and now we have it for VeraCrypt, one of the most commonly used disk encryption package in the criminal world.”
Two things:
1. I’m sure FileVault and BitLocker are also commonly used by criminals. In fact probably more so in the first instance, unintentionally, it given it’s enabled by default in modern MacOS.
2. It seems to imply VeraCrypt is commonly used by criminals. That might be true I guess, but I’d bet more non-criminals than criminals use VeraCrypt.
Maybe VeraCrypt just stands out more as a red flag rather than using native LUKS/FileVault/BitLocker for Linux/MacOS/Windows accordingly.
I also don’t see what elcomsoft have to gain by writing these blogposts? Who are their target audience?
29 comments
[ 3.9 ms ] story [ 68.9 ms ] threadThis seems like a pointless exercise. If the disk is already decrypted and mounted, plus you have access to the computer, why not just... directly read the disk? Or initiate the decryption routine?
Also, if a hacker has admin/root access as is required for this tool to work, you have all kinds of other problems.
PS: you can check whatever SEV enabled this way in the guest. It's suppose to say "AMD Secure Encrypted Virtualization (SEV) active":
I would be interested to know if VPS providers actually go as far as dumping and snapshoting RAM (most of them claim they don’t even access disk or monitor traffic). It would be big deal for systems such as EC2.
This isn't what I would call "Breaking" Veracrypt.
Copying the contents out isn't very desirable because 1) it is slow and bandwidth intensive which means it is less likely to succeed opportunistically and more detectable, 2) you will not be able to examine the data again in the future (including changes) without finding an opportunity to copy it out again. It is also often just easier for someone with malicious intent to subtly capture the encrypted volume (can be sent out very slowly without worrying about user behavior) and then examine it remotely (easier and safer to use/iterate on custom tools when you're not shipping them to the compromised machine).
This way malware, especially like a plugin-based botnet, can continuously check for the key and grab it whenever it's in memory. Then later on, as convenient, plugins can search the encrypted volume for specific signatures whenever they want. That includes loading more signatures in the future, rescanning for changes, etc. All in all, the ability to extract the key from memory violates the fundamental assumption of the user that the data is not accessible when they have not mounted the volume... it means that if the volume has ever been mounted, unauthorized software might have captured the information necessary to examine it as desired, in a subtle way.
Elcomsoft is also principally a forensic vendor, and this kind of thing is very useful in forensics scenarios when you encounter a live machine (e.g. law enforcement seizure). If you can capture the key from the live machine quickly, you can do your analysis later at leisure and with less risk of contamination of the evidence. This minimizes the need for complex and risky methods like transporting the machine without power interruption.
Obviously this kind of problem is not necessarily completely solvable... if the data was decrypted then there was, at some point, the material to decrypt it present on the system. But more modern disk and file encryption solutions tend to use various solutions like the TPM and operating system features to avoid the key being available in memory.
Finally, as always, password reuse is an issue here. If you can get the key material there's a good bet it might work on other volumes as well if you can recompute for whatever the volume salt is... this may be more or less practical depending on how TrueCrypt/VeraCrypt derives the key which I don't remember well.
I am not sure why Elcomsoft would want to write a blog article informing the world of this fact...
Anyway, here is the direct link to how VeraCrypt does their RAM encryption:
* https://sourceforge.net/p/veracrypt/discussion/technical/thr...
It's mathematically impossible to prevent key extraction unless you put the key in an HSM (the TPM might function as such, but it may not have good performance) and use that for decryption (the most you can do is make the key larger up to the amount of RAM you have, at the costing of wasting RAM).
Even if you use an HSM, the malware can just extract the data itself or even on-the-fly decrypt the disk with the HSM and re-encrypt with a known key and then exfiltrate the known key, so all this does is make the attack slower since you need to read/write the whole disk.
That isn't to say RAM encryption doesn't have other benefits, but if your computer is unlocked and unattended, then yeah someone is going to be able to dump those keys one way or another especially if the system isn't tamper-safe (like a smart card aims to be).
Any mounted encrypted data has keys in RAM or an HSM. If you have access to inside of those, you have access to keys. This is not breaking anything.
You can encrypt or obfuscate data in RAM, but then the keys should be stored in disk, ram or HSM, which is subject to the same problem. Actually, TPM/secure enclave merely binds the key to the device, and doesn’t help with key extraction, since it trusts the root, unless you set a PIN, which makes automated access impractical, or a max number of trials.
I liked some posts in this blog, particularly the one on synology which turned out to be consequential, but I think the authors should title their posts more modestly.
—————————————————-
VeraCrypt FAQ answers a question on root privilege, reading RAM and support for TPM:
“No. Those programs use TPM to protect against attacks that require the attacker to have administrator privileges, or physical access to the computer, and the attacker needs you to use the computer after such an access. However, if any of these conditions is met, it is actually impossible to secure the computer (see below) and, therefore, you must stop using it (instead of relying on TPM).
If the attacker has administrator privileges, he can, for example, reset the TPM, capture the content of RAM (containing master keys) or content of files stored on mounted VeraCrypt volumes (decrypted on the fly), which can then be sent to the attacker over the Internet or saved to an unencrypted local drive (from which the attacker might be able to read it later, when he gains physical access to the computer).”
Two things:
1. I’m sure FileVault and BitLocker are also commonly used by criminals. In fact probably more so in the first instance, unintentionally, it given it’s enabled by default in modern MacOS.
2. It seems to imply VeraCrypt is commonly used by criminals. That might be true I guess, but I’d bet more non-criminals than criminals use VeraCrypt.
Maybe VeraCrypt just stands out more as a red flag rather than using native LUKS/FileVault/BitLocker for Linux/MacOS/Windows accordingly.
I also don’t see what elcomsoft have to gain by writing these blogposts? Who are their target audience?