Bitcoin Forum
December 11, 2016, 04:35:26 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [IDEA] Multi-level wallet encryption  (Read 1483 times)
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
October 10, 2011, 01:30:21 PM
 #1

I like how the 0.4 wallet has encryption requirements to send funds. How about multi-level encryption?

Let me explain: Currently I have two wallets:
1. A savings wallet, with a "big pile", for which I will only enter the decrypting password on a totally secure linux computer than has only Bitcoin installed
2. A spending wallet, with a "smaller pile" that I use on my day-to-day Windows machine.

Having to maintain two wallets is a pain, specifically because the savings wallet cannot be accesses (except read-only) on my main machine.

What I propose is having multi-level privilage system within the protocol itself, that would help me define a set of rules such as the following:

1. One master password is required to change the ruleset. I will only ever enter this password on a secure computer. With this password, I can define things like "minimum amount of coins that must remain in this wallet", or "maximum Bitcoin sent from this address per period of 100 blocks".

2. Another password, that will let me transact, but only within the ruleset defined with the master password. I will feel safe enough to use this password on my insecure machine, because even if I happen to have a trojan, I cannot spend more than 50 BTC per week, and I'll always have at least 200 BTC in my wallet (if those are the rules I defined with the master password). These guarantees are protocol-level, and cannot be circumvented by hackers.

3. Another read-only password that must be entered just to open the wallet and read its contents. Why not.


I think this could be implemented, and would greatly increase the security/convenience tradeoff of using Bitcoin.

Thoughts?

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
1481430926
Hero Member
*
Offline Offline

Posts: 1481430926

View Profile Personal Message (Offline)

Ignore
1481430926
Reply with quote  #2

1481430926
Report to moderator
1481430926
Hero Member
*
Offline Offline

Posts: 1481430926

View Profile Personal Message (Offline)

Ignore
1481430926
Reply with quote  #2

1481430926
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481430926
Hero Member
*
Offline Offline

Posts: 1481430926

View Profile Personal Message (Offline)

Ignore
1481430926
Reply with quote  #2

1481430926
Report to moderator
1481430926
Hero Member
*
Offline Offline

Posts: 1481430926

View Profile Personal Message (Offline)

Ignore
1481430926
Reply with quote  #2

1481430926
Report to moderator
1481430926
Hero Member
*
Offline Offline

Posts: 1481430926

View Profile Personal Message (Offline)

Ignore
1481430926
Reply with quote  #2

1481430926
Report to moderator
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
October 10, 2011, 04:27:26 PM
 #2

I like how the 0.4 wallet has encryption requirements to send funds. How about multi-level encryption?

Let me explain: Currently I have two wallets:
1. A savings wallet, with a "big pile", for which I will only enter the decrypting password on a totally secure linux computer than has only Bitcoin installed
2. A spending wallet, with a "smaller pile" that I use on my day-to-day Windows machine.

Having to maintain two wallets is a pain, specifically because the savings wallet cannot be accesses (except read-only) on my main machine.

What I propose is having multi-level privilage system within the protocol itself, that would help me define a set of rules such as the following:

1. One master password is required to change the ruleset. I will only ever enter this password on a secure computer. With this password, I can define things like "minimum amount of coins that must remain in this wallet", or "maximum Bitcoin sent from this address per period of 100 blocks".

2. Another password, that will let me transact, but only within the ruleset defined with the master password. I will feel safe enough to use this password on my insecure machine, because even if I happen to have a trojan, I cannot spend more than 50 BTC per week, and I'll always have at least 200 BTC in my wallet (if those are the rules I defined with the master password). These guarantees are protocol-level, and cannot be circumvented by hackers.

3. Another read-only password that must be entered just to open the wallet and read its contents. Why not.


I think this could be implemented, and would greatly increase the security/convenience tradeoff of using Bitcoin.

Thoughts?

418 people read this post, and not a single comment?

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 10, 2011, 05:04:21 PM
 #3

The problem is that encryption can't  be used to enforce rules.

