btchip



Offline



Activity: 628

Merit: 500



CTO, Ledger







Hero MemberActivity: 628Merit: 500CTO, Ledger [NOW AVAILABLE] BTChip / Ledger HW1 : Bitcoin Hardware Wallet in a USB smartcard January 06, 2013, 10:36:09 AM

Last edit: December 05, 2014, 06:37:03 PM by btchip #1 Revamped first post old first post content stays after the line below, for historical purposes only as the scope and supported features changed quite a lot - you don't need to read below the line if you're new to the project



BTChip is a bitcoin/altcoin hardware wallet in a USB smartcard - low cost, secure, and available now - buy from



See installation and setup instructions on



For developers :



Latest firmware documentation always available on https://btchip.github.io/btchip-doc/bitcoin-technical.html or https://github.com/btchip/btchip-doc

C APIs : https://github.com/btchip/btchip-c-api

Java APIs : https://github.com/btchip/btchip-java-api

Web APIs (Chrome / Chromium only) : https://github.com/btchip/btchip-js-api - sample : KryptoKit integration https://github.com/btchip/btchip-kryptokit

Python APIs : https://github.com/btchip/btchip-python

Updates are always posted on twitter :



User tutorials :



gdassori : https://bitcointalk.org/index.php?topic=787418

User reviews :



Coding In My Sleep : http://codinginmysleep.com/hands-on-with-btchips-hw-1/

Bitvoid : http://bitvoid.net/btchip/

BitcoinInformation : https://bitcointalk.org/index.php?topic=134999.msg8819383#msg8819383

Gabridome : https://bitcointalk.org/index.php?topic=782875.0

-------------------------------------------------------------------------------------------------------------------------------------------------------------------





(Word of warning for people who got a sample at 29c3 and plan to attack it - there will be some chip spoilers during this post)



Hi



Hardware bitcoin related projects look quite alive & kicking in 2012, which is great here is my take on the topic of smartcard wallets, with a real world implementation



Smartcard wallet vs hardware wallet



First an hopefully unbiaised comparison between smartcard wallets and hardware wallets :



Pro smartcard wallet



Hardware security : making sure an attacker who got the device will have a very hard time extracting something useful from it. Also protection against side channel attacks, especially during known-to-leak cryptographic operations.

Cost : not considering an additional reader, an initial target cost per unit between 0.5 and 1 BTC is realistic (not considering large volumes). Shipping costs will be lower too, as sending an hardware wallet in a simple letter envelope seems harder.

is realistic (not considering large volumes). Shipping costs will be lower too, as sending an hardware wallet in a simple letter envelope seems harder. Durability : limited failure options with a single hardware component.

Against smartcard wallet



Not Open Source : smartcard chips and associated toolchains are heavily covered by NDAs, which makes sharing the source a pain. It's of course possible to release an Open Source smartcard wallet application running on an open smartcard platform, but you still need to trust the platform.

Limited protection against custom malware attacking bitcoin transactions : a hardware wallet will offer a display or buttons to review transactions. It is still possible to offer some protection against this in a smartcard as we will see, but not as extensively.

Limited code options : modern smartcards f.e. SC000 based look more and more like typical microcontrollers, if you don't consider the RAM size - however that's still not what you get in a typical secure product. Moreover coding on an "open" platform such as Java Card limits you to what the cryptographic API can offer, which can be an issue for the bitcoin protocol (f.e. ECDSA signature is only offered over SHA-1 for one of the most recent Java Card version, considering the card supports ECDSA first)

BTChip project





http://www.btchip.com



1.4.4 firmware specification



This project started as a more or less 2 weeks hack of a generic smartcard OS to offer bitcoin friendly APIs. The initial motivation was to see if it could be done, and also the pleasure of tweaking a project initially dedicated to banking applications to support something outside the system



The chip used is an



It features an implementation of the basic smartcard wallet described below an advanced smartcard wallet described in the specification, using USB HID as transport protocol - because it's more convenient than CCID for a general public application.



Here's the roadmap for the coming weeks, which will be updated as things get done :



Release the first samples at 29c3 - done

