Cryptsetup сообщает “Недостаточно места в области заголовка json для нового ключевого слота”

Я использую Almalinux, если это важно.

Мы используем LUKS2 на локальном диске с LVM сверху — /dev/sda1 и /dev/sda2 не зашифрованы, но /dev/sda3 зашифрован и используется для ОС.

Мы также используем clevis/tang для автоматического расшифрования (и это работает прекрасно).

Когда мы создаем через kickstart, мы устанавливаем временный пароль при шифровании и сборке, а затем, когда завершаем первоначальную сборку, мы используем ansible для установки качественных паролей в соответствии с нашей практикой управления ключами/безопасностью.

Это подразумевает сценарий, который делает эквивалентное:

cryptsetup luksOpen -S 0 --test-passphrase /dev/sda3 && cryptsetup luksChangeKey -S0 --force-password --batch-mode 

(И, конечно, ‘умолчательный’ пароль сборки проверяется и заменяется одним из нашей системы управления ключами).

Недавно это начало не работать, и я немного озадачен тем, что может пойти не так.

Это определенно работает при нашей первоначальной ‘сборке’, которая использует несколько устаревший образ сборки, но затем мы dnf update до текущей ревизии, и теперь мы не можем выполнить luksChangeKey или luksAddkey больше.

# Добавление нового слота ключа 2 по паролю, ключ тома предоставлен паролем (-1).
# Выбран слот ключа 2.
# Приоритет слота ключа 0 1 != 2 (требуется), пропущено.
# Приоритет слота ключа 1 1 != 2 (требуется), пропущено.
# Пытаемся открыть слот ключа LUKS2 0.
# Запускаем порождение ключа для слота.
# Чтение области слота ключа [0x8000].
# Получение блокировки на чтение для устройства /dev/sda3.
# Открытие файла блокировки ресурса /run/cryptsetup/L_8:3
# Проверка дескриптора блокировки для /dev/sda3.
# Устройство /dev/sda3 БЛОКИРОВКА чтения получена.
# Повторное использование открытого rо fd на устройстве /dev/sda3
# Устройство /dev/sda3 БЛОКИРОВКА чтения освобождена.
# Проверка ключа из слота ключа 0, дайджест 0.
# Слот ключа 2 назначен дайджесту 0.
# Пытаемся выделить слот ключа LUKS2 2.
# Найдена область 548864 -> 806912
# Запуск benchmark argon2id().
# PBKDF benchmark: затраты памяти = 65536, итерации = 4, потоки = 4 (заняло 72 мс)
# PBKDF benchmark: затраты памяти = 227555, итерации = 4, потоки = 4 (заняло 264 мс)
# PBKDF benchmark: затраты памяти = 1048576, итерации = 6, потоки = 4 (заняло 1982 мс)
# Бенчмарк возвращает argon2id() 6 итераций, 1048576 памяти, 4 потока (для ключа 512 бита).
# JSON не помещается в отведенное пространство.
# Недостаточно места в области заголовка json для нового слота ключа.
# Откат в памяти метаданных LUKS2 json.
# Освобождение контекста криптографического устройства /dev/sda3.
# Освобождение бекенда диспетчера устройств.
# Закрытие fd только для чтения для /dev/sda3.
Команда завершилась неудачей с кодом -1 (неверные или отсутствующие параметры).

Я задаюсь вопросом, может ли кто-то помочь мне понять, что здесь не так, и что мне нужно сделать, чтобы исправить это.

Есть ли опция ‘начального размера заголовка’, которую я могу установить в наших сборках? Или параметр для cryptsetup? Или я “просто” сталкиваюсь с ошибкой? (Но я не уверен, что что-то столь широко используемое, как cryptsetup, будет иметь ошибку типа ‘никто не может изменить свои пароли’)

Вот как выглядит заголовок LUKS на примере хоста.

Информация о заголовке LUKS
Версия:           2
Эпоха:             5
Область метаданных:     16384 [байт]
Область слотов ключей:     16744448 [байт]
UUID:              
Метка:             (нет метки)
Подсистема:         (нет подсистемы)
Флаги:           (нет флагов)

Сегменты данных:
  0: crypt
    смещение: 16777216 [байт]
    длина: (все устройство)
    шифр: aes-xts-plain64
    сектор: 512 [байт]

Слоты ключей:
  0: luks2
    Ключ:        512 бит
    Приоритет:   нормально
    Шифр:     aes-xts-plain64
    Ключ шифра: 512 бит
    PBKDF:      argon2id
    Временные затраты:  9
    Память:     1048576
    Потоки:    4
    Соль:       
    AF полосы: 4000
    AF хеш:    sha256
    Смещение области:32768 [байт]
    Длина области:258048 [байт]
    ID дайджеста:  0
  1: luks2
    Ключ:        512 бит
    Приоритет:   нормально
    Шифр:     aes-xts-plain64
    Ключ шифра: 512 бит
    PBKDF:      pbkdf2
    Хеш:       sha256
    Итерации: 1000
    Соль:       
    AF полосы: 4000
    AF хеш:    sha256
    Смещение области:290816 [байт]
    Длина области:258048 [байт]
    ID дайджеста:  0
Токены:
  0: clevis
    Слот ключа:    1
Дайджесты:
  0: pbkdf2
    Хеш:       sha256
    Итерации: 105025
    Соль:       
    Дайджест:    

Не упускаю ли я чего-то серьезного? Как я уже сказал, я уверен, что это работает, если я не ‘обновляю’ систему до более нового ядра, и поэтому мое текущее решение — это собрать ее, вручную изменить ключ и затем продолжать обновлять, но это кажется … неоптимальным.

версии cryptsetup 2.6.0 и 2.7.2

head -c 1M /dev/sda3 | strings -n 128 

переформатировано:

{
  "keyslots": {
    "0": {
      "type": "luks2",
      "key_size": 64,
      "af": {
        "type": "luks1",
        "stripes": 4000,
        "hash": "sha256"
      },
      "area": {
        "type": "raw",
        "offset": "32768",
        "size": "258048",
        "encryption": "aes-xts-plain64",
        "key_size": 64
      },
      "kdf": {
        "type": "argon2id",
        "time": 7,
        "memory": 1048576,
        "cpus": 4,
        "salt": "(удалено)"
      }
    },
    "1": {
      "type": "luks2",
      "key_size": 64,
      "af": {
        "type": "luks1",
        "stripes": 4000,
        "hash": "sha256"
      },
      "area": {
        "type": "raw",
        "offset": "290816",
        "size": "258048",
        "encryption": "aes-xts-plain64",
        "key_size": 64
      },
      "kdf": {
        "type": "pbkdf2",
        "hash": "sha256",
        "iterations": 1000,
        "salt": "(удалено)"
      }
    }
  },
  "tokens": {
    "0": {
      "type": "clevis",
      "keyslots": [
        "1"
      ],
      "jwe": {
        "ciphertext": "(удалено)",
        "encrypted_key": "",
        "iv": "(удалено)",
        "protected": "",
        "tag": "(удалено)"
      }
    }
  },
  "segments": {
    "0": {
      "type": "crypt",
      "offset": "16777216",
      "size": "dynamic",
      "iv_tweak": "0",
      "encryption": "aes-xts-plain64",
      "sector_size": 512
    }
  },
  "digests": {
    "0": {
      "type": "pbkdf2",
      "keyslots": [
        "0",
        "1"
      ],
      "segments": [
        "0"
      ],
      "hash": "sha256",
      "iterations": 88086,
      "salt": "(удалено)",
      "digest": "(удалено)"
    }
  },
  "config": {
    "json_size": "12288",
    "keyslots_size": "16744448"
  }
}

Редактировать2: Ситуация усложняется: luksHeaderBackup, а затем восстановление завершается неудачей.

Но убивая ‘слот 0’ и добавляя ключ, это все еще работает. (Предполагая, что ‘слот 1’ вы можете извлечь, но в моих случаях clevis-luks-pass работает достаточно хорошо)