[NOW AVAILABLE] BTChip / Ledger HW1 : Bitcoin Hardware Wallet in a USB smartcard

[drazvan]

Hey guys, I've sent you an email (contact (at) btchip (dot) com ). I think I might have a solution for your problem with the fact that the smartcard doesn't have a display and keys. We have a service called VeriFi (https://www.veri.fi) that receives HTTP requests and calls you on the phone to ask you a question (it could be like "Rosie's shop wants to charge you $5 for shoes, do you want to authorize this transaction?" - you would say "yes" or "ok" and the transaction would go through. If you say anything else, it doesn't.

So if your BTChip smartcard asks the card reader to establish an encrypted (or maybe just signed) channel to our server, it can ask it to call the user and tell him the amount and the merchant name, then get his/her authorization to proceed and sign the transaction.

It could work something like this:
1. Terminal sends AMOUNT + MERCHANT_NAME to the smartcard.
2. Smartcard generates a signed request like "smartcardid:AMOUNT:MERCHANT_NAME:nonce:signature" and sends it to the terminal.
3 .Terminal sends request to VeriFi (it can't modify it, it's signed)
4. VeriFi calls the user, gets his response, then sends back "smartcardid:nonce:ANSWER:server_signature".
5. Terminal sends the signed response back to the smartcard.

Even if the terminal is hostile, it can't modify a request. Even if it replays a request, VeriFi will ask the question again but the answer will be useless since the smartcard will compare the returned nonce with the one it expects - so it won't accept the answer.

So it would essentially be like your smartcard wallet calling you on the phone to authorize the transaction. Pretty cool, huh?

Razvan

[1715016938]

1715016938

[1715016938]

1715016938

[1715016938]

1715016938

[1715016938]

1715016938

[1715016938]

1715016938

[btchip]

Yep, thanks for your inputs, that's interesting. I should browse that e-mail as often as I browse this forum

However I'd like the service to be as simple, cost effective and standalone as possible - so the new (to be published soon) specification provides a somewhat similar scheme, which is intended to be validated by a smartphone application in order to check the payment destination, amount, fees and change, to avoid having a malware gaming any part of the protocol - as well as profiles to automatically authorize transactions fitting authorized limits / authorized addresses.

I'll definitely keep your proposal in mind in case the smartphone use case proves too difficult to deploy though.

[btchip]

Specification updated to 1.4.2, which should be really close to the really final thing (yes really ) - featuring full transaction control, done automatically for user specified limits or with a manual confirmation from another device (such as a smartphone).

BTChip specification 1.4.2

Also, two of us will exhibit at Bitcoin 2013, don't hesitate to drop by, say hi and grab a sample.

[btchip]

Random show teaser 

[btchip]

For those who picked a sample at Bitcoin 2013 during the last 2 days, thanks - for the others, there is still plenty of time to pick one today

I've updated the http://www.btchip.com/wallet.html page of the website so that you can check if the browser Plug-in is working fine for you.

After enough people report I'll make a dedicated announcement as this can be used by all other HID based wallets (let's keep the spam level to a minimum for the time being)

Very impatient developers might also peek at the /jsapi directory on the website, at your own risks 

[btchip]

Test suite added for developers wanting something to play with  http://www.btchip.com/developer.html

[btchip]

