On Wed, Aug 14, 2019 at 4:09 PM Peter Jones <pjones(a)redhat.com> wrote:
On Wed, Aug 14, 2019 at 03:00:32PM -0400, Paul Moore wrote:
> I don't have anything written up on the approach yet, but the
> abstract/teaser for the LSS-NA talk is below.
>
>
https://lssna19.sched.com/event/RHaB/securing-tpm-secrets-with-txt-and-ke...
I don't intend to argue with you, or to say you're an idiot.
Your phrasing sent a different message.
That said, fundamentally the design of TXT enforces measurement ...
Oddly enough, it really doesn't. TXT, and the SINIT ACM, at its basic
level is really just about creating a clean environment where you have
some guarantee (once again, assuming you trust Intel) that everything
that happened before can not affect what you do next. It's the tboot
implementation that enforces policy.
... but adds a step in the middle of the boot chain that's not
verifiable as part of Secure Boot.
Not verifiable as part of the UEFI Secure Boot as currently
implemented, yes. However, I don't believe that is an inherent
limitation, with some work I believe tboot could be made to co-exist
with UEFI Secure Boot, but I will admit that is beyond the scope of my
initial effort.
Intel claims it is verifiable by the hardware, which may well be
true and meaningful, but we're still just running a binary blob on the
main CPU after the firmware has gone away.
From a practical perspective, the SINIT ACM and various bits of system
firmware are all binary blobs that I really have no way of verifying.
With UEFI Secure Boot I have to trust Microsoft, with TXT I have to
trust Intel.
--
paul moore
www.paul-moore.com