Mobile platform security by wulinqing

VIEWS: 49 PAGES: 12

									  Mobile platform security
  Christian Gehrmann and Per Ståhl




End-user expectations regarding features in mobile phones have                                      where digital rights management (DRM)
increased dramatically in recent years, not the least where security func-                          functions come into play. However, DRM
tionality is concerned. End users, operators, and content providers take it                         mechanisms alone cannot provide all neces-
for granted that the mobile platform will protect all vital information in and                      sary security. To provide a DRM solution
about a mobile phone. And Ericsson is proud to say that thanks to robust                            that meets content provider requirements,
                                                                                                    the mobile phone platform must contain se-
security mechanisms and rich, basic-platform-security functionality, its
                                                                                                    curity functions that guarantee secure exe-
new generation of mobile platforms fully lives up to these expectations.                            cution and code integrity.
   The authors describe the hardware and software security architecture                                Security is usually measured in terms of a
and building blocks implemented in the new mobile platforms. In particu-                            set of basic aspects: confidentiality, integri-
lar, they describe “core” security functionality such as secure boot,                               ty, authentication and authorization. Con-
secure reprogramming, and the protection of critical parameters.                                    fidentiality of data is achieved by crypto-
                                                                                                    graphically transforming original data,
                                                                                                    often called, plaintext, into cipher text,
                                                                                                    which hides the content of plaintext. This
Introduction                                      as viruses and Trojans, or weak or misbe-         operation is realized as a parameterized
                                                  having security mechanisms.                       transformation that keeps the controlling
The term security lacks meaning until one            The second class of stakeholders, mobile       parameter secret. The controlling parame-
has defined what is to be secure and for          network operators, relies on phone network        ter is often called a key. The transformation
whom. Likewise, security is difficult to com-     identification mechanisms (related to             is called encryption. With a key it is easy to
prehend without a potential threat. Mobile        billing capability) and network-related soft-     perform the inverse transform or decryption.
phones for third-generation mobile systems        ware. Users or hostile software must not be       Without the key, decryption should be dif-
(3G) have several security stakeholders for       allowed to circumvent these mechanisms.           ficult.
which the mobile platform must provide se-        Operators thus require that the integrity of         Integrity is about ensuring that data has
curity services. Moreover, the potential          software can be guaranteed when the mobile        not been replaced or modified without au-
threats may differ from stakeholder to stake-     phone is in operation. They also want to be       thorization during transport or storage. This
holder.                                           certain that users cannot break SIM lock          is achieved using cryptographic transforms
   The first class of security stakeholders,      mechanisms.                                       and a key. Additional information must also
users, expects that mobile phones will offer         A third class of security stakeholders, con-   be added to the plaintext to verify its in-
secure and reliable communication – that is,      tent providers, wants to be paid for the con-     tegrity.
they assume their phones can be trusted to        tent (music, pictures, videos and software)          Authentication is the procedure by which
handle sensitive tasks, such as e-commerce        that users download. It also wants to know        a unit (the claimant) convinces another unit
transactions. The main threats to this class      that users cannot (mis)use their phones to        (the verifier) of its (correct) identity. Au-
of stakeholders are malicious software, such      illegally copy or distribute content. This is     thentication is different from authorization,


  BOX A, TERMS AND ABBREVIATIONS


  2G         Second generation                     HMAC      Hash calculation, MAC calculation      ROAP  Rights object acquisition protocol
  3G         Third generation                      IEEE      Industry of Electrical & Electronics   ROM   Read-only memory
  3GPP       Third Generation Partnership                    Engineers                              RNG   Random number generator
             Project                               IKE       Internet key exchange                  RSA   Rivest, Shamir & Adleman
  AES        Advanced encryption standard          IMEI      International mobile equipment         SAT   SIM application toolkit
  AKA        Authentication and key agreement                identification                         SATSA Security-and-trust-services API
  APDU       Application protocol data units       IP        Internet protocol                      SHA-1 Secure hashing algorithm 1
  API        Application program interface         IPDC      IP device control                      SIM   Subscriber identity module
  CA         Certificate authority                 IPsec     Secure IP                              SMS   Short message service
  CBC        Cipher block chaining                 ISMA      Internet Streaming Media Alliance      SRTP  Secure real-time transport protocol
  CID        Customer ID                           MAC       Message authentication code            SSL   Secure sockets layer
  CMS        Cryptographic message syntax          MBMS      Multimedia broadcast/multicast         TCP   Transport control protocol
  CPU        Central processor unit                          service                                TLS   Transport layer security
  DES        Data encryption standard              MD5       Message digest 5                       UICC  UMTS integrated circuit card
  DH         Diffie-Hellman                        OCSP      Online certificate status protocol     UMA   Unlicensed mobile access
  DRM        Digital rights management             OMA       Open Mobile Alliance                   UMTS  Universal mobile
  DSP        Digital signal processor              OS        Operating system                             telecommunications system
  DSS        Digital signature standard            OTA       Over the air                           USB   Universal serial bus
  DVB-H      Digital video broadcast - handheld    OTP       One-time programmable                  USIM  Universal SIM
  EAP        Extensible authentication protocol    PIN       Personal identification number         VPN   Virtual private network
  EICTA      European Information &                PKCS      Public key cryptography                WAP   Wireless application protocol
             Communications Technology                       standard/system                        WCDMA Wideband cell-division multiple
             Industry Association                  PKI       Public key infrastructure                    access
  GPRS       General packet radio system           R&D       Research and development               WIM   WAP identity module
  GSMA       GSM association                       RAM       Random access memory                   WLAN  Wireless local area network

Ericsson Review No. 2, 2006                                                                                                                     59
                                                                                             rithms are also called message authentica-
                                                                                             tion codes (MAC). The most popular MAC
                                                                                             is the HMAC algorithm.1 Because the key
                                                                                             in symmetric mechanisms can be used to de-
                                                                                             crypt content, it must be kept secret from
                                                                                             all but legitimate users of the encryption
                                                                                             scheme.
                                                                                                Asymmetric mechanisms use separate
                                                                                             pairs of keys for encryption transform and
                                                                                             decryption transform. The public key can be
                                                                                             made publicly available, but the private key
                                                                                             must never be revealed. Asymmetric mech-
                                                                                             anisms are typically used for distributing
                                                                                             keys (for example, a symmetric key) or for
                                                                                             digital signing purposes. A public key can
                                                                                             be used to encrypt a symmetric key, which
                                                                                             in turn, can only be decrypted by the legit-
                                                                                             imate receiver using the corresponding pri-
                                                                                             vate key. A private key may also be used to
                                                                                             digitally sign data. The signature can be ver-
                                                                                             ified by anyone who knows the correspond-
                                                                                             ing public key. The RSA scheme is widely
