US9270453B2 - Local security key generation - Google Patents

Abstract

A calling device may obtain a first calling security parameter by registering with a network and obtain a second calling security parameter in response to causing an application authentication architecture of the network to verify that that the calling device is authorized to access a network service corresponding to a communication application stored by the calling device. The calling device may communicate the first and second calling security parameters to a called device and receive first and second called security parameters from the called device in response to communicating the first and second calling security parameters. The calling device may generate a security key based on the first calling security parameter, the second calling security parameter, first called security parameter, and the second called security parameter, and use the security key to encrypt or decrypt communication between the calling device and the called device.

Description

BACKGROUND

Current network communication technologies include various approaches to network security. For example, in many networks, user devices are assigned security keys (also referred to as cipher keys) for encrypting and decrypting messages communicated over the network. However, such technologies often include various deficiencies. For instance, assigning security keys to user devices often involves a third device (e.g., a key management system) to assign the security keys, which can introduce security risks and increase operational complexity within the network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example overview of an implementation described herein;

FIG. 2 is a diagram of an example environment in which systems and/or methods, described herein, may be implemented;

FIG. 3 is a diagram of example components of a device according to one or more implementations described herein;

FIG. 4 is a diagram of example functional components corresponding to one or more implementations described herein;

FIG. 5 is a diagram of an example data flow according to one or more implementations described herein;

FIG. 6 is a diagram of an example process for generating a security key according to one or more implementations described herein;

FIG. 7 is a diagram of another example process for generating a security key according to one or more implementations described herein; and

FIGS. 8A-8C are diagrams of an example call session according to one or more implementations described herein.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same labels and/or reference numbers in different drawings may identify the same or similar elements.

In one or more implementations, described herein, devices may be used to locally generate security keys. For example, a calling device may receive calling security parameters by registering with a network and demonstrating that the calling device is authorized to access a particular network service (e.g., a voice over Internet Protocol (IP) (VoIP) service) and/or use a particular communication application (e.g., a VoIP application). The calling device may communicate the calling security parameters to a called device and, in response, receive called security parameters from the called device. The calling device and the called device may each execute a key generation function based on the calling security parameters and the called security parameters to locally generate security keys for encryption and decryption purposes.

FIG. 1 is a diagram of anexample overview100 of an implementation described herein. As depicted,overview100 may includecalling device110, calleddevice120,network registration architecture130, andapplication authentication architecture140. In some implementations, the systems and devices ofFIG. 1 may correspond to one or more systems or device discussed elsewhere in this specification.

Calling device110 and calleddevice120 may each include one or more of a variety of devices, such as a telephone, a smart phone, a laptop computer, a tablet computer, a desktop computer, a server, or another type of computing or communication device. For example, callingdevice110 and calleddevice120 may each be a smart phone. However, in another example,calling device110 may include a tablet computer, and calleddevice120 may include a network application server. In yet another example, callingdevice110 and calleddevice120 may each be application servers.

Calling device110 may include a device that sends a communication session invitation (e.g., a call session invitation, a session initiation protocol (SIP) INVITE message, etc.), and calleddevice120 may include a device that receives the communication session invitation. However, in some implementations, calleddevice120 may also be capable of sending a communication session invitation, and callingdevice110 may be capable of receiving the communication session invitation. In certain implementations, therefore, a particular device (e.g., a smart phone) may operate ascalling device110 in one scenario and calleddevice120 in another scenario.

As depicted, callingdevice110 and calleddevice120 may include communication applications. The communication applications may enable callingdevice110 and calleddevice120 to communicate with one another via a particular type of network service. For example, a communication application may include a VoIP application, a simple message service (SMS) application, an instant messaging (IM) application, a video conference application, or another type of communication application. In some implementations, before a communication application may be used,application authentication architecture140 may perform one or more authentication or authorization processes to verify that callingdevice110 or calleddevice120 are authorized to use the communication applications and/or corresponding network service.

Additionally, or alternatively, callingdevice110 and calleddevice120 may include key generation functions. The key generation functions may enable callingdevice110 and calleddevice120 to generate a security key based on one or more security parameters. In certain implementations, the key generation function of thecalling device110 and the key generation function of the calleddevice120 may be the same. For example, in some implementations, if the same parameters are inputted into the key generation function of thecalling device110 and the key generation function of the calleddevice120, the outputs of both key generation functions may be the same.

Network registration architecture130 may include one or more of a variety of computing devices. For example,network registration architecture130 may include a desktop computer, a server, a cluster of servers, or one or more other types of computing or communication devices. In some implementations,network registration architecture130 may be capable of registeringcalling device110 or calleddevice120 with a network (e.g., an IP multimedia subsystem (IMS) network). In some implementations,network registration architecture130 may include one or more IMS network devices (not shown inFIG. 1), such as one or more call session control function (CSCF) devices (e.g., a proxy-CSCF (P-CSCF) device, an interrogating-CSCF (I-CSCF) device, a serving-CSCR (S-CSCF) device, etc.), a home subscriber server (HSS), and/or one or more other types of IMS devices.

Similarly,application authentication architecture140 may include one or more of a variety of computing devices. For example,application authentication architecture140 may include a desktop computer, a server, a cluster of servers, or one or more other types of computing or communication devices. In some implementations,application authentication architecture140 may provide one or more of a variety of authentication and/or authorization services to enable callingdevice110 and calleddevice120 to communicate with one another via a particular network service and/or a particular communication application.

In certain implementations,application authentication architecture140 may include a generic bootstrap architecture (GBA). Additionally, or alternatively,application authentication architecture140 may include one or more bootstrapping server functions (BSFs), one or more network application functions (NAFs), or one or more additional or alternative functions or devices for providing authentication and authorization services. For instance, in some implementations,application authentication architecture140 may communicate or otherwise cooperate with the devices of network registration architecture130 (e.g., a HSS) in order to provide authentication and authorization services.

As depicted, callingdevice110 or calleddevice120 may receive one or more security parameters fromnetwork registration architecture130. In some implementations, the security parameters fromnetwork registration architecture130 may be received during, or in response to, callingdevice110 or calleddevice120 registering with a network vianetwork registration architecture130. Additionally, or alternatively, callingdevice110 or calleddevice120 may receive one or more security parameters fromapplication authentication architecture140. In some implementations, the security parameters fromapplication authentication architecture140 may be received in response to application authentication architecture140 (e.g., a BSF) verifying that callingdevice110 or calleddevice120 is authorized to access a particular network communication service or in response to application authentication architecture140 (e.g., a NAF) verifying that callingdevice110 or calleddevice120 is authorized to use a particular communication application.

Calling device110 may communicate one or more of the security parameters received fromnetwork registration architecture130 andapplication authentication architecture140 to calleddevice120. Similarly, calleddevice120 may communicate one or more of the security parameters received fromnetwork registration architecture130 andapplication authentication architecture140 to callingdevice110. In some implementations, this may ensure that callingdevice110 and calleddevice120 apply the same security parameters to the key generation functions in order to generate security keys that complement one another. Additionally, or alternatively, callingdevice110 or calleddevice120 may use security keys to encrypt and decrypt a communication session (e.g., a VoIP call session).

FIG. 2 is a diagram of anexample environment200 in which systems and/or methods, described herein, may be implemented. As depicted,environment200 may includecalling device110, calleddevice120,network registration architecture130,application authentication architecture140, andnetwork210. WhileFIG. 2 shows a particular number and arrangement of networks and devices, in alternative implementations,environment200 may include additional networks or devices, fewer networks or devices, different networks or devices, or differently arranged networks or devices than those depicted inFIG. 2.

Calling device110, calleddevice120,network registration architecture130, andapplication authentication architecture140 are each described above with reference toFIG. 1. Network210 may include any type of network or combination of networks. For example,network210 may include a local area network (LAN) (e.g., an Ethernet network), a wireless LAN (WLAN) (e.g., an IEEE 802.11x network), a wide area network (WAN) (e.g., the Internet), or a wireless WAN (WWAN) (e.g., a Long-Term Evolution (LTE) network, a High-Speed Packet Access (HSPA) network, an Evolved High Rate Packet Data (eHRPD) network, etc). Network210 may also, or alternatively, include an IMS network, a fiber optic (e.g., a fiber optic service (FiOS)) network, a VoIP network, a metropolitan area network (MAN), an ad hoc network, or a telephone network (e.g., a Public Switched Telephone Network (PSTN)).

For example, in some implementations,network210 may include one or more LTE access networks connected to an IMS network. In such implementations, callingdevice110 or calleddevice120 may include one or more LTE-enabled user devices (e.g., a smart phone, a tablet computer, a laptop computer, etc.). Additionally, or alternatively,network registration architecture130 may include a P-CSCF device, an I-CSCF device, an S-CSCF device, an HSS, and/or one or more other types of network devices. In such implementations,application authentication architecture140 may include a GBA, a BSF, one or more NAFs, and/or one or more other types of functions, systems, or devices relating to authentication.

