by Craig Heath

Reproduced by kind permission of John Wiley & Sons.

Prev. Contents

Crystal-Ball Gazing

Predicting the future is a very presumptuous thing to do, and the mobile phone industry as a whole seems to be rather bad at it – the enormous success of SMS text messaging came as a surprise to its developers, and, conversely, a lot of time and money was invested in WAP services, which were much less widely used than was predicted. Nevertheless, we thought it would be interesting to conclude this book with some speculation on how the security features of mobile phones and their associated services might evolve. For the record, this chapter is being written in October 2005; it may be proved wrong even before the book is published!

None of the content of this chapter should be taken as an indication that Symbian intends to offer such features in future releases of Symbian OS, or indeed that we are even aware of work going on in these areas – it merely reflects the authors’ interests and occasional flights of fancy.

Security is not an end in itself – it has been said that the best way to secure a computer system is to turn it off, encase it in concrete and bury it! That is certainly a secure system, but it is not suitable for doing anything useful. Security measures must be applied in order to enable useful functionality. Thus, to decide the future direction of mobile phone security, we need to consider how the use of mobile devices is likely to develop.

Convergence, Content and Connectivity

‘Convergence’, combining mobile phone functionality with that of other consumer electronic devices, is already happening: camera phones are ubiquitous; music player phones are starting to appear; mobile TV broadcasting to phones is on the horizon. These examples are all to do with adding content (mainly commercial entertainment content) to the mobile phone, but the primary raison d’être of a phone remains to connect the user with another person. [Odlyzko 2001] makes the argument that, even for the wired world of the ‘Plain Old Telephone Service’ and fixed-line Internet, consumers ascribe significantly more value to connectivity than to content – the highest-value application for the Internet being email. This not only indicates that mobile phone manufacturers should make sure that their devices continue to be very effective at making phone calls, but also that successful new functionality on mobile phones is likely to be that which assists people to connect with each other in various ways.

It is interesting to consider what other instances of convergence are likely to manifest in the future. One place to start that consideration is with what people typically carry along with them in their wallet, purse or bag – this could include:

keys
money
tickets
credit/debit cards
membership cards/licenses
loyalty cards.

For many people, the mobile phone has become the indispensable item they never leave the house without – this tendency is only likely to become more widespread in future. In a way, the mobile phone is becoming an extension of ‘self’, and there is an opportunity to offload tasks to the phone that people might otherwise use their brains for! This opportunity could be perceived as a risk; those who believe the advent of the pocket calculator was the death knell for the skill of mental arithmetic might similarly bemoan the tendency for people not to remember phone numbers any more, nor to remember appointments, nor their to-do lists – on the other hand, the more optimistic may view this as releasing brain capacity to do something more useful! (Incidentally, pocket calculators are another example of convergence, where the phone has subsumed another, previously separate, consumer electronics device.) Perhaps the most advanced realization of the mobile phone as an extension of human memory thus far is the Nokia Lifeblog software, which continuously records a diary created from photos, videos, and sent and received messages on the phone.

Returning to the ‘connecting people’ theme, there are interesting developments in the area of peer-to-peer (P2P) applications. This resonates with the perception of the mobile phone as an enabler of social networks; in some sense, your phone is a way of carrying around your social circle, friends and family in your pocket. P2P is primarily seen in the wired Internet world as a technology used for file sharing, and predominantly for entertainment content (legitimately acquired or more often not, via what is ominously referred to as the ‘Darknet’ [Biddle 2003]). There are, however, some rather more innovative possibilities for mobile phones, with the phone acting as a sort of social mediator, advertising your interests and ‘match-making’ with other P2P agents, leading to actual human contact by text, voice or in person. The social side of this is exemplified by a prototype application that is currently being distributed for Symbian OS-based phones, Nokia Sensor, which publishes a home page and selected pieces of content to other similarly-equipped phones within Bluetooth connection range and provides a way for like-minded individuals to make contact. It is likely that commercial use could be made of such social profiles too, for instance by transmitting targeted advertising based on the individual’s interests, although for some that may be a little too reminiscent of the obtrusive advertising portrayed in the Stephen Spielberg film ‘Minority Report’!

Services delivered on or to the mobile phone are likely to provide more of a ‘personal touch’ than similar services might do on a PC. Given the mobile phone’s association with the user’s social circle, it is easier to portray services on the phone as being friendly and helpful. Indeed, the mobility of the phone means that it is always (or mostly) available when it is needed, which will certainly contribute to the ‘helpful’ part.

Enabling New Services

Mobile Payments

Mobile payments are an area where there are already several competing standards and technologies. There are two main categories here, one being the use of the phone to pay for things when physically present (for example, groceries or bus fares) and the other being to pay for remote or intangible goods and services (for example, ordering books, downloading music, or paying for an extra life in a game). There is also interest in ‘micropayments’, amounts of perhaps fractions of a penny that are uneconomical to collect using established payment mechanisms such as credit or debit cards due to the per-transaction overheads.

