27 December 2008

Revocation infrastructure

Filed under: revocation, Symbian Signed — David Wood @ 1:30 pm

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:

  1. Put the main focus on checking and testing software (and the originator of the software) before it is allowed to be distributed or installed;
  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.

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:

  1. The process of releasing software (including alpha and beta versions) could be relatively quick and painless;
  2. 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;
  3. 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;
  4. In more extreme cases, these messages could cause the applications to be automatically uninstalled, without waiting for the approval of the user;
  5. 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:

  1. By default, checking at install time for revoked certificates is currently turned off for most (if not all) shipping Symbian phones;
  2. The user would in principle have to pay for the data traffic to check for revocation;
  3. 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;
  4. Revocation checking is done on most phones at software install time, there is limited current support for push revocation;
  5. If the revocation checking was defaulted to on, the user could still turn it off for most (if not all) devices;
  6. 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:

  1. There is bound to be controversy over who has the authority to decide to revoke a certificate;
  2. 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?
  3. Some applications that users like and admire may be viewed as malware by other users;
  4. 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;
  5. 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).

Blog at WordPress.com.