linux-kernel - Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 08 Aug 2023 15:37:53 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Dionna Amalie Glaze <dionnaglaze@...gle.com>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        Sathyanarayanan Kuppuswamy 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>, dhowells@...hat.com,
        Brijesh Singh <brijesh.singh@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Borislav Petkov <bp@...en8.de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Samuel Ortiz <sameo@...osinc.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-coco@...ts.linux.dev, keyrings@...r.kernel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports

On Tue, 2023-08-08 at 11:48 -0700, Dionna Amalie Glaze wrote:
> > Isn't this more runtime attestation?  In which case you wouldn't
> > use the boot report.  I assume someone somewhere is hacking the
> > TPM-TLS protocol to also do RTMRs, but it strikes me we could just
> > use a vTPM and the existing protocols.
> > 
> > Even if you don't do anything as complex as TPM-TLS (and continuing
> > runtime attestation), you can still make TLS conditioned on a
> > private key released after a successful boot time attestation. 
> > Since the boot evidence never changes, there's not much point doing
> > it on each connection, so relying on a private key conditioned on
> > boot evidence is just as good.
> > 
> > James
> > 
> 
> The TPM quote will need to be bound to the VM instance, so there will
> still be a hardware attestation in there that incorporates the user's
> challenge.

Well, it's all in the protocol: A TLS-TPM system using a physical TPM
has to do an EK/AK makecredential/activatecredential to verify it's
talking to a real TPM.  In the CC vTPM case that step is substituted by
doing a vTPM attestation.  However, the point is in each case the
verification step is only done once before you trust the TPM.  After
that, it's the TPM key you trust because the proof, in either case, was
that the key is TPM generated and the TPM should be tamper proof
(enforced by the casing for a physical TPM and the situation in the
VMPL or other software protection for the vTPM).

> Anything less than that is subject to replay attacks, no? Am I
> missing a clever trick?

Trusting the vTPM is a one time thing.  Once trust in the TPM is
established, you don't need to be worried about replay and you can just
use standard TPM primitives for everything onward, even when doing
point in time runtime attestation.

James