Figure 1                                                                                     known example of an asymmetric crypto-
View of platform security hardware.                                                          graphic algorithm.
                                                                                                Ericsson has designed the security archi-
                                                                                             tecture of its mobile platforms to meet the
which is the process of giving a person or      Examples of symmetric confidentiality        security requirements of different stake-
entity permission to do or have access to       mechanisms are                               holders. The architecture is built around a
something.                                      • block ciphers, such as DES and AES; and    combination of hardware and software com-
  There are two major classes of crypto-        • stream ciphers, such as the GSM A1, A2     ponents that support the implementation of
graphic mechanisms: symmetric and asym-           and A3 algorithms.                         mechanisms that provide security. The main
metric. In symmetric mechanisms, the same       Integrity is often protected using symmet-   security functions are
key is used for encryption and decryption.      ric mechanisms. Integrity-protection algo-   • secure boot and software integrity;
                                                                                             • secure control of debug and trace capabil-
                                                                                                ities;
                                                                                             • digital rights management;
Figure 2                                                                                     • hardware cryptographic accelerators;
Security software function blocks and architecture.
                                                                                             • hardware-based random number genera-
                                                                                                tor (RNG);
                                                                                             • cryptographic algorithm service;
                                                                                             • public key infrastructure (PKI) support;
                                                                                                and
                                                                                             • secure communication protocols (GSM/
                                                                                                GPRS/WCDMA security, TLS/SSL, IPsec,
                                                                                                and Bluetooth/WLAN).
                                                                                             These functions either fulfill security ex-
                                                                                             pectations or have been included to acceler-
                                                                                             ate cryptographic operations.

                                                                                             Platform and security
                                                                                             architecture
                                                                                             The second-generation platform architec-
                                                                                             ture, called A2, interconnects an access CPU
                                                                                             and an application CPU through a serial
                                                                                             link from Intel. The access CPU handles
                                                                                             standard communication protocols; the ap-
                                                                                             plication CPU handles user application
                                                                                             functionality. This division of labor sepa-

60                                                                                                               Ericsson Review No. 2, 2006
rates real-time control from high-
performance execution. Figure 1 gives a
schematic view of the hardware configura-
tion.
   A digital signal processor (DSP) performs
critical, real-time computations for the ac-
cess system, and a variety of hardware blocks
perform application-specific tasks. Five
blocks or modules (GPRS cipher, GSM ci-
pher, WCDMA cipher, cryptographic ac-
celerator, and the platform integrity mod-
ule), for example, perform cryptographic
computations for the access system.
   The first three modules (GPRS cipher,
GSM cipher, WCDMA cipher) handle cryp-
tographic computations for the UMTS and
GSM radio access network. The general
crypto accelerator
• boosts the performance of critical algo-
  rithms, such as SHA-1, MD5, AES and              Figure 3
  DES;                                             Schematic view of the crypto accelerator.
• provides DES encryption/decryption to
  and from the block with a unique, chip-
  independent key; and
• exponentiates large numbers (to support
  RSA, DH, DSS operations) with shielded         ic functions related to radio access are not       A DRM module parses protected DRM
  private key computation.                       shown. The figure reflects the software con-    files. It also validates the rights associated
An analog random number generator is di-         figuration during normal operation. Addi-       with protected content, manages decryption
rectly connected to the cryptographic accel-     tional software can be loaded into the phone    and DRM keys, and enforces file usage
erator, supplying it with statistically and      to upgrade and configure software (not          rights.
cryptographically sound pseudo random se-        shown).                                            A security protocol module handles high-
quences.                                            An IP module contains the IP stack, which    layer security protocols and their mecha-
   Secure boot ROM is used on the access         includes the secure IP (IPsec) protocol.3       nisms, such as the extensible authentication
and application side to guarantee the in-           A SIM module handles the UMTS inte-          protocol (EAP) or transport layer security
tegrity of software at startup. This includes    grated circuit card (UICC) data and services,   (TLS).4-5
code on all volatile and non-volatile storage.   and supports applications on the UICC, for
The secure ROM functions can also be used        instance, SIM, USIM2, the SIM application
to verify integrity at run-time.                 toolkit (SAT), and the WAP identity mod-
                                                                                                 Cryptographic engines
   The subscriber identity module (UICC or       ule (WIM).                                      Security in a mobile platform relies heavily
SIM card) provides protected storage and a          An access core platform security module      on cryptographic techniques. Cryptograph-
secure execution environment for user net-       provides the SIM lock, IMEI integrity, and      ic algorithms can be implemented in hard-
work authentication services and key net-        software reprogramming protection at run-       ware or software. Hardware implementa-
work management tasks.2                          time. It also protects data and provides pro-   tions often improve performance and better
   Debug interfaces connect to the applica-      tection during debugging.
tion and access CPUs. If left unprotected,          An access cryptographic module provides
these interfaces could be used as a backdoor     low-level security functionality for platform
to all platform functionality. The platform      modules on the access side – for example,
provides strong protection for the debug         the IP module. Note: The reader should not
                                                                                                   TABLE 1, ALGORITHMS IMPLEMENTED
interfaces through particularly secure plat-     confuse this functionality with low-level
                                                                                                   IN HARDWARE.
form configurations when the debug capa-         network encryption functions, which are
bilities have been enabled. These interfaces     handled by dedicated hardware blocks.
                                                                                                   UMTS, f8 using Kasumi
are always disabled in commercial product           An application core platform security          UMTS, f9 using Kasumi
configurations.                                  module contains mechanisms that protect           GSM, A5/1, A5/2 and A5/3
   Figure 2, which is a sketch of the software   against software and data reprogramming,          GPRS, GEA1, GEA2, GEA3 and GEA4
security architecture, shows the main soft-      for example, secure software upgrading via        SHA-1 (two different hardware realizations)
ware modules associated with security and        over-the-air upgrades of firmware.                MD5
                                                                                                   Platform-specific MAC engine
their relationship to the hardware blocks.          An application cryptographic module            DES and 3DES
Note: Only high-level security functions         handles cryptographic services on the ap-         AES
have been depicted; low-level cryptograph-       plication side.                                   RSA and DH

Ericsson Review No. 2, 2006                                                                                                                  61
                                               platform baseband. These hardware blocks         functionality is partitioned in the applica-
                                               compute the algorithms that are used to pro-     tion and access cryptographic modules.
                                               tect the cellular air interface.
                                                  The cryptographic accelerator block is        Application cryptographic module
                                               dedicated to general cryptographic opera-        The application cryptographic module pro-
                                               tions (Figure 3). It has a fairly large set of   vides cryptographic algorithm and WIM
                                               cryptographic algorithms, supporting             support, stores cryptographic objects, and
                                               shielded symmetric key and asymmetric            handles certificates. A PKCS#11 interface is
                                               public-key algorithms. This facilitates se-      used to access cryptographic algorithms and
                                               cure private key operation with the hard-        stored cryptographic data.7 The idea is that
                                               ware module. The main security advantage         the same interface can be used regardless of
                                               of this design is that the private key can       whether data or algorithms reside in soft-
                                               be encrypted using a unique, chip-               ware, hardware, or on a WIM application on
                                               independent key and the crypto accelerator       a SIM or USIM card.
                                               cipher engine. The private key is thus never        PKCS#11 is an application program in-
                                               exposed outside the accelerator block. The       terface (API) to devices that hold crypto-
                                               crypto block also makes use of hardware ac-      graphic information and perform crypto-
Figure 4                                       celeration to compute demanding algo-            graphic functions. Each device, called a
Schematic view of the platform integrity       rithms, such as 3DES and SHA-1.                  cryptographic token, can be implemented
block.
                                                  The platform also has a dedicated plat-       entirely in software, or with hardware sup-
                                               form integrity hardware block that contains      port. A PKCS#11 implementation consists
                                               both a SHA-1 engine and a dedicated MAC          of one or more tokens and a thin, common
                                               engine (Figure 4). The block verifies plat-      interface to the tokens. This interface, called
protect sensitive information, such as keys.   form code and data integrity. The hardware       Cryptoki, initializes PKCS#11 functionali-
But they also cost more and limit flexibili-   radio functionality in the platform relies on    ty and manages communication with the
ty. Ericsson’s mobile platforms contain a      correct MAC verification of security-critical    cryptographic tokens. The tokens imple-
balanced mixture of hardware- and soft-        platform data.                                   ment the functionality and are responsible
ware-based cryptographic algorithm sup-                                                         for cryptographic data storage. The
port, giving good performance and security     Software cryptographic modules                   PKCS#11 functionality is split into three
at a reasonable cost.                          The platform’s access and application cryp-      tokens: platform token, SIMWIM token,
                                               tographic modules provide applications           and DRM token.
Hardware cryptographic modules                 (DRM, browser security, IPSec, execution            The platform token, which is always pre-
To offer high-level security and crypto-       environments, DVB-H) with low-level              sent, contains every algorithm implement-
graphic performance, the platforms protect     crypto support – for example, cryptograph-       ed in the phone. It also contains built-in
and accelerate computations of essential       ic algorithm support, WIM support, and           WIM functionality that supports TLS/SSL
cryptographic operations. Numerous algo-       certificate handling.6 Most of the function-     client and server authentication.8-9 In addi-
rithms have been implemented in hardware       ality is located in the application crypto-      tion, it contains
(Table 1).                                     graphic module because most clients of this      • symmetric and asymmetric encryption
   Figure 1 shows how the UMTS, GSM and        functionality execute on the application           and decryption;
GPRS hardware blocks are connected to the      CPU. Figure 5 shows how the supported            • hash calculation, MAC calculation



TABLE 2. SUPPORTED ALGORITHMS, KEY SIZES, AND OPERATIONS.




62                                                                                                                   Ericsson Review No. 2, 2006
(HMAC), digital signature generation and         private key. The crypto accelerator block        • other information about validity and
verification1,10;                                uses a unique chip-independent key to en-          time; and
• random number generation;                      crypt and protect the integrity of the DRM       • a digital signature.
• built-in WIM functionality: TLS, and SSL       private key when stored in flash memory.         The certificate thus provides a crypto-
   key exchange (pre-master secret genera-       The DRM private key is always highly pro-        graphic binding between an identity and
   tion, master key derivation, and pseudo       tected. When used for decryption and sign-       a public key. This is very useful for au-
   random function), and storage of session      ing operations, for example, it is decrypted     thentication and key exchange purposes.
   data and master secrets;                      and held inside the hardware block; it is thus   Certificates can be chained such that the
• protected storage of certificates and keys     never exposed outside the block. The pri-        public key in one certificate is used to
   in flash memory; and                          vate key is installed at the time of produc-     verify the signature of another certificate
• asymmetric key pair generation (RSA,           tion using a special RAM loader.                 (delegated authorization).
  DH); among other things, the RSA                  Table 2 lists supported algorithms, key          The certificate-management function
  private-public key pair can be used for cre-   sizes, and operations.                           of the application cryptographic module
  ating signatures for authentication and                                                         parses certificates, verifies certificate
  non-repudiation.                               Certificate management                           chains, stores certificates, and generates
The platform token supports numerous             Digital certificates are used to identify ex-    PKCS#10 certificate requests.
standard algorithms (AES, DES/3DES,              ternal services or the mobile phone itself. A       Certificates are stored via the
RC4, RC5, MD2, MD5, SHA-1, SHA-256,              certificate typically consists of                PKCS#11 interface either in flash mem-
SHA-384, SHA-512, RSA, and DH). As an            • an identity value, which identifies the en-    ory via the platform token or on a
option, many of these (AES, DES/3DES,             tity that uses the certificate;                 WIM/WAP provisioning application on
MD5, SHA-1, RSA, and DH) can be accel-           • a public key;                                  the SIM/USIM card.
erated in the crypto accelerator hardware        • an issuer value, which identifies the cer-        The certificate parser is used internal-
block to boost performance and increase se-        tificate authority;                            ly to verify certificate chains. Applica-
curity (via shielded key operations). The ac-
cess cryptographic module contains drivers
for the crypto accelerator hardware. If man-
ufacturers waive the hardware-acceleration
option, the algorithms are executed in soft-
ware on the application CPU. The SHA-1
algorithm, however, may always be acceler-
ated in hardware via the integrity block. The      Figure 5
other algorithms are always executed en-           Block diagram of the software cryptographic modules
tirely in software.
   The SIMWIM token provides access to
