3

I tried changing my LUKS password.

Source I used: https://www.linuxexperten.com/content/how-do-i-change-my-luks-encryption-password-and-more

I have separate partition’s for Boot, Root, Swap & Home. To make sure which partitions had Luks:

blkid -t TYPE=crypto_LUKS -o device
/dev/sda5
/dev/sda6
/dev/sda7

Then checked how many slots were occupied for sda5.

$ sudo cryptsetup luksDump /dev/sda5 |grep Key.Slot

Key Slot 0: ENABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Apparently root can use the master key to add a new key:

$ sudo dmsetup ls --target crypt

swapfs  (254, 2)
rootfs  (254, 0)
homefs  (254, 1)

But then I said let me check the other partitions sda6 & 7 to see how many slots were occupied. There were two already occupied before changing the password.

$ sudo cryptsetup luksDump /dev/sda6 |grep Key.Slot

Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED


$ sudo cryptsetup luksDump /dev/sda7 |grep Key.Slot

Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

I know all three partitions had the same password. I did not have any other password for LUKS. Does this mean that “SOMEONE ELSE HAD ACCESS” to these other two partitions?

Improve this question

1 Answer 1

Reset to default
0

How many times do you have to enter your password during boot? If only once, it's possible one of the slots is being used to "chain" the encryption:

  1. You enter a password/phrase to unlock partition A
  2. Partition A has a file with a long, randomly-generated password (a key) for partitions B and C.
  3. Partitions B and C are unlocked automatically using the password from partition A.

You'd probably see evidence of this in /etc/crypttab, which would show the location of the key file.

PS: If someone wanted to covertly have access to your encrypted data and had enough access that they could install another key, they'd just take a copy of the master key. That would leave no evidence and allows decryption regardless of passphrase change. The only way to fix that is to re-encrypt the entire partition. (In short, LUKS works by using the passphrases to encrypt the master key. The master key is then used to encrypt the partition. This is why you can change a passphrase without having to re-encrypt the entire drive.)

Improve this answer
7
  • Sorry for the late reply. After changing the password. I made sure that all sda's had only one slot taken. Also all were on the same slot "0". But soon after that I could not log back in.
    – kika
    Oct 19, 2019 at 7:03
  • To answer your question. I have had several problems before while entering my password. Sometimes it takes 3-4 tries before logging in. Sometimes I can't log in at all. Its very strange even when you think your entering the same password correctly it still ends up being wrong. I had to reinstall twice. And even now on boot I still get a few incorrect tries. I have checked the slots again. Root has one slot taken but Swap has two.
    – kika
    Oct 19, 2019 at 7:06
  • If Swap has "0 &1" taken is this ok?? In reference to your PS Note: When you say " if someone had enough access that they could install another key" are you talking about physical access or through the internet.? Thanks and once again my apologies for the late reply.
    – kika
    Oct 19, 2019 at 7:18
  • @kika It's probably OK, especially if that's how the system install set it up. (Again, check /etc/crypttab and see if its mentioned there.) "Enough access" could be physical or over the Internet. That link you used actually shows a command that'd do it: dmsetup table --showkeys. Running that requires root access while the disks are unlocked (e.g., when the system is booted). Someone with the copy of that output can easily get around LUKS, without leaving any trace on the system.
    – derobert
    Oct 19, 2019 at 8:20
  • @ derobert Thanks I checked the file. I found this but not sure what it means. "The value of this variable is interpreted as a shell pattern. # Matching key files from the crypttab(5) are included in the initramfs # image. The associated devices can then be unlocked without manual # intervention. (For instance if /etc/crypttab lists two key files # /etc/keys/{root,swap}.key, you can set KEYFILE_PATTERN="/etc/keys/*.key" # to add them to the initrd.)
    – kika
    Oct 19, 2019 at 11:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .