Topic: [NOW AVAILABLE] BTChip / Ledger HW1 : Bitcoin Hardware Wallet in a USB smartcard - page 19. (Read 62661 times)

I really like this concept, is there any progress?

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?

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  

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.


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

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.

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.

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.


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


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.

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.

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

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 

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

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 

Random show teaser 

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.

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.

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

don't worry, we thought about that

(this space reserved for a not really useful but fun device picture)

Contact Kim Dotcom. He has a job for you.

yes, as long as two chips share the same context (triple DES) keys, they can be exchanged.

Is it possible to use two different keys in such a way that either of those keys could sign?
Just for the single key failover case / redundancy.
Hope it would act like duplicate door keys..

In case some bitcoiners are attending Mobile World Congress 2013, I'll have a few samples available on the 26th and 27th with an intermediate firmware version (faster than the one distributed at 29c3, but without the anti malware features) - just leave a message.

Then development of the new firmware will resume faster, hopefully