6 ms·

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromi

by _lvbh 2y ago

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

pclmulqdq 2y ago
On servers, it protects against someone stealing your disks (or stealing the raw bytes from your disks) and then booting them in a copy of your machine.
mcny 2y ago
> Entering a password on boot isn't even that much work It is on fedora. I wabt the latest packages and I want to install them with dnf offline upgrade but now I need to put in password twice once for the updates d again for next boot. If it is a server, I don't want to keep a monitor attached to it just to enter the password. I want the computer to just boot. There has to be a better way.
- bpye 2y ago
  Is the boot time password unlock occurring in GRUB or after the Linux kernel has started? If the latter you should be able to setup an SSH server to run in that early boot environment, that’s how I can remote unlock drives on NixOS.
- keeperofdakeys 2y ago
  > There has to be a better way. Probably Clevis and Tang, network disk decryption that can only decrypt if most of your servers are online. https://github.com/latchset/clevis https://github.com/latchset/clevis https://github.com/latchset/tang https://github.com/latchset/tang Or network decryption (SSH into initrd). https://github.com/gsauthof/dracut-sshd https://github.com/gsauthof/dracut-sshd
- johnisgood 2y ago
  There is: https://news.ycombinator.com/item?id=42734841 https://news.ycombinator.com/item?id=42734841.
- webstrand 2y ago
  There is, I use kexec to boot a modified cpio containing the fde password, since cpio can be extended by concatenation. https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981871bd7 https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981... It's the same technique grub uses to forward the FDE password to the initramfs after its own initial decryption (to read the kernel and initramfs). This works to reboot remote servers with FDE, without needing a vnc or earlyboot-sshd.
- prmoustache 2y ago
  I also use a fedora. Typically I use offline upgrade if I mean to poweroff but otherwise I just run `sudo dnf update -y && sudo systemctl reboot` in a terminal if I want a quick update&reboot. On another laptop I am using silverblue (well bluefin) and the atomic upgrades solve the issue completely.
Hakkin 2y ago
If a disk is encrypted, you don't have to worry about the contents if you eventually have to RMA or dispose of the disk. For this use case, it makes no difference how the encryption key is input.
- tommiegannert 2y ago
  I'd guess the most common scenario is for someone giving away the entire computer, not fiddle with components. Or theft of the full machine. This feels like one of those half-security measures that makes it feel like you're safe, but it's mostly marketing, making you believe *this* device can be both safe and easy to use.
  - lukeschlather 2y ago
    It's pretty fast to destroy all the keys in a TPM. Should take a minute if you know the right place to go. Meanwhile securely deleting a normal drive requires overwriting every sector with random data, which could take hours. So it also helps if you're giving away the whole machine.
    - SoftTalker 2y ago
      Smashing the disk with a hammer takes seconds. Or dropping it in a shredder. Used disks are not worth hours of time to overwrite with random data. Just physically destroy them.
      - DarkAtom 2y ago
        Or a furnace. That usually leaves no trace of the physical disk having ever existed, which may be important for <insert state actor/military here>.
      - minitech 2y ago
        That’s wasteful, inconvenient, and not even necessarily unrecoverable.
- 2y ago
dangero 2y ago
Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.
- prmoustache 2y ago
  That is what remote kvm are for and if you do that on commodity hardware you can start a tiny ssh server starting up from an initrd. Having said that an attacker with local access could change the initrd without your knowledge so that it logs the password you enter so it is not necessarily the most secure solution.
  - deno 2y ago
    You’ve answered it yourself. Without TPM you have no idea if you can provide the secret to the system or if it’s compromised. Whether that secret comes from TPM or network is secondary.
- tucnak 2y ago
  Google: IPMI, BMC
