Author

Topic: Pay-to-Revoke using the Bitcoin Network (Read 1162 times)

legendary
Activity: 1792
Merit: 1111
March 25, 2014, 04:39:05 AM
#10
aha so you want a collective revoking scheme - eg if a software Company signs malware with their signature, a crowdfunding campain can be started, collecting 2000 BTC and then we can revoke that company's key making the Company unable to spread malware for some time?

Absolutely not. Doing so you are donating 2000BTC to the company signing malware

How should Bitcoin know which bitcoin adress (ECC key) belongs to a specific RSA key/certificate? (and where the Money needs to be sent to revoke the RSA key/certificate)

It doesn't need to. This scheme simply uses the bitcoin network as a distributed timestamping server. You need to announce these information with other method.
full member
Activity: 129
Merit: 119
March 25, 2014, 04:29:35 AM
#9
aha so you want a collective revoking scheme - eg if a software Company signs malware with their signature, a crowdfunding campain can be started, collecting 2000 BTC and then we can revoke that company's key making the Company unable to spread malware for some time?

How should Bitcoin know which bitcoin adress (ECC key) belongs to a specific RSA key/certificate? (and where the Money needs to be sent to revoke the RSA key/certificate)


-----

About the problem with distributing revocation certificates:
Encrypt your revocation certificate with scrypt+passphrase and send it where you want.
You could even publish the encrypted revocation certificate on your website, in internet archives, everywhere, with complete instructions on how to decrypt the certificate, but EXCEPT the passphrase.

When its time to drop the bomb, you simply also publish the passphrase. Anyone can now revoke your keys, and the first one who sees the passphrase will revoke the key for you.
Since now, you want to revoke the key, its no danger that the whole World can see your revocation certificate.

The "bomb dropping mechanism" can simply be anything, let it be a dead mans button webservice - if you die or become unavailable, the web service will simply make sure the passphrase is published, revoking your key.

Think like "Wikileaks Insurance".
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
March 22, 2014, 10:57:30 PM
#8
Quote
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, you scheme actually makes the private key of the pay-to-revoke bitcoin address exactly as sensitive as the (PGP) private key itself. If I could safe keep a bitcoin private key, I could do the same for the revocation and replacement cert.


Not necessarily.  The pay-to-revoke payment address may have different security properties than the signing key(s) being protected.  For instance, I have a single GPG private key for signing company software releases, but the payment goes to a 3-of-5 address controlled by the directors of the company.  Also, a compromised pay-to-revoke address (without the protected signing key) does not give the ability to revoke the key... it simply nullifies the advantage this scheme has over the way revocation is done now, but doesn't really make it any worse.

Though, if the attacker compromises the directors' 3-of-5 address, you are probably totally screwed in so many other ways...
legendary
Activity: 1792
Merit: 1111
March 22, 2014, 10:48:27 PM
#7
Quote
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, you scheme actually makes the private key of the pay-to-revoke bitcoin address exactly as sensitive as the (PGP) private key itself. If I could safe keep a bitcoin private key, I could do the same for the revocation and replacement cert.
full member
Activity: 182
Merit: 100
March 22, 2014, 07:28:00 PM
#6
Wallet/Address issue

I don't know a lot of the code or how it works, a total newbie, making it a simple as possible.

Some thing I thought about lately, a 3 key system for address locking 3+ address's to a user.
...

This is really off-topic for this thread.  You should be aware that my idea is not about protecting Bitcoins or Bitcoin private keys, but about protecting a private key that is used, say, to sign software installers, etc.
no problem Deleting
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
March 22, 2014, 06:09:04 PM
#5
Wallet/Address issue

I don't know a lot of the code or how it works, a total newbie, making it a simple as possible.

Some thing I thought about lately, a 3 key system for address locking 3+ address's to a user.
...

This is really off-topic for this thread.  You should be aware that my idea is not about protecting Bitcoins or Bitcoin private keys, but about protecting a private key that is used, say, to sign software installers, etc.
newbie
Activity: 28
Merit: 0
March 22, 2014, 07:03:20 AM
#4
Using the Bitcoin network as the revocation "server", but adding a large payment to a company address as a condition of revocation is a good solution
full member
Activity: 182
Merit: 100
March 21, 2014, 05:48:12 PM
#3
So you basically mean a user could "lock" a address with 3 or more address's owned by user?

Great idea as it would be a lot harder to find the private keys for 3 public's.
is the 3 address's hidden from hacker's in block chain data?
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
March 21, 2014, 02:39:46 PM
#2
To follow up on the Revoke & Replace idea.  I think it could be somewhat secure if you use the following conditions:

Revoke and Replace:

(1) Must include a valid signature
(2) Must be in a tx sending exactly 2,000 BTC to company address X
(3) Replacement considered valid after 4032 blocks

Replacement Cancellation: (revocation still valid)

(4) Within that 4032 blocks, if a another transaction shows up sending 2,000 BTC to company address X, the replacement is cancelled (though revocation will still be permanent)

Basically, you're allowing revocation of the replacement, which is potentially the most dangerous part of a Revoke&Replace capability.  Revocation remains permanent, since the system has clearly been compromised, anyway.

Again, this adds a hardcore asymmetry to the situation, since it costs the company nothing to exercise any step, but extremely costly to an attacker.  And if their goal is to replace the key, they have to risk 2,000 BTC to even try, and most likely they fail and lose the money.  
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
March 21, 2014, 02:21:19 PM
#1
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: (Huh)

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!
Jump to: