Please login or register.
This location

Dedicated Monero Hardware Wallet

michael posted this 7 years ago

michael | 7 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/

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!

Status

The status of this proposal is:

PENDING FUNDING PLEDGES

Change Log

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

Monero Hardware Wallet

Requirements

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.

Nonfunctional Requirements

  • 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

Functional Requirements

  • 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

Secure Element

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.

Vendor Proposal

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.

Other Requirements

  • Review of requirements from the existing designs of Ledger, Trezor, and KeepKey
  • Blend of features from peripheral devices like Opendime, Mooltipass, and Cryptosteel

Deliverables

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.

Scope Creep

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.

Author

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

Privacy

If you look carefully, you will find the privacy sensitive software development Michael has done for high profile groups.

Motivation

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.)

Rejection

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.

Defunding

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.

Relations

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.

Budget

Production machinery

XMR Item
5 Qinsi QS-5100 reflow oven
45 Analog stereo microscope
150 NeoDen4 Pick and Place
200 Total machinery

Research equipment

XMR Item
1 Trezor
1 KeepKey
4 Ledgers
6 Chipwhisp
2 Launchpad
<1 Opendime
15 Total research

Passive and IC components

XMR Item
20 Total components

Consumable materials

XMR Item
25 Paste, substrate, nozzles

Facilities and services

XMR Item
2 Makerspace entry
68 Workspace rental
12 Datacenter, telco
80 Total facilities

Travel and promotion

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.)

Worktime reimbursement

XMR Item
490 Lost contracts reimbursement⁷

⁷ Estimated by crossing vectors (6 months lapse, proximity obligation, hour loss) and considering used nonworktime procurements.

XMR Volatility

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.

Total budget

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 €.

Existing Resources

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.

Nonexistent Resources

Any tools needed (see 'Production machinery') should be purchased in the first month (see 'Project Plan'), in order to avoid postponement of milestones.

Time Estimate

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

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 introduced by contract manufacturing as well as increase the turn around time of generational testing.

Integration

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.

Design

A schematic diagram is designed using KiCad or equivalent Opensource software. A layout is derived from the schematic and integration work.

Printing

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.

Pasting

An Sn63Pb37 alloy is applied to the substrate with an injection based solder printer.

Assembly

The board is populated (stuffed) with components in a standard pick and place procedure. Manual placing is avoided due to error and delay concerns.

Reflow

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.

Rework

Bridged solder pads, air wires, and other mistakes are corrected.

Testing

Electrical and optical tests are manually done to identify manufacturing problems. This may include stereoscopic magnification or controlled destruction.

Programming

MCU and external flash programming applies primitive bootloader and firmware interface images.

Generation

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.

Samples

Production samples are mailed to investors, testers, and promoters identified during Monero meetings.

Project Plan

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 Reports

Progress is reported in bimonthly Monero developer meetings on the IRC developer channel.

Continuation Plan (Pending New RFC and Revote)

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

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) 2017-2018, The Monero Project.

License

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:

  • Poison pill
  • Conciseness
  • Bodaciousness
  • Lack of lame conditions
  • Lack of Eric Raymond complaints
  • Adoption by other like minded projects

Legal Summary

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.

Intentions

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.

Brainstorm

This project proposal was first discussed by Michael, endogenic, and anonimal at the Monero themed party during DefCon 2017.

Inclusion

Teamwork and collaboration from any competent person is encouraged. Outreach to other hardware makers mutually benefits the respective communities.

Promotion

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.

Replies: 78
michael posted 6 years ago Weight: 0 | Link [ - ]

Milestone 6 Complete

Endterm results

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.

Rare failure

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.

Release prints

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.

Intrusion detection

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.

Battery operation

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.

Secure MCU

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:

  • Off chip program storage
  • On chip Ed25519 and Curve25519
  • Immutable boot (for secure boot)
  • One time programming (OTP) key storage

…as well as a number of less important new features such as timing defense, power variance, and breathing light circuitry.

Security BSides

We served the community of European security enthusiasts at Security BSides in Munich, presenting The first Monero Hardware Wallet with hands on samples inspection.

Mechanical engineering

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

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

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.

Format sizing

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.

Closing video

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.

serhack edited 7 years ago Replies: 1 | Weight: 0 | Link [ - ]

Donated

Reply to: serhack
michael posted 7 years ago Weight: 0 | Link [ - ]

Very helpful serhack, thanks.

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

Milestone 2 Complete

Configuration and documentation

Several tooling tasks such as Create tool configurations story 3, Test accuracy of reflow sensors [task 20], and (https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/task/20/), and Panelise designs task 147 concluded successfully and is closed.

Priority documentation tasks concluded successfully as well, including a number of wiki pages and Maintain documentation story 4

Our conduct of Opendime research ended prematurely, after it became clear that their architecture (Cortex M0+) and closed source design doesn't relate or is not technically possible to integrate. There were online discussions however, relating to the communities' interest in a off chain anonymous disposable bond device. The main discussion thread was abandoned.

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

Milestone 3 Complete

Secure element research

Work to research and integrate an appropriate secure element proves to be a moving target as new models appear and our needs become more clear. Several vendors have mandated nondisclosure agreement terms which we have rejected out of hand thus restricting our choice to Nordic Semiconductor, Atmel, and Microchip. While improving circuits using this technology will be a daily part of the project, we have come to terms with limiting our research and beginning implementation according to a collection of tasks in the user story 6 called Debug secure elements.

Trezor and Ledger porting

The recent Ledger derived port described in story 2 and cancelled Trezor port (because our own Monezor design too closely resembles it) described in story 68 concluded, yielding important circuit information that we plan to integrate in future prototype designs. We met with the technology leadership of the corresponding companies, to complete outreach described in story 113.

We additionally learned from research of Digital Bitbox circuitry, after outreach to the designers at Shift Devices.

Divergence from stretch goals

While not belonging to requirements, several have attempted to create a cryptochip using FPGA technology and this considerably complex effort is moving understandably slow.

zonefinder posted 7 years ago Replies: 1 | Weight: 0 | Link [ - ]

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.

Reply to: zonefinder
michael posted 7 years ago Replies: 1 | Weight: 0 | Link [ - ]

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.

Reply to: michael zonefinder
zonefinder posted 7 years ago Replies: 2 | Weight: 0 | Link [ - ]

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.

Reply to: zonefinder michael zonefinder
michael edited 7 years ago Weight: 0 | Link [ - ]

Fine Pitch

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.

Considered Alternatives

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.

Planned Method

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?

Reply to: zonefinder michael zonefinder
michael edited 7 years ago Weight: 0 | Link [ - ]

>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?

zonefinder posted 7 years ago Replies: 1 | Weight: 0 | Link [ - ]

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?

Reply to: zonefinder
michael edited 7 years ago Weight: 0 | Link [ - ]

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.)