cryptographic algorithms, cryptographic
objects of a WIM application on the
SIM/USIM card, and cryptographic objects
of a WAP provisioning application on the
SIM/USIM card.11 If supported by the
SIM/USIM card, the SIMWIM token
• supports PKCS#1 encryption, decryp-
   tion, signing and verification;
• supports random number generation;
• supports TLS key exchange (pre-master se-
  cret generation, master key derivation, and
  pseudo-random function) and stores ses-
  sion data and master secrets; and
• stores certificates and RSA private-public
   keys.
The SIM software module on the access side
is responsible for communication with the
WIM application on the SIM/USIM card.
The SIMWIM token uses this module to ac-
cess the WIM.
   The DRM token helps realize OMA DRM
support. Access to this token is restricted to
the DRM module. The DRM token contains
functionality that is specific to DRM, such
as RSA-KEM12, which involves the DRM

Ericsson Review No. 2, 2006                                                                                                               63
Figure 6
Public key validation and customization.




tions also use it to display parsed informa-       graphic module. The application crypto-          authority to obtain certificates for a public
tion to the user. The parser supports the          graphic module also supports the generation      key that is
parsing of X.509 v3 certificates according         of online certificate status protocol (OCSP)     • generated on the device, or
to the OMA certificate profile.13 In compli-       requests and the validation of OCSP re-          • available on the WIM on the SIM/USIM
ance with this profile, the verifier verifies      sponses that can be used by an application         card.
certificate chains consisting of X.509 cer-        to check the revocation status of certificates
tificates. If the certificate chain does not in-   in a chain. The platform supports the OMA        Access cryptographic module
clude the root certificate, the verifier can be    OCSP mobile profile.14                           The access cryptographic module provides
instructed to look for it and any other miss-         The application cryptographic module          cryptographic algorithm support for the ac-
ing certificates in the chain on any of the        also generates PKCS#10 certification re-         cess side. IPsec, for example, requires sup-
PKCS#11 tokens of the application crypto-          quests,15 which can be sent to a certificate     port for AES and DES/3DES in cipher block
                                                                                                    chaining (CBC) mode, and HMAC with
                                                                                                    SHA-1 and MD5. The AES, DES/3DES,
                                                                                                    MD5 and SHA-1 algorithms can be accel-
                                                                                                    erated in hardware to boost performance.
Figure 7                                                                                            The access cryptographic module contains
Signing principles and formats.                                                                     the necessary hardware drivers. If the man-
                                                                                                    ufacturer waives this option, the algorithms
                                                                                                    are executed in software.

                                                                                                    Platform software integrity
                                                                                                    and secure boot
                                                                                                    To ensure that the platform behaves cor-
                                                                                                    rectly, one must guarantee the integrity of
                                                                                                    core platform software and critical data. This
                                                                                                    holds true for software that controls the
                                                                                                    radio, and security software that controls
                                                                                                    SIMLock, DRM and general security ser-
                                                                                                    vices, such as TLS and IPsec protocols.
                                                                                                      The integrity of the platform software is
                                                                                                    protected by solely allowing digitally
                                                                                                    signed software to be executed on the plat-
                                                                                                    form. This applies to platform software and
                                                                                                    applications and to RAM loaders; that is,
                                                                                                    software loaded into RAM over an external
                                                                                                    interface. RAM loaders are used for cus-
                                                                                                    tomization, verification, and for updating
                                                                                                    phone software in flash memory.
                                                                                                      The software or loader is validated when

64                                                                                                                      Ericsson Review No. 2, 2006
it is loaded onto the platform and before ex-
ecution. All access software and core parts
of the application software are thus checked
each time the platform starts. A first-time
check is always performed using digital sig-
natures and certificates when the software is
loaded from an external source or when the
platform is started after software has been
flashed into the phone. To speed up valida-
tion, MACs are used to recheck software that
was approved during the first-time check.
The MACs check software before execution
and when a mobile phone is started. They
are also used for verifying certain data areas
(system settings). MAC verification uses a
symmetric encryption key and is thus much
faster than the first-time check. The sym-
metric key is a unique (chip-dependent)            Figure 8
code generated in the integrity hardware           Replacing the signature with a MAC.
block.

Software signing, keys and certificates
The signing of software and RAM loaders is       Ericsson using the Ericsson private key. Cus-      lated from hashes of software blocks of the
based on a PKI solution for which Ericsson       tomers use their private keys to sign soft-        software to be installed. Software blocks may
serves as the root certificate authority.        ware and RAM loaders for the platform. The         be verified each time the software is loaded
Ericsson has generated an RSA root private-      RSA key pairs are either generated by              or flashed into memory. Figure 7 shows how
public RSA key pair. The public key is           Ericsson or a customer. When customers             complete, protected digital signature soft-
stored in the access boot ROM; the private       generate key pairs, they must request              ware packages are created.
key is kept secret. Ericsson’s mobile plat-      PKCS#10 certification from Ericsson. 15               The digital signature is replaced with a
forms have three root keys stored in ROM:        This process is surrounded by careful proce-       MAC when software is flashed into memo-
two 1024-bit keys and one 2048-bit key.          dures to prevent wrongful issuing of certifi-      ry or during the first boot after it has been
Each root key pair is unique for each digital    cates. The certificate format, based on the        flashed into memory (Figure 8). The plat-
baseband controller. Electrical fuses enable     X.509 v3 standard, uses a defined extension        form integrity hardware block calculates
Ericsson to revoke a key pair if the private     that includes Ericsson-specific information        and checks MACs. It also performs all hash
key has been compromised. All three key          for controlling the rights of certified keys. 13   computations (SHA-1).
pairs are activated from the start, but only        Ericsson certifies keys for its customers,         A mobile equipment domain has been in-
one is used at a time.                           who in turn, are allowed to certify keys for       troduced to keep software and RAM load-
   Protected software must be signed with a      their customers or third-party developers.         ers intended for use in R&D and at factories
