Goals/Use cases

• encrypted USB keys (storing GPG keys, secure exchange of documents)
• encrypted home/tmp/swap partitions on laptops (theft)
• pure offline-protection

Available implementations

• virtual device on top of a real device (dm-crypt)
• virtual mounted directory on top of a real directory (LUFS/FUSE); purely userspace
• both backends are in the standard Breezy kernel

dmcrypt

• only raw device, no metadata

• dmsetup is in main

• needs to be enriched with metadata -> LUKS standard

• hal 0.5 can detect LUKS encrypted volumes

Removable Storage Devices

• should use dmcrypt + LUKS standard to be compatible with RedHat

• hal sees metadata, creates volume for encrypted device (status: working, package pending upload)

• g-v-m spawns dialog for password and toggles device setup (status: initial work in progress)

• device setup happens with cryptsetup-luks (status: needs packaging polish, but works)

• extend pmount to allow mounting of devmapper devices on top of removable devices (status: planned)

• find a safe way to call cryptsetup-luks as user with root privileges; pmount integration? (status: planned)

Future Goal: encrypted system/home partition

• encrypted swap
• keyring
• storage of the metadata for encrypted /

Notes from Mataro

Encrypted storage

* Off-line protection of computers * Encryption of usb-sticks

2 Curent altenatives:

• FUSE - Basic design flaws (Not accepted by upstream)
• Encrypted block devices. Encrypted block device solution is the only one possible because of the flaws with fuse.

Possibilities:

• Intergration with HAL, Red Hat solution - add meta data to the
  • first block. Work with this.
• For home directories, no single password - need some way of mapping
  • multiple passwords to one device password.
    • Upper bound of number of users.
    • Pre-allocation of metadata space,
      • so have to pre-set the maximum number of users.
    • Use key ring to map one password to many passwords.
• Loop devices:
  • Free space - dynamically resize filesystem, encrypted file.
  • No metadata - no idea if there is an encrypted device there
    • unless we have correct password.
  • No way of knowing if the password was correct.
• Implement encrypted filesystems.
• Gnome VFS layer - Restricted use case.
• Encrypt everything
  • Un-encrypted boot partition
  • 2 stage encryption (encrypt real password in initrd or usb stick.)

Use Cases:

• What to encrypt?
  • Home directories
    • Very Hard...
  • USB devices
  • Everything
    • Selling point for enterprises.
    • common use case for companies.
  • Swap
    • Very Easy...

Conclusions:

• First get working from running installations before adding
  • installer support.

From JimmyHedman Thu Jan 27 16:03:41 +0000 2005 From: Jimmy Hedman Date: Thu, 27 Jan 2005 16:03:41 +0000 Subject: Encrypted home directories Message-ID: <20050127160341+0000@www.ubuntulinux.org>

Can't this be accomplished with libpam-mount? I have an encrypted image mounted every time I log in (currently not as my home directory). The only problem I found was if I log in over ssh with key authentication.

MartinPitt: Yes, I think libpam-mount will be a convenient way to avoid adding additional setup steps for encrypted home partitions.

From TobiasHunger Fri May 6 21:41:29 +0100 2005 From: TobiasHunger Date: Fri, 06 May 2005 21:41:29 +0100 Subject: cryptdisks script Message-ID: <20050506214129+0100@https://www.ubuntulinux.org>

For what it is worth: I hacked myself a cryptodisks start/stop script that has some advantages over the one that comes with the cryptsetup deb.

For one thing can run scripts in advance of setting up anything, and after it is done (i.e. to format a device after setting it up with a random key, /tmp and swap spring to mind here). It can further use a file and interactive (input that is then hashed) and script-based keys (i.e. gpg).

Further it allows to have "transient" devices: When some such is encountered in /etc/crypttab the script mounts the device (must be registered in fstab for that) immediently after setting it up. After processing crypttab that device is unmounted again and the decrypted device destructed. I use this feature so that I only have one key to enter, which is used to mount a transient device. That in turn holds the keys to the other partitions. It shouldn't be too hard to modify the script to destroy the transient decrypted device and retry again if the mount fails... which is a good indicator that the passphrase was wrong.

I strongly speak out against loopback: That is deprecated in 2.6 kernels for valid reasons. The cryptdisk script can mount files loopback and then use dm_crypt on them, so there is no reason to stick with the old cryptoloop stuff!

If it is resizeability you are after try lvm... good to have around anyway. Makes it easy to have all users on their own partition as well... which makes quotas redundant and hides each users data from all other users.