Okay, hi.
My name is Thomas.
I'm an engineer at TARM.
I'm also a contributor to Project Verazin.
This presentation is about Verazin and wants to give you an idea of what the project is
about and how it fits in the wider translation of natural computing picture.
I hope that, you know, after listening to this, you'd be motivated to at least have
a look at the project and maybe become an early adopter or even a contributor in the
future.
Who knows?
So without further ado, let me go through what I've put together here, starting with
a bunch of trees via about the project.
So we have a logo and the colorful ovals there are supposed to represent grapes.
In fact, Verazin is a term used in winemaking and is the moment when grapes start ripening,
at which point they can be of different colors, and in fact, the word means change of color.
And this is sort of visual metaphor of the blurry nature of trust, which can be yes,
can be no, green grape, red grape, or really anything in between.
There's some debate around the way the word is pronounced, the French say verison, the
English say Verazin or Verazin, so you have a choice, you have multiple choices.
In fact, please do not spell it like the American technical company, because that would be really
confusing.
And it's also a background for verification of attestation.
It started within ARM, in the architecture and technology group, to which I belong, together
with my colleagues, as I'm on the team, as well.
It's been adopted by the Confidential Computing Consortium in June 2022.
It's currently in incubation stage, meaning it's in the early phases of adoption.
And we're looking at growing it across a few different metrics, the most obvious being
code and documentation maturity, but also, we are also trying to grow the community a
bit.
And being here is part of that effort.
But yeah, the headline here is that we've moved from being an ARM project to be under
the Linux Foundation umbrella, therefore, we are completely open governance and of course
open source.
Before we dive into the core of the presentation, though, let me give you a bunch of pointers
also useful, the code base, GitHub, the chat, the mailing list hosted by the Confidential
Computing Consortium, and these confusing URL, which is one for our regular weekly calls,
which I'm not expecting you to memorize, in fact, you could just follow the first link
in the list, the GitHub work, and the splash page should have all of these other links.
But general, feel free to join any of these channels, pop up with our calls, ask questions,
whatever.
You will be always very much welcome.
So now we do a quick recap on remote attestation, starting with the problem.
So you suppose you have these two guys, a test for an underlying party that needs to
engage in some sort of distributed computation.
Suppose also that initially they don't trust each other, they're mutually distrusting,
and then you can't make progress in the computation until a trust relationship can be established
between the two.
And instances of this kind of situation abound, for example, in Confidential Computing, the
test is typically the guy that excuse the workload, the Confidential Workload, and the
underlying party needs to know that these guys is trusted before it shares some input
with it.
Say, for example, you need to ship an ML model, or some privacy sensitive data, or both.
And there's obviously obviously the dual problem where the underlying party is the consumer
of the output of the computation, say you are an actuator of some sort that acts upon
signals that are coming from the tester, and you want to trust the tester before making
a mess, right?
Say, there's stuff in critical infrastructure, especially.
So to break this impasse, the natural thing to do is for one party to convince the other
that they can be trusted.
And here's where attestation comes in the frame, so attestation, what is attestation?
It's a technique that uses specialized components, which is rooted in hardware called the root
of trust, that the attest can use to do basically two things, sampling the current state of
its TCP, of its trusted computing base, and put together a report, and be signed this
report with the secret identity keys that are securely stashed inside the root of trust
in hardware.
All of that in a trustworthy way, in such a way that no one, even a co-located software
or firmware, can subvert these sequence of actions.
And this signed report is called attestation evidence, or evidence.
And the evidence, which is basically a very, very strong authentication signal, can be
sent to the RP, which, once it receives it, needs to verify by checking that the signature
of the report is correct, and that the identity of the signer is known and trusted, and also
to check that the reported TCP state is acceptable, slash good, for some local policy-defined
interpretation of what good means.
And the process of verification of evidence is the process that covers at least these
two checks that we just discussed.
And in the remote attestation architecture, which is RFC 9334, freshly published, this
process of verification of evidence is taken care of by the verifier role, which basically
mediates between attestors and reliable parties.
And I know that the lines in this picture are not real channels between real devices.
They are logical channels between architectural roles.
So they can be recomposed and put together in a very different way, depending on the protocol.
Logically, these are the relationships between various architectural roles.
And in order to do this function, the verifier needs to know a few things, a few very important
things.
First, how to verify the identity of A of the attestor, and typically that is done by
knowing a public key associated with the secret signing key of the attestor, and knowing that
in a reliable way.
And B, what is the expected state of the attestor TCP, of course.
And this can become pretty messy, depending on how complex the attestor is.
On one end of the spectrum, you have very simple attestors that can be described with
a single measurement, does not change or changes glacially.
And on the other hand, there are composite testers that are made of more than one attestor,
each attestor sporting its own TCP, each TCP made of multiple separate independently moving
parts, you know, software components configuration and whatnot, with multiple different supply
chain actors involved, you know, think can become really hairy.
So if the complexity is very low, it makes sense to co-locate a simple verifier with
the underlying party, but if that's not the case, you know, it might be a reasonable choice
to design a system where the verification function is effectively offloaded to a separate
architectural component.
These options are not, you know, aggregation, disaggregation, they are not mutually exclusive.
Take for example, the case where the tester is composite and its evidence can be clearly
split along a platform slash workload axis.
So in that case, one might want to call an external platform verifier, and if everything
is okay, then move to a local verifier for the verification of the workload.
You know, as I said, the things are logical, they can be reassembled and put together in
very, very different way.
But in general, whatever the system architecture you come up with, the verifier role needs
a bunch of trusted links to the supply chain that is involved in the verification, because
the supply chain endorses the attesta, right, and so it's critical that the link between
the supply chain and the verifier is a trusted one, and that endorsements are genuine.
And these are the green boxes in this picture.
But if I could also have an owner, I typically have an owner, that can provide the verification
policies for evidence to it, save for, you know, to customize the process of appraisal
or, you know, in a special situation to provide out batching.
And to complete the RATS architectural picture is the RP owner, Reliant RATS owner, can feed
the policy for how to act on the attestation results coming from the verifier, right, to
extract the reliability to make decisions based on the appraisal done by the verifier
regarding the attesta.
So this finishes the RATS recap.
And the question now is, where is Verizio in this picture?
And as you may have guessed, is the blue box at the center.
But it's not just that, it's also all the lines that are attached to the blue box, that
is all the verifier interfaces, which are quite a few.
Let's start from the bottom left and then move clockwise.
So evidence, we've built a bunch of libraries for manipulating various evidence formats,
both from point of view of the verifier, so the coding and verification, but also from
the attesta point of view, which means encoding and signing.
This way, if one needs to put together an end-to-end flow, say for integration testing
or for the demo, it's quite easy to build this, you know, attesta remulator.
You don't need to deal with the real horror, which can be tricky, especially if you're
dealing with CI environments.
The current list of supported evidence includes two ID profiles, PSA for Cortex-M, so IoT
Gizmo and NCCA for the new ARM-V9 confidential computing architecture.
We also have a TPM profile, and this came from an integration project we did with our
friends at Inact Trust, who have a product for monitoring device health that can use
Verizio as a backend.
We have a bare-bones implementation of DICE, say TCG, but even Open is okay, I think.
And then we have AWS Nitro, contributed by our friends at Veracruz.
Veracruz is another triple-C project, so a confidential computing project that uses
Verizio as the backend for their proxy CA.
On the endorsement, RefValueFront, we have implementation for Quorum, which is a format
we co-designed with Intel and Fromhofer in the DICE working group in TCG, and has now
been adopted in the ATF Rats working group on the standards track.
It's basically a specialized format for describing how the attester looks like to the Verifier,
which aggregates different subformats for specifying a bunch of orthogonal but cool
existing dimensions of the platform, so software, firmware, trust anchors, other things.
For policy, we have integrated OPPA, Open Policy Agent, which is an existing successful
general-purpose policy engine.
We found something that existed that was fit for purpose, so we didn't feel the need
to reinvent this specific bit.
And for attestation results, there's an info model that's being standardized in the ATF
called R4C, which allows to normalize the appraisal output so that the relying party
policies can be simplified greatly, because now they're fully decoupled from the specifics
of the attester.
But because R4C is just an info model, we had to create a serialization for it, which
we based on it.
We call EAR, EAR is a good candidate for standardization, because there's nothing at this point in time,
and so we're trying to push this through the RAS working group in ATF as well, and it's
the only output format we support for now.
As far as attestation result policies, we do nothing because this is completely autoscoped,
this is entirely on the underlying party.
So yeah, now I wanted to give you the map of what we just discussed with what exists
in the Verison Convey.
And note that nearly the entirety of what follows is goal line packages, and also command
line tools and services slash demons in good old UNIX patterns, and this was a conscious
choice.
We choose to go with Golang, because one of the main goals of the project is to provide
a bunch of component 3 to assemble system that provides verification as a service.
And Golang is a very good language in terms of library support, native library support
ecosystem, and also in terms of business, the learning curve is very non-steep, I would
say.
So it's trivial to learn, and therefore we hope that more people can be, more contributors
could come by lowering the barrier here.
So let's start with a couple of layer zero packages, Eat and Gokuzi.
Eat is the entity that is the decision token, it's the main format for attestation messages,
either evidence or attestation results that have been put forward by the ATF.
It's basically a framework that extends caught and jotted by adding a number of claims with
attestation specific semantics, and also a way to instantiate the framework through so-called
profiles, and PSA and CCA being just two such examples.
The Eat package is very neat package is not tracking the most recent version of the draft.
We decided to wait for the draft to become RFC before doing a final alignment pass because
it has all the claims that we need for the dependent packages, and so for the moment
is good as is.
But we will need to make it up to date, as soon as the document goes through the final
stages of the standardization process.
And Eat builds on caught, which in turn uses CosiSign and SineOne, so early on we realized
that we needed a Cosi implementation in Go, and the only thing we could find at the point
in time was Gokuzi, which was originally developed by Mozilla for their autograph service, but
it supported only CosiSign, so we forked it and extended to support SineOne, but then
Mozilla discontinued it, at the point in time when we wanted to contribute it back to the
main line, they discontinued the project, so we took responsibility of it alongside Microsoft,
and together with Microsoft we did a fair amount of work, including improving the ergonomics
of the interfaces, and also making implementation generally more robust, and to that respect,
we went through a couple of external security reviews and addressed older comments, so we're
fairly confident in that this package has production quality, and we shipped 1.0.0 just
a couple of weeks ago, and this is the first ever release bit of Verizon, so we're particularly
excited by that.
It's an interesting package among the lots, also because it's used not just by Verizon,
but also by other quite big projects, Notary in CNCF and SiegStore, OpenSSF, so it's a
nice, it's come out as a nice, useful building block that has relevance in the community.
Now moving on to the evidence, you know, these are the evidence bits, the red, the orange
things, we have the two-it profiles for CCAMPSA, the DICE thingy, and the sort of house-like
shape is the common line interface called AV-CLI, which is an attester emulator that
also talks to the Verizon verification API client side, so it can be used to play with
the services quite easily on the common line.
The yellow things are the attestation results packages, so here, there's only one package,
basically, it's Verizon here, and there's an associated CLI arc, it can be used to verify
and pretty print results, so one can pipe AV-CLI outputs into arc to see what happened
during appraisal, and the green thing is the bunch of endorsement draft file-related packages,
including the top-level manifest format, Corem-Corem, and the dependent bits for firmware verification
keys and software and so on, so Corem-Coremade, Corem-Quartz, and Swede respectively, and
also Cochly, which is the common line interface for assembling Corems from a bunch of JSON
templates, you sign them and then you can submit them to the Verizon services using the
provisioning API, which is linked into Cochly, and finally, the blue box, including microservices,
which I will talk about in the next slide, and the client-side interface of the Verizon
API, which exists also in Rust with C-bindings, and I think a pure C implementation has been
contributed as well, I don't know where, if it's been merged fully or is still an open
PR, but anyway, so yeah, let's have a quick look at the services architecture. Basically,
there are two pipelines, one for verification, the bottom one, and one for provisioning,
the top one, that converge on to the core services, VITIS, which connects to the data
and the plug-in stores, it's called VITIS, VITIS is another winemaking one, and it's
basically Verizon's services, tracel computing base, it has a whole, the security-related
computation in it. The interesting thing is that the processing in both pipelines is
in stages, and with very precise hook points, where plug-in code can be supplied by the
user in order to customize certain aspects of the processing. So basically, what you
do is as a user that wants to add their own format, either of evidence or for endorsements
and ref values, you build your plug-in code so that you basically, you adapt your formats
to the standardized processing pipeline. Right, so next steps, we have a few exciting
new things in the pipeline, adding new formats, of course, opportunistically though, depending
on contributions, integrations, et cetera. We want to improve documentation, not a very
exciting bit, but a necessary step in making the project useful and usable. And this is
a big one, we want to work on the identity and access management to support the more
generic multi-tenant service, and this is the single missing bit that prevents Verizon
from being used in a production context at this point in time. And finally, we want to
allow a static plug-in list build in order to reduce the potential attack surface on the
services. Yeah, this is what the next months will bring us. So, questions? Thank you very
much, by the way, for listening.