search

status-im / swarms

Swarm Home. New, completed and in-progress features for Status
92 stars 31 forks source link

Hardware Wallet Pro #229

Closed bitgamma closed 5 years ago

bitgamma commented 6 years ago

Summary

We currently have a Javacard based hardware wallet implementation. This is a simple and inexpensive hardware wallet with good security. The main limitations of this solution are

  1. Requires a SmartCard reader on the host
  2. Transaction data (amount, address) is displayed on the possibly compromised host device, the card has no screen
  3. The seed is currently partially generated off-card because of JavaCard limitations
  4. Limited API does not allow much room in terms of additional features. We already stretch the limit of what JavaCard can do by a far amount with our hardware wallet, which means that clever tricks and workarounds had to be implemented in a few cases.

The proposal is to create a Pro version of the hardware wallet not based on the JavaCard platform and removing these limitations. This Pro version will have a significantly higher cost that then JavaCard one, since it will be a more complex device.

Swarm Participants

Product Overview

The product will be a HD hardware wallet with its own screen and input buttons used to display and confirm transactions. The seed will be generated on card and mnemonics will be displayed on the card screen as to never reach the mobile device. Communication with mobile/desktop clients will happen through BLE. The device will be powered by its own rechargeable battery (inductive charger). Ideally, the physical size will match that of a standard smart card.

Security and Privacy Implications

As with any hardware wallet security is a prime concern. The device must be engineered to cope at least with the following threats

  1. Data sniffing - this can be solved by encrypting the communication with the client device
  2. Data injection - communication with the client device must be authenticated
  3. User impersonation - beside possessing the card, the user must be authenticated by a PIN (the "something you know" factor)
  4. Tampering of the software - Firmware must be either non-upgradable (less flexible, makes it impossible to fix existing bugs) or the upgrade procedure must be implemented in a secure way
  5. Tampering of the hardware - It should be cost prohibitive to tamper with the hardware to read data or write malicious data. With the correct production techniques the device will be destroyed by disassembling.

Phase 1

Goal Date: Start of Q4 2018 Description: A prototype should be built using an STM32 Nucleo development board with a Bluetooth shield. This will allow writing most of the firmware. During this phase the UI must be designed. This means the design of a custom segment-based LCD and the design of how the user will interact with the device.

Phase 2

Goal Date: End Q4 2018

Description: At the beginning of Q4, the new STM32WB chip will be available. This component integrates a bluetooth stack and a STM32L4 core in a single chip while also providing hw-accelerated encryption and key management. The firmware must be ported to this platform, which will be the platform used by the actual product

Phase 3

Goal Date: TBD

Description: In this phase the final product design, PCB design and BOM must be finalized and a manufacturer must be chosen

Phase 4

Goal Date: TBD

Description: Stock and distribution

Copyright

Copyright and related rights waived via CC0.

0xc1c4da commented 6 years ago

I'll join this initiative

oskarth commented 6 years ago

Great to see this initiative getting off the ground, really exciting stuff!

Would you mind issuing a pull request with this template filled in https://github.com/status-im/ideas/blob/master/TEMPLATE.md? This way we can track progress of the idea and it will show up here: https://ideas.status.im/all

bitgamma commented 6 years ago

@oskarth Yes, I was preparing the pull request. Now it is ready as PR #235

oskarth commented 5 years ago

Closing to reflect current issue state.