- teddyh 2y ago
  You can reboot your full-disk-encryption server while you sleep. Obligatory plug: <https://www.recompile.se/mandos https://www.recompile.se/mandos> Disclosure: I am a co-author of Mandos.
  - prennert 2y ago
    Has this solution been audited? In particular, is it safe to replay attacks by actors listening in to the network traffic? Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong?
    - teddyh 2y ago
      > Has this solution been audited? Only insofar as everybody that I’ve asked over the years has failed to find anything wrong with it. But no formal verification has been done. > In particular, is it safe to replay attacks by actors listening in to the network traffic? Yes, it is safe, since we make sure to only use TLS with PFS. > Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong? No, the secret is stored encrypted on the server, encrypted with a key which only the client ever has. For more information, see the introduction and FAQ: <https://www.recompile.se/mandos/man/intro.8mandos https://www.recompile.se/mandos/man/intro.8mandos>
sedatk 2y ago
Because I don't expect a random thief to go to the lengths of identifying OS level vulnerabilities to bypass the login prompt in order to decrypt the disk contents. The potential gains for them are marginal compared to the time and effort spent there, not to mention technical expertise needed. I expect them to steal it, and if it's encrypted, just sell it for parts, or wipe it and sell it anew. Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). Typos can take a toll too because of all the delays included.
- _blk 2y ago
  A weak password is always better than no password. It's like using a cheap lock on your door or not locking it. Practically, if a thief wants to get through he'll get through but your insurance and sentencing will look different.
  - sedatk 2y ago
    As I said before, if someone’s determined enough to spend a lot of time find OS level vulnerabilities and exploit them to decrypt my disk, they will certainly have enough time and determination to break a weak password.
- prmoustache 2y ago
  > Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). So does-it means you do not setup a password/passphrase for your user account?
  - nick__m 2y ago
    I use auto login (control userpassword2 still work to set that up on Windows11) on my gaming computer in the living room! If I could that user account wouldn't have a password. But my work computers requires a pin to boot and a password that only my yubikeys (bind the static password to the long press) knows to login. different policy for different context...
  - 2y ago
userbinator 2y ago
Between consciously encrypting with a user-supplied password, and not encrypting at all, automatic encryption seems more like a nuisance/hazard for recovery than anything else. Consciously encrypting with a password implies an understanding of the risk of permanent loss. Leaving it unencrypted implies an understanding of the risk of disclosure. Having your drive silently encrypted feels like the worst of both worlds. "I never encrypted or locked it, what do you mean my data is encrypted and gone forever!?"
baybal2 2y ago
[dead]
cyberax 2y ago
> I don't understand why anyone would use passwordless disk encryption. I'm using it on my home server that I'm using for self-hosting. This way, if it's stolen, the thief won't be able to easily get to my data. At the same time, I don't have to physically enter the password if my server reboots.
- jvdvegt 2y ago
  They'll have your data if they just take the whole server...
  - cyberax 2y ago
    And then what? They will be faced with a login prompt. Reading from disks is useless. My login password is strong.
    - akimbostrawman 2y ago
      Boot any Linux ISO and bypass any OS logins (secureboot would prevent this), connect devices over IO to otherwise exploit the login or just dump RAM content to potentially get data or even keys. I would never trust OS login over FDE especially on desktop.
      - akimbostrawman 2y ago
        EDIT: first point won't work on second thought
udev4096 2y ago
It's just not practical. How are you going to manually enter the password for let's say 10 servers?
- johnisgood 2y ago
  USB pendrive with random key, no need to enter anything and is more secure and gives you plausible deniability through many different means.
  - cedilla 2y ago
    Going around 10 servers with a USB drive sounds just as tedious, and what happens when you lose the key or the attacker gets it?
    - johnisgood 2y ago
      You generate a new one and replace it. Those what ifs apply to passwords as well. It might sound tedious for 10 servers, but passwords are even more so. For desktop, it is definitely the way.
