Abstract:
A method and apparatus for securing the interface between a Universal Integrated Circuit Card (UICC) and a Terminal in wireless communications is disclosed. The security of Authentication and Key Agreement (AKA) and application level generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) procedures is improved. A secure shared session key is used to encrypt communications between the UICC and the Terminal. The secure shared session key generated using authenticating or non-authenticating procedures.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. provisional application No. 61/043,007 filed Apr. 7, 2008 and 61/081,756 filed Jul. 18, 2008, which are incorporated by reference as if fully set forth. 
     
    
     FIELD OF INVENTION 
       [0002]    This application is related to wireless communications. 
       BACKGROUND 
       [0003]    The Authentication and Key Agreement (AKA) procedure is used for establishing authentication and shared secret keys for a wireless transmit/receive unit (WTRU) in a 3 rd  Generation Partnership Project (3GPP) communication network. The AKA provides for secure mutual authentication between two parties. In addition, the application level generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U), which is based on AKA procedures, provides a means to enable application security. However, the AKA and the application level generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) procedures do not protect the security of the interface connecting the Universal Integrated Circuit Card (UICC) and Terminal of the WTRU. Critical key related material passes from the UICC to the Terminal during the AKA and GBA_U processes. As a result, the session keys (for example CK/IK and Ks_ext_NAF), are exposed during initial provisioning of the Terminal at the point of sale, when a local key has not yet been established and when an established local key expires. 
         [0004]    Existing protocols that are designed to protect the connection between the UICC and the Terminal cannot be initiated until the AKA and GBA_U processes are complete. As a result, these protocols allow for eavesdropping of the keys. Attempts to secure the link between the Terminal and the UICC, after the AKA and GBA_U process, for other application level processes through interactions with and participation by the wireless network components, do not resolve these deficiencies. 
         [0005]    Therefore, there exists a need for an improved method and apparatus for securing communications between a Terminal and a UICC. 
       SUMMARY 
       [0006]    A method and apparatus for securing the interface between a Universal Integrated Circuit Card (UICC) and a Terminal in wireless communications is disclosed. The security of the Authentication and Key Agreement (AKA) and the application level generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) procedures is improved. A secure shared session key is used to encrypt communications between the UICC and the Terminal. The secure shared session key generated using authenticating or non-authenticating procedures. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein: 
           [0008]      FIG. 1  shows an example of a wireless transmit/receive unit for performing secure session key generation; 
           [0009]      FIG. 2  shows an example of a Terminal configured as a handset for performing wireless communications; 
           [0010]      FIG. 3  shows an example of a wireless transmit/receive unit for performing secure session key generation in conjunction with connected device; 
           [0011]      FIG. 4  shows an example of a network for performing wireless communications; 
           [0012]      FIG. 5  is an example of session key generation for securing communications between the Universal Integrated Circuit Card and the Terminal; 
           [0013]      FIG. 6  shows an example of explicit mutual authentication using the AKA procedure; 
           [0014]      FIG. 7  shows an example of explicit mutual authentication using one-time authenticated encryption; 
           [0015]      FIG. 8  shows an example of explicit mutual authentication using one-time authenticated encryption and replay protection; 
           [0016]      FIG. 9  shows an example of implicit mutual authentication; 
           [0017]      FIG. 10  shows an example of implicit mutual authentication with replay protection; and 
           [0018]      FIG. 11  shows an example of shared secret key establishment without authentication. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    When referred to hereafter, the terminology “wireless transmit/receive unit (WTRU)” includes but is not limited to a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a computer, or any other type of user device capable of operating in a wireless environment. When referred to hereafter, the terminology “base station” includes but is not limited to a Node-B, a site controller, an access point (AP), or any other type of interfacing device capable of operating in a wireless environment. The terminology “WTRU” and “base station” are not mutually exclusive. 
         [0020]      FIG. 1  is an example block diagram of a wireless transmit/receive unit (WTRU)  100  for performing secure session key generation. The WTRU  100  includes a Universal Integrated Circuit Card (UICC)  110  and a Terminal  120 . The UICC communicates with the Terminal via interface  130 . The WTRU  100  is shown as including the UICC  110  and the Terminal  120  for illustrative purposes. The UICC  110  or the Terminal  120  may be configured in any manner so long as they are able to communicate as described herein. For example,  FIG. 3  shows an example wherein the Terminal  120  is located in a connected device. 
         [0021]      FIG. 2  is an example block diagram of an expanded view of the Terminal  120  configured as a handset for performing wireless communication. The Terminal  120  includes a processor  210 , an antenna  220 , a user interface  230 , and a display  240 . 
         [0022]      FIG. 3  is an example block diagram of a wireless transmit/receive unit (WTRU)  100  for performing secure session key generation in conjunction with a connected device  300 . The UICC  10  in the WTRU  100  communicates with the Terminal  120  in a connected device  300  via the interface  130 . The connected device  300  may be a personal computer (PC), or any other device configured as the Terminal  120 . The interface  130  may be a wired or a wireless interface. The method and apparatus recited herein includes any other combination or configuration of a UICC  110  and a Terminal  120 . Optionally, the Terminal  120  may include an internal or external UICC reader. 
         [0023]    For example, the connected device  300  may be a laptop computer. The laptop may be connected to the internet via an Ethernet connection. The laptop may also be connected to the WTRU  100  via a Bluetooth interface  130 . The UICC  110  in the WTRU  100  may then use the Terminal  120  in the laptop for performing communications requiring a secure connection. Alternatively, the Terminal  120  in the laptop may use the UICC  110  in the WTRU  100  for performing communications requiring a secure connection. 
         [0024]      FIG. 4  is an example block diagram of a network  400  for performing wireless communications. The network  400  includes the WTRU  100 , a radio access network (RAN)  410 , and a core network (CN)  420 . The RAN  410  includes a base station  430 , and a Radio Network Controller (RNC)  440 . The CN  420  includes a Visitor Location Register (VLR)  450  and a Home Location Register (HLR)  460 . The network  400  also includes an eavesdropper (EVE)  490 . The base station  430  serves as a point of network entry for the RAN  410 . The RNC  440  carries out various functions in wireless communication, such as radio resource management, mobility management functions, and encryption functions. The VLR  450  stores information about the WTRU  100 , such as a copy of a user service profile and a device location area, which is used for wireless communications. The HLR  460 , which stores a master copy of a user service profile, carries out switching functions and manages the wireless communications between the WTRU  100  and the network  400 . 
         [0025]      FIG. 5  is an example of session key generation for securing the interface  130  between the UICC  110  and the Terminal  120 . The Terminal  120  identifies a secret that can be used to encrypt communications with the UICC  110 , at  510 . Similarly, the UICC identifies a secret that can be used to encrypt communications with the Terminal  120 , at  515 . Optionally, the identified secrets are a pre-provisioned shared secret. A tunnel is established on the interface  130  using the secrets, at  520 , such that a channel between the UICC  110  and the Terminal  120  is secured with the respective secrets. The tunnel is used to share data for use in deriving a secure shared session key, at  525 . 
         [0026]    Next, the Terminal  120  derives a secure shared session key S T  from it&#39;s secret, at  530 . Similarly, the UICC  110  derives a secure shared session key S U  from it&#39;s secret, at  535 . Optionally, the UICC  110  and the Terminal  120  also perform mutual authentication, at  530 ,  535 . The secure shared session keys S T , S U  are used to establish a secure channel between the UICC  110  and the Terminal  120 , at  540 , such that the confidentiality and integrity of information passing through the secure channel are protected. The UICC  110  and the Terminal  120  then carry out the AKA  300  and GBA_U  400  procedures via the secure channel, at  550 . 
         [0027]    In some embodiments, the shared secret K is used to perform a keyed pseudorandom function (PRF) that is capable of accommodating arbitrary-length inputs, such as HMAC with SHA-256, encrypted CBC MAC with AES-128, or the AKA security functions. A PRF using a shared secret K and an input, x, may be denoted as f K (x). Similarly, the notation f K (x,y) indicates that the PRF is performed on a concatenation of the arguments shown. A PRF family is a set of related one-way, non-invertible, PRFs, wherein a value of variable bit-length is transformed to a bit sequence of fixed length (i.e., 128 or 256). For example a first PRF in a PRF family may be denoted as f K (0, Y, Z) and a second PRF in the PRF family may be denoted as f K (1, Y, Z), such that the PRF having the leading 0 produces a different result than the PRF having the leading 1. 
         [0028]    In some embodiments, the Terminal  120  is configured to generate a random challenge (RAND), an anonymity key (AK), and a sequence number (SQN). Terminal  120  is also configured to compute a message authentication code (MAC), an Expected Response (XRES), an expected sequence number (XSQN), or an authentication value (Tag). Similarly, the UICC  110  is configured to generate a response (RES) or an expected authentication value (XTag). One having ordinary skill in the art would recognize that a RAND, an AK, a SQN, a MAC, and a XRES may be produced in accordance with any of a number of respective functions known in the art. Optionally, the functions may be the key generation functions defined by the 3 rd  generation partnership project (3GPP). The Terminal  120  is also configured to send the calculated values to the UICC  110 . The Terminal  120  is also configured to receive a response (RES) from the UICC  110  and to compare calculated values with received values for authentication of the UICC  110 . Similarly, the UICC  110  is configured to send the values to the Terminal  120 , and to compare calculated values with received values for authentication of the UICC  110 . The Terminal  120  and UICC  110  are also configured to independently derive shared values, such as shared session keys and anonymity keys. For clarity, values produced at the UICC  110  may be indicated with the subscript U, and values produced at the Terminal  120  may be indicated with the subscript T. For example, AK U  at the UICC  110  has the same value as AK T  at the Terminal  120 . 
         [0029]      FIG. 6  shows an example of an explicit mutual authentication and session key generation method  600 . First, the Terminal  120  generates a RAND and a SQN T , at  610 . The Terminal  120  also computes a MAC, an XRES, an AK T , and a XSQN, at  620 . The MAC is computed based on the shared secret K, the RAND, and the SQN T . The XRES represents an authentication code and is computed using the shared secret K and the RAND. The AK T  is generated using the shared secret K and the RAND. Optionally, the AK T  is the same size as the SQN T . The XSQN is computed by performing a bitwise exclusive-or (XOR or ⊕) of the SQN and the AK T . 
         [0030]    Next, the Terminal  120  sends the MAC, the RAND, and the XSQN to the UICC  110  over the interface  130 , at  630 . The UICC  110  computes an AK U , a SQN U , and an expected MAC (XMAC), at  640 . The AK U  is calculated using the shared secret K and the received RAND. The SQN U  is calculated by performing a bitwise exclusive-or of the AK U  and the XSQN. The XMAC is calculated using the shared secret K, the RAND, and the SQN U . Optionally, the function used to calculate the AK U  at the UICC  110  is identical to the function used to calculate the AK T  at the Terminal  120 . 
         [0031]    Next the UICC  110  compares the XMAC with MAC, at  650 . If the XMAC and the MAC are not equal, the authentication process fails and terminates with a fail condition, at  655 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the Terminal  120  is authenticated, and the UICC  110  computes a RES using the shared secret K and RAND, at  660 . The UICC  110  sends the RES to the Terminal  120 , at  670 , and derives a shared session key S U , at  680 . For example, the shared session keys are derived using the RAND and the shared secret K. 
         [0032]    Finally, the Terminal  120  compares the RES with the XRES, at  690 . If the RES and the XRES are not equal, the authentication process fails and terminates with a fail condition, at  691 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the UICC  110  is authenticated, and the Terminal  120  derives a shared session key S T , at  692 . The UICC  110  and the Terminal  120  then use the shared session key S U , S T  to perform the GBA_U  400  and AKA  300  procedures. 
         [0033]      FIG. 7  shows an example of an explicit mutual authentication and session key generation method  700  using one-time authenticated encryption. The Terminal  120  generates a session key S T  and a nonce R, at  705 . Optionally, the nonce R is selected using a counter and the counter is incremented. The Terminal  120  computes the encrypted session key e of the session key S T  using the shared secret K, the nonce R, and a tuple E of the nonce R and the encrypted session key e at  710 . The tuple E is generated by an encryption process according to the following vector notation: 
         [0000]        E =( R,e=f   K (0 ,R )⊕ S   T ).  Equation (1) 
         [0034]    The Terminal  120  then calculates an authentication value Tag using the shared secret K, the nonce R and the encrypted session key e at  720 , according to the following equation: 
         [0000]      Tag= f   K (0 ,R,e ).  Equation (2) 
         [0035]    Next, the Terminal  120  sends the tuple E and the authentication value Tag to the UICC  110  over the interface  130 , at  730 . The UICC  110  uses the shared secret K and the received tuple E to validate the received authentication value Tag, at  740 . This validation may be denoted as: 
         [0000]      Tag== f   K (0 ,R,e ).  Equation (3) 
         [0036]    If the received authentication value Tag is not validated, the authentication process fails and terminates with a fail condition, at  745 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the Terminal  120  is authenticated and the UICC decrypts the session key S U , at  750 , according to the following equation: 
         [0000]        S   U   =f   K (0 ,R )⊕ e.   Equation (4) 
         [0037]    Next, the UICC  110  computes an expected authentication value (XTag), at  760 . This computation may be denoted as: 
         [0000]        X Tag= f   K (1 ,R ).  Equation (5) 
         [0038]    The UICC  110  sends the expected authentication value XTag to the Terminal  120  over the interface  130 , at  770 . The Terminal  120  uses the shared secret K and the nonce R to validate the received XTag, at  780 . This validation may be denoted as: 
         [0000]        X Tag== f   K (1 ,R ).  Equation (6) 
         [0039]    If the XTag is validated the UICC  110  is authenticated, at  790 . Otherwise, the authentication process fails and terminates with a fail condition, at  791 . Optionally, the authentication process may be restarted after a predetermined interval. 
         [0040]      FIG. 8  shows an example of an explicit mutual authentication and session key generation method  800  using one-time authenticated encryption and replay attack protection. The UICC  110  generates a nonce N at  805 . Although a nonce is shown in  FIG. 8 , any appropriate pre-key negotiation parameter may be used. Optionally, the nonce N is generated using a counter and the counter is incremented. The UICC  110  then sends the nonce N to the Terminal  120  over the interface  130 , at  810 . 
         [0041]    The Terminal  120  generates a session key S T  and a nonce R, at  820 . Optionally, the nonce R is generated using a counter and the counter is incremented. The Terminal  120  computes the encrypted session key e of the session key S T  using the shared secret K and the nonce R per Equation 1, at  830 . The Terminal  120  then calculates an authentication value Tag, using the shared secret K, the nonce R, the encrypted session key e, and the nonce N, at  840 . This calculation may be denoted as: 
         [0000]      Tag= f   K (0 ,R,e,N ).  Equation (7) 
         [0042]    Next, the Terminal  120  sends the authentication value Tag and a tuple E of the nonce R, and the encrypted session key e to the UICC  110  over the interface  130 , at  850 . The UICC  110  uses the shared secret K, the received tuple E, and the nonce N, to validate the received authentication value Tag, at  860 . This validation may be denoted as: 
         [0000]      Tag== f   K (0 ,R,e,N ).  Equation (8) 
         [0043]    If the received authentication value Tag is not validated, the authentication process fails and terminates with a fail condition, at  865 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the UICC decrypts the session key S U , per Equation 4, at  870 . Next, the UICC  110  computes an expected authentication value XTag per Equation 5, at  880 . 
         [0044]    The UICC  110  sends the XTag to the Terminal  120  over the interface  130 , at  890 . The Terminal  120  uses the nonce R to validate the received XTag per Equation 6, at  892 . If the XTag is validated, the UICC  110  is authenticated, at  894 . Otherwise, the authentication process fails and terminates with a fail condition, at  896 . Optionally, the authentication process may be restarted after a predetermined interval. 
         [0045]      FIG. 9  shows an example of implicit mutual authentication and session key generation. The Terminal  120  generates a nonce R, at  900 . Optionally, the nonce R is generated using a counter and the counter is incremented. The Terminal  120  then calculates an authentication value Tag using the shared secret K and the nonce R, at  910 . This calculation may be denoted as: 
         [0000]      Tag= f   K (0 ,R ).  Equation (9) 
         [0046]    Next, the Terminal  120  sends nonce R and the authentication value Tag to the UICC  110  over the interface  130 , at  920 . The UICC  110  uses the shared secret K and the nonce R to validate the received authentication value Tag, at  930 . This validation may be denoted as: 
         [0000]      Tag== f   K (0 ,R ).  Equation (10) 
         [0047]    If the received authentication value Tag is not validated, the authentication process fails and terminates with a fail condition, at  935 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the Terminal  120  is authenticated and the UICC  110  computes session key S U  using the shared secret K and the nonce R, at  940 . The session key computation may be denoted as: 
         [0000]        S   U   =f   K (2 ,R ).  Equation (11) 
         [0048]    Next, the UICC  110  computes an expected authentication value XTag per Equation 5, at  950 . The UICC  110  sends the expected authentication value XTag to the Terminal  120  over the interface  130 , at  960 . The Terminal  120  uses the nonce R to validate the received expected authentication value XTag per Equation 6, at  970 . If the received expected authentication value XTag is not validated the authentication process fails and terminates with a fail condition, at  975 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the UICC  110  is authenticated, and the Terminal  120  computes the session key S T  using the shared secret K and the nonce R, at  980 . The session key computation may be denoted as: 
         [0000]        S   T   =f   K (2 ,R ).  Equation (12) 
         [0049]      FIG. 10  shows an example of implicit mutual authentication and session key generation with replay protection. The UICC  110  generates a nonce N, at  1005 . Optionally, the nonce N is generated using a counter and the counter is incremented. The UICC  110  then sends the nonce N to the Terminal  120  over the interface  130 , at  1010 . 
         [0050]    The Terminal  120  generates a nonce R, at  1020 . Optionally, the nonce R is generated using a counter and the counter is incremented. The Terminal  120  then calculates an authentication value Tag using the nonce R and the nonce N, at  1030 . This calculation may be denoted as: 
         [0000]      Tag= f   K (0 ,R,N ).  Equation (13) 
         [0051]    Next, the Terminal  120  sends nonce R and the authentication value Tag to the UICC  110  over the interface  130 , at  1040 . The UICC  110  uses the shared secret K, the nonce R, and the nonce N to validate the received authentication value Tag, at  1050 . This validation may be denoted as: 
         [0000]      Tag== f   K (0 ,R,N ).  Equation (14) 
         [0052]    If the received authentication value Tag is not validated, the authentication process fails and terminates with a fail condition, at  1055 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the Terminal  120  is authenticated and the UICC  110  computes the session key S U  using the shared secret K and the nonce R, per Equation 11, at  1060 . Next, the UICC  110  computes an expected authentication value XTag, per Equation 5, at  1070 . The UICC  110  sends the expected authentication value XTag to the Terminal  120  over the interface  130 , at  1080 . 
         [0053]    Next, the Terminal  120  uses the nonce R to validate the received expected authentication value XTag per Equation 6, at  1090 . If the received expected authentication value XTag is not validated the authentication process fails and terminates with a fail condition, at  1091 . Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the UICC  110  is authenticated and the Terminal  120  computes the session key S T , using the shared secret K and the nonce R, at  1092 . The session key computation may be denoted as: 
         [0000]        S   T   =f   K (2 ,R ).  Equation (15) 
         [0054]      FIG. 11  shows an example of shared secret key establishment without authentication using a Diffie-Hellman key exchange protocol. First, the UICC  110  and the Terminal  120  agree upon a very large prime number, p, and a generator, g, at  1100 . The algebraic structure employed is the multiplicative group F* p , derived from the field F p . F* p  is cyclic and contains the generator g, such that, for any member a of F* p  an integer n can be found such that a=g n  mod p. The values p and g are known publically, and represent a public key part of a key pair. 
         [0055]    Next, the Terminal  120  randomly selects a private key, RAND i , such that the private key RAND i  is at least one (1) and is not greater than two (2) less than the very large prime number p, at  1110 . The Terminal  120  computes g RAND     i    from the private key RAND i , at  1120 . This computation may be denoted as: 
         [0000]      g RAND     i   ≡g RAND     i    mod p.  Equation (16) 
         [0056]    Similarly, the UICC  110  selects a private key, FRESH, such that the private key FRESH is at least one (1) and is not greater than two (2) less than the very large prime number p, at  1130 . Then the UICC  110  computes g FRESH  from the private key FRESH, at  1140 . This computation may be denoted as: 
         [0000]      g FRESH ≡g FRESH  mod p.  Equation (17) 
         [0057]    Next, the UICC  110  and the Terminal  120  exchange g RAND     i    and g FRESH  over the interface  130 , at  1150 . 
         [0058]    Next, the Terminal  120  computes the shared secret, K, using the private key R ANDi  and the received g FRESH , at  1160 . This computation may be denoted as: 
         [0000]      K≡g FRESH   RAND     i    mod p.  Equation (18) 
         [0059]    Similarly, the UICC  110  computes the shared secret, K, using the private key FRESH and the received g RAND     i   , at  1170 . This computation may be denoted as: 
         [0000]      K′≡g RAND     i     FRESH  mod p.  Equation (19) 
         [0060]    The Terminal  120  and the UICC  110  now possess a shared secret, K′=K, which is then used to compute a secure secret session key S, at  1165 ,  1175 . The secure secret session key S is used to perform the GBA_U and AKA procedures by securing the interface  130 , at  1180 . 
         [0061]    Although features and elements are described above in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). 
         [0062]    Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. 
         [0063]    A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), Terminal, base station, radio network controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any wireless local area network (WLAN) or Ultra Wide Band (UWB) module.