主页 / user-65333

Sobrique's questions

Martin Hope
Sobrique
Asked: 2024-12-04 20:37:19 +0800 CST
  • 7

我正在使用 Almalinux，以防这与此相关。

我们在本地磁盘上使用 LUKS2，并在其顶部使用 LVM - 因此 /dev/sda1 和 2 未加密，但 /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。

# Adding new keyslot 2 by passphrase, volume key provided by passphrase (-1).
# Selected keyslot 2.
# Keyslot 0 priority 1 != 2 (required), skipped.
# Keyslot 1 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device /dev/sda3.
# Opening lock resource file /run/cryptsetup/L_8:3
# Verifying lock handle for /dev/sda3.
# Device /dev/sda3 READ lock taken.
# Reusing open ro fd on device /dev/sda3
# Device /dev/sda3 READ lock released.
# Verifying key from keyslot 0, digest 0.
# Keyslot 2 assigned to digest 0.
# Trying to allocate LUKS2 keyslot 2.
# Found area 548864 -> 806912
# Running argon2id() benchmark.
# PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 72 ms)
# PBKDF benchmark: memory cost = 227555, iterations = 4, threads = 4 (took 264 ms)
# PBKDF benchmark: memory cost = 1048576, iterations = 6, threads = 4 (took 1982 ms)
# Benchmark returns argon2id() 6 iterations, 1048576 memory, 4 threads (for 512-bits key).
# JSON does not fit in the designated area.
# Not enough space in header json area for new keyslot.
# Rolling back in-memory LUKS2 json metadata.
# Releasing crypt device /dev/sda3 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/sda3.
Command failed with code -1 (wrong or missing parameters).

我想知道是否有人能够帮助我了解这里出了什么问题，以及我需要做什么来解决它。

是否有一个“初始标头大小”选项可以指定在我们的构建中？或者 cryptsetup 的参数？或者我“只是”发现了一个错误？（但我不相信像这种广泛使用的东西cryptsetup会有“没有人可以更改密码”之类的错误）

这是 LUKs 标头在示例主机上的样子。

LUKS header information
Version:           2
Epoch:             5
Metadata area:     16384 [bytes]
Keyslots area:     16744448 [bytes]
UUID:              
Label:             (no label)
Subsystem:         (no subsystem)
Flags:           (no flags)

Data segments:
  0: crypt
    offset: 16777216 [bytes]
    length: (whole device)
    cipher: aes-xts-plain64
    sector: 512 [bytes]

Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2id
    Time cost:  9
    Memory:     1048576
    Threads:    4
    Salt:       
    AF stripes: 4000
    AF hash:    sha256
    Area offset:32768 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
  1: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      pbkdf2
    Hash:       sha256
    Iterations: 1000
    Salt:       
    AF stripes: 4000
    AF hash:    sha256
    Area offset:290816 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
Tokens:
  0: clevis
    Keyslot:    1
Digests:
  0: pbkdf2
    Hash:       sha256
    Iterations: 105025
    Salt:       
    Digest:

我是不是错过了什么深刻的东西？正如所说，如果我不将盒子“升级”到较新的内核，我确信这可以工作，所以我当前的解决方法是构建它，手动重新键入它，然后继续更新它，但这似乎……不是最理想的。

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": "(removed)"
      }
    },
    "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": "(removed)"
      }
    }
  },
  "tokens": {
    "0": {
      "type": "clevis",
      "keyslots": [
        "1"
      ],
      "jwe": {
        "ciphertext": "(removed)",
        "encrypted_key": "",
        "iv": "(removed)",
        "protected": "",
        "tag": "(removed)"
      }
    }
  },
  "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": "(removed)",
      "digest": "(removed)"
    }
  },
  "config": {
    "json_size": "12288",
    "keyslots_size": "16744448"
  }
}

编辑2：情节变得更加复杂：luksHeaderBackup 然后恢复失败。

但删除“插槽 0”并添加密钥仍然有效。（假设您可以提取“插槽 1”，但在我的案例中clevis-luks-pass效果已经足够好了）

luks