12

Security Paradigm for Mobile Terminals

Edgar Auslander, Jerome Azema, Alain Chateau and Loic Hamon

As was highlighted in Chapter 1, the mobile phone has become a personal device that has strong potential to morph into a mobile wallet, or a mobile entertainment device. In both cases, merchants or service providers will want to bill for content or service provision. There lies an opportunity for fraud. When your phone only stores names of people you call, there is not much interest in hacking the device; when it contains your credit card information, however, a lot of energy will be spent trying to steal or hack your mobile phone. Telecommunication fraud has been documented already in the early days of the telegraph, though every attempt was then made to guard the secrecy of transmissions. There was clearly money to be made at the time by speculators if, for instance, they could find a way to transmit news from the stock market in, say, Paris, to other parts of the country faster than the daily papers. A curious case of fraud was discovered on the Paris to Bordeaux line. Two bankers, the brothers Francois and Joseph Blanc, had bribed the telegraph operators at a station just behind Tours to introduce a specific pattern of errors into the transmissions, to signal the direction in which the stock market was moving in Paris to an accomplice in Bordeaux. The telegraph operators near Tours received their instructions from Paris by ordinary (stage-coach) mail, in the form of packages wrapped in either white or gray paper, indicating whether the stock market in Paris had gone up or down. The fraud had been in operation for 2 years when it was discovered in August of 1836. With the advent of the Internet, many more spectacular frauds have been documented. A very good reference is Secrets and Lies: Digital Security in a Network World, by Bruce Schneier, Wiley Computer Publishing. Figure 12.1 illustrates that the mobile phone is likely to be the device that accesses Internet “the most”, making security an even more important mater. Figure 12.1 also illustrates that a mobile phone is potentially the most attractive personal billboard for advertisers; of course, users will not enjoy being bombarded with spam advertising, but subtle value-added advertising might be appreciated. The resulting personalized advertising or coupon gained via affinity programs might result in impulse purchase, at the touch of a button or a finger print on your mobile phone. This prospect motivates even further the industry to develop secure schemes for mobile commerce, what we call “the security paradigm for mobile terminals”. Mobile-commerce/security capabilities is a “must have” as an enabler of value added services. We will explore in this chapter some of the challenges presented by the wireless security issue as well as implementation choices.

Figure 12.1 Mobile phones connected to the Internet

12.1 Mobile Commerce General Environment

When the basic service delivered by mobile telephony was just voice, the value chain was relatively simple and people were billed per minute of usage, either via a subscription package or via a pre-paid scheme. With the possibility to deliver content, new players come into the picture: portal providers, content providers, application providers, mobile Internet service providers, payment processing providers and security providers. Carriers will have to decide the type of vertical integration role they want to play. We see evidence of several choices ranging from carriers outsourcing most roles (we even see the emergence of Mobile Virtual Network Providers (MVNOs), like Virgin Mobile, who lease a network and provide value-added services and brand-related innovations), to carriers who integrate content providers or packagers as illustrated by the recent acquisition of MP3.Com by Vivendi-Universal who also own the mobile operator SFR. The convergence of telecommunications, computing and entertainment will present new quality of service and intellectual property rights ownership and protection challenges.

The security issues that need to be addressed and solved in the mobile phone environment are:

• Confidentiality: ensure that only communication parties are able to understand the content of the transferred information.
• Integrity: ensure that information has not been altered during transmission: changes should not be possible without detection.
• Authentication: ensure that other communication party is who he/she claims to be.
• Non-repudiation: ensure that the sender cannot deny sending the message.
• consumer protection: pseudonym and anonymity.
• Protection against clone.

The security solutions generally examined are: encryption, SSL/WTLS, and Wireless Public Key Infrastructure (PKI). Encryption scrambles data according to an algorithm so that eavesdropping is made useless during transmission. Confidentiality is then achieved, but integrity, authentication and non-repudiation are not necessarily achieved. SSL/WTLS offers encoded connection and server authentication but non-repudiation is not achieved. Wireless PKI, combined with other techniques, provides digital signature over mobile networks and user/server authentication.