coppsilgold 2y ago
Passwordless TPM FDE effectively "pairs" your HDD(s) with the TPM module such that the data on the drive(s) is inaccessible without it or a strong LUKS password if added. Using even a weak pin/password will allow you to both "pair" and "secure" assuming the TPM is configured to destroy the key on multiple failed attempts. You should also add a strong (high entropy) LUKS password to allow data recovery in case the TPM chip is lost or the keys are destroyed. Note that the bits of the encryption keys are present somewhere in the TPM and could in theory be extracted with an exploit or with scanning probe microscopy perhaps.
johnisgood 2y ago
You do not even need to enter a password. Use a randomly generated key. Retrieve it from an USB drive at boot (it does it automagically), which contains everything, giving you full plausible deniability without it. It means literally everything you need to boot up is on the USB drive, and if you so want it, you can use 2 separate USB drives. This is for computers you have physical access to, of course. You will need to carry the USB disk if it is a laptop, but you choose: you want to enter a password (which by itself gives you no plausible deniability BTW), or you want plausible deniability and/or you don't want to enter a password. And while we are at it, laptops (and even desktops) today have SSD, and encryption and plausible deniability is different for an SSD, but again, you choose. Right tool for the job. https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti...
- DarkAtom 2y ago
  A password can definitely give you plausible deniability. Look at VeraCrypt, for example. In a sense it's less secure because it can be seen being typed by others or by cameras and is vulnerable to hardware (and sometimes even software) keyloggers. On the other hand, a USB drive can be stolen and can also make you vulnerable to extortion. It's harder to make someone give up information in their brain then to give up a USB drive.
fulafel 2y ago
Try having a chat with a HCI person. Or in a pinch ask a LLM to emulate one for you. It's a useful perspective to have for a lot of stuff.
logifail 2y ago
> I don't understand why anyone would use passwordless disk encryption You want to install and operate a device at a remote site with restricted (or no) VPN access and where you don't trust the local staff?
- artiscode 2y ago
  A remote KVM, i.e TinyPilot will help avoid dealing with lack of trust in local staff. Additionally connection to the KVM can be done over LTE/Cellular if you don't trust the local connection too.
  - logifail 2y ago
    I set up a server last year which is at a remote site which is completely air-gapped from the Internet, it's allowed to see one local LAN and that's all. For any kind of admin task someone has to drive to site. There is precisely zero chance that the relevant IT security goons would allow any kind of remote KVM/LTE connection.
  - nh2 2y ago
    How does this make sense? Any change the untrusted local staff could make to the server, they could also make to the KVM machine (e.g. turn it into a keylogger). Now you have the same problem but with a smaller computer. You cannot turn untrusted systems into trusted systems by adding more untrusted systems.
usr1106 2y ago
Some systems need to boot without a (trusted or skilled) user present.
michaelt 2y ago
Imagine a big corporate workplace, where the infosec team wasn't comprised of freewheeling anarchic hacker types who've dedicated their career to mastering the intricacies of the Linux boot process, but instead by compliance folks who've dedicated their career to mastering the intricacies of global privacy laws and passing SOC2 compliance audits. From their perspective, "Secure Boot" has the word "Secure" right in the name. And they've looked up details about the TPM - Microsoft says the TPM avoids systems being tampered with, and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices. If you don't know the intricacies involved, that stuff all sounds great! So they put a line into the corporate IT policy that TPM use is mandatory.
jrockway 2y ago
It's always felt like the best way to lock myself out of my own machine. While I don't really keep any important data on it that's not backed up, I also don't build my workstation image from a config file or anything, so some time will be lost. The thing that's always bugged me is that before AMD had a TPM built into the CPU, the TPM was just a poorly-secured dongle hanging off the motherboard (at least with Asus motherboards) and it just seems like something that's going to break randomly. That breaks, then what. Meanwhile, the CPU owning the keys also doesn't feel great. Sometimes you swap your CPU and now there is an 800 step process to disable decryption before you do that, which is certain to be forgotten as you excitedly unpack your new CPU purchase. (Even if you're completely rebuilding the computer, the number of times I've put a new disk into a new build is approximately zero.) Just typing a passphrase at boot seems like a pretty decent compromise. I've done it for years and it's never caused a problem.
- vladvasiliu 2y ago
  I sympathize with your points, especially rebuilding the box from scratch. But all the “passwordless” schemes I’ve seen support at least an additional “master key” which you can type in. So if you’re ok with the security tradeoffs of passwordless tpm, it’s only an added convenience on top of your approach.
- _verandaguy 2y ago
  This was actually a problem for me on my current gaming PC build! I had switched to a new AM4 mobo a few years back and decided to spring for a pluggable TPM chip (since the CPU I have doesn't come with TPM onboard). Plugged it in, set everything up pretty seamlessly in windows, no fuss, no muss, boot drive's encrypted transparently. The lack of a password was a bit jarring at first, but it's a gaming PC, so if things go pear-shaped it's not the end of the world. Fast forward six months and my PC suddently refuses to boot; turns out the pluggable TPM thing was defective and stopped working (without any warning that got surfaced to me). It was just my boot drive, and reinstalling windows isn't a huge hassle, but it definitely cemented my mixed feelings about passwordless FDE. Had that been the drive I use for my photo library, or my software projects, or work-related documents (tax slips, employment contracts, whatever), that would've been devastating. It's actually made me rethink the strategy I use for my laptop's backups, and I think I'm in a better place about that now.
AzzyHN 2y ago
I believe with software-based encryption (LUKS and the like), the decryption key ends up being stored in RAM, which will always present a risk. And TPM-based solutions don't have this problem. Could be wrong though.
- kevincox 2y ago
  I think most TPM based solutions still use software encryption. Most TPMs don't have the bandwidth to actually decrypt all disk data as it is read. (I think Apple devices do actually do something like this, but I don't think it is common.) I believe when using TPM with LUKS the TPM just decrypts the master key and that is handed back to the OS and used in software. So the primary key does end up in RAM.
