Attestation redux : proving code execution on the Ledger platform

In a previous article we showed how the ability of Secure Elements to hold secrets set at manufacturing could be used to prove the authenticity of the platform and make sure it was not altered.
We’ll now see how this can be leveraged on our new platform to prove to a remote party than a given code is executing on a genuine Ledger device, enabling innovative solutions, for example regarding the scalability of payment channels, such as a Teechan implementation.

Ledger application model

Our architecture uses ARM isolation to load and delete native Position Independent Code on the platform. Each application is isolated from each other and from the Operating System, offering different services to communicate with the outside world and perform cryptographic operations on user data. A privileged application, the Dashboard, let users pick the application to run. Before running it, the Operating System sets up the MMU to restrict the accessible flash to the application space. For more details on this architecture, you can refer to a previous article.

The Operating System attestation scheme

The Operating System attestation scheme can be used to verify that the device is genuine by proving that it owns a private key signed at Ledger factory.
During the manufacturing process, the device creates a keypair on the secp256k1 curve (Device keypair). The public key is signed by an issuer key on our HSM, and the generated certificate (Issuer certificate) is stored on the device.

During the standard device lifecycle, a Secure Channel can be established to the device to exchange secrets or prove the ownership of the key signed by the certificate. During the Secure Channel establishment, the device generates an ephemeral keypair on the secp256k1 curve, returns the ephemeral public key, its signature by the previously generated Device private key, and the Issuer Certificate. The remote party can verify that the public key belongs to a genuine device, and generate a session secret with an ECDH key exchange over an ephemeral keypair using this public key.

This attestation scheme is only available from the Dashboard and the Device keypair is not usable by the applications.

The applications attestation scheme

The applications attestation scheme is based on specific cryptographic primitives available as a system call to the application for two different attestation keys with different roles (Attestation #1 and Attestation #2). Those cryptographic primitives combine an application request with the running code hash, which is known by the Operating System before starting the application. Applications can only call those primitives and do not have access to the attestation private keys.
The attestation keys are not created by default — they can be generated on demand and associated to any Owner certificate (which can be Ledger if desired). When creating an attestation key, the device generates an Attestation keypair on the secp256k1 curve and provides the public Attestation key, its signature by the previously generated Device private key, and the Issuer Certificate. The Owner can check the public key signature and return a certificate, which is stored by the device.
The attestation keys can be created for a test setup using the setupEndorsement Python script

Attestation key #1 offers a primitive to generate an application secret based on the running application hash and the generated private key (os_endorsement_key1_get_app_secret) , as well as a primitive to sign an application message concatenated with the running application hash by the Attestation key #1 (os_endorsement_key1_sign_data). This signature can be verified by the verifyEndorsement1 Python script
Attestation key #2 offers a primitive to sign an application message using a private key derived by Attestation key #2 and the running application hash (os_endorsement_key2_derive_sign_data). This signature can be verified by the verifyEndorsement2 Python script
Applications can also retrieve their own hash (os_endorsement_get_code_hash), an Attestation public key (os_endorsement_get_public_key) and the associated certificate (os_endorsement_get_public_key_certificate)

A simple use case : secure private key transfer

A private key transfer application illustrates how the attestation mechanism can be used to exchange a private key between two users and making sure that the owner cannot keep a copy of the private key, using an Open Source application auditable by all parties.
The application creates a keypair, can return a public key to the user. It can also transfer the private key to another application instance having the same hash and the same Owner, and erase its own copy before doing so, as well as sign a message using the private key, but doing so prevents the key from being transferred
To make the secure transfer possible, a Secure Channel is established between both applications using an ECDH key exchange. Each party sends its ephemeral public key along with its signature by Attestation key #1 (which combines the application hash, sealing the commitment to the application behavior) and the Owner certificate of Attestation key #1. The signature of each public key is verified by the other party before establishing the channel, erasing then encrypting the key for the sending party, and storing the key for the receiving party.
The source code of this application is available on https://github.com/LedgerHQ/blue-app-otherdime

Privacy and trust implications

Having per device keys can easily turn the feature into a “super cookie” to track the users. To work around this problem for the OS attestation, the attestation primitives are only available from the Dashboard and require a user confirmation to establish a session. For the applications attestation, the keys creation and selecting Ledger as the Owner is opt-in. Users can then verify which applications use the attestation feature by reviewing their source code.
Using the application attestation feature means that you trust Ledger regarding at least the applications isolation, the Operating System key management and the Owner certificate issuance if you choose to use Ledger as Owner. In all cases you have to trust the Owner to only issue certificates to genuine devices.
We’ll also be busy performing third party audits of the solution and opening more parts of the Operating System in 2017 making it easier for the users to gain confidence in the overall security of the platform.
This application attestation scheme is available on all new generation Ledger products (Ledger Trustlet, Nano S, Blue, HSM, SGX) with some restrictions regarding the Owner selection and available attestation primitives depending on the platform.

Acknowledgements

Razvan Dragomirescu for the Othercoin project describing a similar private key exchange scheme.
Gregory Maxwell for suggesting the attestation key primitives.

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.