On Sat, Sep 21, 2024 at 11:37 AM Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 9/13/24 23:57, Andy Lutomirski wrote: > > On Thu, Sep 12, 2024 at 5:34 PM Daniel P. Smith > > <dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote: > >> > > What, exactly, is your patchset doing that requires hashing at all? > > (I assume it's extending a PCR and generating an event log entry.). > > What, exactly, does it mean to "cap" a PCR? How is this different > > from what your patchset does? > > ... > I did not see the term actually defined in the client profile, but the > term "cap" refers to the specific action of hashing a value across a set > of PCRs. This is to reflect that certain events have occurred and will > result in a different but predictable change to the PCR value. Often > times this is to ensure that if there are TPM objects sealed to the > system with either that event having or have not occurred, they cannot > be unsealed. Thus, one has "capped" the PCRs as a means to close access > to the “acceptable” system state. Okay, so I read Ross's earlier email rather differently: > Even if we'd prefer to use SHA-256-only, if firmware elected to start us > with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse > the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order > to safely use SHA-256 for everything else. I assumed that "deliberately cap" meant that there was an actual feature where you write something to the event log (if applicable) and extend the PCR in a special way that *turns that PCR off*. That is, it does something such that later-loaded software *can't* use that PCR to attest or unseal anything, etc. But it sounds like you're saying that no such feature exists. And a quick skim of the specs doesn't come up with anything. And the SHA1 banks may well be susceptible to a collision attack. So what are the kernel's choices wrt the SHA-1 PCRs? It can: a) Perform business as usual: extend them consistently with the SHA-256 PCRs. This is sort of *fine*: the kernel code in question is not relying on the security of SHA-1, but it is making it possible for future code to (unwisely) rely on them. (Although, if the kernel is loading a trustworthy initramfs, then there won't be a collision, and there is no known second-preimage attack against SHA-1.) b) Same as (a), but with countermeasures: do something to the effect of *detecting* the attack a la SHA1-DC and panic if an attack is detected. Maybe this is wise; maybe it's not. c) Do not extend the SHA-1 PCRs and pretend they don't exist. This seems likely to cause massive security problems, and having the kernel try to defend its behavior by saying "we don't support SHA-1 -- this is a problem downstream" seems unwise to me. d) Extend them but in an unconventional way that makes using them extra secure. For example, calculate SHA-256(next stage), then extend with (next stage || "Linux thinks this is better" || SHA-256(next stage). This makes the SHA-1 banks usable, and it seems like it will probably defeat anything resembling a current attack. But maybe this is silly. It would probably require doing the same thing to the SHA-256 banks for the benefit of any software that checks whether the SHA-1 and SHA-256 banks are consistent with each other. e) Actually try to make the SHA-1 PCRs unusable. For example, extend them with random numbers. My inclination is that having some kind of Linux "policy" that SHA-1 is forbidden adds no actual security value. Option (a) honestly seems fine. Nothing in the kernel *relies* on the SHA-1 hash being secure. But option (b) also seems okay if someone is willing to put the effort into implementing it and creating a proper test case. But the description of all this could certainly do a better job of explaining what's going on. --Andy > [1] A future expansion of Secure Launch will be to enable usage of > Intel's Hardware Shield, link below, to provide runtime trustworthy > determination of SMM. The full extent of this capability can only be > achieved under a DRTM launch of the system with Intel TXT. When enabled, > this can be used to verify the SMM protections are in place and inform > the kernel's memory management which regions of memory are safe from SMM > tampering. > > https://www.intel.com/content/dam/www/central-libraries/us/en/documents/drtm-based-computing-whitepaper.pdf Wow. I skimmed this paper. What an overcomplicated solution to a problem that doesn't deserve to exist in the first place.
