On Mon, 2023-01-23 at 11:48 -0600, William Roberts wrote: > On Fri, Jan 20, 2023 at 9:29 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx> > wrote: > > > > On Sat, Jan 14, 2023 at 09:55:37AM -0500, James Bottomley wrote: > > > On Tue, 2023-01-03 at 13:10 -0800, Matthew Garrett wrote: > > > > On Tue, Jan 3, 2023 at 1:05 PM William Roberts > > > > <bill.c.roberts@xxxxxxxxx> wrote: > > > > > > > > > What's the use case of using the creation data and ticket in > > > > > this context? Who gets the creationData and the ticket? > > > > > Could a user supplied outsideInfo work? IIRC I saw some > > > > > patches flying around where the sessions will get encrypted > > > > > and presumably correctly as well. This would allow the > > > > > transfer of that outsideInfo, like the NV Index PCR value to > > > > > be included and integrity protected by the session HMAC. > > > > > > > > The goal is to ensure that the key was generated by the kernel. > > > > In the absence of the creation data, an attacker could generate > > > > a hibernation image using their own key and trick the kernel > > > > into resuming arbitrary code. We don't have any way to pass > > > > secret data from the hibernate kernel to the resume kernel, so > > > > I don't think there's any easy way to do it with outsideinfo. > > > > > > Can we go back again to why you can't use locality? It's exactly > > > designed for this since locality is part of creation data. > > > Currently everything only uses locality 0, so it's impossible for > > > anyone on Linux to produce a key with anything other than 0 in > > > the creation data for locality. However, the dynamic launch > > > people are proposing that the Kernel should use Locality 2 for > > > all its operations, which would allow you to distinguish a key > > > created by the kernel from one created by a user by locality. > > > > > > I think the previous objection was that not all TPMs implement > > > locality, but then not all laptops have TPMs either, so if you > > > ever come across one which has a TPM but no locality, it's in a > > > very similar security boat to one which has no TPM. > > > > Kernel could try to use locality 2 and use locality 0 as fallback. > > I don't think that would work for Matthew, they need something > reliable to indicate key provenance. No, I think it would be good enough: locality 0 means anyone (including the kernel on a machine which doesn't function correctly) could have created this key. Locality 2 would mean only the kernel could have created this key. By the time the kernel boots and before it loads the hibernation image it will know the answer to the question "does my TPM support locality 2", so it can use that in its security assessment: if the kernel supports locality 2 and the key wasn't created in locality 2 then assume an attack. Obviously, if the kernel doesn't support locality 2 then the hibernation resume has to accept any old key, but that's the same as the situation today. > I was informed that all 5 localities should be supported starting > with Gen 7 Kaby Lake launched in 2016. Don't know if this is > still "too new". It's probably good enough. Current laptops which can't use locality 2 are in the same position as now, but newer ones can provide more security guarantees. There is, however, another wrinkle: can Kaby Lake be persuaded, though bios settings perhaps, to shut off the non zero localities? This would allow for a downgrade attack where you shut off locality 2 then present a forged locality 0 key and hibernation image; the kernel will think, because it can't access locality 2, that it's in a reduced security environment so the key might be OK. We could fix this by requiring Kaby Lake and beyond to have locality 2 and refusing to hibernate if it can't be accessed and building "is this Kaby lake or beyond" into the check for should I have locality 2, but this is getting complex and error prone. James
