On 8/15/24 15:10, Thomas Gleixner wrote:
On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
On 5/31/24 09:54, Eric W. Biederman wrote:
Eric Biggers <ebiggers@xxxxxxxxxx> writes:
That paragraph is also phrased as a hypothetical, "Even if we'd prefer to use
SHA-256-only". That implies that you do not, in fact, prefer SHA-256 only. Is
that the case? Sure, maybe there are situations where you *have* to use SHA-1,
but why would you not at least *prefer* SHA-256?
Yes. Please prefer to use SHA-256.
Have you considered implementing I think it is SHA1-DC (as git has) that
is compatible with SHA1 but blocks the known class of attacks where
sha1 is actively broken at this point?
We are using the kernel's implementation, addressing what the kernel
provides is beyond our efforts. Perhaps someone who is interested in
improving the kernel's SHA1 could submit a patch implementing/replacing
it with SHA1-DC, as I am sure the maintainers would welcome the help.
Well, someone who is interested to get his "secure" code merged should
have a vested interested to have a non-broken SHA1 implementation if
there is a sensible requirement to use SHA1 in that new "secure" code,
no?
Just for the record. The related maintainers can rightfully decide to
reject known broken "secure" code on a purely technical argument.
Thanks,
tglx
There is one simple question, does allowing the Secure Launch code to
record SHA1 measurements make the system insecure, and the answer is
absolutely not.
The role of the Secure Launch code base in the context of the larger
launch process is to function as observer. Within this role, its only
responsibility is continuing the trust chain(s) that were started by the
CPU/Hardware. It does so by measuring the components and configuration
it is responsible for loading and applying, i.e. in TCG parlance, it is
continuing the construction of the transitive trust for the system. In
this aspect, the only degradation of security that can affect the
kernel's role is whether all the necessary entities are safely measured
and not what algorithms are used.
If the system integrator, whether that be the OEM, your employer, the
distro maintainer, the system administrator, or the end user, configures
the DL preamble to only use SHA1 or used older hardware that has a
TPM1.2, then they are accepting the risk it creates in their solution.
In fact, a greater threat to the security of the launch is the
misconfiguration of the IOMMU, which risks the kernel's ability to
safely make measurements, as compared to the use of SHA1. Yet it was
insisted in past reviews that we allow the user to specify an incorrect
IOMMU policy.
In the end, the "security" of an RTM solution is how and what
measurements are used to assess the health of a system. Thus bringing it
back to the opening question, if SHA1 measurements are made but not
used, i.e. the attestation enforcement only uses SHA2, then it has zero
impact on the security of the system.
Another fact to consider is that the current Intel's TXT MLE
specification dictates SHA1 as a valid configuration. Secure Launch's
use of SHA1 is therefore to comply with Intel's specification for TXT.
And like the IOMMU situation, having the option available allows the
user to determine how they ultimately want to integrate Secure Launch
into their integrity management. And because Secure Launch will only
attempt SHA1 if it was in the TXT configuration, when either Intel
removes SHA1 from the MLE specification or firmware manufactures begin
disabling the SHA1 banks, this will obviously mean that Secure Launch
will not produce SHA1 measurements.
On a side note, with my remote attestation hat on, the SHA1 measurements
can in fact be extremely useful. If an attestation was made containing
both SHA1 and SHA2 chains, and the SHA1 of an event was correct but the
SHA2 was not, either a natural collision happened or someone maliciously
caused a collision. The former has an extremely low probability, while
the latter is highly probable.
Thus, with this information alone, it is possible to make the reasonable
determination the device is compromised. Whereas if both hashes are
mismatched, without any additional information it is equally probable of
either misconfiguration or compromise. And to state the obvious, with
only SHA2, further information is needed to distinguish between
misconfiguration and compromise.
V/r,
Daniel P. Smith
