[Proposal] Physically Uncloneable Function (PUF) registery

[indolering]

This will likely remain a proposal for a while due to how behind I am in getting Speech.is running, but I put up a draft spec on the wiki and I have a long blog-post explaining how we could leverage Namecoin to create counterfeit-proof physical Bitcoins.

[domob]

That's very interesting! However, I'm not completely sure that I fully understand your proposal for physical coins. Let me reiterate your proposal in my own words: You create a PUF, for instance an NFC chip with a random private key embedded that can not be extracted from it and when breaking the chip, the private key is lost forever. Then you create a physical coin which uses this NFC chip instead of the usual holograms, such that one has to break it (and thus destroy forever the private key) in order to access the Bitcoin address' private key.

Here's where Namecoin comes in: You store the public key to the key on the NFC chip in the blockchain, associated to the coin's Bitcoin address. Thus if you offer me a coin, I can see its public Bitcoin address, look up the matching NFC chip public key, and ask the chip to prove to me it really owns the corresponding private key. If this is successful, I can be assured that there's indeed the original NFC chip still in place, and thus no one tampered with the coin.

Is my understanding correct? In that case, I think we could use one of the following two ways to actually record things in the blockchain:

• Create a name based on the public Bitcoin address, whose value holds the NFC chip's public key, and also is signed by the Namecoin identity of Casascius, for instance (some trusted issuer of coins). That way, one can immediately look up the public key for the coin in question and verify it with just the blockchain. One also doesn't even need a list of all Casascius coin addresses in order to verify that it was indeed issued by him, that's what his ID-signature is for.
• Create a list of NFC public keys and Bitcoin addresses, store it somewhere on a server, hash it, and just put the hash into a name that could even be human-readable (like "puf/casascius2013"). Then one needs to download the list somewhere in order to verify a coin (your point with updating offline devices before issuing a batch), but anyone who knows that a particular batch was issued with a given name ("casascius2013" in this case) could veriy that a list they got somewhere is indeed the official one of the real issuer (who holds the name's private key).

What do you think about those two ideas? I've not fully read through your proposal, but it seems as if it is more or less the first item above. I also believe that the second could be interesting, because it validates coins against a human-readable "batch name" and also because it doesn't bloat the blockchain too much.

[virtual_master]

How to make non-counterfeit able physical coins is already solved since thousands of years.
You make it of gold or silver.

[indolering]

You create a PUF, for instance an NFC chip with a random private key embedded that can not be extracted from it and when breaking the chip, the private key is lost forever....

Here's where Namecoin comes in: You store the public key to the key on the NFC chip in the blockchain, associated to the coin's Bitcoin address. Thus if you offer me a coin, I can see its public Bitcoin address, look up the matching NFC chip public key, and ask the chip to prove to me it really owns the corresponding private key. If this is successful, I can be assured that there's indeed the original NFC chip still in place, and thus no one tampered with the coin.

Mostly, the NFC is just a physical one-way function, no need for a private key. You can create an NFC or Bluetooth or contact based challenge-response chip to verify that the coin contains the correct and still readable private key. But the net-result is the same.

• Create a name based on the public Bitcoin address, whose value holds the NFC chip's public key, and also is signed by the Namecoin identity of Casascius, for instance (some trusted issuer of coins). That way, one can immediately look up the public key for the coin in question and verify it with just the blockchain. One also doesn't even need a list of all Casascius coin addresses in order to verify that it was indeed issued by him, that's what his ID-signature is for.
• Create a list of NFC public keys and Bitcoin addresses, store it somewhere on a server, hash it, and just put the hash into a name that could even be human-readable (like "puf/casascius2013"). Then one needs to download the list somewhere in order to verify a coin (your point with updating offline devices before issuing a batch), but anyone who knows that a particular batch was issued with a given name ("casascius2013" in this case) could veriy that a list they got somewhere is indeed the official one of the real issuer (who holds the name's private key).

What do you think about those two ideas? I've not fully read through your proposal, but it seems as if it is more or less the first item above. I also believe that the second could be interesting, because it validates coins against a human-readable "batch name" and also because it doesn't bloat the blockchain too much.

I like them, I hadn't thought of this in a vendor-centric manner. I threw in the human readable part as something of an afterthought as scanning a coin will require a machine, at which point the address can be the PUF hash itself, no need for a human to perform the lookup.

However, it would be much easier for the manufacturers if they had some control over the address space. Even if someone did compromise the PUF they would also have to compromise the vendors key as well. And if someone could get the manufacturers private key, then they could get the private keys they are embedding in the coins, so relying on the manufacturer's private key as the authentication component should help things.