Keystone: towards an open standard for trusted execution environments
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 | 637 | |
| 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/52524 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 202171 / 637
1
2
7
8
10
11
12
17
29
33
35
38
40
44
48
50
54
59
63
65
85
87
91
95
97
105
108
114
115
119
120
122
126
127
129
130
133
137
140
142
143
147
149
151
156
159
160
161
168
169
170
175
176
177
178
179
182
183
184
187
189
191
193
197
198
204
206
209
212
220
222
224
227
230
233
235
238
242
243
245
247
252
253
255
258
260
261
262
263
264
265
272
273
278
281
282
285
286
287
288
289
294
295
296
302
304
305
308
310
316
320
323
324
328
330
332
335
338
342
343
347
348
349
350
351
360
361
365
368
370
372
374
377
378
380
381
382
383
386
390
392
395
398
402
405
407
408
409
414
419
420
422
425
427
430
439
451
452
453
458
460
461
464
468
470
471
472
473
475
478
485
486
487
491
492
493
495
496
498
509
510
511
512
516
532
534
538
543
548
550
551
554
556
557
559
563
568
570
572
574
575
577
583
585
588
591
593
595
597
601
602
603
604
605
606
607
610
611
617
627
633
634
00:00
Computer hardwareIntegrated development environmentOpen setStandard deviationSoftware frameworkOpen sourceReduced instruction set computingRing (mathematics)Data integrityRootCryptographyMechanism designFirmwareCodeFormal verificationFormal grammarBus (computing)Software development kitInterface (computing)ArmIterationEndliche ModelltheorieFingerprintMobile appMobile WebPoint cloudIntelDigital rights managementBuildingProjective planeOpen sourceProcess (computing)Semiconductor memoryData managementRevision controlCartesian coordinate systemComputer programmingChainUtility softwareBuildingMereologySoftware frameworkINTEGRALRootIntegrated development environmentEntire functionEncryptionMechanism designOperating systemContext awarenessFirmwareInformationComputer hardwareOrder (biology)Information securitySoftware developerSource codeSpeicherschutzSoftwareWrapper (data mining)Slide ruleImplementationLatent heatArmModel theorySoftware testingLibrary (computing)Computing platformCASE <Informatik>Mobile WebDomain nameDampingMicrocontrollerServer (computing)Partition (number theory)Social classConnectivity (graph theory)Flow separationPhysical systemFunctional (mathematics)CoprocessorNetwork topologyCausalityWorkstation <Musikinstrument>Level (video gaming)Exception handlingPersonal digital assistantPerspective (visual)SpacetimeWebsiteComputer architectureVideo gameWordTime zoneWorkloadExecution unitFormal verificationScripting languageSet (mathematics)FreewareCodeVelocityShared memoryComputer animation
06:00
BefehlsprozessorReduced instruction set computingStandard deviationImplementationComputing platformBuildingReduction of orderDisintegrationComputer hardwareFormal verificationOpen setArchitectureSoftwareSource codeProcess (computing)Ring (mathematics)Asynchronous Transfer ModeVirtual machineModel theoryRootInformation securityRead-only memoryComputer architectureInternet service providerAsynchronous Transfer ModeSet (mathematics)MikroarchitekturOperator (mathematics)Binary codeKernel (computing)Process (computing)Ring (mathematics)MereologyShared memorySoftwareGame controllerCache (computing)PhysicalismVirtual machineSpeicherschutzConnectivity (graph theory)Computer configurationCore dumpProper mapCryptographyRootDifferent (Kate Ryan album)Model theoryAbstractionSemiconductor memoryCoprocessorImplementationRange (statistics)Address spaceContext awarenessIntegrated development environmentProjective planeComputer hardwareOpen setComputing platformInformation securityInterface (computing)Standard deviationOrder (biology)Extension (kinesiology)Open sourceMultiplicationMicrocontrollerLevel (video gaming)FreewareMechanism designSoftware developerCartesian coordinate systemUniform resource locatorWordDependent and independent variablesNP-hardRun time (program lifecycle phase)Graphics processing unitPartition (number theory)Error messageConstructor (object-oriented programming)Arrow of timeFormal verificationINTEGRALSocial classServer (computing)CodeExpert systemMotif (narrative)Physical systemImage resolutionState of matterPosition operatorSoftware frameworkCASE <Informatik>Forcing (mathematics)Service (economics)Latent heatXMLComputer animationProgram flowchart
11:54
Software frameworkBuildingBlock (periodic table)SoftwareFirmwareComputer hardwareMultiplicationComputing platformMicrocontrollerEntire functionExtension (kinesiology)Read-only memoryGame controllerCache (computing)Advanced Encryption StandardLatent heatEncryptionBootingSpeicherschutzReduced instruction set computingCarry (arithmetic)Integrated development environmentReduction of orderDisintegrationFocus (optics)Formal verificationOpen sourceInterface (computing)Binary fileAsynchronous Transfer ModeOpen setRootVideo trackingCryptographyData managementAbstractionModel theoryLevel (video gaming)Formal grammarImplementationFunction (mathematics)Information securityAerodynamicsLibrary (computing)Physical systemSystem callThread (computing)Time zoneCoprocessorSoftware frameworkCartesian coordinate systemOrder (biology)TwitterOpen sourceComputer hardwareProjective planeModeling languageSide channel attackTask (computing)PrototypeElectric generatorSet (mathematics)Medical imagingShared memoryMaxima and minimaThread (computing)Block (periodic table)IP addressModel theoryDifferent (Kate Ryan album)Graphics tabletDampingGroup actionBuildingNumbering schemeDefault (computer science)SoftwareRevision controlCycle (graph theory)Video gameCASE <Informatik>CryptographyLatent heatArithmetic progressionFirmwarePoint (geometry)Semiconductor memoryMereologyCache (computing)Proof theoryFormal verificationRange (statistics)Game controllerInformation securityExtension (kinesiology)ImplementationCoprocessorMultiplicationINTEGRALBinary codeRootEndliche ModelltheorieComputing platformBootingData managementProcess (computing)Level (video gaming)Physical systemComputing platformInterface (computing)Formal grammarRemote procedure callStress (mechanics)Cross-platformComputer architecturePartition (number theory)AuthorizationWebsiteOpen setRoutingMeasurementFunctional (mathematics)Motif (narrative)40 (number)Term (mathematics)WaveComputer animation
18:17
Element (mathematics)Computer animation
Transcript: English(auto-generated)
00:06
Hi, my name is Dayoli from UC Berkeley. Today, I'm going to talk about an open source project called Keystone, which I've been working on for a couple of years. Let me first briefly introduce our project.
00:20
Keystone Enclave is a framework for Trusted Execution Environments or TE. It is an open source project with permissive license. Most parts are under BSE3 class with several components licensed under MIT and Zlib licenses. It's been two years since we released the first version in December 2018.
00:42
Keystone is based on RISC-V instruction set architecture. It was started in the University of California at Berkeley as an academic project. So there is an academic paper published in Eurosys last April. The paper actually explains a lot of details about motivation,
01:00
design, implementation, and so on. So please check it out if you're interested. As of now, it has at least eight users from both academia and industry. There are more than five active contributors and more than 50 forks so far. It's still a growing project
01:21
and it's still in its only stage, but a lot of people are starting to get involved. This is our website, so please check it out if you want more information. I'll elaborate what is Trusted Execution Environment or TE in the context of our project.
01:41
In the traditional perspective, the system security was often based on a trusted operating system. For example, the OS is in charge of process isolation and resource management and so on. We all trust that the OS will always do the right thing. So any application on top of it must trust the OS.
02:04
However, people start thinking that this might not be a good idea. So the OS is getting bigger and bigger every day, and we may never make it entirely bug-free. Because of this, a malicious application can compromise the OS to breach a security-critical application,
02:21
or also sometimes the operating system itself could be malicious. So this is where TE comes into play. The idea of TE solves this problem by relying on hardware, trusted hardware, instead of trusting the OS. So the hardware actually guarantees that the application always resides inside an isolated
02:43
or sometimes even encrypted memory space. This is often referred to as an enclave, which provides confidentiality and integrity of the data and the program execution. Also, these guarantees are, of course, backed by the remote utilization using a chain of trust based on the hardware.
03:01
So this, part of this simple idea, building TE isn't so simple, actually. As a hardware manufacturer, for example, you may need to design the entire silicon root of trust and build it, hardware mechanisms for memory isolation or encryption and so on. Also, you may need to implement some microcode or firmware
03:22
to allow the software, upper layer software, to use your hardware mechanisms. This is not the end of the story. You may also need to verify the entire thing together with rigorous testing or ideally with former methods. Also, in order to seamlessly deploy applications to a TE,
03:43
you'll probably need a lot of software tools like SDK, libraries and wrappers and so on. There are a lot of open source projects on the software side, for example, Google, Cecilo, OPT, Graphene and so on. But you may notice that there are less often
04:03
source projects on the hardware side. I'll talk more about it in the next slide. So now, all of the major hardware vendors have added some TE capability to their processors. Examples are Intel's SJX, TDX, Arm TrustZone and AMD's SEV.
04:21
However, the TE implementations on these platforms are usually not open source. This is simply because they don't disclose their hardware or microcode. Actually, this is totally fine if you're a software developer and you're gonna just trust them and use their chips to deploy your program in a TE they provide.
04:41
But the caveat here is that their TE might be tightly coupled with their business. In other words, the TE might have a very specific frame model and a lot of assumptions on the software you're gonna run. For example, Intel SJX targets a partition server or desktop application and has a very strong frame model against the untrusted external memory.
05:03
And Arm TrustZone targets mobile devices, but the applications are typically provisioned by a trusted party. So it ends up having only two security domains where all the trusted applications share the same security domain. AMD's SEV supports full VM encryption, which would be useful for VM isolation in a data center,
05:23
but not very useful for isolating individual applications. So if you have any needs beyond these use cases or have different assumptions on your workload, you may need significant amount of work to work around these things in software. Or you may also need to build a TE capable hardware
05:44
from the scratch. Actually, this is very expensive because, again, you need to build and design everything, including the root of trust, hardware mechanisms, and the microcontroller firmware. Also, you need to verify functionality and security. So the goals of the Keyson project is as follows.
06:03
First, we're gonna enable TE on every RISC-V processor for free. We enable it by sticking to the standard ISA or sub-ISA as much as possible to provide a basic set of TE functionalities, such as memory isolation and attestation. And then we make TE easy to customize
06:20
depending on the specific needs. So people can still add some kind of platform-specific features to their TE if they want. For example, you can add cache side-channel defense using some cache partitioning mechanism in your hardware or something else. So the key idea here is that you can easily reuse
06:41
a specific part of the TE implementation across multiple hardware platforms if it was open source. Any hardware vendor can easily extend our implementation to enable their custom TE with their own hardware. And also they can contribute back to the project if they want. So more importantly, we'd like to reduce the cost of TE development.
07:03
So we believe that every processor in the world will have some kind of TE in the future and a lot of application will rely on TE eventually. So anyone who want to build their own chip should be able to enable TE with very low cost. In order to achieve that, we are working on reducing various costs
07:21
such as hardware integration, verification, and integrating with existing software tools and so on. So until now, the project has been focusing on these two goals. I'll talk about how we enabled a customizable and portable TE that works with multiple RISC-V platforms. So before we dive in,
07:42
let me talk briefly about RISC-V. RISC-V is an Open Instruction Set Architecture. Note that this is not an open source processor. It is an ISA. And the key design philosophy of the ISA was simplicity, efficiency, and extensibility. So it actually fits our project perfectly well.
08:02
It's now becoming an industry standard for all kind of computing devices. And also its ecosystem is growing rapidly on both software and hardware sides. More and more companies are getting involved and building their own RISC-V chips. A lot of microcontrollers or embedded devices
08:21
are already being built with RISC-V. And we're expecting high performance or server-class RISC-V processors in the near future. So how TE can be implemented in RISC-V? So here's the difference between x86 and RISC-V privilege levels. In x86, kernel is running in ring zero
08:41
and both user process and the kernel will interact with the hardware using x86 SISC instructions. These instructions are once again translated into a microcode. And the TE is mostly implementing this proprietary microcode as a part of hardware. The hardware vendor is in charge of designing,
09:00
implementing, and verifying the TE. In RISC-V, on the other hand, there are currently three software privilege modes. Kernel runs in S mode and M mode acts very similar to the microcode in SISC architecture. Both M mode and S mode share exactly the same base instruction sets. So instead of adding instructions for TE,
09:22
RISC-V M mode can provide so-called supervisor binary interface, which is SBI for TE operations. RISC-V TEs are implemented via the M mode software and the microarchitecture components. So here's the overall architecture and trust model of Keysun.
09:41
Keysun requires a trusted hardware with unmodified RISC-V cores and the root of trust, and also may have optional hardware features such as advanced cache controller or cryptographic accelerators and so on. And on top of that, the security monitor runs in machine mode
10:01
and the monitor implements the basic security features such as memory isolation and attestation, and the monitor is in charge of also provide a proper abstraction interface of the hardware to the upper layer software. For example, different hardware may have different implementation of root of trust,
10:22
but the monitor provides the same interface to the upper layer software. And on top of that, there is a traditional software stack, which is the host, and that host can launch and execute enclaves by using the monitor interface. So each enclave will have isolated execution environment protected by the hardware
10:42
and consists of two components, which are the enclave application, which runs in user mode, and the runtime, which runs in the supervisor mode. Let me talk about how Keysun enables TE on RISC-V processors. Keysun uses hardware-enforced
11:01
and software-defined memory isolation. So we use a standard RISC-V feature called physical memory protection, or PMP. PMP is implemented by a set of special registers, only accessible by the security monitor, and the monitor can use the registers to configure entries of the physical address ranges
11:20
and the access permissions to each range. Since PMP is enforced on every physical memory access, the monitor can use it to implement memory isolation of enclaves. In an untrusted context, the security monitor protects the enclave memory as well as its own memory. By flipping, for example, these two PMP entries,
11:43
each of the enclave memory becomes exclusively accessible only when we enter this enclave, in this case, enclave one context. So based on these standard RISC-V feature, we can implement the basic set of TE capability without requiring any hardware modification.
12:03
This allows Keysun to be a customizable TE framework that can generate various TEs with shared common base. So the basic design principle is that the framework provides building blocks of TEs in software and people can customize their TEs using their framework.
12:20
The framework is in charge of composing these building blocks based on the thread model and features. And finally, the framework generates an image of TE firmware and the enclave that can run on a compatible hardware. So this is the basic idea of the Keysun. And because of our goals, we have been working hard to make Keysun a multi-platform
12:41
and general purpose TE. Thanks to the efforts, Keysun now supports both RV32 and RV64 architectures. Also recently, our team has successfully prototype enclave task execution in FreeRTOS. This means that it will work with embedded devices with minimal hardware as well.
13:01
Keysun aims to generalize the SPI so that it can easily support not only a partitioned application, but also sometimes a full application or even the fully feature OS inside the TE. Also, we make it easy to extend based on the platform specific needs
13:20
or available features on the platform. Few people, including ourselves, already have shown that this is easy to extend. And they have extended Keysun to defend different thread models or improve the performance. So we have implemented memory encryption, for example,
13:42
using the scratch pad available in the hardware, as well as a cache partitioning scheme using the advanced cache controller that has a way masking feature in order to defeat the side channel attacks. A group of people have extended Keysun to improve performance
14:00
by using available crypto accelerators in the hardware. And those are not only examples and there will be more use cases and extensions in the future. So far, we talked about how we built a customizable TE, which is portable across multiple RISC-V processors. So what's next?
14:20
We started looking at our third goal, which is to reduce the cost of building TE. This includes reducing the cost of hardware integration, verification, and also the software integration and so on. For the hardware integration, we have integrated Keysun with OpenSPI, which is ready in Keysun version one.
14:43
OpenSPI is an open source supervisor binary interface for RISC-V following the SBI spec 0.2. OpenSPI also allows to generate an M-Mod firmware for many, many RISC-V platforms. So it's now much easier to enable TE in those platforms supported by the OpenSPI.
15:03
Another effort that we have just started is to use OpenTitan as a Keysun silicon root of trust. So Keysun currently doesn't have a reliable root of trust implementation. So we'd like to integrate OpenTitan as a default root of trust of Keysun.
15:21
OpenTitan is, by the way, an open source silicon root of trust that transparently implements various hardware IPs. For example, the chip life cycle management or verified boot and so on. So this is what we exactly need. The second goal is to reduce the cost of verification.
15:42
So verification is actually the pain point when you design a TE. There is a project work in progress that tries to relieve this pain by automating some parts of the process. Here's the idea of the project from the M-Mod implementation of the security monitor. We actually can automatically generate
16:02
an instruction level software model and based on the high level former specification that we wrote for functionality, we can verify if the implementation actually follows the spec. So once we wrote this high level former specification,
16:21
the system will automatically generate this model and verify if the implementation matches with the functionality. It's quite an ambitious goal, but also we wanna combine this software model with RISC-V hardware model and prove that the model refines an abstract model
16:43
which is proven to be secure from a given adversary model. This is a following work of a formal work by Submanian, a former foundation for secure remote execution of run-claves, which was published in CCS 17, 2017.
17:06
Finally, we'll try to implement a lot of missing pieces to support wider range of applications. There are still a lot to do in order to make this happen. Actually, a long-term goal is to integrate Keystone with the existing software frameworks
17:22
so that any T applications based on these frameworks can be seamlessly ported over Keystone based T's. So to summarize, Keystone is a open source framework for T's on RISC-V. And our goal includes enabling T
17:43
on every RISC-V processor, making it easy to customize and extend, also reducing the cost of building T. We are actually happy to get any contribution or we are very open to discussion. So please contact me if you're interested in collaboration
18:04
or if you have any questions about the project. I'm happy to answer the questions. So thank you. I'm ready to take questions.