2023-02-08 21:01:48 +00:00
#!/bin/bash
2024-10-22 21:42:47 +00:00
# This script contains various functions related to LUKS (Linux Unified Key Setup) encryption management.
2022-03-23 19:47:33 +00:00
. /etc/functions
. /etc/gui_functions
. /tmp/config
2024-10-22 21:42:47 +00:00
# List all LUKS devices on the system that are not USB
list_local_luks_devices() {
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
TRACE_FUNC
2023-10-18 17:15:48 +00:00
lvm vgscan || true
2024-10-22 21:42:47 +00:00
blkid | cut -d ':' -f 1 | while read -r device; do
DEBUG "Checking device: $device"
if cryptsetup isLuks "$device"; then
DEBUG "Device $device is a LUKS device"
dev_name=$(basename "$device")
parent_dev_name=$(echo "$dev_name" | sed 's/[0-9]*$//')
if [ -e "/sys/block/$parent_dev_name" ]; then
DEBUG "Device $device exists in /sys/block"
if ! stat -c %N "/sys/block/$parent_dev_name" 2>/dev/null | grep -q "usb"; then
DEBUG "Device $device is not a USB device"
echo "$device"
else
DEBUG "Device $device is a USB device, skipping"
fi
else
DEBUG "Device $device does not exist in /sys/block, skipping"
fi
else
DEBUG "Device $device is not a LUKS device"
fi
2023-10-18 17:15:48 +00:00
done | sort
2023-07-19 22:48:03 +00:00
}
2024-10-22 21:42:47 +00:00
# Prompt for LUKS Disk Recovery Key passphrase
prompt_luks_passphrase() {
TRACE_FUNC
while [[ ${#luks_current_Disk_Recovery_Key_passphrase} -lt 8 ]]; do
echo -e "\nEnter the LUKS Disk Recovery Key passphrase (At least 8 characters long):"
read -r luks_current_Disk_Recovery_Key_passphrase
if [[ ${#luks_current_Disk_Recovery_Key_passphrase} -lt 8 ]]; then
echo -e "\nPassphrase must be at least 8 characters long. Please try again."
unset luks_current_Disk_Recovery_Key_passphrase
continue
fi
done
echo -n "$luks_current_Disk_Recovery_Key_passphrase" >/tmp/secret/luks_current_Disk_Recovery_Key_passphrase
}
# Test LUKS passphrase against all found LUKS containers that are not USB
test_luks_passphrase() {
TRACE_FUNC
list_local_luks_devices >/tmp/luks_devices.txt
if [ ! -s /tmp/luks_devices.txt ]; then
warn "No LUKS devices found"
return 1
fi
valid_luks_devices=()
while read -r luks_device; do
DEBUG "Testing passphrase on $luks_device"
if cryptsetup open --test-passphrase "$luks_device" --key-file /tmp/secret/luks_current_Disk_Recovery_Key_passphrase; then
DEBUG "Passphrase valid for $luks_device"
valid_luks_devices+=("$luks_device")
else
DEBUG "Passphrase test failed on $luks_device"
fi
done </tmp/luks_devices.txt
if [ ${#valid_luks_devices[@]} -eq 0 ]; then
return 1
fi
# Export the valid LUKS devices
export LUKS="${valid_luks_devices[*]}"
return 0
}
# Confirm with the user to use all unlockable LUKS partitions
confirm_luks_partitions() {
TRACE_FUNC
MSG="The following LUKS partitions can be unlocked:\n\n${LUKS}\n\nDo you want to use all of these partitions?"
if [ -x /bin/whiptail ]; then
if ! whiptail --title "Confirm LUKS Partitions" --yesno "$MSG" 0 80; then
die "User aborted the operation"
fi
else
echo -e "$MSG"
read -p "Do you want to use all of these partitions? (y/n): " confirm
if [ "$confirm" != "y" ]; then
die "User aborted the operation"
fi
fi
}
# Main function to prompt for passphrase, test it, and confirm partitions
main_luks_selection() {
TRACE_FUNC
prompt_luks_passphrase
if ! test_luks_passphrase; then
die "Passphrase test failed on all LUKS devices"
fi
confirm_luks_partitions
DEBUG "Selected LUKS partitions: $LUKS"
}
2023-10-18 17:15:48 +00:00
#Whiptail prompt asking user to select ratio of device to use for LUKS container between: 25, 50, 75
select_luks_container_size_percent() {
2024-02-01 19:30:31 +00:00
TRACE_FUNC
2023-07-19 22:48:03 +00:00
if [ -x /bin/whiptail ]; then
2023-10-18 17:15:48 +00:00
#whiptail prompt asking user to select ratio of device to use for LUKS container between: 25, 50, 75
2023-07-19 22:48:03 +00:00
#whiptail returns the percentage of the device to use for LUKS container
whiptail --title "Select LUKS container size percentage of device" --menu \
"Select LUKS container size percentage of device:" 0 80 10 \
"10" "10%" \
"25" "25%" \
"50" "50%" \
"75" "75%" \
2> /tmp/luks_container_size_percent \
|| die "Error selecting LUKS container size percentage of device"
else
#console prompt asking user to select ratio of device to use for LUKS container between: 10, 25, 50, 75
#console prompt returns the percentage of the device to use for LUKS container
echo "Select LUKS container size percentage of device:"
echo "1. 10%"
echo "2. 25%"
echo "3. 50%"
echo "4. 75%"
read -p "Choose your LUKS container size percentage of device [1-3]: " option_index
if [ "$option_index" = "1" ]; then
2024-10-22 21:42:47 +00:00
echo "10" >/tmp/luks_container_size_percent
2023-07-19 22:48:03 +00:00
elif [ "$option_index" = "2" ]; then
2024-10-22 21:42:47 +00:00
echo "25" >/tmp/luks_container_size_percent
2023-07-19 22:48:03 +00:00
elif [ "$option_index" = "3" ]; then
2024-10-22 21:42:47 +00:00
echo "50" >/tmp/luks_container_size_percent
2023-07-19 22:48:03 +00:00
elif [ "$option_index" = "4" ]; then
2024-10-22 21:42:47 +00:00
echo "75" >/tmp/luks_container_size_percent
2023-07-19 22:48:03 +00:00
else
die "Error selecting LUKS container size percentage of device"
fi
fi
}
2023-11-13 19:37:19 +00:00
# Partition a device interactively with two partitions: a LUKS container
# containing private ext4 partition and second public exFAT partition
2023-07-19 22:48:03 +00:00
# Size provisioning is done by percentage of the device
2024-10-22 21:42:47 +00:00
interactive_prepare_thumb_drive() {
2024-02-01 19:30:31 +00:00
TRACE_FUNC
2023-07-19 22:48:03 +00:00
#Refactoring: only one parameter needed to be prompted for: the passphrase for LUKS container if not coming from oem-provisioning
#If no passphrase was provided, ask user to select passphrase for LUKS container
# if no device provided as parameter, we will ask user to select device to partition
# if no percentage provided as parameter, we will default to 10% of device to use for LUKS container
# we will validate parameters and not make them positional and print a usage function first
2024-10-22 21:42:47 +00:00
2023-07-19 22:48:03 +00:00
#Set defaults
2024-10-22 21:42:47 +00:00
DEVICE="" #Will list all usb storage devices if not provided as parameter
2023-07-19 22:48:03 +00:00
PERCENTAGE="10" #default to 10% of device to use for LUKS container (requires a LUKS partition bigger then 32mb!)
2024-10-22 21:42:47 +00:00
PASSPHRASE="" #Will prompt user for passphrase if not provided as parameter
2023-07-19 22:48:03 +00:00
#Parse parameters
while [ $# -gt 0 ]; do
case "$1" in
--device)
DEVICE=$2
shift 2
;;
--percentage)
PERCENTAGE=$2
shift 2
;;
2023-10-18 17:15:48 +00:00
--pass)
2023-07-19 22:48:03 +00:00
PASSPHRASE=$2
shift 2
;;
*)
2023-10-18 17:15:48 +00:00
echo "usage: prepare_thumb_drive [--device device] [--percentage percentage] [--pass passphrase]"
2023-11-13 19:37:19 +00:00
return 1
2023-07-19 22:48:03 +00:00
;;
esac
done
DEBUG "DEVICE to partition: $DEVICE"
DEBUG "PERCENTAGE of device that will be used for LUKS container: $PERCENTAGE"
#Output provided if passphrase is provided as parameter
DEBUG "PASSPHRASE for LUKS container: ${PASSPHRASE:+provided}"
#Prompt for passphrase if not provided as parameter
if [ -z "$PASSPHRASE" ]; then
#If no passphrase was provided, ask user to select passphrase for LUKS container
#console based no whiptail
while [[ ${#PASSPHRASE} -lt 8 ]]; do
2024-10-22 21:42:47 +00:00
{
echo -e "\nEnter passphrase for LUKS container (At least 8 characters long):"
#hide passphrase input from read command
read -r -s PASSPHRASE
#skip confirmation if passphrase is less then 8 characters long (continue)
if [[ ${#PASSPHRASE} -lt 8 ]]; then
echo -e "\nPassphrase must be at least 8 characters long. Please try again."
unset PASSPHRASE
continue
fi
#validate passphrase and ask user to re-enter if not at least 8 characters long
#confirm passphrase
echo -e "\nConfirm passphrase for LUKS container:"
#hide passphrase input from read command
read -r -s PASSPHRASE_CONFIRM
#compare passphrase and passphrase confirmation
if [ "$PASSPHRASE" != "$PASSPHRASE_CONFIRM" ]; then
echo -e "\nPassphrases do not match. Please try again."
unset PASSPHRASE
unset PASSPHRASE_CONFIRM
fi
2023-07-19 22:48:03 +00:00
2024-10-22 21:42:47 +00:00
}
done
2023-07-19 22:48:03 +00:00
fi
#If no device was provided, ask user to select device to partition
if [ -z "$DEVICE" ]; then
#warn user to disconnect all external drives
if [ -x /bin/whiptail ]; then
2024-06-06 22:59:13 +00:00
whiptail_warning --title "WARNING: Disconnect all external drives" --msgbox \
2024-10-22 21:42:47 +00:00
"WARNING: Please disconnect all external drives before proceeding.\n\nHit Enter to continue." 0 80 ||
die "User cancelled wiping and repartitioning of $DEVICE"
2023-07-19 22:48:03 +00:00
else
echo -e -n "Warning: Please disconnect all external drives before proceeding.\n\nHit Enter to continue?"
read -r -p " [Y/n] " response
#transform response to uppercase with bash parameter expansion
response=${response^^}
#continue if response different then uppercase N
if [[ $response =~ ^(N)$ ]]; then
die "User cancelled wiping and repartitioning of $DEVICE"
fi
fi
#enable usb
enable_usb
#enable usb storage
enable_usb_storage
#list all usb storage devices
2024-10-22 21:42:47 +00:00
list_usb_storage disks >/tmp/devices.txt
2023-07-19 22:48:03 +00:00
if [ $(cat /tmp/devices.txt | wc -l) -gt 0 ]; then
file_selector "/tmp/devices.txt" "Select device to partition"
if [ "$FILE" == "" ]; then
die "Error: No device selected"
else
DEVICE=$FILE
fi
else
die "Error: No device found"
fi
fi
#Check if device is a block device
if [ ! -b $DEVICE ]; then
die "Error: $DEVICE is not a block device"
fi
if [ -z "$PERCENTAGE" ]; then
#If no percentage was provided, ask user to select percentage of device to use for LUKS container
select_luks_container_size_percent
PERCENTAGE=$(cat /tmp/luks_container_size_percent)
fi
2023-11-13 19:37:19 +00:00
confirm_thumb_drive_format "$DEVICE" "$PERCENTAGE" ||
die "User cancelled wiping and repartitioning of $DEVICE"
prepare_thumb_drive "$DEVICE" "$PERCENTAGE" "$PASSPHRASE"
}
# Show a prompt to confirm formatting a flash drive with a percentage allocated
# to LUKS. interactive_prepare_thumb_drive() uses this; during OEM reset it is
# used separately before performing any reset actions
#
# parameters:
# $1 - block device of flash drive
# $2 - percent of device allocated to LUKS [1-99]
2024-10-22 21:42:47 +00:00
confirm_thumb_drive_format() {
2024-02-01 19:30:31 +00:00
TRACE_FUNC
2023-11-13 19:37:19 +00:00
local DEVICE LUKS_PERCENTAGE DISK_SIZE_BYTES DISK_SIZE_DISPLAY LUKS_PERCENTAGE LUKS_SIZE_MB MSG
DEVICE="$1"
LUKS_PERCENTAGE="$2"
LUKS_SIZE_MB=
2023-07-19 22:48:03 +00:00
2023-11-13 19:37:19 +00:00
#Get disk size in bytes
2023-07-19 22:48:03 +00:00
DISK_SIZE_BYTES="$(blockdev --getsize64 "$DEVICE")"
2023-11-13 19:37:19 +00:00
DISK_SIZE_DISPLAY="$(display_size "$DISK_SIZE_BYTES")"
2023-07-19 22:48:03 +00:00
#Convert disk size to MB
DISK_SIZE_MB=$((DISK_SIZE_BYTES/1024/1024))
2023-11-13 19:37:19 +00:00
#Calculate percentage of device in MB
LUKS_SIZE_MB="$((DISK_SIZE_BYTES*LUKS_PERCENTAGE/100/1024/1024))"
2023-10-18 17:15:48 +00:00
2023-11-13 19:37:19 +00:00
MSG="WARNING: Wiping and repartitioning $DEVICE ($DISK_SIZE_DISPLAY) with $LUKS_SIZE_MB MB\n assigned to private LUKS ext4 partition,\n rest assigned to exFAT public partition.\n\nAre you sure you want to continue?"
2023-07-19 22:48:03 +00:00
if [ -x /bin/whiptail ]; then
2024-06-06 22:59:13 +00:00
whiptail_warning --title "WARNING: Wiping and repartitioning $DEVICE ($DISK_SIZE_DISPLAY)" --yesno \
2023-11-13 19:37:19 +00:00
"$MSG" 0 80
2023-07-19 22:48:03 +00:00
else
2023-11-13 19:37:19 +00:00
echo -e -n "$MSG"
2023-07-19 22:48:03 +00:00
read -r -p " [Y/n] " response
#transform response to uppercase with bash parameter expansion
response=${response^^}
2023-11-13 19:37:19 +00:00
#continue if response is Y, y, or empty, abort for anything else
if [ -n "$response" ] && [ "${response^^}" != Y ]; then
return 1
2023-07-19 22:48:03 +00:00
fi
fi
2023-11-13 19:37:19 +00:00
}
# Prepare a flash drive with a private LUKS-encrypted ext4 partition and a
# public exFAT partition. This is not interactive - during OEM reset, any
# selections/confirmations must occur before OEM reset starts resetting the
# system.
#
# $1 - block device of flash drive
# $2 - percentage of flash drive to allocate to LUKS [1-99]
# $3 - passphrase for LUKS container
2024-10-22 21:42:47 +00:00
prepare_thumb_drive() {
2024-02-01 19:30:31 +00:00
TRACE_FUNC
2023-11-13 19:37:19 +00:00
local DEVICE PERCENTAGE PASSPHRASE DISK_SIZE_BYTES PERCENTAGE_MB
DEVICE="$1"
PERCENTAGE="$2"
PASSPHRASE="$3"
#Get disk size in bytes
DISK_SIZE_BYTES="$(blockdev --getsize64 "$DEVICE")"
#Calculate percentage of device in MB
PERCENTAGE_MB="$((DISK_SIZE_BYTES*PERCENTAGE/100/1024/1024))"
2023-07-19 22:48:03 +00:00
2023-11-13 19:37:19 +00:00
echo -e "Preparing $DEVICE with $PERCENTAGE_MB MB for private LUKS container while rest of device will be assigned to exFAT public partition...\n"
2023-10-19 19:42:27 +00:00
echo "Please wait..."
2023-07-19 22:48:03 +00:00
DEBUG "Creating empty DOS partition table on device through fdisk to start clean"
2023-10-18 17:15:48 +00:00
echo -e "o\nw\n" | fdisk $DEVICE >/dev/null 2>&1 || die "Error creating partition table"
2023-07-19 22:48:03 +00:00
DEBUG "partition device with two partitions: first one being the percent applied and rest for second partition through fdisk"
2023-10-18 17:15:48 +00:00
echo -e "n\np\n1\n\n+"$PERCENTAGE_MB"M\nn\np\n2\n\n\nw\n" | fdisk $DEVICE >/dev/null 2>&1 || die "Error partitioning device"
DEBUG "cryptsetup luksFormat first partition with LUKS container aes-xts-plain64 cipher with sha256 hash and 512 bit key"
2023-07-19 22:48:03 +00:00
DEBUG "Creating ${PERCENTAGE_MB}MB LUKS container on ${DEVICE}1..."
DO_WITH_DEBUG cryptsetup --batch-mode -c aes-xts-plain64 -h sha256 -s 512 -y luksFormat ${DEVICE}1 \
--key-file <(echo -n "${PASSPHRASE}") > /dev/null 2>&1 \
|| die "Error formatting LUKS container"
DEBUG "Opening LUKS device and mapping under /dev/mapper/private..."
DO_WITH_DEBUG cryptsetup open ${DEVICE}1 private --key-file <(echo -n "${PASSPHRASE}") > /dev/null 2>&1 \
|| die "Error opening LUKS container"
DEBUG "Formatting LUKS container mapped under /dev/mapper/private as an ext4 partition..."
2023-10-18 17:15:48 +00:00
mke2fs -t ext4 -L private /dev/mapper/private >/dev/null 2>&1 || die "Error formatting LUKS container's ext4 filesystem"
2023-07-19 22:48:03 +00:00
DEBUG "Closing LUKS device /dev/mapper/private..."
cryptsetup close private > /dev/null 2>&1 || die "Error closing LUKS container"
DEBUG "Formatting second partition ${DEVICE}2 with exfat filesystem..."
2023-10-18 17:15:48 +00:00
mkfs.exfat -L public ${DEVICE}2 >/dev/null 2>&1 || die "Error formatting second partition with exfat filesystem"
2023-07-19 22:48:03 +00:00
echo "Done."
}
2024-10-22 21:42:47 +00:00
# Select LUKS container
select_luks_container() {
2024-02-01 19:30:31 +00:00
TRACE_FUNC
2022-03-23 19:47:33 +00:00
if [ -s /boot/kexec_key_devices.txt ]; then
2023-07-19 22:48:03 +00:00
DEBUG "Reusing known good LUKS container device from /boot/kexec_key_devices.txt"
2024-10-22 21:42:47 +00:00
LUKS=$(cut -d ' ' -f1 /boot/kexec_key_devices.txt)
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
DEBUG "LUKS container device: $(echo $LUKS)"
elif [ -z "$LUKS" ]; then
2024-10-22 21:42:47 +00:00
main_luks_selection
2022-03-23 19:47:33 +00:00
fi
fi
}
2024-10-22 21:42:47 +00:00
# Test LUKS current disk recovery key passphrase
test_luks_current_disk_recovery_key_passphrase() {
2024-02-01 19:30:31 +00:00
TRACE_FUNC
2023-10-18 17:15:48 +00:00
while :; do
2022-04-06 22:02:14 +00:00
select_luks_container || return 1
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
PRINTABLE_LUKS=$(echo $LUKS)
2022-03-23 19:47:33 +00:00
if [ -z "$luks_current_Disk_Recovery_Key_passphrase" ]; then
Uniformize vocabulary: LUKS TPM Disk Unlock Key & LUKS Disk Recovery Key
When playing with long fbwhiptail/whiptail messages, this commit played around the long string using fold.
'''
echo -e "This will replace the encrypted container content and its LUKS Disk Recovery Key.\n\nThe passphrase associated with this key will be asked from the user under the following conditions:\n 1-Every boot if no Disk Unlock Key was added to the TPM\n 2-If the TPM fails (hardware failure)\n 3-If the firmware has been tampered with/modified by the user\n\nThis process requires you to type the current LUKS Disk Recovery Key passphrase and will delete the LUKS TPM Disk Unlock Key slot, if set up, by setting a default boot LUKS key slot (1) if present.\n\nAt the next prompt, you may be asked to select which file corresponds to the LUKS device container.\n\nHit Enter to continue." | fold -w 70 -s
'''
Which gave the exact output of what will be inside of the fbwhiptail prompt, fixed to 70 chars width:
'''
This will replace the encrypted container content and its LUKS Disk
Recovery Key.
The passphrase associated with this key will be asked from the user
under the following conditions:
1-Every boot if no Disk Unlock Key was added to the TPM
2-If the TPM fails (hardware failure)
3-If the firmware has been tampered with/modified by the user
This process requires you to type the current LUKS Disk Recovery Key
passphrase and will delete the LUKS TPM Disk Unlock Key slot, if set
up, by setting a default boot LUKS key slot (1) if present.
At the next prompt, you may be asked to select which file corresponds
to the LUKS device container.
Hit Enter to continue.
'''
Therefore, for long prompts in the future, one can just deal with "\n 1-" alignments to be respected in prompts and have fold deal with cutting the length of strings properly.
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-01-19 17:32:04 +00:00
echo -e "\nEnter the current LUKS Disk Recovery Key passphrase (Configured at OS installation or by OEM):"
2022-03-23 19:47:33 +00:00
read -r luks_current_Disk_Recovery_Key_passphrase
2024-08-17 16:29:59 +00:00
echo -n "$luks_current_Disk_Recovery_Key_passphrase" > /tmp/secret/luks_current_Disk_Recovery_Key_passphrase
2022-03-23 19:47:33 +00:00
else
2024-08-17 16:29:59 +00:00
echo -n "$luks_current_Disk_Recovery_Key_passphrase" > /tmp/secret/luks_current_Disk_Recovery_Key_passphrase
2022-03-23 19:47:33 +00:00
fi
2023-10-18 17:15:48 +00:00
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
echo -e "\n$PRINTABLE_LUKS: Test unlocking of LUKS encrypted drive content with current LUKS Disk Recovery Key passphrase..."
for luks_container in $LUKS; do
DEBUG "$luks_container: Test unlocking of LUKS encrypted drive content with current LUKS Disk Recovery Key passphrase..."
2024-10-22 21:42:47 +00:00
if ! cryptsetup open --test-passphrase "$luks_container" --key-file /tmp/secret/luks_current_Disk_Recovery_Key_passphrase; then
2024-10-22 19:29:26 +00:00
whiptail_error --title "$luks_container: Wrong current LUKS Disk Recovery Key passphrase?" --msgbox \
2024-10-22 21:42:47 +00:00
"If you previously changed it and do not remember it, you will have to reinstall the OS from an external drive.\n\nTo do so, place the ISO file and its signature file on root of an external drive, and select Options-> Boot from USB \n\nHit Enter to retry." 0 80
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
detect_boot_device
mount -o remount,rw /boot
rm -f /boot/kexec_key_devices.txt
mount -o remount,ro /boot
luks_secrets_cleanup
unset LUKS
else
echo "$luks_container: unlocking LUKS container with current Disk Recovery Key passphrase successful"
export luks_current_Disk_Recovery_Key_passphrase
fi
done
if [ -n "$LUKS" ]; then
export LUKS
TRACE_FUNC
2024-08-17 16:01:42 +00:00
DEBUG "LUKS container(s) $PRINTABLE_LUKS exported to be reused"
2024-10-22 21:42:47 +00:00
break
2022-03-23 19:47:33 +00:00
fi
done
}
2024-10-22 21:42:47 +00:00
# Function to re-encrypt LUKS partitions
2023-10-18 17:15:48 +00:00
luks_reencrypt() {
2024-02-01 19:30:31 +00:00
TRACE_FUNC
2024-10-22 21:42:47 +00:00
test_luks_current_disk_recovery_key_passphrase || return 1
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
2024-08-17 16:01:42 +00:00
luks_containers=($LUKS)
TRACE_FUNC
DEBUG "luks_containers: ${luks_containers[@]}"
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
2024-08-17 16:01:42 +00:00
for luks_container in "${luks_containers[@]}"; do
2023-10-18 17:15:48 +00:00
if [ -z "$luks_current_Disk_Recovery_Key_passphrase" ]; then
2024-10-22 21:42:47 +00:00
if [ -f /tmp/secret/luks_current_Disk_Recovery_Key_passphrase ]; then
luks_current_Disk_Recovery_Key_passphrase=$(cat /tmp/secret/luks_current_Disk_Recovery_Key_passphrase)
else
msg=$(echo -e "This will replace the encrypted container content and its LUKS Disk Recovery Key.\n\nThe passphrase associated with this key will be asked from the user under the following conditions:\n 1-Every boot if no Disk Unlock Key was added to the TPM\n 2-If the TPM fails (hardware failure)\n 3-If the firmware has been tampered with/modified by the user\n\nThis process requires you to type the current LUKS Disk Recovery Key passphrase and will delete the LUKS TPM Disk Unlock Key slot, if set up, by setting a default boot LUKS key slot (1) if present.\n\nAt the next prompt, you may be asked to select which file corresponds to the LUKS device container.\n\nHit Enter to continue." | fold -w 70 -s)
whiptail --title 'Reencrypt LUKS encrypted container ?' --msgbox "$msg" 0 80
echo -e "\nEnter the current LUKS Disk Recovery Key passphrase:"
read -r -s luks_current_Disk_Recovery_Key_passphrase
echo -n "$luks_current_Disk_Recovery_Key_passphrase" >/tmp/secret/luks_current_Disk_Recovery_Key_passphrase
fi
2023-10-18 17:15:48 +00:00
else
2024-10-22 21:42:47 +00:00
echo -n "$luks_current_Disk_Recovery_Key_passphrase" >/tmp/secret/luks_current_Disk_Recovery_Key_passphrase
2023-10-18 17:15:48 +00:00
fi
2024-10-22 21:42:47 +00:00
2024-08-17 16:01:42 +00:00
DEBUG "$luks_container: Test unlocking of LUKS encrypted drive content with current LUKS Disk Recovery Key passphrase..."
2024-10-22 21:42:47 +00:00
if ! DO_WITH_DEBUG cryptsetup open --test-passphrase "$luks_container" --key-file /tmp/secret/luks_current_Disk_Recovery_Key_passphrase >/dev/null 2>&1; then
2024-10-22 19:29:26 +00:00
whiptail_error --title "$luks_container: Wrong current LUKS Disk Recovery Key passphrase?" --msgbox \
2024-10-22 21:42:47 +00:00
"If you previously changed it and do not remember it, you will have to reinstall the OS from an external drive.\n\nTo do so, place the ISO file and its signature file on root of an external drive, and select Options-> Boot from USB \n\nHit Enter to retry." 0 80
2024-08-17 16:01:42 +00:00
TRACE_FUNC
detect_boot_device
mount -o remount,rw /boot
rm -f /boot/kexec_key_devices.txt
mount -o remount,ro /boot
luks_secrets_cleanup
unset LUKS
continue
fi
2024-10-22 21:42:47 +00:00
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
DEBUG "Test opening ${luks_containers[@]} successful. Now testing key slots to determine which holds master key"
for luks_container in "${luks_containers[@]}"; do
DRK_KEYSLOT=-1
DEBUG "$luks_container: Test unlocking of LUKS encrypted drive content with current LUKS Disk Recovery Key passphrase..."
for i in $(seq 0 31); do
2024-10-22 21:42:47 +00:00
DEBUG "Testing key slot $i on $luks_container"
if DO_WITH_DEBUG cryptsetup open --test-passphrase $luks_container --key-slot $i --key-file /tmp/secret/luks_current_Disk_Recovery_Key_passphrase >/dev/null 2>&1; then
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
DRK_KEYSLOT=$i
DEBUG "$luks_container: Found key-slot $DRK_KEYSLOT that can be unlocked with the current passphrase. breaking loop"
break
2024-10-22 21:42:47 +00:00
else
DEBUG "Key slot $i on $luks_container cannot be unlocked with the current passphrase"
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
fi
done
if [ $DRK_KEYSLOT -eq -1 ]; then
2024-10-22 19:29:26 +00:00
whiptail_error --title "$luks_container: Wrong current LUKS Disk Recovery Key passphrase?" --msgbox \
2024-10-22 21:42:47 +00:00
"If you previously changed it and do not remember it, you will have to reinstall the OS from an external drive.\n\nTo do so, place the ISO file and its signature file on root of an external drive, and select Options-> Boot from USB \n\nHit Enter to retry." 0 80
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
TRACE_FUNC
detect_boot_device
mount -o remount,rw /boot
rm -f /boot/kexec_key_devices.txt
mount -o remount,ro /boot
luks_secrets_cleanup
unset LUKS
continue
2023-10-18 17:15:48 +00:00
fi
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
# Now reencrypt the LUKS container with the same key slot
# Warn and launch actual reencryption
echo -e "\nReencrypting $luks_container LUKS encrypted drive content with current Recovery Disk Key passphrase..."
warn "DO NOT POWER DOWN MACHINE, UNPLUG AC OR REMOVE BATTERY DURING REENCRYPTION PROCESS"
# --perf-no_read_workqueue and/or --perf-no_write_workqueue improve encryption/reencrypton performance on kernel 5.10.9+
# bypassing dm-crypt queues.
# Ref https://github.com/cloudflare/linux/issues/1#issuecomment-729695518
# --resilience=none disables the resilience feature of cryptsetup, which is enabled by default
# --force-offline-reencrypt forces the reencryption to be done offline (no read/write operations on the device)
# --disable-locks disables the lock feature of cryptsetup, which is enabled by default
2024-08-17 17:06:11 +00:00
if ! DO_WITH_DEBUG cryptsetup reencrypt \
2024-10-22 21:42:47 +00:00
--perf-no_read_workqueue --perf-no_write_workqueue \
--resilience=none --force-offline-reencrypt --disable-locks \
"$luks_container" --key-slot "$DRK_KEYSLOT" \
--key-file /tmp/secret/luks_current_Disk_Recovery_Key_passphrase; then
2024-10-22 19:29:26 +00:00
whiptail_error --title "$luks_container: Wrong current LUKS Disk Recovery Key passphrase?" --msgbox \
2024-10-22 21:42:47 +00:00
"If you previously changed it and do not remember it, you will have to reinstall the OS from an external drive.\n\nTo do so, place the ISO file and its signature file on root of an external drive, and select Options-> Boot from USB \n\nHit Enter to retry." 0 80
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
TRACE_FUNC
#remove "known good" selected LUKS container so that next pass asks again user to select LUKS container.
#maybe the container was not the right one
detect_boot_device
mount -o remount,rw /boot
rm -f /boot/kexec_key_devices.txt
mount -o remount,ro /boot
luks_secrets_cleanup
unset LUKS
else
#Reencryption was successful. Cleanup should be called only when done
#Exporting successfully used passphrase possibly reused by oem-factory-reset
export luks_current_Disk_Recovery_Key_passphrase
export LUKS
fi
done
2023-10-18 17:15:48 +00:00
done
2022-03-23 19:47:33 +00:00
}
2024-10-22 21:42:47 +00:00
# Function to change LUKS passphrase
luks_change_passphrase() {
TRACE_FUNC
test_luks_current_disk_recovery_key_passphrase || return 1
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
2024-08-17 16:01:42 +00:00
luks_containers=($LUKS)
TRACE_FUNC
DEBUG "luks_containers: ${luks_containers[@]}"
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
2024-10-22 21:42:47 +00:00
for luks_container in "${luks_containers[@]}"; do
if [ -z "$luks_current_Disk_Recovery_Key_passphrase" ] || [ -z "$luks_new_Disk_Recovery_Key_passphrase" ]; then
if [ -f /tmp/secret/luks_current_Disk_Recovery_Key_passphrase ]; then
luks_current_Disk_Recovery_Key_passphrase=$(cat /tmp/secret/luks_current_Disk_Recovery_Key_passphrase)
else
whiptail --title 'Changing LUKS Disk Recovery Key passphrase' --msgbox \
"Please enter the current LUKS Disk Recovery Key passphrase (slot 0).\nThen choose a strong passphrase of your own.\n\n**DICEWARE passphrase methodology is STRONGLY ADVISED.**\n\nHit Enter to continue" 0 80
echo -e "\nEnter your desired replacement for the actual LUKS Disk Recovery Key passphrase (At least 8 characters long):"
while [[ ${#luks_new_Disk_Recovery_Key_passphrase} -lt 8 ]]; do
read -r luks_new_Disk_Recovery_Key_passphrase
done
TRACE_FUNC
echo -e "\nEnter the current LUKS Disk Recovery Key passphrase (Configured at OS installation or by OEM):"
read -r luks_current_Disk_Recovery_Key_passphrase
fi
fi
echo -n "$luks_current_Disk_Recovery_Key_passphrase" >/tmp/secret/luks_current_Disk_Recovery_Key_passphrase
echo -n "$luks_new_Disk_Recovery_Key_passphrase" >/tmp/secret/luks_new_Disk_Recovery_Key_passphrase
DEBUG "$luks_container: Test unlocking of LUKS encrypted drive content with current LUKS Disk Recovery Key passphrase..."
if ! DO_WITH_DEBUG cryptsetup open --test-passphrase "$luks_container" --key-file /tmp/secret/luks_current_Disk_Recovery_Key_passphrase >/dev/null 2>&1; then
whiptail_error --title "$luks_container: Wrong current LUKS Disk Recovery Key passphrase?" --msgbox \
"If you previously changed it and do not remember it, you will have to reinstall the OS from an external drive.\n\nTo do so, place the ISO file and its signature file on root of an external drive, and select Options-> Boot from USB \n\nHit Enter to retry." 0 80
TRACE_FUNC
detect_boot_device
mount -o remount,rw /boot
rm -f /boot/kexec_key_devices.txt
mount -o remount,ro /boot
luks_secrets_cleanup
unset LUKS
continue
fi
echo -e "\nChanging $luks_container LUKS encrypted disk passphrase to the new LUKS Disk Recovery Key passphrase..."
if ! DO_WITH_DEBUG cryptsetup luksChangeKey "$luks_container" --key-file=/tmp/secret/luks_current_Disk_Recovery_Key_passphrase /tmp/secret/luks_new_Disk_Recovery_Key_passphrase; then
whiptail_error --title 'Failed to change LUKS passphrase' --msgbox \
"Failed to change the passphrase for $luks_container.\nPlease try again." 0 80
continue
fi
echo "Success changing passphrase for $luks_container."
done
# Export the new passphrase if all containers were processed successfully
luks_current_Disk_Recovery_Key_passphrase=$luks_new_Disk_Recovery_Key_passphrase
export luks_current_Disk_Recovery_Key_passphrase
export luks_new_Disk_Recovery_Key_passphrase
export LUKS
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
}
2024-10-22 21:42:47 +00:00
# Cleanup LUKS secrets
luks_secrets_cleanup() {
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
TRACE_FUNC
2022-03-23 19:47:33 +00:00
#Cleanup
2024-08-17 16:29:59 +00:00
shred -n 10 -z -u /tmp/secret/luks_new_Disk_Recovery_Key_passphrase 2>/dev/null || true
shred -n 10 -z -u /tmp/secret/luks_current_Disk_Recovery_Key_passphrase 2>/dev/null || true
cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
This is a critical feature for the Qubes OS 4.2 release for added data at rest protection
Cryptsetup 2.6.x internal changes:
- Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
- This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
- OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
- passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
- reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
cryptsetup 2.6.1 requires:
- lvm2 2.03.23, which is also included in this PR.
- requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
- requires util-linux 2.39
- patches for reproducible builds are included for above 3 packages.
luks-functions was updated to support the new cryptsetup2 version calls/changes
- reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
- from tests, this is best for performance and reliability in single-user mode
- LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
- Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
- If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
- Reencryption: requires to know which key slot to reencrypt.
- Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
- Passphrase change: no slot can be passed, but key slot of DRK rotates.
kexec-seal-key
- TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
- If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
- This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
- If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
- It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
- Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
- But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
- LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.
TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
- this could be subject to future work
Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
- x230-legacy, x230-legacy-flash, x230-hotp-legacy
- t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated
Unrelated:
- typos fixes found along the way
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-08-16 19:20:11 +00:00
#Unset variables (when in same boot)
2022-03-23 19:47:33 +00:00
unset luks_current_Disk_Recovery_Key_passphrase
unset luks_new_Disk_Recovery_Key_passphrase
2024-10-22 21:42:47 +00:00
unset LUKS
2022-03-23 19:47:33 +00:00
}