private key. The digital signature format is     To prevent loaders and software from one           from being used in commercial products.
compliant with the RSA PKCS#1 stan-              customer from being downloaded into other          The domain is indicated in the customer cer-
dard.11 Regardless of who issues the code,       mobile phones, each customer is assigned a         tificate. The integrity of the domain is pro-
the same certification principle and policy      unique customer ID (CID). Several CIDs can         tected and stored in flash memory. The plat-
apply. A valid RSA signature and associat-       be assigned to any given customer but no           form integrity block protects integrity. The
ed chain of X.509 certificates means that the    two customers will have the same CID. The          following domains are used:
software has been approved by Ericsson, by       CID is written into the customer certificate.      • Factory – loaders and software intended
customers of Ericsson, or by trusted third       It is also written into a one-time program-           for use in the factory.
parties, and has not been modified before        mable (OTP) area during production. When           • R&D – loaders and software intended for
being downloaded. The platform will only         software and RAM loaders are verified, a              use in R&D.
accept software with signatures matching         check is made to ensure that the CID of the        • Product – loaders and software for com-
its active public root key. Figure 6 shows       customer certificate matches that of the              mercial products.
the general customer key verification prin-      OTP area. The software version is also             • Service – this domain may only be used by
ciple.                                           checked. In keeping with GSMA and                     the boot ROM code when the current
   Ericsson issues unique certificates to its    EICTA anti-rollback protection require-               phone domain cannot be read. This do-
customers (mobile phone manufacturers)           ments, only software with a larger version            main makes it possible to restore the
who build phones on its mobile platforms.        number than that of current software will             phone domain using a special loader
Ericsson’s customers may sign software and       be accepted.16                                        signed for the domain. This procedure re-
RAM loaders that are to be accepted by the          The customer digitally signs a software            quires special authorization.
platform. A certificate for a particular cus-    header, the software itself, and optionally, a     A customer certificate may contain or be is-
tomer contains an RSA public key signed by       hash list. If present, the hash list is calcu-     sued for several domains. Loaders and soft-

Ericsson Review No. 2, 2006                                                                                                                   65
ware signed by a customer are signed for the      in factory, R&D, or commercial products.         ed. At the end of the factory process, the do-
domains contained in the customer certifi-        The exact list of domains in each certificate    main is changed to either R&D or product.
cate. Only those loaders and the software as-     depends on the needs of the customer (man-
sociated with the domain to which the mo-         ufacturer).                                      Secure boot
bile phone belongs will pass verification and       During production, the phone domain of         The platform can be started in two main
be accepted by the phone. Ericsson issues         the mobile phone is set to factory. Therefore,   modes of operation: service mode and nor-
several certificates to its customers for use     only factory loaders and software are accept-    mal mode. At startup in service mode, the



Figure 9
Normal mode boot sequence. The flash
used to store access and application soft-
ware and bootstrap code is connected on
the application side.
1. The access ROM reads the one-time
   programmable (OTP) contents. The
   OTP configuration only allows software
   intended for the particular platform to
   be executed. The customer ID (CID), for
   example, is part of the OTP. And only
   software signed for the correct CID is
   accepted.
2. The phone domain is read from flash
     memory. The phone domain is stored
     as static data. The integrity hardware
     block verifies the integrity of this data.
     The static data is also compared
     against the OTP configurations.
3. The application and access bootstrap
   codes are read from flash memory. The
   bootstrap codes are stored with a
   header. They are also protected with a
   signature or MAC. The integrity block
   assists the ROM code on the access
   side by checking the integrity of these
   two blocks.
4. Complete access and application soft-
   ware images are loaded and verified in
   exactly the same way as the bootstrap
   codes. This process ensures that the
   integrity of all code is checked before it
   is executed.




66                                                                                                                     Ericsson Review No. 2, 2006
platform loads one or more RAM loaders               A mobility manager software module            are EAP-SIM and EAP-AKA, which are
from a fixed connected local interface, such      manages keys and authenticates users with        based on GSM and UMTS authentication
as a serial port or universal serial bus (USB).   the help of the UICC, which is controlled        methods.21-22 The platform supports these
This mode is used to customize and flash the      by the SIM software module. Note: Because        mechanisms as part of its security protocol
phone during production. At startup in nor-       this software module mainly handles non-         services.
mal mode, the phone is booted from flash          security-related tasks it has not been in-
memory. In either case, the software must         cluded in Figure 2.                              Broadcast traffic protector
be verified before it can be executed. The           Depending on the kind of air interface,       Broadcast services are emerging in mobile
verification principles are similar for both      different software is used to control network    networks. Two major broadcast standards,
modes of operation. Figure 9 shows the            cryptographic tasks. The control software is     multimedia broadcast/multicast service
startup sequence for normal mode.                 part of the communication software (not          (MBMS) and digital video broadcast – hand-
                                                  shown in Figure 2). In WCDMA, the radio          held (DVB-H), are finding their way to mo-
                                                  link controller and physical layer software      bile handsets.23-24 These two technologies
Secure communication                              control encryption. In GSM, the physical         call for separate security solutions.
Users want to be able to use their mobile         layer handles encryption; in GPRS, the log-         In the context of broadcasted content, one
phones to communicate regardless of loca-         ical link controller.                            usually distinguishes between traffic pro-
tion or time. And when they do so, they take                                                       tection and content protection. Content-
it for granted that sensitive voice and data      Local interface security                         protection mechanisms (also called digital
messages will not be revealed to hostile third    In recent years, there has been a growing        rights management, DRM) control how
parties. The kind of protection that is ap-       number of security threats from other radio      broadcasted content is used. Traffic protec-
plied varies according to the application. For    interfaces. Several Bluetooth products, for      tion, on the other hand, is about controlling
some applications, it is sufficient to protect    example, have shipped with bad security          access to the broadcast service. At present,
the wireless communication channel. For           policy settings or faulty access control im-     the standardization of traffic protection is
other applications, users and content             plementations. Some mobile phones on the         incomplete. What is clear, however, is that
providers require end-to-end protection of        market allow unauthenticated devices to ac-      basic security mechanisms cannot easily be
information. We distinguish between net-          cess sensitive phone services, such as phone     combined in DVB-H and MBMS. The mo-
work access security, local interface securi-     book, calender, business card and mobile         bile platform currently supports the
ty, broadcast security and packet data secu-      phone identity number.17                         DVB-H broadcast standard. The security
rity. Ordinarily, packet data protection             One can considerably reduce the risk of       options in DVB-H protect traffic via IPsec,
mechanisms solely apply to end-to-end sce-        security threats by controlling access and by    secure real-time transport protocol (SRTP)
narios. The low-level cryptographic support       switching on Bluetooth security. The             and ISMAcryp according to the IP device
needed for these services (apart from the         Ericsson Bluetooth stack supports access         control (IPDC) standard.25-28 Among these,
Bluetooth and WLAN radio interface) are           control and encryption at the application        IPsec and ISMAcryp are part of the plat-
realized using the hardware and software          level. In the end, however, it is up to appli-   form’s security protocol services. The key
cryptographic modules.                            cation developers to decide on the security      material for this protection (encryption key
                                                  policy for the interface. The Bluetooth en-      and integrity key) must be given to the plat-
