Design Concepts

Devora design concept originated from the idea of key and lockpad. For a Linux Operating System with disk ecryptions like cryptsetup, we have massive passphrase overloads, securing starting from:

  1. Grub (if user authentication is enabled), then to
  2. disk decryption (cryptomount), then to
  3. local user login, then
  4. root account (sudo / su), then to
  5. password manager (if not, see below).
  6. …all your individual passphrases for each services

This has to stop! Especially on Grub and disk decryption layers where password managers are not available.

The Problems

Devora is designed not because it is a fun projects. There are a number of problems even we, the Linux developers got annoyed of.

Chicken and Egg: The MUST have Passphrase

The thing about disk encryption is that it needs a qualified passphrase. Holloway did a research and found out that a qualified passphrase (ignoring the mental memory stress) is something like number 4 in the following sample:

#1 Password (Weak)

#2 Passphrase (weak)
you aren’t getting my password!!!

#3 Passphrase (Strong)
Y0u Ar6n’t_Get1ing My P@$sw0rd!!!

#4 Password (Strong)

DISCLAIMER: If you’re insane enough to use any of the example as your own password, please stop and seek help from BeFrienders. Please do not commit suicide; life is still beautiful.

Now, if you ask a normal human to memorize that long qualified passphrase just to boot a disk, you’re insane. It’s better to encourage a (successfully memorized) user to apply that password into his/her password manager instead.

Overall, we still need that level of password quality but we got problem remembering such long and weird passphrases. Hence, we are stuck with chicken and egg situation.

That leads to the next problem.

Password Manager Unavailability

Password manager is only available when the operating system is fully booted and functional. At grub and disk encryption level, password manager is literally useless.

Now, some smart folks will tell you to search via mobile app and type the passphrase manually into the disk decryptor. After trying it everyday with a minimum of 33 random characters passphrases, sooner or later, we will be looking for some sort of physical key solution.

This is because we got so fed up typing such passphrases a minimum of 2 times to do your computing needs (another one is for password manager). Also, not to mention, doing so has a high fail rate due to unrecoverable typo.

Demands for Full Disk Encryption

This is acutally a design requirement met by ZORALab team, where a laptop should not boot the hard disk instead of loading the bootloader. The laptop’s power system is configured in a way that it is either S0/S1/S4/Off states with forbidden S2 and S3 modes.

While this is a known security theatre, it is good to know that the hard disk carries a full disk encrypted payload at the expense of booting sequence complications.

The idea is that the bootloader alongside with a key should be with the owner and leave the laptop as it is. If someone took it, he/she would not be able to boot or triggering a thought that the hard disk is useless. This creates tendency for reformatting, thus, somewhat protecting the information inside.

Design Principles

Based on the the list of problems, Devora has certain non-compromising principles.

#1 - NEVER Block the Upstream

In any cases of Devora’s deployment, no design and implementation should block the upstream implementation and rolling updates. What this means is that any new features or enhancements should not introduces monkey patches or servere customizations to the status quo system.

Remember, its role is to replace typing passphrase manually to automatic detection. Period. No monkey patches or boogie customizations.

There is absolutely no reason for one to introduce hanky panky stuff into the status quo. It is like throwing away the past talents and experiences. You should be highly familar with Linux boot sequences and booting path before contribution.

#2 - System Seeks, Data on Stick

Devora is based on physical key and padlock analogy. There are guides in the wild has weird directions such as packing the key inside initrd images or reducing the decryption iteration time. These are all wrong!

You should not mess with the passphrase iteration time. There is a reason the original developer set that long time: to introduce hashing delay in order to make your passphrase more resilient from brute-force cracking. Altering the iteration time is like asking to remove the lock bits from the padlock, making it useless in the end.

Also, you should not pack the key inside the boot unit like initrd images. That is like locking the pad lock and have the key keychain onto it.

We should always emulate the analogy:

  1. The padlock always seek out the key stick (System seeks)
  2. The specific key stick always hold the correct key-bits (Data on stick)

#3 - Single Binary

Anything dealing with boot sequences has enough painful complexity. To get a visual, try read Grub2 source codes. Overall, let’s keep the dependency simple: use single binary. Avoid introducing more dependencies.

Keep the output simple.

#4 - Mission Critical

We are adding an automated tool into the boot sequences. Hence, it MUST be mission critical. The following are compulsory:

  1. Defensive coding
  2. Error handling
  3. Clean coding style
  4. Test driven coding