Hi Luto,
My apologies, I missed this response and the active on v11 cause me to
get an inquiry why I hadn't responded.
On 9/21/24 18:40, Andy Lutomirski wrote:
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.
Correct, the only entity that can disable PCR banks is the firmware.
When it initializes the TPM, it can disable banks/algorithms. After
that, when an extend operation is done, the TPM is expecting an entry
for all active PCR banks and the TPM itself does the extend hash that is
stored into the PCRs.
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.
I will chime in here to say that you can't ignore them, but you can send
a fixed value, either well-known or junk, as the SHA1 value when doing
the extend operation as you suggest in (e).
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.
Obviously, for the most part, we are in agreement. The one caveat is
that I don't think the effort to shore-up SHA1 provides a good return on
the costs it would incur. With no intent to disparage any one person,
there generally will be two groups that would use SHA1. The first would
be those limited by their platform and understand the risks. The second
would be those attempting to do a cryptographic-based security solution
that has either been living under a rock the last few years or has done
zero research into the capabilities they are using for their solution.
IMHO it is better to not inhibit the first group trying to save the
latter group as the latter are always doomed to failure.
But the description of all this could certainly do a better job of
explaining what's going on.
I would be glad to do so, and have tried several ways to explain it.
Even working with multiple people that understand the problem to draft a
better explanation. It would be greatly appreciated if you could provide
what points you think should be clarified to better help convey the
situation.
--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.
While we could have a long discussion over the merits of SMM, the fact
we have to face is that it is here, and it is not going anywhere any
time soon. I honestly found AMD's SMM Containerization (Appendix D of
the AMD64 Architecture Programmer’s Manual - Volume 2) the better
approach, and it saddens me that it is completely disabled.
v/r,
dps