Network access security                           cryption functions are performed on the          form, for example, at the application level
Network access security is about giving           Bluetooth hardware module outside the            on top of the platform. Once the MBMS se-
users secure access to 2G and 3G services; in     platform digital baseband.                       curity standard and OMA-based broadcast
particular, protecting them against attacks          Ericsson’s mobile platforms also support      security mechanisms have been standard-
on the radio access link. This entails net-       WLAN access according to the IEEE 802.11         ized, the platform will also support them.29
work and terminal authentication and pre-         standard.18 WLAN communcation security
serving confidentiality and the integrity of      is a rather complex area in which a number       Packet data protector
certain control data, user traffic, user iden-    of security aspects need to be considered.       Two major protection protocols are used to
tity, and location data. Apart from emer-         Earlier versions of the standard had several     protect TCP/IP connections: secure IP (IPsec)
gency calls, a valid SIM or USIM is required      security weaknesses, but WLAN link secu-         and transport layer security (TLS).26, 8
to access any 2G or 3G service. Theft pre-        rity has been much improved through the            TLS and its predecessor, secure sockets
vention through the unique terminal iden-         introduction of IEEE 802.11i link-               layer (SSL), offer secure browsing services.
tity, IMEI, is also an element of network ac-     protection mechanisms and IEEE 802.1X            The TLS and SSL protocol suites contain au-
cess security. The IMEI can be used to bar a      port-based access control.19-20 The WLAN         thentication and key exchange mechanisms
terminal from accessing 2G and 3G services.       hardware module supports the 802.11i             and transport security. TLS is also very flex-
Data protection features keep the IMEI se-        mechanisms. Likewise, the platform data          ible when it comes to client authentication
cure.                                             communcation stack supports the IEEE             options. Server authentication is based on
   The mobile platform supports all manda-        802.1X framework. The 1X standard allows         (X.509) certificates. The optional client au-
tory 3GPP authentication, key exchange,           for a large set of authentication and key ex-    thentication is also based on certificates.
confidentiality, and integrity-protection         change options based on the extensible au-       Platform support for TLS and SSL is pro-
mechanisms. Hardware support facilitates          thentication protocol (EAP).4 Seen in terms      vided on the application system as part of
computation-intensive encryption/decryp-          of mobile phone communication, some of           the protocol services.
tion algorithms.3                                 the most useful authentication mechanisms          The platform also offers IPsec as part of

Ericsson Review No. 2, 2006                                                                                                                   67
the IP stack on the access subsystem. In con-       phones on mobile networks, to combat the           to a SIM/USIM.33 Several different locks are
trast to TLS, the IPsec protocol is solely an       use of stolen equipment. Network operators         available. In addition, an Ericsson-specific
IP packet-protection mechanism. There-              can blacklist stolen phones to prevent them        lock extends locking functionality to fulfill
fore, it must be complemented with key              from being used in their networks. For this        operator requirements (Box B).
management support on another layer. For            mechanism to be effective, users must not             The platform thus offers flexible cus-
virtual private network (VPN) applications,         be able to modify a phone’s IMEI value.            tomization of SIM locks for the manufac-
the obvious choice is internet key exchange         Ericsson supports the 3GPP requirement             turer during production. The customized
(IKEv1 or IKEv2).5,30 IKEv2 will be added           that to resist tampering the IMEI cannot be        SIM lock settings are stored in flash mem-
to the platform protocol suite in 2007.             changed after production. The Ericsson mo-         ory. The platform integrity hardware block
   The TLS and IPsec protocols require low-         bile platform thus solely allows manufac-          prevents SIM lock cloning. Each time the
level support of several cryptographic algo-        turers to store the IMEI in an OTP memo-           phone is started, the platform software
rithms. The cryptographic modules, which            ry area (Figure 1) at the time of production. 32   checks that the inserted SIM/USIM card
implement the algorithms in software,               Once the IMEI has been written, the mem-           matches the SIM lock settings. The integri-
hardware, or both, provide this support.            ory area is locked and cannot be modified or       ty of the SIM lock software is also checked
   Packet data services are important and           rewritten. Furthermore, the integrity of           at every start-up.
must be protected in a WLAN setting. In             platform software that is responsible for             The SIM locks can be unlocked via dedi-
the near future, the platform will support          reading the IMEI value and sending it to the       cated platform interfaces or over the air
universal mobile access (UMA) security              network is protected and verified at every         (OTA), via SMS.33
mechanisms based on IPsec and IKEv2.31              startup. This implementation complies                 Ericsson’s mobile platforms also support
Futhermore, there is an apparent need for           with the GSMA and EICTA security prin-             an anti-theft feature that enables users to
additional protection at the packet level.          ciples related to handset theft.16                 stipulate that a personal identification num-
Ericsson thus foresees a firewall, a virus pro-                                                        ber (separate from the regular PIN protect-
tection mechanism, or both as part of the           SIM lock                                           ing the SIM/USIM card) must be entered
platform security offering.                         The SIM lock feature uses information              each time the phone is powered on. This se-
                                                    stored in mobile phones to list the number         curity PIN prevents stolen phones from
IMEI protection and SIM                             of SIM/USIM cards with which the equip-            being used even after the SIM/USIM card
                                                    ment will operate. The function can also be        has been replaced.
lock                                                used to lock mobile phones to a range of
                                                    SIM/USIM cards. This range can vary from           Application security and
IMEI protection                                     one SIM/USIM card to any SIM/USIM card
Originally intended as a unique identity to         that belongs to one particular or several co-      DRM
prevent non-type-approved mobile phones             operating networks.
                                                                                                       Application security
from connecting to GSM networks, the                   Ericsson’s mobile platforms support the
IMEI is today used to identify mobile               3GPP standard for locking mobile phones            The platform allows Java MIDlets and dy-
                                                                                                       namically linked native applications to be
                                                                                                       downloaded and executed at runtime. To be
                                                                                                       accepted by the platform, applications or
                                                                                                       MIDlets must first be digitally signed via a
                                                                                                       scheme that is based on RSA signatures with
                                                                                                       X.509 certificates. When a native applica-
                                                                                                       tion is installed, the platform installer ver-
                                                                                                       ifies the signature of the application and the
                                                                                                       certificate chain that is downloaded with it.
                                                                                                       The application cryptographic module han-