I like the idea of a multi-password wallet (think checking & savings).  A custom bitcoin client could show for example you have 47BTC in savings and 10.2892389 BTC in checking.  Daily you use the checking password which decrypts the checking addresses.  A compromise of system would limit your coins lost.

The problem with your rules proposal is it wouldn't be "strong" protection.  As far as I understand it the "rules" would be merely enforced by the client.  If I try to send 101BTC the client detects that as invalid and stops me.  If the hacker gets your password they simply copy the wall.dat, use a custom client which ignores all the rules and use the password to decrypt wallet.dat.  The custom client doesn't enforce the "rules" (actually just ignores all rules data in wallet) and happily sends the transactions.  Now if you have two passwords (checking & savings) and hacker got only one of them it limits how much damage he can do but the rules didn't help any.

So in summary:
2 address groups each with different password is strong protection.  A compromised password only compromises some of the addresses.  To implement one would simply need a client which is aware of addresses groupings, knew when to prompt for saving account password, and could display both balances.  Certainly do-able.

Rules based security can only be enforced by the client and no hacker is going to use the valid client meaning it provides no real security.
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
October 10, 2011, 05:35:18 PM
 #4

The problem is that encryption can't  be used to enforce rules.

I like the idea of a multi-password wallet (think checking & savings).  A custom bitcoin client could show for example you have 47BTC in savings and 10.2892389 BTC in checking.  Daily you use the checking password which decrypts the checking addresses.  A compromise of system would limit your coins lost.

The problem with your rules proposal is it wouldn't be "strong" protection.  As far as I understand it the "rules" would be merely enforced by the client.  If I try to send 101BTC the client detects that as invalid and stops me.  If the hacker gets your password they simply copy the wall.dat, use a custom client which ignores all the rules and use the password to decrypt wallet.dat.  The custom client doesn't enforce the "rules" (actually just ignores all rules data in wallet) and happily sends the transactions.  Now if you have two passwords (checking & savings) and hacker got only one of them it limits how much damage he can do but the rules didn't help any.

So in summary:
2 address groups each with different password is strong protection.  A compromised password only compromises some of the addresses.  To implement one would simply need a client which is aware of addresses groupings, knew when to prompt for saving account password, and could display both balances.  Certainly do-able.

Rules based security can only be enforced by the client and no hacker is going to use the valid client meaning it provides no real security.

This might require a change in the Bitcoin protocol itself, not just a change in the client.
But, I believe the protocol could be changed to support this new kind of restrictions ... perhaps even in a backward-compatible way.
Or perhaps it could be implemented with scripts.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
October 10, 2011, 05:55:34 PM
 #5

I don't think such changes to the protocol are necessary. Here's how a client could implement something like what you suggest, but with real encryption rather than just client side password protection.

For the purposes of this post, "key" = the private EC key that Bitcoin uses to sign transactions, "$key" =  password, passphrase, or other encryption key used to decrypt a Bitcoin "key"

A wallet is broken up into multiple pools of keys. Each pool can have a different $key with which all of its keys are encrypted. Your daily use pool may not be encrypted at all for quick transactions. Your intermediate pool(s) may require increasingly complex passwords. Your super secure saving pool may require a hardware token on which a $key is stored.

I like the idea that even while using a password or passphrase, in the background a public/private $keypair is used to do actual encryption of the key. Rather like GPG encrypts your private keys with a passphrase, this would allow more flexibility in the use of pools. For instance, when you generate a new receiving address, you could assign it to a secure pool without having to enter the passphrase or insert the hardware token.
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
October 10, 2011, 07:31:52 PM
 #6

I don't think such changes to the protocol are necessary. Here's how a client could implement something like what you suggest, but with real encryption rather than just client side password protection.

For the purposes of this post, "key" = the private EC key that Bitcoin uses to sign transactions, "$key" =  password, passphrase, or other encryption key used to decrypt a Bitcoin "key"

A wallet is broken up into multiple pools of keys. Each pool can have a different $key with which all of its keys are encrypted. Your daily use pool may not be encrypted at all for quick transactions. Your intermediate pool(s) may require increasingly complex passwords. Your super secure saving pool may require a hardware token on which a $key is stored.

