Digital rights management for multimedia content over 3G mobile networks

Expert Systems with Applications 37 (2010) 6787–6797

Contents lists available at ScienceDirect

Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa

Digital rights management for multimedia content over 3G mobile networks Chia-Chi Wu a, Chia-Chen Lin b,*, Chin-Chen Chang a,c a

Department of Computer Science and Information Engineering, National Chung Cheng University, Chiayi 621, Taiwan, ROC Department of Computer Science and Information Management, Providence University, Taichung 40724, Taiwan, ROC c Department of Information Engineering and Computer Science, Feng Chia University, Taichung 40724, Taiwan, ROC b

a r t i c l e

i n f o

Keywords: 3G Digital rights management Fairness Identity management Low computation cost Security

a b s t r a c t Third generation (3G) mobile systems offer true broadband data transmission and many multimedia services are flourishing on them. Hence, 3G transmission security has become a popular issue. Recently, Dimitriadis and Polemi proposed a lightweight IDM3G protocol for mutual authentication between users and their service providers. However, many multimedia services require safeguards during transmission over 3G networks to protect the digital rights of music and video, for example. Unfortunately, the Dimitriadis and Polemi protocol does not address this requirement in their protocol, which means their protocol can not be directly applied to design a fair and secure digital rights management mechanism. Therefore, in this paper, we try to improve their protocol by integrating the identity management 3G (IDM3G) and then propose a fair and secure digital rights management mechanism for multimedia content or services over 3G networks. Using our proposed scheme enables service providers to provide timebounded multimedia content or services and guarantees user privacy, data integrity, confidentiality, and non-repudiation, as well as forward secrecy and backward secrecy of transferred digital rights with low computation costs. Ó 2010 Elsevier Ltd. All rights reserved.

1. Introduction Because electronic commercial services are becoming more and more popular, users are gradually subscribing to a greater variety of services with service providers over the Internet. Examples of such services are online music, pay-TV, online games, and so on. Because the Internet is an open environment, it offers a convenient channel for service providers to transmit digital content to their consumers, but it also allows illegal users to steal or tamper with valuable unprotected digital content. To make sure the intellectual property rights of digital content are not violated, many techniques and concepts have been proposed and raised. The former includes cryptographic techniques (Schneier, 1996) and watermarking (Cox, Miller, & Bloom, 2002) and the latter includes digital rights as defined by Fujimura and Nakajima (Fujimura & Nakajima, 1998). According to their definition, a ‘‘digital right (DR)” is a digital representation of the right to claim a service or goods, which can be issued by different issuers, and represents various types of rights that may be invalidated when the service or goods are redeemed or transferred. A digital

* Corresponding author. Address: Department of Computer Science and Information Management, Providence University, Taichung 43301, Taiwan, ROC. Tel.: +886 4 26328001x18108 ; fax: +886 4 26321161. E-mail addresses: [email protected] (C.-C. Wu), [email protected] (C.-C. Lin), [email protected] (C.-C. Chang). 0957-4174/$ - see front matter Ó 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.eswa.2010.03.047

right contains four elements: issuer, promise, owner and validityconditions. The validity-condition defines that DR’s usage scope such as date, count, and location and so on. To provide a common infrastructure that assists parties to issue various digital rights and support consumers in the use and transfer their digital rights to another one, in 1999, Fujimura further proposed a Digital Right Trading Infrastructure (DRTI) Fujimura, 1999, in which four entities: an online ownership management system (OOMS), an issuer, a user and a service provider are involved. Furthermore, Foroughi et al. presented a list of features (Foroughi, Albin, & Gillard, 2002) which are provided by Digital Right Management (DRM) systems as Table 1 in 2002. They thought that DRM systems should select combinations of features to provide customized service. Afterward Muir did the related research (Muir, 2004) to propose some recommendations on how legislators, information providers and libraries can work together to ensure long-term access to digital information in 2004. In essence, the data transmission infrastructure of Fujimura’s DTRI is designed for application in the Internet, especially as it relates to wired networks. However, the development of wireless technologies has been so rapid; many technologies for providing wireless services such as the third generation (3G) wide area wireless networks and wireless local area networks (WLAN) have been proposed. Certainly, the essence of wireless networks is still inherited from the wired network. For example, the wireless network is also an open data transmission environment, which means data

6788

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

service provider; and a proper digital rights management mechanism to assist the service provider to issue multimedia digital content or services. In 2003, the Third Generation Partnership Project (3GPP), a joint initiative of telecommunication standardization organizations from the United States, Europe, Japan and Korea, defined the UMTS Authentication and Key Agreement (UMTS-AKA) mechanism as their core element for entity authentication, user identity management, confidentiality and integrity (Third Generation Partnership Project, 2006). The UMTS-AKA mechanism uses a pre-shared secure key (K) between the mobile operator (MO) and the UMTS subscriber identity module (USIM) of the mobile phone to perform authentication and key agreement. The USIM is a cryptography-enabled smart card identified by a unique 15-digit number, called an international mobile subscriber identity (IMSI). The USIM and the mobile operator can perform mutual authentication by a challenge and response mechanism. Fig. 1 (Dimitriadis & Polemi, 2006) shows a simplified version of the UMTS-AKA mechanism. The UMTS-AKA process is briefly explained here.

Table 1 Typical features offered by DRM systems (Foroughi et al., 2002).  Encryption of content with built-in e business cash registers  Plug-ins that end users must download to have access to content  Keys to unlock encryption for which end users must pay money or provide an email address  Access in exchange for personal information from end users  Watermarking video products  Pay-per-view formats  Discounts for regular customers  Free previews  Authorization verification  Usage tracking  Subscription capabilities  Print and copy restrictions  Time limits on access  Control of content sharing  Tracking of use of content-is it viewed, printed, copies, or passed on  Digital clearinghouses that handle payment and distribution of content

transmitted over either 3G or WLAN networks can easily suffer from being illegally accessed and tampered with. In addition, two weaknesses still exist in mobile devices: power limitations and limited computing capacity, both of which lead the most existing data protection solutions, such as authentication protocols, cannot be easily applied to wireless networks because the most of existing data protection protocols are designed for the wired networks and they do not consider above two issues. However, by taking advantage of voice and data services that ensure wide area coverage, high-speed mobility, complete subscriber management and nearly universal roaming, 3G networks still make the mobile device a promising communication channel to access digital content or services over the Internet. Take the following electronic commerce service scenario for example. A 3G mobile device user wants to access video or audio programs from a multimedia service provider over the Internet. The service provider promises that the user can watch programs without time restrictions for a monthly fee. Of course, each video program is transferred to another registered user via the streaming media to prevent it from being stored and broadcasted illegally later. Streaming media is multimedia data that is continuously received by, and normally displayed to, the end-user while it is being delivered by the provider. Three criteria must be satisfied in this scenario: a tripartite authentication among the mobile device user, the mobile operator (MO) and a service provider; a confidential transmission channel between the mobile device user and the

1. After the 3G mobile phone is turned on and the user passes a personal identification number (PIN) test, the mobile phone sends a login request over the 3G networks, which the mobile operator can detect. 2. After detecting a login request from a USIM, MO generates a random number (RAND), an authentication value (AUTN) derived from RAND, K, and some other parameters, and sends (RAND, AUTN) to the mobile phone. 3. After receiving these data, USIM can authenticate the mobile operator by verifying AUTN. Then, USIM computes a number (RES) by inputting RAND and K to a function (f2), and submits RES to MO. 4. The MO computes a value (XRES) using the same procedure as USIM, and compares XRES with RES to authenticate USIM. If they are equal, the mutual authentication can be confirmed by both USIM and MO. At the same time, they can compute a common session (128-bit) key CK generated by applying to RAND and K to f3 for further communications. They also get a common integrity (128-bit) key IK, which is derived by applying RAND and K to f4 for a message authentication codes (MAC) key. 5. The MO dynamically generates a temporary mobile subscribe identity (TMSI) and encrypts it using CK to get ENCR_TMSI. Then, MO sends ENCR_TMSI to USIM.

Parameters

MO

USIM

f2

AUTN Generation

RES ENCR_TMSI

f2 RAND K

f3

f4

CK

Ciphering facility

RAND K

f3

XRES

CK

IK f4

TMSI

TMSI

Ciphering facility

IK ENCR_TMSI

RAND, AUTN RES Fig. 1. Simplified UMTS-AKA mechanism (Cox et al., 2002).

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

6. The USIM can decrypt ENCR_TMSI using CK to get TMSI, which is a temporary identity of USIM and can be applied in reauthentication by MO locally. The UMTS-AKA mechanism can achieve a mutual authentication between the mobile user and MO while preserving mobile user’s identity privacy and location confidentiality. However, the UMTS-AKA mechanism cannot help a mobile device user and the user’s service provider to authenticate each other. Therefore, in 2006, Dimitriadis and Polemi used the existing relationship between the two entities to further implement identity management between the user and the service provider over the Internet (Dimitriadis & Polemi, 2006). Although the Dimitriadis and Polemi’s identity management protocol (Dimitriadis & Polemi, 2006) can be a solution to achieve tripartite authentication, which is one of criteria for the commercial scenario over 3G networks described earlier, the secure communication channel between a mobile user and a service provider still cannot be established after their protocol is completed. That is, to protect the multimedia digital rights against be stolen or abused by unauthorized users, we still have to design extra security mechanisms to provide a secure digital rights management mechanism over 3G instead of adopting the Dimitriadis and Polemi’s identity management protocol alone. In this paper, we propose a digital right management mechanism to protect multimedia content over 3G systems by establishing a secret channel among the mobile user, MO and SP (service provider). The proposed digital right mechanism will also help service providers to provide time-bounded multimedia content and services in a way that ensures only authorized users can receive the content and services they have been granted access to. It also ensures that illegal attacks do not violate legal users’ digital rights, and allows legal users to exchange or transfer their digital rights with each other. Moreover, our scheme avoids the asymmetric key encryption/decryption computations to enhance efficiency; thus, it is suitable for use in 3G mobile devices. The rest of this paper is organized as follows. In Section 2, we briefly review Dimitriadis and Polemi’s scheme (Dimitriadis & Polemi, 2006) which we then improve upon to establish a secure channel among the mobile user, MO and SP. In addition, we introduce Fujimura et al.’s digital ticket circulation framework (Fujimura et al., 1999). In Section 3, we present our proposed scheme. A discussion of how the proposed scheme performs in terms of security and efficiency is given in Section 4. Finally, concluding remarks are given in Section 5. 2. Related works In this section, we introduce the processes of Dimitriadis and Polemi’s protocol (Dimitriadis & Polemi, 2006) and the digital ticket circulation model proposed by Fujimura et al. (1999). 2.1. Review of Dimitriadis and Polemi’s protocol Assume a 3G user signs up for his/her wireless Internet service with an MO. When the user turns on the 3G mobile phone and passes the PIN test, the mobile phone performs UMTS-AKA as outlined in Section 1 to login the mobile network. In essence, Dimitriadis and Polemi’s IDM3G protocol (Dimitriadis & Polemi, 2006), which is based on UMTS-AKA, establishes a mutual authentication procedure between a user and an SP through MO. According to their definition of ‘‘identity management”, identity management is translated to the implementation of robust and user-friendly mechanisms to support the service providers to control access to their resources, for high diverse and dispersed indi-

6789

viduals whose electronic representation is bound with a set of authorization rights (Dimitriadis & Polemi, 2006). IDM3G protocol can provides an identity management mechanism among standalone UMTS mobile operation, interworking 3G mobile and WLANs network operation. Four entities are involved in the Dimitriadis and Polemi’s protocol: the user (U), USIM connected to the user equipment (USIM/UE), the mobile operator (MO) and the service provider (SP). Moreover, in Liberty Alliance terms, the principal is the user in combination with USIM/UE, the identity provider is MO and the service provider is SP. Liberty Alliance specifies the federated network identity, which extends the OASIS’s security assertions markup language (SAML) OASIS, 2005. The SAML is an extensible markup language (XML) World Wide Web Consortium, 2008 based standard for the exchange of user authentication data. SAML can be applied to secure communications between MO and SP, the related implementations can refer the standard document (OASIS, 2005). The IDM3G’s sequence chart shown in Fig. 2 (Dimitriadis & Polemi, 2006) is based on the message sequence charts (MSC) graphical language (SDL Forum Society, 2000), which is an International Telecommunication Union (ITU) standard. The protocol makes the following assumptions. 1. The MO and SP establish a business key agreement, a trust relationship and a secure channel once they become business partners. Doing so allows them to exchange encryption data using this session key via the SAML protocol. 2. A business and trust relationship is established between the user and MO by the user subscribing to MO. The user’s identity is known only by MO after the user applies the mobile phone service to MO. 3. After MO authenticates SP, then transmits a persistent set of attributes regarding a particular principal, which is shared between MO and SP. According to this set of attributes, SP can determine the user’s access privileges for a particular principal. The IDM3G protocol has two preceding phases as follows. 1. The user inputs a PIN to login in USIM according to the 3GPP specifications (Third Generation Partnership Project, 2000). 2. The USIM and MO finish mutual authentication according to the UMTS-AKA mechanism (Dimitriadis & Polemi, 2006). During this period, the CK (for data encryption) and the IK (for integrity protection) are computed by both USIM and MO. In addition, MO generates ENCR_TMSI by encrypting TMSI, and then sends ENCR_TMSI to USIM. The CK, IK, Auth, RAND and XRES compose a group of UMTS_AKA authentication elements called an authentication vector (AV), which is stored by MO during this connection. The IDM3G protocol is initiated when the user wants to connect to an SP (who owns a specific Internet Protocol-IP address); to do so, they must authenticate with each other. Dimitriadis and Polemi’s IDM3G protocol consists of ten steps as follows. Step 1. The UE sends a standard HTTP request to SP. SP can get the UE’s IP address according to the received request. This IP address is dynamically assigned to UE. Step 2. The SP replies to UE with a standard HTTP reply message, with an authentication request included. Step 3. The UE selects a random number (RAND), and encrypts the IP address of SP (ENCR_SP_IP) with the CK. Step 4. The UE computes a message authentication code (MAC1=H(RAND, ENCR_SP_IP, IK)), which is generated by RAND, ENCR_SP_IP, and IK. Then UE submits (RAND, ENCR_SP_IP, MAC1) to MO.

6790

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

U

USIM/UE

MO

SP

a. User authentication b. UMTS--AKA: {CK, IK, ENCR_TMSI} 1. HTTP Request 2. HTTP Reply: 3. Calculation of RAND, ENCR_SP_IP 4. RAND, ENCR_SP_IP, MAC1 5. Ticket {SP_IP, RAND, IMSI}, Currrent AV, TMSI timer 6. HTTP: {MO_ID, ENCR_TMSI, RAND, MAC2} 7. SAML: Request {ENCR_TMSI, RAND, MAC2} 8. Ticket Identification, TMSI comparison 9. SAML: Response {ATTRIBUTES} 10. HTTP Reply

Fig. 2. IDM3G protocol (Dimitriadis & Polemi, 2006) flowchart.

Step 5. The MO verifies the MAC1 and decrypts the ENCR_SP_IP to recognize SP. Because MO has already authenticated the UE in the second preceding phase mentioned earlier, MO combines the IMSI of USIM with SP_IP and RAND. This combination of SP_IP, RAND, and IMSI is a form of ticket. In this ticket, IMSI is used as a permanent identifier of the user, as in normal UMTS-AKA operations. The ticket should be valid for a predetermined time period defined in the business contract between MO and SP. Furthermore, the ticket is accompanied by the current authentication vector (AV) and TMSI of the user to avoid potential synchronization problems. Step 6. The UE submits an authentication response to SP, comprising ID of MO (MO_ID), the encrypted TMSI (ENCR_TMSI) that was generated in the second preceding phase, the RAND, and MAC2, which is derived from RAND, ENCR_TMSI and IK, to maintain message integrity. Step 7. SP recognizes MO_ID and sends an SAML request (OASIS, 2005) to MO. The request contains the ENCR_TMSI, the RAND, and the MAC2. Step 8. MO recognizes SP and combines SP_IP with RAND to locate an existing ticket. Once the ticket is located, MO uses the corresponding secret key (CK) to decrypt the ENCR_TMSI and calculates MAC2 to verify the integrity of the RAND and ENCR_TMSI. The MO compares the stored and submitted TMSIs to verify TMSI, which is a shared secret between USIM/UE and MO. If the comparison is positive, MO confirms the validation of SP. Step 9. If SP is verified, MO sends an SAML response (OASIS, 2005) with a set of attributes related to the IMSI of the

specific user to SP. By translating the received attributes, SP can authorize access right to the specific user. Step 10. The SP grants access rights to the user according to the derived authorization rights. Through these ten steps, Dimitriadis and Polemi’s IDM3G protocol helps the mobile user and SP to successfully authenticate each other. However, in their protocol, the trust relationship between the mobile user and SP is indirect, which means they do not negotiate a shared session key for any further secure communication. Therefore, any secure communication must be decrypted, encrypted, and forwarded via the intermediary MO. This design undoubtedly may create a heavy burden for MO.

2.2. Review of Fujimura et al.’s digital ticket circulation model In 1999, Fujimura et al. developed the comprehensive digital ticket circulation model (Fujimura et al. 1999) shown in Fig. 3. The Fujimura et al.’s model involves six entities: CA, the issuer, the service provider, the user, the broker and the shop. An issuer is in charge of creating, signing, issuing a digital ticket and authorizing brokers to sell digital tickets. A broker sells digital tickets to users. The user can purchase a ticket from a broker in advance, then redeem the ticket. The service provider is responsible for fulfilling the service defined in a ticket. Fujimura et al. also defined three types of ticket transactions: (1) issuance, in which an issuer grants ownership of tickets to users, (2) transfer, in which a user transfers ownership of a ticket to another user, and (3) redemption, in which a user redeems the rights defined in a ticket to the service provider.

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

Issuer

CA

Service Provider

Issue(wholesale) Network

Shop

Service Provider CARD

Transfer(sale)

Transfer

Transfer Redeem (Consume/Present)

User Broker

User

Fig. 3. Ticket circulation model (Fujimura et al., 1999).

