[IDEA] Keyed RFID

[cbeast]

I'm trying to think of low tech solutions for Bitcoin wallets in poor countries. Would it be possible to create an RFID keypair where the private key is disassembled and reassembled by inserting a key into the device and twisting it into position? It would have no electronic components and would be cheap to mass produce. It would of course be shielded for unidirectional operation to avoid remote scanning.

edit: This is only one part of a bigger POS system that could be implemented in poor countries.

[1714172020]

1714172020

[1714172020]

1714172020

[1714172020]

1714172020

[1714172020]

1714172020

[1714172020]

1714172020

[cypherblock]

I'm trying to think of low tech solutions for Bitcoin wallets in poor countries. Would it be possible to create an RFID keypair where the private key is disassembled and reassembled by inserting a key into the device and twisting it into position? It would have no electronic components and would be cheap to mass produce. It would of course be shielded for unidirectional operation to avoid remote scanning.

edit: This is only one part of a bigger POS system that could be implemented in poor countries.

Sort of a cool idea. But how does it work exactly? You carry a physical key instead of a wallet app on a smartphone? Or describe more what you have in mind. What "device" do you insert the key into?

[cbeast]

I'm trying to think of low tech solutions for Bitcoin wallets in poor countries. Would it be possible to create an RFID keypair where the private key is disassembled and reassembled by inserting a key into the device and twisting it into position? It would have no electronic components and would be cheap to mass produce. It would of course be shielded for unidirectional operation to avoid remote scanning.

edit: This is only one part of a bigger POS system that could be implemented in poor countries.

Sort of a cool idea. But how does it work exactly? You carry a physical key instead of a wallet app on a smartphone? Or describe more what you have in mind. What "device" do you insert the key into?

This would be a device that has an RFID representing a Bitcoin private address. The public address can be printed on the outside. The RFID tag circuit is broken until you put in a physical key to complete the circuit. You would do this at a trusted vendor's point of sales. Insert the device into a reader and turn the key. The vendor device would sweep the amount with an RFID reader, return your change to your public address, snap the device back into its locked position, and give you a receipt.

[cypherblock]

This would be a device that has an RFID representing a Bitcoin private address. The public address can be printed on the outside. The RFID tag circuit is broken until you put in a physical key to complete the circuit. You would do this at a trusted vendor's point of sales. Insert the device into a reader and turn the key. The vendor device would sweep the amount with an RFID reader, return your change to your public address, snap the device back into its locked position, and give you a receipt.

Hmm, well, not sure I totally get it, but it might tie into some concepts I've been working on (see my post on 'a smoother brick and mortar experience'). Trying hard to make sense of what you wrote, but too many things to interpret. You'll have to explain it better. What is your goal? How does the merchant get this device that matches my key?

My best guess:

• There is only one store in town
• I drop off my 'device' at this store at some point
• Later I return to the store and want to buy some stuff.
• At the checkout the merchant pulls my device off the shelf and I insert my key
• Their pos system now finds unspent transaction outputs on the blockchain matching my public address and creates a transaction using those transactions as inputs and as outputs specifies their public address for payment and my public address for the change.
• Their pos system then sends this transaction into my device which, after I confirm the amounts on some screen (so that I know they are not taking too much), then digitally signs the transaction (provides the scriptSig) using my private key (but without revealing my private key to the merchant system)
• Merchant pos system then sends this transaction off the bitcoin network.

Have I guessed correctly? If so the main advantages are: I can only spend bitcoins at this one store (because they have my device), so if my private physical key gets stolen, then the robber would either have to also steal my device from the merchant or impersonate me (which could be hard in a small town).

[cbeast]

This would be a device that has an RFID representing a Bitcoin private address. The public address can be printed on the outside. The RFID tag circuit is broken until you put in a physical key to complete the circuit. You would do this at a trusted vendor's point of sales. Insert the device into a reader and turn the key. The vendor device would sweep the amount with an RFID reader, return your change to your public address, snap the device back into its locked position, and give you a receipt.

Hmm, well, not sure I totally get it, but it might tie into some concepts I've been working on (see my post on 'a smoother brick and mortar experience'). Trying hard to make sense of what you wrote, but too many things to interpret. You'll have to explain it better. What is your goal? How does the merchant get this device that matches my key?

My best guess:

• There is only one store in town
• I drop off my 'device' at this store at some point
• Later I return to the store and want to buy some stuff.
• At the checkout the merchant pulls my device off the shelf and I insert my key
• Their pos system now finds unspent transaction outputs on the blockchain matching my public address and creates a transaction using those transactions as inputs and as outputs specifies their public address for payment and my public address for the change.
• Their pos system then sends this transaction into my device which, after I confirm the amounts on some screen (so that I know they are not taking too much), then digitally signs the transaction (provides the scriptSig) using my private key (but without revealing my private key to the merchant system)
• Merchant pos system then sends this transaction off the bitcoin network.

Have I guessed correctly? If so the main advantages are: I can only spend bitcoins at this one store (because they have my device), so if my private physical key gets stolen, then the robber would either have to also steal my device from the merchant or impersonate me (which could be hard in a small town).

The wallet device never leaves the hand of the owner. This isn't a Trezor type device that 'signs' transactions. This is a poor man's secure physical wallet. It is only used to carry the day's cash. It also requires trust that the vendor will not take all of your outputs and keep them. They will only sweep what is needed to settle the transaction and return the change as new outputs back to the public address or to a new address if the user has a deluxe model. Here is an example to illustrate the idea with paper wallets. Only this time cheap RFID tags can be printed with standard printers and conductive inks.

First, here is the problem that led me to this. Most poor people cannot afford smart phones or even cell phones for that matter. How do I come up with a very very cheap, but very very secure wallet for them? Paper wallets are really only good for cold storage. RFID tags are very cheap to make. The problem with RFID is that they can be scanned remotely. If one is used for a Bitcoin private address, it could easily be stolen. The one weird trick is to scramble the RFID tag and reassemble it when it is ready to be read. As long as the RFID tag is not a complete circuit, it cannot be read surreptitiously. The wallet can be preloaded with multiple RFID keypairs or if it only used for very small amounts of money, then one should suffice. No legitimate vendor equipped with a POS system will bother stealing such a small amount.

[DeathAndTaxes]

What is the advantage of this over a concept like sigsafe (NFC & microprocessor combo signs tx it receives from POS).

[cbeast]

What is the advantage of this over a concept like sigsafe (NFC & microprocessor combo signs tx it receives from POS).

Cost? An RFID has almost no cost and can be printed on a laser printer TTBOMK. The device could be made on a simple 3D printer. I'm talking about a solution for the <$10 a day people which is most of the world's population.

[Peter R]

What is the advantage of this over a concept like sigsafe (NFC & microprocessor combo signs tx it receives from POS).

Cost? An RFID has almost no cost and can be printed on a laser printer TTBOMK. The device could be made on a simple 3D printer. I'm talking about a solution for the <$10 a day people which is most of the world's population.

The most common RFIDs nowadays are probably the 13.56 MHz ISO14443-based tags, with prices below a dollar.  An RFID is actually a complex electronic device.  Check out the transmission protocol specification for ISO14443: http://www.waazaa.org/download/fcd-14443-4.pdf.  There's a little computer in those cheap RFIDs!

The nice thing about ISO14443 is that it is the standard upon which NFC is based, and is used by most new RFID designs.  An ISO14443-compliant RFID can be read by an Android smart phone, by a NFC point-of-sales terminal, or by a generic RFID reader.  

I think the cheapest solution would be to port the sigsafe concept to something like a JavaCard.  But based on my initial research, I do not believe these smart cards have sufficient resources to quickly parse bitcoin transactions and perform ECDSA operations.  However, I could be wrong--they are definitely close and perhaps it is worth a more thorough investigation.      

But the sigsafe is ISO14443 compliant and will also be extremely low-cost in high volumes.  In quantities measured in hundreds of thousands, it should not be a problem to create a cost-reduced sigsafe (no battery) with a price well below $10.  In quantities in the millions, I don't see why you couldn't create a smartcard similar to JavaCard with exactly the right resources for bitcoin transaction parsing and ECDSA sign/verify operations and get your price below $5.  

[cypherblock]

The wallet device never leaves the hand of the owner. This isn't a Trezor type device that 'signs' transactions. This is a poor man's secure physical wallet. It is only used to carry the day's cash. It also requires trust that the vendor will not take all of your outputs and keep them. They will only sweep what is needed to settle the transaction and return the change as new outputs back to the public address or to a new address if the user has a deluxe model. Here is an example to illustrate the idea with paper wallets. Only this time cheap RFID tags can be printed with standard printers and conductive inks.