One of the most interesting challenges is in allowing software running on the mobile phone to generate billing events. For example, protected content could be delivered to a mobile phone in anticipation of the content being used (perhaps a digital newspaper) and the rendering software could arrange for the user to be charged only for the content they actually use (pages actually read).

Symbian OS v9 has a security architecture that allows the operating system to distinguish between trustworthy and untrustworthy processes, but the billing system will be implemented in software running on a remote server – how will it know whether a billing request it receives originated from a trustworthy application or an untrustworthy one (or even if it was sent from a Symbian OS-based mobile phone, or some malware running on a PC)? The best mechanism, at the time of writing, appears to be to use premium-rate SMS numbers, as the application will have to be signed appropriately in order to send the SMS. But there is considerable per-transaction overhead involved (including for the mobile phone user, who may be paying a standard rate SMS charge simply for sending the message, on top of the amount going to the vendor). Establishing the trustworthiness of the source of a billing message is a similar problem to that facing DRM rights issuers establishing the trustworthiness of the recipient of rights – we will return to this later in the chapter when we discuss ‘remote attestation’.

Mobile Phone as Access Token

Referring back to our discussion of convergence in Section 10.2, one class of things we carry about with us is keys, whether the old-fashioned mechanical kind, or swipe cards or other forms of access passes. Aside from the convenience of not needing to carry keys separately from the mobile phone, and thus having one less class of things to remember to pick up when leaving home, the phone can provide an additional benefit – the ‘key’ can make sure it is being used by its legitimate owner rather than someone who stole it or just found it lying around. We discuss how the mobile phone might identify and authenticate the person holding it in the next section.

We can also consider the use of the mobile phone as an access token for remote network services – this is already possible to the degree that an Internet browser on the phone can cache passwords used to access web sites, but we can anticipate that this sort of functionality will become more sophisticated and more secure in the future.

Content Protection

The main security challenge in delivering entertainment content to mobile phones is, of course, digital rights management (DRM), or in other words, preventing unauthorized use and duplication of copyrighted content. DRM implementations are already deployed on mobile phones. Somewhat paradoxically, it is easier to protect content on simpler, lower-specification phones which do not allow add-on software, whereas the increased functionality of higher-specification phones which do allow add-on software may make an attacker’s job easier, by providing the means to access and make copies of protected content.

Several of the regular features of Symbian OS platform security architecture are helpful to DRM implementations. For example, data caging, which can prevent access to certain data (perhaps the content itself, or encryption keys used in turn to protect the content), and the capability model, which allows processes that can be trusted to respect the rights associated with protected content to be distinguished from untrustworthy processes. There are, however, a couple of security challenges with specific relevance to DRM solutions, which we will cover in the next section: renewability and remote attestation.

New Security Technologies

We are already seeing some security technologies being added to Symbian OS-based phones by Symbian’s licensees and successfully marketed to mobile phone users. Figure 10.1 shows the Fujitsu F900iC phone, which includes both biometric user authentication using a fingerprint sensor, and mobile payment functionality using a Near-Field Communication (NFC) technology developed by Sony called FeliCa.

Figure 10.1 Fujitsu F900iC

In some cases, new security functionality will be invisible to the phone user. This is appropriate where the security configuration is being managed by an entity that the user trusts, such as a network operator, or an enterprise IT department – increased security can be provided without burdening the mobile phone user with responsibility for making security decisions. In other cases, security functionality will be visible to the user, where the goal is to provide the user with more control. It may be appropriate to provide more control over financial costs or over the disposition of the user’s personal data, but developers still need to be careful not to increase the burden on the user. The default security policy should be carefully chosen to minimize the number of explicit decisions the user needs to make.

Renewability

Providing for ‘renewability’ is accepting the inevitable imperfection of any security solution. However much time and effort is put in to developing a security system, it is always possible that there is an attacker with more time and effort available (or perhaps many attackers whose cumulative time and effort exceeds that of the defender) who will be able to find a flaw in the system and exploit it. In the case of such a successful attack, one potentially effective response is to replace components of the security system with new ones – this particularly applies to secret and private keys, trust anchors (root certificates) and, in extreme cases, to entire cryptographic algorithms (both encryption and hash algorithms). This technique has been widely and successfully employed in what are called ‘conditional access’ systems, as used in set-top boxes providing Pay TV services. The keys used to protect services and content are regularly changed – in some cases they may only be used for a period of seconds, thus making it pointless for an attacker to spend any effort in discovering the key currently in use. As applied to mobile phones, our main challenge is to ensure that the renewal mechanism does not introduce security holes itself; to enable remote management of security, we must first ensure that we have security of management.

Remote Attestation

The topic of this book is a security architecture, implemented in software, that puts in place a number of controls designed to maintain and improve trust in the services provided in and via a mobile phone. You might legitimately ask the question ‘who guards the guardians’ (in the original, ‘quis custodiet ipsos custodes’ [Juvenal 100]) – how can any tampering with the logic of the security-enforcing code (the Trusted Computing Base) be detected? One relatively straightforward means of doing this is checking the integrity of the operating system image when it is loaded in to the mobile phone at boot time (otherwise simply known as ‘secure boot’). Secure boot is implemented in some mobile phones today, and detects attacks which reprogram the phone memory while the operating system is not running (such attacks may be attempted using commercially-available service hardware). A mobile phone with secure boot would, therefore, refuse to start up if it had been reprogrammed with an unauthorized operating system image. This helps improve security, but there is still a gap: a service running on a remote server may need assurance that the mobile phone it is communicating with (perhaps to receive billing messages or to deliver rights to protected content) is a genuine phone, running an integrity-checked version of the secure operating system. The operating system itself has no way of reliably reporting this to the remote server, as it is not able to tell the difference between legitimate hardware, with secure boot performing a successful integrity check, and a carefully crafted simulator running on some other hardware that merely reports plausible, but fictitious, results. (The philosophically inclined might like to ponder the analogous problem posed by [Bostrom 2003] – how can humans know whether they are real or simulations?) In order to remotely report the integrity of a piece of software, we need an independently authenticated trustworthy source to make the assertion – such functionality is known as ‘remote attestation’.

For remote attestation to be useful, it is necessary for the entity generating the integrity report to be more trustworthy (that is, better protected) than the software being measured. If it was no more secure it would be equally easy to attack and nothing would have been gained. In practice, this means that the reporting entity must be protected by hardware security mechanisms. The Trusted Computing Group (TCG) publishes a specification for a Trusted Platform Module (TPM) that has been implemented on several PC platforms in the form of a separate microcontroller on the motherboard. The TPM monitors the software running on the main processor, stores a record of integrity measurements, and contains an embedded private key that can be used to authenticate the reports that it generates. The TCG includes several working groups, one of which (the Mobile Phone Working Group) is working on a specification adapting the TPM concept to the specific needs and constraints of mobile phones. It is likely that the specification will allow a greater part of the TPM to be implemented as software on the main processor, but, as noted above, not all hardware security requirements can be removed as that would weaken the protection to the point that it provided no benefit.

Preventing Denial of Service

As Symbian restricts the damage that malware can do by implementing measures such as the security architecture described in this book, malware authors are likely to turn to other, less well defended avenues. One such avenue is to use Denial of Service (DoS) attacks. Denying access to a particular service is not likely to result in immediate damage to the end user, such as financial loss or loss of privacy, but such attacks can still result in significant inconvenience – they have been used, for example, as a means to blackmail service providers. DoS attacks, performed by software running on a mobile phone, are particularly difficult to defend against as the rogue process isn’t actually performing an operation it shouldn’t be allowed to – it’s just doing more than we would like it to (using more than its fair share of resources such as memory, file store, CPU, network bandwidth, battery power and so on). There are methods for addressing this – such as the concept of ‘quotas’ in multiuser operating systems, which prevent users consuming more than their allocated share of disk space – but the overhead of monitoring processes for such behavior makes them impractical for use on today’s mobile phones. Perhaps as phones become more powerful to support more demanding uses (3D games, video playback and recording) and battery technology improves to keep pace (perhaps using fuel cells), there will be sufficient spare capacity to implement such controls.

User Authentication

The increasing use of mobile phones to perform services on behalf of the phone user leads to an increasing need for the phones to be able to verify that, at a particular time, they are still in the possession of their legitimate user. Most mobile phones already have functionality for authenticating the user via a PIN, both for locking the user interface of the phone so that it cannot be used by others and for authenticating the user to the SIM in order to enable network functionality. Typically, the implementation of PIN checking is closely integrated with the function that it is protecting, and it is not possible for it to be used by other functions on the mobile phone. This can lead to the user having to remember several PINs for different functions, which is clearly an unnecessary burden when they all have the same essential purpose: to verify that the legitimate user is in possession of the mobile phone.

One way to address this might be to split off the authentication into a separate system service, which can then be invoked by the individual functions that need to check the user’s status.

The same authentication token (for instance, a PIN) could be used by several different functions.
The authentication service could ensure that, if the user has recently authenticated themselves, they are not immediately asked to do so again because a different function is being used.
The authentication service could also provide a single point for implementation of alternative authentication mechanisms.

One class of alternative mechanisms to the conventional PIN is biometrics (that is, measuring a physical characteristic of the user). Biometrics differ in their accuracy but, even if the absolute security is no better than a PIN, the improved convenience of, for example, swiping your finger over a sensor versus remembering a string of digits is likely to encourage wider use. A security mechanism which users choose not to turn on benefits nobody. (Biometrics include facial recognition, voice-print recognition and fingerprint recognition.)

