Topic: Idea for encrypted wallet implementation (Read 2297 times)

I use this method for all my banking transactions. I have Puppy Linux 5.2 on a 2GB SD card that I plug into a USB adapter. The advantages of this is once setup the way you want the write protect switch is good to stop anything unwanted being written to the SD card. And Puppy Linux runs entirely in RAM on the hosting PC, no devices are mounted which gives super high security in my opinion. I'm just starting to experiment with Bitcoin on it and it does run okay I just need to get all the procedures sorted out but its very promising. There is even 1GB left over to save backups of your wallet.

I personally would never use such a service if I knew that anyone else had an ability to decrypt my wallet.  I think people should be required to take the steps necessary to remember (or store in a safe somewhere) their wallet password, it's the safest practice and protects them and the services that hold very valuable data.  The UI could make this very clear to the user (if they lose or forget their password, their wallet is gone forever).  Note, I did think about schemes for splitting up an encrypted form of their password and storing it on three separate services...or using the public key of three different such backup services to encrypt the key so as to require the services to coordinate with each other if recovery is necessary.  I think something along those lines might still be possible, but could be added later if really needed, but I would absolutely design it to be optional and come with disclaimers and warnings that you are giving people a means of accessing the contents of their wallet by sharing such information.



Prompting on every send wouldn't be necessary (though for extra security one could set an option to require it).  Password entry would occur only on startup and a hash of the password stored in memory (rather than the user's raw password).  This password hash could then be used for everything...deriving one hash for encryption of the local file and through coordination with the backup service to get a different salt and hash for encryption of the backup copies when necessary.  The user would not need to enter the password again as long as the client remained running (and when the wallet eventually is properly separated from the client and UI processes, one could shut down the wallet when not in use (or it could time out) yet keep the client connected to the network and validating transactions, etc).

Btw, I meant to mention I can help with the coding (my IRC handle is gasteve) if you want help.  I do think getting this right is essential and would make it easier for lay people to have confidence in storing substantial sums of bitcoin in their wallets.

P.S. The client should also verify backups after uploading by re-downloading, decrypting and validating the contents.  And the ability to backup to two or more services should enabled in the client (for extra redundancy) and perhaps even the default.

Yeah but this is a necessary trade-off for people who aren't technical users. If they lose their keys.

Prompting for a new password after every send or new address is made would be annoying. Maybe it can be done like PokerStars- they have a normal password entry to login (with the option to save the password) but you can also upgrade to an RSA key entry token device. Maybe we could look into issuing those for bitcoin users who want more security at a small fee.


Yep, and I don't like messing with the user's keys either.


Sounds pretty comprehensive and better than what I've done. Can anyone see a point of failure in this scheme?

I'm very interested in this feature...if you upload the RSA key pair and the encrypted AES key, wouldn't the server then have everything necessary to decrypt the wallet?  That wouldn't be good.  Here's what I think I would do:

First, I think support in the official client for a wallet backup is an absolute must have.  From a user perspective, they would fire up the client, enter info once for a wallet backup service provider, all the encryption would be done in the official client (only strongly encrypted wallets are ever sent to the backup service provider).  The user should only have to enter a domain name for the backup service of their choosing (I'll leave the design for billing out of this post for now...mainly because I would hope this service would be offered for free initially while bitcoin is gaining in popularity...but also because I haven't given it any thought).  Once the user enters the domain name for the service of their choice, it'll contact the service and get some unique id for the backup (this id would be used for recovery and the user should be instructed to keep that id in safe location in case they ever need to access the backup for recovery purposes).  I suggest just using an id so that the service doesn't have to implement any account creation and such and the user doesn't have to go through that process (however, another alternative would be to use a users email address and doing email confirmation...that would minimize the risk of a user forgetting an assigned backup id).

Now for wallet encryption.  I would ask the user for a password and enforce some basic minimum entropy and password strength.  You then take the password and apply a crypto hash with a salt (i.e. sha256) to yield a derived password of say 24 bytes in length.  This is the key that will be used to encrypt the wallet with AES-256.  The encrypted wallet is transmitted to the server using SSL (which uses public key crypto).  The server could encrypt once more for storage on disk (in case someone gains access to the files on the server).

The client would automatically backup to the server every time a new bitcoin address is created (prompting for the user's password if they haven't already entered it, but remembering the server and id/email details).  The user's password would never be stored on disk.

Recovery would require the server assigned wallet id (or email address) to retrieve the backup wallet and the user would need to support their password (which would be hashed to get the AES-256 key for decryption).

