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:

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.

Attributes	USB Stick	Operating Machine
Roles
Data Type	Storing Decryption Key and /boot partiton	Storing Devora Binary
Data At Rest	Keyfile: encrypted	Comply to Disk Encryption
Data In Motion	Keyfile: encrypted form	Comply to cryptsetup
Permission	Read only	Read only
Access Privilege	Root	Root, User
Capability	Read only	Read (Root, User) and Write (Root)
Ecryption Cipher	AES-GCM 256-bit	Compy to Disk Encryption (e.g. AES-XTS-PLAIN64 256-bit OR AES-ADIANTUM-PLAIN64 256-bit)
File Location	Keyfile: ${USB_STICK}/user/keyfile.asc	/usr/local/sbin/devora
Partition Types	FAT32 for EFI partition, Ext2 for /boot and /users	Comply to OS (e.g. Ext4)
Default Nature	Removable	binded to compute module
Recommended Usage	Booting 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.