Innovating with BOLOS : building an Ethereum Hardware Wallet

03/08/2016 | Blog posts

We might have started the wrong Ðapp. Oopsie.

In our previous article we introduced BOLOS : a platform to innovate around the edges of Personal Security Devices, making sure that your private data stays protected when using embedded third party applications. We’ll have a look today at an interesting example from the point of view of an Hardware Wallet designer : how to enhance the security of a significantly different blockchain, Ethereum.

This is of course in no way an investment advice — just a nice use case which is complex enough to make it hard to implement on a legacy Hardware Wallet, yet simple enough to use it as a BOLOS API training. Also we’re still large Ethereum newbies, so expect gross oversimplifications and a few mistakes. The cryptographic and protocol parts should make sense though.

An Ethereum primer for Bitcoin Hardware Wallet developers

On the easy side, Ethereum user accounts (Externally Owned Accounts) rely on transactions that are more simple than Bitcoin transactions (as the system maintains a state and balance, no inputs are involved) and use the same secp256k1 ECDSA signature scheme than Bitcoin. However the hash algorithm and transaction encoding used are slightly different. Ethereum also handles contract accounts which are managed directly by code and therefore out of scope of Hardware Wallet security as the state of the network guarantees that their execution is consistent.

The hash algorithm used is the pre-release version of SHA-3, Keccak-256 — this can be a bit confusing for newcomers as SHA-3 is released now, and it is quite important to use the right version of the algorithm as it is also used to generate Ethereum addresses, which have no checksum. It is fairly easy to add if your compiler supports 64 bits arithmetic for your platform.

Ethereum also doesn’t include information about the sender account in the transaction — the public key is recovered from the signature. This can be done by iterating on the 4 possible candidates on the client side if the Hardware Wallet API doesn’t support it (which is temporarily the case for BOLOS, because that specific functionality isn’t exposed) but it is more efficient to send back this information along with the signature if possible (e.g. as done in Fast_Sign_Verify).

Transactions include the following fields and are serialized using a proprietary algorithm named Recursive Length Prefix

Validation logic of an ETH transaction on the Trusted UI

We implemented that validation logic as a simple BOLOS application that let the user verify what is signed on the Trusted UI.

The key used to identify an account is a Keccak-256 hash of an uncompressed secp256k1 public key. Wallets can use an arbitrary Hierarchical Deterministic derivation scheme to support several accounts (for example Jaxx supports SLIP 44 with Coin Type 60). As the standard keys encoding doesn’t include a checksum, wallets can also support the ICAP format, derived from the banking IBAN format, which adds one.

We implemented the address generation from a Hierarchical Deterministic wallet along with an ICAP representation of the address in another BOLOS application

Generating and displaying an ETH address on the Trusted UI

Trying this at home

You can start playing with BOLOS API on a Trusted Execution Environment today with the following requirements:

The options menu of Ledger Bootstrap, a mandatory stop to enable developer mode before purchasing

If you are interested in a finalized version of Ethereum support, we will add TEE support to Jaxx shortly.
Our next articles will describe how to write similar applications for Ledger Blue, available for developers this month

BOLOS series

<< Previous article: introduction to BOLOS
>> Next article : dynamic secure applications with BOLOS and Leger Blue