Please login or register.

Advancing Monero Hardware Wallet

XMR498.10

funded of XMR498.00 target

44 individual contributions
100.02%
100.02001669679% Funded
0 payouts
XMR498.10 balance available
0% Paid Out
Version: 1.0
Date: 2 May 2018
Name: RFC-HWALLET-5
Author: Michael Schloh von Bennewitz
Contact: [email protected]
IRC-contacts: msvb-lab, msvb-mob
Title: Advancing the Monero Hardware Wallet
Related to: RFC-HWALLET-1, RFC-HWALLET-2, RFC-HWALLET-3, RFC-HWALLET-4
Location: https://forum.getmonero.org/7/open-tasks/90126/advancing-monero-hardware-wallet/
Crosslinks: https://www.reddit.com/r/Monero/comments/85kkap/monero_hardware_development_34c3/
            https://www.reddit.com/r/Monero/comments/86wt1d/advancing_monero_hardware_wallet_a_set_of_new/
            https://www.reddit.com/r/Monero/comments/7v8zgj/a_prototype_of_the_monero_hardware_wallet/
            https://www.reddit.com/r/CryptoCurrency/comments/7vcb07/a_prototype_of_the_monero_hardware_wallet/

Get Monero Hardware Wallets

"The Monero community has just funded a Dedicated Hardware Wallet which is now in progress."
- https://getmonero.org/downloads/#hardware, December 2017

The progress in question has allowed RFC-HWALLET-1 to conclude on time and on budget!

Status

The status of this proposal is:

PENDING FUNDING PLEDGES

Change Log

In reverse cron order.

20180502  Closed RFC-HWALLET-1 milestones
          Finalised injection molding bids
          Emphasized immutable bootloader
          Collected reddit mentions

20180412  Added recent plastics quotes
          Reduced cost of plastics bids
          Corrected according to exchange
          Replaced DefCon promotion (on request)

20180325  Publish version 0.9
          Added requirements text
          Added second edition image
          Corrected OTA to DFU (David)
          Removed DefCon promotion

20180324  Publish version 0.8
          English corrections
          Added license and legal
          Added budget and workflow
          Added scope and deliverables
          Added author and project plan

20180322  Publish version 0.7
          Added draft sections

20180318  Proposal creation

20180126  Meeting Genesis

Monero Hardware Wallet

Monero Hardware Wallet

Requirements

Note: PLEASE REMEMBER THAT THE DELIVERABLES (SEE SECTIONS 'DELIVERABLES' AND 'SCOPE CREEP') IS A PCB AND ENCLOSURE DESIGN, ALONG WITH DRAFT FIRMWARE AND SUPPORTING DOCUMENTS.

Nonfunctional Requirements

  • Quality: The project is bodacious (bold and audacious)
  • Marketability: Attention on user needs through market survey
  • Availability: Build your own and commercial models supported
  • Usability: Simple and intuitive, one hour learning time
  • Reliability: Provision for seed backup with guidance
  • Featureset: Early wallet firmware features¹
  • Accessibility: One hand one finger operation
  • Maintenability: User facilitated manual flashing
  • Invulnerability: Prohibitive intrusion effort
  • Integrity: Full display of public addresses
  • Use coverage: Diverging user and developer features
  • Choice: Feature rich design is selectively populated
  • Capacity: Maximum density of circuits and minimum case
  • Open natured: Hardware and firmware designs are published
  • Extensibility: Design with common FOSS applications
  • Legal clarity: Avoidance of NDA and closed source
  • Novice service: Firmware first run hand holding
  • Easy powering: USB-C power over any standard cable
  • Mobility: Untethered operation for limited features
  • Assurance: Release engineering backed assurance
  • Supportability: Leverage of existing channels
  • FW testability: Test plan enforcement of Q&A
  • Documentation: Comprehensive developer documents
  • Responsive: Firm button switches (tactile clicks)
  • Understandability: Clear confirmation UI (backlit touch)
  • Visibility: High contrast low profile display
  • Convenience: Possible zero volt ePaper display
  • Size constraints: Standard mechanical limitations
  • Perception: Smoother-than-FDM consumer enclosure
  • Hackability: Hybrid (PLA and acrylic) enclosure
  • Portability: Design merged to and from other projects

¹ Collected from first generation (simplewallet) operations able to complete in an untethered environment (no mining nor IP networking.)

