Scott Kelly, platform architect at Netflix, gets to look at a lot of devices. In depth. He’s got some interesting things to say about smartphones. (At CanSecWest.)
First of all, with a computer, you are the “tenant.” You own the machine, and you can modify it any way you want.
On a smartphone, you are not the only tenant, and, in fact, you are the second tenant. The provider is the first. And where you may want to modify and customize it, the provider may not want you to. They’d like to lock you in. At the very least, they want to maintain some control because you are constantly on their network.
Now, you can root or jailbreak your phone. Basically, that means hacking your phone. Whether you do that or not, it does mean that your device is hackable.
(Incidentally, the system architectures for smartphones can be hugely complex.)
Sometimes you can simply replace the firmware. Providers try to avoid doing that, sometimes looking at a secure boot system. This is usually the same as the “trusted computing” (digital signatures that verify back to a key that is embedded in the hardware) or “trusted execution” (operation restriction) systems. (Both types were used way back in AV days of old.) Sometimes the providers ask manufacturers to lock the bootloader. Attackers can get around this, sometimes letting a check succeed and then doing a swap, or attacking write protection, or messing with the verification process as it is occurring. However, you can usually find easier implementation errors. Sometimes providers/vendors use symmetric enryption: once a key is known, every device of that model is accessible. You can also look at the attack surface, and with the complex architectures in smartphones the surface is enormous.
Vendors and providers are working towards trusted modules and trustzones in mobile devices. Sometimes this is virtual, sometimes it actually involves hardware. (Personally, I saw attempts at this in the history of malware. Hardware tended to have inherent advantages, but every system I saw had some vulnerability somewhere.)
Patching has been a problem with mobile devices. Again, the providers are going to be seen as responsible for ongoing operation. Any problems are going to be seen as their fault. Therefore, they really have to be sure that any patch they create is absolutely bulletproof. It can’t create any problems. So there is always going to be a long window for any exploit that is found. And there are going to be vulnerabilities to exploit in a system this complex. Providers and vendors are going to keep trying to lock systems.
(Again, personally, I suspect that hacks will keep on occurring, and that the locking systems will turn out to be less secure than the designers think.)
Scott is definitely a good speaker, and his slides and flow are decent. However, most of the material he has presented is fairly generic. CanSecWest audiences have come to expect revelations of real attacks.
