Secure Hardware and Open Source

A few weeks ago Yubico published an interesting piece on their security architecture illustrating conflicts between Open Source and Secure Hardware. While we agree on the most important points raised in this article (basically that Secure Elements are a critical part of a security architecture to provide protection against physical attacks and device interdiction), we’d like to offer our perspective on how we’re trying to improve the status quo.

Secure Hardware and Open Source: state of the art today

The state of the art today when considering interaction with a Secure Element is rather poor: open applications live as non native code on an island in a sea of proprietary code with undefined boundaries.

The industry standard for this interpreted code is Java Card — which offers an extremely limited version of the Java platform (no String support, poor dynamic memory management …).

On the plus side, the smartcard industry put a lot of effort over the past decades to design isolation layers in the GlobalPlatform standard, even going to partial formal proofs, making sure that applications can’t interfere with each others and that a product can keep existing certifications when third party applications are installed post issuance using the Composition Model. So even if it’s a quite limited model for Open Source application developers, most recent Java Card products should be able to offer these features one way or another.

If you want to experiment with those technologies, we’d recommend getting a Yubikey Neo through Fidesmo, and open a free developer account to upload and install your own applications. You’ll even be able to verify that the uploaded code has not been modified along the way by using the “encryptedLoad” parameter of the “Install application to card” service. You can also check Martin Paljak’s Applet Playground if you need some examples.

Still, let’s walk down history lane a little bit.

Java Card: how did we get there

In the late 90s the secure microcontrollers ecosystem was quite messy — most products were based on proprietary or customized 80×51 microcontrollers, with no memory isolation logic and proprietary toolchains. At the same time, there was a strong demand to upgrade secure products post issuance (typically in the banking and telecom markets, where SIM cards were used by the telecom operators to offer value added services to the users through SIM Toolkit APIs on phones that didn’t quite offer the flexibility of the typical modern smartphone)

A very limited Virtual Machine allowing applications to run on completely different hardware was quite appealing at that time — thus Java Card was born, and didn’t change that much since its inception. Many standards grew around it, and Java Card kept its appeal for certification purposes — as the process is quite long and costly, being able to run the same application on all Java Card compatible Secure Elements with a single code certification still makes complete sense today.

For developers however, Java Card can be quite annoying for multiple reasons:

• The native (typically cryptographic) APIs are exposed in ways that can be too restrictive (for example you can’t use a specific “nonce” for ECDSA signatures, which makes it impossible to create deterministic signatures on most Java Card implementations)
• The lack of unsigned types (thanks to Java) together with optional support of int32 in early Java Card implementations can create some headaches
• Overall the availability of Open Source code for Java Card is not that great, while it is possible to find multiple C Open Source libraries for modern cryptographic use cases that do not necessarily require strong cryptographic security, such as X509 certificates parsing.

Also during those decades, the mobile landscape and cryptographic needs of the end users changed quite a bit.

ARM, powering the mobile revolution

ARM became the major vendor of mobile SoCs by providing powerful and low power chips IP that multiple vendors could implement and improve while building on strong common layers in the early 2000s. This boosted innovation and Open Source development in the mobile space.

A little known fact is that ARM did exactly the same thing in the Secure Element ecosystem with the SecureCore IP, which are hardened Cortex M0/M3 MCUs offered by most Secure Element vendors today.

Secure Elements therefore inherited almost overnight the rich Open Source development ecosystem of the mobile industry and standard hardware isolation features offered by ARM cores.

Can we put those to good use ?

Designing modern, open secure devices

Thanks to modern chips and Open Source toolchains, we can reverse our initial model and relegate the proprietary parts on their own private island:

By using hardware memory isolation, we get rid of the Virtual Machine and allow native user applications that cannot interfere with the remaining parts of the architecture. Most of those parts can be open, and the other proprietary parts covered by NDAs or offered as binary code by third parties can be isolated.

We can make sure that those proprietary parts don’t introduce software backdoors by implementing an additional applicative firewall on a non secure microcontroller communicating with the Secure Element, don’t provide covert channels by using deterministic cryptographic operations, and don’t store secrets permanently in the flash memory when they shouldn’t by monitoring the chip power consumption.

By relying on this architecture, the Secure Element is at the center of the design and the initiator of all exchanges. Ultimately the non secure microcontroller is just a dumb router executing commands on behalf of the Secure Element.

We’re using this design for the BOLOS implementation on Ledger Blue, and while this is quite a new way to design Secure Element operating systems, we believe that the extra openness combined with the physical security provided by Secure Elements is worth the extra certification effort.
Also, it can still be used to implement more secure Virtual Machines, so we can even be best friend forever with Java Card.

BOLOS brings a powerful and flexible alternative to Java Card, enabling Open Source on Secure Hardware in a way not possible before. With this technology, Ledger aims to breathe new life in the security industry and unleash a new generation of embedded secure applications.

About the Author
Nicolas Bacca is Co-Founder and CTO of Ledger.

He is a Computer Science Engineer specialized in smartcard technologies, fascinated about efficient coding. After 5 years at Oberthur Technologies developping mobile solutions and as head of the “Cards & solutions Innovation” team, he founded Simulity of which he was CTO and lead architect, and then Ubinity of which he is CEO. He has been developing there many projects and solutions, including OS for smartcards, and software & hardware “Secure Element” solutions. Then he has created BTChip, first smartcard based security solution dedicated to Bitcoin, and has co-founded the Ledger startup.