Functional Requirements

  • Physical stability
    • Appropriate (heat, life) glue
    • Glueless fitting where possible
    • Moisture ingress nanocoating Left over from last cycle
    • Screw holes and threading
    • Progressive materialise
  • User input mechanics
    • Capacitive touch testing
    • Extensive untethering
    • Tap detection circuit
    • Alternate ePaper display
  • Enclosure facilitation
    • Battery ejection test
  • Enclosure security
    • Intrusion detection
  • Firmware security
    • Side channel hardware defense
    • Passphrase plausible deniability
  • Firmware features
    • Demonstration mode
    • Familiar functions
  • Complementary seed storage
    • Branded paper kit
    • Cryptosteel equivalent
  • Power supply integration
    • USB-C interop testing
    • Lithium battery research

Support Reasoning

Efforts have yielded hardware wallet designs, and proven a Monero established hardware engineering workflow. The promise of a community controlled hardware wallet remains popular, and work towards financial independence begins in this proposal. The goal is a market entry to become self sustaining and eventually require no community fundraising.

This second development cycle integrates the existing hardware design with a new immutable bootloader, off chip firmware copy, fused deposition modeling and injection molded enclosures, documentation and peripherals. During this time, resources are used for development and to distribute test devices.

Considering that the previous half year cycle concluded on time and on budget, requirements of this proposal are likely to be met or exceeded.

Deliverables

The Monero hardware wallet is a printed circuit board design, immutable bootloader, draft firmware, plastic enclosure design, peripherals design, and supporting documentation.

Scope Creep

The project is particularly vulnerable to scope creep. 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.

Teambuilding efforts is inclusive, and if contributors work out of scope the deliverables will include their contributions.

Author

Michael is a computer scientist with 20 years of industry (software, telecom, embedded systems) experience. He trains engineers at Black Hat, Hack Miami, and undisclosed locations. Michael designs and produces (not for sale) hardware in his circuits lab. He worked with the inventor of mod_ssl at Cable & Wireless, has contributed to Mozilla and the Tor Project, and trained groups using MbedTLS with Atmel secure elements.

He is a Monero citizen ([email protected]) in good standing, and lightweight user of other cyptocurrencies (Ethereum and Bitcoin.) He earned the trust of colleagues and 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.

Budget

Production Machinery

XMR Item
0 Completed in last funding round
0 Total machinery

Research Equipment

XMR Item
2 Reverse engineering device stock²
2 Developer kits (SE, FPGA, CPLD, BTLE)
1 Chip and memory programmers
8 Total research

² SC4-HSM, Trezor-T, Coldcard, Mooltipass, and similar

Passive and IC Components

XMR Item
36 Total components

Consumable Materials

XMR Item
2 Paste, substrate, nozzles
1 Screenprinting supplies
1 PLA, ABS, and other filament
3 SLA resin and container tanks
3 1.4301 (Aisi304) steel sheets
2 Acrylic and Plexiglas
12 Total consumables

Facilities and Services

XMR Item
1 Makerspace entry
33 Workspace rental
34 Total facilities

Plastics Engineering

XMR Item
56 Injection tooling
66 Plastics³ production
122 Total plastics

³ ABS or hybrid, any cost underrun allows for otherwise unplanned developer edition production

Travel and Promotion

XMR Item
8 DefCon and other promotions⁴
8 Total travel

⁴ DefCon village, DefCon demolab, and BSides to service existing demands