All the solutions, hardware and software, are based on asymmetric encryption techniques.

• The need for hardware based security solutions versus a software-only one is motivated by:
• a more difficult and expensive implementation to analyze;
• duplication is more challenging;
• tampering can be detected and the system can more efficiently react to a tampering attempt.
• End-to-end solutions (client and server).
• Stand-alone smart cards will not be able to support the full range of applications and in particular the one related to content protection. Because of the very limited processing and I/O speed of a smart card.

The three main types of applications have to be supported for products (i.e. three different industries and three different actors):

1. Secure e-transaction: make a financial transaction, i.e. pay a product and/or a service directly with a mobile phone. Being able to confirm identity is crucial in being able to bill the end user for the service. Public key technology combined with user identification and tamper proofing techniques are the backbone of wireless e-transactions.
2. Secure e-content: ensure the security of the platform for content and application software download (e.g. MP3 download, application software download, virus protection, copyrights and digital right management...). The main contents are:
   • – Application software: currently provided by handset manufacturers.
   • – Music and video: three solutions are today available on the market and have already been endorsed and used by the majors (Universal, Warner, EMI, BMG, Sony)
3. Secure e-billing: secure billing could be provided via a local solution running on the handset. This local solution will monitor and meter the usage of wireless data communications and will be fully controlled by the hardware based secure central billing system.

12.2 Secure Platform Definition

In order to provide the necessary level of security to the security layers of the chosen protocol stack (WAP or equivalent) and to the PKI system running on the mobile device, it would make sense to merge intimately the security elements within the existing platform as built-in features. A single fabric solution with a sharing of the computing resources seems effectively the best solution to offer a seamless integration of the security sensitive applications in the protocol stack with a minimum silicon cost penalty. Nevertheless, an integrated solution will lead to the introduction in the existing platform of specific software and hardware mechanisms to support the expected level of security.

12.2.1 Security Paradigm Alternatives

Building a secure framework is a complex task. Two approaches can be envisaged.

The first approach, which can be called “fine-grained security paradigm”, implies that a complex custom software “security manager” controls:

• Installed application code and data spaces.
• Security functions code and data spaces.
• Security functions upgrades.
• Application life-cycle management.

This approach has several disadvantages, and is not preferred:

• It requires complex software for dynamic allocation of code and data.
• It requires complex hardware for functions and data boundaries monitoring.

The second approach, which can be called “coarse-grained security paradigm”, implies that the fine-grained security is left to the Java based solution, and that the custom “security manager” implements coarse-grained security for security functions and security system.

This approach has several advantages:

• Hardware complexities are much reduced.
• It is not necessary to track functions for security, which removes much software complexity.
• Code downloads that do not go through the Java environment are restricted to security downloads and are easier to control.

This second approach is the one preferred. The secure platform software component is a Java based solution, and is responsible for the fine-grained security. The security manager of the hardware based component is responsible for the coarse-grained security.

12.2.2 Secure Platform Software Component

The secure platform software component is responsible for overall system dynamic software security:

• It provides access to a service controller for applications.
• It opens connections from the service controller to particular services (keyboard, LCD, cryptography).
• It manages the request between applications and services.
• It manages the service sharing or exclusivity.

It is also responsible for application life-cycle management:

• Download
• Initialization
• Installation
• Registration
• Inter application firewall

The software component role and advantages will be detailed in Section 12.3.

12.2.3 Secure Platform Hardware Component

The secure platform hardware component solution will be detailed in Section 12.4.

12.3 Software Based Security Component

12.3.1 Java and Security

Java technology offers crucial benefits for portability and safety:

• A well-defined semantics independent of the hosting processor/Operating System (OS): a Java program will always behave exactly in the same manner whatever the host device processor and OS.
• A completely typed intermediate code (byte-code) that can be verified: verified Java code cannot break complete typification and, as a consequence, cannot forge pointers and manipulate memory or go beyond limits of data structure and thus access freely the memory. Java can provide perfectly safe software firewalling, without any help from the OS or the hardware (no memory management unit or microprocessor needed).
• Data built by a Java application cannot be accessed by another application if stored in object fields, except exported static fields.
• The memory is automatically freed once used, with the included garbage collection.
• The Java virtual machine includes embedded byte-code verification mechanisms. Moreover, classes loaded through the network are stored in separated space from local classes.

