Key retirement and key compromise

Has anyone been thinking about providing tools to allow users to cope with key compromise - or more generally, to manage key retirement etc?

atm, if you suspect that your keys may be liable to compromise then what would you have to do? You'd have to create a new wallet (on a new computer? or is it easy to have two coexisting installs on one computer?) And then you'd have to make one or more payments from the old wallet to the new wallet, to transfer the coins. It's a pain, and you've lost your address book, your transaction history, etc. And unless you keep the old wallet about, too, you're a bit stuck if someone makes a payment to one of the old addresses. It's something that most users would baulk at unless they're really sure they're at significant risk.

Of course, there are a spectrum of scenarios, ranging from having an unencrypted wallet stolen by someone who knows what it is, through to deciding that the passphrase you used to use when you only had a few dollars worth of BTC maybe isn't good enough now you've got tens of thousands of dollars worth of coins. Or maybe you have no reason to suspect there is a risk of compromise, but just have a corporate key management policy that recommends retiring keys after a period of time.

What would be really nice is for bitcoin to have a big key compromise button, which would automatically transfer all coins to newly generated addresses (optionally with a pause between generation and transaction - to allow for a new wallet backup). Optionally, too, the compromised/retired addresses could be marked with a flag such that if someone sends coins to that address bitcoind immediately generates a transaction to transfer the coins to address(es) which are good.

I know deterministic wallets have many proponents - but personally I like having a bag of keys - with the idea that over a period of time, old keys will routinely be retired and their balances automatically transfered to newly generated keys. If someone really manages to crack the passphrase on that 10-year-old wallet backup they got hold of, then if would be nice to minimise the damage they could do...

And, of course, I want a big panic button that allows me to automatically transfer all my coins to new addresses ASAP if I suddenly do something stupid, like accidentally type my passphrase into my IRC window :-)

Thoughts? Is this functionality that there is any interest in developing within the official client? If there is any interest in this then obviously the first step would be to specify exactly what functionality is wanted...

roy

Just create a new wallet and send everything to a new address. I don't think additional tools for this are needed.

On 2/23/13, Roy Badami <roy@gnomon•org•uk> wrote:

> Has anyone been thinking about providing tools to allow users to cope
> with key compromise - or more generally, to manage key retirement etc?
>
> atm, if you suspect that your keys may be liable to compromise then
> what would you have to do?  You'd have to create a new wallet (on a
> new computer?  or is it easy to have two coexisting installs on one
> computer?)  And then you'd have to make one or more payments from the
> old wallet to the new wallet, to transfer the coins.  It's a pain, and
> you've lost your address book, your transaction history, etc.  And
> unless you keep the old wallet about, too, you're a bit stuck if
> someone makes a payment to one of the old addresses.  It's something
> that most users would baulk at unless they're really sure they're at
> significant risk.
>
> Of course, there are a spectrum of scenarios, ranging from having an
> unencrypted wallet stolen by someone who knows what it is, through to
> deciding that the passphrase you used to use when you only had a few
> dollars worth of BTC maybe isn't good enough now you've got tens of
> thousands of dollars worth of coins.  Or maybe you have no reason to
> suspect there is a risk of compromise, but just have a corporate key
> management policy that recommends retiring keys after a period of
> time.
>
> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet backup).  Optionally, too, the
> compromised/retired addresses could be marked with a flag such that if
> someone sends coins to that address bitcoind immediately generates a
> transaction to transfer the coins to address(es) which are good.
>
> I know deterministic wallets have many proponents - but personally I
> like having a bag of keys - with the idea that over a period of time,
> old keys will routinely be retired and their balances automatically
> transfered to newly generated keys.  If someone really manages to
> crack the passphrase on that 10-year-old wallet backup they got hold
> of, then if would be nice to minimise the damage they could do...
>
> And, of course, I want a big panic button that allows me to
> automatically transfer all my coins to new addresses ASAP if I
> suddenly do something stupid, like accidentally type my passphrase
> into my IRC window :-)
>
> Thoughts?  Is this functionality that there is any interest in
> developing within the official client?  If there is any interest in
> this then obviously the first step would be to specify exactly what
> functionality is wanted...
>
> roy
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

We've been toying with the idea of a 'dead' button, one that issues a bunch of pre-generated txs sending stuff out to a previously secured 'backup' set of addresses (we don't think in terms of wallets, just keypairs).

In this scenario, you have a long-term storage address (or set of them), and if you need to hit the panic button, previously signed transactions send value over to your emergency storage.

If you've mucked around sending / receiving with your long-term storage, you'd only catch some BTC, not necessarily all, but what's nice is the panic transaction leaking has lower security requirements than your private keys -- worst case it's out, and you've got to deal with stuff in emergency storage, as opposed to losing all your coins.

You could pair this with a server that checks if 'safe' addresses have 'unauthorized' transactions showing up on the blockchain, and you'd have a reasonable automated security layer. Maybe. :)

I'm interested in thoughts on this approach as well.

Jorge -- I respectfully disagree with you, there are a number of enterprise scenarios where your method is not appropriate.

On Fri, Feb 22, 2013 at 11:08:51PM +0000, I wrote:

> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet backup).  Optionally, too, the
> compromised/retired addresses could be marked with a flag such that if
> someone sends coins to that address bitcoind immediately generates a
> transaction to transfer the coins to address(es) which are good.

On Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote:

> The problem with automatic transactions would be: by repeatedly sending
> money to an address and seeing if it always moves quickly, an attacker
> can identify (a) that an address is in use, (b) which public key it has
> (if this isn't already public), and (c) that the key is believed to be
> compromised.

I realise on reflection that what I really want is not automatic transmissions, but a means to revoke an address.

The problem is that after transfering the coins from the compromised addresses to a new, hopefully safe address, what to do about the fact that third parties might still try to send me coins to an old, compromised address. So what I think I'm suggesting is that there should be an address revocation protocol, such that clients will give an error if their user tries to send coins to a revoked address.

Unless we think that direct payments to addresses will become completely obsolete once the payment protocol is in use, in which case (maybe) this functionality belongs in the payment protocol instead - but I remain unconvinced of that.

I'm not envisaging something as drastic as changing the rules to make transactions to revoked addresses invalid - just an overlay protocol. Although to be useful such a protocol would have to be pretty much universally implemented by clients.

Thoughts?

roy

On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami <roy@gnomon•org•uk> wrote:

> I'm not envisaging something as drastic as changing the rules to make
> transactions to revoked addresses invalid - just an overlay protocol.
> Although to be useful such a protocol would have to be pretty much
> universally implemented by clients.

That is quite drastic enough, as it requires adding more perpetual data that must remain in fast lookup for all validating nodes (the set of revoked 'addresses').

Keep in mind that this is only improvement for what is a usually inadvisable usage of Bitcoin to begin with... you should not be reusing addresses.

On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote:

> On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami <roy@gnomon•org•uk> wrote:
> > I'm not envisaging something as drastic as changing the rules to make
> > transactions to revoked addresses invalid - just an overlay protocol.
> > Although to be useful such a protocol would have to be pretty much
> > universally implemented by clients.
>
> That is quite drastic enough, as it requires adding more perpetual
> data that must remain in fast lookup for all validating nodes (the set
> of revoked 'addresses').

Maybe it should be possible for addresses to contain expiry dates, so that revocation lists don't need to hang around forever.

> Keep in mind that this is only improvement for what is a usually
> inadvisable usage of Bitcoin to begin with... you should not be
> reusing addresses.

It may be inadvisable but in many cases it is pretty much unavoidable as Bitcoin stands today. Granted, the payment protocol will help with that in many use cases...

roy