FIG. 3 is a diagram of example components of adevice300 according to one or more implementations described herein.Device300 may correspond to callingdevice110, calleddevice120,network registration architecture130, and/orapplication authentication architecture140. Each of callingdevice110, calleddevice120,network registration architecture130, and/orapplication authentication architecture140 may include one ormore devices300 or one or more of the components ofdevice300. As depicted,device300 may includebus310,processor320,memory330,input device340,output device350, andcommunication interface360. However, in other implementations,device300 may include fewer components, additional components, different components, or differently arranged components than those illustrated inFIG. 3.

Bus310 may include one or more component subsystems or communication paths that enable the components ofdevice300 to communicate.Processor320 may include one or more processors, microprocessors, data processors, co-processors, network processors, application-specific integrated circuits (ASICs), controllers, programmable logic devices (PLDs), chipsets, field-programmable gate arrays (FPGAs), or other types of components that may interpret or execute instructions or data.Processor320 may control the overall operation, or a portion thereof, ofdevice300, based on, for example, an operating system and/or various applications.Processor320 may access instructions frommemory330, from other components ofdevice300, or from a source external to device300 (e.g., a network or another device).

Memory330 may include memory and/or secondary storage. For example,memory330 may include random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), programmable ROM (PROM), flash memory, or some other type of memory.Memory330 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.) or some other type of computer-readable medium, along with a corresponding drive. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include space within a single physical memory device or spread across multiple physical memory devices.

Input device340 may include one or more components that permit a user to input information intodevice300. For example,input device340 may include a keypad, a button, a switch, a knob, fingerprint recognition logic, retinal scan logic, a web cam, voice recognition logic, a touchpad, an input port, a microphone, a display, or some other type of input component.Output device350 may include one or more components that permitdevice300 to output information to a user. For example,output device350 may include a display, light-emitting diodes (LEDs), an output port, a speaker, or some other type of output component.

Communication interface360 may include one or more components that permitdevice300 to communicate with other devices or networks. For example,communication interface360 may include some type of wireless or wired interface.Communication interface330 may also include an antenna (or a set of antennas) that permit wireless communication, such as the transmission and reception of radio frequency (RF) signals.

As described herein,device300 may perform certain operations in response toprocessor320 executing software instructions contained in a computer-readable medium, such asmemory330. The software instructions may be read intomemory330 from another computer-readable medium or from another device viacommunication interface360. The software instructions contained inmemory330 may causeprocessor320 to perform one or more processes described herein. Alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

FIG. 4 is a diagram of examplefunctional components400 corresponding to one or more implementations described herein. For example, callingdevice110 or calleddevice120 may includefunctional components400. As depicted,functional components400 may includeregistration module410,communication application module420,security parameters module430, andkey generation module440. Depending on the implementation, one or more of modules410-440 may be implemented as a combination of hardware and software based on the components illustrated and described with respect toFIG. 3. Alternatively, modules410-440 may each be implemented as hardware based on the components illustrated and described with respect toFIG. 3. WhileFIG. 4 shows a particular number and arrangement of modules, in alternative implementations,functional components400 may include additional modules, fewer modules, different modules, or differently arranged modules than those depicted.

Registration module410 may provide callingdevice110 or calleddevice120 with functionality regarding network registration. For example,network registration module410 may communicate withnetwork registration architecture130 to register withnetwork210, which may include establishing a communication session (e.g., a SIP session) withnetwork210. Additionally, or alternatively,network210 may associate the communication session with a random number (e.g., a RAND, a RAND_ID, a session identifier, etc.) or other data structure that may be used to setup and identify the communication session. As described below, a RAND may also be used as a security parameter for generating a security key.

In some implementations, by registering withnetwork210, callingdevice110 or calleddevice120 may be granted access to one or more network services (e.g., standard calling services, Internet access, etc.). However, other network services (e.g., VoIP services, SMS services, IM services, video conferencing services, etc.) may require one or more additional authentication or authorization processes. For example, obtaining access to network services, corresponding to a particular communication, application may requireapplication authentication architecture140 to perform one or more application authentication procedures as described herein.

Communication application module420 may provide callingdevice110 or calleddevice120 with functionality regarding communication applications. For instance,communication application module420 may include a VoIP application that enables callingdevice110 or calleddevice120 to communicate overnetwork210 via VoIP. In implementations where a communication application requires authentication,communication application module420 may communicate withapplication authentication architecture140 to complete the authentication process.

Application authentication architecture140 may communicate with network registration architecture130 (e.g., HSS) to determine whether callingdevice110 or calleddevice120 is authorized for a particular network service (e.g., a VoIP service, SMS service, etc.).Application authentication architecture140 may also, or alternatively, associate an authentication or authorization process with a transaction identifier (e.g., a bootstrapping transaction identifier (B-TID)) in order to track the process. Additionally, or alternatively, a NAF identifier (e.g., a NAF_ID) may be used to derive a NAF key (e.g., an external NAF key, Ks_ext_NAF, etc.), and a NAF key may be submitted to a NAF so that callingdevice110 or calleddevice120 may, for example, use a stored communication application to gain access to a particular network service.

