Hardware-backed attestation in TLS
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61962 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023537 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Presentation of a groupComputer hardwareMechanism designWorkloadPublic key certificateEncryptionTransport Layer SecurityClient (computing)Extension (kinesiology)Suite (music)Server (computing)Formal verificationGeneric programmingLatent heatComputer configurationConfiguration spaceInternetworkingInformation securityAuthenticationBootingPerfect groupRoundness (object)Key (cryptography)Right angleIdentity managementCodeArrow of timePoint (geometry)AuthorizationTerm (mathematics)TelecommunicationMultiplication signPhysicalismScaling (geometry)Connectivity (graph theory)FirmwareOpen setSocial classBenchmarkWorkloadResultantSoftwareQuicksortPoint cloudServer (computing)Formal verificationMetadataMechanism designSurfaceState of matterPeer-to-peerLogicMinimal surfaceINTEGRALCryptographySoftware developerFront and back endsService (economics)NumberStack (abstract data type)RootPrototypeConnected spaceTheoryCASE <Informatik>Communications protocolEndliche ModelltheoriePublic key certificateDirection (geometry)Numbering schemeEncryptionInformation privacyExtension (kinesiology)Open sourceClient (computing)Internet der DingeGroup actionMereologyRevision controlComputer architectureBitGreatest elementRemote procedure callCartesian coordinate systemAbstractionMessage passing2 (number)InformationType theoryDependent and independent variablesSuite (music)Computing platformVariancePlanningProjective planeKernel (computing)Interactive televisionTransport Layer SecuritySign (mathematics)Computer hardwareToken ringDecision theorySoftware engineeringArmBuildingDataflowInterface (computing)Core dumpImplementationDifferent (Kate Ryan album)Generic programmingDiagramConfiguration spaceFactory (trading post)SynchronizationProof theoryOcean currentDiagramProgram flowchart
Transcript: English(auto-generated)
00:00
I trust that everyone here considers authentication a staple of 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.
00:21
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 Yanoz Mihaljia. I'm a senior software engineer in ARM. I do mostly software prototyping, so doing proof of concepts for various software stacks
00:42
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
01:01
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 tracker is somewhere on the communication path between the peers.
01:23
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 that workload is indeed
01:44
running the software that you're assuming it's running. So 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.
02:00
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 state of that workload, and it's key.
02:27
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
02:43
identity key that was provisioned at 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
03:01
only your devices connect and can access whatever service, whatever the service is doing. And sort of a mirror use case is, is one that involves workloads running in the cloud. So you have, you have again, the workload that has a private identity key provisioned, for example, in in the server chip, and you want your local device to connect to the workload.
03:27
And you want to get more information about software, for example, the software that booted on the server, and how the key is managed. This is where remote attestation comes in. So remote attestation is essentially a class of hardware backed mechanisms that allows
03:43
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, what the software in the workload
04:02
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 around on top of it. If we look at the data flow for remote attestation, this is a bit complicated.
04:26
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 attester and the relying party.
04:40
So authentication happens between these two, and it's the attester 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.
05:06
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 attester with its software, the boot time software, for example, and its identity key.
05:25
And then with this information about the attester, 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
05:40
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 provide secure channels of communication.
06:01
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 establish a security channel, the secure channel, and you do remote attestation on top of that. As we're trying to integrate remote attestation directly into TLS to make it more efficient
06:22
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 in that
06:40
client hello, a bunch of extensions and other things for the server to act upon. Then the server sends its, for example, any chosen cipher suit or any other responses to the extensions that the client sends, has its own key share, and then it authenticates
07:00
itself using a certificate message and the certificate verifier and ends with a finish. And then the client can go ahead and authenticate itself using a certificate message and a certificate verifier, and it finishes the handshake with a finish message. After that, you have a secure data channel between the two peers.
07:22
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 verifier is encrypted using session keys. In terms of what we care about, it's the extensions mostly, because those are used to negotiate,
07:43
negotiate a 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.
08:03
Just to state 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
08:21
devices. And we want to support the most common deployment patterns, so for example, we want to allow both client and server to authenticate, or potentially both. We want to allow existing deployments that use PKI to also use remote attestation within the same handshake just to enhance the security, so there's a whole lot of variance there.
08:44
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 from some victim platform, and
09:01
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
09:22
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 redacted some of the metadata, or schemes like direct anonymous attestation that provides some sort
09:41
of privacy. Moving on to the practice, so looking at our prototype. The big picture here is that we're trying to produce an end-to-end prototype of the 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
10:04
is quite broad and allows a lot of deployment patterns, so 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 a root of trust. And obviously we're open-sourcing the entire stack, also because these components that
10:24
we're using are already open-source software, part of, for example, the Cloud Native Computing Foundation or the Confidential Computing Consortium, and it's actually under the Confidential Computing Consortium attestation special interest group that our work is harbored.
10:41
Going 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 attester with an existing root of trust, and the attester wants to communicate with their relying party to authenticate it,
11:00
and the relying party will then send the attestation evidence over to the verifier for verification. So this is what is called, what we call background check model, because the relying party is doing background check on the evidence provided by the attester, and in our case, if we put a bit more flesh onto this diagram, you can see that, in our case, the attester will be
11:24
a client in a TLS handshake, and the relying party will be the server, and the TLS stack that we're using is embedTLS, and the client will essentially send attestation evidence produced by the client's root of trust, and embedTLS on the client side will communicate
11:46
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 embedTLS, again, communicating with the verifier, which is, in our case, composed using the veraison. So now let's have a look at all of these components independently.
12:04
So Parsec. What is Parsec? Parsec is a platform abstraction for security, so if you write, 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
12:23
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
12:44
to create an identity for your workload, and to use it, for example, to sign TLS handshakes. 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.
13:03
Moving on to the other end, so we have veraison, which is a set of components that can be used to build an attestation verification service. So again, veraison is pretty abstract, it has a bunch of components, for example, for appraising different types of attestation schemes, has components for building, for
13:21
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 veraison, and when the device tries to connect to an
13:43
application service, that application service can again go to veraison 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,
14:06
we don't have, 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
14:24
identity, so an attesting key that it can use to sign attestation credentials, and also ways to, for example, select the TPMPCRs that you want to include in the attestation tokens, for example, to select whether you want to send information about your firmware, or about
14:41
your bootloader, or about your operating system kernel. And we also have a new API to produce endorsements that are then fed to veraison for endorsements, so veraison can then trust the key attestation tokens. On the veraison side, again, we have to add
15:04
support for the precise attestation scheme that we're using, and essentially we had to build two new plugins, so one to understand the evidence that we're producing through Parsec, and one to understand the endorsements. So what essentially we're doing here is we
15:23
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, is implementation of TLS and the TLS, and
15:42
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
16:03
for IoT and edge use cases, like the one that I described earlier, and also we had already expertise working with embed 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
16:20
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 pool the expertise and the work required to
16:40
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 to create the ecosystems around our use cases.
17:02
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 roots of trust. So, for example, we've released the TSA API crate that helps with interacting natively
17:21
with TPMs. We've released the Cryptokey crate, which is essentially a successor to the PKCS11 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
17:42
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
18:02
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 PKCS11 individually, what if we could integrate with all of them via Parsec directly?
18:20
On the Go ecosystem side, we also have a bunch of packages that we've released. A notable one is GoCozy, which I believe was initially developed by Mozilla and abandoned. But then our Verizon team took it over, gave it a good dusting, and then released it. And now
18:40
it's, I think it's used quite widely, for example, by Notary and Sixtor. And we also have a bunch of other packages relevant to remote attestation verification, like Swede or Quorum. And yeah, this brings me to my main selling point here, is that we're trying to essentially
19:00
build an ecosystem where attestation can just be used as a plugin 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 to it, we're trying to make
19:22
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 walks. So just to wrap up here, we think that remote attestation is indeed a viable authentication
19:44
mechanism in TLS and perhaps in other protocols as well in the future. Our design, both in terms of theoretical design, so the drafts, the TLS extensions try to be as flexible and secure as possible, but also the prototype that we're building, we're trying to make it quite flexible as well. And we want to refine all of our drafts and all of the things that
20:05
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
20:22
protocols but more widely. So yeah, questions? So any questions from the room? I see a hand.
20:46
Yeah, thank you. You mentioned you're working under CNCF and CCCF. Have you also considered the open source firmware foundation? The open source? Open source firmware foundation. No, not really all. I mean, neither of these, neither of Parsec or Verizon are really
21:03
firmware 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.
21:22
Hey, thanks for the talk. I was kind of curious how big the impact is on like round trip times in TLS if you have like secure enclave or TPM involved in like the initial handshake, like how does that, do you see any problems in practice putting that in scale, at scale or?
21:40
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 like 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,
22:03
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. Okay, do we have some other questions? Anyone? If not, thank you for your talk. Thanks.