Note: I do realize that hashing their password with a salt doesn't really add much additional protection against a brute force password attack if the attacker knows the salt and the hash algorithm (note, for a bit of extra security, the salt could be obtained from the server and be different for each account...an attacker would need to know what salt generation method the server was using).  If the attacker doesn't know the hash algorithm or salt, then the hash ensures a longer, and hence more secure, encryption key.

For even more security, the user's password could also be hashed on the client a second time (different salt) and that hash used for authenticating the user with the service such that someone else couldn't obtain download access to a user's encrypted wallet (keeping an encrypted wallet out of untrusted hands being one additional protection against a brute force attack).

One possibility I thought about, but discarded was to use GPG auth for authentication with the service and for securely storing a long, generated AES key on the client machine.  However, this has the disadvantage of relying on the local storage to keep the keys necessary for authentication and decryption (and then you would need a backup solution for this file as well!!!).

Note, the locally stored wallet should also be AES-256 encrypted on disk...the same password (with hashing and salting) could be used for the encryption key.  This would enable the user to enter one password on startup to decrypt the local wallet...and hash into a key for encrypting the backup.  The user's password would only be in memory temporarily for generating these hashes (thus reducing the risk of stealing this password out of memory...though the hash used for backup encryption would still be in memory).

Uh-huh...  storing a lot of bitcoins on a usually-network-connected device would make me very nervous.  I think we're going to see a LOT of smartphone exploits over the next 5 years (maybe I'll be pleasantly surprised and it will turn out the smartphone OS folks have done a great job making them secure).

But security is not a boolean, and we clearly need to do what we can to help people keep their bitcoin wallets secure.

Especially for windows users, I see only one solid solution currently: bootable usb stick with bitcoin installed. Nothing else but bitcoin, dependencies and tool to clone this to another usb stick. You want to put your savings there? You know the address. If you want to spend, you must reboot from the usb stick.

Caution:
* Never ever put this stick into computer running windows or whatever. You put it only in the machine that is off, then you start it.
* You prepare that stick not from your windows running, but from for example ubuntu liveusb/livecd (afair needed programs are there)

I already have something like this for my own usage, I was thinking about preparing something for mainstream usage but I do have many projects currently and doing this is not profitable (sorry I'm such a ... , anyway bounties welcome) It's also non trivial to convince about this thing authenticity and security. I cannot just provide you an ISO with this, because then you can never know if I haven't switched some binaries with something clever.

You can just use a smartphone app for everything. I don't think it's worth trying to create or use special hardware. You'd end up creating what was effectively a miniature computer, and you can't beat the big smartphone OEMs on price or capabilities. The UI would always be dramatically worse than what a smartphone app can provide too.

On modern phones apps are isolated from one another. The attack I describe with UI tampering is not possible. iOS at least (not sure about Android) supports encrypting files in such a way that they are only decrypted when the screen is unlocked with the phones passcode. It uses PBKDF2 with 50k iterations, apparently, and the device key is mixed in so brute forcing is not feasible. This means your wallet is safe if your phone is stolen.

There are various attacks possible. The most obvious is root exploits on the phones themselves, if there's a local root exploit then a bad app you install can still steal your wallet until the OS is patched. But at least it's not insecure-by-design like Mac/Linux/Windows are, and local root exploits aren't that common on these devices. The various third party "jailbreaking" attacks could be used by malware on your computer to jump the gap onto your phone, you can solve that by using a phone that requires being wiped to jailbreak it (like the Nexus One/S line) or by just not plugging your device into an untrusted computer. The future is cloud based sync anyway, I basically never plug my phone in to my laptop these days as it syncs everything via wifi.

If you have a wallet that you really want to protect, a smartphone that you don't install random apps on, you don't browse the web from and is never plugged into a PC is 99% as secure as a magic BitCoin specific hardware token would be, and the cost of these devices is dropping fast.

I wrote this program,
https://github.com/genjix/sekureco/blob/master/sekureco

Together with a cloud backup service (see www),
https://github.com/genjix/sekureco

I need someone to vet the security by me explaining what it does. I also need to clean up the code (comments, organisation, consistent naming), but for now it encrypts / backs up to server.

For integrating inside a bitcoin client.

./sekureco is a command line tool you can run with help instructions. See README also.

It works by using symmetric encryption for the wallet file (AES) and encrypting the AES key using an asymmetric encryption scheme (RSA).

For the server backup side, you upload (once only) your RSA keypair + encrypted AES key. The server responds with a 40 character long random ID code which you then use to upload your encrypted wallets. If the client wishes to backup their wallet they need the ID to download the latest version. If the user correctly enters the pass to the RSA keypair they can download the keys or ID (which can be used for fetching the encrypted wallets or uploading new versions). If they guess the pass incorrectly then the restore functionality for that account is locked for 10 hours.

I've been thinking a lot and trying to educate myself on best practices for securing the bitcoin wallet.

Part of the solution could be a smart card that supports ECDSA; the PKCS #11 standard supports elliptic key crypto, so it is feasible to have a hardware token that stores your private keys and never lets them out of the token.

If the token includes some type of biometric identification (e.g. built-in fingerprint reader or mechanism for entering a password) then there is no way for the trojan to spoof new transactions.

But [mike] is right-- if your computer is infected by a trojan the trojan can just rewrite the bitcoin address and amount before the software asks the hardware token to sign the payment transaction.  The only way to prevent that is if the hardware token can somehow display the transaction details independent of the infected computer.  That's one very sophisticated hardware token...

Hopefully Hal and bitcoinex will now tell us how all this was solved years ago and how an iPhone app synchronized with a dumb-ish smart card can use smart crypto to make it all work....

Of course that stealing is still possible, but I'm sure that wallet encryption can discourage script kiddies attack like "Wallet backup tool" few days ago. I believe that _you_ are able to write trojan changing GUI, but why are we leaving door open for every thieves going around?


Open door lock or break window is very easy to do. Stilll, this discourage most of people to walk into your house. It's not as perfect as living in vault, but windows & door fits needs of 99% people.

Right, the plan starts to work at step 3 where you "require a hardware device to spend the coins". In practice what that means is you want a BitCoin implementation that runs on (somewhat) secure hardware, or at very least hardware that is less likely than a desktop/server PC like what BitCoin uses today.

That's a significant project though. I've been arguing for using smartphones to do this for a while now and am slowly working towards that. Other devices are possible too.

Just encrypting your wallet on your PC or even storing the keys on a USB drive doesn't work because my trojan can simply sit there, wait until your copy of BitCoin is started up and you use the "send coins" UI then rewrite the address and amount you want to send to after you hit the OK button but before the transaction is created. Such trojans are not difficult. If there's any risk at all your computer might get compromised, you can't use BitCoin safely today   (or rather you can, but you're relying on the obscurity of the project to protect you). That's the key problem we need to solve, like by using phones.

