Please login or register.

Dedicated Monero Hardware Wallet

Version: 1.0
Date: 15 September 2017
Author: Michael Schloh von Bennewitz
Contact: [email protected]
IRC-contacts: msvb-lab, msvb-mob
Title: Dedicated Monero Hardware Wallet

Get Monero Hardware Wallets

"There are currently no hardware wallets available at this time. Please check back for updates."
-, 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:


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


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


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.


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.



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.


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


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.

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


⁸ 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


The Monero Project owns this (Opensource) proposal, the blueprint-like result of a month's careful deliberation and research. The author contributed it by uploading content to the forum. Readers are free to print and hand it to investors, colleagues, university professors, or whoever else, in order to start a hardware project of their own.


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


CERN Open Hardware License 1.2

Being a hardware project, no software license is used. Instead, a open hardware license is applied whose terms resemble the other Monero projects' (BSD|MIT) licenses. Patents are more relevant to hardware projects so to counter risk of conflict the CERN OHL is used.

Note: While deliberating between TAPR and CERN, online chats led to a preference for CERN due to its:

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


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.

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

Milestone 1 Complete

Initialisation work

The Initialise the Project epic #60 concluded successfuly and is closed.


We've centralised project management on Taiga and source code management on GitHub. A lot of abstract platform considerations were made such as designing several editions in parallel as well as including local post in our back and forth prototype deliveries. Although platform matters will dynamically change throughout the six month duration, the majority of them have concluded.


The Create Communication user story #132 concluded successfuly and is closed. Several niceties have surprised us, including extra appearances at physical events, two (!) interviews and articles by journalists, and legal advice. On the negative side, we tried and failed to get a Esperanto name for our GitHub repository.


Initial procurement of a number of machines, electronic components, and consumables has concluded. Documentation of this is spread throughout project planning, where many tasks (future ones as well) require a procurement step.


Some shift in priorities occurred due to an ambitious schedule for a dividend preview, as well as vendor negociation, and unexpected success with team building. For details (why some results are on time while others are ahead or behind schedule) please ask. We're publishing status reports in biweekly meetings as required by this forum proposal, however the channel changed from #monero-dev to #monero-community as stated in meetings.

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

Question: Will any generated income proceeds from sales be 'not for profit' and used to fund future projects?
Answer 1: Whoever markets and sells the deliverables can direct funds to future projects, however it's unclear if the yet to be chosen Opensource license (which one?) will be able to force a nonprofit scheme. Please give your opinion!
Answer 2: A branding system (DefCon Prerelease, Anniversary Edition, etcetera) is supported via a one page documentation 'How to Produce and Market' with the goal of assisting projects wishing to sell in order to fund their needs.

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

Hi Michael--I work at a hardware startup. Have learned quite a bit in the past few years. You may already know this stuff, but just in case not. It's one thing to produce prototypes in low volume and have it end there. It's an entirely different thing to get things to scale (even at "low" 100s/100s volumes).

Some thoughts: Past breadboarding, I would still suggest doing low volume PCB runs w/ assembly from someone like Macrofab (I know another user mentinoed PCBWay, haven't used them, but I assume it's similar) -- even for 10-50 units it will be well worth it. Your time is more valuable and there's way less room for error. It's time you could be spending on firmware development etc. while you're waiting for PCBs to come back. You'll get a better idea of more subtle issues that might crop up at scale.

You sort of have the start of this above, but it's important to get a rigorous product requirements document (PRD), together--a living document to lay out every aspect of the design and specifications that need to be met (down to the amount of force needed for a button click later on) along with state diagrams for the system. You may not be able to fill in all the details yet, but the sooner you get this going, the better. You might consider making this a living document on Google Docs (for all to see?). You will also want to put together a mechanical spec / approximate Industrial Design (it can be ugly for now) to start.

Past PCB: the great thing about PCB/EE is that it's easy to scale nowadays--much less the case on the mechanical side at scale. Given the amount of funds raised and likely mechanical simplicity of the device, I would strongly advocate paying a proper mechanical firm to finalize the ME+ID for production at scale (whether it's a few 100 or 1000+ units). Essentially getting to "Engineering Validation Test" (EVT)-ready (note: not complete EVT). While at a face value, it may seem like the sort of thing your buddy with some solidworks skills at the local makerspace can crank out, which works fine as a 3D print, you'd be surprised at just how precise the design needs to be and also account for different manufacturing processes. Expect to budget $30k-$100k for this work depending on design complexity and caliber of firm. While this may seem expensive, it will save you a TON of time and cost later on--unless you can find an ME who has done this stuff before at scale (like finding a needle in a haystack). I think it will be well worth it to get proper soft or hard tools. Alternative to a mechanical firm, an ODM (original design manufacturer) may be able to take care of this as well and also take care of your manufacture. Because I assume the design is so simple and the volume is likely "low," you probably don't need an ODM and things will probably be easy enough to assemble+QA in-house.

A good resource to keep on top of (if HW @ Scale is new for you) are the Bolt and Dragon Innovation blogs.

If this input is useful, happy to take the conversation offline over a higher throughput medium. A lot more under the hood, especially when getting ready for manufacture.

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

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.

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

Question: What is this? An rfp or a status update?
Answer: It is what the author understands as the best way to propose an FFS for a project yet to be launched. The identifier 'RFC' stands for 'request for comments', to convey meaning that the community is explicitly invited to discuss and amend the proposal.

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

