PastaBoy12345/vystem-b
2
0
Fork 0
forked from lolo859/vystem
Code Pull Requests Activity

Vystem 0.2

Browse Source
This commit is contained in:
lolo859
2026-05-27 19:34:54 +02:00
parent a43c08b893
commit d238606b75
372 changed files with 51320 additions and 83217 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/boottools/commoncrypto.md Normal file
View File

@@ -0,0 +1,18 @@
# Common crypto docs
## Introduction
The `commoncrypto` library is responsible for providing all cryptographic functions necessary to `keygen`, `initfsgen` and later VyBuild
## Detailled informations
Folder: `Blastproof/commoncrypto`
It's build using VyBuild, as both a static and shared library. The provided build file doesn't allow yet for the library to be build outside of Vystem build process.
The `-Ofast -march=native` is used on every source file, to make it faster in every use case.
The library include the following external cryptographic library:
- SPHINCS+, made by the SPHINCS+ team, sourced from [sphincs/sphincsplus](https://github.com/sphincs/sphincsplus), under the MIT-0 license
- tiny_sha3, made by mjosaarinen, sourced from [mjosaarinen/tiny_sha3](https://github.com/mjosaarinen/tiny_sha3), under the MIT license
- Argon2, made by the Argon2 team, sourced from [P-H-C/phc-winner-argon2](https://github.com/P-H-C/phc-winner-argon2), under the CC0-1.0 license

11
docs/boottools/index.md
View File

@@ -1,10 +1,11 @@
# Bootloader tools Docs
In order to generate all necessary components for the build of a Vystem disk image, we have created several C++ tools designed to help generating these components. All of these tools have been intented to be used only in a normal Linux environnement. Here is the list of bootloader tools:
1) [bootanim](bootanim.md)
2) [fontgen](fontgen.md)
3) [initfsgen](initfsgen.md)
4) [keygen](keygen.md)
In order to generate all necessary components for the build of a Vystem disk image, we have created several C++ tools and library designed to help generating these components. All of these tools have been intented to be used only in a normal Linux environnement. Here is the list of bootloader tools:
1) [commoncrypto](commoncrypto.md)
2) [bootanim](bootanim.md)
3) [fontgen](fontgen.md)
4) [initfsgen](initfsgen.md)
5) [keygen](keygen.md)
Here a few precisions about the global mecanisms inside each tools:
- when a tool is iterating on the content of a folder, it rely on the order provided by the filesystem. But tool like `keygen` get there files list through arguments specifying direct files path rather than a folder path, making it a deterministic order if the build script doesn't change

12
docs/boottools/initfsgen.md
View File

