Add BTChip HW.1 Hardware Wallet

[btchip]

Hi

A pull request to include HW.1 as a new hardware wallet - based on a smartcard platform, HD, P2SH friendly.

HW.1 has been around for quite some time now (first sighted in San Jose 2013), redesigned quite a bit, and is now commercially available - it has been integrated into GreenAddress, Electrum, and other services to be announced.

Public APIs are available on https://github.com/btchip and the full technical specification is on https://btchip.github.io/btchip-doc/bitcoin-technical.html

Core devs / testers, feel free to request a sample (samples from San Jose 2013 cannot be updated yet, samples from Amsterdam 2014 are updatable on https://firmwareupdate.hardwarewallet.com)

[schildbach]

deterministaclly -> deterministically?

[btchip]

rigth

[greenaddress]

Our two Satoshis:

The smartcard has been in testing at GreenAddress and used in production for over a month, some feedback is appearing on bitcointalk/reddit as people receive their card.

The hw wallet has good documentation that allowed for very quick integration and support has been great (Nicolas was helpful and very available).

We only met Nicolas from BTChip a few weeks back and we felt they demonstrated to us to be experts/professionals in the secure smartcard/devices industry with a great Bitcoin know-how and community standing.

They are also fun but this is a story for another place :)

[saivann]

Thanks for submitting a pull request.

BTChip HW.1 seems like a cool device. However, I must say that I feel uncomfortable with bitcoin.org promoting hardware wallets that are using the pull model, without input and screen. By reading BTChip website and comments, I have learned that BTChip has tackled part of that problem by erasing the seed on the device after three failed PIN attempts.

But on the other hand, this still offers no protection against a compromised computer as soon as the right PIN is used. Considering that people often don't backup their wallets properly, it also seems uncertain to me if wiping the wallet automatically will cause more harm than good (I also feel this puts the developers in a grey area when it comes to responsibility).

In general, I am concerned that the current wallet page and the general perception that people have of hardware wallets would create a false sense of security - for instance compared to a simple password-protected desktop wallet.

Another particular case is the closed-source firmware. No client-side closed source wallet has been added on bitcoin.org before. This hasn't been discussed before, but I am not sure that crossing that line is a good idea.

[btchip]

HW.1 offers a second factor that let you review a transaction as securely as if you had a screen and button, at least if you read it on a different computer / phone. This is used with Electrum and described in the specification - see https://btchip.github.io/btchip-doc/bitcoin-technical.html#_user_validation

Wiping the wallet automatically seems fine to me - chip & pin cards have been working like that for 3 decades and a concerned developer can choose to reject a PIN entry if there's only one attempt left, as this can be checked before submitting the PIN to the device - see https://btchip.github.io/btchip-doc/bitcoin-technical.html#_verify_pin

Regarding the closed source firmware, I think it's worth opening this discussion as there'll be more clients implemented on Secure Elements (smartcards, TEEs, or whatnot), with certain benefits (non trivial secrets recovery when the device is lost and probed, protection against side channel attacks, protection against altered control flows) and most if not all of them will be closed source in some way (coming as an open source application over a closed virtual machine, limited open source application using a closed source binary blob exposing NDA-ed functionalities of the Secure Element, closed source without specifications that allow proper testing, closed source with specifications allowing proper testing ...). Also we've done our best to provide a specification that allows deterministic blackbox testing by a third party.

[saivann]

@btchip Thanks for providing more details and explanation.

Re Second factor: Can this be bypassed in any way and is it the default? I'm concerned these extra steps likely will be ignored by the end user unless they are mandatory. I was also wondering if the computer itself could simulate a USB disconnect, in which case it could defeat this second factor feature (again, to my yet limited understanding).

Re Wiping the wallet: To my knowledge, chip and pin cards have been working like that assuming that the final user always had a recovery option. My debit card is easily replaced, the content of the BTChip is however unique and irrecoverably lost if the user has no backup and some malware just happens to be trying a few wrong PINs. Again, this risk is theoretical, I don't know if this would be enough to reject the wallet from bitcoin.org, but I feel it's still worth mentionning.

Re closed source: To fragilize my previous argument, I have recently learned about the closed-source Trezor bootloader, so it appears we have already crossed that line to a certain degree. And it's still unclear how one can prove that the firmware of an hardware wallet matches the public one, so I'm wondering if we'll need some transparency score to better reflect that in a near future. Publishing the detailed specification is obviously very appreciated and helpful when it comes to transparency.

[btchip]

The second factor is mandatory unless the dongle was set up to ignore it - so basically once it's initialized it'll be mandatory for the lifetime of that seed. You can set up the dongle with three modes :

