diskencrypterSpec

Summary

Develop a new graphical tool similar to "USB startup creator" that allows to setup a encrypted external hard disk or USB drive for all users with only a few mouse clicks.

Release Note

This program allows every user to setup a external disk (external HDD, USB thumb drive, SD card etc.) with maximum ease of use an without using the command line.

Rationale

Ubuntu already supports mounting of encrypted external disks through the GUI. You just have to plug your encrypted disk into your computer, Ubuntu recognizes it as a encrypted disk, displays a message window where it asks for a password and if you enter the correct password the drive is automatically mounted and appears on your desktop.

Unfortunately, creating such an encrypted disk is not quite so easy and can be done only on the command line so far (e.g. http://ubuntu-tutorials.com/2007/08/17/7-steps-to-an-encrypted-partition-local-or-removable-disk/). This should change because encryption is becoming more important with the proliferation of mobile computing and steady reports of data leaks in companies and governments. And since all the technology is already in place it shouldn't fail just because of a missing graphical frontend.

User stories

Michael works for a company that demands all USB thumb drives used by employees to be encrypted to prevent data leak in the case they get lost. When he receives a new USB thumb drive he just starts diskencrypter, inserts his thumb drive, and creates a new partition table with one encrypted partition that spans the whole disk. All he has to do is to select the his new drive from the drive list and press "Encrypt Disk" while using the default options.

Alice is a power user and wants her data to be extremely save. She plugs her new USB drive she wants to encrypt in and starts diskencrypter. But instead of using the default options she chooses to initialize her disk with random data. But since diskencryper shows the progress of this operation it is less painful than doing it on the command line with "dd".

(Not decided yet) Joana is an architect and uses USB flash drive to move insensitive files along many computers. Also she needs to carry some sensitive files and access them on at home and workplace computers. She does not know the size of the files she will want to encrypt in future. She prefers to not have another USB drive - they probably will fit in the existing device after all.

Assumptions

Design

There will be a single window where the user can select the disk drive, the initialization method for the drive and the filesystem to use. After clicking on a button named "Encrypt Disk" the disk will be initialized with ramdon data, it will be encrypted and a filesystem will be created. During each phase the user will see how many phases there, which one the program is in now and how long it will take to finish this phase (or the degree of completion in percent).

Implementation

  • Python
  • Glade/GtkBuilder
  • Borrow code from USB creator for detecting external drives
  • AES 256 as default algorithm (do we need to provide selection options for the crypto suite or should we go with one default option to keep the interface as clean as possible?)

Test/Demo Plan

BoF agenda and discussion

  • Default cipher: use a heuristic to choose default (prefer stronger ciphers, prefer ciphers we have hardware acceleration for). Optionally provide a way to change the default (e.g. using GTK expander). (There are also several encryption modes for any cipher but there is no need for it to be user configurable.)
  • Password: How/when user enters a password for encrypting/decrypting? After user enters the password and we decrypt the key, should we store the key? It could be part of the config dialog or it could be asked for if the users hits Encrpyt -- AndreasHeck

  • Password (idea): People use weak passwords. People regularly use only a few computers. Make it so the drive's key is stored on user's computers. If user wants to use the drive on a new computer, he/she would have to (invoke this tool and) "set a temporary password on the drive" - this would encrypt the key with the temporary password and store it to the device. When the device would be opened on the new computer, the program would ask for password, decrypt the stored key, save it on computer, and (by default) delete the key on device. The password handling as all encryption details is already done by dm-crypt, I don't wan't to reinvent it, just provide an easy to use interface to creating such devices, since mounting them is already supported in Ubuntu. Apart from that saving the key on the computer would defeat the whole purpose of full disk encryption -- AndreasHeck

    • Not whole. It will still protect data on the USB stick (provided attacker does not get the running computer). Also it would prevent brute-force trying simple passwords against the stick. Each way has its own cryptographic advantages. (Personally, I would more enjoy no-password access to my encrypted flash when using my computers.) -- PetrB
  • Encrypted _directory_: If implemented as an encrypted partition it is difficult to re-size if user also wants to store unencrypted files on the device. Ubuntu similar functionality in EncryptedPrivateDirectory. This is right, you can't change the partition size but providing full disk encryption is the purpose of this tool -- AndreasHeck

  • Discoverability: How do user know what/how to start the tool? Suggestion: Nautilus, the drive, right-click, Properties, some card, checkbox "Encrypt the drive to prevent other people reading" and other controls.
  • Note: "But instead of using the default options she chooses to initialize her disk with highest quality random data what will literally take days." -- What is the use? To conceal how much drive space is used by the filesystem? It conceals the unused space on the disk, noteably the structe of the blocks, since encryption is block wise -- AndreasHeck

  • Note: What is a difference between "highest quality random data" and ordinary random? It's the difference between /dev/random and /dev/urandom -- AndreasHeck

    • Tested on my notebook: urandom: 1.7 MB/s, random: apparently <1kB/s (dd if=/dev/urandom of=/dev/null bs=1 count=1024). Get 32 bits of randomness and spread it using a hash. There will be only 2^32 possible disk-fillings (which is almost enough) and if someone breaks the hash (which is unlikely) he can prove what blocks are empty. And we will get rid of one option to explain to user.

-- PetrB


CategorySpec

diskencrypterSpec (last edited 2009-06-19 14:30:58 by mail)