I like the idea that even while using a password or passphrase, in the background a public/private $keypair is used to do actual encryption of the key. Rather like GPG encrypts your private keys with a passphrase, this would allow more flexibility in the use of pools. For instance, when you generate a new receiving address, you could assign it to a secure pool without having to enter the passphrase or insert the hardware token.

This is true. However, I don't see how this could be used to implement smarter policies like "Don't spend more than 1 BTC per 10 blocks from this pool". I might be shortsighted though.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
October 10, 2011, 07:56:38 PM
 #7

This is true. However, I don't see how this could be used to implement smarter policies like "Don't spend more than 1 BTC per 10 blocks from this pool". I might be shortsighted though.

Not directly, but you could create a "1 BTC per 10 blocks" unencrypted pool, which has an upper limit of 1 BTC balance, and the client will attempt to "refill" it 10 blocks after its balance decreases.

To send, you would have to provide your $key if sending from an encrypted pool. To refill, you would also have to provide your $key if refilling from an encrypted pool.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 10, 2011, 08:04:15 PM
 #8

Not directly, but you could create a "1 BTC per 10 blocks" unencrypted pool, which has an upper limit of 1 BTC balance, and the client will attempt to "refill" it 10 blocks after its balance decreases.

To send, you would have to provide your $key if sending from an encrypted pool. To refill, you would also have to provide your $key if refilling from an encrypted pool.

IF someone used it on a client that ignored the rules then they simply would send all they wanted from your main account (assuming the have the password).  You can't enforce rules on a client that is compromised and for good security you should assume the client is compromised.  Then only way to have any meaningful security is if you could push rules to the network and the network (i.e. miners) would reject transactions that violate the rules.

In that case compromising the client wouldn't do you any good.  If I have an outstanding rule that no more than 1 BTC from address x can be spent per block then the network would reject any transactions in excess of it. 


Encryption is good for keeping secrets.  It isn't good for making rules.  Trying to use encryption for the wrong task only create the illusion of security.
You can't implement security into the client.  You should assume the hacker has their own client and your wallet.dat.  For higher security you should also assume the attacker has any password you have typed. This is why a checking account vs saving account model would provide some limited security.  If you haven't typed your saving's account password since the computer was compromised then damage is limited to your checking account.
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
October 10, 2011, 08:20:00 PM
 #9

Not directly, but you could create a "1 BTC per 10 blocks" unencrypted pool, which has an upper limit of 1 BTC balance, and the client will attempt to "refill" it 10 blocks after its balance decreases.

To send, you would have to provide your $key if sending from an encrypted pool. To refill, you would also have to provide your $key if refilling from an encrypted pool.

IF someone used it on a client that ignored the rules then they simply would send all they wanted from your main account (assuming the have the password).  You can't enforce rules on a client that is compromised and for good security you should assume the client is compromised.  Then only way to have any meaningful security is if you could push rules to the network and the network (i.e. miners) would reject transactions that violate the rules.

In that case compromising the client wouldn't do you any good.  If I have an outstanding rule that no more than 1 BTC from address x can be spent per block then the network would reject any transactions in excess of it. 


Encryption is good for keeping secrets.  It isn't good for making rules.  Trying to use encryption for the wrong task only create the illusion of security.
You can't implement security into the client.  You should assume the hacker has their own client and your wallet.dat.  For higher security you should also assume the attacker has any password you have typed. This is why a checking account vs saving account model would provide some limited security.  If you haven't typed your saving's account password since the computer was compromised then damage is limited to your checking account.

I think you misunderstand my proposal. The pools are secure, they each can have a different password/passphrase/hardware token. The rule based refilling of pools is merely for ripper's convenience. If the attacker acquires the wallet.dat, all they would be able to do without the correct $keys is to steal any bitcoins in the unencrypted pool(s).
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
October 10, 2011, 08:22:07 PM
 #10