For clarity's sake, I will refer to the private keys for use with Bitcoin as BPKs. Any other keys referenced are those used to encrypt/decrypt the BPKs.

Using this implementation, I could set up three levels of security for my wallet.

Level 0 has cleartext BPKs. Access to my wallet is sufficient to spend these coins.
Level 1 has BPKs encrypted with a GnuPG-like scheme as described above, with they encrypted private key stored in the wallet. In addition to access to my wallet, my passphrase is required to spend these coins.
Level 2 is the same as level 1, except the encrypted private key is stored on a smart card or USB drive. In addition to my passphrase and access to my wallet, the hardware device storing the key is required to spend these coins.

I could just be off my rocker, but this seems to rather elegantly solve some of the problems with password encrypted private keys.

I'm not sure what this is supposed to accomplish. If I can trojan your machine I can still steal all your coins. If I can't trojan your machine how do I access your wallet?

I'm cross posting this from a thread in tech support, and also github issues, but I thought it might get some more views here.

Suppose we encrypt keys with the public key of a separate private key. That private key is encrypted with a symmetric algorithm, whose key is derived from the passphrase. I believe this is how GnuPG works. When we store this encrypted key in the wallet, we also store a reference to the associated private key. (Or, perhaps have it elsewhere on the file system... usb drive? smart card? keyring?) With this functionality, we could prompt the user for a password once and decrypt multiple keys. It also means that a wallet could be separated into virtual partitions with different encryption keys. I think it would allow a smooth transition, but would it be backwards compatible?[1]

Here's the way I imagine interacting with this. I would keep a small amount of bitcoin in the clear. This allows me to easily spend the small amount while assuring I won't lose much if my device is compromised (good for mobile devices). I can easily encrypt/decrypt keys by entering a target amount to "transfer". The actual amount is determined by picking keys with transactions (outputs?) summing to approximately the target[2]. In order to spend more than is in the clear, I must enter one (or more) passphrases, but the rest is automated.

[1]Can the structure of the wallet be modified for encrypted keys and a reference to the encrypting private key without causing a breaking change?

[2]You can't split the output of a transaction without writing to the block chain, right?