Secure by design: Rust and Runtime Encryption

At Fortanix, we are big proponents of deterministic security. Designing in security from the get-go by using secure programming principles is a big part of that. It’s way too easy to accidentally introduce bugs in C programs, often with far-reaching consequences. Parts of the C language have been called a “billion-dollar mistake”.

Yet, people keep using C for their most security-critical applications, such as Operating Systems kernels and cryptography.

Rust

Luckily, there is no longer a need to write new programs in C. At Fortanix, we use Rust a lot. Rust is a modern language with advanced static analysis tools built into the compiler. Rust is low-level in that allows you to write any code C would allow you to, including device drivers, dynamic linkers, and bootloaders.

On the other hand, it’s also high-level and therefore much easier to use than C for writing parallel programs, web applications, and even web frontends. Rust’s built-in static analysis makes fine work for common software bugs such as dangling pointers, type confusion, and buffer overflows.

Runtime Encryption®

Many layers of a computer’s software stack are inherently insecure. What if your application could make use of that stack without exposing itself to its vulnerabilities? With Runtime Encryption®, you no longer depend on the hierarchical nature of contemporary computer security.

Through advanced process isolation techniques, your data in your application stays safe even if the underlying OS or hypervisor is compromised.

Fortanix is building a new category of solutions called Runtime Encryption®. Just like encryption today protects data at rest and data during motion, Runtime Encryption® protects applications and data during use from external and internal threats.

Even with the protection of Runtime Encryption®, you still need to develop your application responsibly and securely.

Download Now: Runtime Encryption Platform Techbrief

Rust and Intel® SGX

The Rust language and compiler make remote code execution and information leakage vulnerabilities virtually impossible. Therefore, we use Rust in conjunction with our Runtime Encryption® platform based on Intel® SGX to create a variety of secure applications.

A prime example of this is our Fortanix DSM™, a fully self-contained secure Key Management and HSM solution running in a secure enclave. Because the server’s TLS private key is secured within the enclave, a client can be assured that it’s talking to a secure backend.

A root user or the OS will not be able to steal that private key and impersonate the application server. 

Rust 2018

Rust is the best way to use SGX. In the future, Rust will also be the easiest way to use SGX! 2017 brought the web to the Rust compiler in the form of WebAssembly. In 2018, Fortanix will bring Runtime Encryption® to the Rust compiler in the form of the SGX target!

Writing an application using Runtime Encryption® should be as easy as writing any other Rust program. One end goal of this effort is that developing an SGX-based microservice is going to be as simple as:

rustup target add x86_64-fortanix-unknown-sgx
cargo new sgx_microservice
# follow tutorial at https://rocket.rs/
cargo run --target x86_64-fortanix-unknown-sgx

And that’s it! You’ll of course be able to easily access SGX’s trust primitives, and you’ll be able to use most of the crates you already know and love.

Also Read: Trust in Rust

Making Rust even better

We are also looking forward to upcoming changes in the Rust language itself that will significantly improve our codebase.

We use a lot of fixed-size buffers in cryptography and while interacting with lower-level primitives. Const generics would make working with arrays much, much, more convenient.

Our web applications use various serialization formats including JSON, CBOR and XML. We’d very much like to use specialization in order to serialize the same type in different ways across different formats, in order to match the standards, we implement.

Rust’s take on error handling is absolutely terrific. However, we’d love for there to be even more ergonomics improvements. For example, our top-level error definition is a quick_error enum with more than 100 variants. The failurecrate seems like a step in the right direction, but I’m sure more can be done.

With regards to tooling, we’d love to see improved Cargo dependency resolution and features. In particular the feature system seems too limiting, being able to express only additive features. This leads to hacks using #[cfg()]attributes and compile_error!.

There need to be facilities for making dependency-tree wide decisions such as default allocator, logging backend, and default random number generator. Additionally, the sets of normal, build and test dependencies should be resolved completely disjointly (except for unit tests of course), including determining features.

While we hope we’ll see these improvements this year, rest assured that Rust will be a big part of our security story regardless. 2018 should be a very exciting year for Rust, Runtime Encryption® and Fortanix!