Security parameters module430 may provide callingdevice110 or calleddevice120 with functionality regarding security parameters. For instance,security parameters module430 may collect security parameters (e.g., a RAND_ID) received bynetwork registration module410 during a network registration process, or security parameters (e.g., a B-TID, Ks_ext_NAF, etc.) received bycommunication application module420 during an authentication or authorization process.Security parameters module430 may also, or alternatively, collect one or more security parameters that may be available locally. Examples of such parameters may include a telephone number or another type of identifier associated with calling device110 (e.g., a CALLING_ID), a telephone number or another type of identifier associated with calleddevice120, and/or an identifier associated with a network service or network application function (e.g., a NAF_ID).

Security parameters module430 may communicate one or more security parameters to calleddevice120 and, in response, receive one or more security parameters from calleddevice120. Alternatively,security parameters module430 may receive one or more security parameters from callingdevice110 and, in response, collect and communicate security parameters to thecalling device110. In some implementations, security parameters collected by, communicated by, or otherwise corresponding to callingdevice110 may be identified as calling security parameters (e.g., CALLING_RAND_ID, CALLING_B-TID, etc.). Similarly, security parameters collected by, communicated by, or otherwise corresponding to calleddevice120 may be identified as called security parameters (e.g., CALLED_RAND_ID, CALLED_B-TID, etc.).

Key generation module440 may provide callingdevice110 or calleddevice120 with functionality regarding security keys. For example,key generation module440 may generate a security key based on one or more of the security parameters collected or otherwise obtained bysecurity parameters module430. In some implementations,key generation module440 may generate a security key by executing one or more key generation functions, which may include a key derivation function (KDF) or another type of hash function. In some implementations, a KDF may be implemented according to one or more communication standards, such as the 3rd Generation Partnership Project (3GPP). As mentioned above, a security key may be used to encrypt and decrypt data structures (e.g., IP packets) of a communication session.

FIG. 5 is a diagram of anexample data flow500 for generating a security key according to one or more implementations described herein.Example data flow500 is presented from the perspective of callingdevice110 collecting or otherwise obtaining security parameters. A similar or analogous data flow could be applicable to calleddevice120.

As depicted, security parameters may be obtained by callingdevice110 from different sources and at different times. For example, callingdevice110 may receive a CALLING_RAND parameter or another type of security parameter fromnetwork registration architecture130 while registering withnetwork210. Additionally, or alternatively, callingdevice110 may receive a CALLING_B-TID parameter, a CALLING_Ks-ext-NAF parameter, or one or more other types of security parameters while communicating withapplication authentication architecture140 to, for example, obtain authorization to access a particular network service or use a particular communication application.

Callingdevice110 may also, or alternatively, receive a CALLED_RAND parameter, a CALLED_B-TID parameter, a CALLED_Ks-ext-NAF parameter, or one or more other types of security parameters in response to sending one or more calling security parameters (e.g., a CALLING_RAND parameter, a CALLING_B-TID parameter, a CALLING_Ks-ext-NAF parameter, etc.) to calleddevice120. In some implementations, one or more security parameters may be locally available to calling device110 (e.g., a NAF_ID parameter, a CALLING_ID parameter, a CALLED_ID parameter, etc.).

As illustrated, one or more of the foregoing parameters may be inserted or otherwise applied to a key generation function (e.g., a KDF) to generate a security key. The security key may be used to encrypt or decrypt messages or other information sent to and from calleddevice120. As mentioned above,data flow500 provides an example for generating a security key from the perspective of callingdevice110. As described below with reference toFIGS. 7-8C, an analogous data flow could be applied to calleddevice120.

FIG. 6 is a diagram of anexample process600 for generating a security key according to one or more implementations described herein.Process600 may be performed by, or otherwise correspond to, callingdevice110. In one or more implementations,process600 may be performed by one or more components of callingdevice110. In other implementations, one or more blocks ofprocess600 may be performed by one or more other components/devices, or a group of components/devices, including or excludingcalling device110.

Process600 may include registering with network210 (block610). For example, callingdevice110 may communicate withnetwork registration architecture130 to register withnetwork210. In some implementations, registering withnetwork210 may enable callingdevice110 to, for example, obtain access to some network services, such as standard calling services, Internet services, television services, or one or more other types of network services. As mentioned above, however, some network services may require callingdevice110, or one or more communication applications of callingdevice110, to be authenticated byapplication authentication architecture140.

