What I understand from OpenPay is that it targets traditional EMV, which is a totally different beast.

SmartCardWallet is a simple beast, targeting a simple problem, with a simple solution.

Well, I'm targeting traditional PC-s with this solution and the concern for trojans, sitting between the screen and keyboard and the key-container device is a real concern. Meaning that if Bob wants to send funds to Alice and the trojan controlling Bob's computer replaces Alice's bitcoin address with the one beling to the adversary, things go bad.

One solution would be to create a challenge-response type protocol so that Alice (not Bob) could be sure that the right address (and right amount) are sent to Bob, but that's only part of the solution.

But there are countless other ways you can be fscked and what you should be concerned of if your host is compromised, anyway.

Yes, of course the keys are generated on-card. But depending on cardholder wishes, keys can also be imported or exported or backed up to a similar smart card. This requires a specific card-application, so if you choose a no-export, no-import, no-backup card, you can be sure that the keys you have are the *only* copies on earth.

Software is integrity-checked, as one can't just load arbitrary software to the smart card. There's no point in having "signed software" in this context (the anchor of trust better be a person guarding the process of card manufacturing from source code)

Regarding idealistic hardware devices: the same problem has haunted PKI (think: secure signature creation devices). People should understand, that there is no closed-world 100% secure modelled world available (read: not financially meaningful in civil sector). There has been reports of trojans that intercept smart card calls (Zeus IIRC) and thus have the theoretical capability of intercepting calls to smart cards and forging signatures etc. But in practical terms *stealing* keys in smart cards is really hard (requires a physical theft) and un-authorized use made much more difficult. If you rely 100% on the unbreakability of the smart card, then yes, there is a chance to break it, probably.

But I think there's much more needed for a full solution (including in the overall protocol layer of bitcoin) to have such perfect end2end secure transaction device. And it will take more time than SmartCardWallet.

SmartCardWallet target one weakness in the system and solves just a very traditional problem: secrecy of private keys. The same has been probably debated a long time ago by people smarter than me, that having your signature keys (like the keys in bitcoin are) in a smart card is way better than having them in an encrypted file somewhere.

Thanks for the links, I'll be reading them (but I must admit that I have a very fixed concept already).

As said, the card itself is done, but I failed in linking it (sensibly) to Electrum (which has too much internal stuff related to deterministic key generation etc built into it that I felt like an elephant in a crystal store). Next target is BitcoinJ, as it seems easier to refactor it to use hardware keystores because of Java than other options. Unfortunately higher priority events postponed working on it (which is not a difficult task per se, but wrapping it up into a nice package, be it for end-users or other developers, is more time-consuming than just "make it work").


See also: https://groups.google.com/forum/#!topic/bitcoinj/ukA640Q9J9g


At the moment it is purely a hobby project, no time is directly dedicated to *this* project (but I'm quite involved in "all things smart card" thus it might not be a fair description).

Sufficient donations (?) would of course justify scheduling time, but I don't know if I would like to "wait until it materializes" and try to market/sell it or make it a "take it all" open source solution.

I wouldn't mind collaborating with someone more involved with Bitcoin related activities, as for me it is a purely technical challenge (and the main obstacle for owning more than 10BTC)

I could send you a card and a simple reader for testing purposes, if needed, for around 50€ I guess.

Look around in smartcardfocus.com, cryptoshop.com, smartcardsource.com etc. For cards in quantities the prices are of course cheaper.
EC-211? Bitcoin uses secp256k1 curve ...

Eventually. I must first figure out if/how I want to monetize it. The deal being that "whoever pays, also gets the source", but I might postpone opening the on-card software in the beginning and only distribute pre-made cards. I don't know yet.

I've never seen a software stack for basiccards, thus I'd like to see how a) the source code of an application looks like b) building and loading looks like c) capabilities of the ecosystem feel like. Thus if you have things like sample code or hello world package, I'd like to have a look at it, if possible.

Regarding JavaCard vs MultOS (mostly dead these days, IMHO) vs bare cards vs basiccards...

I don't know if the chip they use is CC verified, it certainly does not exist in FIPS 140-2 list etc. Even though CC/FIPS somewhat contradicts bitcoin spirit, it actually has *some* meaning.

Regarding EEPROM: this is for user data, thus the execution environment should not matter that much.

"You get what you pay for" applies very often, very harshly.


I tried surfing their site but did not find the language reference or datasheet in 2 minutes, except for the short example on http://www.zeitcontrol.de/basiccard_gen.htm

Nevertheless, it might be an interesting option for people who require ease of use or cheap prices, but I have more confidence and experience in JavaCard-s.

And regarding BASIC: I think the last time I used it was when I was in early teens or so Would be strange to go back in time...

JavaCard is the natural choice for such things, in this sector, in 2012.
Apparently you have not worked in this field before. I don't have much notes, but I expect to make pre-release kits (a card and a reader) available for sale ASAP, maybe as early as next week. Anyone interested in getting a rev 1.0 (with BitcoinJ library for using it) at an early bird rate (meaning slightly higher price than eventually) please let me know.
Yes, transactions are signed on the card, that's the usual purpose of smart cards. Keys *can* leave the card, if allowed by policy or for example for backing up to a backup smart card wallet. Again, if allowed by card policy profile *and* card owner. It is a split responsibility of the card platform and application.

On the contrary, EC crypto is much lighter/faster on a smart card than for example RSA (one of the main purposes of ECC is improved efficiency on constrained hardware) and the amount of data needed to be hashed for a transaction is really minimal (compared to a PDF contract, for example). Also, technically you can hash part of the stuff on the host and only part of it on the card.

