This project has started and occupies a Taiga account at:
Dedicated Monero Hardware Wallet
funded of XMR996.00 target
Initialisation work (platform, communication, and procurement)
Funds awarded: 31.53% (~XMR314.04)
Tool configs, project documentation, Opendime research
Funds awarded: 16.87% (~XMR168.03)
Set of PCBs employing secure elements from ST and Atmel, Trezor and Ledger hardware (clone) production
Funds awarded: 12.05% (~XMR120.02)
Trezor and Ledger firmware (fork) programming, Mock or prototype demonstration at 34C3, Midterm report on Trezor and Ledger findings
Funds awarded: 12.05% (~XMR120.02)
Custom design and recent feature tailoring, Midterm remix in favor of Monero features, New prototype demonstration at FOSDEM
Funds awarded: 15.46% (~XMR153.98)
Correlation power analysis, glitch attack trials, PCB generations (schematic and layout improvements), Size and complexity (less or more layers) optimizations, Demonstration video of a release grade manufactured board
Funds awarded: 12.04% (~XMR119.92)
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/
Get Monero Hardware Wallets
|"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.
- Quality: The project is bodacious (bold and audacious)
- Usability: Simple and intuitive, one hour learning time
- Availability: Build your own and commercial models supported
- Accessibility: One (of two total) button operation
- Verification: Standard on board private display
- Legal clarity: Avoidance of NDA and closed source terms
- Legal freedom: Patent treaty via Open Invention Network
- Open natured: All assembled parts ship with datasheets
- Regulatory compliance: Attention to RoHS certification
- Invulnerability: Prohibitive intrusion effort or time
- Data integrity: Selective verification by SE cryptoanalysis
- Reliability: MTBF to be determined and documented
- Operating constraints: High firmware compatibility
- Size constraints: To be determined after enclosure research
- Resilience: Broad degree (voltage and temperature) of operation
- Interoperability: Provision to interface with software wallets
- Capacity: Balance between feature storage size and transistor constraint
- Supportability: Supported through existing (forum, IRC, Reddit) channels
- Privacy: Timer equipped for dimming, and narrow viewing angle
- Documentation: Camera ready collection of developer documents
- HW testability: Unpopulated debug (JTAG or similar) headers
- FW testability: Bootloader and sample firmware templates
- Extensibility: Open design with a common EDA CAD application
- Marketability: Support for product design and management efforts
- Derivability: Variation by unpopulating an overextended design
- Portability: Portions of design forked from other projects
- Power supply
- 5V USB connection
- 3V3 Battery housing
- Security design criteria
- Crypto: Private key in secure element¹
- Potting: Epoxy compound (optional²)
- Production: Non-RST debug removal
- Airgap: Disconnected media option³
- CPA and glitch defense
- Dual MCU comparison circuit⁴
- ...or external secure element⁴
- Invasive border search protection
- Passphrase plausible deniability
- 48V supercap discharge circuit
- ...or puncture destruction kit⁵
- Intrusion detection criteria⁶
- Ambient light interruption
- Mechanical switch interruption
- Physical stability
- High rated semiconductors
- Moisture ingress nanocoating
- Developer friendliness
- Development: JTAG breakout
- Pogo pin harness option
- User friendliness
- Replaceable battery
- Replaceable optional media⁴
- Screen sized to allow QR
- Possible RF integration³
...unless we want to avoid BlueBorne
¹ 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.
Degree of Success
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.
- Review of requirements from the existing designs of Ledger, Trezor, and KeepKey
- Blend of features from peripheral devices like Opendime, Mooltipass, and Cryptosteel
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  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.
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:
- Unexpected scope reverse creep
- Loss of miniaturization requirements
- Loss of component choice requirements
- Reduction or cancellation of samples distribution
- Reduction or cancellation of promotion deliveries
- Fewer test generations leading to reduced QA work
- Introduction of new budget items to fund assembly
- Failure of any process requiring quick or accurate manufacturing
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.
|5||Qinsi QS-5100 reflow oven|
|45||Analog stereo microscope|
|150||NeoDen4 Pick and Place|
Passive and IC components
|25||Paste, substrate, nozzles|
Facilities and services
Travel and promotion
|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.)
|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.
|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:
- In house circuit lab
- Local hacker space
- Remote maker space
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.
|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 |
|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 ||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|
⁸ 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.
Continuation Plan (Pending New RFC and Revote)
|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.
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:
- Poison pill
- Lack of lame conditions
- Lack of Eric Raymond complaints
- Adoption by other like minded projects
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.
I don't know if it's allowed, but can be cool to put a link about your initiative on the official getmonero.org download page (hardware wallets section) ?
You mean like an announcement that hardware development is on the way, similar to how the download page leads mobile users to ask for advice in another channel?
Your idea seems quite helpful. I'll create a bug report on the website repository once I'm back on a full keyboard.
A private key in a real (with lock features) secure element...
...this would be the first design to ever implement such a high degree of wallet security...
Both hardware (Bitbox and Ledger) implementations seem solid enough, but at least Ledger hides from users what they consider the most important crypto code, also what forms the basis of their claims. I see you used the word claim as well. After three weeks and five emails, I finally got a one line answer 'no you may not yet verify the source code that supports our sekp256k1 secrets claim.'
You missed that the new 300 USD Bluetooth model 'Ledger Blue' also integrates a ST SE (ST31G480 instead of ST31H320) and is a bit less opaque to users.
While it seems their work is prime time and high quality, their goals are different than those of the Monero project.
I'm impressed by Digital Bitbox's use of the Atmel suite of secure elements (ATSHA240A, ATECC508A, and ATAES132A) while sad that they suffer from lack of ECDSA in hardware. In fact, both Bitbox and Ledger maintain their own forked software implementations of sekp256k1. They focus resources like BIP32 and BIP44 and secp256k1 software maintainance in order to cater to a non Monero user base. This means, just like Ledger, that if a noncore component must be chopped in the future, it will more likely be Monero's ED25519 (assuming they ever implement it -in software- at all.)
Also impressive is that Bitboxes are designed at or near the ETH Zurich, an important high tech hotbed with history. On the other hand, I wonder why they don't turn to ATECC ICs for the ECDH crypto they claim to secure mobile phone connections with. They are already using Atmel ICs after all.
Thanks a lot for bringing up the Digital Bitbox, which we hadn't fully inspected yet. I've reached out to them, and tried to arrange for a meeting at the Swiss Federal Institute of Technology (ETH.)
I'm pretty sure this doesn't fully answer your question 'I am curious how this would compare...' but possibly steered in the correct direction? It's a bit of a can of worms topic, so hopefully you'll write back, giving an opinion. Feel free to restate or reword the question.
Thanks @michael, honestly I am not qualified to discuss much of this, hence the vague questions. Rather I wanted to be sure that similar projects were considered and there was a space for discussion.
I spoke with the Digital BitBox guys several months ago and suggested they work on Monero support. In the end I just want good hardware wallet options for XMR users. :-)
MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="----577A3B05A6125877ABFE1DF869EB179A" This is an S/MIME signed message ------577A3B05A6125877ABFE1DF869EB179A RFC-HWALLET-1, 'Dedicated Monero Hardware Wallet' This is forum /user/michael ([email protected]) X509 fingerprint: E5:94:D3:D8:9E:62:15:F8:DC:F7:60:F7:21:99:1A:A9:FC:17:3A:98 To verify this message text and signature: $ curl -kO https://www.cacert.org/certs/root.crt $ openssl smime -verify -in thiswholemsg.txt -CAfile root.crt To optionally inspect the client certificate: $ openssl smime -verify -in thiswholemsg.txt -noverify -signer msvbclicrt.pem $ curl -O http://michael.schloh.com/download/msvb-smime.txt $ diff msvb-smime.txt msvbclicrt.pem To optionally compare the cert fingerprint: $ openssl x509 -fingerprint -noout -in msvbclicrt.pem Fingerprint=E5:94:D3:D8:9E:62:15:F8:DC:F7:60:F7:21:99:1A:A9:FC:17:3A:98 To learn more about the certificate's owner: $ openssl x509 -subject -noout -in msvbclicrt.pem subject=... ------577A3B05A6125877ABFE1DF869EB179A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIPlAYJKoZIhvcNAQcCoIIPhTCCD4ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCDOkwggdZMIIFQaADAgECAgMKQYowDQYJKoZIhvcNAQELBQAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkB FhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMTEwNTIzMTc0ODAyWhcNMjEwNTIwMTc0 ODAyWjBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3 dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MIICIjAN BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAq0k1EUh80iZ+U5TPQ6ndKNdCKovz h3gZWHwPntqJfeH763KQDXShlmSrn6AkmXPa4lV2xxd79QSsRrjDvn9kjRBsJPNh nMDykPpR5vVpAWPDD1biSkLP4kSMJSioxXkJfUa5ivPp8zQpCEXkHJ/LlAQcgagU s5hlxEPsToKNCdG9qluNktDs3pDFfwrC4+vmMVpedD6XM1nowwM9YDO/99FvR8TN 7mKDUm4uCJqk2RUYkaaFkkewrkjrbbch7IUaaHI1q//wEF3A9JSnatU7kn5MkAV+ k8Esi6SOYnQVcW4LcQPqrxU4mtTSBXJvjPkr61pyJfk5RuNyGz4Ew2QnIhAqik9Y pwOtvrQuE+1dqkjX1X3UKntc+kYEUOTMDkJbjO3b8s/8lpPg2xE2VGI0OI8MYJs7 l1Y4rfPSW4ugW+pOlrh819WghnBA05Ept6I8rfWMu88akorkNHvA2Gxf6QrCw6cg mlrfLF1SXLpH1ZvvJChwOCAv1X8pwLJBA2iSzOCczJdLRe86EAqrcDqYlXCtNbHq hSukHIAhMamuYHqAJkgAuAHAk2NVIpE8Vuev2zol848xVOomi4FZ+aHRUxHFe50D 9nQR4G2xLD8shpGZcZqmd4s0YNEUtCysna+MENOfxGr4bxP8c1n3ZkJ0Horj+NzS b5icy0eYlUAF++kCAwEAAaOCAg0wggIJMB0GA1UdDgQWBBR1qHFgTIgT8HjZiXe1 bcWJ37yxejCBowYDVR0jBIGbMIGYgBQWtTIb1Mfz4OaO873SsDrusjkY0aF9pHsw eTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQu b3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZI hvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmeCAQAwDwYDVR0TAQH/BAUwAwEB/zBd BggrBgEFBQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5v cmcvMCgGCCsGAQUFBzAChhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoG A1UdIARDMEEwPwYIKwYBBAGBkEowMzAxBggrBgEFBQcCARYlaHR0cDovL3d3dy5D QWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDA0BglghkgBhvhCAQgEJxYlaHR0cDov L3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDBQBglghkgBhvhCAQ0EQxZB VG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFLCBnbyB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwDQYJKoZIhvcNAQELBQADggIBACkoha5EqbmvpHkT 8KijK5dg81zu4y/B9uJmoBGuNjc6dhUEU+pC9fnqwBXYpoLZ5GGucgspXJBD6EGy 4XfbAhNEeEdVr1j8zJj2RbnRIPjYIQf+bapz1LPGB+kJhcw78ra+LBwl1XGMObUu 6r4Ygbqwk7gP4+bXJowxWnIDhFLmpvUzIkUKyAsNirg2b5AJoau919VOLnGi1K76 p1Qr6zWNWrdUiC/udJ/tSBbKDUjQlNOspKL2JN+S473rQ0CRbhwYjla0ghLzqZOf 1LycrZx17lqXG5XndC0cD7Asl5/7qTM5eucDOpKOIvaMDeTZfg12GPcB+e+WlqJV c8A8cbQdGlZDt8MKjXL84hAJC0HOjJSg+QP9cXNLilcz5Y50fhUBAObMShznf5UZ LcWlDIu7te2Fs1zT37i58srHDQEUrHBYxYyNM9SdZqMaUJUj/EjgBkMS2c2nhjkv NnKjgBDk4fPRy1sawOSAmnwTcwZP26NrJAq6sxy8Sni75eN1OKVIp6Ier3bUXvc4 hlZaic7Ww6d5slKgxvGFtCWM8j+WsxDZjWxXO59vhjoYgiI2yLCRONsqoZOqhD/1 J2Wuc9XI1dN36kudx0G7x8DjoD/kfaSNc+YSS9+hc3NzOoDo1cuOL8vqE6fWQYus +jyJ1yT1TrTgYZK38zeYxL6Wo7eKMIIFiDCCA3CgAwIBAgIDApgHMA0GCSqGSIb3 DQEBDQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8v d3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwHhcN MTYwODAyMDg0NDE2WhcNMTgwODAyMDg0NDE2WjBKMSUwIwYDVQQDExxNaWNoYWVs IFNjaGxvaCB2b24gQmVubmV3aXR6MSEwHwYJKoZIhvcNAQkBFhJtaWNoYWVsQHNj aGxvaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVWxgw8f+8 DKvcJQMNRPg931mxyGUxlHkwFlBaajP5RTD89mxxP/IEQFc2IcdpbQY0xF/aCtnI aTc000+DV0y/tllvnMXQ2nB0sQ17LQkl7IcWo3sgf4iDYmvJoiSXyL+bFUj/iT6+ 5Ybe0hvTubhABSTr0t0Yyc8hWI58R5/RNvCa9ws4Ds0PgoKRfPilGzt43xO97cnj d/XCnnYKiaRUFnQX90vEcqApjmt2p4WQRR6cvrsSkQRGM+2N8RKzUgZiuc0NZMvZ 4RiFp518X96w/i20xPKlYuRLmIs9WH4wttwRAzqt4lwDoWaIVFsGuaN0J9+wwBkN l0USRv1bNBsPAgMBAAGjggFrMIIBZzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIB DQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBv dmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwYgYD VR0lBFswWQYIKwYBBQUHAwQGCCsGAQUFBwMCBggrBgEFBQcDAwYKKwYBBAGCNwIB FQYKKwYBBAGCNwIBFgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0 Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcvY2xh c3MzLXJldm9rZS5jcmwwHQYDVR0RBBYwFIESbWljaGFlbEBzY2hsb2guY29tMA0G CSqGSIb3DQEBDQUAA4ICAQB6FQyhpBGWjZK5w8U1DUR7z0FIyspNXpDOmq9749hX mgkbTLSp5ySwtxTxW9FofXBGfQUNrRlj97X/IjcL40j22u/5I7ny7gDDm7HcPFl3 buaNtehSfNBpzz4mT6Ld1wKv3wuDycCkkYSZ1xdIpdz918exwefVSgkW7tOgrlyo P+0JTdDkKaR51MmH/UCk6PV9v5nwI3f8aQGy8FFVU/KSkFCKkJVXJn5W1itqgbKS AF2MbAuIu96UviTUPoW9d0qw2DnRgz4CDV63f5Nhv3r5y6tI1pV935TEAqsZWSdL N2iKRgOD0dezIkzb9mFM0qSlljJ7DbDigJPOFubh2Ls6OKFvhPDp4agO/YFRyaI1 FVO54fZ9RyJb5kX/DIDwkO6bkMTFFKSaIv9icUfx9ovydc+1oW3TsFrgNhAXaDHC LMDi7BMly7ixzM+SDeHTarj/7/p0SE4TJGhq5hHsBYuDXvp6usNO1vvL0w/T4akh 13G1MaYA/DCto/o5VSolDZmEAJm7D0+MTfjFW90JQkTXYluZy/GBM1GZmXoZPrx9 f1Yf/MiIm5OUVVwg8DeUX7qsYscT/JW2bEwCRW2RYN7OZCQofQaqsWAEbVArLVoT G0HGcKIvC3ocGvLX+dP4bGTLa96m8IDpOHsMMIyxJJ8xBHB0U9eqKd8MvsLaYNUY 9DGCAnMwggJvAgEBMFswVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsT FWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdAIDApgHMAkGBSsOAwIaBQCgge4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIwMTIyMTE5WjAjBgkqhkiG9w0BCQQxFgQU /sA3R0n2Oi5kgJt7W+LVQYUTt5AwgY4GCSqGSIb3DQEJDzGBgDB+MAsGCWCGSAFl AwQBKjAIBgYqhQMCAgkwCAYGKoUDAgIVMAsGCWCGSAFlAwQBFjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAJi+U907bw00 RQinudrBAgoOJSBU9FNZbuMnkfkG1WAarvHJJpMfl+69lS8mx7B2okMJ6/5aMinX 96qk1c/PmtzoemURKpOagFNrvUmBRR++1dRjfoO3tfYyFO8EgMw58K2oy8B6hSjd rHSFmGe5i5F+JXQDGEmXmWDhu+mTRsX9wXjodlolSutdrelR0YmDZHh5u6gntfQM lCJbYccbLUKnzM9xdqnmpVzGTeVsg7evpFlHqwhMIg3z3VgyarlWXIOljn4UJzcZ OKj8barNzknXLwPcFAbIImil63WOUROhr1bqnBWhwf5pz5Vvd0/7pV1clZhFTZCZ ejEWwA1wdG8= ------577A3B05A6125877ABFE1DF869EB179A--
Hey @michael, for your next project after this, could we get something like a OpenDime:
Oh, you mean like RFC-HWAPPLIC-6?
Jokes aside, thanks to your enthusiasm I added that RFC to the list of hardware projects that might follow a successful hardware wallet campaign. Just search for 'HW' or 'RFC' in the forums to review payment processors, ATM devices, and other non software projects.
OpenDime is already on the radar (see 'Other Requirements' and 'Project Plan') in this proposal as well, but as you know the use case diverges too much to make a combined wallet and bond device. We're looking at OpenDime in this wallet design for use of its one way physical tamper resistant feature, for example.
Lastly, thanks Ms. or Mr. antw081 for the investment, excellent choice!
Question: Are we stenciling or using a solder jet printer?
Answer: Solder jet printers are six figure machines not within budget. We're not using stencils either however, since the (on hand) Voltera machine that can print traces is able to apply solder paste as well.
Just curious, why are you planning to assemble the hardware yourself? For 500-1000 units it seems like something like pcbway.com would be much cheaper for fully assembled boards vs. all the pick and place etc.
It's likely that we'll do quite a variety of assembly methods requiring rough or fine grained hand placement (even rework and soldering) as well as machine placement and variable controlled reflow.
Your question seems to imply we'll have use of machinery that can produce in thousands. I've checked it out but this would cost twenty times our machinery budget and is not part of the plan. The on-hand machinery plus planned purchase will allow for (1) handfull of boards with QFN, BGA, and possibly 0201 sizes, (2) dozens of boards in a day's work to distribute for testing, and possibly (3) low hundreds of boards without going to a contract manufacturer.
If you're not sure which of the advantages are of avoiding contract manufacturers, that's another question. And finally, you're right that if we try to produce in high hundreds or thousands, that a contract manufacturer would do the PCBA. I'm hopeful this is the case before DefCon for example, which depends on a few variables however.
Yes, your last paragraph is more along the lines of my question: what do you consider are the advantages of avoiding a contract manufacturer? I didn't mean to imply that you'd use machines that could produce thousands.
I only ask because I work as a designer and my company has similar equipment to what you list for building prototypes, but we rarely use it even for only 5-10 boards, mostly because of the set up time involved. You'll have to get the PCBs made anyhow, so why not have them assembled? For example, you can get 5 4-layer boards fully assembled from pcbway.com for about $500-$700. Even if you budget $1000 per revision and you need 5 revs that's still only roughly 50 XMR (at current rates). Any rework you have to do by hand can be done either way the boards are initially assembled.
It seems like you're going to set up a whole prototyping lab for a single board design, which just doesn't seem like the best use of resources. The prototyping houses can do QFN, BGA and 0201 components without issue. You also have the advantage of being able to immediately go to hundreds or thousands of units simply with a few clicks without concern about differences between your manufacturing and theirs.
I'm not trying to be overly critical, and I only comment because I'd be interested in donating.
We'll start with 0805, TSSOP, SOIC, and DFN/QFN .5mm where needed. This will be the developer large model and we'll possibly maintain it to the end (delivering two designs.) As tests progress we'll miniaturize to BGA and 0201 size if possible. It's likely some compromises will be made, since generations of BGA and 0201 based testing is quite ambitious. Placing with vision will be okay but I'm worried about pasting such fine pitch, know what I mean?
>It seems like you're going to set up a whole prototyping lab for a single board design
I'm pretty sure there will be several dozen different board designs which we need to somehow print and quickly populate. The single board design is the product of testing those dozen circuits.
Advantages of Avoidance
Avoiding a contract manufacturer during fast paced (likely more than five generations) of PCB design changes and retesting cuts time down to 3-4 months, which is vital.
Disadvantages of Contract Manufacturing
I've learned the hard way that sending orders to Shenzhen leads to a 10-20% failure rate even when no fine pitch is specified. Chinese communication, and shipping delay has nearly sunk projects for me in the past.
Changes to design while they're configuring the order are not possible. Small changes between boards of a dozen batch are not possible.
Shenzhen express delivery takes up to a month in the E.C., with three weeks customs wait. Paying the prices you mentioned (500-700 USD) seems accurate, and must be repeated for each (of ten?) revs. The math doesn't add up, as we only have six months. The cost however does add up, and we end up paying half or more the price of a machine.
To survive customs and avoid delay, local PCBA service is possible. Multi-CB is a good shop but they want about twice the price of Shenzhen. Another is EEPD, which I've checked with and they refuse any order under 1000 boards.
Our workflow plans a hybrid between contract manufacturing (which we'll still use for printing the alpha devices to send out) and in house rapid prototyping between the few alpha releases.
Advantages of Contract Manufacturing
Yes they exist! And hopes are that once a nonchanging design appears (after prototyping) that we'll send an order to a PCBA contract manufacturer for many many boards. This is part of the 'Continuation Plan' and depends on design and demand.
Services like Macrofab (or Waveshare?) will probably be part of our one page marketing document so that any Monero community member can send off an order for a dozen assembled boards without spending hundreds in service or learning chinese.
Zonefinder, what do you know about new (Macrofab-like) PCBA services? Are they a good alternative to the Shenzhen PCBA fabs?
>we rarely use it even for only 5-10 boards
Would you please give guidance on how practical it is to set up a PnP with vision and PCBs with fiducials (obviously) for a low number of boards if the component placement changes only slightly.
I'm asking since I've spent days hand placing and reworking, especially when DFN/QFN is in use.
Wouldn't it be possible in the worst case to place all parts that don't change between revisions while hand placing the few that do?
Another quick question: without the secure element for private key storage (which may not exist for our purposes) and no software, what makes the hardware wallet specific to Monero?
The worst case scenario as described in the section 'Degree of Success' would still lead to a unique circuit compared to other contending designs. In the requirements list you'll find features like dual MCU, supercap peace of mind (supported by cheap replacement), or dual (light and machanical) intrusion detection. Others defend against CPA and border search in software and sketchy (tell lie to agents) methodology, and no decapsulation defense at all. We defend against all these things with hardware layers at nearly (except for the optional dual MCU) no extra cost.
While these things are not mathematically (source code equivalent) unique to Monero, they accompany the unique reasons someone would choose Monero over another currency. The non worst case scenario includes ED25519 in hardware or locked ROM secrets or both.
We have yet to even research what Texas Instruments or NXP offer, but it's probably CryptoCell. Such in depth research is part of the project, and is accelerated by help from folks like lightfighter (see below.)
I did some basic research comparing a few of the options for secure elements available on the market. This is definitely an introductory glance at what is out there. Hoping the more experienced hardware devs will add criticisms/contributions to this list.
At least at first glance, the Nordic chip (nrf52840) appears to be the best fit given the hardware wallet's design goals. STM32 appears to be the worst fit since it only ships ed25519 support in binary blobs.
- Open source firmware for crypto library (cec1702_hw_blks_b0_build_0300.zip:Source/hw_blks_B0/kernel/skern/source/crypto/ecdsa/ecdsa_app.c)
- Open source development tools (based on ARM-Cortex-M4 architecture)
- Support for ECC in hardware
- Default ECDSA uses p256
- May contain binary blobs (requires reverse engineering)
- Open source development kit (currently Preview release)
- Open source development tools (based on ARM-Cortex-M4 architecture)
- Proprietary portions irrelevant to Monero (Enhanced ShockBurst)
- Support for ed25519 in hardware (CryptoCell)
- Nordic CryptoCell Library
- crys_ec_edw_api in CryptoCell API for ed25519 curve
- May be able to use CryptoCell chip independently
- CryptoCell API for ed25519:
- CryptoCell-312 reference firmware available directly from ARM:
- Default ECDSA and ECC implementations use p256
- Built for bluetooth-le, may need to remove unwanted components
- CryptoCell-312 is part of ARM TrustZone (prior exploits)
STM32 UM1924 (Crypto Library)
- Support for ed25519 in software
- Works on a number of different chips in the STM32 series
- Library shipped as object code (requires reversing)
- CryptoCell API header:
- Implements ed25519 in software
It seems Maxim Integrated has a secure element in production as well, for example the MAX32550 with ECDSA. They don't specify much in the abridged datasheet however, because an NDA is required to get the full documentation. Another problem is that the only package sizes are 8mm X 8mm with ,65mm pitch BGA, which is quite difficult to work with.
It's still worth pursuing as a possible integration, especially if we find out they support Koblitz or even better 25519 curves.
This is pretty awesome, your search came up with a few new options not explored yet.
Relevant due to Ledger's integration to their new, expensive, and open (!) Bluetooth equipped design (Ledger Blue.) It would be good for the design to be partially compatible with other contending designs. Like you say, it's too bad that the crypto happens insecurely in the ARM MCU. Still worth researching though.
CryptoCell implementations (both ARM and Nordic) can be useful since the code is open, we can just copy the source code into firmware. In the best case, the crypto is done in hardware but I don't see guarantees after reading assorted docs:
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Fcryptocell_example.html http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Fgroup__cryptocell__api.html http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fcc_chapter.html
The Nordic variation would give us a Bluetooth option at no extra cost. Do you think some folks would like 100% assurance there is no RF going on, or would this be a positive development? Putting in a nRF would kill our 'airgap' feature, but that's not a big deal.
I like this option since it's cheap (0.65 USD), good (die mesh, fused locks, slot arch), and accessible over simple I2C or 1-wire. But it would only allow for firmware verification (using any choice of supported crypto) since ED25519 is not supported as you discovered.
Do you see the value in the ROM locking ability of the Atmel ICs, and have you found anything similar in the other options? I'd like to use one of the 16 slots for a 'Monero Hardware Project' key and lock it down (meaning blowing internal fuses.) That's a pretty hard to beat arrangement for firmware verification.
These folks have a circuit called 'Cinterion' that seems to resemble 'CryptoCell.' Suffers from poor documentation though, and probably requires NDA terms. Maybe even JavaCard as a disadvantage on top of that, I'm not sure.
Thanks again for the excellent ideas.
> Do you think some folks would like 100% assurance there is no RF going on, or would this be a positive development?
I can't speak for anyone else, but would personally prefer no RF. The advantage of being able to wirelessly connect to other devices (phone, laptop) doesn't seem to outweigh the risk profile bluetooth presents.
> Do you see the value in the ROM locking ability of the Atmel ICs, and have you found anything similar in the other options?
ROM locking is a great idea. If none of the stronger protections of a full secure element are possible, this definitely seems like a good fallback.
Are you suggesting using one of these chips in addition to the SE?
Full disclosure: I didn't really look into ROM locking ICs while researching SE options.
Gemalto's Cinterion card fits a lot of the project's requirements, but the JavaCard aspect you mentioned seems like a huge downfall. There isn't a month that goes by without new security vulnerabilities being disclosed against Java software. Not sure how much of that applies to JavaCard specifically, but it seems like an unnecessary risk if better options are available.
Thanks for the positive feedback. I'll keep looking into different paths for a secure design.
>> Do you think some folks would like 100% assurance there is no RF going on, or would this be a positive development?
>I can't speak for anyone else, but would personally prefer no RF. The advantage of being able to wirelessly connect to other devices (phone, laptop) doesn't seem to outweigh the risk profile bluetooth presents.
My best guess is that the Ledger folks are going to maintain the Nano and Blue in parallel, in order to cater to both crowds. I'll buy/build a Ledger Blue but will never store coins on it, for none other than the perception of increased risk of passive data theft.
I know it's not a high risk, but then again we have ugly things recently damaging Bluetooth's almost perfect security record. Hmm, BlueBorne?
>> Do you see the value in the ROM locking ability of the Atmel ICs, and have you found anything similar in the other options?
>Are you suggesting using one of these chips in addition to the SE?
They are so cheap, that yes I'm suggesting at least building the I2C circuit onto the board. If it turns out that we can't use the Atmel IC or whatever, we just leave the part unpopulated. SOIC is the largest footprint and I think there are smaller ones, so the minimal real estate needed might support this strategy.
>Full disclosure: I didn't really look into ROM locking ICs while researching SE options.
Nice of you to admit that. It's going to take a massive effort to figure out which of our options have locking ROMs or whatever their similar technology is and which marketing term they use at describing it.
My biggest fear is that they simply offer no data locking whatsoever. But we can integrate the Atmels then for a half locked design and cross fingers when the next generation of ICs comes out next year.
>Gemalto's Cinterion card fits a lot of the project's requirements, but the JavaCard aspect you mentioned seems like a huge downfall. There isn't a month that goes by without new security vulnerabilities being disclosed against Java software. Not sure how much of that applies to JavaCard specifically, but it seems like an unnecessary risk if better options are available.
Not only security flaws, but I believe there are few (or none?) implementations of the required JavaCard features that Cinterion provides an API for. If we tried to do standard MCU SE development plus I2C and on top of that JavaCard we've got too much work.
>Thanks for the positive feedback. I'll keep looking into different paths for a secure design.
Please do, of all the technical feedback we've had yours is really the best. Thanks again.
Question: Can this work be sold to an investor?
Answer: No, due to the ownership, copyright, and license terms. It belongs to the Monero Project, so selling it is only as (doubtfully) realistic as selling any other part of the Monero Project.
Question: Can manufactured devices based on this work be sold?
Answer: Yes, for example please make a ecommerce shopping site (http://shop.getmonero.org/) using Serhack's Prestashop XMR software and fund your (Kovri|RingCT|Mobile) project with the proceeds. The whole community is behind you when doing so.