Bitcoin smartcard Point of Sale terminal

[Realpra]

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)

[1714138903]

1714138903

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

[unclescrooge]

Thanks Realpra 

[JustThinking]

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

[Bitcoin Oz]

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)

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

[Realpra]

Thanks Realpra 

And thanks for the 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://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.

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?

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

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.

[JustThinking]

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.

[Realpra]

JavaCard is the natural choice for such things, in this sector, in 2012.

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)

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.

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.

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)

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

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.

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

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.

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.

[JustThinking]

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

[Realpra]

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 caught up on everything in this thread yet, very interesting project though. Can these cards be programmed with assembly and if so would it help much with memory constraints?

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.

EDIT:
Another thought, recently in Ireland there has been a boom in some universal readers to pay for tolls, issue mobile phone credit etc. Don't know what they are or who runs them but it may be an opening for a bitcoin card reader to get in if other countries use them too.

My main focus right now is a card talking to an android phone - even that is very advanced and android phones are more universal than the universal readers of one company.

EC-211? Bitcoin uses secp256k1 curve ...

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

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.

[Realpra]

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!

[Realpra]

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

[Realpra]

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.