To provide a common infrastructure that can help any one of the six parties issue various digital rights and support consumers in redeeming and transferring digital rights, Fujimura further proposed a digital right trading infrastructure (DRTI) Fujimura, 1999. Fujimura’s DRTI involves four parties: an online ownership management system (OOMS), the issuer, the user and the service provider. The OOMS manages ownership and validity of the users. In Fujimura’s DRTI, the issuer must sign an issued digital right to ensure the promise of the digital right; however, DTRI is not suitable for deployment in 3G devices, principally because verifying a digital signature requires substantial exponential computations that consume too much computation time and power to be suitable for 3G devices. Therefore, Fujimura’s DRTI cannot satisfy the low computation requirement of 3G devices. Based on descriptions in Subsections 2.1 and 2.2, it is noted that IDM3G (Dimitriadis & Polemi, 2006) can not provide directly secure communication between the user and SP, and Fujimura’s DRTI can not satisfy low computation requirement for wireless communication. Therefore, we are interesting to conquer these above weaknesses. Considering IDM3G had provided identity management solution, we extend IDM3G protocol to design a novel digital rights management scheme over 3G systems in this paper. Furthermore, the proposed scheme uses symmetric key cryptosystem and hash computations instead of public key cryptosystem to achieve improved efficiency and practicality.

3. Proposed scheme To provide a direct trust relationship between a mobile user and an SP that ensures the user’s digital rights will not be stolen and help SP to provide time-bounded multimedia content or services while keeping computation costs low, in this section, we improve on Dimitriadis and Polemi’s protocol (Dimitriadis & Polemi, 2006), then integrate it with the digital rights management model proposed by Fujimura et al. to propose a novel digital rights management mechanism suitable for use with 3G devices. The proposed scheme consists of three stages: the online registration stage, the login and access service stage, and the transfer stage. Our proposed scheme assumes that the UMTS-AKA (Dimitriadis & Polemi, 2006) authentication between the user and MO is completed and the authenticated MO can be trusted by both the user and SP. In other words, the user and MO obtain the common keys CK and IK. The CK is an encryption key, and IK is a integrity key for checking message integrity. In this section, we introduce notations used in the following paragraphs, first in Subsection 3.1, and give detailed descriptions of the three stages of our proposed scheme, in order, in Subsection 3.2.

6791

Table 2 Notations and definitions. Notation

Definition

UID MID RU RS Z N1, N2 a, b H() Hx() a=Ht1(a) b=HZ– t2 (b) t1 t2 t3 t T  Ek(m) CK IK TK AK

The user’s identity The identity of multimedia A random number is generated by UE A random number is generated by SP A public huge number is greater than 10,000 The nonce values are generated by UE The seeds of the hash function are generated by UE A secure one-way hash function A computation result of the hash function performing x times The result of the hash function performing t1 times with a The result of the hash function performing (Z–t2) times with b A specific serial number which represents a start date of the DR A serial number which denotes the valid date of the DR A serial number which denotes the transfer date of the DR A serial number which denotes the current date A timestamp The exclusive-or operation for two bit-strings Symmetric-key encryption of ‘‘m” with key k A pre-shared encryption key between UE and MO A pre-shared integrity key between UE and MO A temporary key between the user and SP A session key for access services

3.1. Notations Table 2 lists some notations used in our proposed scheme along with their explanations to help readers better understand the scheme. 3.2. Our scheme The proposed scheme can be broken into three stages: the online registration stage, the login and access service stage, and the transfer stage. To achieve confidentiality for the downloaded data in the login and access service stage, we assume that UE has embedded a stream cipher identical to that of the service provider’s. Detailed descriptions of three stages are given in the following subsections. 3.2.1. Online registration stage When a new user wants to subscribe to an SP’s services, the user must perform a 13-step online registration procedure to obtain a user identity (UID) and related information of user’s privilege. Fig. 4 shows the sequence of the online registration stage. Step 1. The UE sends a standard HTTP request to an SP for registration. The SP gets the UE’s IP address according to this request. Step 2. The SP replies in a standard HTTP message containing an authentication request to UE. Step 3. The UE generates a random number RU. Later, UE encrypts the visited IP address of SP (ENCR_SP_IP) and a temporary key (ENCR_TK) using the CK, respectively. Step 4. The UE computes a message authentication code (MAC1), which is generated by H(RU, ENCR_SP_IP, ENCR_TK, IK). Then UE submits (RU, ENCR_SP_IP, ENCR_TK, MAC1) to MO. Step 5. The MO verifies the MAC1 and decrypts the ENCR_SP_IP and ENCR_TK to recognize SP and obtain the TK, respectively. Then MO combines the IMSI of USIM with SP_IP and the RU. The SP_IP, RU, and IMSI compose a ticket. The MO uses the ticket, the current authentication vector (AV)={CK, IK, AUTN, RU, XRES} and the TMSI of UE to perform further SP authentication. Meanwhile, MO sets a time boundary to limit the response time of SP.

6792

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

U

USIM/UE

MO

SP

a. User authentication b. UMTS--AKA: {CK, IK, ENCR_TMSI} 1. HTTP Request: 2. HTTP Reply: 3. Calculation of RU, ENCR_SP_IP, TK 4. RU, ENCR_SP_IP, ENCR_TK, MAC1

timer

5. Ticket {SP_IP, RU, IMS I}, Currrent AV, TMSI, TK

6. HTTP: {MO_ID, ENCR_TMSI, RU, MAC2} 7. SAML: Request {ENCR_TMSI, RU, MAC2} 8. Ticket Identification, TMSI comparison 9. SAML: Response {RU, TK} 10. HTTP Reply: {Ready_Registration, ENCR_RS, MAC3} 11. HTTP Request: {ENCR_Reg_Data, N1, MAC4} 12. HTTP Reply: {RU, ENCR_UID, ENCR_Parameters, MAC5}

Fig. 4. Data flow of the online registration stage.

Step 6. The UE submits {MO_ID, ENCR_TMSI, RU, MAC2} to SP. MAC2 is generated by inputting ENCR_TMSI, RU, and IK to preserve message integrity. Step 7. The SP checks MO_ID from the received data, and forwards {ENCR_TMSI, RU, MAC2} to MO by using the SAML protocol. Step 8. MO checks the MAC2 to verify the integrity of the RU and the ENCR_TMSI. If they pass this check, MO can confirm the integrity of the received data. Moreover, if MO finds an existing ticket according SP_IP with RU, then decrypts the ENCR_TMSI to get TMSI using the corresponding CK from the authentication vector and compares the decrypted TMSI with the stored TMSI in Step 5. If they match, SP is authenticated by MO, since only the valid user possesses the correct CK and IK to generate the message of Step 6. Step 9. The MO sends {RU, TK} to SP by using the SAML protocol. Step 10. The SP stores {RU, TK}, and transmits {Ready_Registration, ENCR_RS, MAC3} to UE. The Ready_Registration is a notification to UE for the user. The ENCR_RS is an encrypted message of the RS using the TK and MAC3 is a message authentication code from H(RU, RS, TK). Step 11. The UE decrypts ENCR_RS using TK to obtain the RS and checks the MAC3 to verify the integrity of the data received in Step 10. Then the user inputs his/her ID UID, password PW, payment instruction Payment, and t2 into UE, and UE generates Reg_Data={UID, Payment, t2, UID_PW_DIGEST, a, b}, where UID_PW_DIGEST=H

(UID, Password). The UE computes {ENCR_Reg_Data, N1, MAC4} and sends them to SP. The ENCR_Reg_Data is the encrypted Reg_Data using TK and MAC4=H(Reg_Data, N1, RU, RS). Step 12. The SP first decrypts the ENCR_Reg_Data and verifies the received message with MAC4. If the validation is verified, SP checks whether the UID has been used. If UID is a new one, SP accepts the payment instruction and the user’s registration data. Otherwise, SP asks the user to select a new UID for registration. Once the user registers successfully, SP computes a=Ht1(a) and b=HZ–t2(b), and stores (UID, UID_PW_DIGEST, t1, t2, a, b) in the User Record. The SP also generates some parameters, Parameters={a, b, Z, N1 + 1}, and computes {RU, ENCR_UID, ENCR_Parameters, MAC5}. Finally, SP sends {RU, ENCR_UID, ENCR_Parameters, MAC5} to UE, where ENCR_UID and ENCR_Parameters are the encrypted UID and Parameters using TK, respectively, and MAC5=H(ENCR_UID, ENCR_ Parameters, RU, RS). Step 13. The UE decrypts the message to check N1 + 1 and the integrity of the ENCR_UID, ENCR_Parameters using MAC5. If they are positive, UE computes Ht1(a) and HZ–t2(b) to compare with a and b, respectively. If they are equal, UE confirms a and b values. Afterward, UE stores {UID, a, b, Z, t2, t1} in a tamper-resistant device (e.g., a SIM card) to protect subsequent communications. Assume that the SIM card’s owner cannot extract the inside data or tamper with UID.

6793

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

USIM/UE

MO

SP

10. HTTP Reply: {Ready_Login, ENCR_RS, MAC3} 11. HTTP Request: {ENCR_SERVICE_REQ} 12. HTTP Reply: {ENCR_STREAM}

Fig. 5. Data flow of the login and access service stage.

3.2.2. Login and access service stage The registered user can access the multimedia content or services from SP, but must perform a mutual authentication process with SP in advance for security reasons. The mobile user and SP share a temporary session key (TK) after the online registration stage is completed. However, to achieve one-time pad high security requirement, a new TK needs to be generated in each session by cooperation of user and MO. Meanwhile, they need to compute a common access control key (AK) to protect their follow-up communications. This stream cipher in the UE and one hold by SP can quickly encrypt the stream of multimedia so that they can perform the following steps to access multimedia services. To simplify our description, we assume that after the user sends a login request to SP, SP will perform Steps 1–9 of online registration stage to authenticate the user and negotiate a new TK between the user and SP. Afterward, the following data flow of the login and access service stage is shown in Fig. 5. We only present detailed procedures for Steps 10–12 as bellow but reader can refer to the discussion of the online registration stage for detailed descriptions of Steps 1–9. Step 10. The SP sends {Ready_login, ENCR_RS, MAC3} to UE. The Ready_Login is a response to UE for the user login. The ENCR_RS is an encrypted message of the RS using a shared key TK. MAC3 is a message authentication code calculated on RU, RS and TK. Step 11. The UE decrypts the received ENCR_RS and checks the MAC3. If it is positive, UE asks the user to input his/her UID, Password, and MID (multimedia identity). Later, UE generates a nonce N2 first and encrypts UID, MID, N2, UID_PW_DIGEST and RS + 1 using the key TK to generate ENCR_SERVICE_REQ. Finally, UE transmits {RU, ENCR_SERVICE_REQ} to SP. Step 12. The SP decrypts the received ENCR_SERVICE_REQ, and verifies UID_PW_DIGEST and RS + 1. If they are valid, SP computes an access control key AK=H(N2  Ht–t1 (a)  Ht2–t(b)) according to four parameters, t1, t2, a, b, which are stored in the User Record in the online registration stage. In addition, SP uses AK as a seed of the stream cipher to encrypt the specified multimedia content whose identity is MID and transmits the encrypted stream to the user. Step 13. The UE computes AK=(N2  Ht–t1(a)  Ht2–t(b)). Then, the stream cipher, which was embedded in UE in advance, uses AK to decrypt the receiving stream. By using the four parameters t1, t2, a, b stored in User Record during the online registration stage, SP not only provides timebounded multimedia content or services, but also controls a user’s access rights during his/her subscription period. We also designed a transfer transaction protocol to implement digital right transfer property as follows.