Is this really different than 1 single paper wallet public/private key (aside from not being paper)?  When assembled it let's someone read both a public and private key, and that is all. So exactly like a paper wallet. Right? I guess it has some advantage if I can keep one part of it (key?) on my body and the other part (device) at home if I'm not planning on spending money that day. So like cutting a paper wallet in half or something. But if I have both parts on me, then it has no security at all if someone gets a hold of it, except that they would need the merchant reading device. So I guess that is some protection if those are hard to come by. But they can still show up at the merchant and spend all my money.

You mentioned maybe a deluxe model would let the merchant send the change to a new public address. So that works better, but there would have to be some protection so that the merchant couldn't scan all the public/private key pairs on the device when assembled. How would you prevent that?

In your other post https://bitcointalk.org/index.php?topic=74978.msg831067#msg831067 the printed checkbook approach at least prevents the merchant from performing additional transactions without your knowledge since the change is sent to a new public key and he doesn't have the private key for that. So that works much better IMO.

[btchip]

I think the cheapest solution would be to port the sigsafe concept to something like a JavaCard.  But based on my initial research, I do not believe these smart cards have sufficient resources to quickly parse bitcoin transactions and perform ECDSA operations.  However, I could be wrong--they are definitely close and perhaps it is worth a more thorough investigation.      

You could be interested to have a look at the port of our old wallet : https://github.com/btchip/btchipJC

depending how quick you want quick, it runs quite well on a recent JCOP, with time mostly wasted on features you won't need (RIPEMD160, base58 encoding)

[cbeast]

Since people have other ideas instead of commenting on mine, I will challenge folks to create a highly secure free physical wallet that can be given away at events by the millions. Basically, something fabricated in plastic with no electronic components that require expensive clean room equipment. The generation of the addresses must also be secured for each individual user. It must also be easy to use and secure for a simple POS system. It must be easy enough for a child to use.

Otherwise, we will never replace paper money.

[Peter R]

Since people have other ideas instead of commenting on mine, I will challenge folks to create a highly secure free physical wallet that can be given away at events by the millions. Basically, something fabricated in plastic with no electronic components that require expensive clean room equipment. The generation of the addresses must also be secured for each individual user. It must also be easy to use and secure for a simple POS system. It must be easy enough for a child to use.

Otherwise, we will never replace paper money.

Aren't you wondering what the cheapest way to implement secure bitcoin payments in the third-world is?  

What is wrong with a smartcard-based device such as Btchip's HW-1 wallet or like the sigsafe ECDSA signing tag?  The cost of either of these devices could be reduced certainly below $10 and very likely below $5 (or lower) with sufficient volume.

And isn't it better to create a device that can be read by hardware that already exists out in the field, rather than some new custom reader that your proposal seems to require?  This way vendors in the third-world can use equipment they already have (they just need new software).  I see this as a significant advantage of a USB solution (HW-1) or an ISO14443/RFID solution (sigsafe).  

How could you further reduce cost or simplify functionality?

[Peter R]

I think the cheapest solution would be to port the sigsafe concept to something like a JavaCard.  But based on my initial research, I do not believe these smart cards have sufficient resources to quickly parse bitcoin transactions and perform ECDSA operations.  However, I could be wrong--they are definitely close and perhaps it is worth a more thorough investigation.      

You could be interested to have a look at the port of our old wallet : https://github.com/btchip/btchipJC

depending how quick you want quick, it runs quite well on a recent JCOP, with time mostly wasted on features you won't need (RIPEMD160, base58 encoding)

Thanks for the link, Btchip!  You guys have done some nice work documenting the smart card application protocol data units (APDUs) for the HW-1 USB wallet.  The sigsafe tag emulates a smartcard using the same APDU format.  However, our commands are of course incompatible!  It would be nice to create a standard, open format for the "Bitcoin APDUs."  This way, hardware manufacturers for bitcoin wallets, signing tags, and point-of-sales terminals can design to a common standard.  

Perhaps we could continue this discussion by PM.  In the meantime, here's the link to the sigsafe white paper if you are interested: http://sigsafe.org/sigsafe.pdf

BTW: how much RAM do the JavaCards you're using contain, and at what clock rate can you run the CPU at?

ans. 6.2 kbytes on the ST23YT66 smartcard MCU according to the project Development thread for BTChip's smartcard: https://bitcointalk.org/index.php?topic=134999.0