• Standard mode : mandatory second factor. This is the default mode.
• Server mode : second factor can be disabled.
• P2SH mode : second factor is mandatory if not consuming P2SH inputs, and disabled if consuming P2SH inputs. This is intended for multisignature services providing their own better second factor, such as GreenAddress.

It's typically not possible for a malware to simulate a disconnect, as all consumer USB controllers I know do not offer a way to change the power settings ("Port Power" feature). First time I saw it supported was on the Novena https://www.crowdsupply.com/kosagi/novena-open-laptop - not your typical configuration.

Regarding the PIN wiping feature, you'll need to disconnect / reconnect the dongle after a wrong PIN is entered, making it less convenient for a malware denial of service scenario. We also kind of drive the user to backup the seed by forcing him to disconnect / read the seed (typed using the same mechanism used to type the second factor) / reconnect / type the PIN after setup. The client can make sure that those steps were taken by prompting the user in a very clear way before the first PIN is entered.

Regarding proving that a device runs a given version of a firmware, I'd say it's an interesting chicken & egg problem, and I don't really see an easy way out of this without being able to reflash all firmware (including bootloader) from the lowest possible physical interface at least once (or every time you want to use the device for paranoid users) - for another take on that topic and an enjoyable week-end read, you can refer to http://firmcoin.com/?page_id=14

In my opinion providing a new bullet point about the testability of Hardware Wallets could be a nice move forward, and a better view on the transparency of those devices rather than just "open source" vs "not open source"

[saivann]

In general, I couldn't see any concerning public feedback and only received positive comments about BTChip thus far. All of my concerns were addressed and the suggested scores in #646 I think should provide a more appropriate description of the transparency offered by both Trezor and BTChip.

@btchip Can you rebase your branch on top of master, or push new commits to make the following change?

s/decentralization: "checkneutraldecentralizevariable"/validation: "checkneutralvalidationvariable"
(Was renamed)

s/transparency: "checkfailtransparencyclosedsource"/transparency: "checkfailtransparencynew"
(This score is temporary for all newly added wallets)

Can you resize your icon to 96px in the 144px png? And at the same time, provide a better quality icon? The one you're using seems pixelized and I see that you have a better version on your website.

[btchip]

Rebased, modified and added our upcoming logo before official rebranding.

[saivann]

@btchip Oh the new icon is a square one, so it needs to be 85px. At the same time, can you also replace "Open Source" by "open-source" in your description (consistently with other occurences on bitcoin.org)?

[saivann]

@btchip The validation score wasn't properly replaced, please replace: s/decentralization:/validation:/

[btchip]

Sorry, should be ok now.

[saivann]

LGTM, I'll leave a few remaining days for anyone to comment if needed.

...And in the absence of critical feedback, this pull request will be merged on November 21th.

[btchip]

Renamed according to our upcoming announcement, otherwise ok to go

[schildbach]

@btchip I'm refering to your Oct 11 comment about USB disconnect / power control. I think it would be possible to

1. Just reset the computer. I'm not an USB expert but to me it looks like all my USB devices loose power for a short time if I do that.
2. If that's not enough, use ACPI to wake up the computer in a few seconds and shut it down. That should "unplug" all USB devices for sure (except maybe those plugged into charging ports).

What do you think?

[btchip]

I tried 1 on different configurations, it didn't seem to lose power during a reset. Also I think it'd complicated to exploit it for a malware, as first it's hard to hide, and second it'd have to grab the keyboard output too soon (in this case it's likely that the dongle would start typing as soon as USB is started, at some point during the BIOS initialization phase)

2 seems also complicated to pull off (would require to have a non sleep and charge port, not having the user notice that you're turning off the computer twice (you'll need to do it again to actually send back the PIN to the dongle), and that the dongle is not typing either too fast so it'd got lost or into a privileged UI such as a login/password when you turn the computer back on)

[schildbach]

Ok it would be noticable, but then again it does not matter after the attacker has emptied the wallet. The "typing too fast" problem could be defeated by flashing a custom firmware. I agree that its difficult to pull off.

Thanks for your quick reply.

[btchip]

I think it matters if the user freaks out and removes the USB device when that happens the first time. Supposing this attack works, maybe that should be worth mentioning, but it doesn't seem that much of a risk IMHO.

[saivann]

In general it seems hard to evaluate how likely it is that such attacks might succeed and be more common in the future. This specific security model relies on many small details. At the very least, AFAIK, there is not a systemic risk in that if this happens, we'll probably see isolated cases being reported first. So I'm sort of torn between the conservative approach (e.g. setting a passing environment score instead of a good score) and the "Wait and see" approach (keep identical scores between HW.1 and Trezor for now). Thus far stealing funds with malware seemed interestingly complicate to me.