3.2.3. C. Transfer transaction stage Assume that both users UA and UB are registered users at SP; moreover, UA has been authenticated by MO and SP (by using Steps 1 to 9 in the online registration stage). Therefore, user UA shares an integrity key IKA and a session key CKA with MO and shares a temporary key TKA with SP. Likewise, user UB also has been authenticated by MO and SP so that UB shares an integrity key IKB and a session key CKA with MO, and shares a temporary key TKB with SP. If user UA wants to transfer digital rights to user UB, the ten steps described below must be performed. The transfer transaction data flow is shown in Fig. 6. Detailed descriptions of ten steps are as follows. Step 1. User UA computes a request ENCR_TRANS_REQ and the corresponding message authentication code MAC6 for transfer as follows: ENCR_TRANS_REQ=ETKA(UIDA, UIDA_PW_DIGEST, Ht3–t1 (a), b, UIDB), and MAC6=H(ENCR_TRANS_REQ, T, IKA), where t3 is the serial number of the transfer date (t3 < t2) and T is a timestamp. Then, UA sends (SP_IP, ENCR_TRANS_REQ, T, MAC6) to MO. Step 2. The MO checks whether T is accepted within a predetermined time interval for transmission against a replay attack, which may occur in unsuccessful transfer transactions. If T is within the predetermined interval, MO computes MAC6’=H(ENCR_TRANSFER_REQ, T, IKA) to compare with the received MAC6. If they match, MO forwards (ENCR_TRANS_REQ, T, MAC6) via the SAML protocol to SP. Step 3. The SP decrypts ENCR_TRANS_REQ using a shared key TKA. The SP also verifies UIDA_PW_DIGEST to authenticate user UA. If the UIDA_PW_DIGEST is valid, SP extracts the stored t2 from the User Record. If t2 is greater than t3, user UA’s digital right is still valid for the period between t3 and t2, then SP can perform the follow-up digital right transfer transaction. Otherwise, user UA’s digital right has expired and cannot be transferred. If user UA’s digital right is within valid date and can be transferred, SP extracts a and b from user UA’s record and computes Ht3–t1(a). Later, SP further checks whether Ht3–t1(a) and b are equal to the received Ht3–t1(a) and b. If they are the same, SP can confirm Ht3–t1(a) and b. Step 4. The SP stores (Ht3–t1(a), b, t3, t2) in user B’s record. The SP also marks user A’s record and stores (TRANS_REQ, T, MAC6) in the User Transfer Record as proof that the specific digital right of user UA has been transferred. Step 5. When user UB logins SP, who transmits Transfer_Data to user UB, Transfer_Data is generated as follows: Transfer_Data=ETKB(UIDB, t3, t2, Ht3–t1(a), b, UIDA). Step 6. User UB decrypts Transfer_Data using a temporary key TKB. Later, user UB stores (UIDB, Ht3–t1(a), b, Z, t3, t2) in

6794

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

MO

USIM A

USIM B

SP

1. SP_IP, ENCR_TRANS_REQ, T, MAC6 2. SAML: Request{ENCR_TRANS_REQ, T, MAC6} 3. Verifies UID A_PW_DIGEST 4. Stores

(Ht3-t1(α), , t3, t2) 5. HTTP: {Transfer_Data} 6. Stores

8. NEW_ENCR_CONFIRM, MAC8

(UIDB, Ht3-t1(α), β, Z, t3, t2)

7. ENCR_CONFIRM, MAC 7

9. OK

Fig. 6. Data flow of the transfer transaction.

Step 7.

Step 8.

Step 9.

Step 10.

his/her UE for subsequent access services and sends an acknowledgment to SP. User UB computes ENCR_CONFIRM=ECKB(H(Ht3–t1(a), b, t3, t2)) and MAC7=H(ENCR_CONFIRM, IKB), then transmits ENCR__CONFIRM and MAC7 to MO. The MO decrypts the received ENCR_CONFIRM and checks its integrity using MAC7. If integrity has been retained, MO computes NEW_ENCR_CONFIRM=ECKA (H(Ht3–t1(a), b, t3, t2)) and MAC8=H(NEW_ENCR_CONFIRM,IKA) and sends them to user UA to confirm that transfer has been accomplished. User UA checks the integrity of NEW_ENCR_CONFIRM using MAC8. If it is positive, user UA computes H(Ht3–t1 (a), b, t3, t2) and compares it with the decrypted NEW_ENCR_CONFIRM to verify the transferred digital right. If they are equal, then user UA notifies an OK message to user UB. Otherwise, user UA sends a transfer-error message to user UB and SP, respectively. When user UB wants to login to SP and access his/her multimedia content, both user B and SP compute a common access key AK=H(N2  Ht–t3(Ht3–t1(a))  Ht2–t(b)) to encrypt and decrypt the multimedia streams as described in Steps 12 and 13 in the login and access service stage.

registration or accessing services stages, user privacy cannot be violated.

4.1.2. Mutual authentication The UMTS-AKA mechanism can perform a mutual authentication between USIM/UE and MO. Furthermore, MO can collaborate with SP to build a key agreement mechanism and a secure communication path according to their business alliance contract. In the IDM3G mechanism, MO also assists USIM/UE and SP to perform a mutual authentication, since MO, as a middleman, can verify both parties. Our proposed scheme is based on the IDM3G mechanism; therefore, we also inherit this property.

4.1.3. Confidentiality To achieve data confidentiality, our scheme uses a symmetric encryption to encrypt private and sensitive data. To perform user authentication over 3G networks, in our proposed scheme USIM/ UE and MO use a session key CK to encrypt the exchange data, which is based on the UMTS-AKA specification of 3GPP. During the online registration stage, USIM/UE and SP use a temporary key TK to encrypt/decrypt their communication data. In the login and access service stage, both USIM/UE and SP can compute a common access key AK to encrypt and decrypt multimedia strings.

4. Discussions In this section, we examine the security properties, performance and implementation complexity of the proposed scheme. 4.1. Security analyses To evaluate the performance of our proposed scheme in security properties, we further examine whether our proposed scheme can achieve the following 12 security requirements. 4.1.1. Identity privacy The proposed scheme neither transmits the IMSI nor reveals any permanent subscriber identities over the networks. The MO binds the TMSI with the IMSI and identifies the subscriber via the TMSI to protect the privacy of the subscriber identity against user location tracing and delivered service tracing. Both the TMSI and IMSI are unknown to SP. Besides, each user can arbitrarily choose a UID that has no linkage to IMSI or TMSI. Therefore, during

4.1.4. Data integrity During mutual authentication between USIM/UE and SP, the UMTS-AKA mechanism provides message authentication codes (MAC) to preserve the integrity of the transmitted data. Because both MO and USIM/UE use the same integrity key IK, MO can verify data integrity from USIM/UE, and can calculate the MAC value from SP forwarding data. In addition, when a user registers at an SP, the SP can verify the user’s registration data by checking the received MAC4. The reason is that only the valid user holds the correct RS generating MAC4, which equals H(Reg_Data, N1, RU, RS). Moreover, SP provides parameters that can be verified by the user from checking MAC5=H(ENCR_UID, ENCR_Parameters, RU, RS). Later, the transferred digital right also possesses the data integrity property because MO helps SP and the user UB to verify the transferred data integrity from checking MAC6==H(ENCR_TRANS_REQ, T, IKA). With these protections, our proposed scheme satisfies the data integrity requirement.

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

