michael posted this 6 years ago
Version: 1.0
Date: 15 September 2017
Name: RFC-HWALLET-1
Author: Michael Schloh von Bennewitz
Contact: [email protected]
IRC-contacts: msvb-lab, msvb-mob
Title: Dedicated Monero Hardware Wallet
Related to: RFC-HWALLET-2, RFC-HWALLET-3, RFC-HWALLET-4
Location: https://forum.getmonero.org/8/funding-required/88149/dedicated-monero-hardware-wallet/
Crosslink: https://www.reddit.com/r/Monero/comments/6urao7/ffs_for_dedicated_monero_hardware_wallet/
Crosslink: https://www.reddit.com/r/Monero/comments/6zm56g/new_version_of_proposal_88149_taking_feedback/
Crosslink: https://www.reddit.com/r/Monero/comments/70bpul/proposal_88149_entered_funding_required/
| "There are currently no hardware wallets available at this time. Please check back for updates." |
|---|
| - https://getmonero.org/downloads/#hardware, August 2017 |
It's time for the Monero community to come together and realize the goal of a hardware wallet!
The status of this proposal is:
PENDING FUNDING PLEDGES
In reverse cron order.
20170915 Publish version 1.0
Added sketchy RF integration
Explained schedule of procurement
Clarified work to reverse engineer
Mentioned possible Shmoocon promotion
Removed nonhardware based requirements
Detailed role of microscopy in workflow
Included more secure element details
Zero sum corrected budget for lab
Added plan column for FFS release
20170913 Publish version 0.9
Added copyright statement
Added airgap feature option
Clarified choice of License
Slight changes to the budget
Slight changes to requirements
Added related project content
New Defunding Option section
New Proposal Ownership section
New Legal Summary section
New requested Intention section
Documented outreach to Gemalto
Emphasized hardware focus and license
20170912 Publish version 0.8
Nonfunctional Requirements additions
Requirements 'note' reminder
Time floor function removed
Secure Element development
New Scope Creep section
Project plan adjustment
Budget detailed design
XMR rate changed to 67
Workflow development
20170830 Publish version 0.7
Functional Requirements additions
Budget clarification
New Workflow section
20170818 Publish revision 0.6
20170816 Proposal creation
20170801 DefCon Genesis
Note: PLEASE REMEMBER THAT THE DELIVERABLE (SEE SECTIONS 'DELIVERABLES' AND 'SCOPE CREEP') IS A PRINTED CIRCUIT BOARD DESIGN. Other efforts exist to produce related deliverables like bootloader, firmware, enclosures, branding, modding, and derivatives.
¹ Depending on availability of supporting IC
² How to apply potting is documentation only
³ Research prone feature, may yield suboptimal
⁴ Depending on results of cost and size analysis
⁵ Destruction by puncture is documentation only
⁶ Independent circuit for optional model extension
A secure element (SE) serves to verify firmware at boot via standard DSA or ECDSA, and hopefully a vendor of hardware key storage is found that supports Monero's ED25519 elliptic curve. A private key in a real (with lock features) secure element means that even rogue firmware cannot access the key.
It seems this would be the first design to ever implement such a high degree of wallet security, but unfortunately ECDSA support depends on the hardware vendor. This is a formidable challenge.
Several weeks of research will determine which of the desired secure element supported implementations are realistic. A worst case scenario is that ED25519 is completely unsupported and must be processed by firmware in SRAM, the same thing that Ledger and Trezor do. Preliminary research suggests the possibility that ARM CryptoCell circuits support hardware ED25519 calculations with a unknown (possibly no locking supported) key deployment method.
Discussion (even before this proposal concludes) is ongoing with Microchip, Atmel, and Gemalto. We want them to produce integrated circuits according to the very easy to meet requirements.
The Monero hardware wallet is a printed circuit board design resembling the Ledger or Trezor wallet PCBs. It may be slightly larger in size and composed of fewer (broader reach) or more (optimal electronic density) substrate layers.
Please see related RFC-HWALLET-X proposals for product design, firmware implementation, and other non hardware design work.
The project is particularly vulnerable to scope creep. Votes or attempts at consensus on how to react to changing requirements are not planned. Rather, a compromise (maintaining pace of progress) is reached by attending nearly all Monero development meetings and reporting accordingly.
If contributors are interested in applied agile methods to track scope, then this can be arranged once agreement is reached in meetings.
Michael is a computer scientist undergraduate with 15 years of industry (software, telecom, embedded systems) experience. He trains groups at Black Hat [1] and produces (not for sale) hardware in his circuits lab. He worked with the inventor of mod_ssl at Cable & Wireless, collaborates with WolfSSL on Atmel/Microchip IC to low powered ESP8266 platform porting, as well as MbedTLS on Atmel secure element provisioning.
He is a cryptocurrency novice of Ethereum, Bitcoin, and now Monero. He has earned the trust of his students using custom derivatives of Bus Pirate, FRDM, and NodeMCU shield devices, as well as larger companies (references on request) assigning first generation SBC hardware shield extensions on contract.
[1] https://www.blackhat.com/us-17/training/analyzing-an-iot-empire.html
If you look carefully, you will find the privacy sensitive software development Michael has done for high profile groups.
Michael is motivated to complete this project in order to have a Monero hardware wallet of his own, improve PCB design skills using a secure element, contribute to Monero enthusiasm, and become more active in the Monero community (by owning coins and IRC communicating frequently.)
If all related FFS proposals are rejected, then Michael will probably be a Monero currency owner but cannot afford to contribute software, firmware, or hardware logic.
Portions of the production machinery budget may be defunded, leading to the following added risk:
The actions and features at risk would still be worked on a best effort basis. To be clear, this proposal has no defunded budget items and production machinery will be procured in the most expedient and inexpensive way.
Some RFC-HWALLET-X proposals are complementary and others mutually exclusive. In the best case, this pilot project will serve to launch and support other (conference badge, sponsored swag, product integrations, university research) related projects.
| XMR | Item |
|---|---|
| 5 | Qinsi QS-5100 reflow oven |
| 45 | Analog stereo microscope |
| 150 | NeoDen4 Pick and Place |
| 200 | Total machinery |
| XMR | Item |
|---|---|
| 1 | Trezor |
| 1 | KeepKey |
| 4 | Ledgers |
| 6 | Chipwhisp |
| 2 | Launchpad |
| <1 | Opendime |
| 15 | Total research |
| XMR | Item |
|---|---|
| 20 | Total components |
| XMR | Item |
|---|---|
| 25 | Paste, substrate, nozzles |
| XMR | Item |
|---|---|
| 2 | Makerspace entry |
| 68 | Workspace rental |
| 12 | Datacenter, telco |
| 80 | Total facilities |
| XMR | Item |
|---|---|
| 0 | Included in other items |
Trips to manufacturing locations (Shenzhen or Hangzhou) will not be taken unless necessary, for example when a flight is cheaper than postal shipping or acting as a courier yields a customs free import. In those cases, trip cost is absorbed by the budget stated resource price (with nothing new to add.)
| XMR | Item |
|---|---|
| 490 | Lost contracts reimbursement⁷ |
⁷ Estimated by crossing vectors (6 months lapse, proximity obligation, hour loss) and considering used nonworktime procurements.
A 20% buffer is in place to lower risk of production loss or delay. This is partly due to Michael's lack of crypto trading experience and partly due to natural monetary fluctuation.
| XMR | Item |
|---|---|
| 996 | Fulfillment of requirements |
Note: The base rate is recalculated (95 € + 40 €) ÷ 2 resulting in 1XMR = 67EUR €. The previous base rate was 40EUR € before fluctuation and the current price is 80EUR €.
A number of machines is already available including a Voltera V-One substrate printing machine, JND-983A solder dispenser, industrial air compressor, dedicated circuit production computer, and solder rework station.
The total value of already acquired machinery is estimated at 8000EUR € (120XMR.) These resources will be used but require no budget.
Any tools needed (see 'Production machinery') should be purchased in the first month (see 'Project Plan'), in order to avoid postponement of milestones.
Ten to twenty hours per week six months long, scheduled at the author's discretion. This variability is to accommodate lack of sync in PCB printing, parts ordering, potential firmware integration, and test revisions, logistics which may take weeks to order and ship.
Time will be spent in a:
Work is transparently carried out according to typical distributed Opensource practices. The degree of in house production is maximized to shrink the attack surface introduced by contract manufacturing as well as increase the turn around time of generational testing.
External and prior logic is researched for possible integration. This may include reverse engineering of contending designs by Opensource documentation or closed source (to the legal extent) microscopic inspection.
A schematic diagram is designed using KiCad or equivalent Opensource software. A layout is derived from the schematic and integration work.
Two layer FR4 (flame retardant) substrate is printed according to the prior layout. Four layer substrate may be used, but a external contract manufacturer like Aisler or OSH Park is required for that.
An Sn63Pb37 alloy is applied to the substrate with an injection based solder printer.
The board is populated (stuffed) with components in a standard pick and place procedure. Manual placing is avoided due to error and delay concerns.
The board is baked according to a timed temperature curve yielding a ready to test PCB. An experimental two sided approach may allow for extra density.
Bridged solder pads, air wires, and other mistakes are corrected.
Electrical and optical tests are manually done to identify manufacturing problems. This may include stereoscopic magnification or controlled destruction.
MCU and external flash programming applies primitive bootloader and firmware interface images.
The PCB is ready for use, and a new generation of correction and improvement follows. Start from the beginning (integration step) to optimise the existing design and fulfill more requirements.
Production samples are mailed to investors, testers, and promoters identified during Monero meetings.
| Date | Milestone | FFS Payment |
|---|---|---|
| October | Initialisation work (platform, communication, and procurement) | 314XMR |
| Early November | Tool configs, project documentation, Opendime research | 168XMR |
| Late November | Set of PCBs employing secure elements from ST and Atmel | |
| Early December | Trezor and Ledger hardware (clone) production | 120XMR |
| Mid December | Trezor and Ledger firmware (fork) programming | |
| Late December | Mock or prototype demonstration at 34C3 [2] | |
| Early January | Midterm report on Trezor and Ledger findings | 120XMR |
| Mid January | Custom design and recent feature tailoring | |
| Late January | Midterm remix in favor of Monero features | |
| Early February | New prototype demonstration at FOSDEM [3] | 154XMR |
| Late February | Correlation power analysis, glitch attack trials | |
| Early March | PCB generations (schematic and layout improvements) | 120XMR |
| Late March | Size and complexity (less or more layers) optimizations | |
| End of term⁸ | Demonstration video of a release grade⁹ manufactured board |
[2] https://en.wikipedia.org/wiki/Chaos_Communication_Congress
[3] https://www.fosdem.org/2018/
⁸ Six month conclusion
⁹ Post prototype
Funds are asymmetrically distributed, due to terms of machinery procurement and facilities use. Some correction (not receiving work time reimbursement the first month) attempts to balance this asymmetry.
Progress is reported in bimonthly Monero developer meetings on the IRC developer channel.
| Date | Milestone |
|---|---|
| April | First viable wallet with hello world firmware |
| May | Invitation documents produced with instructions |
| June | Virtual community event for alpha testers, demo |
| August | Official release at Black Hat and DefCon |
The Monero Project owns this (Opensource) proposal, the blueprint-like result of a month's careful deliberation and research. The author contributed it by uploading content to the forum. Readers are free to print and hand it to investors, colleagues, university professors, or whoever else, in order to start a hardware project of their own.
Source files (text and binary) of all work state Copyright (c) 2017-2018, The Monero Project.
CERN Open Hardware License 1.2
Being a hardware project, no software license is used. Instead, a open hardware license is applied whose terms resemble the other Monero projects' (BSD|MIT) licenses. Patents are more relevant to hardware projects so to counter risk of conflict the CERN OHL is used.
Note: While deliberating between TAPR and CERN, online chats led to a preference for CERN due to its:
The legal terms mentioned in this text are chosen with the intent of maintaining free and open access to the work. Some call this intellectual property (IP) and others consider deliverables (see section 'Deliverables'.)
These intentions are no different than other Monero projects, and the community is unified in encouraging freedom. Like any other similarly licensed Opensource project, groups and individuals may enjoy the free and open terms as specified in the license.
The project intends to serve as a launchpad for small (one man-hour) to large (one man-year) efforts at distributing Monero featured wallet hardware. Several requirements (see section 'Non/Functional Requirements') support the derivation, customization, marketing, and teaching of how to begin commercialization. All are welcome to participate in this way, and the hope is that we end up with both collaborating and competing groups.
This project proposal was first discussed by Michael, endogenic, and anonimal at the Monero themed party during DefCon 2017.
Teamwork and collaboration from any competent person is encouraged. Outreach to other hardware makers mutually benefits the respective communities.
The hackerspace mailing lists and IRC channels for C-Base, MuCCC, and the Noisebridge will serve to promote, while dedicated lists and channels will serve to support. Outreach is conducted with the EFF, NLNet, and other like minded groups.
Midterm deliverables will be taken to CCC congress at Leipzig in December, possibly Shmoocon in January, and prototype or release grade devices will be distributed at DefCon 2018 (see project plan.) It may be Michael that makes these visits or another person familiar with the project.
Hello Ninja,
Yes, we are working towards having an enclosure. This includes design work, and at least a few people are involved. You're quite welcome to participate in this respect, and probably the best way to collaborate is starting with a short status report of mechanical engineering underway. Catch me on IRC (msvb-lab) or email (michael@getmonero) to get this information interactively (with questions and answers.)
Cheers, Michael
We overperformed in a number of areas, too numerous to mention. Some industry developments, such as appearance of new secure element components, forced us to delay final circuit design until migration from the current STM32 based architecture can follow manufacturer's latest production dates.
Our third prototype design failed due to manufacturing errors of a flawed ground plane, so a fourth and final design was released which preserved the third (Breakneck 0.7.0) features while completing the ground plane (needed for power distribution throughout the board.) The fourth design (Breakneck 0.8.0) became our flagship release and will be distributed to supporters and testers.
The release design is being printed and will be assembled in a European lab following a trip to China to pick up the etched boards.
The release design incorporates two (!) circuits to detect intrusion of a enclosed device. A serial bus connected ambient light sensor (ALS) and a mechanical detector switch can be used exclusively or in tandem to increase the level of difficulty of intrusive attacks.
To support intrusion detection and other energy sensitive circuitry, a CR2450 (smallest profile with largest capacity) cell clip is now mounted directly on the back of the wallet.
Following meetings with Microchip, we've come closer than ever to decide on migrating from STM32 to CEC1702 as our central control device (MCU.) The new architecture will be completed in the next development cycle and involves new challenging features:
…as well as a number of less important new features such as timing defense, power variance, and breathing light circuitry.
We served the community of European security enthusiasts at Security BSides in Munich, presenting The first Monero Hardware Wallet with hands on samples inspection.
We have efforts from three groups working to produce a mechanical design for three dimensional FDM and possibly (see next funding proposal) injection molding tools. The future looks bright for an enclosure to dignify our current set of circuit boards.
Side channel analysis and glitch attack trials resulted in a destroyed MCU but no evidence that firmware can't defend against CPA or wallet passwords (assuming SE stored secrets.)
Exotic features illustrate what's possible but aren't expected to materialize in a finished product. Schematic and layout improvements led to a variety of exotic features including accelerometer based tap detection, crystal isolation, and backlit capacitive touch sensors.
We chose to keep all boards at two layers (instead of four or more) due to accessibility to development testers we rely on design validation. Likely, we decided to stay with standard 0805 package sizes for passives, to support hand soldering when needed.
https://www.vimeo.com/267800075/
A demonstration video serves to highlight the release design as well as subsequent prototype generations with varying levels of circuit sophistication.
