Most of the smartcard code is complete, yes (I would say around 80% of it). There's no code on the wallet side yet, I want to complete the smartcard part and freeze the functionality before I move on to the wallet side. I'm in the process of trying to raise some seed funds to allow me to work on this full time (getting it to this point took about 3 months of me working weekends and in-between other projects).

About the issuing authority, I mentioned a bit earlier that I intend to have multiple authorities/issuers certifying cards. The code cannot be open-sourced due to the NDA restrictions put in place by the hardware manufacturers (if you've worked with NXP before you know what I mean ), but I guess we can always share information and source with a third party / issuer if they are also under an NDA.

I could use some help with the development, just need to figure out the financials first, doing this part-time is annoyingly slow.

In the current implementation, the card does not know anything about Bitcoin balances (it cannot parse transactions or do anything Bitcoin-related). It doesn't even know the actual address you're going to use (since that is always the sum of 2 public addresses - one that it generates and another one that the wallet generates).

However, the wallet holding the OtherCoin card does know the address, so part of the protocol could be demonstrating to the other wallet (not the card) that the funds are there. This could be done completely outside the smartcard - a wallet to wallet transfer of transaction data to prove that a certain output has a certain value, just like gmaxwell suggested. I really like that idea!

That's the beauty of it... it doesn't ... the card never knows anything about Bitcoins or balances or anything like that. That's the job of the wallet running on your smartphone or whatever you have the OtherCoin card inserted into. The wallet acts like any other "watching" wallet, it can monitor balances, etc. It's only when it tries to pay from that address that it needs the private key - and it can either ask the card for it (in which case it's removed from secure storage and the wallet just uses it on the Bitcoin network) or it can ask the card to securely send it to the recipient's card (in which case it is encrypted with the recipient's RSA key and given to the wallet in encrypted form to be sent to the other end).

The card cannot sign Bitcoin transactions and only acts as a very "stubborn" Bitcoin key generator - you can ask it to generate a key, it will give you the corresponding public key but keep the private key secure, allowing you to do anything other than transfer the funds away. It's the wallet's job to monitor the blockchain, establish balances and communicate to the recipient (since the card has no communication capabilities other than its physical interface to the smartphone using the microSD slot).

Correct, the only time the issuer is involved is at manufacture time when the RSA keys identifying each card are securely generated on-card and stored, then their corresponding public keys are signed by the issuer and the certificates are also stored by the card to be presented to other cards.

Just as gmaxwell said, each card needs to make sure that it's talking to a similar card, not to a generic chip with fake RSA keys on it.

Exactly. The recipient of the funds presents his signed RSA-2048 key signed by the issuer (us) and a nonce. The sender verifies the signature (to ensure that it comes from a trusted card), then uses its own RSA key to sign a message containing the Bitcoin private key + Bitcoin public key concatenated with the nonce and the destination address, then encrypts the message with the recipient public key and sends the encrypted data together with its own signed public key to the wallet.

So it basically signs a message saying "I hereby certify that the key <BITCOIN_PRIVATE_KEY> with corresponding <BITCOIN_PUBLIC_KEY> has been transferred via an encrypted channel to <RSA_DESTINATION_KEY> with a random nonce of <NONCE>", encrypts it and sends it over to the other side.

The recipient checks the certificate of the sender, then decrypts the message, compares the nonce to the one it has sent out (to prevent replay attacks), compares the destination address to its own (to prevent replays of messages sent to someone else), compares the public key with the one it computes locally from the private key, verifies the signature, then stores the key into its private storage.

I'm aware that there is a lot of redundancy in there (the Bitcoin public key can always be computed from the private key), but it helps keep parties honest.

Unless everyone suddenly implements the protocol (any of the protocols described here), the Trezor must still account for merchants that don't. If the user has paid before at that merchant, he will notice if the connection is no longer authenticated/secure/etc, but if it's their first time there they might simply assume that the merchant does not implement it yet and go right ahead and pay. The Trezor should probably display a message saying "We could not confirm that the address you are paying to belongs to the merchant, proceed at your own risk" and leave it to the user to determine if the address is correct.

Maybe the Trezor should also indicate that the user should contact the merchant offline (phone call?) and ask if they use the Payment Protocol and if they don't, suggest that they implement it in order to securely receive payments.

I really don't see a way to have both backwards compatibility and full security against malware - but I'd love to be proven wrong.

Piotr, the way it works is that there are two separate operations. The first one (called REVEAL) takes the Bitcoin private key out of the secure storage, encrypts it with the RSA-2048 public key of the recipient, then moves it to a public buffer (no longer in secure storage) that the wallet can read it from as many times as it wants. Once the wallet has successfully forwarded that encrypted key to the other end, it issues a second command called REMOVE that clears the public buffer. The Bitcoin private key is erased from secure storage as soon as REVEAL is called, but it is still available in its encrypted form (decryptable only by the recipient) in the public buffer until REMOVE is called.

So in the case of a communication breakdown, the sender can keep reading it from the buffer (or just cache it internally since it's encrypted) and retry sending it to the recipient that is now the only entity capable of recovering that Bitcoin private key.

The scheme also does replay protection by using a nonce sent together with the RSA public key (preventing you from resending an old recorded payment message to a recipient to convince him to reimport the key into its private storage).

What I've described is not a matter of CAs, it's a matter of backwards compatibility. Since merchants are not forced to use the protocol, some of them will not use it (at least at first). So the Trezor must be able to deal with these situations and allow you to sign transactions even if the merchant did not use the payment protocol. But this also means that malware running on your computer could simply replace the Bitcoin address and claim the merchant does not run the protocol, effectively making you pay someone else entirely. Of course, if you know the merchant and you know they do implement the payment protocol, you'll notice if they appear to have suddenly stopped using it for your transaction.

That's actually the plan, but we need to make sure that the person reporting the hack is not the person that has actually hacked the card. If we have a physically intact card that contains a private key that we've seen a spend operation for on the blockchain and the card can keep track of the previous owners of that private key, it can be asked to reveal that chain of previous owners. If two or more physically and logically intact OtherCoins report this, we can compare the chains and find the actual card that has performed the double spend.

The wallet will most probably employ Bloom filters to monitor the blockchain - but most wallets already do that, don't they? The wallet knows the public keys / addresses to look for and it's up to it to fine tune the Bloom filter to not reveal the exact addresses it's looking at. I wouldn't want to implement that on the smartcard.

Piotr_n, there is no private key that all the cards share. They all share the public key of the issuer in order to be able to verify other cards and ensure that the Bitcoin private keys are only transferred to cards issued with the same restrictions and running the same software.

Each card comes with its own "device key" (I think this is called an "endorsement key" in TPM world - see http://en.wikipedia.org/wiki/Trusted_Platform_Module ). The root private key (used to sign the endorsement keys) is definitely not present on any of the cards.

As I've described earlier, the plan is to raise an alarm when we detect a doublespend (meaning one of the cards was compromised). We also plan to have a CRL (http://en.wikipedia.org/wiki/Revocation_list) that we can use to mark a card as compromised.

Right now, the OtherCoin cards do not keep track of where they got the keys from (I mean they do verify the sender but they don't store it), but they could - they could create a chain of public keys indicating the previous owners of that Bitcoin private key (stored securely in the card, not released to the wallet). When the wallet detects an external spend for a key stored in its OtherCoin, it can essentially ask the card to release this chain and we can then blacklist all the cards in the chain (blacklisting would not mean locking them out of their funds, but forcing them to go through the blockchain for their transactions). Since we cannot tell exactly which card from the chain has been broken (but one definitely has been broken if we ended up with a key that has been spent externally), we blacklist them all.

I'm still reluctant to implement something like this since it would give quite a bit of power to the entity controlling the CRL - if implemented, each blacklist would have to be properly documented.

There is an alert mechanism already built into the system - basically, the wallet gets a list of the public keys that the OtherCoin card claims to have secure private keys for, then monitors the blockchain for any transactions involving those addresses. If funds ever move out of any of them, it triggers an alarm and then we know the security has been breached somehow since the private key is supposed to have not been released to anyone (the current user can actually prove it by showing the OtherCoin card with the private key inside, in its "secure/unreleased" status).


I'll look into the bonding idea as well, thank you!

What would happen to merchants that do not speak/use the payment protocol? If the Trezor is set to a "safe mode" and only accepts addresses that are verified using their associated X.509 certificates, it would be unable to pay merchants that do not use it. If you set it to a more compatible mode and accept both, the malware could simply strip the payment protocol and pretend the merchant doesn't support it and request that you pay using the plain old Bitcoin protocol.

But I guess users will ask the merchants to support the payment protocol in order to feel safe buying there.

Also, the plan is to eventually get more than 1 entity certifying/signing the device key - in order to keep everyone honest. For instance, one of the entities signing the cards could be the Bitcoin Foundation or one of the large mining organizations. We would also obviously share the sources with them (but that would have to happen under NDA given the strict requirements of our NDA with NXP - without that we wouldn't have access to hardware-accelerated crypto and everything would be painfully slow, plus that we would have to add SPA/DPA (http://en.wikipedia.org/wiki/Power_analysis) countermeasures ourselves).

My apologies, tamper-resistant is more accurate. The cards we plan to use are certified at the EAL 5+ level (http://en.wikipedia.org/wiki/Evaluation_Assurance_Level) which I understand to be fairly high - maybe not high enough for military apps but definitely designed to withstand casual hacking attempts.

Thank you!
Razvan

Hello everyone,

I've posted a message on the Project Development thread at https://bitcointalk.org/index.php?topic=319146.0 but it didn't get much attention, but there's a technical side to it that I'd like to submit to you and hopefully get some feedback.

To summarize, I'm in the process of developing a system called OtherCoin that allows anonymous off-chain payments by transferring private keys between tamper-proof smartcards. The private keys are either generated internally by the smartcard or received over an RSA-encrypted channel from a similar smartcard. The smartcard just certifies that any key it sends over the RSA-encrypted channel has never left the card in unencrypted form and has never been revealed to the wallet. The smartcard can reveal the private key to the wallet at any time - when it does that, it removes it from its secure storage, effectively making it a plain Bitcoin private key.

A short whitepaper is available at http://www.othercoin.com/OtherCoin.pdf . It explains more than I can do in a single post here.

The system has been designed to work in the absence of trust (you do not have to trust the smartcard, you always combine the public keys it generates with a second set generated by the wallet, so that the card has no idea what your actual Bitcoin public key / address is). And since it's a smartcard, it obviously can't communicate to the outside world by itself, so it cannot leak information. It never signs transactions, its purpose is to only generate private keys and store them securely, then either fully reveal them to the wallet or securely transfer them to the storage of a similar card.

I would appreciate some comments from the more crypto-knowledgeable developers here. I think it's currently the only off-chain payment system that does not rely on a central service/server - the issuer of the cards could go out of business and the system could continue to work indefinitely. And since transactions never touch the blockchain, they are invisible to the Bitcoin network (and your friends in law enforcement) - they are strictly point to point between the payer and the payee, no record is written in the blockchain or anywhere else.

Any ideas, comments and criticisms are welcome.

Thank you,
Razvan

This might have been answered before (if it has, I couldn't find it): can the Trezor help in the case of malware that simply modifies the destination Bitcoin address (for instance when you browse to an online shop, it silently changes the Bitcoin address that you're supposed to send funds to to one that it generates). The user then visually checks that the address displayed by the Trezor is the one that he sees on the website but he has no idea that the address belongs to the attacker.

I understand how the Trezor protects against malware trying to modify the address you're paying to by displaying it on the Trezor itself before signing, but I don't see how it can protect against the malware simply modifying the address shown on the web page. Also, given that receiving addresses are supposed to be one-shot, they will change on each payment so the user has no chance of whitelisting or visually recognizing the correct one.

A rogue Chrome extension for instance could just do a quick find/replace on the page (Bitcoin addresses are easily identifiable, not many words start with 1 and are 27-34 characters long ) and change all Bitcoin addresses to the ones of the attacker. If anyone is interested, I could probably write one as a proof of concept.

Any ideas?

Hi everyone,

I would like to introduce a project that I've been working on for the past 3 months or so. It's called OtherCoin and it is an off-chain Bitcoin payment system based on a microSD card with a tamperproof smartcard in it, inserted into a phone or a computer. It works by securely generating and storing Bitcoin private keys inside its tamperproof chip and only releasing the public key to the wallet. It is also able to establish an encrypted and authenticated connection to a similar OtherCoin smartcard and transfer one or more of the Bitcoin private keys it stores to that card.

To my knowledge, it is the first off-chain Bitcoin payment system that does not require an Internet server. Even if the issuer of the cards goes out of business or the server is hacked or taken offline, the system keeps working because all transactions are strictly between two OtherCoin smartcards that authenticate each other and certify that the transferred Bitcoin private keys have either been generated inside the tamperproof chip or have been received securely from a similar tamperproof chip. The system is fully anonymous and also offers zero-confirmation transactions.

Mike Hearn has pointed out that the protocol it uses is somewhat similar to the one MintChip uses (http://en.wikipedia.org/wiki/MintChip). They have the same "smartcard to smartcard" connection and the same form factor (microSD) but their chip signs messages indicating the value of the transfer while OtherCoin transfers Bitcoin private keys to transfer value.

I have uploaded a short presentation at http://www.othercoin.com/OtherCoin.pdf .

The project is approximately 70% done (most of the smartcard code is done but there is still work to be done on the software wallet side that runs on the smartphone).

Any feedback would be greatly appreciated at this point. Would you use this? Is there anything you'd like to see implemented?

Thank you,
Razvan

The only issue is that the merchant will almost certainly want to convert the Bitcoin to fiat - so you're just moving the problem. The buyer feels good because he's paid in Bitcoins, but now the merchant has to convert the Bitcoins back to fiat or risk the exchange rate going down (and lose considerably more than the Visa/Mastercard credit card processing fees). That will only change once the merchants can pay some (or all) of their suppliers in Bitcoin as well - something I don't see happening very soon.

Well, you won't be using it to film your next Oscar-winning motion picture, 0.3M is good enough to read the QR code from the screen of the laptop and that's all you want it to do. That's why we suggest a cheap dedicated tablet for this and not your everyday tablet or smartphone - it's tempting to start adding stuff ("it can't hurt to have Angry Birds on your wallet, can it?") if the hardware is more capable. But if all it can do is be a wallet, we hope people will stick to that.

We are working though on a smartcard-enabled version that will move the key generation and signature to the smartcard, allowing you to use it in a regular Internet-connected smartphone (with some "secret sauce" to allow the smartcard to talk back to directly to you and make sure that your phone is not full of malware and asking it to sign 1000 BTC transactions to some random address).

http://www.storageoptions.com/products/scroll/tablets/scroll-pocket - go to the Specifications tab. Backside is here: http://static.scan.co.uk/images/products/1977867-d.jpg