Topic: Bitcoin smartcard Point of Sale terminal (Read 26856 times)

The project is now completed.

Yes that is right, you can buy a Bitcoin Card NOW at my web site: www.Blochstech.com

No pre-orders, no waiting, no nothing. Buy and use.

This is a userfriendly Bitcoin wallet card for only 20 EUR.
Anyone with a NFC enabled Android smartphone can accept it which should mean a good amount of existing physical Bitcoin merchants.

Another month, but I have meaty progress and good news to report!

The link at the end I ask you to download and share, it contains the source code, my research and progress so far. It has everything you need to get started etc etc..
(You wouldn't want the FBI to shut this down now would you!?)

What I have done so far is familiarize myself with the ZeitControl IDE and I have programmed some key commands and key/address pairs into the card-program. I still have to work out some kinks with correct command definition as their book has a really crappy way of showing syntax (no examples!  ).

I have started to program every day on my commute so I think step 1 of my plan could be done in a week or two. (Step 1 was making the terminal and card exchange addresses).

Quick guide to ZC IDE:
1. To add a file you first create and save it. Then you include it and rebuild. Only then its will show up as part of your project.
2. Under "help" and then Example projects->"Calc" you can easily access examples of basiccard code.


Now as for the good news: It seems ZeitControl does in fact have a Java library. As you may know Android is mostly straight normal Java and so this could mean putting the terminal program on Android phones could be very easy. The only major problem left is to figure out USB standards. (Android expects an out-going USB connection but the smart card reader is in-going, USB is a one way host->child standard as far as I can tell. Basically both reader and Android are normally "child")

Link:
http://www.4shared.com/zip/HdI942A-/BitcoinCardProject.html

A month huh.. yeah I'm not moving along so fast I admit it. However:

1. I have a game plan right now that says:
   A. Program smard card with a simple pub address and make it send it to a win-PC terminal program (ZeitControl software, only runs on
       win-PC )
   B. Program full card program.
   C. Get it to work and all/maybe an open source protocol for this stuff.
   D. People could at this step accept my BTC credit cards using say a laptop or do their own terminals/cards based on protocol
   E. Get it to work on Android - not easy, but vital more long term.

2. I have now researched Bitcoin itself a bit and I believe I am ready to do this. I was confused about the scripting system and thought my
    card would need RipeMD160 (a pain in the butt) - however since the card does no validation it will NOT be necessary.

3. If I didn't mention it the ZC5 something cards will be necessary for their SHA256 on-card functionality. EC-koblitz1 I still have to do
    myself, but it is actually kinda simple. (Think of it as an equation with two unknowns and the correct solution being a signature )

So yeah, next time I post here I might have a little source code with me!

Right guys sorry I dropped off the map for a while. I became a dad and pursued some other projects (waste of time mostly), I also got a job as a real software developer. Nifty stuff.

Anyway I do have some progress to report and this is still my main and only hobby project.

Not really, the basic language is one the first languages and probably C like in performance. Further the whole basic card has been built around it so the instructions are almost hardware level from the get go.

.. and of course assembly is horrible to code, I don't think anyone uses it.

Yeah I found out.

The EC-211 is just Elliptic Curve crypto over a integer field 211 bits large. It COULD likely have done secp256k1, which itself is just a variation of normal EC, but unfortunately their EC-211 does not use the normal EC curve.

y^2 + XY = x^3 + ax + b instead of y^2= x^3 + ax + b
secp256k1 is just specific values for "a" and "b"

This means the EC-k1 must be ported/implemented from some library - SHA256 is on-card. I still need to read more about pure BTC as I have been mostly reading about the cards and just EC.

I can't link to it directly, but is under "free download" on their english site: http://www.basiccard.com/.


Right now I'm looking into the T1 protocol, the basiccard terminal program from ZC will do it for you automatically, BUT it runs on a PC, not Android. After a quick look I doubt I could do T1 from the bottom, but other options such as reverse engineering the ZC terminal, contacting the company or finding a T1/DS1 library exist.

Thats all for now.

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

How much do you pay for your cards?

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

The EC I could probably do, but the SHA seems to take a lot of code to implement and the price-step lower is a card with 16kbyte to implement both algos + BTC program. (16kb basiccard = 2400 code lines)

Nope completely new to this. I might be interested in your package - I will just look through what I already bought first though.

Would your package include your card code so I can steal/port it XD? I am planning to make mine open source.

Yeah, but the cheaper cards allow quite few lines of code and SHA256 is the problem. ZC 5.4 is the one I think.

I was probably going to port algos from some example project if I did that, but yeah I hope it can be avoided.

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.

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.

They also provide you with a free IDE that lets you test/step-debug smart card programs and program your cards - example programs are included.

Anything else just ask.

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.

And thanks for the interest.

Yeah I'm just starting out alright, still I can see the path ahead.

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.

I would love to share notes, that you have come so far already is impressive - I myself usually work slower.

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?

I will keep it in mind. Currently I mostly need help to develop, which money won't help a great deal with.

Also I am still not entirely sure what I am trying to do is possible so I don't want to owe people money yet!


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.

Perhaps a glbse IPO ? I suspect you would get a lot of interest.

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://bitcointalksearch.org/topic/smart-card-wallet-take-2-94119

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.

Thanks Realpra 

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.

Progress report:
Okay learned some stuff.

Brands:
BasicCard SmartCards (SCs) - Brand by German Zeit Control company. Uses the Basic programming language (DOS like).
JavaCard/JCOP SmartCards - Produced by multiple producers (expensive).
ACS cards - Brand by Advanced Card Systems, runs AC-OS (hence ACOS name).

ACOS cards are developed using their software. ACS sells an SDK.

Basiccards seem more open, though buying an SDK from the company will likely speed your development time. At ~59 EUR I can do this easily. That includes hardware such as test cards/reader, books and manual.


I have tried basic about 10 years ago and I remember it as an easy and simple language. Further the implementation on those cards are done in hardware so it's more efficient than the java cards - hence the price difference.

Basiccards will cost 1.5-5$ I think, it depends a bit on how demanding the BTC app turns out to be.

I have found no "C/C++ cards" though there may well be more card companies.


When communicating with the cards via reader/writers various frameworks exist such as OpenCardSC and as I understand one included in the basiccard SDK mentioned above.


Most card companies can print your cards (including ZC) or you can buy your own card printer at a reasonable price. Some of those printers also have programming modules, though I don't know if they will work with the basic cards.

I consider it very likely that given a little time and quite little start-up capital (5-20K$) you could set up a very serious BTC card manufacturing plant and churn out your first thousand cards or so.
Given the demand we could totally supply the world with BTC cards.


So; I am strongly considering buying the ZC basiccards/SDK, does anyone have any reasons this is a bad choice?
(if the corp dies the same BTC card standard/app developed here can be deployed on a new card, so no worries there)

Does anyone want to join the project or help out anyhow? I estimate I would develop this maybe 5 times faster with a second guy on board - not including his contributions.
(two men dig more than one man in twice the timespan)

Gah almost all the cards I read about say that "the entire memory can always be read". How can I hide keys then?

Maybe I'm misunderstanding something.

EDIT:
Progress report:
SLE44-55 cards seem to be mag stripe cards in chip form. Security if any as I understand it is that the card and terminal establishes a secure channel.

If ONE terminal is compromised fake terminals could bring down any such system.

ACO3-5 cards seem to be what we are looking for with their own micro processor and signing capabilities. Will research more. 3-4$ lowest price I have seen so far:
http://www.smartcardzone.com/acos3.asp

Hi Realpra,

For questions on fees, the actual card used etc on OpenPay the bitcointalk user Isis is the person you want to ask. He is the one actually creating it.

My involvement is mainly that I think it would be incredibly useful if he can get all the parts to work together. He asked if he could fork the MultiBit code for the GUI that does the issue of the smartcards (which is fine by me). I think he plans to clone the multibit.org site and rework it to get that started too. They will both save him a bit of time.

The reference software stack he is producing is open source so I am happy to help.

Programming in C on the cards is the way to go IMO, especially now that there is a cbitcoin code library being written so you do not have to do all the bitcoin/ crypto work from scratch.

What would your fees be compared to OKPay?

Before I read through your entire thread, what smartcard are you using and why?


Progress report:
I have learned the card should be programmed with the C language. Having used it before its not all that bad for simple things.

The reason for this is that the cards for C cost half as much. Sure a dollar or so is not much, but if you want to equip a village with cards 100% that's suddenly twice the village size you could go for.

Also pre-printed cards seem common. I was worried all the first gen cards would be ugly and white, but hopefully they can now be Casasicius-level pretty.

Thanks.

I think the differences between OkPay and OpenPay are:
+ You can self issue in OpenPay ie create your new smartcard directly
+ You can run your own payment generation software ie run your own back office

But yes the offering that the customer sees is similar.

Really you can create whatever combination of services you want !

But doesn't OKPay and similar already exist?

Anyway I'm sure we can cooperate on a bunch of things and that your work is great.

Today you make a smartcard that anyone can self issue that works in all shops on the existing EMV systems.
There is a bridge to the Bitcoin network where all the crypto magic occurs.

It is a poor bridge that only works one way.

Tomorrow you create a cheaper, better system that primarily lives in BitcoinLand, but when it has to (for compatibility reasons) it crosses over the Bitcoin -> EMV bridge and talks to the legacy systems.

I read it now.

I will try to use what I can from their work and also share my work with them of course, however:

I am driven by the desire to see the existing banking sector BURN - I can't do that if I develop cards for them.

On a more rational node, EMV - after re-reading about it briefly - seems ludicrously unsafe and I think BTC can do better and stand on its own.


As for exactly what I will develop, I will describe the payment process below:
0. Card has 5-20 addresses so that even a shopaholic can use addresses with 6-block-verified balances.
1. ONE btc address sent to terminal.
2. If there's a balance on it the terminal requests amount/sends its receive address.
3. Amount multiplied "P" (0-9 nine number that cycles 1 each payment) sent to and displayed in terminal.
4. If the number fits, the user types their PIN (and for high security cards also P).
5A. Card locks itself for 10 seconds* and if everything was correct signs a TX and sends it back.
5B. Card locks itself for 1 minute in case of an incorrect code.

This security model can be further combined with a SMS service that monitors your addresses and warns you if there is too much going on immediately.

With this it would be quite impossible to fraud people without actually robbing them after learning the PIN. Since the merchant does not now P you could also shop just fine at a thief's supermarket every day (even low security cards would be quite safe with a warning SMS service).

All addresses and keys would be known by the owner of the card so that he may recharge it or empty/"block" it.

The card would self-fund by sending half of the just used address to the address just before itself in the cycle. The terminal may request more addresses if one is not enough for a big payment.


*Time here measured as "time while powered by a terminal".

EDIT: Also, I just realized, the connector cable + android would be cheaper for merchants to buy than existing VISA/Mastercard terminals and would not rely on being signed/blackbox security.