mirror of
https://github.com/suikan4github/kaiten-yaki.git
synced 2025-12-20 10:31:17 -03:00
Update the documentation
This commit is contained in:
Suikan
parent
f1ad8ae660
commit
40972cebaf
4 changed files with 22 additions and 22 deletions
|
|
@ -1,7 +1,7 @@
|
|||
# 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 os passphrase is warn 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 under to use a long passphrase.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ 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. In this mode, the user can recover from 3 commands.
|
||||
In the case of the mistyping passphrase, GRUB goes into rescue mode. The user can recover by 3 commands from this mode.
|
||||
|
||||
```
|
||||
cryptomount -a
|
||||
|
|
@ -18,9 +18,9 @@ insmod normal
|
|||
normal
|
||||
```
|
||||
|
||||
The **cryptomount** command tries to mount the specific encrypted partition to boot. To mount it, the GRUB prompts the user to type the passphrase. The "-a" option specifies all encrypted partitions. If the system is encrypted by Kaiten-yaki, it has only one encrypted partition. So, this is the easiest way.
|
||||
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 the specified 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.
|
||||
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.
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ 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.
|
||||
|
||||
Alternatively, GURB is not in the rescue mode but the normal mode, even the passphrase is mistyped. So, the user can use command completion. This is better than 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.
|
||||
```
|
||||
|
|
@ -37,7 +37,7 @@ 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. By using **ls** command check the list of volumes existing in the system, and identify which volume contains the grub menu. And then, pick that volume and assign it to the **prefix** variable, with grub path.
|
||||
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.
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ Following is the screenshot of the command sequence to recover the mistyping of
|
|||
|
||||
|
||||
|
||||
## Summary
|
||||
## 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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,18 +6,18 @@ On the other hand, some extreme cases like installing distributions as many as p
|
|||
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. That means, up to 8 key hash values can be stored. In other words, the user can use 8 different keys to open a LUKS volume.
|
||||
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 some 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.
|
||||
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, its hash will be matched with the hash value in slot 0, by default.
|
||||
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 open the LUKS volume from the Linux kernel. This passphrase is different from the user passphrase. 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, the risk is small because it is difficult to ready for a human being.
|
||||
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
|
||||
|
|
@ -25,14 +25,13 @@ 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 2 or 3, if there is not vacant LUKS key slot.
|
||||
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 l
|
||||
The example of this command is shown below. Slot 0, 1, and 2 are occupied :
|
||||
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
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Let's assume there is a Ubuntu desktop system in which the disk was encrypted by
|
|||
|
||||
If the user mistyped the passphrase at boot, Ubuntu prompts to type a passphrase again. There is no pain. It just asks.
|
||||
|
||||
Now, what's happen if a user mistyped the passphrase on the Kaiten-yaki installed system. 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.
|
||||
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.
|
||||
|
||||
|
|
@ -19,19 +19,19 @@ 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 using more computation resources on the brute force attacking. The more stretching iteration times require the more resources to attack.
|
||||
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.
|
||||
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 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".
|
||||
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 makes the duration to the "Wrong password" 4 seconds, in the above example. This sounds acceptable.
|
||||
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 ).
|
||||
|
||||
|
|
|
|||
|
|
@ -6,11 +6,11 @@ This application note explains how to use the favorite partition with favorite s
|
|||
## 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.
|
||||
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/sdb.
|
||||
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"
|
||||
```
|
||||
|
|
@ -41,3 +41,4 @@ Now, it's a time to run Kaiten-yaki
|
|||
```sh
|
||||
source kaiten-yaki-ubuntu
|
||||
```
|
||||
All other operations are same with usual install.
|
||||
Loading…
Add table
Add a link
Reference in a new issue