HOWTO_Ecrypt_partitions_with_keys_stored_on_encrypted_usb_pen_drives
| Installation • Kernel & Hardware • Networks • Portage • Software • System • X Server • Gaming • Non-x86 • Emulators • Misc |
Contents |
Overview
This article will describe how to:
- Encrypt an usb pen drive
- Create an encryption-key on it
- Use that key to encrypt a partition, eg for your /home
- Decrypt, map and auto-mount the partion while booting (using the key on your pen drive and your passphrase)
- Unmount and unmap it automatically on shutdown
- Create seperate encryption-keys that you can store in a secret place (eg give to your best friend); to be prepared in case you loose your key-container. You will be able to disable such a key again if the secret place is no longer secret.
Security Argument
In this situation someone trying to decrypt your partition would fail, even if he (however) gets your usb stick. Cause the stick is useless without the password, which is only known to you.
| FIXME: Tell more. Especially: TrueCrypt and Hidden Partitions. |
So, this approach results in a relatively high level of security. In addition I don't think it's necessary to encrypt the whole disk, including rootfs, cause all (my) sensitive data are located in the home dirs. But I recommend encrypting swap; to be sure your encryption-key is unusable, even if it somehow makes it's way to swap. Nevertheless it's a good idea to also encryt the /tmp fs.
By the way, this is although a matter of performance. It's slow enough to have an encrypted home partition.
| FIXME: Say how to do this. |
RC Addon needed
In case you want the encrypted partition to be mounted at boot-time, you will recognize that gentoo's rc system is not sufficient in this situation; at least for the approach I am just talking about. Don't get my wrong, Gentoo is just great.
While booting, the usb-key-container has to be located, decrypted using a password given by the user, mounted; and after this, the encrypted partition must be decrypted with the key from the usb-container and finally the usb-container needs to be unmounted and it's ecryption-mapping removed.
I've written an addon to the gentoo rc system which will do this for you.
On Boot
... when it's time to decrypt your partition, before checkfs/localmount are invoked:
- The system will wait for you to attach the usb-key-container
- Use cryptsetup-LUKS to decrypt/map the container asking you for the passphrase
- Temporary mount the container providing the key
- Use cryptsetup-LUKS to decrypt/map the partition using the key from the mounted container
- Unmount the container and remove it's decryption-mapping (you can remove the stick instantly)
... rc will call checkfs/localmount afterwards so the partition is fschecked and mounted
On Shutdown
... after localmount has unmounted the partition:
- Your partition's encryption-mapping is removed
Alternatives
Why not use the existing dm-crypt-addon?
Dm-crypt is called by rc before checkfs and after localmount(and on shutdown). This is required cause you can define pre- and postmount-actions to be executed, and dm-crypt has to be called to run these when their time has come.
We could use this premount-action to mount the usb-key-container, right after decrypting it. Then encrypt the partition using the key from the mountpoint and unmount it again in the partition's premount action. This would look like this:
| Code: /etc/conf.d/cryptfs |
mount=usb-key-container
source='/dev/sda1'
type=luks
options=' --readonly'
pre_mount='mount ${dev} /mnt/usb-key-container'
mount=home
source='/dev/hda8'
type=luks
options=' --key-file /mnt/usb-key-container'
pre_mount='umount /mnt/usb-key-container && cryptsetup luksClose usb-key-container'
|
This works cause dm-crypt first creates the device-mapping before it executes the premount action. The pre-/postmount-actions are originally inteded to be used for creating a fs on an encrypted /tmp and for changing it's permissions after mounting.
| FIXME: Say howto do this |
Abusing dm-crypt in that way has some disadvantages:
- Dm-crypt doesn't wait until you attach the stick
- So, if the usb pen drive is not connected when dm-crypt accesses it first on boot, it will (most likely) not be able to decrypt it; the whole story failes and you have to reboot (having the stick attached) or do the mapping/mounting stuff by hand
- On shutdown dm-crypt will try to unmap the stick, resulting in a failure
- Unbeautiful configuration
But it's your choice to stop reading at this point and copy/paste/review the above config.
What about simply writing an init script?
Yeah, this was my first thought. I wrote an init script that did the mapping/mounting/... stuff, but this was an useless waste of time, because init scripts will always be aborted by runscript.sh (even if added to the boot runlevel or called directly from checkfs) while sysinit is running. And excactly this is the time, we want the partition to be decrypted.
Requirements
Encrypting the usb pen drive
fdisk -l
find the new added disk such as sda or sdb create the 2 partitions on usb pen disk fdisk sd* (what you find in fdisk -l)
dd if=/dev/urandom of=/dev/sd*2
Ecrypting the partition
Installing the rc addon
Usage
Creating fallback keys
Created by NickStallman.net, Luxury Homes Australia
Real estate agents should be using interactive floor plans and real estate agent tools.
