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.