Dynamic secure applications with BOLOS and Ledger Blue : a use case with Ethereum and The DAO

We gave you a quick primer on Ethereum transactions earlier with a TEE application, today we’ll see how this model fits well into dynamic secure applications that can be loaded and removed on demand for specific purposes, offering an efficient way to validate an otherwise complex process.

Ethereum transactions and smart contracts

Inputs passed to a smart contract are provided as an additional “Data” field in an Ethereum transaction — the encoding of that field is contract specific. It can be seen as a function call containing parameters encoded following Ethereum Contract ABI.

Those parameters cannot be decoded without knowing what the contract is about, and can have of course very different meaning and impact for the user. Therefore, they cannot be signed blindly by a Hardware Wallet.

For this reason, we developed our Ethereum application for Ledger Blue as a parsing framework that can be included in other applications, and reject all transactions containing this “Data” field in the default wallet.

The DAO smart contract

The DAO made the news as the most popular crowdfunding campaign — it can be seen as a Smart Contract on the Ethereum blockchain allowing users to vote and invest in specific proposals which are self managed.

Users stake in the DAO is modeled by tokens bound to the Ethereum address that invested in the DAO. At some point, those tokens can be used to vote on proposals, or transferred to someone else (bound to a different Ethereum address). This is accomplished by calling the “transfer” function of The DAO contract.

When reviewing the contract, you can also notice that all tokens belonging to an account are locked when this account is used to vote on a proposal — therefore, it can make sense for a user to have several accounts in order to vote for several proposals or keep more options open while voting.

This leads to an interesting user experience problem where Hardware Wallets are useful — it would be great to only authorize Token Transfers to an account belonging to the user when desired, without having to check that the destination address is correct, leveraging on the Hierarchical Deterministic Wallets organization.

Implementing a Token Transfer application

We’ll review the main differences between the generic wallet code and the Token Transfer application to see how easy it is to implement this use case using BOLOS.

All the following screenshots are a diff between the generic Ethereum HW code and the Token Transfer application.

A new APDU instruction, INS_ADD_SELF is added. This APDU will be used to provide the destination address as a BIP 32 path so it can be enforced as being generated from the same seed.

To display the amount of tokens exchanged, we use the official conversion rate of DAO tokens to Wei which is 10¹⁶ rather than 10¹⁸ for Ether.

A new structure is created to hold the data parameters of the transaction. It will contain the “to” and “value” parameters of the transfer function call.

DAO_ADDRESS is the official contract address, used to enforce that the transaction is going to the right contract.

DAO_TRANSFER_ID is used to enforce that data point to the proper DAO function. This can be checked by computing the SHA-3 hash of “transfer(address,uint256)” as specified in Electrum Contract ABI.

The new customProcessor function copies the data field into the new structure rather than ignoring it. It is modeled after the generic methods implemented by the parser.

Then the new INS_ADD_SELF APDU logic is implemented, converting the provided BIP 32 user path into an address that will be checked against the destination of the transfer.

After parsing the data field, the transaction parameters are checked (destination address, contract function ID) and the Hardware Wallet makes sure that no additional Ether amount is sent to the contract.
If the destination address matches the BIP 32 path provided by the user, “Self” is displayed rather than the address — otherwise the address is displayed for validation.

The validation reuses the same core logic as the generic wallet with the following changes:

• The value displayed is the second parameter of the contract call, instead of using the “Value” field of the transaction
• The address displayed is the first parameter of the contract call, instead of using the “To” field of the transaction

The user can then approve a message which is quick clear to understand, without any risks.

We believe dynamic secure applications are a critical asset for Hardware Wallets to adapt quickly to new crypto systems and offer the best user experience — just upload an application you pre-approved (or that was pre-approved by the community) to perform a specific action, and you’re good to go.

BOLOS series

<< Previous article: building an Ethereum Hardware Wallet
>> Next article: Splitting your Ethers securely on your Nano S