We are excited to introduce a new quick prototyping architecture for Blockchain security applications, offering hardware security features on Intel Skylake Core CPUs (and above).
There has been some significant noise and doubts raised about those enclave architectures, so this post will provide technical details about how our architecture tries to come up with practical solutions for possible concerns — this is mostly intended for interested developers who want to low level read code. It will be followed by some actual action (integration with live wallets) will happen in the coming weeks.
Enclaves overview
Enclaves are an exciting branch of Trusted Execution Environments where a general purpose chip (typically the main application processor of the system) offers a hardware isolation solution to execute critical code fragments protected from any other system component interference. They are essentially used to protect this critical code against malware attacks.
On Intel, this implementation is called Software Guard eXtensions. A free SDK for Linux or Windows and resources are offered to let developers create their own applications, but running a production (non debuggable) application requires Intel authorization.
We’re providing the full source code of the enclave under the Apache license to let developers verify that the deterministically built binary code matches that authorization — and also let you test your own modifications in debug mode, which we can merge later.
Overall the architecture is a new mapping of our previously described BOLOS TEE
Small but flexible Trusted Computing Base
Having a small code base is essential to make the audit process easier. We picked our third party code from a short list of already well audited or simple libraries — cryptographic libraries have been specifically selected for their focus on protection against passive monitoring attacks
- libsecp256k1 for Elliptic Curve cryptography over secp256k1
- micro-ecc for Elliptic Curve cryptography over secp256r1
- ctaes for AES encryption
- libsodium for high level authenticated encryption primitives
Flexibility is granted by a Moxie CPU emulator executing signed scripts as interpreted C code, which also allows to create independent attestations which can be verified without calling a third party.
The glue code linking all those pieces together is also conveniently small to audit.
Limiting third party trust
Third party trust is usually a critical part in an enclave design — while you always have to trust the chip manufacturer regarding the enclave implementation, you can try to limit what a misbehaving manufacturer or issuer could do.
The only mandatory SGX trusted components used by this enclave are the isolation mechanism itself, the RDRAND instruction if generating random from the enclave, and the principle that Intel doesn’t know the unique key used by each individual CPU to wrap secrets.
Attestation that the enclave is genuine provided as an opaque service by Intel is not mandatory — a developer can leverage application level attestation by compiling the enclave and installing it in a trusted environment (for example using a live OS for the enclave personalization). When used, it is only done once to link the enclave attestation to a Ledger certificate, which can be used to verify the authenticity of all running scripts inside the enclave.
Trust in Ledger is also limited to the optional attestation mechanism itself. Ledger signing key doesn’t grant us any specific authorization other than being whitelisted to disable debugging as all secret material is bound to an enclave policy (MRENCLAVE) rather than a signer policy (MRSIGNER), protecting against rogue signed updates.
Dealing with no trusted display
Not having a trusted display is an issue for typical user oriented hardware wallets — while this might be supported in a standard way by the different enclave technologies later, it can be worked around with an alternative device used as secondary display with a cryptographic pairing to the enclave (just like we did with our original Ledger Nano).
The flexible scripting system can also let you define your own rules (whitelisted addresses, sending quotas and so on), for user wallets or server/cloud based wallets.
Free for the community, with no strings attached
This solution is provided for free for any interested party, with scripting certificates created by Ledger to run your own scripts on a specific computer.
We’re also offering a commercial version of the enclave with additional isolation mechanisms (ongoing a certification process), support for more cryptocurrencies and management schemes, and professional support.
More information and samples will be released in the coming weeks, in the meantime you’re welcome to ask us questions on #enclave on our Developer Slack, and review the code on https://github.com/ledgerhq/bolos-enclave
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.