Skip to content

Commit

Permalink
fix README (#427)
Browse files Browse the repository at this point in the history
to provide better active roadmap & project summary.

---------

Co-authored-by: Dayeol Lee <[email protected]>
Co-authored-by: David Kohlbrenner <[email protected]>
  • Loading branch information
3 people authored Mar 9, 2024
1 parent e9fcf7f commit 0f8b751
Showing 1 changed file with 81 additions and 6 deletions.
87 changes: 81 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,20 +3,95 @@
![Documentation Status](https://readthedocs.org/projects/keystone-enclave/badge/)
[![Build Status](https://travis-ci.org/keystone-enclave/keystone.svg?branch=master)](https://travis-ci.org/keystone-enclave/keystone/)

Visit [Project Website](https://keystone-enclave.org) for more information.
> Visit [Project Website](https://keystone-enclave.org) for more information.
`master` branch is for public releases.
`dev` branch is for development use (up-to-date but may not fully documented until merged into `master`).
## Introduction

# Documentation
Keystone is an open-source project that builds trusted execution environments (TEEs) for RISC-V systems. Its hardware-enforced and software-defined memory isolation enables trusted computing (a.k.a. confidential computing) with various threat models and functionalities. The implementation is platform-agnostic, making Keystone portable across different RISC-V platforms with minimal engineering efforts.


## Goals

Keystone is a free and open framework for architecting and deploying TEEs on RISC-V hardware platforms. The project's goals are:

* **Enable TEE on (almost) all RISC-V processors**: Keystone aims to support as many RISC-V processor cores that follow RISC-V standard ISA and sub-ISAs as possible. This will help hardware designers and manufacturers to enable TEE with minimal efforts.

* **Make TEE easy to customize depending on needs**: while providing simple TEE features, Keystone also aims to allow various customization that depends on platform-specific features or non-standard sub-ISAs. We borrow the concept from software-defined network, where hardware platform provides *primitives* and the software leverages the primitives to implement specific functionalities or meet security requirements.

* **Reduce the cost of building TEE**: Keystone aims to reduce the cost of building TEE or TEE-based systems. We achieve this by reusing the implementation across multiple different platforms, reducing hardware integration cost, reducing verification cost, and integrating with existing software tools. We hope that anyone can simply extend Keystone to build their own novel TEE design with very low cost.


## Status

Keystone started as an academic project that helps researchers to build and test their ideas.
Now, Keystone is an **Incubation Stage** open-source project of the Confidential Computing Consortium (CCC) under the Linux Foundation.

Keystone has helped many researchers focus on their creative ideas instead of building TEE by themselves from scratch.
This resulted in many innovative research projects and publications, which have been pushing the technical advancement of TEEs.

We are currently trying to make Keystone production-ready. You can find the latest general roadmap of Keystone [here](https://docs.google.com/document/d/1E-982564GvOcWzdCqM7TXCJV_7uWy2F8NiwglWorjFA/edit#heading=h.xa3pe84ubay4)

Here are some ongoing and/or planned efforts towards the goal:

* **Technical Improvements**: Make Keystone more usable and on par with existing industry solutions, including memory isolation improvement, better application and hardware support, and additional features.

* **Parity with Industry Standards**: Make Keystone follow the industry standard. This includes standard cryptography, measured boot, and remote attestation protocols.

* **Hardware Integration**: Partner with RISC-V hardware designer/vendor to fully integrate with the hardware. This includes integration with hardware root-of-trust, memory encryption engine, and crypto accelerators.

## Documentation

See [docs](http://docs.keystone-enclave.org) for getting started.

# Contributing
## Hardware Support

Keystone requires a standard RISC-V platform with a *hardware root of trust* --- including secure key storage and measured boot. Currently, no hardware root of trust has been designed or manufactured specifically for Keystone. If you have a open-source root-of-trust we'd love to integrate with it!

As this project focuses more on the software stack and the toolchain, you can still run the full Keystone software stack on top of a few RISC-V platforms without a real root-of-trust. See https://github.com/keystone-enclave/keystone/tree/master/sm/plat for the supported platforms. In general, `generic` should work with most of the standard RISC-V cores as long as they support:

- RV64 with SV39 addressing mode (or RV32 with SV32)
- M/S/U privilege modes
- More than 4 PMP registers

For full security, platform architect needs to provide the followings

- Entropy source (and ideally a platform specific random number generator)
- Measured boot
- Secure on-chip key storage

Keystone doesn’t provide high-performance hardware-based memory encryption, as it requires a proprietary memory controller. Instead, it provides an example software-based encryption, which uses scratchpad SRAM (if any) to encrypt physical pages.

## Team

Contributors

- Gregor Haas
- Evgeny Pobachienko
- Jakob Sorensen
- David Kholbrenner
- Alex Thomas
- Cathy Lu
- Gui Andrade
- Kevin Chen
- Stephan Kaminsky
- Dayeol Lee (Maintainer)

Advisors

- David Kohlbrenner @ UW
- Shweta Shinde @ ETH Zurich
- Krste Asanovic @ UCB
- Dawn Song @ UCB

## License

Keystone is under BSD-3.

## Contributing

See CONTRIBUTING.md

# Citation
## Citation

If you want to cite the project, please use the following bibtex:

Expand Down

0 comments on commit 0f8b751

Please sign in to comment.