I don't know how Firmcoins exactly works but I think there is a potential problem.
As you said, Firmcoin can export the private key to a smartphone through NFC. Is the following attack possible?
1. The phone requests the private key through NFC
2. Firmcoin sends the key through NFC
3. The phone receives the key but does not response
4. Firmcoin is not sure whether the key has been successfully sent, and does not delete the key. (If Firmcoin deletes they key without confirmation from the phone, the key may be lost if there is communication error)
Possible solution: the Firmcoin will always send a warning to the user if it had any unsuccessful key export attempt.
The firmcoin BEFORE sending the private key enters a special internal state "no-funds". The private key is NOT immediately wiped. You can query the device for the private key as many times as you want until you're satisfied the transmission has no errors. Then you send the firmcoin a command "wipe" and the firmcoin will wipe the private key. The firmcoin will never go back to the state "funded" after the state "no-funds" without going through the state "create-new-key". Sergio. |
|
|
|
Also in a firmcoin there are two methods to reload coins:
1. You send the the pubkey to a Firmcoin server, and he server returns you a signed message that your Firmcoin verifies to and enters the "funded" state.
Why do you involve a firmcoin server? Does that mean a firmcoin server retains the technical authority to falsely trigger a firmcoin to think its loaded? Good point. But it doesn't work like that. Anyone can load a certificate to the firmcoin tho prove the coins are valid, and the firmcoin will gladly accept it. The coin can have (currently) up to 8 user provided certificates. So if you don't trust the manufacturer, you can reject a coin that has only the certification of the manufacturer. Maybe The Bitcoin Foundation in the future can be generating its own certificates to put into the firmcoins. Anyway, why we are providing the method 2, that is exactly what you say in your post. The firmcoin tells you which method was used to load the coins. edit: I guess you're concerned that proper validation is too expensive for the coin,
Yes, it requires much computation, but the nice fact is that it can be done incrementally with little memory. |
|
|
|
Awesome project!
So if I understand correctly, the NFC interface lets you both retrieve the public key and the atomically-destroyed private key?
It let's you retrieve both keys and atomically change the state of the firmcoin to "empty". Are you going to integrate this with the Android wallet app? It already has some NFC support and syncs with the network every 24 hours.
It would an interesting feature, I will think about it. But we're not ready to manufacture in high volumes. However, I must admit I am not entirely sure of the purpose. If you accept a firmcoin without checking it with your smart phone, it might be empty, so that's dangerous. And if you have a working smartphone, you could just as well do a direct P2P payment. I suppose the difference is, the payer doesn't have to have a phone, just the receiver. But is that really an advantage?
For a first security level, none of them have to be online. If you trust the manufacturer (us) then you can trust a firmcoin has coins. You query the firmcoin with a NFC-enabled smartphone and it will tell you if it has coins or not. Another version we're building has a LED that flashes when it has coins when you touch it. And you don't even need to trust us: we've done things so that you have to trust only "ST Electronics" (at least now). For a higher security level, you can carry with you the UXTO set of the day before (and update them once each day). A firmcoin will only respond that it has funds if the transactions that fund the firmcoin are at least one day old. For a higher security level, you can photograph the firmcoin and check its random features against a small database of physical features you can download from our servers. For more security you can even query the firmcoin to prove it has a private key related to a certain public key (without the firmcoin disclosing the private key). For even more security you can access our database online which can track which addresses are associated with each firmcoin. For even more security you can upload the photographs of the device and we'll check the authenticity of the firmcoin against high definition images taken during the manufacturing process. For even more security you can just extract the private key, transfer the funds using any Bitcoin client, and then send new funds to the firmcoin. This is (IMHO) the future of off-line anonymous transactions (bills and coins), Best regards, Sergio. |
|
|
|
|
Also in a firmcoin there are two methods to reload coins:
1. You send the the pubkey to a Firmcoin server, and he server returns you a signed message that your Firmcoin verifies to and enters the "funded" state.
2. You provide the firmcoin with a block-chain branch of at least 144 blocks with the current difficulty, where the first block contains a transaction that funds the firmcoin, along with the merkle tree. If each block reward is 12 BTC, when you can fund upto N*12/2 BTC, where N is the size of the supplied chain, an N is at least 144. This can be done privately, and anonymously.
None of this methods has any security problem: if you receive a firmcoin, it's either authentic or not authentic (you check by eye inspection, and some other methods).
If it's authentic, either it has funded coins or it does not, and you can query the device for this information.
Sergio.
|
|
|
|
Your use of x=yx' (y chosen by user) makes more sense in that context also, as then attacker cant mark coin public keys for transfers to coins (which will appear on the block chain).
btw As you have a funded state on the coin, and passive accumulated stray RF power possibility you could flash a light on button push to indicate green or red status even.
Passive displays are very expensive. I found that the smallest eInk display costs 8 USD. And a capacitor with a LED will hold the status not long enough. A solar cell may work, but still they are expensive. I want the firmcoin to be under 3 USD.
Any thoughts about suggestion to make the private key recoverable by combination of users retained (but not block chain published) y values (or other new value) and manufacturer on receipt of broken hardware? May make it more attractive for bigger balances - otherwise I can see people being scared to put bigger amounts on it in case of hardware failure. As is I could take the value off the card (empty state) for safe storage/backup/paper-wallet, but as soon as I reload the coin it chooses a new private key that I dont know, and cant easily know without resetting it back to empty state.
One possibility is that when the firmcoin generates a key pair X, and you generate another key pair Y. You print the keypair Y in a QR code and stick QR code in the firmcoin. To load funds, you load them to a 2-2 multisig (a transaction that requires both private keys to sign the input). The the firmcoin cannot by himself do anything to steal the coins, even leaking its private key is useless. The worst thing it can do is just stop working (which will make you loose your coins, but the attacker gains nothing). The person who stamped the QR code must collude with the hardware manufacturer in order to create a firmcoin that can leak usefull information to stole the coins. So if you stamp the QR code yourself, then the fircoin manufacturer still cannot steal your coins. |
|
|
|
|
Anyway, if you ask the firmcoin to sign a transaction, then it doesn't matter if it leaks all the private key, probably your transaction will get into a block before the attacker extracts the private-key, and creates his own competing transaction, which will be regarded as a double-spend attempt.
|
|
|
|
However it seems that the same people want the coin to be online spendable (emptyable) and reloadable. Those objectives seem in conflict as any non-technical guy can follow the online spendable procedure, and end up with a coin that within protocol has no bitcoins in it! So then you see the defense that the coin is somewhat offline verifiable in that it reports itself over local hardware link (eg NFC in case of firmcoin) as empty. (eg it deletes its private key when spent). Maybe to the limited extent of the tamper resistance, tamper evidence, an holograms etc that some people may want to trust that, we could have both objectives in one coin (moderately safe for offline transfer AND new owner chooses part of the key). And Sergio Lerner said something like this: What I actually do is to create the private-key in the hardware, then the hardware tell the user the public key. Then the user provides a user-chosen random multiplication factor to the hardware and then the hardware multiplies both the private and the public key.
Then the hardware manufacturer cannot know the private key.
So that means device computes P1=x'G, then user chooses y such that P=x'P1=x'yG so the final key is x=x'y mod n. So while its true that the device didnt chose all of the private key bits, it still knows the full private key, could leak it over NFC, or more subtly send it in k when making the ECDSA signature via the big fat 256-bit DSA subliminal channel, so the user or manufacturer or criminal buyer of hostile hardware can later harvest coins from the signatures published to the network by examining the signatures. Because I knew about side channel attacks, I preferred that the firmcoin do not sign anything that goes out to the Internet. The firmware jusr gives you the private key whenever you want, but at the same time it enters a special "empty" state, where it no longer advertises as a funded device. Also I like the idea that you have to give the physical device to the other party, because if you have manufactured a counterfeit device, then you´re giving the proof of your criminal act to the other party, so the other party could go legally against you. Also the day a counterfeit device appears on the market, from that day on the firmcoins will no longer be able to be verified off-line, but that doesn´t mean they are useless. They still can be extracted their private keys. They can be reloaded and uses as BTC storage. So the incentive to an attacker is very low: he can just steal some very few BTC until everybody knows there are counterfeit devices in the market. Who will invest in manufacturing a special chip for such a crappy attack? Best regards, Sergio. |
|
|
|
|
And if a chip manufacturer is caught making counterfeit chips, then it will have a huge legal problem.
|
|
|
|
You can prove that you have a certain private key by simply signing an arbitrary message with it (but the message to be signed must be chosen such as neither of the parties can force it).
Yes but you cant prove the key was generated in a way not computable by the hardware manufacturer. I was thinking it would be safer to have the key chosen by the software system under the currrent owners control (the person loading the coins). (Or maybe verifiably half the private key bits by the owner and half by hardware). In that way the hardware does not actually have to be trusted. Also if the hardware fails you dont lose the coins (you could back them up). What I actually do is to create the private-key in the hardware, then the hardware tell the user the public key. Then the user provides a user-chosen random multiplication factor to the hardware and then the hardware multiplies both the private and the public key. Then the hardware manufacturer cannot know the private key. This is not new and some other people have posted about similar methods (like adding two keys). I've also added a new method to verify the FIRMWARE authenticity by using "practically incompressible" firmware. And challenging the firmcoin to dump the firmware in a very short time.
Its probably fine for modest value but in principle it seems that the manufacturer you use could make another coin with a different bigger firmware that contains both a standard firmware for responses and a hostile firmware for generating trap-door predictable private keys (eg) Adam The idea is not bullet-proof. But you can inspect the hardware and check that the chips are the ones with the right amount of memory. If I use a chip from a manufacturer with the highest amount of memory, then you know I cannot add more, without adding additional chips. That's why I think firmcoins work best for low valued denominations. Sergio. |
|
|
|
Now all we need is a kick starter for someone with a bit of hardware expertise to put an unpowered 1kB contact readable serial readable flash drive inside a coin  Maybe you could have a coin hold a standard usb drive, just pull it in half and plug it in even easier to read. Unfortunately smart phones dont have usb readers. This is what I did: check the new thread: https://bitcointalk.org/index.php?topic=232898.0You can prove that you have a certain private key by simply signing an arbitrary message with it (but the message to be signed must be chosen such as neither of the parties can force it). I've also added a new method to verify the FIRMWARE authenticity by using "practically incompressible" firmware. And challenging the firmcoin to dump the firmware in a very short time. You can check how this protocol work in : http://firmcoin.com/?page_id=14And also the firmcoin is rechargeable. You can store some funds, extract them, and store additional funds (the device generates a new private key address each time you load funds, using a hardware random number generator). Best regards, Sergio. |
|
|
|
Hi everybody!  I'd like to present my latest innovative hardware project. It's called Firmcoin. Check http://FirmCoin.comIt's like cheap eWallet. But it's so cheap that, in order to pay with Bitcoins, you can actually give the Firmcoin to the payee. And it's rechargeable! Currently you can verify the authenticity of a Firmcoin with any NFC-enabled smartphone (that can run our software). When requested, a Firmcoin will send you its Bitcoin private key, but will automatically and atomically wipe the private key from memory, preventing double-spends. There are several ways to verify the authenticity of a Firmcoin. For low value payments, you can just query the device if it has funds or not. Also the device can cryptographically prove that it is holding a certain private key, by signing user provided messages (but not transactions!) If you want to verify the authenticity of a Firmcoin with more confidence, you must have connected to the Bitcoin network in the last 24 hours in order to download the list of Firmcoin addresses with funds. The Firmcoin can only receive funds if the transactions that load the funds are 24 hours old. Carrying this small database, you can check the full validity of a Firmcoin without being online! Also you can download a physical description of random features of each manufactured token and check its physical authenticity by just taking a photo of the Firmcoin. Last but not least, we have a novel method to verify the authenticity of the firmware loaded. And we hope we can sell each Firmcoin for less than 5 USD when we start manufacturing in higher volumes. Keep in mind that we're still developing the product to make it ready for mass production, so we're open to any ideas you may want to share with us. Also if you have the skills to help us develop a better product, we'd be glad to hire you in our team, or partner with you. Best regards, Sergio. Part of the Firmcoin team. (please note the image is not the actual prototype, it is photoshoped). |
|
|
|
From the post: "But again, the core developers think it’s not worth implementing this fix."
Do you believe that the core developers just do not want to implement the two changes you suggest? Or would they block someone else making those changes and incorporating them?
I think that if someone implements them, they may apply the patches. The decision not to implement them right away may be to a lack of resources to research and implement the patches. |
|
|
|
Thank you all for your help. I found that on github you can access any old release by tag (instead of by branch) For example, here https://github.com/bitcoin/bitcoin/tree/v0.4.0 you can browse the 0.4.0 branch. Best regards, Sergio. |
|
|
|
So, Sergio, still on your Quest for Satoshi TM?  No, this is for other purposes. I want to see when something was patched and by who. |
|
|
|
Did you check github?
I cannot see anything there before Apr 23, 2011 |
|
|
|
|
The source codes of the Satoshi Client prior 0.3.24 have been removed from the sourceforge repository. I don't know why.
Do any of you have the source codes of client versions prior 0.3.24 ?
The only previous version I have is 0.1.
I would appreciate it a lot.
Best regards,
Sergio.
|
|
|
|
I'd start designing the SHA-3 ASIC miner right now.... Seriously, keep in mind that even if SHA-2 is broken because of collisions found, this does not pose any risk to mining. And even if pre-image attacks were found, it does not pose any risk to mining either, because SHA-256 is applied twice. So we could in theory still use SHA-256 for 50 years without problem because of classical cryptanalysis. The ONLY problem is quantum computing. |
|
|
|
|
Show Posts