For all these reasons, the security software component will use Java language.

12.3.2 Definition

The secure platform software component is a Java Application Environment (JAE). It provides a complete Java API to program applications. This JAE is built as a profile on top of a CLDC configuration (KVM), which is the smallest configuration defined in the family J2ME proposed by Sun for embedded devices.

This component offers a multi-application framework in which applications can be integrated via download. As a framework, it should define an exhaustive set of device services. It defines device services needed to perform secure transactions, such as payment, identification, cryptographic services, secure storage services, but also services needed for distant connections using Internet or WAP based protocols.

The security features built into the software component design are important not only for secure transactions but also to control other kinds of applications that could be installed on the device besides secure transaction ones, such as games, etc.

12.3.3 Features for Security

12.3.3.1 Access Manager

The central feature of the secure platform software component is the concept of “access manager”. When launched, an application using the secure platform security API gets from the shell an AccessManager object. This object is personalized for the particular application that receives it. An application cannot access directly any device service or peripheral. The access is made in two steps:

• First, the application has to ask its personal access manager to provide a “service control” for a particular kind of device service. The access manager can reject this request if the application has not the rights associated to the use of this kind of services (e.g. an application may not be allowed to use cryptographic service).
• If the access manager provides a service control object, this is not yet an access to a device service. The service control object, which is an emanation of the access manager, has then to be connected to a particular device service of the correct type. The control can deny the access to a particular service if the application has not the right to use it (for instance, an application can have the right to access a customer smart card slot but not some other smart card slots internal to the device).

The advantage of this approach is that it allows an efficient and easy to implement control of applications.

A classical alternative is to have the services protecting themselves from their clients, checking for each of the methods they export the right of their caller, which has to be identified then by scanning the call stack, to use this method. This is what is done in full Java: each method of the API has to call the so-called “security manager” that retrieves on the call stack and checks the right of the caller. This approach has proven to be very difficult to achieve a flexible and complete security, and moreover requires too many dynamic checks.

The secure platform approach delegates this security control to a gatekeeper, the “access manager”, personalized for each application, which allows a flexible fine tuning of the security control that has not to be implemented by the device services themselves, but by the shell. The alternative provided by the secure platform is more flexible, easy and also efficient as it requires no scanning of the call stack.

12.3.3.2 Indirect Access to Services

The secure platform software component is characterized by the indirect access to services. An application is never allowed to get a direct reference on a service implementation; it can only handle service controls that can only be connected themselves (i.e. have a communication channel) to a service implementation. With this approach, an application has no way of knowing the real implementation and API of the service it uses, it can only communicate with it through the fixed API provided by the control. This is important both for portability of applications and security of the hosting device. A second advantage is that the secure platform software component can manage through the service controls the sharing of device services. Most of these services are of exclusive use, i.e. cannot be used simultaneously by two concurrent applications. This can be translated by the fact, easy to verify by secure platform software component implementation, that these services cannot have a communication channel with two service controls simultaneously.

12.3.3.3 Asynchronous Communication

All the communication from the application to the device services, via service controls, is made exclusively through asynchronous requests, and the communication from device services to the application via events. The secure platform software component distinguishes two kinds of events: completion events indicating the completion (or abortion) of a task launched by an asynchronous request, and status events, used by the services to alert spontaneously their client of some change of situation. More generally, the choice of an event-driven style of programming allows to naturally take into account device services that are not local to the hosting device but can be remote and, as a consequence, with unpredictable time of answer (distributed platform: e.g. connected wireless). In addition, the use of status events allows the application to react immediately to unexpected events.

12.3.4 Dependency on OS

The dependencies between the secure platform software component and the hosting device OS are very weak. In fact, with the exception of the access to peripheral drivers almost no interaction with the OS is needed.

The secure platform software component should control its security with respect to downloaded applications and the security of the applications themselves entirely on its own and independently of the OS.