Sample offline wallet posted for developers (only if you're ready to play with transactions directly) - http://www.btchip.com/wallet-developer.html - stay tuned for the real user friendly version 

[btchip]

The browser plug-in has been updated to fix Windows-64 issues, it should work fine now.

[Luke-Jr]

Hmm, I presume you're aware Bitcoin usually needs at least 2 outputs (and often more than 1 input) for transactions.. is that broken as implied by "Only a single point-to-point output"?

It would make sense to support sending to any arbitrary script equally - not just the (semi-deprecated!) pubkeyhash form

It might also be wise to *not* expose IMPORT PRIVATE KEY to untrusted users (at all), as this is an attack vector in ordinary wallets.

[btchip]

Hmm, I presume you're aware Bitcoin usually needs at least 2 outputs (and often more than 1 input) for transactions.. is that broken as implied by "Only a single point-to-point output"?

Sure, we might want to make this more clear in the specification then - I meant "one chosen no-change output" here. So one change output, one payment output, and multiple inputs are supported.

It would make sense to support sending to any arbitrary script equally - not just the (semi-deprecated!) pubkeyhash form

you can do that, but then lose the anti-malware protection you get when the card is able to check the content of the script - of course I'll gladly look into any better future proof format you can point me to provided it can be parsed easily - plus it'd be a great opportunity to test a firmware update

It might also be wise to *not* expose IMPORT PRIVATE KEY to untrusted users (at all), as this is an attack vector in ordinary wallets.

Which attack vector do you have in mind ? This function is used to work with an existing transaction (i.e. encrypt the private key with the context key so that the chip can sign a new input with it), but cannot be used to dump a private key.

[Luke-Jr]

It would make sense to support sending to any arbitrary script equally - not just the (semi-deprecated!) pubkeyhash form

you can do that, but then lose the anti-malware protection you get when the card is able to check the content of the script - of course I'll gladly look into any better future proof format you can point me to provided it can be parsed easily - plus it'd be a great opportunity to test a firmware update

How does checking the form of the script provide any malware protection? Malware can certainly use pubkeyhash just as easily as other scripts...
BIP 16 describes the current P2SH standard.

It might also be wise to *not* expose IMPORT PRIVATE KEY to untrusted users (at all), as this is an attack vector in ordinary wallets.

Which attack vector do you have in mind ? This function is used to work with an existing transaction (i.e. encrypt the private key with the context key so that the chip can sign a new input with it), but cannot be used to dump a private key.

Perhaps I'm misunderstanding your function here, but the attack vector on wallets would be something along the lines of:

• Put some worthless amount on a key, trick some user to import it to "redeem" the key (or, in this case, just import it to some unsuspecting smartcard in "untrusted" mode!).
• Later, initiate a payment to said person. But instead of the address they give you, send it to the one you tricked them into importing.
• Play dumb and have the user/merchant verify your payment manually. It's in the wallet, so it's theirs, right?
• Attacker receives his goods, and uses his copy of the private key to redeem all the funds back to an address he controls exclusively, out from the user/merchant's wallet.

[btchip]

How does checking the form of the script provide any malware protection? Malware can certainly use pubkeyhash just as easily as other scripts...
BIP 16 describes the current P2SH standard.

Thanks, that'll be easy enough.

In untrusted mode, we know the card always produces the same (simple) script given inputs + change address + payment address and does not take an arbitrary input script to sign, so this protects against something that would ask to sign "pay to X or oh by the way to me as well" instead of "pay to X" - granted this would likely be rejected by the client today, but I had the feeling it was safer to whitelist rather than to think about all possible scripting abuse here. We can still do that with BIP 16 by forcing the script we'll sign.

And we can add a mode in which we still check the inputs and the amount / fees / change involved then have the user verify the provided script, the same way we have them optionally check the amount / fees / change / change address today with a signature of what the card has seen, for more open use cases.

• Put some worthless amount on a key, trick some user to import it to "redeem" the key (or, in this case, just import it to some unsuspecting smartcard in "untrusted" mode!).
• Later, initiate a payment to said person. But instead of the address they give you, send it to the one you tricked them into importing.
• Play dumb and have the user/merchant verify your payment manually. It's in the wallet, so it's theirs, right?
• Attacker receives his goods, and uses his copy of the private key to redeem all the funds back to an address he controls exclusively, out from the user/merchant's wallet.

oh sure, makes sense. never forget good old social engineering I'll make sure this is disabled in untrusted mode (I think it already is but it can't hurt to double check and document it).

[btchip]

The specification has been bumped to BTChip Specification 1.4.3 (github link) to support submitting a transaction to a P2SH address.

You can use this great opportunity to suggest new features and stuff you'd like to change, even if there's almost no space left  

[crazy_rabbit]

So whats up with the BTChip project? I still have my "0.1" BTC cards from the conference, but the website looks more or less dead. Whats up with the project? I really like the idea- but has there been any progress?

[jonasbits]

So whats up with the BTChip project? I still have my "0.1" BTC cards from the conference, but the website looks more or less dead. Whats up with the project? I really like the idea- but has there been any progress?

I really like this concept, is there any progress?

[btchip]

Oops. Guess I should check that thread more often

There have been some thoughts about improving the malware detection, which will be available in the next firmware version.

Also, a lot of under the hood upgrades of the generic smartcard platform used to host BTChip (among those : code saving, RAM saving, more code saving, more RAM saving, migration from generic HID to WinUSB, did I mention code saving ?), and of course, significant yak shaving, such as an open source Java Card implementation that can be used for developers to play with the concept.

The biggest remaining task right now is a clean integration into a few clients - we don't want to go on sale without that, and we need to find more free time to do it properly. Also yes, the website needs some serious redesign - it started out fine, then I touched it 

So, sorry guys, we're not dead, just a bit slow on the bitcoin topic.

[btchip]

Big specification update at the usual location - BTChip Specification 1.4.3 (github link) (yes, the version isn't bumped yet)

Main new features :

• HD Wallets
• New anti-malware method, using the dongle as a keyboard (similar to the Java Card contactless notification option)
• WinUSB support for integration in Chrome-family browsers without external plugins
• Partial transactions signing (for CoinJoin oriented projects, with still some user validation)

And a new form factor



To be hopefully finalized during 30c3, come and get your sample if it's ready  

[btcusr]

All the best!

[nogreedy]

Hello,

and what about your competitor, Trezor?

http://www.bitcointrezor.com/

[btchip]

I think there is plenty of space for multiple secure hardware wallet implementations

Trezor is fully open source while we are with open specifications.

We are better protected than trezor against side channel attacks.

Trezor has a screen and buttons while we plan to be the cheapest secure hardware wallet available

so feel free to choose the best implementation for you, or even better, pick both

That said I fully support the trezor project, ordered one, and I'm typing this while waiting for their 30c3  presentation