[opensuse] Encrypted swap with random key no longer working in Leap-15.1?
Hello, For many years, I am using encrypted swap partition with a random key to avoid typing the password at boot time. Now I reinstalled openSUSE Leap 15.1, and this no longer works. I always have to type the password when booting. This is well documented in crypttab(5) and I am using it like this: raven:/ # grep swap /etc/crypttab cr_ata-ST3250310AS_6RYB6W7W-part7 UUID=a71035e1-abe3-4cb0-bee9-af42787c40cf /dev/urandom swap raven:/ # Any ideas/suggestions how to track this down? -- Josef Wolf jw@raven.inka.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/30/19 3:52 AM, Josef Wolf wrote:
Now I reinstalled openSUSE Leap 15.1, and this no longer works. I always have to type the password when booting.
Yes, it still works. I'm using on Leap 15.2Alpha (in a virtual machine). I don't think I have tested on 15.1, but I'm sure it still works there too. What has changed, is that the installer doesn't support it, so you cannot set it up during install. You need to set it up manually after the install. And then there's the additional problem -- once LUKS, always LUKS. The system sees the LUKS header, and treats it as a LUKS encrypted partition instead of a plain dmcrypt partition.
raven:/ # grep swap /etc/crypttab cr_ata-ST3250310AS_6RYB6W7W-part7 UUID=a71035e1-abe3-4cb0-bee9-af42787c40cf /dev/urandom swap raven:/ #
That won't work. You need to replace that "UUID=some-funky-string" with "/dev/disk/by-id/different-funky-string" Maybe it just needs to be "/dev/disk/by-id/ata-ST3250310AS_6RYB6W7W-part7" but best to check that this works. You can't use UUID to identify the randomly encrypted swap partition, because the UUID is randomly changed every time (once you get it working). Go into Yast Bootloader -- the kernel parameters tab. There may be a resume=some-string to resume from swap. Best to change that to "noresume", since resume from hibernation won't work with randomly encrypted swap. Once you have made those changes, I suggest you reboot to make sure everything still works. And you will still need to provide the password for this reboot. If all is fine, then: swapoff -a #disconnect swap dd if=/dev/zero of=/dev/disk/by-id/ata-ST3250310AS_6RYB6W7W-part7 count=1000 That should zap the LUKS header on the swap partition. Then reboot and you should have it working as you want. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 17.50, Neil Rickert wrote:
On 8/30/19 3:52 AM, Josef Wolf wrote:
Now I reinstalled openSUSE Leap 15.1, and this no longer works. I always have to type the password when booting.
Yes, it still works. I'm using on Leap 15.2Alpha (in a virtual machine). I don't think I have tested on 15.1, but I'm sure it still works there too.
...
You can't use UUID to identify the randomly encrypted swap partition, because the UUID is randomly changed every time (once you get it working).
That makes me wonder about the benefits of the random key. If you are using encrypted swap, you probably are also using encrypted root and data partitions. In that case, you can store a fixed crypto key in one of those - being encrypted partitions, they can not be read by a hacker offline. And then hibernation should also work (not tested). -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/30/19 1:00 PM, Carlos E. R. wrote:
That makes me wonder about the benefits of the random key. If you are using encrypted swap, you probably are also using encrypted root and data partitions.
That's not necessarily true. Before I retired, I had a work computer that I wanted to be able to boot/reboot unattended. That means that an encryption key cannot be provided during boot. I set it up to use an encrypted home directory (with "ecryptfs"). But ecryptfs can use swap, so I also used randomly encrypted swap. It worked pretty well. I did not need to be there for it to be booted. But, of course, I was there if I logged into it, so I could handle crypto for the HOME directory. Actually, I could do that via ssh and a command line login. I made sure that "$HOME/.ssh" was available whether or not the home directory was decrypted. I logged in with ssh and public key authentication. Then I used "ecryptfs-mount-private" to make the encrypted home directory visible, providing the login key of the ssh session. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEv7/MJoKYXv2p0PaIZJcsjNEnCIUFAl1pva4ACgkQZJcsjNEn CIVHBAf+KLWeWQJOqFAfXTKNlaxK8znFu6h/DmGfSqb8rH7aQ7Cxh9AF/cM4f4FF 0cSWZp+d8pM8yMA7chlXk3mRXwgqj3qegFPg/G5LxEWfGQ9NirMCLdL0ZoL8esbY RynPIEZbocjIotrtjmdSil24eRVVHPs6OimgzpFEyUTxZ5LgTqb8VADUA7DXdhOo 5n9nXDACgKs0+6uGYsgO7P2B6H+jaMp/SdiqPOlTpg6SyYQkoCkHbt9e22JL0I2r LSK+jlryHc5gUBK9cu4Owf4kXK7orqBYCbA7dgDFQhkk49qNoDq90yYZi/SrcSz9 hUnQWArEBNscZFH39vZlx2yKPITjuA== =gXuK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/30/2019 07:22 PM, Neil Rickert wrote:
That's not necessarily true.
Before I retired, I had a work computer that I wanted to be able to boot/reboot unattended. That means that an encryption key cannot be provided during boot.
I set it up to use an encrypted home directory (with "ecryptfs"). But ecryptfs can use swap, so I also used randomly encrypted swap. It worked pretty well. I did not need to be there for it to be booted. But, of course, I was there if I logged into it, so I could handle crypto for the HOME directory. Actually, I could do that via ssh and a command line login. I made sure that "$HOME/.ssh" was available whether or not the home directory was decrypted. I logged in with ssh and public key authentication. Then I used "ecryptfs-mount-private" to make the encrypted home directory visible, providing the login key of the ssh session.
One of these days I will have to try encrypted drives. Since SSD will take most of the sting out of the overhead, it may be a good addition. But I always keep coming back to "Why do I need it encrypted to begin with?" Sad, but there is nothing very interesting I worry about someone gaining physical control over a drive an getting. If it's important, it's already encrypted. Why I would want all the files in /opt and /bin and /usr encrypted -- just seems like a stretch. If it's really important, it doesn't even go on a computer :) -- David C. Rankin, J.D.,P.E.
On 07/09/2019 10.27, David C. Rankin wrote:
On 08/30/2019 07:22 PM, Neil Rickert wrote:
One of these days I will have to try encrypted drives. Since SSD will take most of the sting out of the overhead, it may be a good addition. But I always keep coming back to "Why do I need it encrypted to begin with?" Sad, but there is nothing very interesting I worry about someone gaining physical control over a drive an getting. If it's important, it's already encrypted. Why I would want all the files in /opt and /bin and /usr encrypted -- just seems like a stretch. If it's really important, it doesn't even go on a computer :)
Because it is easier to encrypt it all than parts of it. For example, you can encrypt /home, which what I do on my small laptop; but if I click view on a bank statement, it downloads it to /tmp, which is not encrypted. Other applications may do similarly; perhaps Libre Office (I don't know, I have to verify). The logs sometimes contain passwords to places; not normally, but I have seen them in some debug logs. The configuration files in /etc may contain mail passwords, too. So, what, encrypt /tmp, /var, /etc...? Rather encrypt it all. And I don't notice an impact on speed, anyway. I often encrypt backup media; for the same reason, there can be a file somewhere with a password or a bank statement. And the last one I did, I also used filesystem compression, with btrfs. No snapshots, just btrfs compression and LUKS encryption. It just happens that btrfs is the only openSUSE supported filesystem with compression. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 8/30/19 1:00 PM, Carlos E. R. wrote:
That makes me wonder about the benefits of the random key. If you are using encrypted swap, you probably are also using encrypted root and data partitions.
That's not necessarily true.
Before I retired, I had a work computer that I wanted to be able to boot/reboot unattended. That means that an encryption key cannot be provided during boot.
I see. Maybe the encryption key could be downloaded via network, using initrd. Just a wild idea. If the machine or its disks are stolen, they can not decrypt them.
I set it up to use an encrypted home directory (with "ecryptfs"). But ecryptfs can use swap, so I also used randomly encrypted swap. It worked pretty well. I did not need to be there for it to be booted. But, of course, I was there if I logged into it, so I could handle crypto for the HOME directory. Actually, I could do that via ssh and a command line login. I made sure that "$HOME/.ssh" was available whether or not the home directory was decrypted. I logged in with ssh and public key authentication. Then I used "ecryptfs-mount-private" to make the encrypted home directory visible, providing the login key of the ssh session.
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 09/07/2019 03:47 AM, Carlos E. R. wrote:
Before I retired, I had a work computer that I wanted to be able to boot/reboot unattended. That means that an encryption key cannot be provided during boot. I see.
Maybe the encryption key could be downloaded via network, using initrd. Just a wild idea.
If the machine or its disks are stolen, they can not decrypt them.
That's truly an excellent idea, Carlos! Windows computers can use TPM (Trusted Platform Module) chips on the motherboard for unattended reboots, but Linux doesn't seem to support them. But even so, the TPM thing only protects encrypted disks once removed from their home computers (as I understand it). There's no protection if the whole computer is stolen. A system with an encrypted disk, if it first prompted for a local password, then tried to download a key from a pre-selected location, would be great! I have no idea if it would be possible to do this kind of thing without BIOS modifications. What would be required, and would there be risks of leaking unencrypted bits? Alternatively, maybe the decryption key could be passed with the remote reboot command? Something like grub2-once? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2019 19.28, Lew Wolfgang wrote:
On 09/07/2019 03:47 AM, Carlos E. R. wrote:
Before I retired, I had a work computer that I wanted to be able to boot/reboot unattended. That means that an encryption key cannot be provided during boot. I see.
Maybe the encryption key could be downloaded via network, using initrd. Just a wild idea.
If the machine or its disks are stolen, they can not decrypt them.
That's truly an excellent idea, Carlos! Windows computers can use TPM (Trusted Platform Module) chips on the motherboard for unattended reboots, but Linux doesn't seem to support them. But even so, the TPM thing only protects encrypted disks once removed from their home computers (as I understand it). There's no protection if the whole computer is stolen.
A system with an encrypted disk, if it first prompted for a local password, then tried to download a key from a pre-selected location, would be great! I have no idea if it would be possible to do this kind of thing without BIOS modifications. What would be required, and would there be risks of leaking unencrypted bits?
Not bios. initrd. Same as it is possible to download the boot image from a remote machine using tftp.
Alternatively, maybe the decryption key could be passed with the remote reboot command? Something like grub2-once?
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 09/08/2019 12:32 PM, Carlos E. R. wrote:
A system with an encrypted disk, if it first prompted for a local password, then tried to download a key from a pre-selected location, would be great! I have no idea if it would be possible to do this kind of thing without BIOS modifications. What would be required, and would there be risks of leaking unencrypted bits? Not bios. initrd. Same as it is possible to download the boot image from a remote machine using tftp.
Good point, but it would have to be done with overall security in mind. After all, you went to the trouble of encrypting the disk, you don't want to waste the effort by compromising the decryption key. Obviously, something with PKI for authentication on both ends, with encrypted content would be needed. SCP with pre-placed public keys would be perfect. I wonder how much larger that would make initrd? BTW, is it time for this to go to a more appropriate list? Your idea really has merit, Carlos, and would solve a number of difficult problems that Linux faces in the Information Assurance (IA) universe that large corporations and governments face. Has someone already solved this problem: remote reboot of a whole disk encrypted computer, while preserving authenticity and security? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/09/2019 03.36, Lew Wolfgang wrote:
On 09/08/2019 12:32 PM, Carlos E. R. wrote:
A system with an encrypted disk, if it first prompted for a local password, then tried to download a key from a pre-selected location, would be great! I have no idea if it would be possible to do this kind of thing without BIOS modifications. What would be required, and would there be risks of leaking unencrypted bits? Not bios. initrd. Same as it is possible to download the boot image from a remote machine using tftp.
Good point, but it would have to be done with overall security in mind. After all, you went to the trouble of encrypting the disk, you don't want to waste the effort by compromising the decryption key.
Not a problem :-) If the key is false, the disk doesn't decrypt and the machine doesn't boot. At that point some emergency measures could trigger. Like an alarm, call for human assistance, I don't know. The disk can not be deciphered without the proper key, a wrong key does nothing bad. As for reading the key with a rogue machine installed in that LAN, that's a different problem. You could transmit the key with encryption with a pair of keys only known to the server and the machine that is booting, different for each machine. But having access to the client machine would give access to its key. So the countermeasure would be, if the client goes missing, then disable the corresponding key on the server. It is a game of measures and counter measures.
Obviously, something with PKI for authentication on both ends, with encrypted content would be needed. SCP with pre-placed public keys would be perfect. I wonder how much larger that would make initrd?
BTW, is it time for this to go to a more appropriate list? Your idea really has merit, Carlos, and would solve a number of difficult problems that Linux faces in the Information Assurance (IA) universe that large corporations and governments face. Has someone already solved this problem: remote reboot of a whole disk encrypted computer, while preserving authenticity and security?
But I don't work in that field, I just have ideas :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (6)
-
Carlos E. R. -
Carlos E.R. -
David C. Rankin -
Josef Wolf -
Lew Wolfgang -
Neil Rickert