toast0 2y ago
I would consider it for my hosted server. Entering a password on boot is a lot of work, because I need to vpn in, and run a java webstart kvm application (serial over ipmi would work better, but it doesn't work well on the hardware I have). Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. But I assume I would be able to clear the TPM (if present) when I return the machine. And I could store a recovery key somewhere I think is safe in case of hardware issues (although, last time I had hardware issues, I simply restored from backup to new to me disks)
- cuu508 2y ago
  > Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. Couldn't you wipe the disks yourself? Or are you thinking of cases where the disk breaks, gets replaced, and the removed disk does not get properly destroyed?
  - toast0 2y ago
    Sometimes yes, but if there's a hardware issue, I may not be able to. Ex: the first server I had failed and they ended up replacing it with a different server with similar specs, but the drives werem't moved. In this case, the failure was gradual (resetting by itself) and as part of debugging it, I wiped the drives and installed a new OS, but towards the end, the amount of time between resets was very short, and I wouldn't have had a chance to wipe it if I had started later. Yes, this isn't great service, but it's personal hosting and it's cheap and I get a whole (very old) machine.
- gizmo 2y ago
  Dropbear is the solution for this.
  - toast0 2y ago
    Well, if the FreeBSD installer would set that up for me, I probably would have done it that way, but lazy, and I don't reboot that often.
pg5 2y ago
Fully agree, especially for a laptop. A password that combines three unrelated words and a few numbers takes about 3 seconds to type in. I shut it down every day, so type in the password every day too. Short of a concussion, I'm not going to get locked out.
- booi 2y ago
  So.. it is possible…
  - pg5 2y ago
    Yes.. it is... It's a risk I'm fine with. Anything I care about is backed up separately.
surajrmal 2y ago
Full disk encryption is just inherently a flawed approach compared to per file encryption. Androids approach of only protecting user data with behind the password and otherwise using a separate encryption key to allow the os to boot to the lock screen and some apps to run (eg alarms) is a more user friendly approach. Unfortunately we don't seem to have that sortve option available to us with desktop OS.
- betaby 2y ago
  > Unfortunately we don't seem to have that sortve option available to us with desktop OS. As I understand MacOS uses per file encryption on AFS.

by _lvbh 2y ago

pclmulqdq 2y ago

On servers, it protects against someone stealing your disks (or stealing the raw bytes from your disks) and then booting them in a copy of your machine.

mcny 2y ago

> Entering a password on boot isn't even that much work It is on fedora. I wabt the latest packages and I want to install them with dnf offline upgrade but now I need to put in password twice once for the updates d again for next boot. If it is a server, I don't want to keep a monitor attached to it just to enter the password. I want the computer to just boot. There has to be a better way.

bpye 2y ago
Is the boot time password unlock occurring in GRUB or after the Linux kernel has started? If the latter you should be able to setup an SSH server to run in that early boot environment, that’s how I can remote unlock drives on NixOS.
keeperofdakeys 2y ago
> There has to be a better way. Probably Clevis and Tang, network disk decryption that can only decrypt if most of your servers are online. https://github.com/latchset/clevis https://github.com/latchset/clevis https://github.com/latchset/tang https://github.com/latchset/tang Or network decryption (SSH into initrd). https://github.com/gsauthof/dracut-sshd https://github.com/gsauthof/dracut-sshd
johnisgood 2y ago
There is: https://news.ycombinator.com/item?id=42734841 https://news.ycombinator.com/item?id=42734841.
webstrand 2y ago
There is, I use kexec to boot a modified cpio containing the fde password, since cpio can be extended by concatenation. https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981871bd7 https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981... It's the same technique grub uses to forward the FDE password to the initramfs after its own initial decryption (to read the kernel and initramfs). This works to reboot remote servers with FDE, without needing a vnc or earlyboot-sshd.
prmoustache 2y ago
I also use a fedora. Typically I use offline upgrade if I mean to poweroff but otherwise I just run `sudo dnf update -y && sudo systemctl reboot` in a terminal if I want a quick update&reboot. On another laptop I am using silverblue (well bluefin) and the atomic upgrades solve the issue completely.

Hakkin 2y ago

If a disk is encrypted, you don't have to worry about the contents if you eventually have to RMA or dispose of the disk. For this use case, it makes no difference how the encryption key is input.

tommiegannert 2y ago
I'd guess the most common scenario is for someone giving away the entire computer, not fiddle with components. Or theft of the full machine. This feels like one of those half-security measures that makes it feel like you're safe, but it's mostly marketing, making you believe *this* device can be both safe and easy to use.
- lukeschlather 2y ago
  It's pretty fast to destroy all the keys in a TPM. Should take a minute if you know the right place to go. Meanwhile securely deleting a normal drive requires overwriting every sector with random data, which could take hours. So it also helps if you're giving away the whole machine.
  - SoftTalker 2y ago
    Smashing the disk with a hammer takes seconds. Or dropping it in a shredder. Used disks are not worth hours of time to overwrite with random data. Just physically destroy them.
    - DarkAtom 2y ago
      Or a furnace. That usually leaves no trace of the physical disk having ever existed, which may be important for <insert state actor/military here>.
    - minitech 2y ago
      That’s wasteful, inconvenient, and not even necessarily unrecoverable.
2y ago

dangero 2y ago

Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.

prmoustache 2y ago
That is what remote kvm are for and if you do that on commodity hardware you can start a tiny ssh server starting up from an initrd. Having said that an attacker with local access could change the initrd without your knowledge so that it logs the password you enter so it is not necessarily the most secure solution.
- deno 2y ago
  You’ve answered it yourself. Without TPM you have no idea if you can provide the secret to the system or if it’s compromised. Whether that secret comes from TPM or network is secondary.
tucnak 2y ago
Google: IPMI, BMC
teddyh 2y ago
You can reboot your full-disk-encryption server while you sleep. Obligatory plug: <https://www.recompile.se/mandos https://www.recompile.se/mandos> Disclosure: I am a co-author of Mandos.
- prennert 2y ago
  Has this solution been audited? In particular, is it safe to replay attacks by actors listening in to the network traffic? Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong?
  - teddyh 2y ago
    > Has this solution been audited? Only insofar as everybody that I’ve asked over the years has failed to find anything wrong with it. But no formal verification has been done. > In particular, is it safe to replay attacks by actors listening in to the network traffic? Yes, it is safe, since we make sure to only use TLS with PFS. > Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong? No, the secret is stored encrypted on the server, encrypted with a key which only the client ever has. For more information, see the introduction and FAQ: <https://www.recompile.se/mandos/man/intro.8mandos https://www.recompile.se/mandos/man/intro.8mandos>

sedatk 2y ago

Because I don't expect a random thief to go to the lengths of identifying OS level vulnerabilities to bypass the login prompt in order to decrypt the disk contents. The potential gains for them are marginal compared to the time and effort spent there, not to mention technical expertise needed. I expect them to steal it, and if it's encrypted, just sell it for parts, or wipe it and sell it anew. Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). Typos can take a toll too because of all the delays included.

