Show Posts
|
Pages: [1]
|
Hi, have you heard of OpenPay? https://bitcointalk.org/index.php?topic=92055.0How I wish these 3 card related projects can be merged or at least be compatible with each other so that merchants could have only one device for all. (I know this project is not aimed on customer <=> merchant transactions) Don't take me wrong, I love diversity and competition, but what we need now is single product that can be used by masses. 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.
|
|
|
I disagree. The purpose of this device is to protect the key from being copied and to sign requests. Providing the correct address is a concern of the recipient of the funds, if the POS terminal is infected and the store does not get its money then it has nothing to do with the card.
I think this smartcard is solving a very specific problem and that other concerns must be addressed elsewhere.
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.
|
|
|
A smart card is of course one of the best possible compute platforms for a portable wallet. Correct me if I am wrong but the software on the card can create new private keys in secure memory which can be extremely difficult to access outside of the provided API(like some sort of tunneling microscope).
Do these cards support signed software to prevent malware from being installed? I know some POS systems allow something like that.
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)
|
|
|
Thanks for the link, interesting discussion in the bitcoinj group.
I share Mike Hearn's concerns about a virus showing bogus addresses - I think a successful "hardware Bitcoin security device" needs to be immune to such attacks, and assume the threat model is a computer infested with a sophisticated virus that targets this wallet, can fake address, etc...
I think I'll be content to watch this project and others for the time being. I would want to own one such device when a usability & security threshold is reached, but perhaps it's premature.
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.
|
|
|
How much do you pay for your cards?
Look around in smartcardfocus.com, cryptoshop.com, smartcardsource.com etc. For cards in quantities the prices are of course cheaper. I think I will have to pay 3.8$/piece in order to get the crypto functions I need. (ZC5.4 card - 16 kbyte, SHA256 and EC-211 on co-proc).
EC-211? Bitcoin uses secp256k1 curve ... Would your package include your card code so I can steal/port it XD? I am planning to make mine open source.
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. If the cards you have are BasicCard-s, then I'd be "professionally interested" in learning more about them. They are. According to the producer they cost 1/3 of javacards/multiOS cards. They use a version the Basic language which is DOS like. The cards run near-byte code at the hardware level which supposedly means they require less EEPROM than javacards etc. (hence the price difference). I don't know to what extent this is all true, but they SEEM cheap when I compare them to other cards on the net. 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. A comprehensive manual/datasheet/Basic language tutorial is free for download on their site - the SDK just lets you have a cybermouse and some cards on top of all that otherwise free stuff. Anything else just ask.
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.htmNevertheless, 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Would be strange to go back in time...
|
|
|
What you are doing seems very similar though focused on securing the computer wallet. I can see you chose the JavaCard; with dropping hardware prices that's probably a good choice too.
JavaCard is the natural choice for such things, in this sector, in 2012. I would love to share notes, that you have come so far already is impressive - I myself usually work slower.
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. Do you sign transactions on the card or do you only store information on the card? If its the second, how do you prevent keys leaving the card and getting used by someone else?
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. Progress report: I have looked into Bitcoin a bit more and what my cards need to do. It seems ECDSA is used to sign and what is signed is a SHA256 hash of the transaction data/tx.
Both of these algorithms are unfortunately a bit heavy computationally for a smartcard - simply programming them could use up a lot of/all EEPROM. Hence some co-processing will likely be needed - I still have to research more on what my exact options are there.
Further I have found that the card needs to store a reference to any transaction it wants to spend as this is required info in a tx. This will not be a major problem as most of these txs will be generated from the card itself and only a few will be "refills" that may be relayed to the card by a merchants terminal.
Fraudulent data from a terminal to the card can at worst only lead to having to pay twice and some unintentional doublespends by the user - security is still fine.
It will still be a no-trust security model.
I have also received the SDK which is very slick and all, I will share it with you guys when/if possible.
Next is finding out the exact card specifications needed (16EEPROM? ECDSA/sha coprocessor?) and what to program. If an algorithm is not supported I can program it, but this is CPU? expensive and a bit time consuming.
ZeitControl sells many different cards, some with different coprocessors and some with lots of EEPROM for custom implementations of unsupported things.
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.
|
|
|
Progress report: Okay so I have been reading the technical datasheet/manual on the basiccard website.
I have found the following: - Communication standard should be T1 - faster, newer and less error prone than T0. - 200-400 lines of basic code will be able to run on a 2kb basiccard (0.9-1EUR). - Files/directories can be locked completely or assigned a pub key you must communicate by. - The card may be locked into a RUN state in which it can no longer be read or re-programmed. This would be the product the users get, so that a corrupted/thief terminal does not wipe/re-program the card or steal your keys.
Additionally ZeitControl, the company behind the cards, is a member of the ISO 7816 committee since 1996? so they are quite big, proven and respected.
In light of this I am buying the SDK and going forward with these cards.
Hopefully the basiccard "enhanced basiccard ZC3.12" card with 2kb EEPROM will prove adequate as they are very cheap - I think the cheapest on the WORLD market.
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.0Current 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, I just created this wiki page. I'm coining the term here, I think ... not sure what was it called when discussed on Bitcointalk. My question is: Has anyone implemented this "2 factor paper wallet"? Is it being worked on? x-post to SE 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.
|
|
|
I have been thinking about somethin like that, too. But I came up with some attacks, that have to be prevented for a smart card to be useful (more than some kind of offline storage netbook).
In my opinion the system to which the reader is connected has to be considerd as totally corrupted with trojans, rootkits, etc.
The reader or the smartcard has to ensure, that the host system can't have arbitrary signature requests signed by the card. The only solution, that came to my mind, was to display the to be signed transaction at the reader (which is secure, and therefore does not display a bogus transaction). Then the user has to enter the pin/password at the reader (so it can not get into the host system), which gives it to the smartcard, which in turn can use it to decrypt the private keys and sign the transaction.
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.
|
|
|
I need to argue with this line "Smart Card Wallet does the obvious: stores your bitcoins securely inside a smart card."
the bitcoins are stored on the NETWORK. The KEYS are stored anywhere you want to store them. Multiple copies at multiple locations.
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).
|
|
|
Sure, if your system is built up like that. Usually keys matter if you have something irreversible associated to them.
In usual PKI deployments the association is done by a CA and underlying keys can change without a problem.
I apologise for the awkward wording of my question. Lets forget the Bitcoin for the moment, just look back into the past for the PKI systems that already exist, are deployed and in use. 1) Is/was there any system where the cryptographic keys carried any value higher than the cost of inconvenience to replace them? 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) 2) Are/were there any smartcards/cryptodevices that provide internal error detection and correction and use it to signal impending failure instead of simply zeroizing the key material and self-destructing?
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.
|
|
|
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 ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) ). Given your prior experience I have one question: is anyone storing irreplaceable data on the smartcards? Thus far in my limited experience all practical cryptosystems relied on the fact that in case of smartcard/device failure the custody chain can provide replacement of the key material at a cost of inconvenience. Is there any practical application where lost/damaged keys have actual value lost together with them? 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 ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) ). 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)
|
|
|
|