In case you're not already in the loop, there's been some discussions about extending the scripting language used for transaction verification and modify it to allow scripts to be transparent to senders (example). I'm not at all in the know what's going on but it's possible this can be accomplished with the right script.

PS I've been thinking about the same thing for a long while.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 10, 2011, 08:28:50 PM
 #11

I think you misunderstand my proposal. The pools are secure, they each can have a different password/passphrase/hardware token. The rule based refilling of pools is merely for ripper's convenience. If the attacker acquires the wallet.dat, all they would be able to do without the correct $keys is to steal any bitcoins in the unencrypted pool(s).

I get each pool can have unique password.  I even indicated that was a good idea above (checking account vs savings account).

However you abstract away a serious important point:
" The rule based refilling of pools is merely for ripper's convenience"
How does the client follow the rule and move funds from one pool to another (i.e. refill a pool).  It MUST have the password/private key/token/etc for the pool the funds are coming from.  Otherwise how is it doing the refilling? (which is just a transaction from one pool into another pool)?  Attack the client and steal passphrase for the "refilling pool" and transfer out all funds.

Even worse if the pool has to be manually refilled (by user entering password) for larger fund well you have no more security than a single wallet address.  When you enter the password, someone can keylog it, and then create a new transaction to empty the "filling" address to their wallet.

Having multiple "accounts" inside a single wallet is of some security value.  One could have daily transactions from a limited wallet and only periodically (preferably on a secure usb key) transfer funds from the "savings" account pool to "checking" account pool.  This means daily the only thing accessible to keylogger is the checking account which has limited value.

Once you start making rules to transfer funds between accounts *SOMETHING* must be doing that transfering and that something has the key.  Attack the *SOMETHING* and you have the key of the big wallet.  Forget the limited access wallet at that point you just hit the motherload.
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
October 10, 2011, 08:29:38 PM
 #12

I think you misunderstand my proposal. The pools are secure, they each can have a different password/passphrase/hardware token. The rule based refilling of pools is merely for ripper's convenience. If the attacker acquires the wallet.dat, all they would be able to do without the correct $keys is to steal any bitcoins in the unencrypted pool(s).

I get each pool can have unique password.  I even indicated that was a good idea above (checking account vs savings account).

However you abstract away a serious important point:
" The rule based refilling of pools is merely for ripper's convenience"
How does the client follow the rule and move refill one pool.  It MUST have the password/private key/token/etc for the pool the funds are coming from.  Otherwise how is it doing the refilling? (which is just a transaction from one pool into another pool)?  Attack the client and steal passphrase for the "refilling pool" and transfer out all funds.

If the pool has to be manually refilled (by user entering password) for larger fund well you have no more security than a single wallet address.  When you enter the password, someone can keylog it, and then create a new transaction to empty the "filling" address to their wallet.

This.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
October 10, 2011, 08:33:03 PM
 #13

In case you're not already in the loop, there's been some discussions about extending the scripting language used for transaction verification and modify it to allow scripts to be transparent to senders (example). I'm not at all in the know what's going on but it's possible this can be accomplished with the right script.

PS I've been thinking about the same thing for a long while.

Ho Many, I never saw you around here, even though we met in person and you seem to be quite active.
To sidetrack for a second, what's your opinion on this thread (totally unrelated, if you respond please post there)?

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
October 10, 2011, 09:36:41 PM
 #14

Ho Many, I never saw you around here, even though we met in person and you seem to be quite active.
I am, you're probably not looking hard enough. And not interested enough in mining pool reward systems, which is generally my primary area of contribution.

To sidetrack for a second, what's your opinion on this thread (totally unrelated, if you respond please post there)?
Which thread? Is a link missing?

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
October 10, 2011, 09:45:03 PM
 #15

Ho Many, I never saw you around here, even though we met in person and you seem to be quite active.
I am, you're probably not looking hard enough. And not interested enough in mining pool reward systems, which is generally my primary area of contribution.

To sidetrack for a second, what's your opinion on this thread (totally unrelated, if you respond please post there)?
Which thread? Is a link missing?

Sorry, this: Alternate Currencies Review.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!