Can a mobile be protected against the "Linode problem"?

Question

The "Linode problem" I'm referring to is where an external trusted party has administrative control over your device.

Mobile phones are essentially managed devices. They can be fully controlled by someone other than the owner of the device.

Yes, they are managed by the carrier but possibly that carrier has people that cannot be trusted or, something just as bad, has people who don't maintain secure systems themselves such as what reportedly is what happened at Linode.

The importance is this. Consider Safaricom's M-Pesa mobile payments system used widely by those in Kenya.

An attack that defrauds M-Pesa's users en mass means that at some point Safaricom figures out that there's a problem, halts all affected systems to prevent further losses, and in the end eats some, most or all of the customer's losses.

With a mobile app like BitcoinSpinner, or My Wallet from BlockChain.info or even a hosted service like Paytunia's online wallet, the risks are quite different from M-Pesa's. The carrier doesn't promote the Bitcoin app nor offer any guarantees. A similar attack through the managed services of the mobile carrier's network to steal bitcoins from mobiles would cause the finanical losses to afflict the individual mobile user alone.

Just like how Linode disavowed any responsibility to Slush, Bitcoinica, etc. for the tens of thousands of bitcoins lost, carriers such as AT&T, Vodafone and Safaricom would likely maintain the same type of position.

So, this is a fundamental question -- is the practice of storing bitcoin private keys on the mobile something that exposes it to so much risk that it shouldn't even be considered (at least, not for amounts greater than the amount of cash one might carry in a back pocket?)

Or are there ways to secure a mobile device so that even if some piece of malware is deployed by a carrier's rogue employee that the bitcoins would still be secure?

Answer 1

If your private key is compromised your coins are gone

So the short answer is that the "Linode problem" where your entire private key is at the mercy of a third-party capable of root access to your system is somewhat intractable. As others have stated you can limit your key's exposure, but malware is patient.

Off topic, but possibly of interest, is a project by the MultiBit team to use a HP50G scientific calculator as an item of trusted hardware capable of signing transactions. Not much use out in the field like a mobile would be, but handy for a small business reconciling small volumes of transactions.

Answer 2

The answer to that depends on the scope of what the malware can do. Assuming the whole device is compromised, exposing all of our stored data as well as everything we do on it, storing your wallet on a mobile phone will result in your coins being stolen sooner or later.

If your coins are store in an encrypted wallet, the malware just has to wait until you input your password to decrypt your keys and your money is lost. If your wallet is unencrypted, it's all the easier.

One could, however, still use an eWallet semi-securely if some additional measures are taken. If the service provider would provide one-time passwords that are not time-synchronised, the system could either allow for somewhat safe Bitcoin usage, or at least detecting that your system is compromised. This is how it would work:

Lets say you have a set of one time passwords numbered 1-10, and you alreay used numbers 1, 2 and 3. You log into your eWallet with your mobile phone, compromising your password, but every important action on the website requires one of the otps to be used. Should the malware try to change anything, it would use up password 4 attempt, and when you'd want to do something, you'd be prompted for password 5. Seeing that you haven't used number 4, you could suspect compromise.

If the malware didn't act, you could try sending a Transaction and inputting an otp, and the malware could either stop you from doing that, or perform a sort of double-spend by trying to execute a second Transaction from your eWallet in the background. If the request for a Transaction came after yours, it would not work, as it would require password 5 which you will not input, as you'd use password 4.

Depending on the sophistication of the malware, it is possible to develop a very specific malware that would execute its own transaction instead of yours, spoofing the website form for your inputs and tricking you into inputting the correct password for its use.

All in all, if your system is compromised, coins stored on it are as good as gone once you input the password to decrypt them. If they are stored online, there are measures to prevent their theft, but there are workarounds.

Answer 3

Assuming you want an app which is secure, but presumes that:

1. the mobile is completely compromised;
2. the private key has a strong password;
3. there is a backup of the private key.

A form of two-factor authentication, perhaps through bluetooth on another device, may be able to provide enough security for most use cases and most current bitcoin demographics. Still, that would of course bring the usual trade-off of bringing additional overhead to user experience.

Answer 4

Generally, application updates do not occur automatically. As a result protection from a wallet-stealing compromise, for instance, can come from not installing updates until after most everyone else has already upgraded.

This delay won't protect if you do installed it eventually but the likelihood would be that others would experience a problem before you've even installed the update.

Answer 5

Stephen, I would add to what the user linhares answered earlier to your question. Indeed, a two-devices solution would clear the air and in the same time will mitigate the wrongdoings of the staff of the mobile software manufacturer (I'd refer here only to Samsung as you did, too), or even of a possible malware infecting your smartphone. A wearable wallet, like the one suggested by Accelabyte, could be a future solution, when fully developed and released. On one hand, the part of software installed in the smartwatch, connected only by BLE, and controlled exclusively from the "watch side" of the duo, could execute the decryption of keys, issue the raw transactions and then eventually only broadcast them, signed, through bluetooth toward the other end (a smartphone connected to the internet). Each end of the BLE connection would play its separate role, as time as even the barcode requested in order to know the address of recipient can be scanned with the watch camera, too. The major drawback occurred in the process was the update of Gear from Android to Tizen, instead, which changed the established playground of Android with the less mature (and secure) one of Tizen. The second one was the update to KitKat, which affected for unsuspecting users (I would say then the majority of bitcoin users) the feature offered by App Ops application (now working only for rooted smartphones), namely the option of blocking these endless and nasty privileges asked by almost any new app installed from Google play. Both those shelved the Accela's project for a quite long time, as I've heard from someone familiar with the matter. For short, the data container created by Accela would effectively insulate the processes used in spending the coins (think of kinda Knox features, which work separately from the main "Home" apps and data flow inside the same smartphone). Ironically, the most detested version of Gear would be the most fit in order to be used as an almost perfectly secure mobile wallet (no internet, no Tizen, no sim card and also few other special advantages which better to be kept from the public). So, the answer to the question could be Yes -- for people less than paranoid :) --, but difficult to achieve, because bitcoin world is still in its infancy.

Answer 6

Not unless it is open source.

Check out http://replicant.us (Free / Open Source Android)