Please login or register.

Dedicated Monero Hardware Wallet

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 4 years ago Weight: 0 | Link [ - ]

There has been lively debate this week on a reddit thread, with good (both pro and contra) arguments and a number of questions and answers.

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

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.

lightfighter edited 4 years ago Replies: 2 | Weight: 0 | Link [ - ]

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.

Microchip

ATECC508A

Microchip ATECC508A

Pros
  • 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
Cons
  • Default ECDSA uses p256
  • May contain binary blobs (requires reverse engineering)

Nordic

nrf52840

Pros
  • 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)
  • May be able to use CryptoCell chip independently
  • CryptoCell API for ed25519:
    • nRF5_SDK_14.0.0_3bcc1f7/external/nrf_cc310/include/crys_ec_edw_api.h
  • CryptoCell-312 reference firmware available directly from ARM:
Cons
  • 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)

ARM

CryptoCell-300 Series

CryptoCell ARM site

ST

STM32L4 DigiKey listing

STM32 UM1924 (Crypto Library)

Pros
  • Support for ed25519 in software
  • Works on a number of different chips in the STM32 series
Cons
  • Library shipped as object code (requires reversing)
    • STM32CubeExpansion_Crypto_V3.1.0/AccHw_Crypto/STM32L4/Middlewares/ST/STM32_Crypto_AccHw/Lib/libSTM32AccHwCryptoV3.1.0_L4_GCC.a
    • CryptoCell API header:
    • STM32CubeExpansion_Crypto_V3.1.0/AccHw_Crypto/STM32L4/Middlewares/ST/STM32_Crypto_AccHw/Inc/ECC/AccHw_ecc.h
  • Implements ed25519 in software
    • STM32CubeExpansion_Crypto_V3.1.0/AccHw_Crypto/STM32L4/Middlewares/ST/STM32_Crypto/Inc/ED25519/ed25519.h
Reply to: lightfighter
michael posted 4 years ago Weight: 0 | Link [ - ]

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.

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

This is pretty awesome, your search came up with a few new options not explored yet.

STM32L4

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.

Cortex-M(0|4) bundles

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.

ATECC508A

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.

ROM Lock

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.

Gemalto

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.

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

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

Reply to: lightfighter michael lightfighter
michael edited 4 years ago Weight: 0 | Link [ - ]

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

Reply to: lightfighter michael lightfighter
michael edited 4 years ago Weight: 0 | Link [ - ]

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

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

Question: Monero XMR value is too volatile, can we edit this proposal to list costs in fiat currency?

Answer 1: No, this proposal should remain Monero based.
Answer 2: If you want to propose a similar project without budgeting in Monero XMR, just copy all relevant text. The project is fully Opensource and Michael is happy to play a role.

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

Question: Can we stop using Monero's Forum, XMR, and FFS? Can we start using a competing method like Indiegogo, Y Combinator, Initial Coin Offering, Kickstarter, or Tindie?

Answer: Yes, if you:

  • Learn how the foreign platform works
  • Do the communication and accounting

...then Michael will carry out all obligations of this proposal in your method of choice.

philip_rhoades posted 4 years ago Replies: 1 | Weight: 0 | Link [ - ]

Very exciting stuff! I have just gotten involved with Monero and I hope to contribute in the near future.

Many thanks Michael!

Reply to: philip_rhoades
michael posted 4 years ago Weight: 0 | Link [ - ]

Hello Philip,

It's great to hear your enthusiasm. The best way to keep informed, get a board, or help the project with your good comments, is to become a team member.

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

Question: Does this proposal resemble the structure of typical crowdfunding campaigns?

Answer 1: This FFS proposal shares certain crowdfunding features like early hardware shipments to donors.
Answer 2: Only the minimum administration and bureaucracy is carried out, so the degree of FFS similarity to other funding platforms requires an analysis few are interested to do.

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

Question: Why are the costs so much?

Answer 1: Hardware design requires a lab equipped with physical devices. The machines already bought for this project each cost between €1000 and €10,000. Others are yet to be acquired.
Answer 2: The nature (proximity to lab and lead time of contract manufacturing) of tasks prohibits concurrent work, leading to loss of contracts during the six month period.
Answer 3: Limits of in house engineering require expensive third party contracts like decapping service or possibly scanning electron microscopy.
Answer 4: A floor function has been applied to the hour estimate.

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

Milestone 4 Complete

Contending firmware integration

We succeeded in programming a cloned bootloader and firmware stack from contending hardware models, and worked to accelerate custom firmware development. We succeeded far enough to render outside firmware integration obsolete.

Prototype showcasing and QA

We showcased all over the 34C3 venue and distributed prototypes, while officially demonstrating two prototype models.

Contending hardware research

We ported contending circuit designs, and reported after meeting technology leaders of respective firms. In lab research of own and contending circuits provided clues to USB-C migration.

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

Question: Will the project fail due to underestimation?

Answer: No, there are no underestimated values. The approximations of resources, budget, and duration needed are based on past experience and accurate enough to properly manage the project.

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

Milestone 5 Complete

Midterm remix

We completed a third prototype design, blending features and tricks learned from the first two generations. This will fit a Chip Whisperer for advanced timing, CPA, and voltage glitch testing. Unique features in design allow for operation under observation of a test harness, tethered operation accompanied with a USB-C connected computer, untethered operation with USB-C power, or untethered operation with DC or battery power.

Monero features

We received and designed provisional battery and DC intake circuits to support detethered operation, as well as tested custom Monerujo firmware proving detethed mode viable. We designed a off chip coprocessing circuit enabling hybrid MCU to secure MCU cryptography over a SPI bus. To facilitate timing we repurposed unused GPIOs to act as polling triggers. While porting schematics, we implemented a dual display connector and built out relationships to display vendors of Monero unique OLED sizes.

New packages

We replaced SOIC packages with DFN which enables placing secure elements on the same layer as other components.

Secure elements

We received samples of nRF52840 and bought CEC1702 MCUs, along with developer kits by Mikroeletronika to accelerate integration.

FOSDEM showcase

We shared the stage with hyc at FOSDEM, and showcased two detethered prototypes with different firmware.

fluffypony edited 4 years ago Replies: 1 | Weight: 0 | Link [ - ]

Donated 300 XMR from the general donation fund

Reply to: fluffypony
michael posted 4 years ago Weight: 0 | Link [ - ]

Thanks fluffypony. You could have donated 1/2 XMR and the symbolic value would have been big.

pa edited 4 years ago Replies: 1 | Weight: 0 | Link [ - ]

donated 200 xmr

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

Thanks pa, very generous.

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

This project has started and occupies a Taiga account at:
https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/

Hueristic posted 4 years ago Replies: 1 | Weight: 0 | Link [ - ]

Hi, Following this and had a question, does "Airgap: Disconnected media option³" cover physical disconnect of Antenna? If not I would make sure there is a means (even just a jumper) of physically disconnecting the antenna(s).

Also you misspelled "negociation". ;)

Looks like very professional project going on here, Kudos. :)

Reply to: Hueristic
michael posted 4 years ago Weight: 0 | Link [ - ]

Hello Hueristic,

Your impression is correct. We want to either completely disable RF, or at least give the user an option to do so temporarily. The feature could be opt in or opt out, depending on which transport (NFC, Bluetooth) or other considerations to be made after research. A pin or solder jumper might be okay, or a 0 ohm resistor or unpopulated pads. Lots of possibilities.

If you've thought this through, then definitely give your opinion. Please do it in our project management rather than this forum. That's where it really counts.