The Symbian Signed Story, Part 3

Symbian Signed costs reduced by open market for servicesDevelopers could choose between 3 test houses and 2 certificate authorities

And now, introducing platform security…

Platform security turned out to be quite well timed, as we can see from the graph in a previous post, The Mobile Malware Threat. The first malware written for Symbian OS, the Cabir worm, appeared in June 2004, and from that point on there was a definite trend of increasing numbers of malware strains. With hindsight, I would have liked platform security to have launched a year earlier so that we could have minimised the spread of the Commwarrior worm and its variants over MMS, as it did cause significant problems for network operators until they deployed filtering technology on their MMSCs (Multimedia Messaging Service Centres). It is, however, difficult to persuade customers that there is an imminent threat to security until after they have actually experienced it, and we did at least have the platform security architecture ready to roll.

The premise of Symbian OS platform security is that, somehow, trustworthy applications can be distinguished from untrustworthy ones, and that operations which might endanger security will only be permitted to trustworthy applications. This is further refined by the notion of capabilities which provide access to specific subsets of potentially dangerous operations and, along with that, the least privilege principle which says applications should only get the capabilities that they really need to do their jobs; in effect, “I will trust you this far and no further”.

Note that there’s nothing inherent in the architecture that says how a trustworthy app is identified, just so long as it can be done at the time the application is installed (see chapter 8 of my book for the full details). In practice, Symbian Platform devices are configured by their manufacturers so that the user can make that decision for some capabilities, and for other capabilities the app has to be signed by a recognised authority (that is, one that has a root certificate pre-installed in the phone).

By coincidence, one of the first things I did when I joined Symbian in January 2002 (I think it was in my first or second week) was to represent Symbian at a meeting of the JSR 118 expert group which was working on the Java MIDP 2.0 GSM/UMTS Recommended Security Model. I had some serious misgivings about the document but, as it was about to be published just when I joined the group, it was too late to do anything about it. It defined specific “protection domains” (trusted third party, operator and manufacturer) which had hard-wired special cases (operator-signed applications were supposed to stop working if you changed the SIM, and so on). This worked so poorly in practice, with different manufacturers and different operators interpreting the spec differently, that most independent software developers saw no benefit from having their MIDlets signed.

The way the Symbian Signed root certificates are set up is much simpler, and was intended to avoid the fragmentation that plagues signing programmes for MIDP Java. The Symbian Signed roots can grant any and all of the capabilities that control access to the Symbian Platform APIs, so a developer doesn’t have to consult a device-specific table of signing authorities and permissions to know where to submit their application depending on which APIs they want to use. That doesn’t, however, mean that any application submitted to Symbian Signed can do anything it wants; as part of the submission process you have to state which capabilities you want, and if you ask for dangerous capabilities then the criteria will be tougher than if you ask for relatively benign ones.

So, if you compare it to Java MIDP, platform security with Symbian Signed really wasn’t that bad! Inevitably though, when the first devices with the Symbian platform security architecture started shipping in March 2006, most Symbian developers compared it to Symbian OS before platform security where getting your application certified was an optional step. Now, if you wanted access to potentially dangerous APIs (such as those requiring WriteDeviceData capability, for example) you were forced to go through (and pay for) this certification process. I’m afraid this was a necessary change though; as seen in the graph of malware signatures linked to in the first paragraph above, malware was already a problem and it was only going to get worse if we carried on with the previous free-for-all access to all APIs.

One useful consequence of not hard-coding “protection domains” as in MIDP was that adjustments could be made to the criteria for certain capabilities simply by changing the Symbian Signed workflow without needing any changes to the software or configuration on the devices. In the next instalment I’ll cover some of the operational adjustments we made to try to ease some of the pain for developers.