Notice: MesaTEE is constantly evolving and designed to demonstrate types of functionality, not necessarily 100% matching this design description.
MesaTEE is the acronym from “Memory Safe (Mesa) Trusted Execution Environment (TEE)”. It favors memory safe programming languages (e.g. Rust) and inherits the design philosophy from TEEs like Intel SGX and ARM TrustZone: isolation and attestable integrity protection. However the full MesaTEE stack has more to offer than a TEE design. Figure 1 demonstrates the high-level layered architecture of our MesaTEE stack.
Function-as-a-Service (FaaS) computing model allows developers to concentrate on the core event-driven processing logic, without having to worry about the underlying frameworks and infrastructures. This decoupling dramatically shortens the development cycle, makes scaling much easier, and enables more fine-grained execution metering.
In MesaTEE stack, FaaS is made possible by combining the unified, secure, yet enriched API interface, as well as the carefully tailored secure event service workflow.
Programs written in memory unsafe languages are prone to memory bugs like buffer overflow, double free, use after free, etc. Formal verification helps to alleviate this problem but the cost is huge -- neither scalable nor sustainable. Rewriting everything in memory safe languages like Rust and Go is promising, but the higher engineering effort can be a tradeoff.
To provide strong security guarantees using balanced approach, MesaTEE stack is adopting Hybrid Memory Safety: top critical system components like operating system core utils, secure communication libraries (e.g. TLS library), authentication interfaces, etc. are rewritten in Rust and Go; important but less changed C/C++ libraries are formally verified to ensure memory safety; other components not been rewritten/verified are isolated in sandbox container. In general, the overall system must obey the following rules-of-thumb to ensure the safety.
As shown in the Figure 1, in order to realize universal secure computing, the MesaTEE stack supports various TEE platforms, including Intel SGX, AMD SEV, ARM TrustZone, etc. To unify the capabilities on these platforms, a pack of TEE low-level libraries are developed. The core of such libraries is the Standard Library (STD), which is independent of the specific TEE platform; other low-level libraries are also provided to enrich the supported functionalities. This layer of libraries is also called the “enabling layer”, where TEE platforms’ capabilities can be largely exposed. However since this layer is close to bare metal, MesaTEE does not guarantee the stability of APIs in this layer. Moreover, because this layer does not differentiate trusted/untrusted APIs by considering whether they cross the TEE boundary, MesaTEE does not encourage developers to directly call APIs in this layer.
Based on this Low-level Libraries layer, a stable Abstraction Layer is provided. This layer also has a strict differentiation for trusted/untrusted APIs -- if developers stick to trusted APIs, the underneath logic can be guaranteed to execute within the TEE boundary, so developers do not have to worry about implicit data leakages. MesaTEE does expose other untrusted APIs for functionality corner cases, however they are well labelled (e.g. open v.s. untrusted_open) to match developers’ intention.
Although the Abstraction Layer APIs are stable and convenient, we also have TEE platform independent APIs (common APIs) and TEE platform dependent APIs (platform specific APIs) available for specific needs. To ease the development, MesaTEE further provides the TEE Foundation Layer, by wrapping up the APIs into turing-complete interpreters. For example, memory safe WASM interpreter is provided to support WebAssembly execution, and memory safe Python interpreter (MesaPy) is also included to support Python script execution. With the help of this Foundation Layer, developers can enjoy the confidentiality and integrity benefits of TEE, while still writing versatile codes with agility.
Targeting at redefining AI and big data analytics, MesaTEE stack utilizes the TEE Abstraction and Foundation capabilities to build popular ML algorithms and data processing services. To name a few:
MesaTEE stack also provides secure end-to-end communication channels into the TEE environment. This includes both TEE-to-TEE as well as external-to-TEE communications. Unlike traditional TLS communication channels, MesaTEE secure channels combine certificate based attestation with TEE remote attestation, so that clients are able to not only know which nodes they are talking to, but also ensure the integrity of the remote executing entities.
As shown in Figure 2, in traditional TLS settings, client verifies the endpoint certificate up against to the root certificate authority (Root CA), and validates it according to certificate revocation list (CRL) or through the online certificate status protocol (OCSP). In MesaTEE, client performs remote attestation of the target platform, and finishes trust establishment as well as key exchange at the same time.
Different application scenarios may require different security promises; data in processing may also have various clearance levels. To answer for these different levels of situations, MesaTEE stack can be configured to five different security levels, and is able to be further tailored at finer granularity in architecture, as shown in Figure 3.
The five security levels are: