User:midnite/machizero

From Gentoo Wiki
Jump to:navigation Jump to:search


machizero is the main computer operating system under the umbrella of zandiro (currently under construction), powered by Gentoo Linux. It is the cornerstone of (almost) all zandiro applications. The followings are the essential aspects of the machizero, not one less.


Design

Plausible deniability encryption

Plausible deniability is archived by full disk encryption with detached header.[1] As the header is detached (e.g. to a removable USB), the main storage is no more than a random sequence of bits without the decryption key in the header. In theory, the attackers will not be able to prove if the disk is wiped with random data or containing encrypted data.

Although it is arguable whether plausible deniability works in real world scenarios,[2][3][4] ensuring data confidentiality can save lives in some cases.

Apart from extreme situations, having full disk encryption allows us to return our hard disks for warranty claims without any worries.

Important
It may seem invincible though, even a properly configured system is vulnerable to many other threats, including keylogger attack or as simple as shoulder surfing attack.

Data redundancy

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. -NeddySeagoon

Storage media is hardware. All hardware will fail. If it does not fail now, it will fail some days later.

Data confidentiality is critical, meanwhile storage reliability is equally important. machizero archives both by building software RAID on top of the full disk encryption.

Data integrity check

Data redundancy provides an extra copy (or copies) when data corruption occurs. The system needs to know when. There needs to be a mechanism to check whether the data is corrupted or not. Moreover, in case of a bit rot happens, the system needs to know which copies among the pool of redundancies are correct. This cannot be done without checksumming.

Snapshot

RAID and checksumming may tackle hardware errors well, there are significant times that data losses are due to human errors (including malfunctioning software) where data backup will save the day.

Conventional backup creation is usually a lengthy process and requires taking the system offline, which is not feasible to high-availability systems.

A full backup may consume up to the size of the original data. The storage space requirement is large. Considering machizero is already having data redundancy, a certain file can be duplicated into up to 4 places. This renders storage efficiency could be as low as 25%, which is undesirable.

RAID-1 mirror with backup may require up to 4x storage space.
Active Disks Mirror Disks
Current Disks 
A certain file
 
Mirror of the file
Backup Disks 
Full initial backup of the file
 
Mirror of the backup file

To solve the aforementioned issues, snapshots come into play. Snapshot creation does not require system downtime. Furthermore, the creation of a snapshot does not take up extra storage space. It only takes a “snapshot” of the system state at the moment, meanwhile allowing the system to be rolled back to a particular point in the past. Snapshot serves the purpose of undoing human and/or software errors.

Implementation

Warning
This section is under construction. Content here is incomplete or even incorrect. Please skip this section for now until this warning banner is taken down.

When considering redundancy over encryption (RAID on LUKS), versus encryption over redundancy (LUKS on RAID), many documentations recommend the later approach. Benefits includes:

On the contrary, the issues of having encryption over redundancy (LUKS on RAID) those need to be overcome includes:

  • Debugging RAID problems becomes much harder.[5] In case of RAID failure, one needs to be sure there are snapshots to roll back to previous working state.
  • You cannot do automatic RAID assembly

anymore.

  • You need to keep the encryption keys for the different RAID components in sync or manage them somehow.
  Filesystem 1    <- top
  |
  Encryption (LUKS)
  |
  RAID
  |
  Raw partitions (optional)
  |
  Raw disks      <- bottom
  Filesystem 2    <- top
  |
  Encryption (LUKS)
  |
  RAID
  |
  Raw partitions (optional)
  |
  Raw disks      <- bottom
machizero architecture
Layer Concept Implemented by Proof of concept Implemented Documented Automated
A Application Varies applications N/A N/A N/A N/A
6 Container LXD Not yet Not yet Not yet Not yet
5 Graphical user interface KDE Plasma Partial Partial Not yet Not yet
4 Display server Wayland Not yet Not yet Not yet Not yet
3 Operating system Gentoo Linux Yes Yes Not yet Not yet
2 RAID and filesystem ZFS with RAIDZ Yes Yes Not yet Not yet
1 Full disk encryption LUKS with detached header Yes Yes Not yet Not yet
0 Physical Storage Hard Disks N/A N/A N/A N/A

Full disk encryption

Full disk encryption is implemented using Linux Unified Key Setup (LUKS) with detached header. LUKS, an implementation of cryptsetup, is the best feature-wise, well maintained, and open source full disk encryption solution.[6]

RAID and Filesystem

ZFS is an innovative filesystem with volume management capabilities. ZFS, by its own, provides software RAID by its mirror and RAIDZ features.

To avoid any filesystem metadata appears on the physical disk which breaks plausible deniability, bare LUKS encryption needs to be sit in the lowest layer just on the bare disks. Besides, having multiple hard disks with identical random bit sequences would lower the degree of plausible deniability. Each member of the mirror or RAID needs its own LUKS header.

While RAID

TODO

Operating system

TODO

Display server

TODO

Graphical user interface

TODO

Container

TODO

Installation

The setup steps of machizero is highly inspired by the Gentoo Linux amd64 Handbook, the Sakaki's EFI Install Guide, and the Fearedbliss's Installing Gentoo Linux On ZFS. The commons, deviations, and options of choices will be explicitly annotated between the steps.

Installation Steps Collation
machizero Gentoo amd64 Handbook Sakaki's LUKS Guide Fearedbliss's ZFS Guide
Installation Prerequisites From 1) Introduction
until 8) Manual network configuration		 From 1) Installation Prerequisites
until 4) Setting Up Networking and Connecting via ssh
LUKS
on raw disks		 From 9) Introduction to block devices
until 12) Partitioning the disk with MBR for BIOS / legacy boot		 5) Preparing the LUKS-LVM Filesystem and Boot USB Key
ZFS mirror From 13) Creating file systems
until 14) Mounting the root partition		 Within 5) Preparing the LUKS-LVM Filesystem and Boot USB Key
Section 5-8) Formatting and Mounting the LVM Logical Volumes (LVs)
Install Gentoo From 15) Installing a stage tarball
until 43) Rebooting the system		 From 6) Installing the Gentoo Stage 3 Files
until 9) Final Preparations and Reboot into EFI
  1. Installation Prerequisites. Encryption is a double edged sword. It adds confidentiality to our system. Yet it is easy to render our data unrecoverable if not handled correctly. In this section there are some examples to get familiar with LUKS and ZFS. There are also some tests for performance. And gather necessary information to start the installation process.
  2. LUKS on raw disks.
  3. ZFS mirror
  4. Install Gentoo
  5. Wayland
  6. KDE Plasma
  7. LXD
  8. LAMP

References

  1. ↑ Bullet Proof Data Encryption with LUKS and a detached Header, originally inspired by this article.
  2. ↑ Cryptsetup FAQ Item 5.18 What about Plausible Deniability? So, does the idea work in practice? No, unfortunately.
  3. ↑ Rubber-hose cryptanalysis.
  4. ↑ The $5 wrench approach.
  5. ↑ Cryptsetup FAQ Item 2.2 Scenario 4 RAID on LUKS?. One is that suddenly debugging RAID issues becomes much harder.
  6. ↑ Comparison of disk encryption software
Retrieved from "https://wiki.gentoo.org/index.php?title=User:Midnite/machizero&oldid=1268689"