!agkXCfUrgbadYlQXRj:kack.it

NixOS + TPMs

173 Members
44 Servers

Load older messages


SenderMessageTime
28 Jan 2023
@zhaofeng:zhaofeng.liZhaofeng LiHmm possibly, we should ask18:37:54
30 Jan 2023
@elvishjerricco:matrix.orgElvishJerricco

If the owner auth is empty, you have a worthless TPM

Can anyone explain what they mean by this?

21:12:41
31 Jan 2023
@baloo_:matrix.orgbalooHis concerns seems to be that someone would be able to nuke the keys.17:37:21
@baloo_:matrix.orgbaloo(you need to auth with the password for the lockout hierarchy to issue a tpm clear on the owner hierarchy)17:38:03
@baloo_:matrix.orgbaloo not entirely sure what the owner auth refers to? You'd need that to tpm2_nvundefine I guess? 17:39:22
@baloo_:matrix.orgbalooif you want a sandbox to play with that: https://gist.github.com/baloo/dcc7dc2405063a151ca527b79893170c17:43:16
1 Feb 2023
@grahamc:nixos.org@grahamc:nixos.orgwhat's a few nuked keys between friends14:59:43
2 Feb 2023
@elvishjerricco:matrix.orgElvishJerricco baloo: I'm still very confused about what that PR actually does, and the author was very dismissive and unhelpful when I asked. 15:30:46
@baloo_:matrix.orgbaloo Yeah that’s the curse of tpm I guess. Everyone has an opinion but everyone is always wrong. Except mjg59 16:30:52
@elvishjerricco:matrix.orgElvishJerricco baloo: Yea it was mentioned to me that that person might have a good explanation about TPM stuff somewhere but I didn't really find anything browsing their blog 19:16:20
@elvishjerricco:matrix.orgElvishJerriccoI mean I saw some stuff basically outlining measured boot and whatnot but that's not really what I'm not understanding19:16:54
@baloo_:matrix.orgbaloowho's that?19:16:57
@elvishjerricco:matrix.orgElvishJerriccomjg19:17:06
@raitobezarius:matrix.orgraitobezariusmjg5919:17:07
@baloo_:matrix.orgbalooha, yeah. well I do enjoy his fediverse's feed19:17:43
@baloo_:matrix.orgbaloo * ha, yeah. well I do enjoy his fediverse feed19:17:50
@matthewp:matrix.orgMatthew joined the room.21:44:55
3 Feb 2023
@flokli:matrix.orgflokliI tried backporting the systemd tpm fixes into the current stable release, but tripped an assertion: https://github.com/NixOS/nixpkgs/pull/21438316:54:57
4 Feb 2023
@elvishjerricco:matrix.orgElvishJerriccoThis ended up being incredibly helpful for my SRK questions and generally does a good job explaining all aspects of the TPM at a high level: https://google.github.io/tpm-js/03:19:46
20 Feb 2023
@mixis:bau-ha.usmixis set a profile picture.18:09:00
27 Feb 2023
@elvishjerricco:matrix.orgElvishJerricco
In reply to @elvishjerricco:matrix.org

https://github.com/systemd/systemd/pull/26185

This sounds like you won't be able to just systemd-cryptenroll with a TPM anymore without taking ownership of the TPM, is that right?

I figured this out finally. Basically the problem is that if the TPM has any authorization set on the key hierarchy, systemd simply can't use it. Because the easy way to use the TPM (the way systemd does it) is to always have the TPM recreate the same "primary key" (meaning the key at the root of the hierarchy, derived from the seed burned into the hardware). This key is what systemd asks the TPM to use to seal and unseal stuff (note that it remains internal to the TPM). But you're not allowed to create keys if the hierarchy requires authorization that you can't provide. So systemd just doesn't work if that authorization exists.

But anyone who takes ownership should almost certainly create an SRK (storage root key) and store it in the TPM. This is a primary key in the hierarchy that systemd wants to use. Since it's stored in the TPM, systemd can just ask the TPM to use it without having to create it.

So unauthorized users are able to use the keys stored on the TPM how they like, but they can't change the key hierarchy within the TPM or ask it for new keys. The PR changes systemd to work this way instead when the SRK exists in the TPM.

So it should have absolutely no effect except that now more people can use systemd's TPM support

20:58:08
@elvishjerricco:matrix.orgElvishJerricco (but only for systemd-cryptenroll; no support for systemd-creds yet) 21:00:11
@elvishjerricco:matrix.orgElvishJerricco * (but only for systemd-cryptenroll/cryptsetup; no support for systemd-creds yet) 21:00:30
@elvishjerricco:matrix.orgElvishJerriccoThe short version: The TPM just creates keys in memory by default, without storing them, and requiring authorization. Whenever someone sets the authorization, they should tell the TPM to create a special key called the SRK and store it so that others can use the TPM via the SRK without authorization. Systemd now supports this method.21:03:45
@elvishjerricco:matrix.orgElvishJerricco * The short version: The TPM just creates keys in internal memory by default, without storing them, and requiring authorization. Whenever someone sets the authorization, they should tell the TPM to create a special key called the SRK and store it so that others can use the TPM via the SRK without authorization. Systemd now supports this method.21:04:25
@elvishjerricco:matrix.orgElvishJerricco * The short version: The TPM just creates internally reproducible keys in internal memory by default, without storing them, and requiring authorization. Whenever someone sets the authorization, they should tell the TPM to create a special key called the SRK and store it so that others can use the TPM via the SRK without authorization. Systemd now supports this method.21:04:51
@baloo_:matrix.orgbaloobut if noone took ownership there wouldn't be a need to require authorization in the first place?21:12:58
@baloo_:matrix.orgbalooor am I missing something21:13:08
@elvishjerricco:matrix.orgElvishJerricco baloo: That's correct. And that's why it works currently; systemd expects no one to have taken ownership 21:15:12
@baloo_:matrix.orgbalooalright, makes sense21:15:34

Show newer messages


Back to Room ListRoom Version: 6