In an increasingly connected world, workloads may run in any number of environments and locations.
It's necessitates moving the trust boundary out of the data center, out to the edge where
data is being produced and processed.
If we consider networks which is, for instance, deployed across the University campus or
servers within an office or workstations at a retail location, even with in these areas
with sort of physical, limited physical access controls, remote attestation gives us assurance
as to the state of those systems.
So key lime is an open source project which does TPM based at a station and verification.
It has built-in support for UEFI measured boot and Linux IMA file integrity.
And IMA basically sort of reports on the state of files, measures files.
So if somebody boots one of our devices for me USB drive, for instance, an appropriately configured
key lime policy could detect that.
But there is a bit of a problem here because in the current key lime architecture, the protocol
is driven by the server or by the verifier.
What this means is that in these scenarios which we just talked about, that's probably
not going to work because those communications are going to get blocked at the firewall because
you would need to open ports so that the key lime verifier can reach out to a, you know,
attested node and attain obtain the attestation from that node.
So over the last year, the key lime community has undertaken a project to enable attestations
to be pushed from the various nodes on the network instead.
So we've also used this opportunity to sort of modernize the key lime protocols, improve
the security and lay the groundwork for future capabilities.
Before we get into the details, my name is John.
I work for Hulate Packard Labs as a security researcher in the office of the CTO.
I have a master's in information security and procrastination from the University of
Surrey and since last year, I've been working as a contributor on the key lime project
to unlock the features that we're going to talk about today.
So key lime consists essentially of four rough components.
You have first the registrar and the registrar receives a set of identities for a system
that you're trying to attest.
And yes, of course, yeah, I see it, let's try it out.
You want to just know where, okay, you know, I'm glad I can, I see things appreciate it.
Hold it, yeah, I can do that.
Where was I, so, all right, so, you know, I'm not shown on this diagram, the key lime
agent here, but, you know, those identities are being sent by the agent on startup.
And so, we have the endorsement key, which is sort of resonant within the TPM, an additional
attestation key, and, you know, optionally, that might include a device ID as well, which
will talk about in a bit.
The sort of third component here is the key lime verifier.
And the key lime verifiers, main job is to, you know, actually verify the evidence.
But the verifier needs to get access, because these components are separate, right, they're
totally different web services that you deploy.
So you need to get the attestation key to the verifier.
And so, the user does this sort of, as a provisioning step, where they basically invoke
or they query the register or database, you know, 40 identities fetch the AK from there,
and then the user can also provide their policies and reference measurements and, you
know, provide them to the verifier.
And there's this tenant CLI tool, which you can use to do that as well, you don't have
to use the rest APIs directly, but that's how that works.
And then, you know, once that AK is in, those APIs as none of the APIs are both secured
by NTLS with a certificate, you know, that's issued to the, you know, requesting party.
And then once you have that in place, you can now sort of receive evidence from your
helium agents in the push model.
And this includes your TPM quote, your UFI, and I'm a logs.
So we're going to take a look at individual pieces here.
First we're going to start with the sort of register side on the left there.
So if you look at the sort of bits that we're adding to, in the push model, the,
I forgot to mention, sorry, this, you know, push that to station API, we're securing it
with this sort of proof of possession, which is sort of a new authentication protocol,
which I'm going to talk about in a bit, and that's based on the AK.
But if we, if we focus first here on the, on the register side, we're adding this new web
hook mechanism.
So if we take a look at that, effectively, what we're trying to accomplish here is when
when the verifier submits sort of these identities, I'm sorry, we, we, we create them.
When the agents submits these identities to the register are, the register needs to make
a determination as to whether those identities are, you know, to be trusted or not, whether
they're coming from sort of a legitimate expected node.
And, but like, if you, if you're familiar with the AK certificate, FETPM, you know, typically
has this endorsement key, and there's a, a certificate that is issued by the TPM in the
factor with that sort of endorsement key in the certificate, right?
So you may think that that might be sufficient, you know, to, to authenticate the by-sets
registering.
But in fact, if you look at the TPM spec, it contains this statement here, which says that
the TPM reporting state of the platform by quoting the PCR values.
For assurance that these PCR values accurately reflect that state, it is necessary to establish
the binding between the RTR that's a root of trust for reporting and the platform.
So in other words, you need to establish a binding between your TPM and the platform, the
system, you know, in which that TPM is a part of.
So why do you need to do that?
Well, if you look, if you consider this scenario where you're over the register on a verifier
and we have this note on the right, but they were trying to attest the state of, you know,
in this example, we have an attacker here that has, you know, basically compromise that note
in some way, maybe for instance, they're exploiting the black loaders vulnerability to sort
of install, which is for bypassing your boot and install a UEFI, what's the word?
A boot kit, sorry, and, you know, but because we're doing sort of remote attestation, we expect
to be able to detect that scenario, right?
But if our adversary sort of also has control of the network, when that note goes and sort
of sends that message to register its identities with the register, the adversary can just block
that request, right, going through. And then if you have another note and this could be a note,
you know, the gym and node, that's part of your network, or the adversary could, you know,
might have control over this note as to know that they've constructed, but they're leaving
it sort of the state sort of in a known, good state intentionally. And the registration request
for that note goes through just fine, it reaches the register. But on the way there, the adversary
changes the message so that instead of, you know, saying, oh, hi, I'm, I'm node two, you know,
it's claiming that actually this is a message coming from node one. And so, you know, the
registrar will accept that because that EK is an EK that is coming from a legitimate or a genuine
TPM device. So it's going to match against the manufacturer cert just fine. And our sort of
challenge response here where we do this make credential, actually credential process, that's also going
to, you know, proceed as normal without issues. So when the, the user then goes to sort of in
roll this node or it goes to the going to roll node one here for verification with the
verifier, they're going to query the registrar and they're going to get EK2 back, right? And so now
you have this scenario in which the verifier has associated the identity of node one. And importantly,
the policies and reference measurements for node one with actually the attestation key or the
EK4 node two, right? So the mismatch here between what policy is being applied and, and the policy
that we intend to apply apply. So when we're thinking of attestation security as a kind of security
property, you need to, you know, we make the statement that we say that the sort of verification
outcome that is reported by the verifier needs to match the sort of expected verification outcome
for that node. And if you don't do that, that's a vulnerability in your protocol. And the
inverse of that is also true because depending on how you're using this attestation, you know,
that can, you know, if somebody forces an attestation to fail, that could cause the denial of
service, uh, service scenario, consider if you are, uh, you know, provisioning identities with
something like spiffier spire. Um, so there already exists an option in QLum today for sort of
solving this problem. Um, and this is because QLum supports, uh, what are known as dev IDs,
and dev ID is really just an X509 certificate that's issued to a specific device.
And if you issue that certificate at the time of manufacture of that device,
we call it an ID of ID or initial dev ID. There's also this other identity here called the IAK,
very similar concept. It's, again, a certificate, uh, which, you know, is issued for the device.
And the, the corresponding keys for those certificates are both generated by and stored in the
TPL. Um, so what this means is that you have a certificate identity, uh, which is issued by the
device manufacturer, um, with keys that are stored, um, only resident within the TPL, um, and that
certificate identity is, is, you know, typically has a serial number of the device in it, right?
Um, so you can basically identify a particular, uh, server, for example, on your network,
and say, I want to apply this policy to this server, and you can have a assurance that you're actually
applying the policy to the right, uh, node. Um, so, but we're introducing a new, uh, you know, option
here for people, um, if you don't have dev IDs or, or maybe you want to augment, uh, dev IDs, uh,
in this way, um, and so in this sort of new new approach, uh, you have, um, you know, registrar,
uh, basically can, you know, optionally reach out to an external service, uh, to help in this sort of decision
process. So here you have the agents submitting its identities across, um, you have the registrar
comparing those against your, uh, trust store as per usual, um, and it's reaching sort of an initial,
uh, trust decision there. Um, but now, um, it can submit that decision along with all the
identities that's discovered from the agent, uh, to this external service, and that service may, uh,
queries, some type of inventory system, or maybe it reaches out to, uh, your CSPs, uh, rest APIs,
because maybe you're, you're running this workload, um, in the cloud, and, and you don't,
and you actually have a VTPM, and you don't actually have a, um, EK cert, uh, for this particular
node, uh, so you need to verify the, the identity, uh, in some other way, um, and then that service can
reply, uh, either override the decision that the registrar, uh, reached, uh, originally, or it can just
provide additional information that it's discovered. For example, here I'm having it sort of providing an
additional, uh, C.A. cert, um, and the registrar will reevaluate that and, and come to a final decision.
Um, so that was the identity decisions web hook. Um, now we're going to take a look here on the
right on the verifier side. And we're first going to take a look at this, uh, proof of possession,
authentication, protocol. So in key lime today, messages from the agent, um, are authenticated
by a TLS certificate, which is sort of generated by the agent, um, and then it sort of enrolls
that certificate with the verifier via, you know, a particular, uh, uh, uh, you know, protocol.
Um, and so the, and so that's the fundamental way at which your rest APIs are sort of protected
by, from sort of unauthorized access by just sort of anyone on the network, right? Um, where
sort of replacing that in the push, uh, protocol with this proof of possession, uh, mechanism.
So the way that this works is that the, uh, agent, uh, or sorry, there's actually two phases here
that I'm going to talk about. There's a capabilities, no good inflation phase first. And in that phase,
we have the, the agent that is supplying a list of its sort of supported, uh, sort of capabilities,
um, here we're just doing sort of, you know, basic, uh, you know, TPM sort of attestation. So it's been
quite listed, uh, algorithms at the TPM supports, um, and the verifier replies with, um, sort of, a token
that it issues, um, you sort of like a session token, basically, similar to a bearer token in, in a
loft, uh, world, if you're familiar with that concept, um, and it also provides the nons, and it picks
one of the, the algorithms that are, uh, you know, that the, the agent says it has available to use, um,
and then the, we have the second phase here. And the first part of this phase is that this,
agent is going to perform a TPM to certify. Um, we're doing something slightly interesting here,
or something, unconventional, in which we are certifying the key, the AK with itself, if that makes sense.
So we're signing, uh, the TPM object, which is the AK, and we're using the AK to actually perform
that signing operation, um, because we don't really care about so much about what we're signing,
as long as it includes or not. So we're going to include our nons, you know, qualifying data, um,
and, you know, and that gives us, you know, the sort of proof that we need that this, uh, uh,
you know, that we're talking to this agent, uh, or the agent with this TPM, really. Um, and so the,
the agent replies with that sort of sort of occasion, which, uh, the verifier is going to, you know,
check against the AK check against the nons, um, and then, you know, the verifier applies,
uh, with a message saying that, okay, this token is actually now, uh, valid, uh, is now active.
And then we can use that token in sort of subsequent requests. Um, moving along to, now, you know,
the actual interesting portion, or what we're trying to get to here, and this is the, the sort of
push out of station protocol. Um, so we have, again, the two two parties here, and again,
very similar to the, the authentication protocol. We just talked about it. It sort of happens in these two
phases. Um, and again, you know, you submit here, you know, in your first request. Now, you're token
that you've got from your authentication protocol, um, and again, a list of supported algorithms,
um, and other details about the device. Um, and then the verifier can use whatever logic it needs to
determine, uh, you know, which of those capabilities, the, the agent should use to protect,
excuse me, to prepare the evidence, um, and it's going to include, uh, a new nons there as well. Um,
and so the agent can now sort of prepare, um, a quote, uh, using the, uh, those details, um, and it provides
whatever, you know, logs it needs to, and again, it's authenticating that with our session token,
which is just sent sort of in the authorization, uh, header of an HTTP request. Um, and then so
so you're, you're verifier then just sort of replies with an okay response, provided that all these,
sort of bits of data look correct. They sort of validate against sort of surface level, um,
you know, validation tracks. Um, and then the verifier actually after this protocol is complete,
if goes off and actually goes and verifies the evidence that's been provided, um, against our policies
and against our reference measurements, uh, for that device. So, I want to give you all sort of an idea
of what this, these APIs, uh, you know, look like how, what it's like to work with them. Um, um,
and what we've really tried to do here is be kind of forward thinking in how we specify these,
so that, you know, maybe in the future, you know, K-line has other capabilities, maybe we're doing
at a station that is not TPM based, maybe we're doing other forms of TPM, at a station
we're providing different kinds of evidence. So we have, you know, this is the request that you've sent
in, um, when you're sort of creating that, uh, when you're doing that capabilities and negotiation,
first, so this is sort of message one there on this diagram here. Um, so you're saying, okay,
I want to sort of create a new attestation resource on the server, um, and this is the evidence
that I, as the agent, um, support, um, you know, I can give you a TPM code if you want it, um,
and that TPM is running version two, um, and of the other TPM spec, um, and, you know, these are all
hash algorithms, I support these are all signature schemes I support, um, and here are all the keys I have,
you know, knowledge of as the agent, and, you know, in K-line today, of course, it only sort of
contemplates this attestation key, so you're only going to have that one attestation key, uh,
there typically, um, but in the future, maybe you have other keys, maybe you have, um, a, a, a, a
v-sac, for instance, uh, for talking about confidential computing. Um, and if you scroll down here,
we can see, okay, you know, the, you can also sort of specify, okay, I have access to a measured
boot log, I have access to, to I'ma entries. So, this gives us sort of flexibility to expand,
uh, keyline capabilities in the future, um, you know, for various other uses. Um, the last thing I
want to sort of point out here, um, is that in the, the poll model, um, you know, there's less concern
about the verifier, or sorry, about an agent sort of behaving, uh, sort of, you know, misbehaving,
really. Um, but when agents can sort of submit attestation, sort of, of their own deletion, you
have to do sort of additional things here. So, some of the things that we do do sort of, uh, prevent
misuse of these APIs is that we sort of allow the user to configure an interval between which,
quotes are expected to be received. Um, and that's enforced by the verifier, um,
and we also enforce that only one attestation is ever processed for a given agent at any one time.
And then finally, we also have a configurable verification time out. Um, so if a single
attestation is occupying the verifier for too long, um, you know, we can reject that request.
Um, so this is the current status of all of this work. Um, we have one PR that's been merged
which was sort of just a kind of, kind of, kind of, kind of offended, or exceedingly, a foundational
refactor of the existing sort of web code base. Um, and we have sort of three PRs that are sort of,
um, in various stages of maturity. Um, I think they're all currently marked as graphed, I think
that's been a change, a very suit in the very near future, uh, particularly the one that
implements the push at the station protocol. Um, I think that one's reaching, uh, maturity, um,
and, and then the, the pop, uh, authentication protocol will probably follow, uh, shortly thereafter.
Uh, these are all service exchanges so far. Um, we have Anderson and, uh, some folks that
read had that are helping us, you know, come, yeah, that's over the finish line with the sort of
agent side of this. Um, so, so that, that can be expected in the, in the, in the near future, hopefully,
as well. Um, and then, you know, there's this other PR, where sort of extending the docs to
explain sort of the adversarial model or the threat model that we were considering when we designed
uh, these protocols. Uh, so thanks for, uh, listening to me, listening to me ramble, uh,
for half an hour, um, does anyone have any questions?
Yes.
You mentioned that if you use a divine D, you, uh, right, of course, yeah, I've
greeted the question, I'm so sorry. Uh, so the question is that, um, in this scenario in which
you have these two, uh, nodes and you're sort of, you know, you have an adversary that's sort of mixing
up the, the, the, the, the, the, the, the, the, the, the, the attestations or the, or the messages that
are coming from these two nodes. How does a device ID or a dev ID prevent that from occurring?
So the idea here is that instead of using some arbitrary identifier for your node, like,
node one or some random UUID or whatever or a hostname, um, you know, you're, you're, you're, you're
you're using the device as serial number as the identifier.
So you're saying, OK, I know I have this device.
With this serial number, why do I know that?
And I know that because I have an inventory database
of all my systems.
And I want this particular policy to apply to this serial number.
And you have that enforcement from the,
because you trust the device manufacturer
who has issued the certificate, which contains that serial number.
Yeah, does that make sense?
Well, I mean, if, I mean,
anyone can issue a certificate, right?
But you have, it's going to be dependent on what
sort of the ASR to you trust, right?
So it's signed by the manufacturer of cert.
So you're going to add the manufacturer of cert
to your trust store.
And then only that manufacturer can issue those
the ID certificates.
Yeah?
I don't know if the certificate is to your interest.
So that would be when you should get back to cert
versus what they change in the identity piece of the node.
That there would be a free sum security protocol
in place here, actually, because the practical authentication
of the, in this case, of the ID by the,
because otherwise, your choice, replacing the identity
by a new, the identity find a certificate,
which I can again copy from somewhere else,
which I actually found to be from somewhere to please.
Yeah.
So sorry, I didn't get into the details of how that works.
But yes, there is a check that happens.
So you basically prove possession of the,
the, the, the, the, the, the, the, the,
effectively, when you do that registration.
So you use, you prove that the AK is linked to the,
dev ID, basically, during the registration process.
So I think that's all all my time.
If anyone has any further questions, yeah, I'll be around.
So.