4.1.5. Replay attack protection The proposed scheme involves four key elements to prevent replay attacks. The first is that the IK and CK are fresh for each authentication procedure. Dynamic TMSI is the second key element that can protect USIM/UE against location tracing. The third key element is the RU, RS and MAC calculation to preserve data integrity, because the RU and RS are randomized for each user’s registration and login. The fourth key element is that MO sets a lifetime of the ticket to prevent replay attack as described in Step 5 in the online registration stage. In the login and access control stage, if an attacker collects a transmitted ENCR_Service_Req and performs a replay attack, it will fail. The major reason is that SP checks RS + 1 value, which will be different in each session. Even if an attacker can intercept a valid user’s connection and replay ENCR_Service_Req to SP, the attacker still cannot decrypt the multimedia string from SP because he/she cannot compute AK=H(N2  Ht–t1(Ht1(a))  Ht2–t(HZ–t2(b))) without the related data. 4.1.6. Man-in-the-middle attacks According to Neimi and Nyberg’s definitions (Neimi & Nyberg, 2003), man-in-the-middle attacks contain entity impersonation, session hijacking, eavesdropping, tampering and replay. Our scheme incorporates confidentiality, integrity, mutual authentication, and replay protection. Therefore, the proposed scheme can prevent man-in-the-middle attacks. 4.1.7. Brute force and dictionary attacks In our proposed login and access service stage, each user uses a password to generate the UID_PW_DIGEST. Even if an attacker can perform a data dictionary attack to obtain a valid password; he/she still cannot forge a valid service request. A valid service request consists of UID, MID, N2, UID_PW_DIGEST, RS + 1 and is encrypted by a shared key TK. Because the TK remains out of reach of an attacker, he/she cannot forge a valid ENCR_Service_Req. 4.1.8. Cryptographic keys derivation The three cryptographic keys used in our proposed scheme are CK, IK and TK. Because the CK and IK used in our scheme are generated according to UMTS-AKA specifications, their security of the key derivation has been guaranteed according to those discussions in IETF (2006). Therefore, we only discuss the security of the TK here. The TK is a temporary key used to encrypt messages between a user and an SP. In our scheme, USIM/UE uses the CK to encrypt the TK as ENCR_TK=ECK(TK) and the IK to generate the message authentication code MAC1=H(IK, RU, SP_IP, TK), respectively. Later, USIM/UE sends the encrypted TK ENCR_TK and its MAC1 to MO, who can verify the integrity of the TK. Later, MO uses the preestablished business key to protect the TK and send it to SP using SAMLprotocol. Thus, the security of the TK in our proposed scheme is based on UMTS-AKA and SAML standards, which means the security of the TK is also guaranteed. 4.1.9. Security of access control key Because no one can compute AK==H(N2  Ht–t1(a)  Ht2–t(b)) except a valid user and an SP, the security of an access control key is ensured. Besides, the AK=H(N2  Ht–t1(a)  Ht2–t(b)) is computed by using four confidential parameters, t1, t2, a and b. The attacker cannot derive the AK from the encrypted stream. As for N2, it can be a large number involving up to 128 bits, so it would be hard to guess N2. Even if a user accidentally leaks a and b, malicious attackers still cannot compute the AK. The major reason is that malicious attackers cannot obtain N2, which is generated independently when a user wants to login and access service from an SP.

6795

4.1.10. Time-bound property of the access key If a valid user has an access right for a period from t1 to t2 and attempts to compute an access key of t5 to violate the valid t1-tot2 interval, the user must first compute AK=H(N2  Ht5–t1 (Ht1(a))  Ht2–t5(HZ–t2(b))). However, computing Ht2–t5(HZ–t2(b)) is infeasible because t2 is less than t5 so that t2–t5 is negative. On the other hand, when an SP detects that t2 is less than t5 in computing the AK, SP judges that the digital right of the user is overdue. That is, SP will reject the service request from this user. 4.1.11. Security of transferred digital rights If user UA wants to transfer a digital right to user UB in our proposed scheme, after the transfer stage is completed, user UB obtains (UIDB, Ht3–t1(a), b, Z, t2, t3). Because user UA is the previous owner, he/she may violate the ownership of the digital rights owned by user UB. To prove that our proposed scheme can protect the transferred digital rights, we discuss forward secrecy and backward secrecy in the following paragraphs. (a) Forward secrecy: In our proposed scheme, user UA cannot use a transferred digital right to access services from an SP after the digital right is transferred. For example, user UA cannot compute user UB’s access key AK=H(N2  Ht–t3(Ht3–t1 (a))  Ht2–t(b)) since the nonce value N2 is determined by the user UB. In addition, user UA cannot successfully impersonate user UB because user UA cannot obtain user UB’s UID_PW_DIGEST. (b) Backward secrecy: In our proposed scheme, user UB also cannot use the transferred digital right to decrypt multimedia streams that have been downloaded by or granted to user UA before a digital right is transferred without user UA’s assistance. The major reason is that user UB cannot compute user UA’s access key AK=(N2  Ht–t1(a)  Ht2–t(b)), where N2 is generated by user UA. 4.1.12. Non-repudiation Once a digital right has been transferred, users UA, UB and SP cannot deny this transfer for the following reasons. First, MO verifies the request time and integrity of the ENCR_TRANS_REQ from user UA in Step 4 of the transfer stage; hence, user UA cannot deny that he/she has asked to transfer the digital right. Second, user UB cannot deny that he/she received the transferred digital right, since he/she must send an acknowledgment to SP in Step 8 of the transfer stage before he/she receives the transferred digital rights. Finally, SP cannot cheat user UA or user UB because once SP rejects the request to send or tampers with the transferred digital right, user UA will discover it by checking NEW_ENCR_CONFIRM. 4.2. Efficiency analyses In this subsection, we present the efficiency of our proposed scheme. Advantages of the proposed scheme are follows. 1. The proposed scheme does not require the public key infrastructure. In our proposed scheme, all encryption procedures use only symmetric encryption instead of public key cryptosystems. Therefore, our scheme can be applied in wireless or 3G networks without requiring support from the public key infrastructure. 2. The scheme has no exponential computation. Our scheme does not require any exponential computation and asymmetric encryption computation. This arrangement successfully decreases the computation cost and speeds up response time.

6796

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797

Table 3 Number of computations and exchanged messages in our scheme. Items Stages IDM3G Registration stage Login stage Transfer transaction

