Integrating identity-based cryptography in IMS service authentication

The IP Multimedia Subsystem (IMS) [1], is an architectural framework for delivering Internet Protocol (IP) multimedia services. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), as a part of the vision for evolving mobile networks beyond Global System for Mobile Communications (GSM). The IMS provides multimedia services (such as Voice over IP (VoIP), video conferencing, presence, push-to-talk etc.) on top of all IP networks as well as NGN (Next Generation Networks). IMS provides a unique architecture for authentication and accounting of different services. Each subscriber uses an ISIM (IMS-SIM) card with a stored secret key to be able to authenticate to the IMS network and to be able to access the IMS services. One requirement provided in IMS, is the tight attachment of the subscriber authentication to the User Equipment UE since the ISIM card participates in the Authentication and key Agreement (AKA) [2]. Therefore, the keys are not generated from the user Identity but are randomly chosen by the Home Subscriber Server (HSS). Consequently, IMS authentication falls short in one hand to realize authentication in a personalized manner, which is an important prerequisite in new services such as social internet ones. Moreover, using AKA in IMS proved to have some weakness, like short key for cryptographic purposes [3], [4]. Many solutions are provided to strengthen IMS security. Wu et al [5] define a new AKA based on Elliptic Curve Cryptography (ECC) and Huang et al [6] define a new AKA called one pass AKA for UMTS. Furthermore, Ring et al [7] tried to design a new AKA mechanism for Session Initiation Protocol (SIP) using Identity Based Cryptography (IBC) [8]. However, these works were only done for the subscriber authentication with nothing special on service authentication. In this paper, we propose a new authentication scheme for services authentication in IMS. Our proposed scheme is an Identity based authentication type which in turn allows users' identification with a certain sort of personalization. The key advantage of IBC lies in its simplicity and robustness. Moreover, our solution proposes an Identity based batch verification which will decrease the verification time for simultaneous clients requesting service authentication. The remainder of this paper is organized as follows: Section 2 describes the IMS service authentication process. Section 3 gives an overview on the IBC mechanism. In Section 4, we present our novel solution, and in Sections 5, we analyse its security. In Section 6, we briefly discuss the performance analysis that we carried out and we conclude the paper in Section 7. Third Generation Partnership Project (3GPP) has provided the bootstrapping of application security to authenticate the subscriber by defining a Generic Bootstrapping Architecture (GBA) [9] based on Authentication and Key Agreement (AKA) protocol. The GBA model can be utilized to authenticate subscriber before accessing multimedia services and applications over HTTP. The GBA consists of five entities [10]: • The UE (User Equipment): is a UICC (Universal Integrated Circuit Card) containing USIM or ISIM related information that supports HTTP Digest AKA (Authentication & Key Agreement) • The BSF (Bootstrapping Server Function): participates in the GBA through mutually authenticating with the UE using the AKA protocol, and agreeing on session keys that are afterwards applied between UE and the NAF. • The NAF (Network Authentication Function): has the functionality of locating and communicating securely with subscriber's BSF • The HSS (Home Subscriber Server): is the master database of IMS that stores IMS user profiles. There are two types of identities that are associated with an IMS user. In order to allow the access to services over HTTP in a secure manner, IMS uses the Generic Bootstrapping Architecture (GBA) [9]. The GBA performs authentication between the Bootstrapping Server Function (BSF) and the UE, which is also based on AKA. Figure 1 shows the GBA authentication for services access in IMS. Figure 1: GBA Authentication Before the service access, the UE communicates with the NAF to verify if the bootstrapping procedure is needed (message 1). If it is the case and if there are no available bootstrapping parameters in the UE (message 2), the UE will contact the BSF by sending an HTTP request including the private user identity (message 3). Then, the BSF contacts the HSS to get the GBA User Security Setting (GUSS) and the Authentication Vector (AV) which includes RAND, AUTN, CK, IK and XRES (messages 4-5). In order to demand the UE to authenticate itself, the BSF then forwards the RAND and AUTN to the UE in a "401 (Unauthorized) message" without including the CK, IK and XRES (message 6). The UE then checks AUTN (following the same procedure described in IMS authentication) to verify that the challenge is from an authorized network; and calculates CK, IK and RES. This will result in session keys IK and CK in both BSF and UE. The UE sends another HTTP request to the BSF, containing the Digest AKA response which is calculated using RES (message 7). The BSF authenticates the UE by verifying the Digest AKA response and generates key material Ks by concatenating CK and IK. The BSF also generates B-TID (Bootstrapping Transaction Identifier) and sends a "200 OK message", including the B-TID to the UE to indicate the success of the authentication (message 8). The UE uses CK and IK to calculate the key material Ks and both the UE and BSF use the Ks to derive the key material Ks-NAF. The UE contacts the NAF and provides the B-TID and a digest calculated using Ks_NAF (message 9). The NAF then requests the corresponding Ks_NAF and GUSS from the BSF by sending B-TID (message 10). After receiving the BSF response (message 11), the NAF calculates the digest values using Ks_NAF and compares the calculated values with the received ones from the UE to be able to authenticate the UE (message 12). We notice that the BSF is the entity which communicates with all the other entities and has the important role to verify the UE's signatures. In real cases, there will be simultaneous UEs requesting for authentication and this will lead to a potential bottleneck of signature verification at the BSF. The Identity Based cryptography (IBC) has emerged as a long-term evolution or substitution to Public Key Infrastructure PKI. It is a cryptosystem in which the public key is retrieved from an identity of the entity (user) and the private key is more precisely the public key multiplied by the secret key of the server. The latter is responsible of the private key distribution and is called the Private Key Generator (PKG). The IBC concept is old and was first proposed by Shamir in 1984 [11], then the first fully practical and secure identity-based public key encryption scheme was presented by D. Boneh and M. Franklin in [8], using the fundamental operations of Elliptic Curve Cryptography (ECC). Since then, a rapid development of Identity based cryptosystems has taken place. The IBC is based on the bilinear pairing which is presented later. Shamir's original motivation for identity-based encryption was to simplify the certificate management in e-mail systems. This solution is illustrated in Figure 2. Let (G1; +) and (G2; .) be two cyclic groups of prime order q. G1 is an additive group and G2 as a multiplicative group. The bilinear pairing is given as e: G1 * G1  G2, which satisfies the following properties: 1. Bilinearity: For all P; Q, R ∈ G1; e(P + Q, R) = e(P, R). e(Q, R) and e(P, Q + R) = e(P, Q). e(P, R); 2. Non-degeneracy: There exists P; Q ∈ G1 such that e(P, Q) ≠ 1; 3. Computability: It is efficient to compute e(P, Q) ∀ P; Q ∈ G1. A bilinear map satisfying the three properties above can be considered as an admissible bilinear map [8]. In IBC, the public key is usually related to the public identity of the user (for example, email addressee). The following functional aspects are always present in any IBC cryptosystem. 1. System Setup: IBC systems rely on a trusted central authority that manages the parameters with which keys are created. This authority is called the Private Key Generator (PKG). The PKG creates its parameters, including a master secret S used to generate the private keys for users. The system parameters are: the order q, the prime number p, the generator point P, PKG public point Ppub= S.P and the hash functions. 2. Encryption: When a user (Alice) wishes to send an encrypted message to another user (Bob), she encrypts the message to him by computing or obtaining the public key, KpubBob, and then encrypting a plaintext message M with KpubBob to obtain cipher message C. When Bob receives the message, he wants to decrypt it. He authenticates himself to the PKG and obtains the secret key KprivBob that he uses to decrypt the cipher message C. When Bob receives KprivBob, he decrypts the cipher message C to obtain the plaintext message M. In some architectures we need to verify a signature to authenticate the users, where the party concerned by the verification presents a bottleneck in the system if the load is high (case of many users asking for authentication). One solution is the Batch verification which consists on the verification of all the signatures received in a time window with rather short time compared to verifying each signature one after the other. The batch cryptography based on RSA was introduced by Fiat [12] in 1989. Some other batch signature schemes were proposed later like [13]. Zhang et al [14] used 3 pairing operations to verify a single signature. To verify n signatures, they needed 3 pairing operations instead of 3n pairing operations. In other words, the verification time of the dominant operation (i.e., pairing) is independent of the number of signatures to verify [14]. As a result, the time spent on verifying a large number of signatures will be decreased. In this section, we describe our novel solution which uses IBC in the IMS GBA authentication to generate the private keys of the UE instead of using AKA mechanisms. Our objective is to personalize the IMS service authentication process through using IMPU. This new scheme will lead to better performances when there are simultaneous authentication requests thanks to using Identity-based Batch Verification. The HSS has a PKG server which has the role to generate the private keys for the UE. We use bilinear map e: e: G1 * G1  G2. The PKG randomly chooses s1, s2 ∈ Z * q as its two master keys, and computes Ppub1 = s1.P, Ppub2 = s2.P as its public keys. In our work, we assume that the UE has the shared key sk with HSS and the PKG parameters (order q, prime number p, P, Ppub1, Ppub2 and MapToPoint function) stored in the ISIM card. We present in Table 1, all the notation used in the solution. The generator of the cyclic additive group G1 A bilinear map: G1 × G1 → G2 The order of the group G1 A random nonce The private master keys of the PKG The public keys of the PKG, Ppub1 = s1.P and Pub2= s2.P A MapToPoint hash [8] function such as H : {0, 1}* → G UEID = H(IMPU) The public keys of the UE i The private keys of UE i , SK i 1 = s1.Ppub1 and SK i 2 = s2.Ppub2 A one-way hash function such that SHA-1 Message concatenation operation, which appends several messages together in a special format The proposed solution is explained in the following steps. In Figure 3, we illustrate all the messages exchanged to authenticate the ith UE (UE i ). Step 1. (messages 1 and 2) UE i starts communication with the NAF without GBA parameters. If the NAF requires the use of shared keys obtained by means of the GBA, but the request from the UE does not include GBA-related parameters, the NAF replies with a bootstrapping initiation message. Step 2. (messages 3, 4 and 5) UE i sends a HTTP request to the BSF (Bootstrapping Server Function) including its IMS private user identity (IMPI i ) and public user identity (IMPU i ). The BSF then retrieves from the HSS: 1. the public keys Kpub i 1and Kpub i 2 (generated using IMPU i ) from the PKG. Kpub i 1 = r. P and where r is a random number, ⊕ XOR operation and UEID = H(IMPU i ) 2. the complete set of GBA user security settings (GUSS i ), 3. an Authentication Vector (AV i ) containing the RAND i and PKG parameters, 4. the private keys Kpriv i 1and Kpriv i 2 encrypted with shared key sk where Kpriv i 1 = s 1 . Kpub i 1 and Kpriv i 2 = s 2 . H(Kpub i 1 || Kpub i 2 ) Step 3. (message 6) In order to demand the UE i to authenticate itself, the BSF forwards Kpub i 1, Kpub i 2, [Kpriv i 1]sk and [Kpriv i 2]sk and RAND i to the UE in the "401 (Unauthorized) message". Step 4. (message 7) The UE i extracts its private keys Kpriv i 1and Kpriv i 2 using the shared key sk which is stored in the ISIM card. Then, the UE i hashes the RAND i and computes the signature Sig i 1 where: Sig i 1 = Kpriv i 1 + h(RAND i ) . Kpriv i 2 The UE i sends IMPU i , RAND i , Sig i 1 to the BSF in an HTTP request. To verify the UE i 's signature, the BSF has already the PKG parameters and Kpub i 1and Kpub i 2 corresponding to IMPU i . Sig i 1 is valid if e(Sig i 1 , P) = e(Kpub i 1 , Ppub 1 ) . e(h(RAND i ). If the verification phase is successful, then, the user is authenticated. This is how equation 1 is computed: e(Sig i 1, P) = e(Kpriv i 1 + h(RAND i ) . Kpriv i 2, P) = e(Kpriv i 1, P) . e(h(RAND i ).Kpriv i 2, P) = e(s1.Kpub i 1, P) . e(h(RAND i ).s2.H(Kpub i 1 || Kpub i 2), P) = e(Kpub i 1, s1.P) . e(h(RAND i ).H(Kpub i 1 || Kpub i 2), s2.P) = e(Kpub i 1, Ppub1) . e(h(RAND i ).H(Kpub i 1 || Kpub i 2), Ppub2) Step 5. (message 8) After the successful verification, the BSF generates B-TID i (Bootstrapping ID) and stores it with the IMPU i and GUSS i . Then, the BSF sends to the UE a "200 OK message" including the B-TID i encrypted with UE i 's public key kpub i 1 (BSF can use any asymmetric elliptic curve algorithm). After receiving the message, the UE retrieves the B-TID using Kpriv i 1. In our solution, there is no key material Ks stored in the UE and the BSF. Our system is based on asymmetric cryptography. The shared key sk between the UE i and the HSS is used to encrypt the UE i 's Kpriv i 1and Kpriv i 2. The BSF cannot retrieve these keys and has to encrypt B-TID i using UE i 's kpub i 1. Step 6. (message 9) The following steps apply Elliptic Curve Diffie-Hellman (ECDH) Protocol. This key agreement protocol will be used to generate the Ks-NAF key. The UE i and the NAF first have to agree whether to use the shared keys obtained by means of the GBA. The UE i chooses a random value 'a' to generate 'a. Kpub i 1' and provide the IMPU i , B-TID i , 'a. Kpub i 1', and a signature of B-TID i to the NAF to allow it to retrieve the corresponding keys from the BSF. The Signature of BTID i is: Step 7. (message 10) The NAF sends to the BSF the NAF-ID, the IMPU i , B-TID i and Sig i 2 to request for GUSS i and PKG parameters. NAF-ID is used by the BSF to verify that the NAF is authorized to use that hostname. Step 8. (message 11) First of all, the BSF verifies the signature using Kpub i 1and Kpub i 2 (same verification as in step 4, equation ( 1)). Then, it retrieves the GUSS i and PKG parameters using B-TID i and IMPU i . Finally, it supplies to the NAF the IMPU i , Kpub i 1 and Kpub i 2, GUSS i , and the PKG parameters. Step 9. (message 12) The NAF checks the authentication and the authorization of the UE i to the services according to the received GUSS i and then generates a random value 'b' and send to the UE i 'b. Kpub i 1'. After receiving the message, the UE i and the NAF will have the same Ks-NAF = a.b.Kpub i 1. Once the execution of the protocol is completed, the UE i and the NAF will communicate in a secure way and UE i will be granted the services. To verify Sig i 1 and Sig i 2, the BSF needs one MapToPoint hash (H), one multiplication, and three pairing operations. We estimate that the computation cost of a pairing operation is much higher than the cost of a MapToPoint hash and a multiplication operation. We suppose that we have n UEs which belong to the same HSS and communicate through the same BSF. The latter will receive (IMPU 1 , RAND 1 , Sig 1 j), (IMPU 2 , RAND 2 , Sig 2 j), ..., (IMPU n , RAND n , Sig n j), respectively, which are sent by n distinct UEs UE 1 , UE 2 , … UE n and j= 1 or 2. We just focus in this paragraph on j = 1 because it is respectively the same for j = 2. All the signatures, denoted Sig 1 1, Sig 2 1, …, Sig n 1, are valid if (2) We proceed like this to give the details of equation 2: Our proposed solution has a number of advantages as follows: 1. The applied batch verification can dramatically reduce the verification delay, particularly when verifying a large number of signatures. From the batch verification equation ( 2), the computation cost that the BSF spends on verifying n signatures is dominantly comprised of n MapToPoint hash, n multiplication, 3n addition, n one-way hash, and 3 pairing operations. Without the batch verification we will have 3n pairing operations to realize. 2. Our proposed solution doesn't use AKA-MD5 in the GBA and provides more simplicity since it is based on Elliptic Curve Cryptography (ECC). Therefore, it is more efficient and preferable in the applications that require low memory and rapid transaction. Furthermore, for elliptic-curve-based protocols, it is assumed that finding the discrete logarithm of an elliptic curve element is infeasible. Our system is based on asymmetric cryptography, where the shared key ks between the UE and the HSS is used to encrypt the UE's private keys. We don't need to have mutual authentication with the BSF. The latter cannot retrieve these keys and has to encrypt B-TID using UE's Kpub1. Then, even if there is no mutual authentication between the UE and the BSF, security will be always guaranteed. The UE based frauds lead to illegitimate use of IMS services with stolen credentials. In the following, we analyze the Eavesdropping attack and we show the robustness of our proposed solution against this attack. In our point of view, it is the most common attack on IMS. We also explain how the message authentication is secure. All the messages used in this section are the ones illustrated in Figure 3. During the authentication phase (messages 3 to 8), a malicious user can play the role of a Man in the Middle (MITM), listens to the communication and retrieves the GUSS related to the IMPI and IMPU of the legitimate user. The malicious user then tries to connect to the system using his ISIM card (containing his private identity IMPI' and the legitimate's IMPU). The HSS will reject the request because it doesn't have the couple (IMPI', IMPU) in its database. In the proposed scheme, the signature Sig1 = Kpriv1 + h(RAND) . Kpriv2 is actually a one-time identity based signature (for each authentication, the HSS chooses a different random number r). Without knowing the private key Kpriv1 and Kpriv2, it is infeasible to forge a valid signature. Because of the NP-hard computation complexity of Diffie-Hellman problem in G, it is difficult to derive the private keys Kpriv1 and Kpriv2 by using Kpub1, Ppub1, P, and H(Kpub i 1 || Kpub i 2). At the same time, because Sig1 or Sig2 is a Diophantine equation [14], by only knowing Sig1 and h(RAND) (or Sig2 and h(B-TID)), it is still difficult to get the private keys. Therefore, the onetime identity-based signature is unforgeable, and the property of message authentication is fully satisfied. In this section, we evaluate the performance of the novel proposed solution especially for verifying the delay caused by the BSF. We believe that IBC performance is the most critical point that can judge the feasibility of deploying our solution, and the measures that we got are not discouraging especially with the use of Batch Verification. For the whole scenario, the most important parameter influencing the performance will be the speed of the cryptographic operations (such as private/public key pair generation, encryption/decryption, and signature/verification time). In this performance analysis, we mainly measure the speed of the cryptographic operations, without considering the underlying network architecture at this phase. We estimate that the BSF will be the bottleneck of the service authentication process since it processes many HTTP messages and has the important role to verify the UE's signatures. We notice the existence of IMS platforms [15] however without any implementation of the GBA Authentication for services access that why we need to implement our own testbed. We implemented the PKG, which is found within the HSS, through employing the IBE demo provided within Miracl library [16]. We use the elliptic curve y 2 = x 3 + 1 mod p where p is 256 bits prime number. In the following, all the measures are real measures from the implementation realized using an Intel® Core ™2 CPU T5470 @ 1,60GHZ. We observed that the time needed to generate PKG parameters (160 bits q, 256 bits q, 512 bits point P, 512 Point Ppub, 160 bits secret S and 512 bits cube root of unity in Fp2) is around 14 ms. To generate Kpub1 and Kpub2, we use a MapToPoint function, which has the role of finding a point in the curve corresponding to the Hash of the IMPU. We found that the time needed for MapToPoint Tmtp will be in the order of 4,4 ms. To generate Kpriv1 and Kpriv2, the PKG needs almost 7,5ms. The time needed for bilinear pairing Tbp is about 9,3 ms and the time for multiplication Tmul is about 1,5 ms. For the verification of Sig1 or Sig2, we need 3 bilinear pairings, 1 MapToPoint and 1 multiplication, so for 1 person Tv = 3 Tbp + Tmtp + Tmul ≈ 33,8 ms. The BSF has a maximum capacity, we note as N. If we have more than N UEs simultaneously requesting authentication, the system will reject or delay the answer. With the Batch Verification, this can be avoided since the verification for n signature will cost 3 bilinear pairings, n MapToPoint and n multiplication. Table 2 shows the time needed that we deduced for different number of UEs (we choose N >=1000 UEs). From the performance point of view, the asymmetric system seems to need more time to finish all operations than symmetric one but this is not harmful to our work. Furthermore, from the security point of view, the identity Based Cryptography IBC is more secure (using 160 key instead of 128 key for AKA) and we calculated that we need about 4 min to authenticate 50000 UEs, and it seams to be an encouraging result. IP Multimedia Subsystem (IMS) merges the internet with the cellular world to provide ubiquitous access to internet technologies and to provide consumers with appealing services. IMS authentication falls short in one hand to be realized in a personalized manner, which is an important prerequisite in new services such as social internet ones. On the other hand, using AKA in IMS proved to have some weakness, like short key for cryptographic purposes. In this paper, we integrate the Identity Based Cryptography (IBC) in the IMS Service Authentication scheme. Since IBC is based on Elliptic Curve Cryptography (ECC), it is more efficient and preferable in the applications that require low memory and rapid transaction. Security is assured thanks to using of symmetric protocol with a shared key (ks) between the UE and the HSS, an asymmetric protocol for signature, and Diffie-Hellman for key agreement. We define a Batch Verification on the Bootstrapping Server Function BSF to decrease verification delay and the authentication response time. We analyzed some security aspects of the solutions and we showed that our proposed solution can prevent against the attacks. To validate the performance of our proposed solution, we implemented the cryptographic operation in our proposed solution including the IBC procedures. We observe that the use of asymmetric cryptographic procedures will lead to longer running time than symmetric procedures. However, the Batch Verification helps the BSF to verify the UEs signature in a reasonable time. As a future work, we need to improve our testbed by integrating it to an IMS core for a complete authentication session and to perform tests in realistic network conditions. International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009