BOX B, SUPPORTED SIM LOCK TYPES                                                                        dles certificate parsing and verification.
                                                                                                          The platform supports the downloading
• Network lock – locks the phone to a specific network defined by the mobile country code and          and verification of Java MIDlets according
  the mobile network code.
• Network subset lock – locks the phone to a specific subset of the network.                           to Java MIDP 2.0.34 The MIDlets are either
• Service provider lock – uses the group identifier on the SIM/USIM to lock the phone to a specif-     trusted or untrusted. Untrusted MIDlets
  ic service provider.                                                                                 may operate in a “sandbox” without access
• Corporate lock – uses the group identifier to lock the phone to SIM/USIM cards that belong to        to sensitive platform APIs. Trusted MIDlets
  a specific company.
• Cooperative network list – locks the phone to a specific group of networks. This lock can be a
                                                                                                       must be digitally signed and verified before
  combination of any or all the locks listed above.                                                    they can be granted access to more sensitive
• SIM lock – locks the phone to a specific SIM/USIM card.                                              platform APIs. The platform APIs they may
• Extended SIM lock – an Ericsson-specific lock that adds greater flexibility for handling special     access is determined by the Java MIDP se-
  operator requirements.                                                                               curity domain to which they belong. The
The Ericsson mobile platforms also support auto-locking to a SIM/USIM card; that is, the phone         platform supports operator, manufacturer,
locks to the first SIM/USIM card inserted into it. The lock type can be one or more of the lock        and third-party domains.34 The signing of
types described above.                                                                                 Java MIDlets is based on RSA signatures

68                                                                                                                         Ericsson Review No. 2, 2006
with X.509 certificate support. The Java            basic security services of the application
MIDlets are verified in the same way as na-         cryptographic module to write their own se-
tive applications. In addition, the platform        curity applications, such as secure e-mail
checks the security domain to which the Java        clients, e-commerce applications, and so on.
MIDP belongs. This is determined by the
root certificate in the certificate chain asso-     DRM
ciated with the MIDlet.                             The platform supports DRM, which is a
   The platform also supports the Java secu-        complete system designed to limit access to
rity-and-trust-services API (SATSA, JSR             digital media content to people who have
177)35, which defines a collection of APIs          acquired a proper license to play or view it.
that provides the following security and            The content provider (the party who creat-
trust services:                                     ed the content) “packages” the content ac-
• Secure storage, to protect sensitive data,        cording to the DRM specification and es-
   such as private user keys, public key (root)     tablishes one or more sets of usage rights (or
   certificates, personal information, and so on.   rules) and associated usage costs. Consumers
• Cryptographic operations, to support pay-         can buy and download content (usually en-
   ment protocols, data integrity, and data         crypted) and associated rights from, say, the
   confidentiality.                                 website of a content distributor. The DRM
• A secure execution environment, for de-           part of the phone makes certain that a prop-
   ploying custom security features. Java           er license has been obtained and enforces
   MIDlets rely on these features to handle         rules for playing content.
   many value-added services, such as user             The DRM functionality in Ericsson’s mo-
   identification and authentication, bank-         bile platforms provides a secure, efficient      Figure 10
   ing, payment, loyalty applications, and so       and robust solution for implementing DRM         Reference printed circuit board (PCB) for
   on.                                              support in mobile devices. The platform          Ericsson’s U350 mobile platform.
The above features can be obtained via a            DRM functionality is not a complete DRM
smart card. They can also be implemented            client solution, however. The platform con-
in software.                                        tains basic mechanisms that can be used to
   The APIs are grouped into four categories:       build complete DRM agents, but the func-
SATSA-APDU, SATSA-JCRMI, SATSA-                     tionality, such as that required to download
PKI and SATSA-CRYPTO.                               DRM content, is handled by the applica-
   The SATSA-APDU and SATSA-JCRMI                   tions (with some support from the plat-
categories handle communication with a              form). The platform currently supports
smart card. The implementation of SATSA-            OMA DRM v1.0 and v2.0 agents. In addi-
APDU allows a Java MIDlet to communi-               tion, a plug-in framework is available in the
cate with applications on a smart card that         platform to support other DRM standards.
is attached to the platform via the applica-        Manufacturers may thus implement other
tion protocol data unit (APDU) protocol.            DRM standards without having to modify
   SATSA-JCRMI allows a Java MIDlet to              the platform software.12,37 The platform sup-
invoke a method of a Java object on a Java          ports each of the different DRM implemen-
card attached to the platform.                      tations in parallel, including application-
   SATSA-PKI gives Java MIDlets the func-           level DRM solutions implemented using
tionality to generate digital signatures that       the plug-in concept.
conform to the cryptographic message syn-              The platform DRM solution provides a
tax (CMS) format36 and manage user certifi-         uniform rendering interface for non-DRM
cates and public or private keys.                   and DRM content. Platform rendering ser-
   SATSA-CRYPTO gives Java MIDlets                  vices might also be used, for example, by
basic cryptographic operations, such as mes-        DRM solutions implemented by a mobile
sage digest, digital signature verification,        phone manufacturer (using the plug-in con-       TRADEMARKS
encryption, and decryption. The crypto-             cept). The platform uses a common inter-
graphic operations enable a Java MIDlet to          face for generic DRM operations. Likewise,
                                                                                                     • Java is a trademark or registered trademark
provide secure data communication, protect          it provides automatic DRM support for              of Sun Microsystems, Inc. in the United
data, and manage content.                           every supported media type. To protect it,         States and other countries.
   The implementation of SATSA-                     decrypted DRM content is kept inside the         • Intel is a trademark or registered trade-
CRYPTO and SATSA-PKI is based on basic              platform domain. Tight coupling to the              mark of Intel Corporation or its subsidiaries
cryptographic services, including WIM               platform cryptographic services also ensures        in the United States and other countries.
                                                                                                     • Microsoft is a registered trademark of