@@ -9,9 +9,9 @@ The `initfsgen` utility is responsible for generating the InitFS and SignSyst fi
Folder: `Blastproof/initfsgen`
Source code file: `initfsgen.cpp`
For building `initfsgen`, use the provided build script `build.sh` while being in the utility directory.
For building `initfsgen`, you will need to use the provided build file. But for the moment, the provided build file doesn't allow yet for the utility to be build outside of Vystem build process. The build file will require `libcommoncrypto.a` to be provided inside the `initfsgen` folder.
External library:
External library provided by `commoncrypto` and used inside `initfsgen`:
- SPHINCS+, made by the SPHINCS+ team, sourced from [sphincs/sphincsplus](https://github.com/sphincs/sphincsplus), under the MIT-0 license
- tiny_sha3, made by mjosaarinen, sourced from [mjosaarinen/tiny_sha3](https://github.com/mjosaarinen/tiny_sha3), under the MIT license
@@ -35,16 +35,16 @@ initfsgen ./initfs_dir
2) Collect 48 bytes of entropy for installation ID and 8 bytes of entropy for entropy check, by opening `/dev/urandom`. No others method of entropy generation are or will be supported.
3) Copying installation ID inside InitFS and SignSyst headers, filling all possible informations about files and signatures quantity and sizes inside the headers.
4) Generating entropy check, putting it into InitFS header.
5) Computing installation ID hash and saving it into `initfs-footprint.bin`, saved into the current directory.
6) Computing hash of the content of `initfs-footprint.bin` and saving it into the InitFS header.
5) Computing installation ID hash and saving it into `initfsfp.bin`, saved into the current directory.
6) Computing hash of the content of `initfsfp.bin` and saving it into the InitFS header.
7) Iterate for each file: loading the entire file, generating InitFS file name, copying file data into files content area, computing file content hash, generating SPHINCS+ keypair unique to this file, generating signature for file by using private key, securely erasing private key (without compiler optimization), saving file hash and public key into file entry, saving file entry into files table and adding generated signature to SignSyst
8) Generating files table, files content area and signatures area hash, saving them into headers by xoring them with part of the installation ID
9) Generating and saving padding for InitFS and SignSyst headers. Computing headers hash and finalizing filesystems raw data.
10) Saving InitFS under `initfs.bin`, hashing SignSyst header and saving it into `signsyst-hash.bin`, saving SignSyst under `signsyst.bin`
10) Saving InitFS under `initfs.bin`, hashing SignSyst header and saving it into `sshash.bin`, saving SignSyst under `signsyst.bin`
For the full and detailled layout of InitFS and SignSyst, please see [customs filesystems docs](../blastproof/fs.md).
All hashing operations use SHA3-512. All entropy generations use secure entropy from `/dev/urandom`.
This utility generate four files:
- `initfs.bin` and `signsyst.bin` are the filesystems expected to be flashed into their respectives partitions on disk
- `initfs-footprint.bin` and `signsyst-hash.bin` are files expected to be protected by SPFIE and put inside the ESP partition
- `initfsfp.bin` and `sshash.bin` are files expected to be protected by SBFIE and put inside the ESP partition

27
docs/boottools/keygen.md
View File