_blk 2y ago
A weak password is always better than no password. It's like using a cheap lock on your door or not locking it. Practically, if a thief wants to get through he'll get through but your insurance and sentencing will look different.
- sedatk 2y ago
  As I said before, if someone’s determined enough to spend a lot of time find OS level vulnerabilities and exploit them to decrypt my disk, they will certainly have enough time and determination to break a weak password.
prmoustache 2y ago
> Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). So does-it means you do not setup a password/passphrase for your user account?
- nick__m 2y ago
  I use auto login (control userpassword2 still work to set that up on Windows11) on my gaming computer in the living room! If I could that user account wouldn't have a password. But my work computers requires a pin to boot and a password that only my yubikeys (bind the static password to the long press) knows to login. different policy for different context...
- 2y ago

userbinator 2y ago

Between consciously encrypting with a user-supplied password, and not encrypting at all, automatic encryption seems more like a nuisance/hazard for recovery than anything else. Consciously encrypting with a password implies an understanding of the risk of permanent loss. Leaving it unencrypted implies an understanding of the risk of disclosure. Having your drive silently encrypted feels like the worst of both worlds. "I never encrypted or locked it, what do you mean my data is encrypted and gone forever!?"

baybal2 2y ago

[dead]

cyberax 2y ago

> I don't understand why anyone would use passwordless disk encryption. I'm using it on my home server that I'm using for self-hosting. This way, if it's stolen, the thief won't be able to easily get to my data. At the same time, I don't have to physically enter the password if my server reboots.

jvdvegt 2y ago
They'll have your data if they just take the whole server...
- cyberax 2y ago
  And then what? They will be faced with a login prompt. Reading from disks is useless. My login password is strong.
  - akimbostrawman 2y ago
    Boot any Linux ISO and bypass any OS logins (secureboot would prevent this), connect devices over IO to otherwise exploit the login or just dump RAM content to potentially get data or even keys. I would never trust OS login over FDE especially on desktop.
    - akimbostrawman 2y ago
      EDIT: first point won't work on second thought

udev4096 2y ago

It's just not practical. How are you going to manually enter the password for let's say 10 servers?

johnisgood 2y ago
USB pendrive with random key, no need to enter anything and is more secure and gives you plausible deniability through many different means.
- cedilla 2y ago
  Going around 10 servers with a USB drive sounds just as tedious, and what happens when you lose the key or the attacker gets it?
  - johnisgood 2y ago
    You generate a new one and replace it. Those what ifs apply to passwords as well. It might sound tedious for 10 servers, but passwords are even more so. For desktop, it is definitely the way.

coppsilgold 2y ago