Calling security parameters may be obtained (block620). For instance, callingdevice110 may obtain calling security parameters from various sources or at various times. In some implementations, callingdevice110 may obtain a CALLING_RAND parameter fromnetwork registration architecture130 in response to registering withnetwork210. Callingdevice110 may also, or alternatively, obtain a CALLING_B-TID parameter or a CALLING_Ks-ext-NAF parameter from interacting withapplication authentication architecture140. Callingdevice110 may also obtain security parameters that are locally available, such as a NAF_ID parameter, a CALLING_ID parameter, or a CALLED_ID parameter.

Calling security parameters may be communicated (block630). For example, callingdevice110 may send parameters to calleddevice120. In certain implementations, callingdevice110 may communicate one or more calling security parameters using a session initiation message, such as a SIP INVITE message. In such implementations, security parameters may be included in the SIP INVITE message by using session description protocol (SDP).

Called security parameters may be received (block640). For example, callingdevice110 may receive called security parameters from calleddevice120. As discussed above with reference toFIG. 5, called security parameters may include a CALLED_RAND parameter, a CALLED_B-TID parameter, a CALLED_Ks-ext-NAF parameter, and/or one or more other types of security parameters, such as a CALLED_ID parameter, a CALLING_ID parameter, or a NAT_ID parameter. In some implementations, one or more of the security parameters sent by calleddevice120 may already be locally available to callingdevice110. However, callingdevice120 may use such security parameters (e.g., redundant security parameters) to verify that callingdevice110 and calleddevice120 will be applying the same parameters to the key generation function.

A security key may be generated (block650). For instance, callingdevice110 may generate a security key using one or more key generation functions, as described above. Additionally, or alternatively, the security key may be based on the calling security parameters and/or the called security parameters collected or obtained by callingdevice110.

WhileFIG. 6 shows a flowchart diagram of anexample process600 for generating a security key, in other implementations, a process for generating a security key may include fewer operations, different operations, differently arranged operations, or additional operations than depicted inFIG. 6.

FIG. 7 is a diagram of anexample process700 for generating a security key according to one or more implementations described herein. As depicted,process700 may include one or more operations that are similar or analogous to the process ofFIG. 6. However, while the process ofFIG. 6 may be performed by callingdevice110,process700 may be performed by calleddevice120. For instance, in one or more implementations,process700 may be performed by one or more components of calleddevice120. In other implementations, one or more blocks ofprocess700 may be performed by one or more other components/devices, or a group of components/devices, including or excluding calleddevice120.

Process700 may include registering with network210 (block710). For example, calleddevice120 may register withnetwork210. In some implementations, calleddevice120 may register withnetwork210 by communicating withnetwork registration architecture130. In certain implementations, registering withnetwork210 may enable calleddevice120 to, for example, obtain access to one or more network services, such as standard calling services, Internet services, television services, or one or more other types of network services. However, some network services may require calleddevice120, or a communication application of calleddevice120, to be authenticated byapplication authentication architecture140.

Calling security parameters may be received (block720). For instance, calleddevice120 may receive one or more calling security parameters from callingdevice110. The calling security parameters may be included in a session initiation message (e.g., a SIP INVITE message). In certain implementations, the calling security parameters may include a NAF_ID parameter, a CALLING_ID parameter, a CALLED_ID parameter, a CALLING_RAND parameter, a CALLING_B-TID parameter, a CALLING_Ks-ext-NAF parameter, or one or more other types of security parameters. In some implementations, one or more of the security parameters sent by callingdevice110 may already be locally available to calleddevice120. However, calleddevice120 may use the security parameters (e.g., the redundant security parameters) to verify that callingdevice110 and calleddevice120 are applying the same parameters to the key generation function.

Called security parameters may be obtained (block730). For example, calleddevice120 may obtain called security parameters from one or more sources or at one or more times. For example, calleddevice120 may obtain a CALLED_RAND parameter fromnetwork registration architecture130 in response to registering withnetwork210.Called device120 may also, or alternatively, obtain a CALLED_B-TID parameter, a CALLED_Ks-ext-NAF parameter, or another type of security parameter as a result of interacting withapplication authentication architecture140.Called device120 may also, or alternatively, obtain security parameters that are available locally, such as a NAF_ID parameter, a CALLING_ID parameter, or a CALLED_ID parameter.

Called security parameters may be communicated (block740). For instance, calleddevice120 may send, or otherwise communicate, called security parameters to callingdevice110. In some implementations, calleddevice120 may communicate called security parameters in response to, for example, receiving a communication session invitation (e.g., a SIP INVITE message) with calling security parameters from callingdevice110. In such implementations, callingdevice110 may respond by sending the calling security parameters in a SIP response message, such as a SIP RINGING message that may be modified using SDP to include the called security parameters.

