status-im
/
hardwallet-firmware
mirror of https://github.com/status-im/hardwallet-firmware.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

update documentation with input from Slack discussion

This commit is contained in:
Michele Balistreri 2018-05-21 20:03:18 +03:00
parent 30497d742d
commit 0c3fb7499a
2 changed files with 10 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -1,14 +1,14 @@
# Hardware Wallet Pro
This repository contains the Hardware Wallet Pro firmware as well technical documentation.
This repository contains the Hardware Wallet Pro firmware as well as technical documentation.
## Introduction
The Hardware Wallet Pro is a SNT and Ethereum hardware wallet which integrates with the Status application. The device is responsible for generating a HD wallet and for signing transactions in a way that the keys never leave the hardware wallet. It provides 2FA by requiring a PIN to sign transactions.
The Hardware Wallet Pro is an Ethereum and ERC20 (possibly BTC, too) hardware wallet which integrates with the Status application. The device is responsible for generating a HD wallet and for signing transactions in a way that the keys never leave the hardware wallet. It provides 2FA by requiring a PIN to sign transactions.
## Physical characteristics
The device will be credit-card sized, have a custom segmented LCD and one (or more) buttons. It will have a rechargeable battery and a bluetooth module.
The device will be credit-card sized, have a custom segmented LCD and two buttons. It will have a rechargeable battery and a bluetooth module.
## More info

38
docs/UI.md
View File

@ -1,6 +1,6 @@
# HW Pro UI
Being a widget with a segmented display and a limited number of physical buttons (possibly one), defining the UI is crucial to determine which features we can support and even what security measures can be implemented.
Being a widget with a segmented display and two buttons, defining the UI is crucial to determine which features we can support and even what security measures can be implemented.
## Security related issues
@ -8,40 +8,16 @@ To maximize security the device should require all sensitive input to come from
## Input
The device will have either capacitive touch buttons or resistive ones. Buttons take PCB space and MCU I/O lines so the device will have to use a limited amount of them. Here are some options that we have to discuss
The device will have either capacitive touch buttons or resistive ones (cheaper/highly realiable, but require a flexible dome-like structure with a conductive pad if we want a sealed device to avoid exposing contacts). The device will have two buttons, UP and DOWN. If we go for capacitative buttons we might design them as to be two halves of a circle. The other option is placing classic round buttons next to each other.
### Single button option
Giving a single button means eithe relying on external input for most things or using timing to encode additional information. A proposed solution is like this
1. If the device is off, pressing the button turns it on
2. If any other state, a long press of 2 seconds cancels the current task, 4 seconds turn the device off (actual time may vary)
3. If we are doing pin entry, a short press means +1 and a long press means confirm.
4. Theoretically mnemonics can be entered in the same way, but it would be extremely tedious. To make things much faster, after each letter is entered only letters available in the remaining list of possible works are shown. Also only the unique part of the word needs to be entered
5. In other situations a short press means OK, a longer one means cancel.
Delegating PIN and mnemonics entry (the latter used to restore from backup) to the mobile device is possible but a very bad idea, especially with regards to the mnemonics (since these alone are enough to do anything with the coins/tokens on the account).
The advantage of this method is that it the minimum cost in terms of PCB space, components and I/O lines.
The disadvantage is convenience. If the PIN is 9285 for example and we start from 0000 the user has to press 9 times shortly and one time long, then 2 times short and 1 long, 8 short and 1 long, 5 short and 1 long.
### Two buttons options
Using two buttons (UP/DOWN) we can separate the OK/Cancel and Increase/Decrease functionality so
The interaction will go as follows:
1. If the device is off, pressing any button turns it on
2. If it is on, pressing the cancel button long enough turns it off
3. PIN entry would go as follow: UP goes to next number, DOWN to previous, in a cyclic manner. Pressing UP longer confirms, pressing down longer deletes the last digit (if no digit has been entered, cancels PIN entry)
4. Mnemonic entry goes the same way, with the same shortcut described above
2. If it is on, pressing the DOWN button long enough turns it off
3. PIN entry would go as follow: UP increases the digit, DOWN decreases it, in a cyclic manner (pressing DOWN when you have 0 gives you 9, pressing up when you have 9 gives 0). Pressing UP longer confirms the digit (if it is the last one, confirms the whole PIN). Pressing down longer deletes the last digit (if no digit has been entered, cancels PIN entry)
4. Mnemonic entry goes the same way, with the same shortcut described above. To make things faster, after each letter is entered only letters available in the remaining list of possible words are shown. Also only the unique part of the word needs to be entered (I think the first 4 letters are enough?)
5. In other situations, UP means OK, DOWN means cancel.
This increases convenience (the previous example with PIN 9285 becomes DOWN, UPlong, UP, UP, UPlong, DOWN, DOWN, UPlong, UP, UP, UP, UP, UP, UPlong which is only 14 keypresses compared to 28 of the previous example, at least if the user takes the shortest path. The cost is at least 1 additional I/O line, some PCB space and a capacitor is we used capacitative buttons.
### Scroll wheel
A rough touch scroll wheel could be implemented as three-capacitative buttons and a larger one in the middle. PIN/mnemonics entry would be sped up by using clockwise/counterclockwise rotation to increase/decrease and the center button to confirm. This avoids long presses altogether. Additionally the 3 scrollwheel segment can be assigned functions of their own since they are still buttons. Altough quite convenient the cost in PCB space is quite large, since the wheel would need to be rather large to be useable. It is also equivalent to 4 buttons in terms I/O lines and component usage. This can only be implemented with capacitative buttons
## Output
The output device will be a segment-based LCD display. Most segments will be used for numerical/alphanumerical address characters, while some will be for custom icons. The MCU used is able to drive LCD screens directly, up to a theoretical 320 segments (multiplexed 8x40, thus requiring 48 pins). The problem is that some LCD pins are multiplexed to other devices (such as SPI, Touch Sense Controller) and thus not all channels are actually available in our case and in the end the safer choice is to keep it at around half of that. Also the more segments we drive, the more power we are going to use. PCB space increases because of the additional tracks and possibly using a larger version of the same MCU with more pins. Also a screen with more segments might need to be physically larger to be legible. If we really need more segments that the MCU can provide, we will need an external LCD controller which adds cost and requires extra PCB space. Chip-On-Glass LCD (controller is in the screen itself) is also possible, but the costs are much higher than the other solutions.
@ -50,7 +26,7 @@ At the same time, we need to be able to display as much information as possible
As it happens, cryptocurrency transactions are probably the worst case scenario for devices with limited screen estate, since they usually contain many digits and addresses are long. For this reason we will have to find some compromises.
We will need space for some icons, such as the currency icon (ETH, SNT), battery icon (with 3 bars).
We will need space for some icons, such as the currency icon (ETH, ERC20), battery icon (with 3 bars).
The main decision points are