Bitcoin smartcard Point of Sale terminal

[casascius]

Cool. I think I'd establish a wiki page for this project first, put all details there so that people can contribute.
I don't really have any specific questions about the PoS part right now. Unless maybe this: is it possible to make them work with any arbitrary smart card? Is it just a matter of the software running on it? I would imagine so...

If that's the case - will they be fast enough to perform block scanning and signature validation and stuff? Not to mention that they'd basically be running a version of bitcoin software, and that means validating the block chain and all the other stuff that it does...

When these guys build these terminals, they are nice enough to use quality 3rd party hardware for which documentation is independently available.  And these terminals run "monolithic" code: you interface with the hardware ALMOST on a direct level... there is a layer of abstraction (its API library makes syscalls into the firmware to get things done) but it's all blocking calls, there's no pre-emptive multitasking and no kernel doing anything in the background.  (Multiple threads and processes are supported but it's purely cooperative, when one thread/process blocks, control goes to another).

The interface they provide to the smart card reader IIRC is so low level that it's probably possible to get it to do anything the hardware supports.

One notable thing about the platform is they will only run signed code.  A bank can lock down a terminal with a public key and then the terminal will only run binaries signed by the bank.  But if you acquire an unlocked terminal (it says "DEFAULT CERTIFICATE" on the home screen) then their SDK comes with the private key to sign binaries for development purposes.

[1714823321]

1714823321

[1714823321]

1714823321

[1714823321]

1714823321

[Vasili Sviridov]

I can run the following on a VeriFone Vx570 POS terminal

Well, that's a start Sprinkle it with some cryptography and we're almost there...

When these guys build these terminals, they are nice enough to use quality 3rd party hardware for which documentation is independently available.  And these terminals run "monolithic" code: you interface with the hardware ALMOST on a direct level.  The interface they provide to the smart card reader IIRC is so low level that it's probably possible to get it to do anything the hardware supports.

Excellent. Also, would they have enough resources to support both debit/credit/bitcoin in same software?
Although that probably would not be possible due to the fact that companies who lend those terminals to people would object. Because the transaction fees are their bread and butter...

Okay, so we have our PoS developer. Now we need a smart card developer

[casascius]

Excellent. Also, would they have enough resources to support both debit/credit/bitcoin in same software?
Although that probably would not be possible due to the fact that companies who lend those terminals to people would object. Because the transaction fees are their bread and butter...

YES, the VeriFone terminals I'm familiar with are designed to support up to 13 isolated apps.  Each has its own file system partition so they can't steal data from one another, and they're targeted to not just do credit cards, but other things like EBT (food stamps/electronic benefits), time and attendance (punch in and out), etc...  I made a simple video poker app for one just to prove I could do it.

Although they don't have huge amounts of resources (4-8 MB of memory), they are physically designed so they can execute code directly out of flash memory (saves RAM) and the executables tend to be very small...in short...this should be no problem.  Notably, they are also physically designed to protect encryption keys - with specially caged memory that automatically forgets encryption keys if you try to physically tamper with the unit.  Pretty robust.

Because of the code signing requirement you wouldn't be able to add apps to terminals provided by a bank (if the default certificate were overridden) but acquiring new terminals with the default certificate is pretty cheap.

[Vasili Sviridov]

Looks like those terminals go for about $300-$500 on ebay... Pretty pricy.
Do you have one to play around with in spare time? Just to run some crypto code to see how fast it is?
Do they have a dedicated crypto chip by chance to speed things up?

[casascius]

Looks like those terminals go for about $300-$500 on ebay... Pretty pricy.
Do you have one to play around with in spare time? Just to run some crypto code to see how fast it is?
Do they have a dedicated crypto chip by chance to speed things up?

I can get them for $100 to $200 for a basic refurbished model with dialup or Ethernet, as can anyone seriously in the business of buying in bulk.  The refurb market is lively because businesses close their doors all the time. Refurb companies replace the exterior facing parts and they work good as new for a low price.

No dedicated crypto chip, just ARM CPU, but for signing transactions it is plenty.  The only dedicated crypto related components are tamper resistant memory and smart card readers.

Oh I forgot, they also have spots where smart cards can be permanently installed like by the bank, these are so you can add your own TPM etc. So 3 semi permanent slots (sized like gsm sim cards) and one full size slot for customer cards.

[benjamindees]

Because of the code signing requirement you wouldn't be able to add apps to terminals provided by a bank

In my opinion the biggest hurdle is that the transaction processing business is a total racket.  There are theoretically several different tiers of processors but they are all owned by the same company so they dictate everything from hardware and software to banks to fees.  And then there's the fact that I've never actually seen a POS terminal in the US with a smartcard reader.  They can't be that common.  Instead of messing with existing POS terminals you would be better off making a small ethernet-ready box that runs the necessary software and interacts with your Bitcoin cards or smartphones directly.  I'm not joking when I say it would end up being cheaper to go this route.

[ByteCoin]

custom ECDSA implementation for JavaCard is really slow
http://amadousarr.free.fr/crypto/ECDSAJAVACARD.pdf

I've been reading that paper. They seem to be using a slow modular inversion routine that runs 150 times slower than multiplication and also a point multiplication routine that involves many inversions. From this, it looks like they're using affine coordinates rather than projective for the point multiplication. This is a serious shortcoming.

I would hesitate to use that paper to support an argument.

ByteCoin

[casascius]

Because of the code signing requirement you wouldn't be able to add apps to terminals provided by a bank

In my opinion the biggest hurdle is that the transaction processing business is a total racket.  There are theoretically several different tiers of processors but they are all owned by the same company so they dictate everything from hardware and software to banks to fees.  And then there's the fact that I've never actually seen a POS terminal in the US with a smartcard reader.  They can't be that common.  Instead of messing with existing POS terminals you would be better off making a small ethernet-ready box that runs the necessary software and interacts with your Bitcoin cards or smartphones directly.  I'm not joking when I say it would end up being cheaper to go this route.

How much cheaper?  Those terminals are exactly what you describe, with hardening to keep cryptographic keys safe. They are perfect.  What more do you want?

I write time and attendance software for a living. I have written time and attendance both for POS terminals as well as little boxes running Linux just like you describe. POS terminals with smart card are easy to acquire, I have one sitting right here, it is just an option that adds a few bucks to each unit. And I appreciate the fact that I can lock the hardware down with signed binaries if I choose to, so I can sell a trusted product. The point of it is to secure the contents right?

Anybody can buy their SDK, take their course, and start compiling apps. I am not a banker and I was able to do it.  

[casascius]

Their SDK I should mention costs $10k to $20k. So one who wants to develop apps has to be serious, but that is chump change for someone building a payment processing network.

Also I wrote my own server side code. They hold no monopoly on that either.

[benjamindees]

Well, there are really two separate issues.

In my experience banks and credit card processors tend to have conniption fits when presented with non-standard hardware or software.  Telling them you want to install a competing processing service on hardware that they have any control over is just an excuse to raise your fees or cause you problems.  I don't know the usual arrangement, but if it's common for the POS terminals to be subsidized or locked-down then you can say "adios" to the dream of running Bitcoin on them.

As for smartcard readers, I was referring to currently-installed hardware.  If it's really just an easy and cheap (<$400) upgrade, then great.  But if a substantial portion of older POS hardware in use isn't capable of easy upgrade, then at a certain point dedicated hardware becomes the better choice.

[Vasili Sviridov]

Update from the guy who works with SIMs. He talked to his sales rep, and rep said that with such small order volume a 64K JavaCard would probably go for $0.55-0.60. That is in Singapore. More volume obviously means cheaper cards.

[ChrisRich]

Update from the guy who works with SIMs. He talked to his sales rep, and rep said that with such small order volume a 64K JavaCard would probably go for $0.55-0.60. That is in Singapore. More volume obviously means cheaper cards.

What I don't get is why anyone would make effort to go backwards in the tech tree? Smart cards are just another point of failure and expense when we already carry smart phones?

I've been doing work with point of sale (professionally) for over 9 years now, and you can trust me when I say that I've got no love for the existing infrastructure.

I'd push for a in-store product registry with Aztec(public domain) or similar 2d barcoding on the items for information and purchasing. Scanning one of these items will bring up the entire history of the item which can in many cases add value to the store/products.

When you spot something you wish to own, you'd scan it (take a picture) with a mobile app that would handle the purchase and authenticate. You can place the item in your cart and at the checkout the cashier scans the items a second time to confirm which ones are paid and which need to be paid to continue.

This would allow the retailer to do promotions on items and track those sales, while still allowing everything else to be purchased normally. Retailers LOVE solutions that they can ease into slowly without shutting down the store for a few days.

[casascius]

In my experience banks and credit card processors tend to have conniption fits when presented with non-standard hardware or software.  Telling them you want to install a competing processing service on hardware that they have any control over is just an excuse to raise your fees or cause you problems.  I don't know the usual arrangement, but if it's common for the POS terminals to be subsidized or locked-down then you can say "adios" to the dream of running Bitcoin on them.

Seems to me this would be for good cause.  If you administered these things, why would you go to the effort of acquiring a secured payment platform only to let people run whatever they choose on them?  The bank card industry suffers ingenious data thefts left and right, so you'd be hard pressed to blame them for this.  That said, if their customers are demanding it in droves, and there is a revenue stream to be shared, and their engineers can inspect and sign the code, that's what will get them on board.  They are fairly receptive to my time and attendance app for those reasons.

As for smartcard readers, I was referring to currently-installed hardware.  If it's really just an easy and cheap (<$400) upgrade, then great.  But if a substantial portion of older POS hardware in use isn't capable of easy upgrade, then at a certain point dedicated hardware becomes the better choice.

Look here, a Vx570 with smartcard reader for $299: http://www.terminaldepot.net/products/VeriFone-VX570-6mb-w%7B47%7D-Smartcard.html

Despite it only having 6 MB of memory, that goes a LONG way on this platform as compared to an app for a PC.  My time and attendance app, complete with a statically linked TCP/IP stack with SSL, is only about 0.5 MB.  This device isn't going to be able to hold the whole block chain by any means.  But it would be perfect for kicking off transactions from a MYBITCOIN or equivalent, or talking to a participating bitcoind when needed.

The real travesty, the way I see it, is how valuable retail merchants consider the surface area of their countertop.  You can easily put another terminal in there for less than $400, they're more likely to balk at having to have one more gadget.  That said, at this early stage, if they really want to deal in Bitcoins, they're not going to mind.

[Vasili Sviridov]

What I don't get is why anyone would make effort to go backwards in the tech tree? Smart cards are just another point of failure and expense when we already carry smart phones?

The problem with using bitcoin in PoS scenarios is the necessity to wait for confirmations. And smart cards are infinitely more tamper proof compared to cell phone apps. One reads about many hardware platforms (like high-end phones, or game consoles) being hacked and made run custom software. In the case of SIM cards, for instance, you might hear a story, that involved SIM cloning, and it was only possible with very low-grade cryptography used, which allowed to be broken after 65536 brute force attempts.

And if you can easily clone things, that means that the merchant will have to wait for confirmations, in order to avoid double-spent coins. It will render the PoS unusable in most cases.

[casascius]

And if you can easily clone things, that means that the merchant will have to wait for confirmations, in order to avoid double-spent coins. It will render the PoS unusable in most cases.

A terminal that can consult with a well-connected instance of bitcoind can validate against a casual double spend, a topic that has been well discussed in the past.  The tl;dr of it was that, even without confirmations, once a transaction has been well broadcast amongst lots of nodes, and no other competing double spends have been received (regardless of confirmation status), it's pretty difficult to reverse a typical retail transaction with less resources than the transaction is probably worth.  And also, knowing that scalability of Bitcoin depends on the formation of bitcoin "banks" like MYBITCOIN, these "banks" when trusted by the merchant may also be able to guarantee availability of funds on their own balance sheets without  waiting for confirmations in the block chain.

[casascius]

A terminal that can consult with a well-connected instance of bitcoind can validate against a casual double spend

The ten-minute blocks are not a fundamental limitation for point-of-sale. I can imagine a few mining pool operators collaborating to offer a service to merchants where the pool operators are prepared to validate any transaction within a few seconds on the basis that "if any of the pool operators mines a block, that transaction will be in the block because no earlier spend has been seen".

With the mining pools accounting for about half of generating capacity, that ought to provide enough reassurance for point-of-sale transactions.

Yes, great idea, those mining pool operators, after "validating" any such transaction, could also automatically work to fight any block that happens to contain a double spend against their validated transactions as part of their services.

[Vasili Sviridov]

Good point, casascius. Looks like the implementation of this particular scheme is way to expensive and hard to integrate. If the window for potential doublespend is indeed short, at shouldn't be a problem for 99% of all use cases.

A few things were voiced in this topic, one of them is the use of sites like mybitcoin to arbitrate payments. That kinda makes it centralized, and the whole point of bitcoin is to avoid centralization.
I have a few ideas on the subject, which I'll voice in another topic.

[oillio]

The confirmation issue can probably be overcome.  But there is another issue that cannot be solved with smart-cards.

A smart-card does not have an independent display.  You must trust the POS system that you plug your card into.
The POS can claim that it is debiting $1 from your card, while it is really transferring $100.  You won't notice this until you try to use your card again, which is probably much too late.  There is no way to overcome this issue, except for using a device with its own display (like a smartphone).

This is not an issue for credit cards because the bank can do a charge back.  If this happens to you (and it does happen) you just call up your bank and they give you your money back.  But Bitcoin is different...

[Vasili Sviridov]

discussion cont'd here : http://bitcointalk.org/index.php?topic=7872.0

bitcoin debit card in physical form might not be best idea.

[ChrisRich]

The confirmation issue can probably be overcome.  But there is another issue that cannot be solved with smart-cards.

A smart-card does not have an independent display.  You must trust the POS system that you plug your card into.
The POS can claim that it is debiting $1 from your card, while it is really transferring $100.  You won't notice this until you try to use your card again, which is probably much too late.  There is no way to overcome this issue, except for using a device with its own display (like a smartphone).

This is not an issue for credit cards because the bank can do a charge back.  If this happens to you (and it does happen) you just call up your bank and they give you your money back.  But Bitcoin is different...

Yes and the lack of a display on the smart card nixes any added information value of the effort which is why I suggested 2D Barcoding as a win-win. The retail perks of having more information given to the customer and the retailer is going to offset any concerns of cost to implement.

Plus the interface on the phone would have the option to challenge the bitcoin account holder for validation, meaning the amount paid will be verified, and it can't be stolen and abused by simply physically having the phone.