...
May I ask what are the known risks of accessing your wallets on a community binary download rooted Android ROM? Can you sandbox your application so other applications or system binaries can't readily access your wallets?
Sorry for not replying earlier... for some reason your post didn't show up as a reply until recently.
Caveat: speaking for my wallet application - Electroid - only.So - on a completely rooted ROM, you have a few attack vectors to consider:
* File access
* Memory access
* Input access
* Screen capture
File access is mitigated by the fact that your entire wallet will be an encrypted database, not the items, but the entire wallet. Inside the encrypted database will also be the encrypted keys (or seeds if a derivation-based algorithm is used). So - attacker would need to know your PIN which would be used to encrypt the entire database (or you could not encrypt if chosen)... then.. past that, the attacker would need to know your password for the wallet.
Memory access, you are not at risk unless you enter your PIN and passcode while something is watching the wallet's address space. Then the PIN / passcode and private key could be discovered...
Input access has similar risk to memory access, except it is significantly easier to watch and record all presses instead of watching for memory traces and record. This /could/ be mitigated by a custom keypad... however if someone has compromised your input method, it's not too far a stretch that other items are compromised.
Willing to add a custom keypad entry in the future, however. This would at least make the attacker use input detection AND image recording...
Screen capture would let the attacker see password entry due to typical keypad feedback. This paired with file access would give the attacker full access on device.
One possibility that I just thought of, relevant to newer devices, is that there is a possibility for hardware-stored crypto keys that are limited to a given application to access - this would be a good way to force the attackers hand into memory access watching or hack the hardware crypto mechanism.
Another item is the backups, since the mechanism will use public/private keys and encryption keys protected with those, the keypair attack window will be watching memory and/or input and/or screen at key generation time. The encryption key attack window will be at each backup... however if your memory is being watched - you're losing the battle.
If interested, I could post a security analysis as a blog entry - though I suppose a living document composed of attack vectors would be better...
Show Posts
... however... extending the hours in a day in such a way that sanity is maintained - well... that's more like the work for a Time Lord...
) I'll publish the algorithm that's needed to calculate the "proper" fee, ideally alongside the litecoind code so that it's easier to validate.
... after I make sure it merges with trunk and 1.9 cleanly.