A security key may be generated (block750). For instance, calleddevice120 may generate a security key. In some implementations, calleddevice120 may generate a security key using a key generation function (e.g., a KDF), as described above. Additionally, or alternatively, the security key may be based on one or more security parameters. For instance, in some implementations, calleddevice120 may generate a security key by executing one or more KDFs based on one or more of the calling security parameters and/or one or more of the called security parameters.

WhileFIG. 7 shows a flowchart diagram of anexample process700 for generating a security key, in other implementations, a process for generating a security key may include fewer operations, different operations, differently arranged operations, or additional operations than depicted inFIG. 7.

FIGS. 8A-8C are diagrams of an example call session800 (referenced individually by800A,800B, and800C, respectively) according to one or more implementations described herein. As depicted, call session800 may involve callingdevice110, calleddevice120, gateway810-1, gateway810-2, P-CSCF device820, I-CSCF device830, S-CSCF device840,HSS850, telephony application server (TAS)860-1, TAS860-2, policy charging and rules function (PCRF) device870-1, PCRF device870-2, and call delivery application server (CDAS)880. WhileFIGS. 8A-8C represent a particular number and arrangement of devices, operations, and data structures, in alternative implementations, a call session may include additional devices, operations, and data structures, fewer devices, operations, and data structures, different devices, operations, and data structures, or differently arranged devices, operations, and data structures than those depicted inFIGS. 8A-8C.

Referring toFIG. 8A, callsession800A may begin with callingdevice110 triggering a GBA function (e.g., a BSF) to obtain GBA parameters (e.g., a CALLING_B-TID parameter, a CALLING_Ks-ext_NAF parameter, or other types of security parameters). In some implementations, this may include callingdevice110 communicating withapplication authentication architecture140 and receiving one or more security parameters, such as a CALLING_B-TID parameter, a CALLING_Ks-ext-NAF parameter, or another type of security parameter. Additionally, or alternatively, callingdevice110 may register withnetwork210 before triggering the GBA (see, for example,FIG. 6, blocks610 and620).

Callingdevice110 may send a session initiation message that includes the GBA parameters (event1). The session initiation message may include a SIP INVITE 100rel, timer message that is modified with SDP to include the GBA parameters. As depicted, the session invitation message may be routed to various devices, including P-CSCF device820, S-CSCF device840, TAS860-1 (which may perform number completion from 7 digits to E.164 format), TAS860-2, and CDAS880 (events2-9). The session initiation message may arrive at calleddevice120 via gateway810-2 (event10).

Similar to callingdevice110, calleddevice120 may trigger a GBA process to obtain GBA parameters, such as a CALLED_B-TID, a CALLED_Ks-ext-NAF, or one or more other types of security parameters (see, for example,FIG. 7, block730). As depicted, calleddevice120 may communicate a SIP RINGING message (180) that has been modified with SDP to include the GBA parameters obtained by called device120 (event11). The SIP RINGING message may be passed to several network devices, including P-CSCF device820, S-CSCF device840,CDAS880, TAS860-2, and TAS860-1 (events12-19). The SIP RINGING message may arrive at callingdevice110 via gateway810-1 (event20), which may result in callingdevice110 generating a local ringing tone.

At this point, callingdevice110 and callingdevice120 may each derive or otherwise calculate a security key using, for example, a KDF. As depicted, callingdevice110 may produce a SIP provisional acknowledgement (PRACK) message in response to the SIP RINGING message from called device120 (event21). The SIP PRACK message may be modified to include GBA parameters. Additionally, or alternatively, the SIP PRACK message may be communicated to various network devices including P-CSCF device820, S-CSCF device840, TAS860-1, TAS860-2, and CDAS880 (events22-29). The SIP PRACK message may arrive at calleddevice120 via gateway810-2 (event30).

Called device120 may communicate a SIP OK message (200) in response to the SIP PRACK message of callingdevice110. Similar to several of the SIP messages discussed above, the SIP OK message may be communicated to several network devices. For example, the SIP OK message may be sent to P-CSCF device820, S-CSCF device840,CDAS880, TAS860-2, and TAS860-1 (events31-39).

Referring toFIG. 8B, the SIP OK message from calleddevice120 may arrive at callingdevice110 via gateway810-1 (event40).Called device120 may also, or alternatively, communicate a SIP OK (200) message corresponding to the SIP INVITE message of callingdevice110, which may be received by P-CSCF820 (event41).