Passwordless TPM FDE effectively "pairs" your HDD(s) with the TPM module such that the data on the drive(s) is inaccessible without it or a strong LUKS password if added. Using even a weak pin/password will allow you to both "pair" and "secure" assuming the TPM is configured to destroy the key on multiple failed attempts. You should also add a strong (high entropy) LUKS password to allow data recovery in case the TPM chip is lost or the keys are destroyed. Note that the bits of the encryption keys are present somewhere in the TPM and could in theory be extracted with an exploit or with scanning probe microscopy perhaps.

johnisgood 2y ago

You do not even need to enter a password. Use a randomly generated key. Retrieve it from an USB drive at boot (it does it automagically), which contains everything, giving you full plausible deniability without it. It means literally everything you need to boot up is on the USB drive, and if you so want it, you can use 2 separate USB drives. This is for computers you have physical access to, of course. You will need to carry the USB disk if it is a laptop, but you choose: you want to enter a password (which by itself gives you no plausible deniability BTW), or you want plausible deniability and/or you don't want to enter a password. And while we are at it, laptops (and even desktops) today have SSD, and encryption and plausible deniability is different for an SSD, but again, you choose. Right tool for the job. https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti...

DarkAtom 2y ago
A password can definitely give you plausible deniability. Look at VeraCrypt, for example. In a sense it's less secure because it can be seen being typed by others or by cameras and is vulnerable to hardware (and sometimes even software) keyloggers. On the other hand, a USB drive can be stolen and can also make you vulnerable to extortion. It's harder to make someone give up information in their brain then to give up a USB drive.

fulafel 2y ago

Try having a chat with a HCI person. Or in a pinch ask a LLM to emulate one for you. It's a useful perspective to have for a lot of stuff.

logifail 2y ago

> I don't understand why anyone would use passwordless disk encryption You want to install and operate a device at a remote site with restricted (or no) VPN access and where you don't trust the local staff?

artiscode 2y ago
A remote KVM, i.e TinyPilot will help avoid dealing with lack of trust in local staff. Additionally connection to the KVM can be done over LTE/Cellular if you don't trust the local connection too.
- logifail 2y ago
  I set up a server last year which is at a remote site which is completely air-gapped from the Internet, it's allowed to see one local LAN and that's all. For any kind of admin task someone has to drive to site. There is precisely zero chance that the relevant IT security goons would allow any kind of remote KVM/LTE connection.
- nh2 2y ago
  How does this make sense? Any change the untrusted local staff could make to the server, they could also make to the KVM machine (e.g. turn it into a keylogger). Now you have the same problem but with a smaller computer. You cannot turn untrusted systems into trusted systems by adding more untrusted systems.

usr1106 2y ago

Some systems need to boot without a (trusted or skilled) user present.

michaelt 2y ago

Imagine a big corporate workplace, where the infosec team wasn't comprised of freewheeling anarchic hacker types who've dedicated their career to mastering the intricacies of the Linux boot process, but instead by compliance folks who've dedicated their career to mastering the intricacies of global privacy laws and passing SOC2 compliance audits. From their perspective, "Secure Boot" has the word "Secure" right in the name. And they've looked up details about the TPM - Microsoft says the TPM avoids systems being tampered with, and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices. If you don't know the intricacies involved, that stuff all sounds great! So they put a line into the corporate IT policy that TPM use is mandatory.

jrockway 2y ago

It's always felt like the best way to lock myself out of my own machine. While I don't really keep any important data on it that's not backed up, I also don't build my workstation image from a config file or anything, so some time will be lost. The thing that's always bugged me is that before AMD had a TPM built into the CPU, the TPM was just a poorly-secured dongle hanging off the motherboard (at least with Asus motherboards) and it just seems like something that's going to break randomly. That breaks, then what. Meanwhile, the CPU owning the keys also doesn't feel great. Sometimes you swap your CPU and now there is an 800 step process to disable decryption before you do that, which is certain to be forgotten as you excitedly unpack your new CPU purchase. (Even if you're completely rebuilding the computer, the number of times I've put a new disk into a new build is approximately zero.) Just typing a passphrase at boot seems like a pretty decent compromise. I've done it for years and it's never caused a problem.

