crypto-drive-manager 1.0

Unlock all your encrypted drives with one pass phrase.

crypto-drive-manager: Unlock all your encrypted drives with one pass phrase

The crypto-drive-manager program allows you to safely, quickly and conveniently unlock an unlimited number of LUKS encrypted devices using a single pass phrase. You can think of it as a key pass for LUKS encrypted devices. It works by creating a small (10 MB) encrypted file system inside a regular file (using a loop device) and storing key files for the encrypted devices of your choosing inside this encrypted file system. Each time you run the program it temporarily unlocks the 10 MB encrypted file system and uses the key files to unlock and mount encrypted devices that are present and not already unlocked.

Installation

The crypto-drive-manager program is written in Python and is available on PyPI which means installation should be as simple as:

$ pip install crypto-drive-manager

There’s actually a multitude of ways to install Python packages (e.g. the per user site-packages directory, virtual environments or just installing system wide) and I have no intention of getting into that discussion here, so if this intimidates you then read up on your options before returning to these instructions ;-).

Getting started

The crypto-drive-manager program doesn’t have a configuration file because it looks at your system configuration to infer what it should do. You need to create or change /etc/crypttab in order to enable crypto-drive-manager. As an example here’s my /etc/crypttab file:

# <target name>  <source device>                            <key file>                 <options>
internal-hdd     UUID=626f4560-cf80-4ed9-b211-ac263b41ca67  none                       luks
media-files      UUID=6d413429-f8d1-4d8e-8a3a-075603b8efdd  /mnt/keys/media-files.key  luks,noauto
mirror3          UUID=978d7a3a-c902-43e6-aa71-5654d406c247  /mnt/keys/mirror3.key      luks,noauto
mirror4          UUID=7a48e547-1dfa-4c6a-96e9-05842c87465d  /mnt/keys/mirror4.key      luks,noauto
mirror5          UUID=ac6aa22a-0c32-4bd9-829a-75316177affb  /mnt/keys/mirror5.key      luks,noauto
mirror6          UUID=00474636-6d6e-4ecc-a7d6-21b42d850ac6  /mnt/keys/mirror6.key      luks,noauto
mirror7          UUID=ec56dc10-1086-4f2b-808c-88995cb8b513  /mnt/keys/mirror7.key      luks,noauto

You can see why I don’t want to manage all of these encrypted devices manually by entering pass phrases for each of them :-). Even though my root device (internal-hdd) is also encrypted, storing key files to unlock my encrypted devices on my root device doesn’t feel right because the key files will be exposed at all times.

You tell crypto-drive-manager to manage an encrypted device by setting the key file (the third field in /etc/crypttab) to a file located under the mount point used by crypto-drive-manager ( /mnt/keys by default). Every time you run crypto-drive-manager it parses /etc/crypttab to find and unlock managed devices. The UUID=... definition in /etc/crypttab is used to check if the physical device exists in /dev/disk/by-uuid. Because of this a source device definition with a UUID=... value is required.

Each physical device that exists is initialized, unlocked and mounted. Device initialization happens when the key file for the encrypted device doesn’t exist yet: The key file is created with 4 KB of random bytes and installed as a key on the encrypted device.

The end result is a program that requires a single pass phrase to unlock a virtual keys device containing key files used to unlock a group of encrypted devices. Once the encrypted devices have been unlocked the virtual keys device is unmounted and the keys are no longer available (except in memory, which cannot be avoided to the best of my knowledge).

Contact

The latest version of crypto-drive-manager is available on PyPI and GitHub. For bug reports please create an issue on GitHub. If you have questions, suggestions, etc. feel free to send me an e-mail at [e-mail].

License

This software is licensed under the MIT license.

© 2015 Peter Odding.