New Deo Design

This page describes the new Deo design. Our first attempt worked, but several use cases emerged that were not part of our original design. Further, we came up with a better algorithmic design.

Use Cases

1. Automated Unlocking: Sam has 10,000 servers. In the event of a power outage, he can't go around and type passwords for all of them to unlock the disk. He needs an automated way to unlock the disks when systems boot on his network but which does not allow decryption outside of his network. He also need a manual recovery key stored in some escrow in case the automatic system fails for some reason. Thus, he needs two keys with a logical OR such that either can be used to unlock the disk.

2. Kill Switch: Sheila manages encryption on company laptops. She needs a kill-switch mechanism so that she can disable devices remotely. She would also like the users to type a password when not on the secure company network. This requires three keys in a complex relationship: kill-switch AND (password OR network).

3. Threshold Unlocking: Karen works in a high-security facility. She would like to do something similar to Sam (above). However, she is worried that compromise of a single system could weaken security. Because of this, she would like to require m servers of a total set of n servers to be available for locking to occur. This still allows for some downtime of some servers. But so long as some number of them (m) are a available, decryption can occur.

4. Bluetooth Proximity: Nathaniel would like his security related phone application to only work when in proximity to a Bluetooth beacon. This requires a minimal implementation on the part of the server such that it can fit on an embedded device. Additionally, requiring a consensus based model (like Karen above) can give a strong security picture.

5. Trusted Computing: Christian works with Karen in the high-security facility. He is in charge of software security and he guarantees a full signature chain from EFI through the kernel. He would like full disk encryption as part of this trusted computing chain. This means that both EFI and the kernel need to know how to decrypt the disk using the above methods; or, alternatively, that the kernel needs to learn how to execute trusted userspace code.

6. Application Persistence: Sarah is a Postgres DBA. She wants to ensure that the database is encrypted on disk and that only the Postgres user (or process) has access to decrypt it. In particular, she does not want this system decrypted at boot for all users. She can do this today with ext4 encryption; but this is a manual process. She wants to automate this.

Splitting up Deo

Since the client needs to support multiple unlocking relationships, including escrow, this project should be split into two components:

• The Server
• Clients