# Encrypting an entire partition

## dragonuv

Hi,

I have read a manual that talks about creating a file within a partition and then the user encrypts it and then mounts it everytime he wants to use it.

This time I have an entire partition I want to encrypt, and have decided to do it with LUKS.

My question is are those methods different? do I need to create a file which covers the entire partition and then should I encrypt it and mount it?

Are there any good manuals that talk about it? I'd be grateful if someone could help  :Smile: 

Thanks!

----------

## avx

FullDiskEncryption (or partitions) for that matter, are a little different.

Basically, you create a partition-layout first, i.e. with fdisk (lvm is of course possible), then you encrypt the/a partition, i.e. encrypt /dev/sda2, then you open the encrypted partition, which is then transparently handled by the kernel as (for example) /dev/mapper/sda2. Finally, you create a filesystem on /dev/mapper/sda2 (ie. ext3), mount this and install/work with it as usual.

How you do it exactly depends heavily on what you want to protect and against what. A quite lenghty but good guide can be found here: http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS

If you have further question, please be as specific as possible, we don't want do risk your data, don't we  :Wink: 

----------

## dragonuv

thanks for your reply  :Smile: 

in the guide there is a tip that says  *Quote:*   

> Note: Tip! Using the AES_x86_64 "AMD64 users only":
> 
> as of kernel-2.6.9 the 64bit version of the AES cipher that can be used in replacement of the 32bit AES cipher that's used by default. you must load this module before running the cryptsetup command or else the 32bit AES will be use instead. type "modprobe aes_x86_64" and continue with creation of mappings.
> 
> 

 

So how do I disable the " -*- AES cipher algorithms" in my kernel and use the x86_64 version instead?

My AES cipher algorithms (x86_64) is also built into the kernel

----------

## avx

If I'm not mistaken, if both options are available, the kernel decides, ie if the kernel sees your system supported, it'll use the x64 version.

----------

## salam

I use cryptsetup(dm-crypt). Easy to implement - just one command to create and re-activate, online resizing supported. One password for data filesystems(/home and similar), one for backups on other system. I don't use encrypted rootfs and other system FSs...is it useful? Its just linux like any other similar system.

----------

## Hu

 *salam wrote:*   

> I don't use encrypted rootfs and other system FSs...is it useful?

 That depends on your threat model.  If you are using encryption to guard against the possibility that the hardware will be stolen and its contents disclosed, then no, you probably do not need to encrypt filesystems which do not contain personally generated content[1].  If you are using encryption to guard against someone secretly obtaining the hardware, modifying the software on it, and then returning it to you undetected, then there could be benefit to encrypting all the filesystems, if you take adequate other measures to prevent the installation of malicious hardware/kernels.

[1] Remember to encrypt swap and ensure that there are no user-writable areas not covered by encryption.  It would be unfortunate to discover that you dutifully encrypted /home, then your applications saved temporary files with sensitive data to a persisted /tmp, which the attacker then recovered.

----------

## dragonuv

Does anyone know what this problem mean?

Gentoo user # cryptsetup luksOpen /dev/sdb6 root

Enter passphrase for /dev/sdb6: 

semid 393220: semop failed for cookie 0xd4d5456: incorrect semaphore state

Failed to set a proper state for notification semaphore identified by cookie value 223171670 (0xd4d5456) to initialize waiting for incoming notifications.

yet I still see the /dev/mapper/root

----------

## avx

Are you doing this on a drive >=2TB or using the "advanced format" ie 4k sector size? According to Google, that seems to be a common problem here and the solution should be to properly align the partition(s).

Edit, apparently, at lest it's not as critical as it reads.

----------

## dragonuv

 *avx wrote:*   

> Are you doing this on a drive >=2TB or using the "advanced format" ie 4k sector size? According to Google, that seems to be a common problem here and the solution should be to properly align the partition(s).

 

I'm not using a drive >= 2TB, but what do you mean by the "advanced format"?

What do you mean align the partitions?

 *avx wrote:*   

> 
> 
> Edit, apparently, at lest it's not as critical as it reads.
> 
> 

 

Can I just ignore the error message then?

----------

## salam

 *Hu wrote:*   

> If you are using encryption to guard against someone secretly obtaining the hardware, modifying the software on it, and then returning it to you undetected, then there could be benefit to encrypting all the filesystems, if you take adequate other measures to prevent the installation of malicious hardware/kernels.
> 
> [1] Remember to encrypt swap and ensure that there are no user-writable areas not covered by encryption.  It would be unfortunate to discover that you dutifully encrypted /home, then your applications saved temporary files with sensitive data to a persisted /tmp, which the attacker then recovered.

 

This is very good point which I wasn't thinking of. I do not use swap anyway, but I'm considering full encryption now. Thanks for info.

----------

## AngelKnight

 *dragonuv wrote:*   

> Does anyone know what this problem mean?
> 
> Gentoo user # cryptsetup luksOpen /dev/sdb6 root
> 
> Enter passphrase for /dev/sdb6: 
> ...

 

I get yelled at for IPC stuff like this whenever I use LUKS.  I've been ignoring these without any obvious issues, but my use case is specifically manually mounting filesystems within luks containers written to external HDDs, not anything fancy like mounting my real root from an initrd or anything like that.

----------

## salam

OK, so its perfectly easy to do full encryption with downtime 5 minutes(for reboot). Note that I use software RAID 1. 

This is not a full howto, just a quick tip how it works and maybe i also forgot some step.

Also, my order is [physical disk => SW RAID1 => DMCRYPT => LVM], for other layouts, service start order may need to be changed. /boot and / are not on lvm in my setup...maybe i'll put root fs there another time

Here's what I did(system only partitions):

Prepare initrd so it starts raid arrays and open root one with cryptsetup, then mount ro to temporary root(classic initfile you find in gentoo wiki), but mount devtpmfs here before!!!

Also, assemble one-disk arrays here on first boot (the encrypted ones) mdadm -A -R /dev/md1 /dev/sdb2 (counterpart sda2 will contain unencrypted data used as source)

Order of commands

...mdadm assemble...

cryptsetup create...

mount to /mnt/root

mount -t devtmpfs none /mnt/root/dev

exec switch_root /mnt/root /sbin/init

you can also load modules in initrd, i have all compiled-in so no modules

the key file used for decrypting root partition needs to be accessible on boot, i just put it within initrd image (one unencrypted fs /boot i have on external media with keys...so it needs to be in to boot)

Ok, with initrd prepared and placed(update also grub.conf with it), proceed

prepare configuration in /etc/conf.d/dmcrypt (place key files there and optionally, remote media - if you prefer key on USB like i did - for example)

Split mirror for root(md1), create new RAID1(md4) with device removed from array, apply cryptsetup on it (with a key file).

Rsync / (this filesystem does not change by its own in my layout, as I have /var /tmp and so separately).

/var /usr /tmp -> all are on lvm within md2

Same split like on root partition, then cryptsetup again, then pvcreate and vgcreate on encrypted md device

Using LVM snapshots freeze and mount original FSs, then rsync and remove snaps

Update fstab, stop services, rsync final differences(it will be quick), REBOOT

Boot into fully encrypted FS, you remain with non-encrypted raid devices used as sources in the build

remove superblocks from these unencrypted devices and re-add them to raid arrays

update initrd with mdadm.conf and array auto-scan instead of first-boot hard one-disk setting

done

----------