The only case where a secure platform software component platform relies on the OS for its security is for protection from the attacks of non-certified native applications that would have been downloaded. If there are such applications, the isolation of the software component in its own secure environment via secure storage should be required from the hardware based security component.

12.4 Hardware Based Security Component: Distributed Security

The distributed security is an optimized combination of selected hardware blocks together with a protected software execution environment. In this application, the platform processor will host the security application. A partitioned “secure mode” will be created so that it operates as a separate “virtual security processor” while it is executing security operations. A set of critical security blocks, such as crypto-processors, can be added to the peripheral bus of the processor with an access restricted to the sole secure mode operation.

The main assumptions, which guided the implementation of distributed security, are:

• All re-writable software in the system must be considered originally as un-trusted.
• The operating system is un-trusted

12.4.1 Secure Mode Description

A secure mode processing means creating an environment for protecting sensitive information from access or tampering by un-trusted software. It relies on the presence of special purpose hardware creating a boundary between services that trusted software might access, and those that are available to any code.

Typically, the services controlled by the secure mode hardware are sections of memory. Mainly:

• Program ROM
• Program RAM (optional)
• Secure storage RAM
• Root key store

However, by extension, that control can also be used to place I/O devices (such as a keypad, LCD, touch-screen, smart card) inside the secure boundary by protecting access to I/O or memory-mapped registers. In any case, the hardware resources must be linked together by proper control of the software itself. That is, there can exist no possible flows by which un-trusted code can either fool the hardware into allowing it secure mode privileges, or get trusted code to perform tasks it shouldn't.

If the boundary is properly created, there should be no way to utilize the normal operation of the processor to move information from inside the boundary to outside, except through controlled operations. For example, an operation may be provided to decrypt a message, and the operation may return the plain text result for use by un-trusted software, but there should be no way to view the keys used to do the decrypting.

Note that normal operation of the processor includes executing flawed “user-mode” software, which for example might corrupt the process call stack or overflow a variable boundary. Depending on the potential cost of compromise, additional mechanisms beyond the implementation of secure mode may be required to protect against abnormal operation of the processor. These mechanisms can be protective to prevent tampering or reactive to inform of a tampering attempt and generate an appropriate response.

12.4.1.1 Secure Mode Activation

The security manager is running in supervisor mode with an additional privilege level granted by the secure configuration bit, which can be viewed as an outer privilege level encompassing the processing unit sub-system.

The security manager and the standard secure routines from the secure library are resident and located in the embedded program ROM. Thus the corresponding code can be considered as trusted.

On user application call to a security function through a dedicated API of the OS, the OS will branch to the single entry point of the security manager. This single entry point allows control of the activation of the secure mode and the access to the secure resources. The OS using the normal procedure will handle the saving of the system context.

The first task of the security manager will be to mask all the interruptions. After executing the sequence of instructions that prevents any preemption of the secure mode privilege by un-trusted software. Hardware based state-machine spying of the fetched instruction address will set the secure bit to grant the access to security dedicated resources and to restrict concurrent access from other processors to shared resources.

Two strategies are offered:

1. Disabling the program and data cache, which has the advantage of easing the procedures of entry in and exit from secure mode with the drawback of lower processing performances.
2. Enabling program and data caches with the consequent improvement of processing performances at the cost of an increased complexity of the entry and exit procedures. One needs to insure that instructions fetched during entry procedures are effectively executed and that a proper cleaning is achieved on exit.

Note: the root key store must be located in a non-cacheable section.

12.4.1.2 Interrupts Management

If interruptions are allowed in secure mode, the security manager must take over the handling of all the interruptions. The management of interruptions in secure mode requires handling all interruptions over the secure mode. An indirection table for interrupt vectors is located in the secure ROM in order to control the application call.

On interrupt occurrence in secure mode, the security manager will save context in a private stack stored in the secure storage RAM. It will clean all the registers and the secure bit will be released before giving back the hand to the OS.

If interrupt occurs in non-secure mode, then the program will directly jump to the OS, which will manage the context saving with the normal procedure. The interruption of a secure application with another secure application will require a complex management of the secure stack stored in the secure storage RAM (i.e. use of session keys for temporary encryption of application related data).