support, from the application cryptograph-          overall high security.                              Microsoft Corporation.
ic module.                                             Support for OMA DRM v1.0 includes for-        • Open Mobile Alliance (OMA) is a trademark
   Phone manufacturers can employ the               ward lock (a mechanism that prevents con-           of Open Mobile Alliance Ltd.

Ericsson Review No. 2, 2006                                                                                                                       69
tent and messages from being transferred           Conclusion                                         applications. This limits the need for fur-
out of the mobile phone), combined deliv-                                                             ther software-protection mechanisms. In
ery of content and rights, and separate de-        Ericsson’s mobile platforms contain a vari-        the future, however, we might see a more
livery of content and rights. The platform         ety of security mechanisms and an advanced         PC-like situation, where new native soft-
also supports every mandatory part of OMA          model for issuing and checking the integri-        ware, such as non-Java software, can easi-
DRM v2.0, including the rights object ac-          ty of software. Manufacturers of mobile            ly be installed and executed. In that case,
quisition protocol (ROAP). In addition,            phones can thus build secure applications          non-trusted software will have to be iso-
Ericsson is adding support for OMA DRM             and a secure process for issuing platform          lated from trusted software. Advanced op-
domains, progressive download, and                 software. Apart from communication secu-           erating systems isolate non-trusted soft-
streaming to the platform.                         rity and basic platform integrity control,         ware in such a way that it is never allowed
   The DRM module, which plays a central           mobile phone developers can decide how             to interfere with the execution of trusted
role in the platform DRM solution, decrypts        and when they want to use these mecha-             software. In a large and flexible OS, how-
content while rendering downloaded and             nisms. Therefore, additional security mech-        ever, isolation is difficult to achieve.
streaming DRM content. It also downloads           anisms might be needed.                            Therefore, other means, such as hardware
(ROAP) and parses DRM files, stores and reads         The mobile platforms do not use an open         mechanisms or more stringent security re-
license files, validates rights associated with    software environment that permits end              quirements (in the OS) will have to be em-
protected content, and manages DRM keys.           users to install new software modules or           ployed.




REFERENCES

 1. HMAC: Keyed-Hashing for Message Authentication, IETF RFC 2104,        21. Extensible Authentication Protocol Method for Global System for
    http://www.ietf.org/rfc/rfc2104.txt                                       Mobile Communications (GSM) Subscriber Identity Modules (EAP-
 2. 3GPP TS 31.101: 3rd Generation Partnership Project (3GPP); Techni-        SIM), IETF RFC 4186, http://www.ietf.org/rfc/rfc4186.txt
    cal Specification Grou Terminals; UICC-terminal interface; Physical   22. Extensible Authentication Protocol Method for 3rd Generation
    and logical characteristics, http://www.3gpp.org                          Authentication and Key Agreement (EAP-AKA), IETF RFC 4187,
 3. V. Niemi and K. Nyberg, UMTS Security, Wiley, 2003                        http://www.ietf.org/rfc/rfc4187.txt
 4. Extensible Authentication Protocol, IETF RFC 3748,                    23. ETSI EN 300 744 Digital Video Broadcasting (DVB); Framing struc-
    http://www.ietf.org/rfc/rfc3748.txt                                       ture, channel coding and modulation for digital terrestrial television,
 5. The Internet Key Exchange (IKE), IETF RFC 2409,                           http://www.etsi.org
    http://www.ietf.org/rfc/rfc2409.txt                                   24. 3GPP TS 223.246: Multimedia Broadcast/Multicast Service, Stage 1,
 6. OMA, Wireless Identity module v1.1, http://www.openmobileal-              http://www.3gpp.org
    liance.org                                                            25. The Secure Real-time Transport Protocol (SRTP), IETF RFC 3711,
 7. RSA Laboratories, PKCS#11 v2.20, http://www.rsasecurity.com/rsal-         http://www.ietf.org/rfc/rfc3711.txt
    abs/pkcs                                                              26. Security Architecture for the Internet Protocol, IETF RFC 2401,
 8. Transport Layer Security v1.0, IETF RFC 2246,                             http://www.ietf.org/rfc/rfc2401.txt
    http://www.ietf.org/rfc/rfc2246.txt                                   27. Internet Streaming Media Alliance Encryption and Authentication
 9. Secure Socket Layer v3.0,                                                 Version 1.1, http://www.isma.tv/technology/ISMACryp1.1.html
    http://wp.netscape.com/eng/ssl3/draft302.txt                          28. IPDC Services Purchase and Protection Specification,
10. RSA Laboratories, PKCS#1 v2.1, http://www.rsasecurity.com/rsal-           http://www.etsi.org
     abs/pkcs                                                             29. 3GPP TS 33.246: Security of Multimedia Broadcast/Multicast Ser-
11. OMA, Provisioning Smart Card Specification v1.1, http://www.open-         vice, http://www.3gpp.org
     mobilealliance.org                                                   30. Internet Key Exchange (IKEv2) Protocol, IETF RFC 4306,
12. OMA, DRM Specification v 2.0, http://www.openmobilealliance.org           http://www.ietf.org/rfc/rfc4306.txt
13. OMA, Certificate and CRL Profiles v1.1, http://www.openmobileal-      31. Unlicensed Mobile Access (UMA); Protocols (Stage 3),
     liance.org                                                               http://www.umatechnology.org/specifications/index.htm
14. OMA, Online Certificate Status Protocol Mobile Profile v1.0,          32. 3GPP, International Mobile station Equipment Identities (IMEI), TS
     http://www.openmobilealliance.org                                        22.016 v5.0.0
15. RSA Laboratories, PKCS#10 v1.7, http://www.rsasecurity.com/rsal-      33. 3GPP, Personalization of Mobile Equipment (ME); Mobile Functional-
     abs/pkcs                                                                 ity Specification, TS 22.022 v5.0.0
16. GSMA/EICTA, Security Principles Related to Handset Theft v3.0.0       34. Java Micro Edition (JME), Mobile Information Device Profile v 2.0
17. C. Gehrmann, J. Persson and B. Smeets, Bluetooth Security, Artech     35. Java Micro Edition (JME), Security and Trust Services API (SATSA) v
     House, 2004                                                              1.0
18. IEEE 802.11 1999 Edition,. http://www.ieee.org                        36. Cryptographic Message Syntax, IETF RFC 2630,
19. IEEE 802.11i -2004, http://www.ieee.org                                   http://www.ietf.org/rfc/rfc2630.txt
20. IEEE 802.1X-2004, http://www.ieee.org                                 37. OMA, DRM Specification v 1.0, http://www.openmobilealliance.org

70                                                                                                                          Ericsson Review No. 2, 2006

								
To top