@@ -2,16 +2,16 @@
## Introduction
The `keygen` utility is responsible for generating SPFIE keys, files and boot password. This file focus on how these ressources are generated and setuped, not how the verification is made at boot time. The explenations in this file are complementary to the informations in [SPFIE docs](../blastproof/spfie.md).
The `keygen` utility is responsible for generating VFTM keys, SBFIE keys, files and boot password. This file focus on how these ressources are generated and setuped, not how the verification is made at boot time. The explenations in this file are complementary to the informations in [SBFIE docs](../blastproof/sbfie.md) and [VFTM docs](../blastproof/vftm.md).
## Detailled informations
Folder: `Blastproof/keygen`
Source code file: `keygen.cpp`
For building `keygen`, first make sure that you have the `libargon2.a` static library file inside the utility directory. This one and the source of Argon2 for the `keygen` isn't included inside the main Vystem repository but downloaded and compiled by the build script. So you may have to compile Argon2 yourself before compiling `keygen`. To compile `keygen`, use the provided build script `build.sh` while being in the utility directory.
For building `keygen`, use the provided build file. The provided build file doesn't allow yet for the utility to be build outside of Vystem build process.
External libraries:
External libraries provided by `commoncrypto` and used inside `keygen`:
- SPHINCS+, made by the SPHINCS+ team, sourced from [sphincs/sphincsplus](https://github.com/sphincs/sphincsplus), under the MIT-0 license
- tiny_sha3, made by mjosaarinen, sourced from [mjosaarinen/tiny_sha3](https://github.com/mjosaarinen/tiny_sha3), under the MIT license
- Argon2, made by the Argon2 team, sourced from [P-H-C/phc-winner-argon2](https://github.com/P-H-C/phc-winner-argon2), under the CC0-1.0 license
@@ -24,19 +24,22 @@ sudo keygen <path to file 1> <path to file 2> ... <path to file n>
```
You can provide as much paths as you want, as long as they all lead to regular files.
It's recommanded the `keygen` utility be launched as root.
It's necessary the `keygen` utility be launched as root. If the user launched `keygen` using sudo, all created files and folder will be changed of owner to be owned by the user that launched the `keygen` utility.
To transmit the `manifest` keypair to VyBuild, `keygen` expect the `vftm.sock` UNIX socket to be created inside the current folder of execution. The generation process will fail if this socket isn't created by calling entity.
The `VYSTEM_KEYGEN_PASSWORD` environnement variable can be used to transmit a password. If this variable isn't defined of empty, the utility will default on standard input method. This method of transmiting the password should only be used if you are in a test/developpement environnement, and not in production.
## Detailled generation processus
1) Firstly, the `keygen` processus disable all possibilty of process memory dumps or memory swapping before doing anything else. Due the very thight security here, `keygen` should be running as root to ensure his own security.
2) Then, it check for the existence of all the provided files and lock private and public keys buffer as well as signature buffer to ensure that all the secrets aren't dumped on disk due to process fault or swapping.
3) Iterating for all the provided files: loading the file into memory, generating SPHINCS+ keypair for it, computing and signing the SHA3-512 hash of the file content if it's above 1 megabyte, or signing directly the file if under 1 megabyte, securely erasing all temporary keys and signature buffer, saving signature and public key into their dedicated buffer.
4) Saving all signatures into a directory named `sign`, created if non existing, under the name format `<original name>.sig`, then securely erasing the signatures buffer
5) Letting the user enter a boot password. If password is empty, it will ask for a number multiple of 2 to generate this many hexadecimal characters that will serve as password, the default amount of hexadecimal characters being 16. If the user enter a password, the user will have to confirm it
6) Checking that the password fill all criterias: should be (not enforced) at least 12 characters, can (enforced) only include ASCII characters due to EFI shell limitations, shouldn't be longer that 512 characters (enforced), and shoudn't use the numerical pad at all (not well supported in the EFI shell, but the user can still use numbers)
7) Offering the user the possibility to translate their password into a QWERTY representation of it, if they doesn't use a QWERTY keyboard. That way, the user can enter his password like he would do on his keyboard but the password that will be hashed will be the password translated in QWERTY.
1) Firstly, the `keygen` processus disable all possibilty of process memory dumps or memory swapping before doing anything else. Due the very thight security here, `keygen` must be running as root to ensure his own security.
2) It generate all the necessary keys for VFTM. Please see VFTM docs for more informations.
3) Verifying if the `VYSTEM_KEYGEN_PASSWORD` environnement variable exists and acting accordingly.
3) Then, it check for the existence of all the provided files and lock private and public keys buffer as well as signature buffer to ensure that all the secrets aren't dumped on disk due to process fault or swapping.
4) Iterating for all the provided files: loading the file into memory, generating SPHINCS+ keypair for it, computing and signing the SHA3-512 hash of the file content if it's above 1 megabyte, or signing directly the file if under 1 megabyte, securely erasing all temporary keys and signature buffer, saving signature and public key into their dedicated buffer.
5) Saving all signatures into a directory named `sign`, created if non existing, under the name format `<original name>.sig`, then securely erasing the signatures buffer
**Warning:** This feature is still very experimental, the only translation supported is AZERTY to QWERTY and the user experience is still very unsettling. For testing purposes, it's recommanded using a password with no characters differences between keyboard layout such as `test`, for example compatibility between the AZERTY and QWERTY keyboard. A better password inputing experience with support for various keyboard layout is planned for future release.
The 2 following steps are only executed if the standard password input method is selected:
6) Letting the user enter a boot password. If password is empty, it will ask for a number multiple of 2 to generate this many hexadecimal characters that will serve as password, the default amount of hexadecimal characters being 16. If the user enter a password, the user will have to confirm it
7) Checking that the password fill all criterias: should be (not enforced) at least 12 characters, can (enforced) only include ASCII characters due to EFI shell limitations, shouldn't be longer that 512 characters (enforced), and shoudn't use the numerical pad at all (not well supported in the EFI shell, but the user can still use numbers)
8) Converting the final password to UTF16LE for EFI environnement easier compatibilty. Obtaining 32 bytes of entropy from `/dev/urandom`. Hashing the password with the Argon2id algorithm using no parralelism, time cost of 3 and memory cost of 262144, with the salt, resulting in a 96 bytes output.
9) Using the password as seed for generating a master SPHINCS+ keypair. Generating a signature of the public keys of each files concatenated into a single block. Securely erasing both keys of the master keypair.