Labeling

Sharing, or otherwise publishing, user data from the device – as we discussed in the context of P2P applications – gives rise to a number of concerns relating to user privacy. The most important property a security technology needs to address this is simplicity (referring back to Chapter 2, Section 2.1.2, this is the principle of ‘economy of mechanism’ [Saltzer and Schroeder 1975]). As we mentioned at the start of this section, we must minimize any burden on the mobile phone user, so that any decisions they are expected to make have the virtue of clarity. A clear decision point with clear consequences is likely to provide the user with a useful degree of control, whereas unnecessary complexity either results in a security feature not being used at all, or worse, used incorrectly.

One security technology that has a venerable history in security systems but is currently rather out of fashion is the notion of ‘labeling’. This has mainly been used in the context of multi-level secure systems implementing mandatory access controls to classified data – typically ‘classified’ in the sense of government or military security controls. Briefly, every object on the system (typified by a file, but also other collections of allocated data) has associated with it a label describing its sensitivity; this sensitivity label is then processed by the TCB to ensure that the data is only made available to processes that have the necessary clearance.

Instead of using such labels for mandatory access controls enforced by the TCB, they could be used in an advisory way to help trustworthy applications make the right decisions about what to do with a user’s personal data (including photos, videos, voice recordings, text notes, and so on). The system would simply need to ensure that the label stayed with the data as it was moved or copied around. Instead of using hierarchical classifications such as ‘Secret’, ‘Confidential’ and ‘Unclassified’, labels could be, for example, ‘Private’ or ‘Shared’. Such labels could subdivide the current set of data to which access is controlled by the ReadUserData and WriteUserData capabilities. Applications with those capabilities would be trusted to respect the advice of the labels, such as a file sharing application only sharing files with the ‘Shared’ label, and the contacts application refusing to transmit any contact marked as ‘Private’ from the device.

Going further, it might be possible in future to agree standards for transmitting these labels along with data when it is sent from the mobile phone, for example to a web site as part of making an e-commerce purchase. This could go hand-in-hand with privacy profiles, which would express the mobile phone user’s intent in supplying that data to the remote server (such as prohibiting it from being used for marketing purposes). There is an existing standard developed by the Platform for Privacy Preferences Project (P3P), but this works in reverse (the server tells the user what the privacy policy is) and the more sophisticated (and hence more interesting) features of the P3P specification are not widely implemented in browsers today.

Auditing

The final area where we may anticipate some additional security technology in mobile phone operating systems is in the area of auditing. In ‘traditional’ secure computer systems, there is a lot of attention paid to making sure that all security-relevant events can be recorded for future analysis, but somewhat less attention is paid to making sure that what is recorded can actually be made sense of. It seems to be forgotten that the word ‘auditing’ refers more to the analysis of data than it does to the recording of it.

Clearly, given the limited storage available on most mobile phones today, it would not be practical to record all security-related events just in case that log might prove useful in the future. Nevertheless, some means to analyze what it going on in the phone would be of considerable benefit in analyzing any security incident that occurred. Such data is almost certainly going to be meaningless to the majority of mobile phone users, but could be used by, for example, a network operator or enterprise IT department responding to a support call. It is, therefore, likely that auditing functionality would be mainly, if not exclusively, accessed remotely, perhaps using existing device management infrastructure. We want to stress again here though, that before enabling management of security, it is necessary to be confident of the security of management. It would certainly not be good if an attacker could turn on the audit log and effectively perpetrate a DoS attack, nor would it be good if an unauthorized entity could use the audit log to discover personal data about the user, authentication codes, and so on.

The hooks that would enable logging of security-related events could also potentially be used by security software running on the mobile phone, perhaps to detect abnormal behavior and raise an alert, or for other forms of intrusion detection.

Summary

This final chapter discusses some of the ways in which security technology on mobile phones may evolve in the coming years.

We considered how the use of mobile phones may evolve, as the purpose of new security technology should be to help people use their phones more effectively. This usage is likely to increasingly include the functions of other consumer electronic devices such as cameras, music players or TVs. New services are also likely to be provided on mobile phones, including payment services, use of the phone for access control to physical or network resources, and protection of digital content.

We concluded by examining some new security technologies which may be implemented on mobile phones to support these new uses and services: renewability, remote attestation, preventing denial of service, user authentication, labeling, and auditing.

We hope this book has proved useful, and that the Symbian OS platform security architecture will be a sound basis for both improving security and enabling more and better services to be provided by all participants in the mobile phone industry. By ensuring secure and happy users, we should all benefit!

Symbian OS Platform Security/10. The Servant in Your Pocket

Contents