In the quest to stop bad applications from doing damage to the data or operation of a phone (or running up large bills, or otherwise adversely impacting the phone network), possible approaches divide into two main routes:
- Put the main focus on checking and testing software (and the originator of the software) before it is allowed to be distributed or installed;
- Be permissive as regards the initial distribution and installation of software, but withdraw (or “revoke”) these permissions if it becomes clear that the software has bad effects.
It seems to be the consensus view that it is impractical (if not impossible) to reliably identify bad software by any prior checking system. These checks will always fail on at least one criteria:
- The tests will be insufficient to cover all usage conditions; applications which work well on some handsets on some networks may well go wrong on other handsets or other networks;
- Any attempt to make the tests more reliable will introduce unacceptable time delays and cost.
The best that an application checking system can hope to accomplish is a quick sanity test – to spot significant errors. Inevitably, this means that some bad software will slip through the system. As a result, any anti-malware system on mobile phones needs to consider at least some revocation component.
In principle, here’s what revocation could accomplish:
- The process of releasing software (including alpha and beta versions) could be relatively quick and painless;
- An application that is subsequently found to generate problems on phones could be removed from distribution lists and application stores, to prevent anyone else from installing it;
- Messages could be sent to all phones on the network with the effect that users who have already installed the application could be warned about these problems – and given the opportunity to uninstall it;
- In more extreme cases, these messages could cause the applications to be automatically uninstalled, without waiting for the approval of the user;
- In yet other cases, the developer who signed the application could be barred from signing any more applications – this could be appropriate in cases where the developer has been caught out making pirated zero-cost versions of commercial software.
This picture is attractive. However, we need to be aware that it relies on the existence of a “revocation infrastructure”. One part of this infrastructure is the reliable identification of an application. This is accomplished via tamperproof digital signing. However, this is only the start of what’s needed for revocation to work.
It was because of the lack of a developed revocation infrastructure that the original Symbian Signed scheme followed route 1 above – Put the main focus on checking and testing software (and the originator of the software) before it is allowed to be distributed or installed – rather than route 2 – Be permissive as regards the initial distribution and installation of software, but withdraw (or “revoke”) these permissions if it becomes clear that the software has bad effects.
Here are some of the issues with the mechanics of revocation:
- By default, checking at install time for revoked certificates is currently turned off for most (if not all) shipping Symbian phones;
- The user would in principle have to pay for the data traffic to check for revocation;
- Operators ought ideally to agree on something like a free dedicated access point which is supported across networks while roaming, etc., before it’s acceptable to turn this on for the majority of users;
- Revocation checking is done on most phones at software install time, there is limited current support for push revocation;
- If the revocation checking was defaulted to on, the user could still turn it off for most (if not all) devices;
- Software that deliberately or accidentally broke PlatSec partitioning of processes & data could disable the revocation check.
In addition, there are some issues with the policy of revocation:
- There is bound to be controversy over who has the authority to decide to revoke a certificate;
- Some applications that run without problems on some networks may cause problems to other networks; does this mean that revocation may need to be specific to individual networks?
- Some applications that users like and admire may be viewed as malware by other users;
- For example, users may have entered considerable amounts of data into an application, that is subsequently forcibly uninstalled due to being revoked; users may complain about no longer have access to their data;
- Some application writers may seek to contest decisions to declare their software as malware.
I’m not saying these issues are insurmountable. There are candidate solutions for all these issues. But I do want to point out that revocation has its own costs.
My own view nowadays is that even a partially working revocation would probably still be a better system than the current reliance on centralised testing of applications before they can be distributed.
By “partially working revocation” I mean a system that works by community reviews. Users who notice problems with applications would be encouraged to publicise these issues, so that the community as a whole can weigh up the evidence. Popular application stores would take this information into account in the material provided to describe the applications available for download.
In principle, users would be willing to pay money for a premium service from application stores, as follows:
- The application store remembers which users have downloaded which applications;
- If an application is subsequently deemed to be problematic (on, say, particular phones), then relevant users would be sent messages alerting them of this situation.
In some ways, this premium service would be akin to the anti-virus monitoring solutions that are already available from some security specialist companies – although the implementation mechanism would be different.
Note finally that I’m not advocating opening all functionality to all developers, without any vetting. I believe that functionality such as AllFiles, DRM, and TCB, still needs to be carefully controlled, and cannot fall under a system of “use until revoked”. One argument in support of this view has already been mentioned (point 6 in the list above of issues with the mechanics of revocation).
dw2 
You write:
In some ways, this premium service would be akin to the anti-virus monitoring solutions that are already available from some security specialist companies.
I have long believed that revocation handling is a role that the AV vendors are perfectly placed to fulfill in the Symbian environment.
There has always been a certain amount of ridicule on why there are probably more AV solutions for Symbian 9.x than viable viruses, but if the role of AV vendors could be extended to deal with revocations, this might give more legitimacy to their products, while at the same time requiring exactly the types of judgment calls that security firms are used to making on a daily basis.
This could probably be extended to policing different definitions of “malware” – e.g. company phones may be more restrictive about certain types of software than phones managed by an individual.
Anyway, there is an ecosystem here waiting to be developed…
Comment by Marcus Groeber — 28 December 2008 @ 9:33 am
Hi Marcus,
>"I have long believed that revocation handling is a role that the AV vendors are perfectly placed to fulfill in the Symbian environment…
>"Anyway, there is an ecosystem here waiting to be developed…"
Interesting thought!
I look forward to the ecosystem itself stepping forward to implement this kind of solution.
However, I suspect that such solutions will require some centralised changes too – changes that can only be made at the heart of the ecosystem (such as alterations to some core parts of Symbian Signed).
// dw2-0
Comment by David Wood — 28 December 2008 @ 12:23 pm
I think you might be interested in the following presentation ( Exploiting Symbian, Page 48 and following), in which an interesting way to exploit Symbian vulnerabilities is presented, so ingenious that not even a perfect revocation infrastructure could ever stop the malware that could be created with it…
Comment by Anonymous — 29 December 2008 @ 2:37 am
Hi Anonymous,
>“…an interesting way to exploit Symbian vulnerabilities is presented, so ingenious that not even a perfect revocation infrastructure could ever stop the malware that could be created with it…”
Wouldn’t this mechanism be defeated if the Publisher ID certificate being used to sign such malware was revoked (and if the personal credentials used to obtain this Publisher ID were barred from being used to obtain another ID)?
Here, I’m using the word “revoked” in the loose general sense of point 5 in my original posting:
“In yet other cases, the developer who signed the application could be barred from signing any more applications”.
// dw2-0
Comment by David Wood — 29 December 2008 @ 8:39 am
You’re right: if all software must be signed with a Publisher ID, this attack is not a problem. Thus, “Open Signed Online” should also require a Publisher ID…
Comment by Anonymous — 3 January 2009 @ 2:08 am
> In principle, users would be willing to pay money for a premium service from application stores…
Why? The vast majority of users today don't have a problem with malware (as I type, there still hasn't been any on Symbian OS v9). This seems like asking users to pay for making developers' lives easier (either directly with this app store surcharge, or indirectly by suffering malware) and that isn't a very attractive sales pitch!
I do think economics might provide an answer though, it's basic supply and demand – stakeholders who want more security should pay more for it, and stakeholders who want less security should pay less for it. Right now most users don't care about security; most developers actively want less; so who wants more?
Comment by Craig Heath — 21 January 2009 @ 5:00 pm
Hi Craig,
>"The vast majority of users today don't have a problem with malware (as I type, there still hasn't been any on Symbian OS v9)."
True, but the situation might change in the future, if the testing and other hurdles before apps can be signed are reduced (as many developers request).
If that change occurs, then a service such as I described in the main posting becomes more desirable:
“In principle, users would be willing to pay money for a premium service from application stores, as follows:
“*) The application store remembers which users have downloaded which applications;
“*) If an application is subsequently deemed to be problematic (on, say, particular phones), then relevant users would be sent messages alerting them of this situation.”
As you say, the interesting question is, who should pay for such a service?
This question applies more generally. It seems that, either way, there are costs to keeping networks and phones free from malware. Costs have to be borne, whether malware is policed by up-front testing or by retrospective revocation.
In the present setup, these costs are largely incurred by developers. I like your idea of exploring alternatives!
// dw2-0
Comment by David Wood — 21 January 2009 @ 5:50 pm