Bitcoin irrevocability & fungibility is cool and one of the main benefits of bitcoin. However the cost is stealing them constitutes the perfect virtual crime, and so the level of APT attacks will surely rise to new proportions against both user machines, and bitcoin processors.
Now one step towards making bitcoins hard to steal is offline wallets (armory & trezor) where the remaining remote threat is almost removed (subject to very few lines of code in usb drivers and the attack vector of the protocoin sent to the offline device for verification and signing). Given the stake the lines of critical code can be minimized and audited. This is robust starting point.
However the remaining issue is, while you can receive bitcoins securely over an air-gap, and pay from an offline wallet using usb or QR code, your ability to securely communicate addresses for receipt via the users online computer is questionable. Targeted bitcoin malware can win this race (show you what you want to see, but send a different address to the sender via local SSL backdoor, app patches, OS patches etc).
Similarly security of the online payment processor's environment is in question. They can use host security experts, best practices etc. But still there is the 0-day and the APT attack, but surely it will escalate to a new level. And the payment processor despite hot-wallet / cold-wallet trade-offs is an increasingly valuable target. Malware on the payment processor can send users the attackers address for "deposit". It can steal the hot-wallet. It can replace users "withdraw" addresses. They'll notice but it maybe too late.
The payment protocol
https://en.bitcoin.it/wiki/BIP_0070 helps, however that has to be part of the online merchant app because its not just signing the merchant invoice address, its signing the transaction details also. Likely it will be signed by the SSL web site, though it could be signed with a separate sub-domain. Lack of a hard requirement for this to be the case makes that assurance weak - an attacker who gains control of the merchant site can sign with the SSL cert key and users wont consider anything amiss.
Also even without breaking into the merchant, SSL certs can and have been hacked, and absent cert pinning, the entire system is as weak as the weakest CA.
So what could we do about this.
We need to rearchitect for the bitcoin offline wallet security model. Its fine for the web app layer to best-effort sign the transaction, if one values it for what it is - an assertion by an at risk web app with at risk keys. (Hardware security modules dont help that much, the app layer still obtains no-restriction signatures from the HSM).
So one more thing that could be done is to use hierarchical deterministic wallets to make a sub-wallet with a shared chain code between the user and the merchant. For repeat custom or a bitcoin exchange this could make sense. Then if both the merchant and user keep the chain code off the online machine they can at least be assured that the address is unique to them. Use out of band security to set this up. Or use TOFU (trust on first use) so that both sides abort of something changes about the security context.
Secondly it seems to me we could do with something end to end authenticated between the sender and the receiver. Signed addresses?
Then the sender and the receiver dont need a secret (shared chain code of sub-wallet), they only need an authenticated signing address from the respective online wallet.
Maybe you derive identity assertion keys deterministically from the offline wallet, derived from the receiving parties identity (domain name, email address etc). And send those to the receiving party during setup, or use out of band for one off.
Privacy, fungibility? The signatures are not part of the bitcoin transaction, they are just to convince the relying party. They are not receipts like payment request ack messages, they just show you that the person you expect is the owner of the address with offline hardware assurance.
Because the addresses are not user specific the merchant can upload batches of them from the offline computer.
Could you use abuse the payment request protocol to encapsulate a second signature on an address? Probably but that seems like a protocol layering violation to me. Payment protocol is an app level protocol, authenticated addresses are simple, have no external references and gives a stable public handle to authorize. The hash of chain code of a sub-wallet could do something similar.
In terms of concepts and terminology you could consider the signing address (that signs the one-use addresses) to be an account number. And the one-use addresses as transaction or invoice numbers that are signed to prove they are owned by the account number. You can use a different signing address for each recipient to add privacy. Or a different signing address for each time if its not an identified ongoing relationship.
You can wrap these signing addresses with X509, PGP, SSL, phone call to check, offline address signing key fingerprint on company business cards etc.
Adam
