Option to move wallet.dat to SD card storage #9

Closed
gary-rowe opened this Issue Jul 7, 2011 · 6 comments

Comments

Projects
None yet
4 participants

Given the limited size of the HTC Desires internal memory (~20Mb available) and the growth of the wallet.dat due to transactions, would it makes sense to allow the user to move the wallet.dat file to the SD card (with appropriate security?).

This issue was first raised here: http://forum.bitcoin.org/index.php?topic=26718.msg336516#msg336516

I support this enhancement request. I installed the app and uninstalled it immediately because it takes up too much internal memory.

The wallet.dat is tiny (relatively); so won't be using up a lot of memory.

However: bear this in mind... the SD card has no access permissions. any app can access any of it. There are already information stealing trojan apps appearing for android. When they figure out that there could be a wallet.dat on the freely-accessible SD card, there will be thefts.

Remember: theft of a wallet is undetectable. Until the day you put 1000 BTC in a wallet that someone copied five years ago. That's the day they empty it.

That's a very good point.

So it seems to come down to either relying on the Android security protecting the internal memory, or encrypting the wallet.dat in a form of the owner's choosing so it can be safely stored in the open.

If the app provides a default encryption technique then it needs to satisfy the following at a minimum:

  1. easy for a non-technical user to unlock when they want to buy their latte
  2. able to operate securely in a compromised environment (e.g. keylogging trojan is eavesdropping)
  3. offer strong offline protection against a sustained brute force attack (e.g. wallet.dat is copied to thief's machine and subjected to rainbow tables etc)

That's a tough list to meet. Some immediate (probably half-baked) thoughts are:

  1. simple PIN/gesture to unlock wallet in memory - combine with random salt (perhaps taken at startup or present in secure cloud storage)
  2. no idea how to overcome this (the eavesdropper has full access to everything and inifinte knowledge) - just rely on installing apps from reputable sources and marketplaces
  3. pretty much any of the Bouncy Castle algorithms will do the trick, AES is a good start.

I think mitigating against a keylogger on android is not worth bothering with. If you are that compromised, then you're doomed whatever.

However, there are plenty of trojans that trick people into installing them. They don't necessarily have free reign of the system, they aren't root and Android's permission system will keep them sandboxed to an extent. But... nobody worries too much when they see "accesses SD card" in the permissions list; most programs want to store data. That would be enough to read off a wallet.dat stored on the SD card.

At the very least (if storage space is an issue), encrypt the wallet on the SD card and keep the key on internal storage.
A PIN to make spending possible would be an excellent addition, but would be a bonus rather than a necessity.

The necessity is: don't store an unencrypted wallet on the SD card.

This issue is probably going to get resolved as part of ongoing developments in the underlying BitCoinJ library with common encrypted wallet formats and key management. Is that the general concensus of the developers?

Owner

barmstrong commented Jul 17, 2011

Good discussion thanks! Yep for now we don't want to move the wallet to the SD card since other apps can read it there.

I think it's unlikely the wallet file would grow beyond 100k, even with tons of transactions.

The reason it uses so much internal memory is that we packaged the production blockchain with the app, so it ends up being 22MB. it may help to move the actual app to the SD card? You can do this from Settings -> Applications -> Bitcoin -> Move to SD card.

On my phone it installed there by default I think (we set this preference in the Android Manifest). But could be different on different hardware?

@barmstrong barmstrong closed this Jul 17, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment