From: "zhangjiale" <zhangjiale@linux.alibaba.com>
To: "linux-coco" <linux-coco@lists.linux.dev>,
"dionnaglaze" <dionnaglaze@google.com>,
"hannes.tschofenig" <hannes.tschofenig@gmail.com>,
"Yogesh.Deshpande" <Yogesh.Deshpande@arm.com>,
"thomas.fossati" <thomas.fossati@linaro.org>,
"Thomas.Fossati" <Thomas.Fossati@arm.com>,
"public" <public@thson.de>,
"jeffandersen" <jeffandersen@google.com>,
"chongc" <chongc@google.com>,
"roksana.golizadeh.mojarad" <roksana.golizadeh.mojarad@intel.com>,
"dan.j.williams" <dan.j.williams@intel.com>,
"jejb" <jejb@linux.ibm.com>
Subject: Re: Attestation evidence collection "standard package(s)" effort
Date: Wed, 06 Mar 2024 15:32:21 +0800 [thread overview]
Message-ID: <7440d664-0004-42d4-9067-f6ce79cc1f5b.zhangjiale@linux.alibaba.com> (raw)
Dionna Amalie Glaze wrote:
> Hi all, I thought I'd start the conversation here about a concern I'm
> hearing in various working groups. There are many software packages
> folks are writing to provide in their VM guest images to gather
> attestation reports and quotes, and no one feels they have a good
> mandate to say "X package is what everyone ought to use" and that it
> should be in most distributions' software repositories.
>
> I'm not coming here with a suggested 15th tool that standardizes all
> the other 14 standards, but to see what folks' requirements are such
> that we can establish a concerted effort to solve them as a
> collective. I still will suggest a concrete starting point to focus
> the conversation.
>
> The problem I think a large majority of us want to solve is how to
> provide evidence to (possibly remote) requesters in a standard format.
>
> Challenges:
>
> 1. authZN: who is allowed to gather evidence? To make attestation work
> with a background check model (RFC9334) and seamlessly for users who
> want "security sprinkles", the standard tool should be a daemon that
> provides an evidence collection service for a standard protocol. I'd
> recommend getting a tcp port assigned from the IANA and combining TLS
> with OAuth 2.0 to pass "evidence challenge requests" to the server and
> get evidence out. This is just a concrete starting point, not a line
> in the sand.
>
> The service doesn't need to be on, and in fact I think we want an
> offline tool and a service that wraps the tool in order to keep the
> functionality opt-in.
>
> 2. request/response formats: I would recommend that responses use the
> standards effort in IETF RATS for a Conceptual Message Wrapper (CMW).
> Part of the challenge is to reduce the amount of variance in that
> wrapper. Roksana (CC'd) is trying to lead an effort for manufacturers
> to converge on a standard evidence format going forward, but an
> envelope is needed for now due to existing bespoke evidence formats.
> For the request, I think we should talk about ways to multiplex
> challenges out to configfs-tsm, TPM, workload attesters and the like.
>
> Given a standard request/response format, we may even get Microsoft to
> provide more access to the guest attestation service in their Windows
> offering?
>
> 3. extensibility: I think that each evidence collection technology
> should be a separately installed plugin to the daemon, and the daemon
> knows through configuration how to request evidence and store the
> result in the final CMW.
>
> 4. binary distribution: distributing the binary(ies) that collect
> evidence to include in the format is the nail biter. How do we build
> trust in which implementation to use? This is where I think we would
> like to come together to produce an implementation under open
> governance and consortium support in the form of CCC or linux
> foundation or something. The goal of proposing a standard for evidence
> collection though is that other implementations would still be able to
> be used seamlessly in the remote attestation ecosystem.
>
> 4b. trustworthiness: not to start a flame war (please), but I think
> there's a large contingent of folks that expect this tool to be
> written in Rust.
>
> I would ask that we keep the discussion of a single non-envelope
> evidence format to a separate forum, since we are trying to account
> for SEV-SNP, TDX, and TPM.
>
> On that note, I will shout out different client/library implementation
> projects that I specifically hope would join the collective effort.
>
> * go-configfs-tsm/go-sev-guest/go-tdx-guest/go-tpm-tools: All Google
> libraries with a client aspect that would be happy to switch to a
> standard client that more folks can easily include in their images.
> * Keylime: A TPM project that cares deeply about TPM quotes, yet also
> has the client problem.
> * cc-api/cc-trusted-api: An Intel project that provides a compelling
> interface, yet still is looking for collaboration to build collective
> trust in the project.
> * virtee: Mostly a SEV tool, but an open source community that cares
> about security and remote attestation
> * AMDESE/sev-guest: AMD's own tool for collecting a SEV-SNP attestation.
>
> I'm sure James Bottomley has a specific suite of TPM tools to plug
> here, but I don't know them specifically. I've heard about client
> software on video calls but haven't learned the specifics.
>
> This is a lot of duplicated effort that makes negotiations with Linux
> distributions difficult. What packages should be included? I would
> hope a suite of packages under a single banner that we can all be
> happy with.
> --
> -Dionna Glaze, PhD (she/her)
Hi, Dionna. Glad to see this proposal.
I would like to recommend an open-source component that has made
considerable efforts toward unifying TEE evidence provision: attestation-agent.
(https://github.com/confidential-containers/guest-components/tree/main/attestation-agent)
This component is currently implemented under the Confidential Containers
(CNCF Sandbox project), but it is not customized for Confidential Containers.
It is a completely universal component that focuses on Attestation.
The current implementation of the Attestation Agent is:
1. A fully Rust written daemon service that supports listening to specified
TCP ports or UNIX socket in the form of gRPC/ttRPC.
2. Each evidence collection technique is implemented as a plugin that
can be installed at compile time, and currently supports six different
platforms‘ evidence collection techniques (tsm-configfs support is currently in
a pull request (PR)).
3. Use JSON-wrapped serialized strings for request and response formats.
4. In addition to providing evidence, it can also support connecting to remote
attestation services to obtain reports or tokens of evidence verification results.
Here is the declaration of the API provided by Attestation Agent:
https://github.com/confidential-containers/guest-components/blob/main/attestation-agent/protos/attestation-agent.proto
I think that the implementation direction of this open-source component is
largely consistent with the expectations you mentioned in your proposal,
and its maintainers now hope to further develop and distribute this component
in some form in more upstream communities (such as CCC).
We hope to work together with you and the other open-source projects
you mentioned to achieve the ultimate goal of unification.
--
- Jiale Zhang
next reply other threads:[~2024-03-06 7:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 7:32 zhangjiale [this message]
2024-03-06 9:50 ` Attestation evidence collection "standard package(s)" effort Christophe de Dinechin
-- strict thread matches above, loose matches on Subject: below --
2024-01-23 18:44 Dionna Amalie Glaze
2024-01-27 16:29 ` James Bottomley
2024-01-27 22:39 ` Dionna Amalie Glaze
2024-01-29 21:29 ` Thomas Fossati
2024-01-29 23:46 ` Yogesh Deshpande
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7440d664-0004-42d4-9067-f6ce79cc1f5b.zhangjiale@linux.alibaba.com \
--to=zhangjiale@linux.alibaba.com \
--cc=Thomas.Fossati@arm.com \
--cc=Yogesh.Deshpande@arm.com \
--cc=chongc@google.com \
--cc=dan.j.williams@intel.com \
--cc=dionnaglaze@google.com \
--cc=hannes.tschofenig@gmail.com \
--cc=jeffandersen@google.com \
--cc=jejb@linux.ibm.com \
--cc=linux-coco@lists.linux.dev \
--cc=public@thson.de \
--cc=roksana.golizadeh.mojarad@intel.com \
--cc=thomas.fossati@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).