A dedicated hardware wallet for Monero was first proposed in August 2017 and the project has now been set in motion. With the goal of 996 XMR reached (worth around $97,608 at the time of writing) thanks to contributions from 39 individuals, Michael Schloh von Bennewitz will deliver a printed circuit board, which will form the foundation of an independent hardware wallet. Built by the Monero community for the Monero community.
The Forum Funding System (FFS) allows users to donate to projects that they support and think will benefit the Monero ecosystem without having to go down the road of raising funds using the increasingly scrutinized Initial Coin Offerings (as it seems Raiden is doing, the scaling upgrade for Ethereum).
Schloh brings 15 years experience in software and telecommunications to the table, as well as his knowledge and experience from running training sessions at Black Hat and producing hardware in his circuits lab and privacy sensitive software development. His proposal was commended by the community for its transparency, detail and vision, serving as an example for anyone in the future who wants to make an improvement to Monero through the FFS.
With the recent mobile wallet release making it to the Google Play store and an anticipated integration of XMR into Ledger’s hardware wallets (and potentially Trezor in the future), many people may wonder whether there is a need for a hardware wallet dedicated to Monero. The community engaged in a lively discussion of its merits and drawbacks, but the main reason seems to be clear. The hardware wallet companies that exist in the space at present are not fully aligned with the goals and principles of the community.
A unique, exclusive hardware wallet will be a key differentiator for the privacy-oriented cryptocurrency. We will first get a glance of this product at prototype demonstrations at two events (34C3 and FOSDEM) during late 2017/early 2018. By June 2018, the product will be released to alpha testers, while the official release is slated for August in conjunction with Black Hat and DefCon.
To find out more, BTCManager spoke to Michael Schloh von Bennewitz and ‘Anonimal,’ lead developer of Kovri and the man instrumental into bringing Michael’s expertise on board.
- 1 How Did You Both Get Involved with Monero?
- 2 Michael, What Personally Inspired You to Take the Time and Effort to Submit the Proposal?
- 3 Anonimal, Would You say that the Hardware Wallet has a Similar Purpose to Kovri, since it is getting around a Single Point of Failure? (Tor in the case of hiding IP, only a handful of hardware wallet companies to crack?)
- 4 So in the Crypto Space, it is more of a Desired/Scarce Skillset then?
- 5 Why is the Dedicated Hardware Wallet Needed?
- 6 Right, Similar to How Paper Wallets are Vulnerable When Spending or Importing?
- 7 And How is this Achieved?
- 8 Your Proposal States, “a private key in a real (with lock features secure element means that even rogue firmware cannot access the key…” Can You Explain this a bit for the ‘Man in the Street’? So Rogue Firmware can Affect Trezor, KeepKep, Ledger, etc.?
- 9 Right, But You Are Just Identifying an Improvement?
- 10 Michael, Your Proposal is Fully Funded. Once the Project is Complete, There is Much More Work To Do. What will be the Plan following Completion of Your Project?
- 11 How Much Time Have You Put into this Project?
- 12 The Proposal Mentioned a Demonstration at 34C3, the Hacker’s Event in Leipzig, Germany starting December 27, 2017?
- 13 Any Final Thoughts/Comments?
How Did You Both Get Involved with Monero?
Michael: I’m in the Monero thing about three months now, the first time I heard about it was from my Hack Miami buddies. As I cruised the DefCon halls, it came out there were Monero folks on the 21st or 22nd floor, having a meeting. Okay let’s call it for what it was, namely a party. I spoke to quite a few Monero folks then, including anonimal who was very encouraging in getting involved.
Reverse four years to the first Bitcoin conference in San Jose, that’s when I met folks like Gavin, Charlie Shrem, and Mike Hearn. Didn’t really make a lasting impression, but opened the world of cryptocoins to me.
Now, I want to go deeper, and recognize there’s not many who know hardware design. So I’m filling that gap by constructing a bunch of gear, starting with the dedicated hardware wallet.
Anonimal: I first got involved with Monero in the fall of 2015. At that time, I had stumbled upon an abandoned project with a poorly maintained codebase called i2pd. I met fluffypony and, after a few meetings with community contributors (Monero and Java I2P), fluffypony and I forked the project and subsequently created Kovri. I can’t begin to tell you the amount of drama that ensued. It’s an article in itself!
Michael, What Personally Inspired You to Take the Time and Effort to Submit the Proposal?
Michael: My involvement with the Tor project, use of cryptocurrency, development with secure hardware, and dislike of the current financial environment has made me embrace Monero.
Specifically about this hardware wallet project, I was recently doing hardware work with secure elements and want to continue working with them. I also want to stamp Monero’s name on some hardware in order to give Monero a higher profile.
Let’s see if I’m correct that so many people ignore cryptocurrencies until they have a piece of hardware in their hands and start learning to use it. This and other questions or guesses led me to start the project, in order to find out what the answer is.
Anonimal, Would You say that the Hardware Wallet has a Similar Purpose to Kovri, since it is getting around a Single Point of Failure? (Tor in the case of hiding IP, only a handful of hardware wallet companies to crack?)
Anonimal: Yes, absolutely. There are no hardware engineers involved in Monero development that I know of. But I’m certain more will rear their heads as Monero grows. Michael is really an innovator in this area. This is just one reason why I was thrilled to hear about his ideas at DefCon.
Michael: Also, did you know that Anonimal and I share a for data leaking systems? Like anything that by default requires you to deliver parts of your personality or identity is a nightmare for us.
Anonimal: Let’s expand on Michael’s comment on data leakage; that is another pleasure-point for creating this hardware wallet. People can be more involved in the development process and keep an eye out for backdoors and what not.
So in the Crypto Space, it is more of a Desired/Scarce Skillset then?
Michael: The risk is that folks don’t jump on board and do contributions to the hardware design code base.
Anonimal: For me, it’s hard to say but yes I think hardware skillset is scarce in the cryptocurrency community purely by the fact that cryptocurrency is still “young.” But honestly, I’m not an expert in that particular area. For example, rpi and 96boards have reached a massive global audience, and I doubt many of them know more about cryptocurrency. So the interest in hardware tinkering is at least there, in my humble opinion.
Why is the Dedicated Hardware Wallet Needed?
Michael: A hardware wallet is simply a physical appliance that stores cryptocurrency. If software wallets could be trusted to do the job, hardware ones wouldn’t be needed.
Hardware wallets are only really cold when the data cable is unplugged (USB). Imagine a hardware wallet that just does the same thing as the software ones, and get’s its energy from the USB cable. It’s online and hot, as well as being vulnerable. The dedicated Monero wallet tries to mitigate or even completely avoid those two things.
Right, Similar to How Paper Wallets are Vulnerable When Spending or Importing?
Michael: That’s probably right, because for a moment the key goes from paper to the software’s memory. Some hardware wallet designs do this too, for a variety of reasons. They are completely respectable, but we want more… We want that key to never leave the paper, so to speak.
And How is this Achieved?
Michael: Some secure elements support us in this goal. If we get what we want (which is only possible to know after lengthy research) then the seed and or key will never leave the secure element. All crypto will occur inside the SE, like the controlling logic will say ‘SE please tell me if this transaction X is valid’ and the SE will calculate… instead of saying ‘SE please deliver the private key so I can calculate the validity on my own in unsafe SRAM memory.’
A BTCManager reader might better understand that companies like Apple call their SE ‘secure enclave’ and that there is considerable benefit to using them properly.
I’m excited about learning how the variety (ST, TI, Atmel, NXP, Nordic, ARM…) of manufacturers all try to make a better SE. And what they truly offer. For example, Atmel allows the developer to write a piece of code that when the user (who buys the wallet) clicks a button, will actually blow fuses in the SE. This is useful for protecting a seed or private key, for example. And after that only the SE can tell if a given transaction is valid, because only it has access to the key.
Anonimal: it sounds reasonable in the sense that there are use-cases for such a feature, but ensuring that data is truly destroyed when the fuse is blown; can that be proven?
Michael: I’m quite confident that the fuse blowing system works, but there are people who decapsulate IC chips and then run electron microscopy. There is probably no absolute defense against that. I’m trying to get further along the line with an experimental super capacitor 48V frying system that’s even worse than a blown fuse. We’ll see if this idea works though.
The good news is that our design will probably be cheaper than the typical products, so if someone buys our wallet for half the price and decides to destroy it, they can pull out their ‘spare copy’ at the end of the flight and all is well or the one they left back home. Similar to what you can do with Yubikeys, there’s always two backup copies.
Your Proposal States, “a private key in a real (with lock features secure element means that even rogue firmware cannot access the key…” Can You Explain this a bit for the ‘Man in the Street’? So Rogue Firmware can Affect Trezor, KeepKep, Ledger, etc.?
Michael: There are other designs which are well defended but because they are closed source it’s impossible to verify their claims. In other cases, some designs use no secure element at all. It’s strange to me to believe that their bootloader/firmware/secrets chain is well protected. I’m not really decided, but it seems like a no brainer to use a secure element for doing crypto in hardware.
A BTCManager reader should consider if their hardware wallet becomes infected with rogue firmware, if the thing that executes that firmware (the bootloader) will know it. And assuming the rogue firmware gets executed, if yet another line of defense is there. Like to stop it from getting the user’s private key and uploading to the Internet. The private key is no different than having an ATM card and PIN for your only bank account in the world. Very risky.
“That’s a nutshell reason for taking a very close look at what a hardware wallet claims and what is verifiable that it delivers. But let’s not forget that nearly all vendors of hardware wallets are doing an excellent job in their field.”
Right, But You Are Just Identifying an Improvement?
Michael: Hard question. An improvement would be if a hardware wallet design does not contain a secure element and is not benefiting from this decision. Then putting one in is a definite improvement. Some are not including a secure element because of nasty conditions that a company might attach to selling or using their secure element. Stuff like NDAs which mean ‘this code can now no longer live on GitHub.’
The most popular hardware wallet designs today have either benefitted from not integrating a SE, or have done so and signed NDAs (it’s assumed) but also benefitted. That’s why I said that all hardware designs, while being different from each other, are doing a good job in their field.
Anonimal: Are there any open hardware initiatives/projects that you know of which you could one day re-design the wallet around?
Michael: Yes, it’s the smart thing to do. Clone a few of the better designs, research, combine the best breed of what passes muster in Monero world, and then little by little our design will diverge and depart so much it becomes unrecognizable with time.
“It’s looking like the dedicated Monero hardware wallet will be one of the first designs that both ‘sticks to open source hardware terms’ and ‘integrates one or more strong secure element circuits.’”
Michael, Your Proposal is Fully Funded. Once the Project is Complete, There is Much More Work To Do. What will be the Plan following Completion of Your Project?
Michael: The project is ambitious, and after it concludes we will study which parts got extended or removed and why. It’s time for reflection then, but also for hope. You know why? It’s built into the proposal.
Namely, one of the requirements is ‘extendability’ which in our world means that groups like Globee, RingCT, Kovri, Monero itself, can take the design and make it their own.
How Much Time Have You Put into this Project?
Michael: I’ve spent a solid month planning, looking at what’s feasible for a single nerdy guy in six months, and what could possibly go wrong. It’s been almost full time for a few weeks.
The Proposal Mentioned a Demonstration at 34C3, the Hacker’s Event in Leipzig, Germany starting December 27, 2017?
Michael: We have some momentum built on 34C3 already, even earlier at the CCC event ‘Datenspuren’ in Dresden during October. Readers might like to know that as far as we know there is no Ethereum or other cryptocurrency folk there at 34C3. Just Monero and Bitcoin.
Any Final Thoughts/Comments?
Michael: The design delivers both a secure element and open source hardware. In other words, the Monero dedicated hardware wallet is ‘bodacious,’ where ‘bodacious’ is a combination of bold and audacious.
And a question for your readers to think about:
“Does adding an ambitious project (mathematical, physical, software, or hardware) to a community’s work… build new bridges or break the community’s back?”