I would say extracting the key is the hard part. The protocol is open, so once you have the key there's nothing stopping you from emulating a card. We're actually going to do just that as a way for users to try out the system before buying a real hardware card - instead of talking to a local smartcard (microSD inserted into the phone), they would establish an HTTPS connection to a server and send/receive data that way - it would work like a remote smartcard accessible over HTTPS.

This obviously doesn't offer the same guarantees (the entity running the server would see your requests to the virtual smartcard, so it could theoretically tell when you're paying someone and who you're paying - based on their public RSA key). So you would have to trust them considerably more than you would if you had a physical card in your phone, under your complete control.

The problem with smart cards is that they don't have a calendar.
If you want a card to know what time it is, you need to tell it after each power on.
Normally people do it via a signed messages - in this case it would need to be signed by the issuing authority, I would say.
So a locktime, or basically anything time related, complicates stuff pretty much.

You mean the same GPS signal that Iran spoofed, to land the US drone on their airfield?
Trust me, you don't want it Not to mention details like: GPS does not work inside buildings.

As I see it, the card shall only trust messages signed by its issuing authority, or messages from others cards (but only because they have public keys signed by a trusted issuing authority).

There is also a fairly easy solution to pop up a card, without a need for it to know time, parse blocks, check difficulty, or play with SPV.

1. The card generates a new bitcoin private key and outputs its public address, signed with the unique card RSA key - gives you this data via a terminal.
2. You send this information to the issuing authority and transfer the coins to the address.
3. The authority verifies the origin of the message and checks the balance at the bitcoin address. Likely they would charge a fee for it, to have a business case.
4. The authority sings a message (with its master key) confirming the balance at the given public address and sends this message to you.
5. Using your terminal again, you forward the signed message to your card, effectively popping up its balance, since by verifying the message the card confirms that the key contains a certain amount already.

But it is all about the trust to the authority and how well they can protect the master key.
This would be the weakest link and the master key leaking out would have been a deal breaker, for all the cards out there.
These kind of applications should normally have a life cycle - like a banking card; you just throw it away after a few years.
And the master keys should cycle - so even if some old master key leaks out, the new cards shall be safe.
Usually there is an even and an odd key - only one is used in a certain period, while the other one is being updated by any possible chance (e.g. while adding more balance to the card).

Well so long as we are relying on trusted things, one could have a virgin mined coin and a time-stamp authority using TPM hardware also, which would define just that coin is valid if its virgin (its address is in the coinbase/block that the card can present) and the public key is signed by a certified-as hardware contained key, and the difficulty of the mine is >= difficulty at that time-stamp (to prevent cheaper mining at historic difficulty rates.

Thats a looser definition of time-stamping as its not directly blockchain auditable, though it can easily be made indirectly blockchain auditable by including the time-stamping authorities signed master-hash into a bitcoin message in the block chain.  It is looser because doesnt quite adhere to the 21mil limit - its follows bitcoin difficulty but doesnt contribute to it.  To track it strictly you'd need to what gmaxwell said with SPV.


Btw I presume people also know about or recall firmcoin https://bt.irlbtc.com/view/232898.0 by Sergio_Demian_Lerner, it also contains a private key, only in that case uses the hardware to sign transactions, and does do things with SPV information.  I presume he made at least a prototype from the initial post photo.


About the private key, and addative homomorphism, its not explicitly stated that I saw in the article or thread, but I think what is going on is that the smartphone app has the second half of the coin, to compose the address (as with BIP 38) except thats using ECDH (curve multiply) vs addative homomorphism (analogous effect).  Then the smart phone transfers one half of the key to the other smartphone, and the hardware key container transfers the other half (via hw certified RSA as described in this thread).  The key-half held by the phone cant be changed between transfers, without going via the block chain, so all previous parties who held the coin have enough to spend the coin online, once the coin private key is taken from a card.

[EDIT: and the purpose of this is like a poor-mans observer protocol like in Brands and other offline ecash systems: the card cant tell much because what it knows is not correlateable with the public key].

What about instead at each transfer the private key (composed of x+y where the public key is Q=xG+yG, x held on card, y held on smart-phone) is resplit as in proactive security at each transfer?

So far the design is smartphone and the card never know the full private key z=x+y mod n in one place, unless and until the coin is spent online (by removing it from the card).  To preserve that security assurance, the card can instead create r=random, send RSA(z'=x-r) to the other card, and r to the other phone.  Then the other phone learns y'=y+r and hte other card learns x'=x-r, and the private key and public key remain the same: z=x+y=x'+y' mod n.  But yet the previous smartphone owner does not retain power to spend the coin, even if he physically stole it back from you as he is missing y'.  The recipient smartphone will not consider the payment offline validated unless it can check that x'G+y'G=Q and that x'G is certified by the card.


(I used this mechanism in my still not yet posted, really must get around to editing last bit and hitting send, non-TPM model for this).

Adam

Hi Adam,

The mechanism you described (which is pretty cool btw!) would protect against physical theft of the card by a previous owner, in the absence of any other security measures. But in the case of the OtherCoin, each card is protected by a 6 digit PIN code and you get 3 tries, so stealing the card doesn't get you anything unless you can also get the PIN code. The card is also physically inside the phone, so it would be hard to steal without the user noticing it (unless he leaves the phone unattended for a long time). Finally, previous owners have no way of telling that you did not forward that key to someone else - since there's no trace of the payment anywhere, they could steal your card only to find out that you've already spent the key that they have the other half for. So I think we're safe, at least in the current model. Of course, there's always the Rubber Hose Cryptanalysis method (http://xkcd.com/538/) - that is sure to reveal the PIN in record time .

No problem there: When you load a coin give it a SPV proof that it's loaded, the bitcoin network provides the date.

That's tricky.
You know that all the coins in the existence are born as a coinbase and I do not quite see it how a card can estimate a legitimacy of a coinbase while not having access to any reliable time source. Not to mention that it would need to follow a chain - which is hard for such a small piece of embedded hardware.
1MB that a single block can heave - for such a tiny card, its really a lot. And even if you do not parse entire blocks, one transaction can be as big as 100kb.

SPV is definitely a path worth exploring.

But @drazvan, do you even have ECDSA and the Kobuz curve on your platform?

Yes and yes. They are both there. I already have them working (ECDSA on secp256k1) but the only place the Koblitz curve is used is to calculate the public key corresponding to the private key received (to check that the sender didn't just send a random number but the actual private key to the public key it's pretending to use).

I just realized, an easy way to think about all this is if you're familiar with GSM networks - the SIM card (a smartcard) secures the key that is used to identify you to the network. It does not speak the GSM protocol, it cannot talk to towers or call numbers or receive texts. It just securely runs an authentication protocol with the network, using the phone to relay its messages. The SIM card never knows if your subscription is even active or how much credit you have (if it's a prepaid account).

OtherCoin works in a similar way - it only secures keys and offers some guarantees regarding their status (never revealed before). The wallet runs the Bitcoin protocol and handles everything else. The only thing it cannot do itself is sign transactions to send funds away, it asks the card to reveal its half of the key or just send it to the other card in encrypted form.