# Security and integrity model at boot level

## Introduction

The Vystem project has been designed for the ground up for security and integrity, and that start directly at the boot level, by focusing on boot file integrity.

## Overview

In order to achieve a strong amount of security without sacrificing compatibility with existing devices, we have chosen to integrate the following elements into the boot sequence:
- Vystem FAT Trusted Manifest (VFTM): ensure that the FAT32 filesystem on the ESP partition was produced by an authorized entity, that the ESP partition hasn't been changed from disk, that the FAT32 filesystem hasn't been corrupted or modified, and allow for the bootloader to check his own binary without EFI Secure Boot. It's signed by Keygen and verified by the bootloader himself. See [VFTM docs](vftm.md) for more informations.
- Secure Boot Files Integrity Enforcement (SBFIE): protect cores bootloader files assuming bootloader integrity with a user-defined password, without storing it directly but integrating it very deeply in the integrity check chain. See [SBFIE docs](sbfie.md) for more informations
- Robust post-quantum cryptography integrated directly into the bootloader: while we rely on EDK II for files and disk IO as well as password input, all the cryptography stack is integrated into the bootloader, not relying on firmware cryptography at any time. We use post-quantum signing algorithm like SPHINCS+ and strong hashing primitives like Argon2 and SHA3, with their sources codes directly taken from their official implementation, only modified to integrate with EDK II types and memory allocation system
- Signing of every system files: every sensitive system file is integrated into the InitFS, signed into a trio of check: each Blastproof binary (and so SBFIE keys), InitFS and SignSyst is uniquely associated (mainly by installation ID), meaning that the whole system can only work if all of them are properly setup on the same machine device. InitFS integrity check are also cryptographically linked to SBFIE verification.

## Limitations

The current Vystem security model assume that we can trust the firmware and that the user boot password is secure. We plan to add support for UEFI secure boot by using custom certificates generation in the future.

## Detailled parameters for cryptographic algorithms

For SPHINCS+, we use the set of parameters named `sphincs-sha2-256f`.
For SHA3, we use the standard implementation with the 512 bits variant.
For Argon2, we disable parallelism (this would be a pain to setup in a UEFI environnement) and use the following parameters: 96 bytes output (to match SPHINCS+ keypair seed size), 32 bytes salt, memory cost set to 262144 and time cost set to 3. We use the Argon2id variant.
