Encrypt your swap devices, the safe and easy way

[Khaine]

Well I loaded linux back onto my server box, and used this script and it seems to work fine

One quick question tr -cd [:alnum:] < /dev/urandom 2>/dev/null | head -c $keysize prints uppercase chars, lowercase chars and digits. Wouldn't it be better to try and maximise the amount of characters used, to encrease the entropy? I don't know how to implement it, but having a password like JB{:5f|Z&%!s seems more secure than one deviod of symbols, if not because it increases the number of characters that could possibly be used.

[Cintra]

Everytime you log onto your computer the password is sent to PAM (Pluggable Authentication Module), which in turn encodes the password using a special algorithm. The encoded password is then compared to other pre-encoded passwords in a hidden database, and if it's a match - grants you the access to your user. And here lies the problem: PAM stores the password in plain text in the memory. Although the password is quite (very) safe within the memory, it can turn into a huge security problem if the memory residing the password(s) is cached to the swap device. An unauthorized user can then scan the swap devices for available passwords and, in worst case, gain full access to your system. This is something we don't want (do we? Wink).

Hei

Have just been reading through this thread and, not knowing much about PAM, ask myself the question - why does PAM leave an unencrypted copy of the password in memory in the first place - shouldn't something rather be done with PAM to fix that specific problem?

mvh

[Sachankara]

Everytime you log onto your computer the password is sent to PAM (Pluggable Authentication Module), which in turn encodes the password using a special algorithm. The encoded password is then compared to other pre-encoded passwords in a hidden database, and if it's a match - grants you the access to your user. And here lies the problem: PAM stores the password in plain text in the memory. Although the password is quite (very) safe within the memory, it can turn into a huge security problem if the memory residing the password(s) is cached to the swap device. An unauthorized user can then scan the swap devices for available passwords and, in worst case, gain full access to your system. This is something we don't want (do we? Wink).

Hei

Have just been reading through this thread and, not knowing much about PAM, ask myself the question - why does PAM leave an unencrypted copy of the password in memory in the first place - shouldn't something rather be done with PAM to fix that specific problem?

mvh

Well, as far as I understand; if you where to encrypt the passwords within the memory, you'd still be able to read the key used to encrypt the passwords, so it'd be useless. The only solution I see is to have a hardware device which generates the keys used for the password encryption, and that device musn't be able to be read. Instead, the passwords are sent through the device which encrypts them and then returns the encrypted password...

Although I could be wrong and the solution might even be as simple as overwriting the password within the memory once it has been verified...

Protecting your computer memory against direct physical access (reading) will always be a problem... If one gets access to it, you're f***ed anyway (for example, all keys used to encrypt your devices and similar are then easily readable)...

[Sachankara]

Well I loaded linux back onto my server box, and used this script and it seems to work fine

One quick question tr -cd [:alnum:] < /dev/urandom 2>/dev/null | head -c $keysize prints uppercase chars, lowercase chars and digits. Wouldn't it be better to try and maximise the amount of characters used, to encrease the entropy? I don't know how to implement it, but having a password like JB{:5f|Z&%!s seems more secure than one deviod of symbols, if not because it increases the number of characters that could possibly be used.

Yes, the more characters the better. But there's a problem: many of the characters have special meanings in *nix, like the pipe sign |, or quote ". Those characters can't be used for the keys, and since only A-Za-z0-9 are characters that one can trust, those are the ones that I use.

Of course I could implements something like "A-Za-z0-9#,.!{}()[]+-_:*~", but I don't know if it truely does any difference. As long as you don't have a true hardware randomization device, your passwords will be predictable, even if the chances are very small (minescule? <- spelling?).

[Master One]

I am just getting into that encryption matter, and I was wondering:

1. On most machines with large amount of RAM (> 512 MB), swap gets hardly used at all, so do you really think it makes sense to nevertheless encrypt it?

2. Did anybody check the latest ~x86 baselayout, which has filesystem-encryption included (using /etc/init.d/checkfs and /etc/conf.d/cryptfs)? (Looks like the new baselayout will render such scripts obsolet)

(I was already playing around with the new feature in baselayout, but for some reason I coun't not get cryptsetup to work at all, and due to some other issues I am now reinstalling the whole system on my new notebook, so it may take a while until I can play arround with it again)

[Sachankara]

I am just getting into that encryption matter, and I was wondering:

1. On most machines with large amount of RAM (> 512 MB), swap gets hardly used at all, so do you really think it makes sense to nevertheless encrypt it?

2. Did anybody check the latest ~x86 baselayout, which has filesystem-encryption included (using /etc/init.d/checkfs and /etc/conf.d/cryptfs)? (Looks like the new baselayout will render such scripts obsolet)

(I was already playing around with the new feature in baselayout, but for some reason I coun't not get cryptsetup to work at all, and due to some other issues I am now reinstalling the whole system on my new notebook, so it may take a while until I can play arround with it again)

1. Yes, I think so... I know Linux hardly uses any swap unless it's absolutely necessary, but when it does, you can count on that it'll put your PAM password into the swap (since it's just normal data - which is exactly what kswapd will put on the swap)...

2. No, I'm not experimenting with any ~x86 stuff. But I'll implement as many encryption features as possible when they're available as non-testing...

[Master One]

Ok, just finished my "Stage 1 on a Stage 3 tarball" installation, and using the new ~x86 baselayout indeed renders most of the guides & scripts for filesystem-encryption obsolet.

I just activated the swap-encryption only by setting the proper options in /etc/conf.d/cryptfs and changed "/dev/hda2" to "/dev/mapper/crypt-swap" in the line for the swap-partition in /etc/fstab. Was up and running in notime, and works right out of the box like a charm.

[Cintra]

..using the new ~x86 baselayout indeed renders most of the guides & scripts for filesystem-encryption obsolete. I just activated the swap-encryption only by setting the proper options in /etc/conf.d/cryptfs and changed "/dev/hda2" to "/dev/mapper/crypt-swap" in the line for the swap-partition in /etc/fstab. Was up and running in notime, and works right out of the box like a charm.

Hei
can you clarify a little or point to respective docs
your /etc/conf.d/cryptfs for example..
my swap is btw

Code: Select all

/dev/hda5  none  swap  sw   0 0

thanks

[Master One]

As there are no docs available until now, I just wrote a quick and dirty howto, which can be found here.

Also it is working fine, I already had to disable swap encryption again, because an encrypted swap disables the possibility to use swsusp2.
There is a way, how to have both, but I need a little help on this matter, please see this thread.

[Cintra]

As there are no docs available until now, I just wrote a quick and dirty howto, which can be found here.

Many thanks Master One
mhv

[Vietor]

I am just getting into that encryption matter, and I was wondering:

1. On most machines with large amount of RAM (> 512 MB), swap gets hardly used at all, so do you really think it makes sense to nevertheless encrypt it?

It only needs to be used once. Have a look for yourself.

Code: Select all

strings < /dev/SWAP | less

then search for your root password. . . .

Also consider, what is the point of encrypting your swap? To protect your system.
Consider the attacker who gains access to an account on your system for a few minutes. Then proceeds to run code that expands to fill all available RAM, pushing everything else out to swap.

When designing for secure operations you must hypothetically grant the attacker control of everything but that which you are currently trying to protect. Fight them as if they had everything else at their disposal. Otherwise you are only prepairing yourself for failure.

[Master One]

Ok, Vietor, you convinced me, but as long as I can not solve that issue, how to be able to use swsups2 with an encrypted swap, I'll have to let swap encryption disabled. If anyone can help concerning building a working initrd, please have a look at this topic.

[linux_girl]

what the diff btw AES multi key and single key and how to get it ?

i am also crypting my home partition using a homemade

Code: Select all

 cat /etc/conf.d/local.start 
# /etc/conf.d/local.start:
# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/conf.d/local.start,v 1.4 2002/11/18 19:39:22 azarah Exp $

# This is a good place to load any misc.
# programs on startup ( 1>&2 )
                
cryptsetup -c aes create home /dev/hdb1
mount /dev/mapper/home /home

plus i have added a 500MB files that i crypt using losetup+cryptsetupe with the help of bash script in my home where i store text files and critical info

[Chaosite]

It only needs to be used once. Have a look for yourself.

Code: Select all

strings < /dev/SWAP | less

then search for your root password. . . .

Also consider, what is the point of encrypting your swap? To protect your system.
Consider the attacker who gains access to an account on your system for a few minutes. Then proceeds to run code that expands to fill all available RAM, pushing everything else out to swap.

When designing for secure operations you must hypothetically grant the attacker control of everything but that which you are currently trying to protect. Fight them as if they had everything else at their disposal. Otherwise you are only prepairing yourself for failure.

Alright, I'll bite.

Yes, you can find your root password in your swap.

But, where exactly is it? Its 1 string out of many. There is no way an attacker can find out exactly which one of the many strings represents your root password.

Also, linux_girl:

Yeah, that little tidbit will work. But why not use the Gentoo baselayout way of doing it (and not break your fstab?)

[linux_girl]

lets says u can rip from ur swap 500MB of valid strings (passwords are 6 char at least) hehehe that an esay way to have a worldlist from where to choose passworwd candidate and try them against ur hash with jhon the ripper and that wont take mutche of time to guesse ur passwords ! 500MB of valid strings from 1GB of swap while the keyspace size of all the passwords for the old crypt is 2^56 =72057594037927936 passwords

[Sachankara]

But, where exactly is it? Its 1 string out of many. There is no way an attacker can find out exactly which one of the many strings represents your root password.

No way? There's always a way...

[Sachankara]

When designing for secure operations you must hypothetically grant the attacker control of everything but that which you are currently trying to protect. Fight them as if they had everything else at their disposal. Otherwise you are only prepairing yourself for failure.

Words of wisdom... May I quote you on that?

[alberich]

Hi,

I've installed your script (great work! ) and it seems to work, but I am not sure, if I did everything right when installing it. My swap Partition is /dev/hda1

The /etc/fstab entry:

Code: Select all

/dev/hda1               none            swap            pri=42                  0 0

So when I boot Gentoo, dmesg gives the following message:

Code: Select all

root # dmesg | grep swap
Adding 1036152k swap on /dev/hda1.  Priority:42 extents:1
Adding 1036152k swap on /dev/mapper/swapdev-hda1.  Priority:0 extents:1

Executing the command strings on each partition gives for

Code: Select all

root # strings < /dev/mapper/swapdev-hda1

some strange output as it should be. But

Code: Select all

root # strings < /dev/hda1

(that's the swap partition) yields the same output as I had before encrypting the swap partition. It's just plaintext.

That shouldn't be, but I don't see any error... Maybe I'm just understanding the whole thing not thoroughly enough, so can anyone tell me, what's wrong here?

Cheers

[Sachankara]

Hi,

I've installed your script (great work! ) and it seems to work, but I am not sure, if I did everything right when installing it. My swap Partition is /dev/hda1

The /etc/fstab entry:

Code: Select all

/dev/hda1               none            swap            pri=42                  0 0

So when I boot Gentoo, dmesg gives the following message:

Code: Select all

root # dmesg | grep swap
Adding 1036152k swap on /dev/hda1.  Priority:42 extents:1
Adding 1036152k swap on /dev/mapper/swapdev-hda1.  Priority:0 extents:1

Executing the command strings on each partition gives for

Code: Select all

root # strings < /dev/mapper/swapdev-hda1

some strange output as it should be. But

Code: Select all

root # strings < /dev/hda1

(that's the swap partition) yields the same output as I had before encrypting the swap partition. It's just plaintext.

That shouldn't be, but I don't see any error... Maybe I'm just understanding the whole thing not thoroughly enough, so can anyone tell me, what's wrong here?

Cheers

You mean that you do the following:

1. Encrypts the swap partition using the script.
2. View the data on the encrypted swap partition.
3. Restores the original swap partition.
4. View the data on the swap partition.

?

Then the answer is simple, the encrypted data is still present after you've restored the swap partition (but it is encrypted). If you are paranoid and doesn't even want the encrypted data to remain after an restore, then set the variable "PARANOIA_MODE" to 1 within the script.

[alberich]

Hello,

You mean that you do the following:

1. Encrypts the swap partition using the script.
2. View the data on the encrypted swap partition.
3. Restores the original swap partition.
4. View the data on the swap partition.

?

Then the answer is simple, the encrypted data is still present after you've restored the swap partition (but it is encrypted). If you are paranoid and doesn't even want the encrypted data to remain after an restore, then set the variable "PARANOIA_MODE" to 1 within the script.

um, no I mean directly after finishing the boot process. After I log in I can do a

Code: Select all

strings < /dev/hda1

as well as

Code: Select all

strings < /dev/mapper/swapdev-hda1

In the first case I see plaintext and in the second some random data. I do not restore anything (at least I think so ). It seems it is both, encrypted and not encrypted... But I also have an encrypted filesystem, therefore dm-crypt and whatever is needed should work.

I think it's a case of "PEBCAK" but I don't see my mistake, yet.

Cheers

[Nimo]

Could you not please make a version of the script that will work with initng to? (if it's not too much work)

[user]

a script like this?

root # grep swap /etc/fstab
/dev/hda2 none swap sw,loop=/dev/loop/2,encryption=AES128 0 0
root # losetup /dev/loop/2
/dev/loop/2: [000a]:1344 (/dev/hda2) offset=4096 encryption=AES128 multi-key-v3
root # swapon -s
Filename Type Size Used Priority
/dev/loop/2 partition 2008112 2644 -1

[Sachankara]

Could you not please make a version of the script that will work with initng to? (if it's not too much work)

I'm unable to do it right now, but perhaps in two weeks from now. I'm currently studying four courses at the same time, which is equal to 80 work hours a week.

[svf]

Also consider, what is the point of encrypting your swap? To protect your system.
Consider the attacker who gains access to an account on your system for a few minutes. Then proceeds to run code that expands to fill all available RAM, pushing everything else out to swap.

i think the point in swap-encryption is to keep critical data save between poweroffs and/or reboots.
you may have the strongest algo+pass for your data/home partitions, but this doesnt matter if your plaintext pass is somewhere on your unencryptet swap.

mh just my thoughts

ah btw.. sorry for bad english

cya

[bld]

Can you explain me from the security perspective.. what's the diff between this entire script and these[1] 3 lines in your local.start file?

[1]
/usr/sbin/cryptsetup -c serpent -d /dev/urandom create enc-swap /dev/hdb1
mkswap /dev/mapper/enc-swap
swapon /dev/mapper/enc-swap

except from the error checking of course.