12.4.1.3 Secure Mode Configuration

The secure mode configuration is set with the secure bit. This bit is controlled by a hardware state-machine, which has the following features:

• Spying the program address fetched.
• Control the integrity of the entry sequence starting from the single entry point.
• Set and release the secure configuration bit.

The logic must not be scanable to prevent any tampering attempt to set the secure bit out of the secure boundary of the security manager.

Access Control to Security Dedicated Resources

The processor will have access to the secure components when only in secure mode.

Secure components considered are:

• Secure program ROM. This ROM element can be partitioned to allow access to one area by the processor in secure mode only and to another area in regular mode. The access control will be only valid from the security manager entry point. The boot area will be free access.
• Secure program RAM (optional). Dedicated to the execution of non-resident secure applications downloaded from external FLASH device.
• Secure storage RAM
• Key root store

Access Control to Shared Resources

While in secure mode, the concurrent access to the shared peripherals must be prohibited. Components considered are:

• MMI peripherals (keyboard, LCD, FPR sensor)
• Smart card physical interface
• Crypto-processors (optional)

Additionally, the emulation capability or any test mode configurations must be prohibited thus requiring disabling of the embedded JTAG TAP controller. Note that in emulation mode, the secure mode cannot be entered.

12.4.1.4 Impact on OS

The OS manages the calls to the “security API”. Collaboration between the OS kernel and the security manager is mandatory. The aim is to minimize the modifications to the OS and keep them as generic as possible. If the secure mode needs to be exited through interruption, it will impact the interruption management of the OS with the necessary use of indirection tables.

12.4.2 Key Management

Key management is the main feature to consider when building a secure system. The compromise of key material is the most dangerous fault in a security system since it can allow an adversary to attack a system silently. The key management combines the secure library functions with the proper hardware protection logic to safely generate keys, use these keys and store those keys outside of the security boundary without compromise. This allows a large number of keys to be used in the system, without requiring a large amount of protected key storage RAM in the device.

The main tasks of the key manager are:

• Key generation
• Key storage
• Key usage control
• Key archiving and recovery
• Key hierarchical ring

The key management scheme must allow system applications to build their own key management mechanism. A hierarchical key structure allows multiple applications to share a single cryptographic library, while keeping the keys separate. User identification data such as PIN or FPR are used as input data of the key management system for authentication purpose. The key management system should not be intrusive on the system and must not cause performance degradation on traffic encryption or other time-sensitive tasks.

12.4.2.1 Key Generation

The robustness of the keys generated is highly dependent of the randomness of the output data generated by the Random Number Generator (RNG). A truly entropy driven RNG must rely on a hardware based RNG device.

The key generation will be run in the secure mode under the control of the security manager. The secure library incorporates a full set of symmetric and asymmetric key generation commands. Asymmetric keys (public keys) are generated according to the existing standards like X9.42/X9.43 and PKCS

12.4.2.2 Key Encryption

The confidentiality of the keys and certificates stored off-chip relies on their encryption with a symmetrical algorithm using the device permanent root key. AES algorithm should be favored for its robustness and key/block sizes flexibility. Triple-DES algorithm is also possible.

12.4.3 Data Encryption and Hashing

The encrypted data baud rate expected in mobile equipment is not in the same order of magnitude as the one required for networking applications. Consequently, the choice of a hardware implementation versus a software implementation must not be considered as the prime criterion (Table 12.1).

Table 12.1 Recommended cryptographic algorithms

A main criterion to consider for a hardware implementation of a crypto-algorithm is the best level of protection offered by a crypto-processor because the host processor does not have access to the keys.

However, the secure boundary offered by the proposed secure architecture with dedicated program and data memories to run the secure applications is tending to a software implementation of the crypto-algorithms as long as the processing time is acceptable at the application level.

The choice of hardware versus software implementation of crypto-algorithms is also dependent on the type of devices and these will be discussed further in the later sections of this chapter.

12.4.4 Distributed Security Architecture

12.4.4.1 Secure Components

Program ROM

The secure mode firmware is executed from an embedded ROM. Thus no authentication of the security software is needed. Additionally, ROM is offering a greater density than RAM and consequently a better silicon area versus capacity ratio. The ROM will contain the security manager and the secure library in addition to the processor boot session and indirection interruptions table.

The size of the ROM is expected to be in the range of 64–128 Kbytes depending mainly of the secure library specification.

Program RAM (Optional)

There may be a need to extend the security software for adding more algorithms or other custom secure applications, such as the software based security component described earlier. The corresponding program code will be stored off-chip in an encrypted form and downloaded in the program RAM. Before any execution, the security manager will be required to authenticate this extended software with its digital signature (HMAC). This extended software will execute equally in the secure mode.

Secure Storage RAM

Eight Kbytes of secure embedded storage RAM will be used for:

• Key material generation.
• Dynamic key storage.
• Data encryption or hashing, using symmetrical or asymmetrical keys.
• Manage secure data (private stack, scratchpad...).

This RAM will allow the security manager to create a secure run-time environment for building its own stack space, scratch RAM, and a heap for big-number mathematical operations to support asymmetrical algorithms. The security manager supports the procedure of “clean-up” of the stack and scratch areas of any key material to prevent any potential accidental key material leakage between different secure applications.

Non-Volatile Root Key Store

The non-volatile storage of the root key is based on electrically programmable fuses. The programming of these fuses is done subsequently to the fabrication process of the chip from a value generated from the embedded RNG.

Additional fuses can be used for a device personalization (custom application, test device...).

Die Identifier

A device identifier or die ID is provided as a seed for the generation of a bound key. As a result of the hashing of this die ID and of an application key, this bound key will be used to bind an application firmware to the physical platform through the encryption of the firmware and the creation of its HMAC.

The die identifier is a 64-bit word based on electrically programmable fuses. It is programmed at silicon manufacturer factory level.

Randomizer

The randomizer generates the seeds for hashing, encryption and key generation. It is based on a true RNG, which can be associated with additional logic to guarantee the generation of an unbiased output (i.e. to a von Neumann hardware corrector).

12.4.5 Tampering Protection

They are several techniques for attacking a security system:

• Physical modifications to the device or its external interface.
• Modification of programs running on the device.
• Environmental attacks on power, clock or emissions.

The device must provide a resistance to the static and dynamic observation of internal data and to the modification or alteration of these data. The level of tamper proofing must be balanced with the impact of the disclosure of the secret data to the attacker (implementation cost versus tamper consequence). The ultimate goal is to keep a device secure even if attackers carried out a successful tampering attack on another device from the same class and to make the attacked device out of service after the tampering attack (destructive tampering).

12.4.5.1 Tamper Resistance

The first level of tamper resistance must be integrated in the secure system architecture itself. The recommended rule is to bind the embedded secrets to the device itself. The acquaintance of the secrets does not allow tampering with another device. This level of system resistance relies on a hierarchical key ring structure with each key ring level secured by the level below (i.e. encryption of the private key of the key pair of one level with the public key of the underlying level). The root level is based on the “root” or device key.

When operating in secure mode, the JTAG access to the on-chip emulation logic of the processors must be disabled, thus preventing any external possibility to take the control on the OS execution. Any other modes of observation of internal data transfer on external ports of the device must be prohibited.

The use of a PLL to provide the system clock to the processors prevents any manipulation of the clocks. The configuration in bypass mode of the embedded PLL cell must be prohibited when operating in secure mode.

The resistance to crypto-analysis relies on the prevention of an analysis of the electronic trace (i.e. current based). A first level of resistance can be reached with a binary balancing of the data content when accessing sensitive data in memory elements. A complementary mean is a shielding against electromagnetic analysis (i.e. coating in package material).

The use of complex techniques, such as logic scrambling, bus interleaving or dummy logic, for a resistance to a structural analysis of the device layout is of no interest if the means used to lead the analysis are destructive and the acquaintance of the disclosed information not usable to tamper with another device of the same class.

12.4.5.2 Tamper Detection

