Giszmo
commented
7 years ago The longer pins and encrypted keys is a very frequent topic here and I agree with the long standing discussion that it's not practical to use keys that can't be brute-forced on the phone. Suppose we used x rounds of scrypt of pin and salt to get to the key. x would need to be small enough so it gets to a key in maybe a second yet big enough so that a state adversary can't brute force stuff with an array of super computers. With a 6 digit pin, brute forcing is "only" a million times more costly than knowing the pin. Trivial for super computers vs. a cell phone.
Now most users lose their coins due to forgotten pins and backups, not to threats described by you. For the inclined users there always exist ways to have decoy wallets. With a keepkey you can use bip39 with password and use the account without password on your phone as a decoy and with the password as an account you usually delete.
The Hardware-Backed security certainly is something we should add.
Feature Request: Hardware-Backed Security
Recent Android hardware supports hardware-backed security. The APIs since Android 6.0 include calls to access the secure hardware. The Mycelium developers should consider (as time and resources permit) encrypting private keys, decrypting them when the PIN is entered, and doing this with hardware-backed security to make offline brute-force decryption impractical.
I don't see any provision in the Android APIs for keys to be automatically wiped after repeated brute-force cracking attempts. But the API does allow for limiting the number of cracking attempts during one power-up session. I'm not sure how well this protects against offline attacks. It should definitely slow them down.
Possibly relevant previous issues: #21 encrypt wallet, #283 protect pin from being brute-forced, #274 PIN timeout, and #156 encryption using NFC tag.
Optional Reading Below
Background discussion and additional miscellaneous ideas are presented below. I hope random searches will turn these up in the future any time the Mycelium developers are looking for new ideas to enhance security. I'll refrain from adding to unnecessary clutter by creating multiple issues for these.
Risk of PIN Reuse
Human beings often reuse passwords. If a 6-digit PIN used in one place can be guessed by brute force, it is compromised in other places too where it has been used by the same person.
Suppose a user's favorite PIN x is used as the lock screen code on that user's iPhone and also as the Mycelium PIN on the user's Android device. If an adversary steals both devices, cracking the Mycelium PIN also allows them to access the iPhone using the same PIN. Normally, iPhone's PIN would be uncrackable because rate-limited hardware-backed encryption is used. But cracking the Mycelium PIN is trivial if done offline by a competent hacker who accesses the storage medium directly.
The Android OS decrypts storage when the boot-time lock screen code is entered, and the storage remains decrypted even after the powered-up device enters lock screen mode. So an Android device that is stolen while powered up might as well not have encrypted storage at all -- the lock screen is implemented in software, and does not prevent the decrypted storage from being directly accessed after opening the still-powered-up device. This is why the FBI keeps complaining about inability to break into iPhones, but never complains about Android devices.
New Threat Model
Previously, it was assumed that if we lost our Android device, we could sweep out bitcoins into new locations before the bad guys were able to get past the lock screen and the Mycelium PIN. Our new threat model should take into account the possibility that we are locked up and unable to move bitcoins out while the adversary has full access to our device.
Keep in mind that the adversary already has a reputation for stealing cash. Stealing bitcoins, once they figure out how, will be only a slight extension of this common practice.
Encryption Without Hardware-Backed Security
Even if hardware-backed security is not available, encryption would still be preferable, because it will at least slow down access to private keys. This will give the phone owner, if he was detained and then released (as in the cited link above), more time to sweep out the bitcoin funds.
Long PINs
In the absence of hardware-backed security, long PINs should be permitted. With suitable password-stretching, and if a long enough PIN is used, it would take an adversary weeks or months to crack a software-based PIN.
All we need to do is add an Enter key to indicate the end of PIN entry.
As proposed in issue #325, a partial PIN could be used to unlock to a read-only mode, and the entire PIN would then be required to decrypt the keys and allow spending funds.
Additional Characters in PINs
Despite the name "PIN", additional characters can and should be permitted in PINs.
Numeric-only PINs made sense in ancient times when we were entering them on touch-tone keypads. Now we are using smartphones and there is no good reason to limit PINs (despite the name) to digits only. The real benefit to a PIN as opposed to a general password is easy of data entry. Most smartphones could easily show 16 to 20 characters on a "PIN" keypad while still providing the same easy of data entry. Increasing the complexity of PINs will allow for more secure PINs. A 4 x 4 layout gives us 16 characters, and a 6 x 4 layout (to fit a rectangular screen) gives us 24.
Mycelium as a Semi-Hardware Wallet
Currently we have two types of solutions to protect private keys. We can implement one in software, as Mycelium currently does, or we can use a hardware wallet, which means we have to carry a yet another device with us.
If Android's hardware-backed security is used, we have an intermediate solution. The keys would be protected to a much greater degree than they currently are, but not as well as a dedicated hardware wallet. So Mycelium + Android's hardware-backed security would be a sort of semi-hardware wallet, suitable for intermediate amounts of bitcoin funds.