Number of messages exchange

Number of random numbers generation

Number of message integrity checks

Number of symmetric key en/decrypt-ions

6 9 9 16

1 4 2 2

2 5 3 5

10 16 16 20

Therefore, it can be easily applied in mobile devices, and it can provide better service in the efficiency and security. 3. The scheme provides efficiency in computation and transmission rounds. In IDM3G (Dimitriadis & Polemi, 2006), the computation cost contains one random number generation, two message integrity checks, and six message exchanges, as well as ten computations for symmetric en/decryption. Our scheme integrates IDM3G to handle digital rights management over 3G networks. Table 3 lists the number of computations and transmission rounds in our proposed scheme with IDM3G incorporated. As showing the following table, in the online registration stage and login and access service stage, our scheme has more three numbers of data operations in message exchange, random number generation and integrity checks than IDM3G. As well as, the number of symmetric key en/decryptions in the online registration stage and login and access service stage of our scheme is six times more than IDM3G. That means our scheme increases costs by only a fraction over the IDM3G scheme. Furthermore, the number of symmetric key en/decryptions is up to 20 times greater in our transfer transaction stage. However, the speed of each encryption or decryption computation is still faster than a TCP connection, according to Table 4 (Schneier, 1996), with only a slight effect on response delay.

4.3. Implementation complexity To maintain efficiency in computation and transmission rounds, our scheme employs simple and fast computations instead of complex exponential computations. Keeping the computations simple and fast makes our scheme suitable for the limited power and computation ability of mobile devices. We further discuss the complexity of implementing the proposed scheme in the following paragraphs.

4.3.1. User equipment In our proposed scheme, UE must have the basic functions that satisfy the requirements of the Liberty Alliance protocols (Liberty Alliance, 2003), including the HTTP and WML protocols. The existing standards and computation functions in the UE are enough to implement the proposed scheme.

Table 4 Comparison of computation and network connection speeds (Schneier, 1996). Operation

Number of operations per second

Public key signature (1024 bits RSA) Symmetric key encryption (DES) One-way hash function (MD5/SHA) Network connection (TCP/internet)

2 2000 20,000 1000

4.3.2. Mobile operator In existing 3G systems, the mobile operator provides secure databases and management mechanisms to maintain subscribers’ personal data and communications. Therefore, an existing MO can play the role of verifier between users and service providers. At the same time, MO can take charge of forwarding the transferred digital right between the sender and the receiver without adding extra cost. 4.3.3. Service provider In our proposed scheme, the service provider must implement a secure path with MO using the SAML protocol. Moreover, the service provider must perform some simple mechanisms to manage and store subscribers’ data to grant access rights and key agreements. In summary, the proposed scheme can simply apply existing mobile equipment and service providers’ management mechanisms to manage digital rights and transfer transactions, which requires only minimal implementation costs for all participants. Therefore, our scheme offers a practical and feasible solution to secure content transmission over wireless 3G networks. 5. Conclusions In this paper, we propose a scheme for secure digital rights management of multimedia content or services over 3G mobile networks. It can fulfill all strict security requirements, while keeping computation loading very light. Furthermore, our proposed scheme not only controls subscribers’ access rights but also provides privacy protection. Therefore, our scheme provides a fair and efficient access control mechanism for digital rights with low computation costs. In our proposed scheme, we successfully improve upon Dimitriadis and Polemi’s IDM3G to design a fair and secure digital rights management of multimedia over 3G networks, which makes our proposed scheme more practical and easy to implement in the future. References Cox, I. J., Miller, M. L., & Bloom, J. A. (2002). Digital watermarking. Academic Press. Dimitriadis, C. K., & Polemi, D. (2006). Identity management protocol for internet applications over 3G mobile networks. Computers and Security, 25(1), 45–51. Foroughi, A., Albin, M., & Gillard, S. (2002). Digital rights management: A delicate balance between protection and accessibility. Journal of Information Science, 28, 389–395. Fujimura, K. (1999). Digital-right trading infrastructure (DRTI). In Proceedings of the 46th internet engineer task force (IETF), Washington, DC, USA. Available from http://www.ietf.org/proceedings/99nov/slides/trade-drti/index.htm. Fujimura, K., & Nakajima, Y. (1998). General-purpose digital ticket framework. In Proceedings of the 3rd USENIX workshop on electronic commerce, Boston, Massachusetts, USA (pp. 177–186). Fujimura, K., Kuno, H., Terada, M., Matsuyama, K., Mizuno, Y., & Sekine, J. (1999). Digital-ticket-controlled digital ticket circulation. In Proceedings of the 8th USENIX security symposium, Washington, DC, USA (pp. 229–238). The Internet Engineering Task Force (IETF) (2006). RFC 4187, Extensible authentication protocol method for 3rd generation authentication and key agreement (EAP-AKA). Available from http://www.ietf.org/rfc/rfc4187.txt/.

C.-C. Wu et al. / Expert Systems with Applications 37 (2010) 6787–6797 Liberty Alliance (2003). Liberty ID-FF bindings and profiles specification, ver. 2.0. Available from http://www.projectliberty.org/liberty/content/download/319/ 2369/file/draft-liberty-idff-bindings-profiles-1.2-errata-v2.0.pdf/. Muir, A. (2004). Digital preservation: awareness, responsibility and rights issues. Journal of Information Science, 30, 73–92. Neimi, V., & Nyberg, K. (2003). UMTS security. John Wiley and Sons. OASIS (2005). Glossary for the OASIS security assertion markup language (SAML), ver. 2.0, 2005. Available from http://www.docs.oasis-open.org/security/saml/ v2.0/. Schneier, B. (1996). Applied cryptography (2nd ed.). Wiley.

6797

SDL Forum Society (2000). What Is An MSC. Available from http://www.sdlforum.org/MSC/. Third Generation Partnership Project (2000). TS 31.101, UICC terminal interface; physical and logical characteristics, ver. 3.0. Available from http:// www.3gpp.org/ftp/Specs/html-info/31101-CRs.htm/. Third Generation Partnership Project (2006). TS 33.102, 3G security; security architecture, ver. 7.0. Available from http://www.3gpp.org/ftp/Specs/archive/ 33_series/33.102/. World Wide Web Consortium (2008). Extensible markup language (XML). Available from http://www.w3.org/XML/.