- done Improve the key generation & signing speed. Target is less than 2s, maybe less than 1s Now 900 ms to generate the keypair / 900 ms to sign

Now 900 ms to generate the keypair / 900 ms to sign Maybe support the advanced wallet model ( discussion below check the specification), but that's unlikely.

support the advanced wallet model ( check the specification), Support additional rich clients - so far there's a prototype for bitcoinj and integration into the official client is in progress. If you're a client developer and want a sample to play with, don't be shy and drop me a PM

Support web clients - even if Java security has been a bit controversial in the past months (and Java browser support turned into a sick joke on OS X) I've had good success with javahidapi running in an applet container and Java should still be available on public computers, so it can be a starting point. since I wrote this Java security got even worse (hats off to Oracle, that's quite an achievement), so browser plug-ins here we come Exposing hidapi through FireBreath is quite easy, so that's the preferred approach so far.

A few words about GlobalPlatform



are a set of specifications implemented by most recent multi application smartcards - they define how the card applications and cryptographic materials are isolated, as well as how to establish a secure transport channel (Secure Channel - think TLS with authentication and optional confidentiality using only symmetric keys) between the card and an external entity.



The smartcard wallet implementations will rely on GlobalPlatform concepts to :



Define how keys are inserted into the card

Authenticate the user to validate access rights to access specific keys

Optionally authenticate the card responses

Smartcard wallet architecture



We assume the user store a lot of keys, not necessarily related to each other (i.e. not necessarily generated by a deterministic wallet)



To support this model, no ECDSA key will be stored on the smartcard and the smartcard will only manipulate the private component of an ECDSA key (S, 32 bytes) in an encrypted form.



A key used to encrypt private component of an ECDSA key is called a Context Key. Context Keys are stored on the smartcard itself and never revealed. The suggested encryption algorithm is Triple DES in CBC mode (because Triple DES capable cryptoprocessors are still way more common than AES capable cryptoprocessors nowadays on smartcard chips).



A bitcoin client stores the private key in an encrypted form along with the reference of the Context Key used to access it. It then sends SHA-256 hashes to sign to the smartcard for a non transaction aware smartcard wallet, or each component of the transaction to sign for a transaction aware smartcard wallet, along with the encrypted private key to sign with.



A Context Key can be associated to a specific GlobalPlatform Secure Channel. In this case, the user should be authenticated to the Secure Channel before being able to sign a transaction.



Basic smartcard wallet (non transaction aware)



The basic smartcard wallet just knows how to generate a keypair over the bitcoin ECDSA curve, and sign something. It is not aware of anything else bitcoin specific, and does not need to support SHA-256 either.



The following APIs are defined :