As depicted, an authentication authorization request (AAR) message and an authentication authorization answer (AAA) message may be exchanged between P-CSCF820 and PCRF870-2 via an Rx interface. Additionally, a re-authentication request (RAR) message and re-authentication answer (RAA) message may be exchanged between PCRF device870-2 and gateway810-2 via a Gx interface.

The SIP OK message corresponding to the SIP INVITE message may be sent to S-CSCF840,CDAS880, TAS860-2, TAS860-1, and again to S-CSCF device840 and P-CSCF device820 (events42-49). Similar to the Rx and Gx interface exchanges mentioned above, an authentication authorization request (AAR) message and an authentication authorization answer (AAA) message may be exchanged between P-CSCF820 and PCRF870-1 via an Rx interface. Additionally, a re-authentication request (RAR) message and re-authentication answer (RAA) message may be exchanged between PCRF device870-1 and gateway810-1 via a Gx interface.

The SIP OK message corresponding to the SIP INVITE message may be received by calling device110 (event50). At this stage, callingdevice110 and calleddevice120 may begin encrypting and decrypting a voice payload of the call session using the previously generated security keys. As depicted, a SIP acknowledgement (ACK) message may be sent from callingdevice110 to calleddevice120 via a sequence of transmissions (events51-60) that is similar to the communications described above.

Referring toFIG. 8C, a SIP BYE message may also be sent from callingdevice110 to calleddevice120 using a similar sequence of transmission (events61-70). As the SIP BYE message is being transmitted to calleddevice120, session termination request (STR) messages and session termination answer (STA) messages may be exchanged between P-CSCR device820 and PCRF device870-1 and between P-CSCR device820 and PCRF device870-1, via Rx interfaces. Similarly, RAR message and RAA messages may be exchanged between PCRF870-1 and GW810-1 and between PCRF870-2 and GW810-2, via Gx interfaces. In response to the SIP BYE message, calleddevice120 may communicate a SIP OK (200) message, which may use a sequence of transmissions similar to those discussed above (events71-81).

In one or more implementations, described herein, devices may be used to generate security keys locally. For instance, callingdevice110 may receive calling security parameters by registering withnetwork210 and interacting with application authentication architecture to demonstrate that callingdevice110 is authorized to access a particular network service (e.g., a VoIP service) and/or use a particular communication application (e.g., a VoIP application). Callingdevice110 may communicate the calling security parameters to calleddevice110 and, in response, receive called security parameters from calleddevice110. Callingdevice110 and calleddevice120 may each execute a key generation function based on the calling security parameters and the called security parameters to locally generate security keys that may be used to encrypt and/or decrypt information passed between callingdevice110 and calleddevice120.

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware could be designed to implement the aspects based on the description herein.

Further, certain implementations may involve a component that performs one or more functions. These components may include hardware, such as an ASIC or a FPGA, or a combination of hardware and software.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit disclosure of the possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one other claim, the disclosure of the implementations includes each dependent claim in combination with every other claim in the claim set.

No element, act, or instruction used in the present application should be construed as critical or essential to the implementations unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

Claims (22)

What is claimed is:

1. A method, comprising:

obtaining, by a calling device, a first calling security parameter by registering with a network;

obtaining, by the calling device, a second calling security parameter in response to causing an application authentication architecture of the network to verify that the calling device is authorized to access a network service corresponding to a communication application stored by the calling device;

communicating the first calling security parameter and the second calling security parameter to a called device;

receiving a first called security parameter and a second called security parameter from the called device in response to communicating the first calling security parameter and the second calling security parameter;

generating a security key based on the first calling security parameter, the second calling security parameter, the first called security parameter, and the second called security parameter; and

using the security key to encrypt or decrypt communication between the calling device and the called device.

2. The method ofclaim 1, further comprising:

establishing a communication session with the called device; and

using the security key to encrypt information communicated to the called device and decrypt information received from the called device during the communication session.

3. The method ofclaim 1, further comprising:

obtaining a third calling security parameter comprising a data structure used to demonstrate to the application authentication architecture that the calling device is authorized to use the communication application to establish a communication session within the network; and

communicating the third calling security parameter to the called device with the first calling security parameter and the second calling security parameter.

4. The method ofclaim 3, further comprising:

receiving a third called security parameter, from the called device, with the first called security parameter and the second called security parameter, where the third called security parameter comprises a data structure used to demonstrate to the application authentication architecture that the called device is authorized to use a communication application that corresponds to the communication application of the calling device.

5. The method ofclaim 1, where the first calling security parameter comprises a data structure identifying a network session associated with the calling device upon registering with the network.

6. The method ofclaim 1, where:

the first called security parameter comprises a data structure identifying a network session associated with the called device upon registering with the network, and

the second called security parameter comprises a security parameter type and security parameter format consistent with the second calling security parameter.

