Arch Linux

nomival

Member

Registered: 2023-09-29

Posts: 3

LUKS encryption security

Hello.

Suppose you a new phisical disk to a server where you must store sensitive data with the following commands:

1. get disks
lsblk

2. format and setup with luks2
cryptsetup luksFormat --type luks2 /dev/sdb

2. open it
cryptsetup luksOpen /dev/sdb safe_data

3. fill space with 0
dd if=/dev/zero of=/dev/mapper/safe_data status=progress

4. format it
mkfs.ext4 /dev/mapper/safe_data

5. mount it
mount /dev/mapper/safe_data /home/safe_data

6. copy data on it from secure web transfer

Now i am curious, suppose the server gets a shutdown/reboot (power outage) without manually running the `cryptsetup luksClose` cmd on a encrypted cointainer. Is there any posibility that you can access the data without entering the password because you did not closed the container?

You can have phisical access to the disk, dump ram memory or even using recovery software.

How about run-time attacks (having access to the server but not knowing user/pass to log in)?

Thank you.

frostschutz

Member

Registered: 2013-11-15

Posts: 1,647

Re: LUKS encryption security

I recommend using a partition instead of whole drive. Too many ways for a partition table to be created and then the LUKS header is wiped...

luksClose only clears the master key from memory (ram), it does not change on-disk data, so shutting down without luksClose is not an issue. It would be a problem if ram were stored persistently (suspend to disk) or some other means of dumping memory (virtual server).

How about run-time attacks (having access to the server but not knowing user/pass to log in)?

LUKS only offers at-rest protection, so if your system can be hacked at runtime, while LUKS containers are open, you're out of luck.

kermit63

Member

Registered: 2018-07-04

Posts: 371

Re: LUKS encryption security

After the 6 steps you mentioned, you should also consider backing up the luks header in case it gets corrupted for whatever reason.

---

Never argue with an idiot, they will drag you down to their level and then beat you with experience.
It is better to light a candle than curse the darkness.
A journey of a thousand miles begins with a single step.

Joedang

Member

From: Cascadia

Registered: 2020-05-17

Posts: 16

Re: LUKS encryption security

It would be a problem if ram were stored persistently (suspend to disk)

So, an unencrypted swap partition would be an example of how data or keys could be recovered from a drive, right?

nomival

Member

Registered: 2023-09-29

Posts: 3

Re: LUKS encryption security

I recommend using a partition instead of whole drive. Too many ways for a partition table to be created and then the LUKS header is wiped...

luksClose only clears the master key from memory (ram), it does not change on-disk data, so shutting down without luksClose is not an issue. It would be a problem if ram were stored persistently (suspend to disk) or some other means of dumping memory (virtual server).

How about run-time attacks (having access to the server but not knowing user/pass to log in)?

LUKS only offers at-rest protection, so if your system can be hacked at runtime, while LUKS containers are open, you're out of luck.

LUKS key would still remain in RAM, so it is kinda useless. From what i read on internet, you should store the KEY in CPU registry or maybe an external memory.

When i say run time, imagine that server is on and attacker does not know the user/pass to SSH connect to the machine. Assume the login password is very strong.

nomival

Member

Registered: 2023-09-29

Posts: 3

Re: LUKS encryption security

After the 6 steps you mentioned, you should also consider backing up the luks header in case it gets corrupted for whatever reason.

You rather back up data somewhere on different disk (different encryption maybe). It is a pain to recover from LUKS even with the headers.

loqs

Member

Registered: 2014-03-06

Posts: 18,928

Re: LUKS encryption security

LUKS key would still remain in RAM, so it is kinda useless. From what i read on internet, you should store the KEY in CPU registry or maybe an external memory.

Is decrypted access to the data on that server a requirement?

When i say run time, imagine that server is on and attacker does not know the user/pass to SSH connect to the machine. Assume the login password is very strong.

Is local password based access a requirement  Is remote password based access a requirement?