The tamper detection is based on the evidence of a physical attack resulting in physical sense. This evidence can be based on active means like sensors – temperature, voltage, ionization – or passive means like embedded conductive grid in device package for the detection of open or shorts created by an opening attempt. The appropriate selection of the means must be suited to the targeted security level based on FIPS 140–1 specification.

12.4.5.3 Tamper Response

The tamper response must erase the content of the volatile elements, namely sequential elements and RAM memories. The erasing of the encrypted secret stored in the FLASH can be considered with the appropriate sector erase command. In this case it should be noted that the efficiency of the tamper response is limited by the latency of the flash erase sequence. The tamper response must be adapted to the possibility of the system to reuse or not the confidential data after this response. This tamper response can be managed on two levels:

• Zeroization with the reset of the confidential data contained in the device.
• Activation of an erasure routine of the protected RAM content and asynchronous reset of the sequential elements of the processors and the secure peripherals.

The erasure of the RAM can be software based (controlled by the processor) or hardware based with the use of the BIST controller if it exists. The PLL will be forced in free run mode to maintain the system clock whatever the possible forgery of the external clock source.

The possibility to keep a status flag of the tampering attempt, voluntary or non-voluntary, can be of main importance for the secure system to take a decision after the zeroization sequence.

It does not matter whether the tampering attack leads to the definitive destruction of the device preventing its further functional operation or whether the tampered data will be renewed anyway when reactivating the secure protocol. Again, this is true only if the acquaintance of the disclosed information does not allow tampering of another device of the same class.

12.5 Secure Platform in Digital Base Band Controller/MODEM

The Digital Base Band controller (DBB)/MODEM is the real central security device of mobile phones. This device has to support secure e-transaction and secure e-billing applications.

It is, application wise, a closed environment, which means that it is not allowed to download on it new native applications. The phone manufacturer itself certifies the applications present on the DBB (often called legacy applications). Nevertheless, it is possible to download on the DBB data such as media files (video, audio – for example ringing melodies). The DBB will then handle some multimedia tasks, so it will have limited e-content applications support.

The DBB central processor is generally already loaded with communication protocol and IO management, so to avoid bandwidth limitation due to cryptographic calculations, hardware accelerators could be preferred for:

• Asymmetrical key generation
• Symmetrical key generation
• Data and key encryption
• Hashing

According to the level of security required by the application, the generated keys that must be stored off-chip can be sent to the SIM/smart card, or to the external flash. In any case, the key stored will be covered (or wrapped) with a device permanent root key, which will never be exported from the DBB.

12.6 Secure Platform in Application Platform

The application platform will be added in hi-end phones as a complement to the DBB controller, to handle complex hi-speed multimedia tasks, such as streaming audio or video.

The application platform, compared to the DBB, is an open environment, which means that it is possible to download data and applications on it. Some of the downloaded applications could involve financial transactions, so this device will have to support secure e-transaction plus e-content applications.

Since the application platform is an open environment, special attention needs to be paid to the application download, installation, certification, registry and control. The secure platform software component will handle these features.

The application platform offers generally high processing power, and it offers flexibility in terms of software implementation of cryptographic algorithms. As long as the processing time is acceptable at the application level, the software solution is interesting.

According to the level of security required by the application, the generated keys that must be stored in permanent storage areas can be sent to the external flash. In any case, the key stored will be covered (or wrapped) with a device permanent root key, which will never be exported from the application platform device.

For any data exchange between the application platform and the DBB, a secure communication must be established by using Internet Layer Security Protocol (IPSec) or Transport Layer Security (TLS, SSL, WTLS), or by using proprietary protocols. It should be possible, once this secure link is established, to transfer for example certificate and keys from the application platform to DBB.

12.7 Conclusion

Mobile commerce can only happen in a trusted environment; you put your money in a bank because you trust the bank. A trusted environment can only exist when the appropriate legal framework and proven technologies are in place and advertised as such. Content download, transactions, and billing have to be reliable and fair to users, merchants, banks, as well as content authors and owners. No system is unbreakable though. We just believe that the modern PKI techniques we described, implemented with smart key management and a combination of software and hardware, are up to the “trusted security” challenge: hacking attempts would be far too costly, or even unreasonable, both in terms of time and money.