Generate Keypair : takes a Context Key reference, generates a keypair over secp256k1, returns the public component of the key (W) and the encrypted private component of the key (S') using the Context Key.



Import Private Key : takes a Context Key reference and a cleartext private key component (S), returns the encrypted private component of the key (S') using the Context Key.



Sign : takes an encrypted private key component (S'), the SHA-256 hash to sign, and returns the ASN-1 encoded signature components.



Verify (optional) : takes a public key component (W), the SHA-256 hash to verify, the signature and returns ok or not ok.



Advanced smartcard wallet (transaction aware) (old version, check the posts below for the updated version)



The following description is mostly outdated and kept only for reference - check the firmware specification instead



The advanced smartcard wallet proposal uses a simple concept to defeat useful malware : all output addresses must be authenticated by the card when included in a transaction.



In this model, before starting a transaction you'd take the output addresses, provide them to the card to be encrypted on a trusted computer or a different platform, then go on with the transaction signing.



Two new type of keys are defined, the Address Key, which is used to encrypt an address, and the Secure Hash key, which is used to encrypt a SHA-256 context.



In this implementation the smartcard needs to support SHA-256 and optionally RIPEMD-160 if automated keys generation for change is desired



The following APIs are defined :



Generate Keypair For Change : takes a Context Key reference, an Address Key reference, generates a keypair over secp256k1, returns the public component of the key (W), the encrypted private component of the key (S') using the Context Key, and the associated encrypt address.



Encode Address : takes an output address, an Address Key reference and returns an encrypted address that the smartcard will authenticate later.



Secure Hash Generic : takes a generic part of the transaction which is not an Output script, a Secure Hash context (or nothing if creating a new hash), a Secure Hash key reference and returns an updated (or new) Secure Hash context. The Secure Hash context holds the context of the SHA-256 hash, encrypted by the smartcard. It is sent back to the host instead of being kept in RAM in case people are interested to have a distributed implementation. This function must validate the provided data i.e. make sure that no Output script can be hashed by this function (f.e. by fragmenting it into meaningless parts).



Secure Hash Output Script : takes an Output script, a Secure Hash context, a Secure Hash key reference, a list of encrypted addresses and associated Address Key references and returns an updated Secure Hash context. The Output script structure is parsed and only accepted if the given address matches one of the encrypted addresses passed.



Sign Secure Hash : takes an encrypted private key component (S'), a Secure Hash context, a Secure Hash key reference and returns the ASN-1 encoded signature components.



Protecting against custom malware



Creating multiple Context Keys can be effective protected by a Secure Channel can help fragmenting the risks for large wallets - supposing an all powerful malware grabbed the authentication key of the Secure Channel and can play transactions, the risks are limited to the private keys linked to this Context Key.



Another simple method to protect against custom malware using an USB implementation can be to rely on an annoying fact : powering off a USB device by software is painful. Using this model, we can choose to accept one signature per session and force the user to unplug/plug again the device for each signed output - a cheap way to check that no additional outputs were added, but requires free fingers to count and doesn't prevent a malware that'd just replace a legitimate transaction by a fake one rather than adding outputs to a legitimate one.



Feel free to comment and improve on this BTChip is a bitcoin/altcoin hardware wallet in a USB smartcard - low cost, secure, and available now - buy from https://buy.hardwarewallet.com (limited promotional offer, 2 cards for 20 , payable in bitcoins)See installation and setup instructions on http://www.hardwarewallet.com - BTChip works out of the box with GreenAddress (Chrome application & Android wallet) and Electrum (upcoming release)For developers :Updates are always posted on twitter : https://twitter.com/btchip -------------------------------------------------------------------------------------------------------------------------------------------------------------------HiHardware bitcoin related projects look quite alive & kicking in 2012, which is greathere is my take on the topic of smartcard wallets, with a real world implementationFirst an hopefully unbiaised comparison between smartcard wallets and hardware wallets :This project started as a more or less 2 weeks hack of a generic smartcard OS to offer bitcoin friendly APIs. The initial motivation was to see if it could be done, and also the pleasure of tweaking a project initially dedicated to banking applications to support something outside the systemThe chip used is an ST23YT66 which is your regular smartcard microcontroller with a twist : USB support. Which means it can be directly connected into a USB port with no reader necessary.It features an implementationan advanced smartcard wallet described in the specification, using USB HID as transport protocol - because it's more convenient than CCID for a general public application.Here's the roadmap for the coming weeks, which will be updated as things get done : The GlobalPlatform Card Specifications are a set of specifications implemented by most recent multi application smartcards - they define how the card applications and cryptographic materials are isolated, as well as how to establish a secure transport channel (Secure Channel - think TLS with authentication and optional confidentiality using only symmetric keys) between the card and an external entity.The smartcard wallet implementations will rely on GlobalPlatform concepts to :We assume the user store a lot of keys, not necessarily related to each other (i.e. not necessarily generated by a deterministic wallet)To support this model, no ECDSA key will be stored on the smartcard and the smartcard will only manipulate the private component of an ECDSA key (S, 32 bytes) in an encrypted form.A key used to encrypt private component of an ECDSA key is called a. Context Keys are stored on the smartcard itself and never revealed. The suggested encryption algorithm is Triple DES in CBC mode (because Triple DES capable cryptoprocessors are still way more common than AES capable cryptoprocessors nowadays on smartcard chips).A bitcoin client stores the private key in an encrypted form along with the reference of the Context Key used to access it. It then sends SHA-256 hashes to sign to the smartcard for a non transaction aware smartcard wallet, or each component of the transaction to sign for a transaction aware smartcard wallet, along with the encrypted private key to sign with.A Context Key can be associated to a specific GlobalPlatform Secure Channel. In this case, the user should be authenticated to the Secure Channel before being able to sign a transaction.The basic smartcard wallet just knows how to generate a keypair over the bitcoin ECDSA curve, and sign something. It is not aware of anything else bitcoin specific, and does not need to support SHA-256 either.The following APIs are defined :: takes a Context Key reference, generates a keypair over secp256k1, returns the public component of the key (W) and the encrypted private component of the key (S') using the Context Key.: takes a Context Key reference and a cleartext private key component (S), returns the encrypted private component of the key (S') using the Context Key.: takes an encrypted private key component (S'), the SHA-256 hash to sign, and returns the ASN-1 encoded signature components.(optional) : takes a public key component (W), the SHA-256 hash to verify, the signature and returns ok or not ok.The advanced smartcard wallet proposal uses a simple concept to defeat useful malware : all output addresses must be authenticated by the card when included in a transaction.In this model, before starting a transaction you'd take the output addresses, provide them to the card to be encrypted on a trusted computer or a different platform, then go on with the transaction signing.Two new type of keys are defined, the Address Key, which is used to encrypt an address, and the Secure Hash key, which is used to encrypt a SHA-256 context.In this implementation the smartcard needs to support SHA-256 and optionally RIPEMD-160 if automated keys generation for change is desiredThe following APIs are defined :: takes a Context Key reference, an Address Key reference, generates a keypair over secp256k1, returns the public component of the key (W), the encrypted private component of the key (S') using the Context Key, and the associated encrypt address.: takes an output address, an Address Key reference and returns an encrypted address that the smartcard will authenticate later.: takes a generic part of the transaction which is not an Output script, a Secure Hash context (or nothing if creating a new hash), a Secure Hash key reference and returns an updated (or new) Secure Hash context. The Secure Hash context holds the context of the SHA-256 hash, encrypted by the smartcard. It is sent back to the host instead of being kept in RAM in case people are interested to have a distributed implementation. This function must validate the provided data i.e. make sure that no Output script can be hashed by this function (f.e. by fragmenting it into meaningless parts).: takes an Output script, a Secure Hash context, a Secure Hash key reference, a list of encrypted addresses and associated Address Key references and returns an updated Secure Hash context. The Output script structure is parsed and only accepted if the given address matches one of the encrypted addresses passed.: takes an encrypted private key component (S'), a Secure Hash context, a Secure Hash key reference and returns the ASN-1 encoded signature components.Creating multiple Context Keys can be effective protected by a Secure Channel can help fragmenting the risks for large wallets - supposing an all powerful malware grabbed the authentication key of the Secure Channel and can play transactions, the risks are limited to the private keys linked to this Context Key.Another simple method to protect against custom malware using an USB implementation can be to rely on an annoying fact : powering off a USB device by software is painful. Using this model, we can choose to accept one signature per session and force the user to unplug/plug again the device for each signed output - a cheap way to check that no additional outputs were added, but requires free fingers to count and doesn't prevent a malware that'd just replace a legitimate transaction by a fake one rather than adding outputs to a legitimate one.Feel free to comment and improve on this Ledger |

Ledger Wallet |

HW.1 Thread | Java Card Bitcoin

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANN] Smartcard wallet project + btchip implementation (no reader required) January 06, 2013, 06:17:46 PM #4 I saw your clone of bitcoinj, great to see this announced. It sounds very cool.



I have some questions.



Firstly, you state that this chip can be attached directly to a USB port without any reader necessary, but the image you provide looks like a regular smartcard, which won't physically fit. So how does this work, exactly? Could you post a photo of one attached to your computer?



Secondly, I'm still a little confused as to use cases. As you admit, because it simply signs hashes in the standard mode, this is security-wise equivalent to having an encrypted wallet on a PC. If malware gets onto the machine it has to wait until the user makes a transaction, and can then steal all the funds. So a BTChip seems to have same security as a strong password, with the downside that you cannot back it up and you have to carry it around. Could you elaborate more on where you see this product fitting in? For instance, could it store time horizons (block time of earliest transaction, latest transaction) and be used as a kind of card-based wallet?





btchip



Offline



Activity: 628

Merit: 500



CTO, Ledger







Hero MemberActivity: 628Merit: 500CTO, Ledger Re: [ANN] Smartcard wallet project + btchip implementation (no reader required) January 06, 2013, 08:10:25 PM #5 Quote from: Mike Hearn on January 06, 2013, 06:17:46 PM I saw your clone of bitcoinj, great to see this announced. It sounds very cool.



I have some questions.



Firstly, you state that this chip can be attached directly to a USB port without any reader necessary, but the image you provide looks like a regular smartcard, which won't physically fit. So how does this work, exactly? Could you post a photo of one attached to your computer?

Hi, sure. First you cut the shape in the center







Then you fold it







Then you can insert it







Quote Secondly, I'm still a little confused as to use cases. As you admit, because it simply signs hashes in the standard mode, this is security-wise equivalent to having an encrypted wallet on a PC. If malware gets onto the machine it has to wait until the user makes a transaction, and can then steal all the funds.

The basic use case is indeed very similar to an encrypted wallet, but offers some additional security in my opinion.



One thing is that once a malware obtains the passphrase to an encrypted wallet, it can grab the private keys and use them later without requiring any interaction from the user. Using a smartcard wallet, the malware can request the smartcard to sign something using those keys, as long as the smartcard is connected and agrees to sign (you could set a session based limit according to the number of outputs you plan to sign, for example, and after this the card would have been to be removed / inserted again to be operational, or other creative countermeasures).



The biggest difference is that the private key is never manipulated in a usable form by the host.



You could also make the malware attack less successful by using different encryption keys for the private keys, each one using a different PIN.



Quote So a BTChip seems to have same security as a strong password, with the downside that you cannot back it up and you have to carry it around.

You can back it up, and it's very important to do so the idea is to generate the context keys (encrypting the private keys) on a trusted computer when you first use the card (or decide to create a new context key), and keep the Triple DES key value in a safe place (printed / gpg encrypted ...). Thus you can exchange keys between another client implementation and the smartcard if you wish.



Quote Could you elaborate more on where you see this product fitting in?

I can see it fitting some space between the pure software approach and the hardware wallet for people wanting some additional security, as it's cheaper to produce and distribute. And rebrand, if you consider the BTChip form factor (f.e. a web based wallet providing this to its users). Also as a side note more secure if physically attacked.



Now if the consensus is that basic mode is not secure enough, then I'll see how this can be improved and we can discuss it.



Quote For instance, could it store time horizons (block time of earliest transaction, latest transaction) and be used as a kind of card-based wallet?

yes it could do that, although it has a very limited storage capacity (on this version, 16 kb). Can you elaborate more on this ? Hi, sure. First you cut the shape in the centerThen you fold itThen you can insert itThe basic use case is indeed very similar to an encrypted wallet, but offers some additional security in my opinion.One thing is that once a malware obtains the passphrase to an encrypted wallet, it can grab the private keys and use them later without requiring any interaction from the user. Using a smartcard wallet, the malware can request the smartcard to sign something using those keys, as long as the smartcard is connected and agrees to sign (you could set a session based limit according to the number of outputs you plan to sign, for example, and after this the card would have been to be removed / inserted again to be operational, or other creative countermeasures).The biggest difference is that the private key is never manipulated in a usable form by the host.You could also make the malware attack less successful by using different encryption keys for the private keys, each one using a different PIN.You can back it up, and it's very important to do sothe idea is to generate the context keys (encrypting the private keys) on a trusted computer when you first use the card (or decide to create a new context key), and keep the Triple DES key value in a safe place (printed / gpg encrypted ...). Thus you can exchange keys between another client implementation and the smartcard if you wish.I can see it fitting some space between the pure software approach and the hardware wallet for people wanting some additional security, as it's cheaper to produce and distribute. And rebrand, if you consider the BTChip form factor (f.e. a web based wallet providing this to its users). Also as a side note more secure if physically attacked.Now if the consensus is that basic mode is not secure enough, then I'll see how this can be improved and we can discuss it.yes it could do that, although it has a very limited storage capacity (on this version, 16 kb). Can you elaborate more on this ? Ledger |

Ledger Wallet |

HW.1 Thread | Java Card Bitcoin

paybitcoin



Offline



Activity: 85

Merit: 10





1h79nc







MemberActivity: 85Merit: 101h79nc Re: [ANN] Smartcard wallet project + btchip implementation (no reader required) January 06, 2013, 08:37:38 PM #6 Quote from: Mike Hearn on January 06, 2013, 06:17:46 PM Secondly, I'm still a little confused as to use cases. As you admit, because it simply signs hashes in the standard mode, this is security-wise equivalent to having an encrypted wallet on a PC. If malware gets onto the machine it has to wait until the user makes a transaction, and can then steal all the funds. So a BTChip seems to have same security as a strong password, with the downside that you cannot back it up and you have to carry it around. Could you elaborate more on where you see this product fitting in? For instance, could it store time horizons (block time of earliest transaction, latest transaction) and be used as a kind of card-based wallet?

I can see it adding a bit more trust in a centralized, cloud-based card-provider scenario. The customer wins because the card provider doesn't have any way of getting at the funds directly as only the encrypted private key is stored (short of breaking 3DES.) They can also backup the funds directly in case the card provider goes defunct.



If you add more verification in the card itself to only allow signed transactions from the card provider, then the card provider and customer are secure in the fact that the signed transactions are not affected by malware (except if the recipient/merchant generating the transaction is infected, but at least someone can see it before it is signed.)



The customer would still have to trust the card provider not to spend all the funds as part of the next transaction, but then the card provider would also have to be cooperating with the merchant terminal/ host software provider to hide this fact when showing the receipt before signing.



Another note on this smartcard, there will always be some sort of cloud provider/host in the mix as the actual private key is _not_ stored in the card itself. Therefore (and as btchip just posted) it needs to be transferred to the card for signing.



btchip, if there is 16 kb of storage space available, is there a way to store and transfer out the encrypted key directly? Then you could do offline signing, as long as you trust the host software. Also, is it kilobits (Kb) or kilobytes (KB)? I see in the chip posted there is 66 Kbytes of User EEPROM... I can see it adding a bit more trust in a centralized, cloud-based card-provider scenario. The customer wins because the card provider doesn't have any way of getting at the funds directly as only the encrypted private key is stored (short of breaking 3DES.) They can also backup the funds directly in case the card provider goes defunct.If you add more verification in the card itself to only allow signed transactions from the card provider, then the card provider and customer are secure in the fact that the signed transactions are not affected by malware (except if the recipient/merchant generating the transaction is infected, but at least someone can see it before it is signed.)The customer would still have to trust the card provider not to spend all the funds as part of the next transaction, but then the card provider would also have to be cooperating with the merchant terminal/ host software provider to hide this fact when showing the receipt before signing.Another note on this smartcard, there will always be some sort of cloud provider/host in the mix as the actual private key is _not_ stored in the card itself. Therefore (and as btchip just posted) it needs to be transferred to the card for signing.btchip, if there is 16 kb of storage space available, is there a way to store and transfer out the encrypted key directly? Then you could do offline signing, as long as you trust the host software. Also, is it kilobits (Kb) or kilobytes (KB)? I see in the chip posted there is 66 Kbytes of User EEPROM...

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANN] Smartcard wallet project + btchip implementation (no reader required) January 06, 2013, 09:17:24 PM #8 By time horizons, I mean, if I buy a card and put some keys in it and then load up those keys with some coins, if I give it to somebody else I want them to be able to quickly load up a usable wallet. For sites that have a full index of the blockchain (like blockchain.info or things that use their API) you don't need any other data, but most nodes don't have such an index. For them knowing the block span which may be useful to scan can speed up synchronization immensely. It means storing two extra ints, so hardly a big deal if you have 16kb.