Preservation/kaiten-yaki
1
0
Fork 0
mirror of https://github.com/suikan4github/kaiten-yaki.git synced 2025-12-20 02:21:17 -03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Removed applicaiton notes.

Browse source 
Move application notes to Wiki

  Issue #28
This commit is contained in:
Suikan 2021-07-21 09:27:45 +09:00
parent e0ff77c549
commit 00d506a017
6 changed files with 4 additions and 247 deletions
Download patch file Download diff file Expand all files Collapse all files

2
CHANGELOG.md
View file

@ -10,6 +10,8 @@ Record of the modification in project development.
### Deprecated
### Removed
- [Issue 28 : Move application notes to Wiki](https://github.com/suikan4github/kaiten-yaki/issues/28)
### Fixed
- [Issue 24 : Fail to install the ubuntu when the / volume is btrfs](https://github.com/suikan4github/kaiten-yaki/issues/24)

7
README.md
View file

@ -48,11 +48,8 @@ If you install two or more Void Linux into the EFI system, only the last one can
# Variants considerations
Ubuntu has several variants ( flavors ). While while only the MATE flavor is tested, other flavors may work correctly as far as it uses Ubiquity installer.
# Application notes
- [AN01 : How to recover from the mistyping of the passphrase](appnote/an01_howtorecover.md)
- [AN02 : Managing LUKS key slots](appnote/an02_keyslot.md)
- [AN03 : The ITERTIME parameter and vulnerability](appnote/an03_itertime.md)
- [AN04 : How to make LUKS volume to the favorite partition](appnote/an04_favoritepartition.md)
# Other resources
See [Wiki](wiki/) for the application notes and the useful links.
# Acknowledgments
These scripts are based on the script by [myn's diary](https://myn.hatenablog.jp/entry/install-ubuntu-focal-with-lvm-on-luks). That page contains rich information, hint, and techniques around the encrypted volume and Ubiquity installer.

67
appnote/an01_howtorecover.md
View file

@ -1,67 +0,0 @@
# AN01 : How to recover from the mistyping of the passphrase
The mistyping of the passphrase is painful, in the full disk encrypted Linux.
In the usual encrypted Ubuntu install by Ubiquity, mistyping disk passphrase is warned by the kernel, and prompted to re-type. But in the full encrypted system, the user sees a boring message and command prompt. Usually, the user just gives up and reboot. It adds tens of second to reboot, and discourage the user to use a long passphrase.
![bios](../image/an01_bios.png)
This application note explains how to recover from this condition, quickly.
# BIOS system
In the BIOS system, the recovery is pretty easy.
In the case of the mistyping passphrase, GRUB goes into rescue mode. The user can recover by 3 commands from this mode.
```
cryptomount -a
insmod normal
normal
```
The **cryptomount** command tries to mount the encrypted partition specified by parameter. To mount it, GRUB prompts the user to type the passphrase. The "-a" option means all encrypted partitions. If the system is encrypted by Kaiten-yaki, it has only one encrypted LUKS partition. So, this is the easiest way.
The **insmod** command loads a GRUB command module from the mounted storage and inserts it into the command list. The second line loads the "normal" command which displays the normal menu to the user.
Finally, **normal** command shows the normal boot menu to the user.
Now, the user can select the system to boot as usual.
# EFI system
In the EFI system, recovery needs extra steps compared to the BIOS system.
Unlike the BIOS system, GURB is not in the rescue mode but the normal mode, when the passphrase is mistyped. So, the user can use command completion. This is better than the BIOS system.
The first step of the recovery is the same with the BIOS system.
```
cryptomount -a
```
Again, in the EFI system, the user can use the command completion by pressing the [TAB] key.
The second step is unique in the EFI system. The user can check the list of volumes existing in the system by **ls** command. The ls command allows the user can identify which volume contains the grub menu. And then, the user picks the right volume and assign it to the **prefix** variable, with the grub path.
Following is the example. The (lvm/vg1-mate) is dependent on the system. It has to be substituted by the appropriate volume name for each system.
```
ls
set prefix=(lvm/vg1-mate)/boot/grub
```
Note that above example assumes the root volume format is usual one ( ex: ext4, jfs, xfs ). If the root volume is formatted by btrfs, above prefix doesn't work. The path name should contain the sub-volume name :
```
ls
set prefix=(lvm/vg1-mate)/@/boot/grub
```
Then, the third step is the same with the BIOS systems.
```
insmod normal
normal
```
Following is the screenshot of the command sequence to recover the mistyping of the passphrase.
![bios](../image/an01_efi.png)
## Conclusion
In the full disk encrypted system, mistyping of the passphrase is more painful than the partially encrypted system. The user can overcome this situation with several steps of commands and can show the normal boot menu.
![bios](../image/an01_normal.png)

83
appnote/an02_keyslot.md
View file

@ -1,83 +0,0 @@
# AN02 Managing LUKS key slots
If somebody wants to install two or three distributions into a system, Kaiten-yaki works perfectly. There is no problem at all.
On the other hand, some extreme cases like installing distributions as many as possible, or repeating the overwrite installation unveils the limitation of the number of the LUKS key slots. The user must understand and must manage the LUKS key slots well, to handle these cases.
This application note explains the limitations and difficulties that come from the number of LUKS key slots, and how to overcome that limitation( if possible ).
# The LUKS key slots
The LUKS volume has 8 key slots which can stores one key hash value. In other words, the user can use 8 different keys to open a LUKS volume.
In this context, the "user" is not limited to a human being. Any software can use a passphrase to open a LUKS volume. Thus, even only one person uses a computer, multiple key slots may be used.
If an user ( or software ) feeds a passphrase to open a LUKS volume, the management software ( dm-crypt library ) scans key slots and check whether there is a matching slot or not. If there is a slot in which the stored hash value matches with the hash value of the given passphrase, that passphrase is the right one.
# How Kaiten-yaki uses the LUKS key slots
Kaiten-yaki uses N+1 LUKS key slots to install the N distributions in a system ( where N is an integer ).
Whenever Kaiten-yaki creates a LUKS volume, it registers a passphrase typed by the user. This passphrase is stored in the key slot 0. So, when the user types his passphrase correctly at boot time, its hash will be matched with the hash value in slot 0, by default.
In addition to the user passphrase, Kaiten-yaki uses one key slot to register the passphrase to let the Linux kernel open the LUKS volume. This passphrase is different from the user passphrase. Actually, this passphrase is random binary brock generated by /dev/random. This key is stored in the file under /etc/luks. Even somebody watches its value over the shoulder of a user, the risk is small because it is difficult to read for a human being.
Anyway, this usage defines the maximum number of Linux installed in a system. That is 7 if all are installed by Kaiten-yaki. If a user try to install the 8th distribution in a LUKS volume with Kaiten-yaki, it will fail because there is no vacant LUKS key slot.
# Overwrite installation
The overwrite installation is another case that consumes a LUKS key slot.
if the variable OVERWITEINSTALL in config.sh is set to 1, Kaiten-yaki just overwrites an existing logical volume in the LUKS volume. Also, in this case, Kaiten-yaki registers a new key file for the new installation. Thus, while the number of the installed Linux is the same, the number of the used LUKS key slot is increased.
Eventually, the user fails to install even the installed Linux is small like 2 or 3, if there is not vacant LUKS key slot.
# Managing key slots
Some users may want to delete a key slot to install another distribution. In this case, they must know which LUKS key slots are used or not.
This section explains how to investigate the used slots.
First of all, user can list the status of the all LUKS key slots. The example of this command is shown below. Slot 0, 1, and 2 are occupied :
```
takemasa@mate-vm:~$ sudo cryptsetup luksDump /dev/sda2 | grep -i bled
Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
```
If there is still a vacant LUKS key slot, the user can install another distribution without deleting the existing slot. But if there is not vacant LUKS key slot at all, the user must delete an occupied but unused slot. To know such a slot, the user must mark all the occupied and used slots.
First of all, check the LUKS key slot for the user passphrase. Run the followings command.
```sh
cryptsetup -v --test-passphrase luksOpen /dev/sdXN
```
Where X is a, b, c..., N is 1, 2, 3...
The command will prompt to type the passphrase to decrypt. If the user types the correct passphrase, the command shows the key slot number of that passphrase. The followings are the example :
```
takemasa@mate-vm:~$ sudo cryptsetup -v --test-passphrase luksOpen /dev/sda2
Enter passphrase for /dev/sda2:
Key slot 0 unlocked.
Command successful.
```
We can see the slot 0 is used.
Next, run the following command **for each** installation of distribution. This command shows the slot number which stores the key of the passphrase file passing to the kernel. /etc/luks/boot_os.keyfile is created by Kaiten-yaki, during the installation
```sh
sudo cryptsetup -v --test-passphrase luksOpen /dev/sdXN --key-file /etc/luks/boot_os.keyfile
```
Followings are the sample execution :
```
takemasa@mate-vm:~$ sudo cryptsetup -v --test-passphrase luksOpen /dev/sda2 --key-file /etc/luks/boot_os.keyfile
Key slot 2 unlocked.
Command successful.
```
By repeating this command inside all installations, the user can list up the occupied and used slots. The other slots are occupied but not used.
Finally, the user can delete the appropriate occupied but not used LUKS key slot by the following command.
```sh
sudo cryptsetup luksKillSlot /dev/sdXN key_slot_number_to_delete
```
# Conclusion
For the typical case like installing 2 or 3 distributions in a system, there is no problem to use Kaiten-yaki, at all.
But if users want to install as many as possible, or repeat the overwrite install, they must understand the number of the LUKS key slots.

48
appnote/an03_itertime.md
View file

@ -1,48 +0,0 @@
# AN03 The ITERTIME parameter and vulnerability
The ITERTIME configuration parameter in the config.sh can provide a better user experience during the passphrase input. It can reduce the pain of the longer passphrase and encourage users to use longer passphrases.
On the other hand, it may pull a vulnerability.
The followings are the consideration around the ITERTIME parameter.
## The passphrase experience
Let's assume there is a Ubuntu desktop system in which the disk was encrypted by Ubiquity installer without Kaiten-yaki. In this system, the /boot partition is installed as a separate and un-encrypted state. So, the Linux kernel file is not protected.
If the user mistyped the passphrase at boot, Ubuntu prompts to type a passphrase again. There is no pain. It just asks.
Now, let's see what's happen if a user mistyped the passphrase on the system which was installed by Kaiten-yaki. It takes a very wrong time to see the error message. And the system doesn't prompt to type again ( The prompt issue is discussed in the [AN01](an01_howtorecover.md) ). Especially, the more number of the installations in a system makes the longer duration till the error message. Sometimes this is unbearable pain to the user.
This kind of pain de-motivates users to use a long passphrase, because the longer passphrase causes more mistypes. As a result, some users may use the shorter passphrase. The bad user experience of passphrase input may help the malicious attackers.
## Why the full disk encryption is so slow at passphrase input
GRUB is the root cause of this slow user passphrase matching.
The passphrase is hashed and stored to LUKS key slot when a LUKS volume is created ( or, a new passphrase is added ). The stored hash value is not simple. The cryptsetup command makes hash value from the user passphrase. And then, create the next hash from this hash. And then, create a third hash from the 2nd hash, so on. This repeating is named [key stretching](https://en.wikipedia.org/wiki/Key_stretching).
The key stretching technique enforces malicious attackers to use more computation resources on the brute force attacking. The more stretching iteration times require the more resources to attack.
Of course, there is a balance and security strength. By default, the cryptsetup command takes the iteration needing 1 sect to calculate the passphrase hash, for the LUKS1 format. This sounds like a good balance. The cryptsetup runs on Linux when it calculates the appropriate iteration of key stretching. So, there is no problem if Linux challenges user passwords. It will take about 1 sec, by default on the Linux system. 1 second is acceptable for almost users.
But there is a pitfall. On the full disk encryption system by Kaiten-yaki, the /boot is encrypted. So, to load the Linux kernel, GRUB has to decrypt the LUKS volume. That means GRUB has to calculate the passphrase hash. Unfortunately, this calculation is slower than Linux's one. Thus the user has to wait longer than 1 second.
The duration by GRUB to calculate the passphrase hash value is up to the system. It depends on the CPU. Also, In addition to this slow hashing, GRUB has to scan all used key slots when the user mistyped. For example, if 3 distributions are installed in a LUKS volume by Kaiten-yaki, 4 key slots are used. Thus, if it takes 10 seconds to challenged one hash by GRUB, this system takes 40seconds to show "The wrong password".
This is the mechanism of the slow response at the passphrase input.
## The key stretching, the --iter-time parameter, and the vulnerability
Kaiten-yaki can relax this pain by ITERTIME configuration parameter in config.sh. This parameter is passed to the cryptsetup command as --iter-time parameter.
By setting 1000 to the ITERTIME, cryptsetup takes the key stretching iteration cycle to take 1000 milliseconds. By setting 100, it will be 100 milliseconds. It is believed the default value of --iter-time is 1000 ( Its compile default ). Thus, choosing 100 as ITERTIME shorten the duration to the "Wrong password" from 40 seconds to 4 seconds, in the above example. This sounds acceptable.
On the other hand, the smaller ITERTIME is the weaker to the bute force attack. It is assumed the strength of the passphrase hash is linear to the ITERTIME parameter ( --iter-time parameter of cryptsetup ).
## The longer passphrase vs. longer key stretching
While the passphrase hash strength is considered linear to the key stretching iteration, the passphrase strength is exponential to its length.
There many discussions on the strength of the passphrase. Simply speaking, Adding one alphabet ( a-z ) may expand its strength 26 times. That is why the long passphrase is very important.
The 1/10 strength of the key stretching can be covered by adding 1 character to the passphrase.
## Conclusion
The full disk encryption will give big pain to the user at the passphrase input phase. It seems to be reasonable to use the smaller ITERTIME ( --iter-time ) parameter to encourage the user to use the longer passphrase like 20 letters, from the viewpoint of security.
The security policy is up to the people, community, and mission. The consideration here assumed the desktop PC as a hobby. For mission-critical usage, the user should consult security experts.

44
appnote/an04_favoritepartition.md
View file

@ -1,44 +0,0 @@
# AN04 How to make LUKS volume to the favorite partition
Kaiten-yaki creates the LUKS volume on the 1st partition for the BIOS system ( 2nd partition for the EFI system ) by default. Also, Kaiten-yaki assigns all space for the LUKS volume, except the space for the EFI partition.
This application note explains how to use the favorite partition with favorite size for LUKS volume.
## Step 1: Making partitions
To use custom partitioning, the user must create all partitions by themselves. The user can do it with the popular partitioning tool like gparted. It is recommended to set the partition table as MBR and GPT for BIOS and EFI systems, respectively.
In this documentation, we assume the user wants to use /dev/sda5 as LUKS partition to install Ubuntu, as example.
## Step 2: Configuration
Next user must configure the config.sh.
The first parameter to edit is **DEV** parameter which represents the target device. In this example, it must be set as /dev/sda.
```sh
export DEV="/dev/sda"
```
The second parameter to edit is **CRYPTPARTITION**. By default, this parameter is set automatically according to the firmware type. The EFIPARTITION parameter can be left untouched. This parameter is not used.
```sh
if [ ${ISEFI} -ne 0 ] ; then
# EFI firmware
export EFIPARTITION=1
export CRYPTPARTITION=5
else
# BIOS firmware
export CRYPTPARTITION=5
fi # EFI firmware
```
Makes sure the **ERASEALL** and **OVERWRITEINSTALL** are 0.
## Step 3: Make LUKS partition
After saving the customer config.sh, run the following command to set the environment variable.
```sh
source config.sh
```
Then, run the following command to create a LUKS volume.
```sh
cryptsetup luksFormat --iter-time "${ITERTIME}" --type=luks1 "${DEV}${CRYPTPARTITION}"
```
This command sets up the LUKS volume on the specified partition. This command also asks for the passphrase of this LUKS volume.
## Step 4: Run Kaiten-yaki
Now, it's a time to run Kaiten-yaki
```sh
source kaiten-yaki-ubuntu
```
All other operations are same with usual install.