Patent Application
20090259851
The present invention relates to user authentication techniques and, more particularly, to methods and apparatus for user authentication in IP-based telephony networks.
The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia to mobile users. An IMS network is typically divided into an access domain and a network domain, each having its own security specification. A user may access an IP network via the access network of an access network provider, and then access different services, such as voice, video and streaming media, through one or more service networks provided by one or more service network providers.
Authentication in an IMS network is typically based on the known Authentication and Key Agreement (AKA) mechanism. AKA is a security protocol typically used in 3G networks. AKA is a challenge-response based authentication mechanism that uses a shared secret and symmetric cryptography. AKA results in the establishment of a security association (i.e., a set of security data) between the user equipment and the IMS network that enables a set of security services to be provided to the user.
Public cryptography has not been widely employed in the telephony domain. There is a growing trend, however, to employ a public key infrastructure (PKI) for authentication in the telephony domain, such as in IMS networks. While public cryptography techniques can significantly improve the security of an IMS network, there are a number of technical considerations that have previously limited the use of public cryptography techniques in IMS networks. In particular, there is a concern that the private keys can be recovered from the allegedly “secure” volatile memory contained in the user equipment. Thus, any solution that would allow even temporary storage of private keys in a terminal memory is deemed unacceptable.
A need therefore exists for end user-to-network authentication based on the Public Key Infrastructure (PKI) within an IMS network. Another need exists for methods and apparatus for authenticating a user in an IMS network that ensure that the private keys are stored on a secure smart card or another secure memory. Yet another need exists for methods and apparatus for authenticating a user in an IMS network that ensure that all computations that involve the private keys are performed on the secure smart card or another secure processor.
Generally, methods and apparatus ate provided fox user authentication using a Public Key Infrastructure (PKI) in an IP-based telephony environment, such as an IMS network. According to one aspect of the invention, an authentication method is provided that is performed by a user device attempting to access an IP-based telephony network. One or more private keys of the user are initially obtained from a secure memory associated with the user device. The secure memory may be, for example, a component of a smart card having an IMS Subscriber Identity Module (ISIM) that can securely stole data and perform computations on the data. Thereafter, the disclosed method generates an integrity key and a ciphering key; encrypts the integrity key and the ciphering key using a session key; encrypts the session key with a public key of the IP-based telephony network; and provides the encrypted session key, encrypted integrity key and encrypted ciphering key to the IP-based telephony network fox authentication.
According to another aspect of the invention, a method is provided for authenticating a user employing a user device attempting to access an IP-based telephony network. The user is authenticated by obtaining an encrypted session key encrypted with a public key of the IP-based telephony network; obtaining an encrypted integrity key and encrypted ciphering key from the user device, wherein the integrity key and the ciphering key were generated by a secure device associated with the user device using one or more private keys of the user; decrypting the encrypted session key using the public key of the IP-based telephony network; decrypting the encrypted integrity key and encrypted ciphering key using the decrypted session key; and authenticating the user device based on a Public Key Infrastructure (PKI) computation.
In various exemplary implementations, one or more of the encrypted session key, the encrypted integrity key and the encrypted ciphering key can optionally be encrypted using the one or more private keys. In addition, a user identity can be encrypted using the session key. In this manner, the user identity can be obtained only by a holder of the session key. A nonce can be employed to protect against a replay attack.
A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings.
The present invention provides end user-to-network authentication based on the Public Key Infrastructure (PKI) within an IMS network. According to one aspect of the invention, a user is authenticated in an IMS network using one Or more private keys that are stored, for example, on a secure smart card having an IMS Subscriber Identity Module (ISIM), or a secure set-up box for IPTV, associated with the user equipment. According to another aspect of the invention, when a user is authenticated in an IMS network, all computations that involve the private keys are performed on the secure smart card or another secure processor. As used herein, a “secure” device, such as a smart card, shall comprise a device that satisfies one or more predefined security standards. For example, a smart card having an ISIM shall comprise a secure smart card.
Generally, the disclosed pubic key cryptography techniques perform a mutual end user-to-network authentication for an IMS network that results in a key agreement that is substantially similar to the conventional AKA authentication mechanism. In addition, the disclosed pubic key cryptography techniques do not require a shared secret.
The home network 130 comprises a home subscriber server (HSS) 132, an Interrogating Call Session Control Function (I-CSCF) 134 and a Serving Call Session Control Function (S-CSCF) 136. The S-CSCF 136 can alternatively be implemented as any network server that is responsible for user authentication. The visited network 140 comprises a Proxy Call Session Control Function (P-CSCF) 144. Generally, a Call Session Control Function (CSCF) entity defined in the IMS network is adapted to accomplish functions such as control and routing during a call or session.
Proxy, Interrogating and Serving CSCFs are distinguished based on their corresponding functions. The P-CSCF 144 is adapted for an access of the user equipment 110, and any user equipment 110 shall gain an access to the IMS network 100 through the P-CSCF 144. The S-CSCF 136 provides core functions such as session control and routing. The I-CSCF 134 is adapted for selection of the S-CSCF 136 and the intercommunication between different service providers or different area networks. The HSS 132 is adapted to store subscription data and configuration data of subscribers (for example, the user's certificates), and to support a function of Authentication & Authorization (AAA) for the subscribers.
As shown in
As previously indicated, interfaces 105 and 150 are typically implemented in the 3GPP through application of an IMS AKA mechanism during a registration process for the user equipment. The present invention, however, provides end user-to-network authentication based on the Public Key Infrastructure (PKI) within an IMS network.
As discussed further below, an aspect of the present invention augments an existing smart card having an ISIM application or another secure storage device associated with the user equipment device 110 with the private key of the user, the network certificate, an (optional) function for generating an Integrity Key (IK) and Cipher Key (CK) based on the private key, and a capability of the ISIM application to perform the encryption with at least one existing PKI algorithm (such as RSA, Elliptic Curves, or El Gamal) to be chosen by a network provider. A further aspect of the present invention augments the IMS authentication with a new protocol exchange among the end-user terminal, ISIM, and Serving Call Session Control Function (S-CSCF).
1) One or more user's private keys 210 (for signature and encryption), of which, for simplicity, only one, Upr, is used herein;
2) A function 220 (typically already present in an ISIM card) for computing the integrity key, IK and the ciphering key, CK. The function 220 may need to be augmented to use as an input, a private key, or some other key material in place of the ISIM shared secret, as discussed hereinafter;
3) (Optionally), a function 230 for randomly computing a one-time session key, KS, that is used to encrypt the other keys as discussed below and also serves as a challenge for the network-to-user authentication. This key is generally equal in length to combined lengths of the IK and CK keys; and
4) The user public and private identities 240 (such as IMS Private User Identity (IMPI) and IMS Public User Identity (IMPU) in IMS), for the purposes of illustration, grouped into one string, Id. It is noted that the user's certificate can bind the IMPI with the use's public keys.
To start the registration, the UE 310 requests during step 325 that the smart card 305 provides the authenticator, Autn. The smart card 305 computes (possibly, in cooperation with the UE 310, as explained below) the authenticator, Autn, and delivers the authenticator, Autn, to the UE 310 during step 330, as discussed further below in the section entitled “Computation of the Authenticator, Autn.”
Once the Autn parameter has been computed, it is passed along to the Network Server 315 during step 335, for example, as part of a Register message (such as a SIP Register method). It is not essential that this authentication procedure is performed during the registration. Technically, the authentication procedure can be performed at any time when the authentication is needed and be part of any protocol, as would be apparent to a per son of ordinary skill in the art.
Although unnecessary (and possibly wasteful of bandwidth and execution time), it is possible that the user includes its certificate along with the Autn parameter. In this case, of course, the procedure of the retrieval of the certificate by the network server 315 as described below is replaced by the procedure of verifying the certificate in its chain.
Upon the reception of the Autn parameters the network server 315 performs a sever authentication process 400, discussed further below in conjunction with
When the UE 310 receives the Autn′ parameter message, the UE 310 checks the network signature, while handing out the part that corresponds to the encrypted nonce to the smart card 305 during step 365 for the private-key-based decryption. If either the integrity check of the message fails, or the decrypted value is not equal to freshness+1, the UE 310 proceeds according to the network policy for this specific case. If both checks pass, the procedure is complete.
Computation of the Authenticator, Autn
As discussed above in conjunction with
Autn=U
pr
{N
pu
[K
S
]|K
S[Id, freshness, IK|CK]},
where:
1) freshness is a nonce (such as a timer value, or the IMS SEQ parameter, or any other nonce) that protects the communication against the replay attack; and is generally equal in length to combined lengths of the IK and CK keys;
2) “|”, designates the string concatenation operation;
3) KS [. . . ] designates a symmetric key encryption operation (such as DES, triple-DES, AES, or a one-time pad) performed with the key KS);
4) Npu [. . . ] designates the encryption with the network public key Npu available from the network certificate; and
5) Upr {. . . } designates the signature operation with the user's private signature key. For example, first a hash (such as SHA2 hash) of the argument is computed, then the result is encrypted with that key, and finally this result is concatenated with the argument. The presence of the signature solves two problems: first, it protects the integrity of the message, and, second, it provides (in combination with the freshness parameter), the non-repudiation feature, which is typically essential to operators inasmuch as it constitutes the proof that the session was initiated by the user.
Thus, the resulting Autn string, consists of three concatenated components:
Autn=A|B|C, where
A=Npu[KS] can be decrypted only by the network;
B=KS[Id, freshness, IK|CK] allows recovery of the Id and keys only to the holder of the key KS, which, again, can be derived only by the network from A; and
C=Upr [Hash(A|B)] allows checking of the integrity of the previous two components as well as to prove to the receiver that the message was issued by the user.
It is noted that the identity of the user (contained in B) is fully protected.
It is further noted that the step of separately computing B is not essential. It is used, as is the practice, to minimize the expensive private-key computation. The alternative is to compute A=Npu [Id, freshness, IK|CK] and omit B altogether, in which case there may be no need to derive KS.
To optimize the performance, certain pieces of the above computation (i.e., the ones that do not involve the user private key operations) can actually be performed at the UE 310, in which case one or more messages carrying the results of such computations may need to be exchanged between the UE 310 and the smart card 305.
The only operation that is generally always performed on the card 305 in the exemplary embodiments of the invention is the signature with the private key. Ultimately, it is the only potentially intensive computation required, compared to the rest of the computations.
Server Authentication Process 400
As discussed above in conjunction with
The server authentication process 400 then proceeds to decrypt B with the key KS and recover the identity, Id, of the user during step 420. Once the identify is obtained, the network server 315 checks if there is a record in the subscription directory of legitimate users indexed by this identity, and, if so, whether the user is authorized to register or receive any other service specified by the particular protocol message in which this parameter has been carried. The network server 315 also retrieves the certificate of the user (unless there is a necessity of the certificate to be sent by the user as described above). If there is no entry in the table, the processing stops and, depending on the network security policy, the event may be logged, or in case of server overload reported as a denial of service attack.
The network server 315 proceeds to recover the nonce, freshness, and determines if there is a possibility of the replay during step 430. If for example, the timestamp is used, the network server 315 checks if it is in the acceptable time window. Likewise, if a sequence number (such as sequence in the AKA algorithm) is used, again, the network server 315 will check if its value is in acceptable range (and, if not, it may initiate re-sequencing procedure with the UE 310). If the examination fails, the processing stops and, depending on the network security policy, the event may be logged, or in case of server overload reported as a denial of service attack, especially if there is an obvious indication of replay.
During step 440, the network server 315 a) decrypts C with the public key of the user (obtained from the user's certificate); b) computes the hash of A|B; and c) compares the quantities obtained in a) and b). If these quantities are different, the message is considered tampered with, and the event may be logged, or in case of server overload reported as a denial of service attack. (This step may precede step 3.)
The network server 315 then proceeds to recover IK and CK during step 450. At this point, the authentication of the user 310 to the network has completed, and the network has the same information as it would have had with an AKA authentication technique.
To authenticate itself to the user (and effectively acknowledge the success of the user's authentication), the network server 315 computes the Autn′ parameter during step 460, as follows:
Autn′=N
pr
{U
pu[freshness+1]),
where
1) Upu [. . . ] designates the encryption with the user's public key Upu available from the user's certificate; and
2) Npr [. . . ] designates the signature operation with the network private signature key: first a hash (such as SHA2 hash) of the argument is computed, then the result is encrypted with that key, and finally this result is concatenated with the argument. The presence of the signature solves two problems: first, it protects the integrity of the message, and, second and most important, it provides a proof that the message came from the network.
Among other benefits, the present invention ensures substantially perfect forward secrecy of the IMS session in that the secrecy of a session is not less secure than that relying on the existing IMS authentication mechanism (AKA). The present invention also ensures that other-factor authentication mechanisms present in AKA (such as the sequence number, SQN) can also be used if desired by the network operator. The present invention can also ensure user privacy in that the user identity does not need to be transmitted in the clear. Finally, the present invention can optionally ensure that only absolutely necessary computations are performed on the smart card, recognizing inefficiency of such computations.
While
While exemplary embodiments of the present invention have been described with respect to processing steps in a software program, as would be apparent to one skilled in the art, various functions may be implemented in the digital domain as processing steps in a software program, in hardware by circuit elements or state machines, or in combination of both software and hardware. Such software may be employed in, for example, a digital signal processor, micro-controller, or general-purpose computer. Such hardware and software may be embodied within circuits implemented within an integrated circuit.
Thus, the functions of the present invention can be embodied in the form of methods and apparatuses for practicing those methods. One or more aspects of the present invention can be embodied in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a device that operates analogously to specific logic circuits. The invention can also be implemented in one or more of an integrated circuit, a digital signal processor, a microprocessor, and a micro-controller.
System and Article of Manufacture Details
As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, memory cards, semiconductor devices, chips, application specific integrated circuits (ASICs)) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.
The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. The memories could be distributed or local and the processors could be distributed or singular. The memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network.
It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention.