7. The method ofclaim 1, where communicating the first calling security parameter and the second calling security parameter comprises sending a session communication invitation, comprising the first and second calling security parameters, to the called device.

8. The method ofclaim 1, where generating the security key comprises executing a key generation function, where:

an input of the key generation function comprises the first calling security parameter, the second calling security parameter, the first called security parameter, and the second called security parameter, and

an output of the key generation function is the security key.

9. The method ofclaim 8, where the key generation function comprises a key derivation function (KDF) that is identical to a KDF used by the called device to generate security keys.

10. The method ofclaim 1, where:

the network comprises an Internet Protocol (IP) multimedia subsystem (IMS) network,

the application authentication architecture comprises a generic bootstrap architecture (GBA) of the IMS network, and

the second calling security parameter comprises a bootstrap transaction identifier (B-TID).

11. A first device, comprising:

a memory to:

store a communication application to enable the first device to establish a first communication session with a second device using a selected network service, and

store a first key generation function to enable the first device to generate a security key; and

a processor, connected to the memory, to:

register the first device with a network, where registering with the network comprises receiving a first network session identifier from the network,

communicate with an application authentication architecture of the network to demonstrate that the first device is authorized to use the selected network service, where communicating with the application authentication architecture comprises receiving a first transaction identifier from the application authentication architecture,

communicate the first network session identifier and the first transaction identifier to the second device,

receive a second network session identifier and a second transaction identifier from the second device, and

execute the first key generation function to generate a security key based on the first network session identifier, the first transaction identifier, the second network session identifier, and the second transaction identifier.

12. The first device ofclaim 11, where the first device obtains access to at least one network service, other than the selected network service, upon registering with the network.

13. The first device ofclaim 11, where the processor is to:

establish a communication session, with the second device, using the selected network service, and

use the security key to encrypt information sent to the second device via the selected network service and decrypt information received from the second device via the network service.

14. The first device ofclaim 11, where the processor is to:

obtain a first data structure used to demonstrate to the application authentication architecture of the network that the first device is authorized to use the communication application to establish a communication session within the network, and

communicate the first data structure, to the second device, the first network session identifier and the first transaction identifier.

15. The first device ofclaim 14, where the first transaction identifier comprises a data structure that associates the first device with a first authentication process, performed by the application authentication architecture, to verify that the first device is authorized to use the communication application.

16. The first device ofclaim 14, where the processor is to:

receive a second data structure, from the second device, with the second network session identifier and the second transaction identifier, where the second data structure comprises information used to demonstrate to the application authentication architecture that the second device is authorized to use a communication application that corresponds to the communication application stored by the first device.

17. The first device ofclaim 11, where the second transaction identifier comprises a data structure that associates the second device with a second authentication process, performed by the application authentication architecture, to verify that the second device is authorized to use a communication application that corresponds to the communication application stored by the first device.

18. The first device ofclaim 11, where, to communicate the first network session identifier and the first transaction identifier to the second device, the processor is to:

generate a communication session invitation directed to the second device,

include the first network session identifier and the first transaction identifier in the communication session invitation, and

send the communication session invitation to the second device.

19. The first device ofclaim 11, where:

the network comprises an Internet Protocol (IP) multimedia subsystem (IMS) network, and

the application authentication architecture comprises a generic bootstrap architecture (GBA) of the IMS network.

20. A non-transitory computer-readable medium storing a program for causing a first device to perform a method, the method comprising:

obtaining a first security parameter by communicating with a generic bootstrapping architecture (GBA) to demonstrate that the first device is authorized to use a selected network communication service for establishing a communication session within a network, where the first security parameter is generated by the GBA to associate the first device with a first GBA authentication process;

obtaining a second security parameter from a second device in response to communicating the first security parameter to the second device, where the second security parameter is obtained by the second device by communicating with the GBA to demonstrate that the second device is authorized to use the selected network communication service, where the second security parameter is generated by the GBA to associate the second device with a second GBA authentication process;

generating a security key based on the first security parameter and the second security parameter; and

using the security key to establish an encrypted communication session, using the selected network communication service, with the second device.

21. The computer-readable medium ofclaim 20, where the method further comprises:

obtaining a third security parameter by registering with the network, where:

registering with the network enables the first device to communicate with the GBA, and

the third security parameter is generated by a network registration architecture of the network to identify a network session associated with the first device; and

generating the security key based on the first security parameter, the second security parameter, and the third security parameter.

22. The computer-readable medium ofclaim 20, where:

the network comprises an Internet Protocol (IP) multimedia subsystem (IMS) network, and

the network communication service corresponds to a voice over IP (VoIP) communication service.

Images