summaryrefslogtreecommitdiff
path: root/src/shared/tpm2-util.h
Commit message (Collapse)AuthorAgeFilesLines
* tpm2: add tpm2_is_encryption_session()Dan Streetman2023-05-051-0/+1
|
* systemd-cryptenroll: add string aliases for tpm2 PCRsOMOJOLA JOSHUA DAMILOLA2023-04-131-0/+27
| | | | Fixes #26697. RFE.
* tpm2: add support for a trusted SRKWilliam Roberts2023-04-031-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prevent attackers from spoofing the tpmKey portion of the AuthSession by adding a trusted key to the LUKS header metadata. Also, use a persistent object rather than a transient object. This provides the following benifits: 1. No way to MITM the tpmKey portion of the session, see [1] for details. 2. Strengthens the encrypted sessions, note that the bindKey could be dropped now. 3. Speed, once it's created we just use it. 4. Owner Auth is needed to call create primary, so using the SRK creates a scratch space for normal users. This is a "first to set" model, in where the first person to set the key in the LUKS header wins. Thus, setup should be done in a known good state. If an SRK, which is a primary key at a special persistent address, is found, it will use whatever is there. If not, it creates an SRK. The SRK follows the convetions used through the tpm2-software organization code on GitHub [2], however, a split has occured between Windows and Linux with respect to SRK templates. The Linux SRK is generated with the unique field size set to 0, in Windows, it properly sets the size to key size in bytes and the unique data to all 0's of that size. Note the proper templates for SRKs is covered in spec [3]. However, the most important thing, is that both SRKs are passwordless, and thus they should be interchangable. If Windows is the first to make the SRK, systemd will gladly accept it and vice-versa. 1. Without the bindKey being utilized, an attacker was able to intercept this and fake a key, thus being able to decrypt and encrypt traffic as needed. Introduction of the bindKey strengthened this, but allows for the attacker to brute force AES128CFB using pin guesses. Introduction of the salt increases the difficulty of this attack as well as DA attacks on the TPM objects itself. 2. https://github.com/tpm2-software 3. https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf Fixes: #20668 Fixes: #22637 Signed-off-by: William Roberts <william.c.roberts@intel.com>
* tpm2: add/rename functions to manage pcr selectionsDan Streetman2023-03-091-6/+25
| | | | | | This renames some functions to match other to/from_string() naming, and allows better management of TPML_PCR_SELECTION and TPMS_PCR_SELECTION structs.
* tpm2: add TPM2_PCR_VALID()Dan Streetman2023-03-091-6/+12
|
* tpm2: add Tpm2Handle with automatic cleanupDan Streetman2023-02-011-1/+13
| | | | | This allows using _cleanup_ with the handles, which then allows removing the use of goto in all functions that use the handles.
* tpm2: use Tpm2Context* instead of ESYS_CONTEXT*Dan Streetman2023-02-011-4/+4
| | | | | This is needed for later patches that use Tpm2Handle, which requires access to the Tpm2Context.
* tpm2: use ref counter for Tpm2ContextDan Streetman2023-02-011-3/+8
| | | | | | | This will be used by Tpm2Handle instances, which is added in later patches. The refcounting allows the context to be retained until all Tpm2Handles have been cleaned up, and the initial ref is released, before cleaning the context.
* tpm2: rename struct tpm2_context to Tpm2ContextDan Streetman2023-02-011-7/+7
| | | | This aligns with systemd coding guidelines for struct naming
* tpm2: rename tpm2 alg id<->string functionsDan Streetman2023-02-011-4/+4
| | | | | | The 'pcr_bank' functions operate on hash algs, and are not specific to the PCR banks, while the 'primary_alg' functions operate on asymmetric algs, and are not specific to primary keys.
* tpm2: add salt to pinWilliam Roberts2023-01-181-2/+9
| | | | | | | | | | Add a salt to the pin and store it in the TPM2 LUKS header for future this. This adds entropy to user supplied pins and helps brute forcing the passphrase on the key residing in the TPM or brute forcing bind key encrypted sessions with low entropy passphrases. Signed-off-by: malikabhi05 <abhishek.malik@intel.com> Signed-off-by: William Roberts <william.c.roberts@intel.com>
* tpm2-util: optionally do HMAC in tpm2_extend_bytes() in case we process ↵Lennart Poettering2023-01-171-1/+1
| | | | | | | | | | | | | | sensitive data When measuring data into a PCR we are supposed to hash the data on the CPU and then pass the hash value over the wire to the TPM2. That's all good as long as the data we intend to measure is not sensitive. Let's be extra careful though if we want to measure sensitive data, for example the root file system volume key. Instead of just hashing that and passing it over the wire to the TPM2, let's do a HMAC signature instead. It's also a hash operation, but should protect our secret reasonably well and not leak direct information about it to wiretappers.
* tpm2-util: split out code that extends a PCR from pcrphaseLennart Poettering2023-01-171-0/+2
| | | | This way we can reuse it later outside of pcrphase
* tpm2-util: split out code that derives "good" TPM2 banks into an strv from ↵Lennart Poettering2023-01-171-0/+1
| | | | | | pcrphase and generalize it in tpm2-util.c That way we can reuse it later from different places.
* condition: Check that subsystem is enabled in ConditionSecurity=tpm2Daan De Meyer2022-11-011-5/+6
| | | | | | | | | Instead of succeeding when either the firmware reports a TPM device or we find a TPM device, let's check that the firmware reports a TPM device and the TPM subsystem is enabled in the kernel. To check whether the subsystem enabled, we check if the relevant subdirectory in /sys exists at all.
* tpm2-util: fix parameter nameLennart Poettering2022-10-171-1/+1
|
* tpm2-util: add helper for determining enabled/used PCR banksLennart Poettering2022-09-221-0/+2
|
* tpm2-util: pick up Esys_PCR_Extend() symbol tooLennart Poettering2022-09-221-0/+1
|
* cryptsetup: hook up TPM2 token code with policies based on PCR signatures, tooLennart Poettering2022-09-081-0/+1
|
* tpm2-util: add helper for formatting PCR masks as stringLennart Poettering2022-09-081-0/+2
|
* tpm2-util: add common parser for the LUKS2 TPM2 JSON structureLennart Poettering2022-09-081-0/+1
| | | | | | | | | | This splits out the JSON parser used by the systemd-cryptsetup code. This is preparation for later work to reuse it in the tpm2 cryptsetup token module, which currently uses a separate but very similar parser for the same data. No change in behaviour.
* cryptenroll: hook up new TPM2 signed policies with cryptenrollLennart Poettering2022-09-081-1/+1
|
* creds-util: hook up new signed PCR policiesLennart Poettering2022-09-081-0/+3
|
* tpm2-util: extend TPM2 policies to optionally check PCR values against ↵Lennart Poettering2022-09-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | signed values Traditionally, TPM2 PCR policies are bound against literal PCR values, which makes them hard to work with when updating software that is measured into PCRs: each update will change the PCR values, and thus break TPM2 policies of existing objects. Let's improve the situation: let's allow signed PCR policies. Secrets and other TPM2 objects can be associated with a public key that signs a PCR policy. Thus, if the signed policy and the public key is presented, access to the TPM2 object can be granted. This allows a less brittle handling of updates: for example, whenever a kernel image is updated a new signed PCR policy can be shipped along with it, signed by a private key owned by the kernel vendor (ideally: same private key that is used to sign the kernel image itself). TPM2 objects can then be bound to the associated public key, thus allowing objects that can only be unlocked by kernels of the same vendor. This makes it very easy to update kernels without affecting locked secrets. This does not hook up any of the consuming code (just passes NULL/0 everywhere). This is for later commits.
* tpm2-util: allow external code to create tpm2 contextsLennart Poettering2022-09-081-0/+20
|
* tpm2-util: pick up 4 more symbols of tpm2-tssLennart Poettering2022-09-081-0/+4
|
* Merge pull request #24368 from poettering/tpm2-json-pcr-array-reworkLennart Poettering2022-08-191-0/+3
|\ | | | | tpm2: add helpers for building/parsing JSON arrays of PCR indexes
| * tpm2-util: also add helper for parsing PCR arraysLennart Poettering2022-08-191-0/+2
| |
| * tpm2-util: split out helpers which format a PCR mask as a JSON arrayLennart Poettering2022-08-191-0/+1
| | | | | | | | | | This makes the code easier to read, and is something we can reuse later on.
* | tpm2-util: introduce tpm2_parse_pcr_argument() helperLennart Poettering2022-08-191-0/+2
| | | | | | | | | | | | Add a new tpm2_parse_pcr_argument() helper that unifies how we merge PCR masks in a single function, we can use all over the place. Previously we had basically the same code for this at 4 places.
* | tpm2-util: expose more hash algorithmsLennart Poettering2022-08-191-2/+10
| | | | | | | | swtpm supports them, hence maybe support them in our codebase, too
* | tpm2-util: add TPM2_PCR_MASK_VALID() helperLennart Poettering2022-08-191-1/+5
|/
* creds-tool: add new "has-tpm2" verbLennart Poettering2022-04-201-0/+2
| | | | | | | | | | | | | | | Sometimes it's useful from shell scripts to check if we have a working TPM2 chip around. For example, when putting together encrypted credentials for the initrd (after all: it might be wise to place the root pw in a credential for the initrd to consume, but do so only if we can lock it to the TPM2, and not otherwise, so that we risk nothing). Hence, let's add a new "systemd-creds has-tpm2" verb: it returns zero if we have a working TPM2 (which means: supported by kernel + firmware + us), or non-zero otherwise. Also show which parts are available. Use-case: in future the 'kernel-install' script should use this when deciding whether to augment kernels with security sensitive credentials.
* tpm2-util: add helper that checks for the various facets of TPM2 supportLennart Poettering2022-04-201-0/+10
| | | | | | | | | | | So far we were a bit sloppy regarding checks for TPM2 support. Let's make things more precise and introduce a single helper that checks for three axis of TPM2 support: whether we have a loaded kernel driver, whether the firmware used it, and whether we ourselves are compiled for it. This only adds the helper. Follow-up patches will use it at various places.
* tpm2: enable parameter encryptionGrigori Goronzy2022-03-161-0/+1
| | | | | | | | | | | | | Use a salted, unbound HMAC session with the primary key used as tpmKey, which mean that the random salt will be encrypted with the primary key while in transit. Decrypt/encrypt flags are set on the new session with AES in CFB mode. There is no fallback to XOR mode. This provides confidentiality and replay protection, both when sealing and unsealing. There is no protection against man in the middle attacks since we have no way to authenticate the TPM at the moment. The exception is unsealing with PIN, as an attacker will be unable to generate the proper HMAC digest.
* cryptenroll: add support for TPM2 pinGrigori Goronzy2022-03-151-1/+5
| | | | | | | | Add support for PIN enrollment with TPM2. A new "tpm2-pin" field is introduced into metadata to signal that the policy needs to include a PIN. v2: fix tpm2_make_luks2_json in sd-repart
* tpm2: support policies with PINGrigori Goronzy2022-03-151-2/+6
| | | | | | | | | | | Modify TPM2 authentication policy to optionally include an authValue, i.e. a password/PIN. We use the "PIN" terminology since it's used by other systems such as Windows, even though the PIN is not necessarily numeric. The pin is hashed via SHA256 to allow for arbitrary length PINs. v2: fix tpm2_seal in sd-repart v3: applied review feedback
* tpm2: check if PCR values make sense before using themLennart Poettering2021-09-131-0/+1
| | | | Fixes: #20684
* tpm2: support RSA primary keys as fallback if TPM2 devices don't support ECCLennart Poettering2021-09-131-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | Previously, we hardcoded use of ECC as primary keys, since they are much faster (i.e. saving multiple seconds) to do TPM2 operations with. Alas, not all TPM2 chips appear to support ECC. Bummer. Let's hence add a fallback logic: if we can't create an ECC primary key, use an RSA key, and store that fact away. AFIU the security guarantees should be roughly the same, it's just that RSA primary keys is so much slower to work with than ECC. The primary key algorithm is used is stored in the JSON header of LUKS disks, in a new field. If the field is absent we assume to use ECC, to provide full compatibility with old systemd versions. The primary key algorithm is stored in a new field in the credentials file format (in fact, a previously unused zero space is used), too. Hopefully, this should ensure that TPM2 support will "just work" on more systems. Fixes: #20361
* tpm2-util: auto-detect supported PCR banksLennart Poettering2021-07-301-3/+8
| | | | | | | | | | | | | | | | | | | Previously, we'd encode PCR policies strictly with the SHA256 PCR bank set. However, as it appears not all hw implement those. Sad. Let's add some minimal logic to auto-detect supported PCR banks: if SHA256 is supported, use that. But if not, automatically fall back to SHA1. This then changes both the LUKS code, and the credentials code to serialize the selected bank, along with the rest of the data in order to make this robust. This extends the LUK2 JSON metadata in a compatible way. The credentials encryption format is modified in an incompatible way however, but given that this is not part of any official release should be OK. Fixes: #20134
* Add support for systemd-tpm2 libcryptsetup plugin.Ondrej Kozina2021-07-261-0/+5
| | | | | | | | | | | Add support for systemd-tpm2 based LUKS2 device activation via libcryptsetup plugin. This make the feature (tpm2 sealed LUKS2 keyslot passphrase) usable from both systemd utilities and cryptsetup cli. The feature is configured via -Dlibcryptsetup-plugins combo with default value set to 'auto'. It get's enabled automatically when cryptsetup 2.4.0 or later is installed in build system.
* cryptenroll: add support for TPM2 enrollingLennart Poettering2020-12-171-0/+51
View Lorry Controller Status