NixOS + TPMs | 173 Members | |
| 44 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Jan 2023 | ||
| Hmm possibly, we should ask | 18:37:54 | |
| 30 Jan 2023 | ||
Can anyone explain what they mean by this? | 21:12:41 | |
| 31 Jan 2023 | ||
| His concerns seems to be that someone would be able to nuke the keys. | 17:37:21 | |
| (you need to auth with the password for the lockout hierarchy to issue a tpm clear on the owner hierarchy) | 17:38:03 | |
not entirely sure what the owner auth refers to? You'd need that to tpm2_nvundefine I guess? | 17:39:22 | |
| if you want a sandbox to play with that: https://gist.github.com/baloo/dcc7dc2405063a151ca527b79893170c | 17:43:16 | |
| 1 Feb 2023 | ||
| what's a few nuked keys between friends | 14:59:43 | |
| 2 Feb 2023 | ||
| 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 | |
| Yeah that’s the curse of tpm I guess. Everyone has an opinion but everyone is always wrong. Except mjg59 | 16:30:52 | |
| 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 | |
| I mean I saw some stuff basically outlining measured boot and whatnot but that's not really what I'm not understanding | 19:16:54 | |
| who's that? | 19:16:57 | |
| mjg | 19:17:06 | |
| mjg59 | 19:17:07 | |
| ha, yeah. well I do enjoy his fediverse's feed | 19:17:43 | |
| * ha, yeah. well I do enjoy his fediverse feed | 19:17:50 | |
| 21:44:55 | ||
| 3 Feb 2023 | ||
| I tried backporting the systemd tpm fixes into the current stable release, but tripped an assertion: https://github.com/NixOS/nixpkgs/pull/214383 | 16:54:57 | |
| 4 Feb 2023 | ||
| This 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 | ||
| 18:09:00 | ||
| 27 Feb 2023 | ||
In reply to @elvishjerricco:matrix.org 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 | |
(but only for systemd-cryptenroll; no support for systemd-creds yet) | 21:00:11 | |
* (but only for systemd-cryptenroll/cryptsetup; no support for systemd-creds yet) | 21:00:30 | |
| The 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 | |
| * 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 | |
| * 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 | |
| but if noone took ownership there wouldn't be a need to require authorization in the first place? | 21:12:58 | |
| or am I missing something | 21:13:08 | |
| baloo: That's correct. And that's why it works currently; systemd expects no one to have taken ownership | 21:15:12 | |
| alright, makes sense | 21:15:34 | |