New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Actually it is quite easy. For a short while after it was released it was not, but the DDR4/DDR5 memory scrambler was reverse engineered. It's just a crappy LFSR and can be broken with the Berlekamp-Massey algorithm.
As for data remanence proper, you just have to chill the RAM for data to remain stable, which is quite easy with off-the-shelf computer duster. However most cold boot attacks these days don't involve physically removing the memory, but resetting the CPU into an alternate BIOS and then dumping the memory, which isn't particularly difficult if the alternate BIOS doesn't need to support anything other than the memory. That is more reliable than freezing and removing the memory because the memory is never actually powered down. Also, that technique even works with LPDDR5 which cannot be removed.
The only thing that can actually protect against a cold boot attack is TSME. Even hacks like TRESOR that hide disk encryption keys from RAM (in its case, by keeping them in the x86 debug registers) won't protect the page cache.
Look, I get that systems like LUKS is good for scrambling data in order to safeguard your privacy. No one will go extra mile for legitimate data extraction from encrypted storage. That's ridiculous. I do not argue about legitimate use of encryption. It makes people feel safe.
If you were perpetrator - the law organs will just deem you "guilty" by not unlocking encrypted device. "Not guilty, until proven otherwise" is Hollywood movie plot, not real life.
Those who says "they can't force me"... After being dragged by law enforcement for years, I bet they will reconsider this.
That depends heavily on your particular jurisdiction and particular circumstances.
In the UK with ample evidence against you? Well, at least you can be put in jail until you disclose the key (though most people are let out after several years when it's clear they won't disclose it). In the US? Unless the contents of your storage device is a foregone conclusion, you generally can't be made to disclose it. In North Korea with a smuggled laptop? You bet your ass you're gonna give up the key.
Do you know any safe haven for poor fck like me, who’s renting low end dedicated servers?
Unfortunately all that matters is your own jurisdiction and I have no idea where you live.
I heard performing cold boot attacks on newer DRAM generations is harder since the data fades out faster:
I get that it's still a valid concern. I had no idea it's possible to perform it also on soldered RAM. Obviously I have no experience with performing that kinds of attacks, but last time I heard about them performed in real world, it was with old DDR3 RAM.
TRESOR was working on like kernel 3.x and required patching the kernel manually. Not very maintainable long term, and the project is also dead as of now. Cool research experiment I guess.
A bit later, there was also TresorSGX - someone's master thesis which instead of "hiding" keys in debug registers, used SGX enclaves to perform drive encryption operations. However there the performance was severely limited by the netlink bus they used to send/retrieve data from enclave. Also SGX got deprecated since, so it's not really useful anyway.
btw my previous answer had nothing to do with this threat model.
The OP just asked for recommendations for disk encryption, which I personally don't associate with hiding anything from law enforcement agencies. I'm more concerned by poorly recycled drives or unauthorized access to the data by 3rd party after compromising the provider (happened a few times on LET already). I think those are similar concerns to what @MannDude mentioned as well.
If you have troubles with LE, I guess you have much bigger problems than just the disk encryption.
I don't think it's an option in the installer
Since cryptsetup 2.4.0 luksFormat should autodetect the optimal sector size, however I'm pretty sure both Alma and Debian still defaulted to 512 byte on my VMs.
From what I know, LUKS2 reencrypt allows to change the sector size but it also requires the sectors to be aligned properly. Personally I was not able to get it to work without corrupting LUKS container.
Ultimately, that's just one more reason why I use my own automated installation script for Debian (instead of the installer).
@oloke , aside of providers blunder to recycle storage on service termination - do you really think that encryption performance penalty (it is not big, but it IS) is worth the hassle?
Who gonna care for your data? I store a large amount of structured adult movies (mainly hardcore German stuff) backed from 2004 as I'am a data hoarder. From time to time I move it to new provider. But I never thought about encryption as measure to "safely keep data".
In your opinion, what other threat models exist in real world for encrypted storage?
This is getting scary close to "i have nothing to hide".
I understand that here, we're talking in the context of drive encryption in "the cloud" which probably matters less to regular people. However it looks like over the years Google and Apple really went through "the hassle" of implementing FDE by default on all devices.
Google even designed a new encryption scheme (
xchacha12,aes-adiantum,xchacha20,aes-adiantum) for LUKS2, optimized for low end mobile devices without hardware AES acceleration:eww... I don't think anyone would dare to even look at this 🫣
I don't think anyone would care about my personal things. However the situation may be different for others - especially enterprise which store data of their high value customers online.
I want to be able to advise them on the topic and recommended implementation to the best of my ability
Indeed, but that only matters if you're doing it the old-fashioned way and aren't freezing the RAM. With DDR2 and to a lesser extent DDR3, it used to be an issue that someone could grab your computer after you had powered it down and obtain the data from it for up to a few minutes. On those systems, the recommended solution was to stay with your system for several minutes after it had turned off. With DDR4 and DDR5 which fades in seconds, that particular threat has been effectively neutralized.
However, the threat of a cold boot attack being used as a way to get into a running system is still present and roughly the same whether the system uses DDR5 or DDR2.
I used to maintain a fork of TRESOR (and RamCrypt, which is based on TRESOR but encrypts the virtual memory of select processes) for modern kernels up until around the time TSME was released. I simplified the logic and improved security in a few edge cases, but ultimately I dropped it when I got a modern AMD processor. TSME is not faster, but it does hide everything rather than only the data on the block device that isn't in the page cache.
I experimented with that a bit as well, but it was amazingly slow. But nothing is as slow as one technique from years prior which hid the encryption keys in L2 cache by setting it to CAR (Cache-As-RAM) mode. That reduced performance by a factor of about 200 because the system literally had no L2 cache (and there was no L3 back then; L2 was the LLC)!
There was a company that was purchased by Facebook some time ago that had an additional trick up their sleeve: Moving the entire kernel into the cache! No idea how they managed to do that effectively.
Real hardware memory encryption should be mandatory in new processors. It's so useful. I'm sure they could reduce the latency if they chose something other than AES, but I get that they want to use industry standards (that people recognize).
Yeah, I heard about those attempts as well. Disabling CPU cache L2 entirely must've been a big performance hit
Oh, didn't know much about RamCrypt and its implementation. That's cool!
How is it not faster?
From my understanding the encryption process happens on the memory controller entirely and is Transparent to the CPU.
But yeah, that's definitely true. It's also the approach Intel went after Deprecating SGX on newer chips.
TME (Total Memory Encryption) was introduced later to not have to deal with lots of issues SGX had (mostly related to side-channel attacks on partially encrypted memory).
And most recently, Intel shifted their focus to a different approach lets each Virtual Machine have their own encrypted memory space with Intel TDX (something similar to AMD SEV-SNP with remote attestation).
However I'm pretty sure the adoption on the Intel side is still quite low.
Because TRESOR only hides the encryption key for the disk whereas TSME protects all memory, not only the disk encryption key. The throughput with TSME on and off is the same (I believe), but the latency is increased somewhat when it's enabled. So if your only goal is to protect the disk encryption key, TSME has a small overhead but TRESOR has no overhead (and sometimes actually improves performance, surprisingly, despite having to recalculate the round keys for each encryption). But of course TSME does more than just protect the disk key.
Another big issue with SGX is that it does not protect the host from a malicious enclave. The EEXIT instruction restores the host process' execution context (including RIP and RSP) from registers managed by the enclave, so a malicious enclave could attack the control flow of the host (https://eprint.iacr.org/2016/086.pdf section 5.2.4 Synchronous Enclave Exit).
SGX was just overall ill-conceived. When you look at it deeply, it's clearly just a crappy attempt to get "rights" holders to fawn over Intel for providing what is, in effect, a glorified DRM mechanism that is next to useless for anything else. They were envisioning it doing little more than decoding proprietary video streams.
Enable "expert mode" on the Debian installer, preload the cryptsetup component, then execute a shell and manually encrypt the desired partition. Then exit the shell. I'm pretty sure the partition manager will now let you use the encrypted partition.
Wowza. Is there any detailed tutorial?
@oloke can you share your magic script?