vladvasiliu 2y ago
I sympathize with your points, especially rebuilding the box from scratch. But all the “passwordless” schemes I’ve seen support at least an additional “master key” which you can type in. So if you’re ok with the security tradeoffs of passwordless tpm, it’s only an added convenience on top of your approach.
_verandaguy 2y ago
This was actually a problem for me on my current gaming PC build! I had switched to a new AM4 mobo a few years back and decided to spring for a pluggable TPM chip (since the CPU I have doesn't come with TPM onboard). Plugged it in, set everything up pretty seamlessly in windows, no fuss, no muss, boot drive's encrypted transparently. The lack of a password was a bit jarring at first, but it's a gaming PC, so if things go pear-shaped it's not the end of the world. Fast forward six months and my PC suddently refuses to boot; turns out the pluggable TPM thing was defective and stopped working (without any warning that got surfaced to me). It was just my boot drive, and reinstalling windows isn't a huge hassle, but it definitely cemented my mixed feelings about passwordless FDE. Had that been the drive I use for my photo library, or my software projects, or work-related documents (tax slips, employment contracts, whatever), that would've been devastating. It's actually made me rethink the strategy I use for my laptop's backups, and I think I'm in a better place about that now.

AzzyHN 2y ago

I believe with software-based encryption (LUKS and the like), the decryption key ends up being stored in RAM, which will always present a risk. And TPM-based solutions don't have this problem. Could be wrong though.

kevincox 2y ago
I think most TPM based solutions still use software encryption. Most TPMs don't have the bandwidth to actually decrypt all disk data as it is read. (I think Apple devices do actually do something like this, but I don't think it is common.) I believe when using TPM with LUKS the TPM just decrypts the master key and that is handed back to the OS and used in software. So the primary key does end up in RAM.

toast0 2y ago

I would consider it for my hosted server. Entering a password on boot is a lot of work, because I need to vpn in, and run a java webstart kvm application (serial over ipmi would work better, but it doesn't work well on the hardware I have). Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. But I assume I would be able to clear the TPM (if present) when I return the machine. And I could store a recovery key somewhere I think is safe in case of hardware issues (although, last time I had hardware issues, I simply restored from backup to new to me disks)

cuu508 2y ago
> Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. Couldn't you wipe the disks yourself? Or are you thinking of cases where the disk breaks, gets replaced, and the removed disk does not get properly destroyed?
- toast0 2y ago
  Sometimes yes, but if there's a hardware issue, I may not be able to. Ex: the first server I had failed and they ended up replacing it with a different server with similar specs, but the drives werem't moved. In this case, the failure was gradual (resetting by itself) and as part of debugging it, I wiped the drives and installed a new OS, but towards the end, the amount of time between resets was very short, and I wouldn't have had a chance to wipe it if I had started later. Yes, this isn't great service, but it's personal hosting and it's cheap and I get a whole (very old) machine.
gizmo 2y ago
Dropbear is the solution for this.
- toast0 2y ago
  Well, if the FreeBSD installer would set that up for me, I probably would have done it that way, but lazy, and I don't reboot that often.

pg5 2y ago

Fully agree, especially for a laptop. A password that combines three unrelated words and a few numbers takes about 3 seconds to type in. I shut it down every day, so type in the password every day too. Short of a concussion, I'm not going to get locked out.

booi 2y ago
So.. it is possible…
- pg5 2y ago
  Yes.. it is... It's a risk I'm fine with. Anything I care about is backed up separately.

surajrmal 2y ago

Full disk encryption is just inherently a flawed approach compared to per file encryption. Androids approach of only protecting user data with behind the password and otherwise using a separate encryption key to allow the os to boot to the lock screen and some apps to run (eg alarms) is a more user friendly approach. Unfortunately we don't seem to have that sortve option available to us with desktop OS.

betaby 2y ago
> Unfortunately we don't seem to have that sortve option available to us with desktop OS. As I understand MacOS uses per file encryption on AFS.