16th of June - Under the Weather

Just wanted to let everyone know that I’m still here. But for past two weeks I have made almost zero progress. :( I’ve managed to catch something and whenever I’m home from work, resting has been getting a higher priority than coding.

I seriously hope this thing will blow over soon and I can start showing progress again.

A small question: Would it be possible to create a seperate bootloader for "monezor" so that it recognises your firmware? This is why I ask: Black Arrow released a Trezor copy (eWallet) and they offer the devices without bootloader if requested by the costumer. I think it would be great to have a signed firmware running on a device.

And about the fact that it's a trezor ripp-off: yeah, that's true, but you are basically rewriting the firmware, so I don't see any harm in using the eWallet for Monezor.

Thoughts?

31st of May - Communicating with Trezor

Last week has been pretty crazy. I managed to launch my other Monero related project (CryptoName) on Tuesday and then accepted a full-time job on Thursday. Time commitment wise there will be no changes for this project, 10h/week should still be doable.

I now have a pretty good idea how I want to approach developing Monezor. The short version of the plan is as follows:

• Reorganise trezor-mcu project, removing Bitcoin crypto code and changing the protobuf communication API to suite Monezor.
• Port over Monero crypto to Trezor.
• Implement actual Monezor features: wallet generation, PIN protection, key image generation, mnemonic seed displaying/restoring.
• Library for communicating with Monezor (which will also be used by the wallet app later on).

I’ve created a little tool for myself to communicate with Trezor and will use that to verify that Monezor works when I'm doing the firmware changes. This tool will later be refactored into the library that anyone can use.

24th of May - Navigating the Trezor codebase

I have been studying the Trezor code in detail. It has become clear that the right course of action for our project is to throw out most of the Bitcoin related functionality and create a “Monezor”. Basically a completely different firmware specialised for Monero. All of the low-level USB, proto-buf RPC and UI code can be reused.

I have been trying to come up with some sort of a plan on how to approach this. But progress has been slow on that front sadly. Ideally I’d like to include only really basic functionality (ie authorising payments), but there are a lot of “extra” functionality that is implicitly required to be implemented: generating a new wallet, recovering a wallet, etc.

Hopefully by next time I have come up with the concept of what I want the device usage to be like and started reorganising trezor-mcu code for our needs. If you have any suggestions for the name of the Trezor-specialized-for-Monero project, let me know. Otherwise I’ll just go with Monezor.

11th of May - Intimate weekend with crypto

Past weeks I’ve been prototyping things in Go, to see if it would be feasible to implement the PC side wallet application in Go. I had already got serialization and deserialization of various Monero data types working. This weekend I spent porting Moneros crypto functions to Go.

Though the work I’ve done did stop being a prototype and started resembling a real library a long time ago, but now all of the basic things to interact with Monero are there: binary serialization, portable storage binary serialisation and cryptographic functionality.

The code lives on Github and I will be basing future developments on that, instead of trying to refactor simplewallet into something usable for this project.

Next, I’ll (finally) start hacking away at Trezor’s code.

2nd of May - Trezor has arrived!

Just a quick update. On the PC side, still working on the prototyping the required functionality in Go.

The Trezor rottenchris sent, has arrived! I’ve tested out compiling the official firmware and installing it with non-SatoshiLab signatures. Minor annoyance with custom firmwares (like the one I’ll be making) is that Trezor prompts the user on every startup if they want to continue with the potentially unsafe firmware.

That’s it for now. Hopefully next time I’ll have a Go prototype which can sign and verify ring signatures and communicate with monerod using binary serialisation formats.

21st of April - Trezor on it’s way!

Christoph (rottenchris) has mailed me one of his spare Trezors - thank you very much! I’ll be flying to Estonia for a week tomorrow. Unless the package reaches me today, I won’t be able to play around with it until I’m back.

Progress This Week

I spent the better part of last week getting to know Monero wallet better: how it works behind the scenes, what is the code like, etc.

What I learned is that view key can only be used to detect outputs in a transaction which belong to the account. It cannot be used to detect when said output was spent.

The way simplewallet detects outgoing payments is by generating a key image for each of the transaction outputs belonging to the account and monitors the blockchain for usage of that key image. The only way to generate such key image is to have access to the private spend key.

Having Trezor generate key images for each of those outputs would defeat the purpose of a hardware security module. Having access to those key images means it is possible to spend that output.

See my notes below on outgoing payment detection for more information about this.

To get spend detection working for Monero I need to extend the public Trezor communication protocol with Monero specific features. This will decrease the chance of this work getting merged back upstream into official Trezor firmware.

After I’ve played around with the Trezor I’ll know more or less what kind of changes I need to do in the firmware. If they are fairly extensive, then it will make more sense to have Monero specific alternative firmware for Trezor.

Adding Trezor support directly to simplewallet would unnecessarily complicate usage of that tool and it would definitely not be a simplewallet anymore. I think the best option is to create a separate wallet tool for Trezor, dealing with just payments (no RPC for instance).

To do that I have three options:

1. The easiest would be to copy-paste most of the existing wallet code into a new directory, make changes to add Trezor support and delete code (RPC, etc) that isn’t useful for the new tool. I don’t see such code being merged into Monero upstream nor anybody wanting to maintain this hack in the future. So this option isn’t really an option.
2. The better option would be to refactor the existing wallet code extensively, in a way that would make it to be possible to build a second wallet utility with Trezor support on top it. It would be a fairly big undertaking with a lot of swearing involved and a chance of breaking existing simplewallet functionality.
3. Or implement the Trezor wallet in Go, from scratch. This would probably take slightly more time, but it wouldn’t break any existing functionality nor would it have to be merged upstream. It would also mean in the future there would be solid building blocks for people wanting to build something on top of Monero using Go.

Out of the three options I prefer the last one as it would mean less swearing and more fun. I’ve started prototyping various required functionality (encoding/decoding Monero binary formats, generation & verification of ring signatures) to see if they can be implemented using the Go standard library & existing 3rd party libraries already out there.

Plan for Next Week

I am going to continue prototyping the Go wallet implementation idea. I will also be taking a more in depth look at trezor-mcu source code to get a better idea about how I would approach adding Monero support there.

Notes

Outgoing Payment Detection

View key only allows us to detect incoming payments for the address. So far I haven’t found a way to detect with view key if the key image was generated by the spend key holder.

That means detecting when the user has spent some of their money is tricky. The official wallet uses spend key to generate key images for each of the incoming payments. Then it compares those with all key images in the blockchain to see if it has been spent. If the spend key is not available this is not an option.

Hashed Key Images

To sign a transaction the user needs to interact with Trezor. We could however, implement a new API in Trezor which would output the hash of the key image. This would allow us to hash all seen key images and see if the users output was spent.

Educated Guessing

We could attempt to guess spend transactions. This would involve checking if all of the inputs in a transactions contain at least one of transaction output we know is ours. If there are change outputs we can be 99% certain this was an outgoing transaction.

There is an edge case which is difficult to detect using this approach: single input and single output, no change outputs. There just isn’t enough information to be 100% certain these outputs were spent by the user.

This also breaks bad when the transaction contains funds from several accounts. Thus the hashed key images would be a more foolproof way to monitor this.