62
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Sep 2023
62 points (91.9% liked)
Linux
47228 readers
795 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
I second this.
Full disk encryption is entirely practical for everyday use. If you don't already have a dedicated TPM, your motherboard/CPU may provide a software TPM (fTPM?). If so, you don't even have to interact with the machine during boot. It's just a bit slower to start up (by a few seconds), which really isn't a big issue for your average user.
Pardon my ignorance here, but I don't get it how is the whole thing still safe with unlocking from TPM instead of me providing the password at boot time?
Considering now anyone can just boot the machine into the installed system then bruteforce/exploit something to get login/get read permissions and make a plain copy of the data?
Where, without tpm, as long as I do not type in the encryption password myself I have a pretty high guarantee that the data is safe, especially when I am not at the (powered down) computer.
This is what I don't understand either. It seems like with tpm it only protects the data from someone taking or copying the hard drive, but the bigger risk seems like what you describe
plus, using an encryption password and then automatically logging in the user prevents needing to enter two passwords while still keeping the data secure as long as the machine is off
You have a competent grasp of the situation
The idea behind it is that the files are stored encrypted at rest, which is really what you want, because once a system is booted, you have to play by the computer's rules (respect file permissions, policies, etc.).
The TPM provides a secure mechanism to provide a decryption key to the computer during boot, eliminating the need for direct interaction.
Could it be compromised? Probably, but it would take considerably more effort than a man-in-the-middle on your keyboard via a logic analyzer.
This is a common misunderstanding insofar as how encryption works. You can't flick a bit and TURN your storage unencrypted nor can you plausibly make your computer obey restrictions.
If your storage is encrypted it remains encrypted always including the file you have open right now. Your takes a plausibly length usable string and uses it to compute or retrieve the long binary number actually needed to decrypt your files. This number is stored in memory such that encrypted files can be decrypted when read into memory.
Once that key is loaded in memory anyone with 10 minutes and access to google could trivially unlock your computer in several different ways. It is virtually exactly like having no security whatsoever.
If you don't actually enter a passphrase to unlock you have no meaningful security against anything but the most casual unmotivated snooping.
Your little sister might not be motivated enough to read your diary but the dipstick that stole your laptop will definitely be spending your money.
I highly doubt it.
If you have any tips for how I can personally bypass my computer's encryption in 10 minutes without being able to login, I'd love to try my hand at it.
You aren't actually asking to how to bypass encryption because the key is already in memory. You are asking about the much simpler task of compromising a computer with physical access to same. Depending on configuration this can be as ridiculous as killing the lockscreen process or as hard as physically opening the case chilling the contents of ram enough that data survives transfer to different physical hardware. See also the massive attack surface of the USB stack.
That doesn't sound trivial at all.
On most systems you can press a hotkey in grub to edit the Linux command line that will be booted and in about 7 keystrokes gain access to any unlocked filesystem. Asking how you can break into a system you physically control is like asking how many ways you could break into a house supposing you had an hour alone with a crowbar the answers are legion. No machine in someone else's hand which is unlocked can possibly be deemed secure.
Even dumber no installer will create such an insecure configuration because the people that design Linux installers are smarter than you.
I'm not advocating for this right now, but yes that is why when using TPM password, one must insure to enable secure boot, enable bios password, disable boot media, and disable grub editing. That's the recommended proceedure for this setup.
This is essentially how HEADs works too. Some very smart people have worked on TPM boot and it is even built into systemd. You're just wrong here.
Reference:
Whether I would fully rely on the systems proper operation against a state sponsored adversary is a different question though.
Here is an alternative Piped link(s):
Matthew Garrett - TPM based attention
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
Ah yes security brought to you by the same folks who brought you "bypass encryption by holding down the enter key" and "name your user 0day to get root access"
It's like putting security cams and interior locks all over your house instead of locking the front door. If your storage can't be read without the passphrase then NOTHING can fail in such a way as to provide access. Simplicity and obvious correctness have virtues.
There isn't much reason to use anything other than FDE with a sufficient passphrase, auto login so the user doesn't have to type two distinct passwords, and go luks suspends to evict key from memory on suspend.
Boot up enter the passphrase -> see your desktop -> close the lid -> open the lid -> enter your passphrase
I don't think you understand the TPM chain, there is absolutely value in validating that the firmware, bootloader, kernel, and initramfs haven't changed and not decrypt the disk if they have. That's what the TPM does, it doesn't just store a key, it calculates it.
Obviously, the optimal setup is TPM calculation + passphrase, which completely avoids decrypting the drive if some compromise, or modification, happened somewhere in the bootchain, or if the disk is taken out of the computer.
I never suggested there wasn't value in the TPM for anyone although I think such validation has small value for most folks use case. Normal users are worried about theft of laptop by criminals not spies bugging their machine. I suggested that any configuration without a passphrase was inherently insecure.
It's not an "optimal setup" its the only setup that makes even the slightest sense because the alternative configuration can be defeated by a smart 12 year old with access to google.
Though after a point rubber hose cryptanalysis will become the more pragmatic option for an attacker.
Depends on the attacker. For example: In Europe, law enforcement can legally confiscate/steal your laptop and read out the keys from RAM. They can't (legally) force you to give up your password.
I can say with full confidence this is something you'll never actually need to worry about. Law enforcement isn't just going to grab laptops and pull keys. Plus, it's easier for them to grab the laptop while it's logged in anyways. 😐
I know of several instances where laptops where confiscated and I wouldn't put it past law enforcement to know how to extract the keys.
Actually, thinking more about this...
Can you give an example of this grub cmdline bypass? If what you're saying is true, this would be a huge issue. I'd switch bootloaders over something like this.
You can disable editing and enable password in grub, done. That's the recommended proceedure for TPM boot.
Finally, someone reasonable.
You can google lets drop all the crap you think you understand but don't use simple logic. Unencrypted data isn't secure against physical access. If your data is automatically unencrypted without benefit of entering a passphrase then its not actually secure. There's no free lunch.
Lol, holy hostility, Batman.
I know there's no such thing as a free lunch. That's why I purchased a TPM for my machine. Anyway, if your intent is to prevent someone from sticking your HDD into another machine to extract your data, FDE ticks that box. If you're worried about highly advanced attacks to find your kiddie porn collection, then you probably are justified in your paranoia.
Security is about understanding reasonable threat models. 99.99% of reasonable threats to your machine involve theft or loss of the entire machine and personal data or accounts being accessed. This doesn't require advanced attacks or paranoia nor does it require extreme measures to protect against. No installer will create such a configuration without a passphrase because its a simple and effective step to take to protect your data that is enforced by systems created by people who are all smarter than you.
Your cute statement about child porn is tasteless and thoughtless. I don't take reasonable precautions like taking 5 seconds to type a password because I'm paranoid or criminal I do so because I have basic common sense.
"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." https://en.wikipedia.org/wiki/Nothing_to_hide_argument
A thief is going to steal your computer and gut it, not apply liquid nitrogen to your RAM and attach a bunch of instruments with hopes of extracting a crypto key so he can have a small chance at accessing potentially interesting data.
If you think a thief is going to do more, your threat model is very skewed. I suspect that you think you're much more interesting than you actually are.
But it was cute.
You asked for details and pick on the unlikely measure of cold boot but ignore the fact that in most configurations you can press the letter "e" to edit the boot up command line. It wasn't "cute" it made you look like a gross human being.
Lol, whatever.
TPM is only kinda related to FDE, in that it can be used to unlock a LUKS encrypted volume. FDE doesn’t require a TPM.
I also wouldn’t recommend automatically unlocking your root partition on boot using the TPM as this allows access to your data if the device is stolen, which, for an average user, defeats the main purpose of FDE.
How so? The data is still encrypted on the drive after boot, so unless your machine also automatically logs you in, there shouldn't be anything to worry about.
At that point you relying on the fact that nothing running in your machine at boot can be compromised - after all, everything running on your machine has access to your unencrypted data.
If you don’t automatically unlock using the TPM, an attacker only has access to encrypted data.
Very true, which is why it's important to run as few services and have a locked down firewall. Maintaining a minimal attack surface is everything.
If the attack involves stealing the machine it has been demonstrated that you can ice the ram and swap it into another machine without data loss, recover the keys, and access the drive.
If we're talking apt adversaries it's also possible to just build a ram sniffer
While true, I think most people's concern is that their laptop is stolen and along with it all the access details for their email, online banking and so on.
If you're doing things that mean you're going to be the target of people with the knowledge, time, and technology to freeze the RAM and attempt to recover the data, you're presumably already well aware of those (and other) dangers anyway.
Those people need to learn how to fend of these attacks somewhere, too.
I guess my point was that if you're going to use FDE and unlock the disk without a password, don't bother hardening against attacks that involve stealing the whole machine.
Agreed that this is almost fiction level paranoia.
As others explained: If the FDE key is in RAM, I'm vulnerable. My thread model includes a stolen Laptop with the attackers able to freeze my RAM and reading out the keys.
Thank you for mentioning TPM though. Didn't know of that before. :)
There are plenty of reasons to not want FDE or not want just FDE alone. Shared computer, your data isn't safe if you share the FDE password with another user who needs to share the system. He said he's paranoid, so he is wanting his data encrypted above all. Home directory encryption, especially on top of FDE, while a performance hit, would do well for that. But most importantly, he said FDE isn't practical for him, end of FDE story.
That's a very absolutist way to look at a situation. It's equally likely (in fact, much more likely) that OP is missing a detail or two about FDE, and we won't know for sure until we discuss it.
The question was specific to systemd-homed. Jumping to why isn't FDE good enough for you isn't even logical. Sure they changed direction later, but it is not what was originally asked. In answering the primary question, additional questions from the OP may have arisen, which is fine. What is not fine is to assume incompetence from the start, which is what ya'll were doing.