Question: What are some reasons to reject this proposal?
Answer 1: It is speculated that a Monero supporting wallet might be created by waiting for the Ledger or Trezor community to produce one.
Answer 2: Once a viable hardware design is reached by this project, it might be too much work for the Monero community to complete a full scale product launch (FW, enclosure, maintenance, logistics.)

Note: A separate proposal RFC-HWALLET-2 addresses some of these concerns:

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

Question: What are the benefits of a dedicated hardware wallet as opposed to adoption of RFC-HWALLET-2?
Answer: Too complex to answer in a comment box. Possibilities include the control over roadmap, featureset, branding, IC and component choice, fostering of community identity, and decreasing risk of another year with no hw wallet.

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

Question: What is an example of a dedicated featureset?
Answer 1: It might be possible to offer a optional lock down fuse blowout of a private key's read registers.
Answer 2: To defend against border searches, this design might allow for a private key's total destruction, something existing hardware wallets don't support.

Question: What is an example of IC and component choice?
Answer: To increase firmware security and glitch defense even more, the dedicated design might contain a less expensive ST31H128 plus an additional verifier chip like the ATSHA204A.

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

It appears that more and more smart guys have figured out that the montenero community is a generous one, however the proposal at hand almost feels like trying to take advantage of this. While I really like the idea of a dedicated hardware wallet I certainly won't support this proposal in its current form, which is a premiere for me.

Reply to: drfred
anonimal posted 6 years ago Weight: 0 | Link [ - ]

>the proposal at hand almost feels like trying to take advantage of this.

I see no evidence of this.

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

Recent opinions from other sources (thanks to drfred for posting here) include...

Pro: Better to have more than one (since Trezor is problematic) viable hardware wallet for Monero users to choose from. Vendor choice is good.

Contra: The project will not succeed, or the funds are better used in other areas of Monero development.

anonimal posted 6 years ago Replies: 3 | Weight: 0 | Link [ - ]

I think this is a fine proposal and michael's community presence is an invaluable one.

>6 months at 10/hr a week for total 2000 XMR

For 2000 XMR, would you be able to work 40/hr a week? If not, the community may be more inclined to donate if the 2000 were set to 1000 or lower.

Does your budget include travel and promotion?

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

Budget Scope

>Does your budget include travel and promotion?
The budget is all inclusive. This implies the following answers:

Q: What will fund a flight/hotel from <here> to <there>?
A: It's funded by the budget as stated in this FFS proposal.

Q: What will fund the purchase of a (still outstanding) PnP machine?
A: It's funded by the budget as stated in this FFS proposal.

...get the idea?

Please stay tuned, as version 0.8 (now at 0.7) of this proposal will provide more details of budget use. See the very first line for version information and new section named Changelog.

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


>Does ... promotion?

It's likely that once tangible results appear, enough community enthusiasm follows to promote from a variety of angles. Expensive things like staffing a table at DefCon-like events (to showcase prototype models and gain worldwide recognition of Monero's viability) would be funded by the same budget.

On the radar right now:
- Privacy-oriented CCC Datenspuren
- European renowned C34C
- 33C3 BTC Relevancy
- MuCCC Hack Friday

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

Timesheet and Payment

>>6 months at 10/hr a week for total 2000 XMR
>For 2000 XMR, would you be able to work 40/hr a week?
I'm interested in a fair arrangement for all involved (whether funding with XMR or contributing in other ways.) The floor function applied to result in a 10/hr week estimate already guarantees more time spent.

Answer 1: If XMR value funds 100% of my 40/hr workweek then yes I can do that.

Answer 2: If investors agree*, then their payout obligations are paused while I take other part time work. This might be a good solution to the 'lead time' problem.
* via a weighted majority (like shareholder voting)

Lead Time Problem

Vendor lead times and other delays (shipping, customs, damage, misunderstandings) make for an irregular <number> hour work week. Project planning can partially mitigate this.

Community Agreement

Some would like a full time 40/hr per week effort while others prefer to spend less for part time results. To make matters worse, XMR value has fluctuated since this proposal began, a hard fork awaits, and there will be more instability to come.

>If not, the community may be more inclined to donate if the 2000 were set to 1000 or lower.
Good suggestion, I'll review conditions again while making changes to the proposal and versino 0.8 will reflect this.

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

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

I am curious how this would compare to the Digital Bitbox which uses the ATAES132A a "high-security chip that prevents physical extraction (50 year lifespan)"?

The Ledger Nano S also claims to use a secure element - ST31H320.

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

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.

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

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

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

Forget about qualifications, your comments are right on target. I've recently found a vendor willing to share info on the ST31H320 (no guarantee yet though) and have exchanged email and calls with the Bitbox folks in Zurich.

michael posted 6 years ago Weight: 0 | Link [ - ]
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="----577A3B05A6125877ABFE1DF869EB179A"

This is an S/MIME signed message

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
$ 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
$ diff msvb-smime.txt msvbclicrt.pem

To optionally compare the cert fingerprint:
$ openssl x509 -fingerprint -noout -in msvbclicrt.pem

To learn more about the certificate's owner:
$ openssl x509 -subject -noout -in msvbclicrt.pem

Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"


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

I just stamped my authorship signature, and did so in comments rather than modifying the text (as folks in IRC suggested.)

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


Hey @michael, for your next project after this, could we get something like a OpenDime:

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

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!