Post AaSEaLabgbh38F1OpU by starchturrets@mastodon.social
(DIR) More posts by starchturrets@mastodon.social
(DIR) Post #AaRra5bUGG1GY6U39M by mjg59@nondeterministic.computer
2023-10-05T04:14:37Z
0 likes, 0 repeats
Hurrah recording of my Linux Security Summit talk on per-process hardware-backed secret management is up: https://www.youtube.com/watch?v=cMwQD0jtUfU
(DIR) Post #AaRsVgN6EPKv5aDU0G by k@layer8.space
2023-10-05T04:24:58Z
0 likes, 0 repeats
@mjg59 time to binge!
(DIR) Post #AaRwha33xxxwlmm0xM by womble@infosec.exchange
2023-10-05T05:11:41Z
0 likes, 0 repeats
@mjg59 "I'm not going to be talking about the trucks" nooooooooooooo! Want trucks!
(DIR) Post #AaRyFFgUHmb9PZpkKu by akendo@chaos.social
2023-10-05T05:28:57Z
0 likes, 0 repeats
@mjg59 thanks for sharing.
(DIR) Post #AaSEaLabgbh38F1OpU by starchturrets@mastodon.social
2023-10-05T08:32:12Z
0 likes, 0 repeats
@mjg59 This was an awesome talk
(DIR) Post #AaSMIgATEjSPNLsn0y by pid_eins@mastodon.social
2023-10-05T09:58:24Z
0 likes, 0 repeats
@mjg59 hmm, so the hibernation thing, what i never grokked: isn't it entirely sufficient to just bind encryption to a secret locked to PCRs 0…7? that's a very simple policy that just says: if you want to unlock the hibernation image you have to boot the same system with all the same components, including the kernel?I mean, usually the PCR brittleness issue is what makes policies like that unrealistic in reality, but in a simple hibernation/thawing cycle that shouldn't be as much of a problem.
(DIR) Post #AaSXiupqQR6dtGwqjw by mjg59@nondeterministic.computer
2023-10-05T12:06:15Z
0 likes, 0 repeats
@pid_eins just using 0-7 means an attacker can write out a new image sealed against those values. We need something that proves the key was generated by the kernel, which means we need the creation data to include that.
(DIR) Post #AaSZ0fnhA8cSQaySQa by pid_eins@mastodon.social
2023-10-05T12:20:25Z
0 likes, 0 repeats
@mjg59 then attach a quote of the same pcrs to the hibernation image. And some nonce that binds image and quote together. That would mean the same boot path is necessary to generate and use a hibernation image.
(DIR) Post #AaSZTdagSRMZyKhQUi by michaelguntsche@fosstodon.org
2023-10-05T12:25:33Z
0 likes, 0 repeats
@mjg59 First time hearing you speak and it is scary how similar you sound to the voice I hear when I read your blog posts, please stop hacking my brain. :)
(DIR) Post #AaSbmW1uzaPtvvZFk8 by mjg59@nondeterministic.computer
2023-10-05T12:51:27Z
0 likes, 0 repeats
@pid_eins Hmm that might work. It does increase fragility so there'd need to be some constraints on userland, but as you say this is probably within the realm of "Don't do that".
(DIR) Post #AaScHOcGbel1uvIJ84 by michaelguntsche@fosstodon.org
2023-10-05T12:57:10Z
0 likes, 0 repeats
@mjg59 Tough crowd, did no one at least chuckle when you compared TPMs and trucks in the beginning?
(DIR) Post #AaSeMQ84bm47xwh9kG by mjg59@nondeterministic.computer
2023-10-05T13:20:29Z
0 likes, 0 repeats
@pid_eins Ah wait no that doesn't work because you boot the system as normal, write out an image that has appropriate creation data associated with it, and the kernel will happily resume that. You need a way to prove it was the kernel that was in control when the image was generated.
(DIR) Post #AaSheHzbtjlLo1wsQS by mjg59@nondeterministic.computer
2023-10-05T13:56:56Z
0 likes, 0 repeats
@pid_eins But hmm we could filter on outsideInfo during tpm2_create() instead, that would be less disruptive than blocking PCR 23. I'll play some more.
(DIR) Post #AaSiyLlhfZq5GIZc8m by pid_eins@mastodon.social
2023-10-05T14:12:00Z
0 likes, 0 repeats
@mjg59 here's another idea: generate the hibernation encryption key already during early boot (i.e. any time before you allow userspace to do the first TPM interaction), keep it in mem (i.e. kernel keyring or so) Bind the key to PCR 0..7 + PCR 9. Then measure some separator into PCR 9, to make the key unretrievable by userspace.Now you have the guarantee that userspace cannot retrieve the key, nor gen one anymore, but as long as the same boot path is booted the key will be avail to the kernel
(DIR) Post #AaSjwtN1rofAqrturo by mjg59@nondeterministic.computer
2023-10-05T14:23:25Z
0 likes, 0 repeats
@pid_eins How do we retrieve the key on resume? We can't get at the hibernation image until userland has started…
(DIR) Post #AaSkPobudwwCUFecUq by pid_eins@mastodon.social
2023-10-05T14:27:46Z
0 likes, 0 repeats
@mjg59 the rule is basically: kernel acquires hibernation key from TPM (and then destroys its accessibility via PCR 9 extension) when either: 1) userspace makes first attempt to access the TPM 2) userspace asks for a hibernation resumewhatever comes first. Hence, you basically let userspace start as much as it wants, you only shut the gates when you need the key or when userspace might try things.seems super simple to me.
(DIR) Post #AaSkjlYTiGC6noYqNk by mjg59@nondeterministic.computer
2023-10-05T14:32:00Z
0 likes, 0 repeats
@pid_eins Ah so the key is stored in nvram rather than the hibernation image?
(DIR) Post #AaSl0eBeMR2isCvtey by mjg59@nondeterministic.computer
2023-10-05T14:32:51Z
0 likes, 0 repeats
@pid_eins oh wait no I see now. Hmm. Maybe?
(DIR) Post #AaSlN4hGTiFHSmPluy by pid_eins@mastodon.social
2023-10-05T14:38:36Z
0 likes, 0 repeats
@mjg59 yeah, that's certainly the easiest option.I mean, if I understood your talk correctly your more recent ideas where built around "fake PCRs", i.e. "hybrid" nv indexes? those make NV changes too, hence you already were almost there, accepting using NV as storage..Linux could just pick some fixed nv index for this (and maybe a kernel param to change it). It's rather unlikely that people intend to "multi-boot" two hibernation images and expect things to just work.
(DIR) Post #AaSnQObB8jqzxsHNOS by mjg59@nondeterministic.computer
2023-10-05T15:01:53Z
0 likes, 0 repeats
@pid_eins I don't think the "extend on first userspace access" works because it breaks if the swap partition is on a TPM-backed LUKS setup
(DIR) Post #AaSnj8tnjdBqm7vekK by mjg59@nondeterministic.computer
2023-10-05T15:04:07Z
0 likes, 0 repeats
@pid_eins You can set the NV indexes up so they're actually only persistent in RAM rather than NV
(DIR) Post #AaSoDc7beNdy5xur1U by pid_eins@mastodon.social
2023-10-05T15:10:46Z
0 likes, 0 repeats
@mjg59 hmm, when i read that in the spec my understanding was that the nv index are allocated persistently always, but the contents might get reset on reboot.
(DIR) Post #AaSoYnsp7GZged6bPU by pid_eins@mastodon.social
2023-10-05T15:13:28Z
0 likes, 0 repeats
@mjg59 why? I mean, if you want to store the encryption key in the swap file then yeah this complicates things a bit. But as mentioned i think for this a fixed allocated nvindex is fine, because (my assumption at least says) that one active hibernation image per system is enough.
(DIR) Post #AaSotgRHzL13eFBOme by mjg59@nondeterministic.computer
2023-10-05T15:15:46Z
0 likes, 0 repeats
@pid_eins Sorry, yes, I'm fine statically allocating an NV index for this (and some other purposes)
(DIR) Post #Ab5Z54i3i8Jkss1Fbs by pid_eins@mastodon.social
2023-10-24T07:55:32Z
0 likes, 0 repeats
@mjg59 BTW, one addendum: instead of dealing with PCRs and stuff I think a much simpler and nicer approach is to initialize/read the NV index in the kernel, before allowing userspace to access it, and setting TPMA_NV_READLOCKED|TPMA_NV_WRITELOCKED on it. This means the key can be read/written exactly once until the system is reset. That makes things super simple: during early boot in the kernel read it/reinitialize it, and then you can be sure later stuff cannot fuck with it anymore.