The cards I've chosen for Smart Card Wallet all have 64K or more of EEPROM available, which means that a bunch of addresses can be made on the card (but for now I've limited the amount of addresses to 64, to keep it maintainable for the user).

One more suggestion: unless you are *sure* (like... 80% or more sure) about what you are doing, I don't suggest to try to create any crypto or algorithms yourself, unless you *have to* (gunpoint) or *want to* (for learning purposes). The chances of messing something up are really high.

If the cards you have are BasicCard-s, then I'd be "professionally interested" in learning more about them.

Hello,

I have not fully understand the scope of what you are trying to do (and too much to read as well), but you seem to be mostly on the starting into the smart card world.

I don't know if this relates to what you do or not: https://bitcointalk.org/index.php?topic=94119.0

Current status: integrating it with Electrum for a sensible GUI. The card itself works for what I believe is sufficient functionality to keep a wallet.

Hello,
Maybe relevant:

I'm working on a "traditional" two factor wallet, called SmartCardWallet. In essence you shall have a physical card in your wallet, that acts something like a normal chipped visa card. Unlike paper based solutions, it is considered a difficult task for an average adversary to copy/attack the contents of a smart card. See https://bitcointalk.org/index.php?topic=94119.0

Yes I have, and that has no immediate relation to SmartCardWallet.

SmartCardWallet has a very simple yet powerful goal: protect in hardware the keys that authorize transactions. No fancy self-made hardware, no extra displays and pay buttons. Just a smart card much like your VISA or electronic identity card.

First, it builds upon "established standards and practices" (readily-available, certified hardware)
Second, it includes no self-made hardware components or hardware R&D, relying on commodity (CCID readers, plenty of them already installed in computers)
Third, it does not want to change everything or change the world or become the ubiquitous way of using bitcoins. It just wants to make "storing your coins"  safer than it would be with software keys. That's it.

Yes and no.

Yes, there are always attacks and successful attacks.
Yes, the computer should be considered a probably contaminated area.
Yes, using a pinpad reader is the obvious way to protect from unauthorized signatures from trojans.

But. This (a reader with a secure display or a card controlling it) is not the target of this development. The target of the development is simple: protecting the keys from arbitrary copying (which is still possible with offline storage netbooks and such instances, and also way cheaper). The ability to interact with commodity hardware and software, securely with the reader, displaying card-controlled information, just doesn't exist at the moment.

With "software data" you never know if and where there are two copies.

Certain adjustments in terminology must be made to make it understandable to "common people". Unless you have heard about common people talking about PKI, then you might not know that "people sign with certificates" (not private keys) or "sign with PIN codes" (not private keys).

Assuming I understand your question, the answer is yes. This implies that the *key* has any value that can not be replaced (like the ability to decrypt something valuable which is toed to the key or the ability to authorize transactions, like with bitcoin)


None that I know of. The primary purpose of crypto devices is usually to protect the keys. If you worry about degradation or something similar, it is not in the scope of a single device. Your backup procedures must be sound. Though most intelligent devices and applications do make internal integrity checks.

Sure, if your system is built up like that. Usually keys matter if you have something irreversible associated to them. For example encryption keys or in the case of bitcoin, value associated with the ability to use a *specific* key.

In usual PKI deployments the association is done by a CA and underlying keys can change without a problem.

In the context of SmartCardWallet, the ability to make secure copies of your wallet to a smart card card with the same capabilities is planned, but not in 0.1 version.

Hello,

Being a bitcoin lurker for a while, the main showstopper for me has been the complexity of required procedures for secure bitcoin handling.
As a hardware security/PKI guy, the obvious choice for anything handling private keys in a small scale is a smart card. Unfortunately there is no support for smart cards in bitcoin at the moment. There has been some initial work in the wiki: https://en.bitcoin.it/wiki/Smart_card_wallet but the work has stalled and it also seems that the expectations are not too realistic for the chosen solution (no card I know can do on-card programmable displays at the moment, for a reasonable price).

Building on the idea of storing the wallet securely in a smart card and requiring the smart card and a PIN code for any outgoing transactions, I made some tests with some hardware, based on information gathered from the web (https://en.bitcoin.it/wiki/Protocol_specification). AFAIU, the required primitives are plain ECDSA with secp256k1, ripemd160 and sha-256, where in fact only plain ECDSA is required to be implemented on the card.

I made a website, http://smartcardwallet.org, but I'm asking for feedback on feasibility here.

Do understand that this is a vaporware at the moment, but the time  to market is really short, unlike more fancy ideas. Suitable smart cards exist, required algorithms seem to be present, the set of tasks required for securing a wallet seem to be defined (at least in my head) and somebody on #bitcoin-dev even suggested to integrate a C library implementing the hardware wallet into bitcoind, if time permits (I would assume that time can be bought with money).

Given prior experience with the field, I would suggest that this can be implemented in a month or two, and would give a real physical wallet, with comparable security to traditional chip cards (without the bad terminal<->card protocol in EMV ).

Would somebody be interested in this? Would people pay for it (I wrote down some rough prices of hardware that would be required. For a successful business, the development cost should probably be financed through ready-made kits) ?

Saying this, I must admit again that I'm a bitcoin lurker with less than 1BTC on one account, but a somewhat seasoned person in the smart card, applied cryptography and overall security field. Bitcoin usually crosses my information barrier when things break (like the links in the "why" section) so I decided to have a look at the *technical* feasibility of protecting a bitcoin wallet in the fastest (in terms of R&D) and most secure way (in terms of validated, established smart cards).

What do you think? If there is enough interest that would justify a few weeks of interesting hacking, I'd continue with an overall POC hack.



(and somebody dealing with the moderation of the forum, please shift this topic to the tech & dev board)