Abstract:Design an authentication system that uses the blockchain as a revocation "list" (for say, software signing keys). By doing this, you can add extra conditions for a revocation to be considered valid, such as requiring a large payment to the person or company that controls the original key. The payment is "free" for the authorized individuals, but not anyone else.
Situation:You are an individual or organization with some kind of signing key or certificate that is used for Important Things (such as signing Armory installers). You'd like a way to permanently revoke the key/cert if it is compromised or lost, to prevent users from trusting it anymore. And you'd like the revocation to be timestamped so that users can still trust messages signed before that time.
Since you are also protecting yourself from simply losing the key/cert, just like in GPG, you may pre-sign a revocation cert, and keep it in a secure place until it is needed one day. The problem with revocation is that it relies on permanency -- you can't unrevoke a key. It is revoked one time and permanently updated in all key servers, etc. So it would be great if you were the only one who had that power.
But you can't keep it too secure, because it needs to be available quickly in case it's needed -- for instance, you find evidence that the signing key was compromised, and want to revoke it before the attacker can sign and distribute malicious versions of your software. If it's kept in a safe deposit box, and it's Saturday, you may have to wait two days to revoke. Also, if you are the only person trusted to control the private key, and you die, it would be good for someone else to be able to revoke it for you.
So you also may want to back it up, and/or distribute it to semi-trusted individuals to make sure it's available if needed. But you don't want those individuals to have access to the signing key itself, and would like to be protected if they don't secure the revocation cert properly.
An attacker that gets access to the revocation cert can do a lot of damage to you or your organization, even if they don't personally benefit (blackmail?). Or maybe they can find a way to exploit the power vacuum while the key is revoked and not yet replaced (perhaps they know how to poison the key re-distribution process). As always, most solutions are a balancing act of security and convenience.
My Solution: (assume the signing key is controlled by a company)
Use the Bitcoin network as the revocation "server", but add a large payment to a company address as a condition of revocation. The software that relies on verifying signatures from this key, will track of the latest blocks on the network, looking for the revocation trigger. Perhaps, they are hardcoded with the revocation cert message, and simply watch for OP_RETURN strings that contain a valid signature (and of course you get natural timestamping from this tx being mined).
So make the revocation condition 2-fold:(1) Requires a signature from the key being revoked in an OP_RETURN string
(2) The tx with the OP_RETURN must include a payment of 2,000 BTC to company address X
(X is probably a 3-of-5 address controlled by the 5 directors of the company, etc)
This is cool, because if the company itself decides to issue the revocation, it doesn't cost them anything because they are simply sending 2,000 BTC to themselves. They don't actually lose any money. But if someone else wants to maliciously revoke it without company permission, they're going to have to cough up 2,000 BTC to a company address, and won't get it back. Even if the company doesn't have that much BTC on hand, they can simply borrow it, send it to themselves, then return it (the existence of the 2,000 BTC tx is the trigger, doesn't matter where the money goes after that). Perhaps the value chosen is the perceived cost to the company of a malicious revocation -- an attacker has to pay them the cost of fixing the problem, if he's going to revoke maliciously.
While we don't like people dumping data into the blockchain, revocation happens exactly 0 or 1 time, ever. Very few people/orgs would use this technique, and even fewer would need to actually ever revoke. I'm fine with this, personally, in terms of blockchain bloat.
Revoke & Replace: (
)
In general there is no safe way to include revoke&replace in the same operation, since it would make the revocation certificate exactly as sensitive as the private key itself. However, if you employ pay-to-revoke, you've made it extremely expensive for anyone but the company to exercise that option. In some contexts, this still wouldn't be considered safe as an attacker may be able to profit more than 2,000 BTC by being able to quickly replace the signing keys.
OTOH, if you're going to do key revocation & replacement at the same time, you could also add a third and fourth condition, where the new key will not be considered active until after 30 days, and can be canceled by an even bigger payment to the same address! Then the company has 30 days to detect the attack, and send themselves >2,000 BTC to cancel the revocation -- and they get to keep the attacker's money!