Trips to remote manufacturing locations (Shenzhen, Hongkong, 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, the trip cost is absorbed by the resource savings (with nothing new to add.)

Worktime Reimbursement

XMR Item
195 Lost contracts reimbursement⁵

⁵ Estimated by crossing vectors 6 months lapse, proximity obligation, and hour loss.


XMR Volatility

A 20% buffer is in place to lower risk of production loss or delay. This is partly due to component and service instability (like past LED shortages) and partly due to monetary fluctuation.

Total Budget

XMR Item
498 Fulfillment of requirements

Note: The base rate is calculated according to last month's average 172 € XMR exchange rate. The current price is 202 €.


Existing Resources

Machinery in use is too numerous to mention. A local maker lab offers a quarter million euros worth of equipment in twelve rooms. Preexisting (owned, borrowed, or otherwise accessible) resources including SLA printers, solder injectors, JBC rework stations, vapour phase reflow ovens, pick and place, and four (!) CO2 laser machines will be used while consuming no budget.

Defunding

Portions of this proposal may be defunded according to degree of fundraising success. This may lead to unplanned scenarios:

  • Unexpected scope reverse creep
  • Cancellation of injection moulding
  • Replacement of bootloader development
  • Reduction of PaaS documentation systems
  • Cancellation of some promotion deliveries
  • Fewer test systems leading to reduced QA work
  • Introduction of new budget items to fund plastics tooling

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 all resources (see 'Budget') will be procured in the most expedient and inexpensive way.

Work Items

Bootloader

Software engineering develops a second stage bootloader to replace the current factory stock bootloader. This allows for a device that requires no extra UI for boot or reset circuits, and streamlines the appearance. The first stage bootloader will be migrated to a device (probably the CEC1702) that supports a immutable bootloader and secure boot.

Either (immutable or second stage) bootloader may assist the next generation secure MCU (probably CEC1702 based) to verify all on chip code according to the Monero Project's secret key.

A locking memory or programming block is not planned (allowing for maximum user control.)

Firmware

Firmware is the part of a hardware wallet located in the microcontroller's internal flash storage.

While supporting Monerujo-hw firmware, this generation of devices will depart from STM32 specific constructs. A set of libopencm3(3) based interfaces allow modular feature selection at buildtime. For example, a board lacking intrusion detection ICs may receive a smaller and less expensive flash storage, by tuning firmware size according to hardware needs. In addition to libopencm3(3) (via GNU GCC/ARM), MBed, PlatformIO, and CryptoAuthLib (possibly via MPLabX/Eclipse) research will preclude a decision on a firmware development platform.

Host Software

Development of host software and drivers (in ISO C, C++/Qt, Go, or JavaScript) is not part of this proposal.

Test Harness

Unit and regression testing is conducted on second stage bootloader and firmware. Because common virtualization systems don't emulate Cortex-M (low power) environments, this promises to be a worthy challenge.

Enclosure Cases

Mechanical engineering results in enclosures for both developer edition and consumer edition.

Developer Enclosure

To support the hacker creative mentality, the developer edition enclosure release is a set of portable modelling source files as well as generated Standard Triangle Language (STL) files. A document serves to guide the developer when preparing slice files (in GCode or equivalent) for a FDM or SLA technology 3D printer. To encourage modification and remixing, (GitHub tracked) designs are indexed on trending solid modelling hubs like:

https://www.yeggi.com/
https://www.shapeways.com/
https://www.thingiverse.com/

Consumer Enclosure

A separate enclosure is designed for the consumer edition wallet device, to accommodate its small size and lean featureset. While mechanical engineering may produce files for do it yourself printing, attention is turned to professionally tooled model to support injection moulding technology.

The consumer enclosure may be produced in volume by contracting with a tool maker and plastics factory, in the same manner as almost all plastic enclosures in the world. The material will likely be acrylonitrile butadiene styrene (ABS) in the colour chosen by community survey.

Documentation

The current state of online documentation is maintained:

Taiga
Kastelo
GitHub

Additionally, new documentation is published:

Sphinx
Web Chat
Board Explorer
Getting Started

To manage complexity, the documentation system moves from simple GitHub pages to a devops PaaS system.

As usability goals are achieved, hardcopy is published to serve users and developers.

Peripherals

Several supporting peripherals are researched. This includes paper and (Cryptosteel equivalent) stainless steel seed media, professionally created using 1.4301 (Aisi304) steel sheets and a 150 Watt CO2 laser or CNC router. Daughter boards exposing FPGA or CPLD components as well as SDHC, NFC, and other requested technologies are researched.

Such promising peripherals may be bundled with prototype deliveries or prove valuable enough to become official projects.

Production Runs

Online PCBA services are seeded with design material for simple (few clicks) ordering. Michael is reachable for PCBA production as well. Contract fabricators publish designs (shared projects) and 3D print shops are seeded with enclosure information.

On a related note, the same production facility (as used in this project) is used for producing DefCon Monero badges, of use to our project as they test NFC circuitry and EEPROM off chip storage.

Marketing Promotion

A marketing plan is constructed to guide towards a future market entry, playing an important role in sustainable development. This requirement supports the goal of long term project survival with no direct community funding.

Promotional activities introducing the larger cryptocurrency community to Monero's unique ecology are undertaken. People get quite excited when seeing, hearing about, and studying (in their hands) hardware wallet devices. For example, CCC, BSides, and DefCon events are served by distributing prototype or release grade devices.

Sales Configuration

A sales plan is drafted and a pilot ecommerce system is researched to offer community members a gratis or subsidized device. This integrates other colleagues' ecommerce work (such as Monero Integrations and Globee) where possible.

Preview Samples

Prototype samples are mailed to forum investors, testers, and promoters in accordance with current hardware team practices, including poste restante blind delivery on request.

Testnet Leverage

As firmware matures enough to support on-chain network operations, the testnet is used to provide an out of the box trial experience. The testnet my be (ab)used for new user aquisition challenges, such as make a first transaction with your new hardware wallet for a free shirt or a more advanced transfer from your hardware to mobile wallet for a free card pack. The testnet is considered for ecommerce trials as well.

Time Estimate

Twenty to sixty hours per week six months long, scheduled at the author's discretion. This variability accommodates the challenge of synchronized board printing, mechanical engineering, parts ordering, firmware integration, and quality assurance.

Time is spent in a:

  • Local maker space
  • In house circuit lab
  • Local and some remote travel

Workflow Reference

Those interested in board development may refer to the last proposal section 'Workflow.' The forthcoming project involves too many technologies (PCB, PCBA, FDM, SLA, steel, acrylic, Cortex-M development, and injection moulding) to concisely detail a workflow.

Work is transparently carried out according to typical distributed Opensource practices. The degree of in house production is maximized to shrink the attack surface of supply chains.

Project Plan

Date Milestone Budget
Early April Early firmware demonstration at Security BSides [1]
Late April Initialisation work (platform, communication, and procurement) 12 XMR
Early May April Production testing of first batch of released board design 34 XMR
Mid May Technology showcasing at DefCon China, site visit to Chinese manufacturers
Late May FDM tooling, immutable bootloading, project documentation, mechanical research 38 XMR
Early June SLA tooling, set of second generation release PCBs and test distribution
Mid June Laser tooling, reverse engineering of injection moulded enclosures 38 XMR
Late June Hybrid (acrylic) tooling, mechanical constraint specification of board features 8 XMR
Early July PaaS administration, midterm report on bootloader and firmware development 108 XMR
Mid July Enclosure fine tuning and start of injection moulding tooling 38 XMR
Late July Backport of mechanical features in hardware and firmware
Early August First volume production of streamlined (for reach) device
Mid August Board and enclosure demonstration at DefCon[2], distribution 48 XMR
Late August Regression side channel attack trials, board explorers
Early September FDM and SLA generations (UI and decorative improvements) 98 XMR
Late September Injection moulding and board fabrication, pilot sales site work
End of term⁶ Demonstration video of a enclosed device running immutable bootloader 38 XMR

[1] http://www.bsidesmunich.org/
[2] https://www.defcon.org/

⁶ Six month conclusion

Contention

Most contending hardware wallet vendors (such as Shift Devices, Satoshi Labs, Ledger, and Keepkey) have launched efforts at Monero support in the past. Part of the Monero hardware team's existential role is to force the hand of such vendors to integrate and maintain Monero support (which is working slowly but surely.)

It is the author's hope that several Monero capable hardware wallets eventually exist, and that the community holds the keys to features and production of their own model.

Ownership

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.

Copyright

Source files (text and binary) of all work state Copyright (c) 2018, The Monero Project.

Licenses

CERN Open Hardware License 1.2

Being a hardware project, no software license is used for schematic, layout, and related work. 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.

Appropriate Opensource licenses are applied to documentation, software, and other designs.

Nondisclosure

Nondisclosure agreements (NDA) are avoided. According to the author's knowledge, no Monero hardware team member has ever signed a NDA relating to technology in use. This allows us to publish everything under free and open terms.

Communication

Progress is reported at community meetings and hardware team meetings. Support and collaboration is conducted primarily via IRC, with attention to other common channels (Telegram, Mattermost, Slack, Reddit) as well. Physical meetings such as meetups and conferences are attended.

Inclusion

Teamwork and collaboration are encouraged. Teambuilding is a soft requirement and strengthens the Monero community. Outreach to other hardware makers mutually benefits the respective communities.

Replies: 21
pa posted 6 years ago Replies: 1 | Weight: 0 | Link [ - ]

This is amazing work so far and should definitely be supported by the community. I can't wait to use it!

michael edited 6 years ago Weight: 0 | Link [ - ]

Regarding the previous development cycle of project RFC-HWALLET-1

Question: What happened to RFC-HWALLET-1?
Answer: It concluded on budget and on schedule on 31.03.2018. The forum thread 88149 described its plan, milestones, and requirements.

Question: How did RFC-HWALLET-1 begin and conclude on time?
Answer: The project's proposal began in August 2017 and finalized September 2017. The project itself began October 2017 and concluded end of March 2018.

Question: Why did RFC-HWALLET-1 conclude?
Answer: It concluded when its requirements were met.

Question: What were the requirements of RFC-HWALLET-1?
Answer: The were stated in the proposal text (search requirements.)

Question: Were all requirements met?
Answer: No, of 46 functional and nonfunctional requirements only 43 were met.

Question: Which requirements failed?
Answer: MTBF specification, camera readiness in documentation, and 48V supercap circuit.

Question: Why did these requirements fail?
Answer: Market part availability, safety reasons, and overperformance in other areas.

Question: Why did so many requirements succeed?
Answer: The project was ambitious but enormous effort and overtime combined with a bit of luck.

michael edited 6 years ago Weight: 0 | Link [ - ]

Budget questions and answers

Question: What are the most expensive aspects of this project?
Answer: As described in the text, parts to assemble, enclosure costs, and time compensation (in that order.)

Question: Why are parts so expensive?
Answer: While some parts cost cents, others cost 10 €, and a single board may require 100 parts (see schematic.) To meet a important requirement, sales practice in needed to distribute boards widely. Boards need to be tested and may be distributed to a fraction of the 30000 people attending Vegas events (in the Monero DefCon village for example.)

Question: Why are some enclosure costs cheap and others expensive?
Answer 1: Two board designs exist, a developer edition and a consumer edition.
Answer 2: The developer edition enclosure is cheap to produce in small quantity, because we expect developers to print only a few.
Answer 3: The developer edition Fused Deposition Modeling (FDM) enclosure would be too expensive to produce in quantity (which is the reason this design will not be produced.)
Answer 4: The consumer edition does not support developers, rather it provides very accurate ABS or similar injection molded enclosure. This is expensive, requires fiat, is difficult, but unfortunately a requirement for any consumer product.

Question: Can the project survive without proper enclosure designs?
Anwer: We're not sure, attempting a market entry with no enclosure certainly raises risk of failure.

Question: What is covered by time compensation costs?
Answer: The work time estimate is enough to complete all requirements, including firmware implementation.

Question: Why aren't there any machinery costs?
Answer 1: The machinery needed for most tasks is on hand.
Answer 2: Tooling (molds) and some etching (boards) is appropriately subcontracted.

Question: Why is the project so expensive?
Answer: Creating new hardware devices requires a different class of budget than new network or software, which is difficult to relate to for some.

Question: Why is the project so cheap?
Answer: Compared to what is spent in similar projects, in house R&D is maximized with existing machinery or equipment loans. The only subcontracting carried out serves to avoid 1,8M (!) fiat costs on injection and other fabrication equipment.

Question: Where are the budgets for comparable projects (TV-B-Gone, HackRF, Trezor, etcetera?)
Answer: There are no other projects (correct me?) which Opensource their budgets. We are alone in providing this transparancy.

antw081 edited 6 years ago Replies: 1 | Weight: 0 | Link [ - ]

Donated.

Very impressed with progress so far. Lets make this happen!

Reply to: antw081
michael posted 6 years ago Weight: 0 | Link [ - ]

Thank you for the vote of confidence and continued enthusiasm. You've done the project a great service in the past and I see you're continuing with that, thanks.

Thanks as well, for excusing the delayed publishing of this proposal. The plastics manufacturers were very late in placing their price quotes to support an accurate budget.

esperantomato posted 6 years ago Replies: 1 | Weight: 0 | Link [ - ]

Bodacious. Donated.

keatonofthedrake posted 6 years ago Replies: 1 | Weight: 0 | Link [ - ]

Donation coming your way! Amazing work so far! Thank you for all that you are doing for the community!

Reply to: keatonofthedrake
michael posted 6 years ago Weight: 0 | Link [ - ]

You're welcome and thanks for the encouraging words. A plan is materialising on a new community distribution here at Defcon China. Thanks again.

Reply to: esperantomato
michael posted 6 years ago Weight: 0 | Link [ - ]

Thanks a lot, I just picked up parts for the next assembly and hope you'll be interested in testing a board.

Reply to: pa
pa edited 6 years ago Replies: 1 | Weight: 0 | Link [ - ]

+50

Reply to: pa pa
michael posted 6 years ago Weight: 0 | Link [ - ]

Thanks a lot pa, very generous and I hope you'll have time to join in the fun and rewards during development.

drfred posted 6 years ago Replies: 1 | Weight: 0 | Link [ - ]

donation on its way :)

binaryFate edited 6 years ago Replies: 1 | Weight: 0 | Link [ - ]

+65 from me.

The hardware project is a perfect example of the high quality contributors and contributions Monero is able to attract. People that are both passionate about the principles behind the whole Monero project and very talented. On top of this, Michael and everyone involved in the hardware project have delivered in a very professional manner so far, and I am confident they will execute this proposal in the same way. Let's get this funded!

Reply to: drfred
michael edited 6 years ago Weight: 0 | Link [ - ]

Thanks for the extra help drfred, and I hope you'll stay involved and inform of your opinion once we get the next round of devices assembled and ready.