fuldeka
f3fe668cdf
The current TPM2 PIN mode is flawed as a compromised TPM directly exposes the sealed secret which is the LUKS volume key itself (#27502 and #37386). Goal: add Argon2id-based PIN hardening to TPM2 enrollment, making the TPM a second factor rather than a single point of failure: 1. Password + salt -> Argon2id -> 512-bit key split into Key1 + Key2 2. Key2 (base64-encoded) is used as the PIN to seal a random secret in the TPM 3. Key1 + unsealed secret -> HKDF-SHA256 -> final LUKS volume key This implementation ensures that if the TPM is compromised, an attacker still needs the password to derive Key1 and combine it with the unsealed secret. The --tpm2-with-pin= option now accepts three values: - false (no PIN used) - true (PIN hardened with Argon2id - default) - "direct" (legacy PIN without Argon2id for backward compatibility) Argon2id parameters are customizable via: --tpm2-argon2id-memory= --tpm2-argon2id-iterations= --tpm2-argon2id-parallelism= --tpm2-argon2id-iter-time= These default to a function of available CPUs and physical memory, with a benchmark that scales iterations to the target time (default: 2s) and falls back to ARGON2ID_PARAMETERS_DEFAULT (64 MiB, 8 iter, 4 lanes) when auto detection fails. Also if the runtime OpenSSL lacks Argon2id support (< 3.2), the feature silently falls back to direct PIN mode with a warning. Added includes: - src/cryptenroll/cryptenroll.c: cpu-set-util.h, limits-util.h, time-util.h for Argon2id benchmark auto-tuning (cpus_online, physical_memory_scale, now/usec_t) - src/cryptenroll/cryptenroll-tpm2.c: crypto-util.h for Argon2IdParameters struct in load_volume_key_tpm2() - src/shared/tpm2-util.h: crypto-util.h for Argon2IdParameters in tpm2_make_luks2_json() API - src/shared/tpm2-util.c: limits-util.h, tpm2-util.h for physical_memory() validation of Argon2id memory cost and function prototypes - src/cryptsetup/cryptsetup-tokens/luks2-tpm2.c: crypto-util.h for kdf_argon2id_derive()/kdf_hkdf_sha256() on the token unlock path
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release