Architecture Design

This section is the engineering design for Devora’s role in the Linux boot sequences. We will look into various design aspects.


Boot Sequences Design

Devora has an additional process to the current Linux boot sequences, complying to its 1st design principle. This is the design diagram:

boot-design

In general, Devora plays 2 main roles:

  1. Seek out keyfile and load it into cryptsetup.
  2. Update USB stick bootloader before letting user know to unmount the USB stick gracefully.

Devora project only introduces the addition process blocks for the OS.

Triggers

Devora only get triggered by 2 processes:

  1. cryptsetup triggers Devora searching for keyfile.
  2. bash profile triggers Devora to update the USB stick /boot partition.

Fail-Safe

For cryptsetup keyfile seeking process, the fail-safe is always fallback to the common user manual input.

As for /boot update, the fail-safe process is to handle the user experience for unmounting process.


Data Management

These are the data management for Devora’s implementation. We are looking into 2 different form-factors: the USB stick acting as a key while the machine acting as the lock.

AttributesUSB StickOperating Machine
Roleskeylock
Data TypeStoring Decryption Key and /boot partitonStoring Devora Binary
Data At RestKeyfile: encryptedComply to Disk Encryption
Data In MotionKeyfile: encrypted formComply to cryptsetup
PermissionRead onlyRead only
Access PrivilegeRootRoot, User
CapabilityRead onlyRead (Root, User) and Write (Root)
Ecryption CipherAES-GCM 256-bitCompy to Disk Encryption
(e.g. AES-XTS-PLAIN64 256-bit OR AES-ADIANTUM-PLAIN64 256-bit)
File LocationKeyfile: ${USB_STICK}/user/keyfile.asc/usr/local/sbin/devora
Partition TypesFAT32 for EFI partition, Ext2 for /boot and /usersComply to OS (e.g. Ext4)
Default NatureRemovablebinded to compute module
Recommended UsageBooting and Update: only bind
Otherwise: stay detached and stored safely
normal computing usage


Selected Tools

These are the tools selected for developing Devora.

Main Language

Go programming language is selected as main language due to its single binary compilation nature. This fulfills the Design Principle #3 - Single Binary.


Continuous Integrations

Fennec project is used to automate the project. It has Go 1.12 supports which mitigate most of the Go library issues.


Documentations

There are 2 technologies we are currently using:

  1. Hugo - Extended - for documentations rendering.
  2. Bissetii - for serving as content templates and documentationg engine.


Packaging

Since this is a core system application, the proposed packaging format would be:

  1. Debian deb package
  2. Red Hat rpm package

Others like Snapcraft and Flatpak are not a suitable candidiates.