I trust that everyone here considers authentication a stable internet security and that you think
that having more information about the security state of your peer when authenticating them
is obviously a good thing if you want to make a good decision.
So with that in mind, I want to talk to you about our work to integrate remote attestation
as an authentication mechanism in TLS.
So first off, who am I?
I'm Jonas Mihalca.
I'm a senior software engineer in ARM.
I do mostly software prototyping, so doing proof of concepts for various software stacks
that we think might be useful for our software ecosystems.
So looking at an overview of the presentation, so we're going to start with some theory.
Looking at remote attestation at TLS and how we plan to integrate the two.
And then we're going to continue looking at the practice at the prototype that we're
building to instantiate the theory and the draft that we're working on.
So let's kick off with the theory.
What exactly are we trying to improve here?
So the current internet security model is mostly based around an assumption that the
attacker is somewhere on the communication path between the peers.
So what you usually do is you have some sort of certificate that you issue to the workloads
and you have the private key associated with that certificate.
And the workload can then essentially authenticate itself to its peers.
But the problem is that in this trust model, you have to trust that workload is indeed
running the software that you're assuming it's running.
Even if, for example, your peer presumably uses some open-source software, you still have
to trust them that they've deployed that and that that's where they're running.
And also that they're keeping their key secure because if the software is changed or if the
key is exfiltrated, then you're kind of hosed.
So if you want to have more guarantees, can we actually use more emotive verifiable information
within our authentication methods so that we have more information about the security
states of that workload and its key?
And we actually were prompted to look at this from two use cases in particular.
So the first one involves IoT or edge deployment.
So for example, you have in this diagram, you have an edge device that has a private
identity key that was provisioned at a manufacturing time.
And with this identity key, you want to create some attestation credential that you can present
to a service.
So presumably, you own both the device and the service, and you want to make sure that
only your device is connected and can access whatever the service is doing.
And sort of a mirror use case is one that involves a workload running in the cloud.
So you have, again, a workload that has a private identity key provisioned, for example,
in the server chip.
And you want your local device to connect to the workload.
And you want to get more information about software, for example, the software that booted
on the server and how the key is managed.
And this is where remote attestation comes in.
So remote attestation is essentially a class of hardware-backed mechanisms that allows
you to provide cryptographically verifiable metadata about the state of your device.
So you can have more trust about, for example, what kind of firmware was running at boot
time, what OS kernel you're running, and maybe even what the software in the workload
is.
So you do this by using that private identity key that was provisioned within the device.
And the device essentially becomes certificate authority for itself, and it can issue credentials
for all the workloads running on top of it.
If we look at the data flow for remote attestation, this is a bit complicated, and it's useful
to think of the arrows not as physical communication paths, but as logical data flows, essentially.
And the components that we care mostly about here are the attestor and the relying party.
So authentication happens between these two, and it's the attestor that wants to authenticate
themselves using some sort of remote attestation.
And as you can see from the diagram, they're not actually connected in the data flow.
There's another component there called a verifier, which takes the attestation evidence, produces
attestation results that the relying party can then understand and trust.
And the verifier also has above in the diagram a sort of supply chain, and in particular
the endorser and the reference value providers, they issue, essentially, they provision the
attestor with its software, the boot time software, for example, and its identity key.
And then with this information about the attestor, they can go ahead and talk to the verifier
and make sure that the verifier trusts the device.
So when the verifier tries to appraise the evidence, it understands it and trusts it
and then can produce valid attestation results.
Switching on to TLS, so the transport layer security, a pretty ubiquitous security protocol.
It's used everywhere from HTTPS to lightweight M2M to secure, to provide secure channels
of communication.
And these secure channels essentially follow a handshake protocol where the peers authenticate
each other.
And what usually happens with remote attestation is that you have, you establish a security
channel, the secure channel, and you do remote attestation on top of that.
Whereas we're trying to integrate remote attestation directly into TLS to make it more efficient
and also to limit the attack surface that an attacker might see.
If we look at TLS 1.3, the handshake in particular, and how we want to integrate with it.
So the handshake starts with the client sending over a client hello, a key share, and then
the client hello, a bunch of extensions and other things for the server to act upon.
Then the server sends, for example, any chosen Cypher suit or any other responses to the
extensions that the client sent, has its own key share, and then it's authenticates itself
using a certificate message and a certificate verify, and then it's with the finished.
And then the client can go ahead and authenticate itself using a certificate message and a certificate
verify, and it finishes the handshake with the finished message.
After that, you have a secure data channel between the two peers.
It's important to note for privacy reasons mostly, that from the second flight onwards,
most of those messages are actually encrypted.
For example, the certificate, certificate verify are encrypted using session keys.
And in terms of what we care about, it's the extensions mostly, because those are used
to negotiate, negotiate the type of credentials that, for example, the relying party might
care about, and also to send across any freshness that is required to issue the attestation
evidence.
And also, we care about the certificate message, because that's obviously where we're going
to carry the attestation credentials.
Most of our goals, our high-level goals, obviously we want to enhance authentication
in TLS to support your model attestation.
We want to support as many platforms as possible, from very beefy cloud servers to small IoT
devices.
And we want to support the most common deployment pattern.
So for example, we want to allow both client and server to authenticate, or potentially
both.
We want to allow existing deployments that use BKI to also use remote attestation within
the same handshake just to enhance the security.
So there's a whole lot of variance there.
In terms of security and privacy, we're planning to formally verify the extensions that we're
creating, and we're working quite meticulously to try to prevent any potential attacks, for
example, relay attacks, where taking a credential form, some victim platform, and you're trying
to pawn that off as your own.
Then in terms of privacy, fortunately, attestation does reveal quite a lot of metadata, and this
can be both privacy and security relevant.
And the best we can do is to mitigate some of these by allowing the relying party to
choose what kind of attestation scheme or attestation results it gets.
So you can get, for example, specially crafted attestation results that have blinded or deducted
some of the metadata, or schemes like direct anonymous attestation that provides some sort
of privacy.
Moving on to the practice.
So looking at our prototype.
The big picture here is that we are trying to produce an end-to-end prototype of this
system, so we're trying to implement everything from the root of trust all the way to the
verifier.
And we're sort of limiting this because our drafts and our theoretical work is quite broad
and allows a lot of deployment patterns, we're limiting this to, for example, a background
check model that I'll talk about in a bit, and the TPM 2.0 as the root of trust.
And obviously we're open sourcing the entire stack, and also because these components that
we're using are already open source software, parts of, for example, a cloud native computing
foundation or a confidential computing consortium, and it's actually under the confidential computing
consortium attestation special interest group that our work is harbored.
Moving back actually to the remote attestation diagram, architecture diagram, you can see
here a simplified version of that, so on the bottom you can see an attestor with an existing
root of trust, and the attestor wants to communicate with the relying party to authenticate it,
and the relying party will then send the attestation evidence over to the verifier for verification.
So this is what we call a background check model because the relying party is doing a
background check on the evidence provided by the attestor, and in our case if we put
a bit more flesh onto this diagram, you can see that in our case the attestor will be
a client in a TLS handshake, and the relying party will be the server, and the TLS stack
that we're using is MBET-TLS, and the client will essentially send attestation evidence
produced by the client's root of trust, and the MBET-TLS on the client side will communicate
with the root of trust not directly, but through Parsec, which is one of the projects that
we've been developing, and on the server side you have MBET-TLS again communicating with
the verifier, which is in our case composed using Uvaraison.
So now let's have a look at all of these components independently.
So Parsec.
What is Parsec?
Parsec is a platform abstraction for security.
So if you try to write an application in Java or Python or Go, you might want to use some
sort of cryptographic hardware backing, so for example a discrete EPM or some trusted
services running in TrustZone, and you want to use these in a more generic way, and this
is what Parsec is doing, it's presenting a high-level interface that you can use to provision,
and Parsec in particular has this sort of identity key as a core use case that it works
with, so it tries to allow you to create an identity for your workload and to use it,
for example, to sign TLS antics.
And Parsec is also quite modular, so it's really easy to implement backends for other
types of hardware backends that you might want to support.
Moving on to the other end, so we have Varaison, which is a set of components that can be used
to build an attestation verification service.
So again, Varaison is pretty abstract, it has a bunch of components, for example, for
appraising different types of attestation schemes, as components for building, for example,
APIs for evidence provisioning, or for endorsement provisioning for verification APIs.
So in this diagram here, some factories is creating a device and then producing the endorsement
data that it then feeds to Varaison, and when the device tries to connect to an application
service, that application service can again go to Varaison to verify those credentials.
In terms of what the work that we had to do to make this prototype work across the stack,
so Parsec, as I've said, works mostly with cryptographic keys, however, at the moment,
we didn't have a very generic key attestation API, and this is something that we had to
build to produce those attestation tokens or attestation evidence.
Parsec also needs to have configuration to allow it to essentially provision its own
identity, so an attesting key that it can use to sign attestation credentials, and also
ways to, for example, select the TPM PCRs that you want to include in the attestation
tokens, for example, to select whether you want to send information about your firmware
or about your bootloader or about your operating system kernel, and we also have a new API
to produce the endorsements that are then fed to Varaison for endorsements, so Varaison
can then trust the key attestation tokens.
On the Varaison side, again, we have to add support for the precise attestation key scheme
that we're using, and essentially, we have to build two new plugins, so one to understand
the evidence that we're producing for Parsec, and one to understand the endorsements.
So what essentially we're doing here is we have two components, and we're trying to make
them agnostic of whatever is transporting evidence and endorsements between them, which,
in our case, is actually a bad TLS.
So the TLS implementation that we're using, the TLS, it's an implementation of TLS and
the TLS, and the reason why, it's actually multiple reasons why we're using it, so one
of them is because it offers this PSA crypto API, which Parsec hooks into, as per our design,
since we created it in sync with the PSA crypto API.
It also has a small code footprint, so it's more suitable for IoT and Edge use cases,
like the one that I described earlier, and also we had already expertise working with
Mbeth TLS, so it was easier for us to work with it.
So the open source ecosystem around our projects, and this is something that has been quite important
for me in the past years while I've been working on Parsec, realizing that open source is more
than just some checkbox that we want to take, and that's it.
It's more about the continuous involvement in the community and trying to pull the expertise
and the work required to create some components that we can reuse across all of our stacks.
And yeah, this is the reason why we've been seeding projects into CNCF and CCC, because
we're trying to create these communities around our projects and create the ecosystems around
our use cases.
So if we look at the Rust ecosystem in particular, for example, because the Parsec service is
written in Rust, we've released a number of crates relevant to handling routes of trust.
So for example, we've released the TSA API crates that helps with interacting natively
with TPMs.
We've released the CryptoKey crate, which is essentially a successor to the PKS11 crate
that was abandoned some time ago, and we have the PSA CryptoCrate that allows native interaction
with PSA Cryptography API, and it's actually been quite a nice experience to see the communities
around these projects grow and have more developers from various projects, some of which have actually
presented today getting involved and helping us build this ecosystem.
Yeah, the more important goal for us, at least, is not just to make these particular backends
easy to use in Rust, but perhaps even to make them easy to use in an abstract way.
So instead of having to integrate with TPMs or PKS11 individually, what if we could integrate
with all of them via Parsec directly?
On the Go ecosystem side, we also have a bunch of packages that we've released.
A notable one is GoCosy, which I believe was initially developed by Mozilla and inabandant,
but then our Verizon team took it over, gave it the dusting, and then released it, and
now it's, I think, it's used quite widely, for example, by No3 and SixTor, and we also
have a bunch of other packages relevant to remote attestation verification like SWEED
or Quorum, and yeah, this brings me to my main selling point here, is that we're trying
to essentially build an ecosystem where attestation can just be used as a plug-in for authentication.
So whether you integrate it within the authentication step of a TLS stack, or perhaps you want to
switch that to some sort of quick stack, or maybe you want to even have some sort of bespoke
authentication server and workload trying to authenticate it, we're trying to make it
easy to use remote attestation by making Parsec and Verizon interact so easily, so you can
just plug those components in and hopefully get attestation right as it works.
So just to wrap up here, we think that remote attestation is indeed a viable authentication
mechanism in TLS, and perhaps in other protocols as well in the future, or design both in terms
of theoretical design, so the drafts, the TLS extensions try to be as flexible as possible,
but also the prototype that we're building, we're trying to make it quite flexible as
well.
And we want to refi all of our drafts and all of the things that we're trying to define
with other people across the industry, trying to create an end-to-end prototype that represents
all of this theoretical work, and yeah, we're hoping that the prototype will serve as a
model for integrating remote attestation not just into specific protocols, but more widely.
So yeah, questions?
So any questions from the room?
I see hands.
Yeah, thank you.
You mentioned you're working under, well, CNCF and CCCF, you also considered the open
source for more foundation?
Open source?
No, not really.
I mean, neither of these, neither of Parsec or Verizon are really firmer level components.
Right.
So yeah, we're essentially doing very similar stuff, but doing the full flow, like starting
from the very first code running on your platform, like in the firmware.
We should get in touch.
Thank you.
Perfect.
Hey, thanks for the talk, I was kind of curious how big the impact is on round trip times
in TLS if you have secure enclave or TPM involved in the initial handshake, like how does that
work?
Do you see any problems in practice putting that in skill at scale?
We've not really gotten to the point where we can properly test end-to-end in terms of
actually going to hardware and talking to hardware, so we're mostly doing with software
TPMs and stuff like that, so just to integrate, we still have some integration work to do
there.
But yeah, we're definitely going to benchmark that and see how it impacts, but it obviously
depends on the hardware because if we do that on some server, you know, some cloud server,
that's going to be quite different from doing it on an IoT device that has a TPM or something
like that.
Yeah.
Okay, do we have some other questions, anyone?
If not, thank you for your talk, thanks.
Thank you.