US20130007434A1 - Local security key generation - Google Patents
Local security key generation Download PDFInfo
- Publication number
- US20130007434A1 US20130007434A1 US13/174,644 US201113174644A US2013007434A1 US 20130007434 A1 US20130007434 A1 US 20130007434A1 US 201113174644 A US201113174644 A US 201113174644A US 2013007434 A1 US2013007434 A1 US 2013007434A1
- Authority
- US
- United States
- Prior art keywords
- network
- calling
- security parameter
- called
- security
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
Definitions
- 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.
- FIGS. 8A-8C are diagrams of an example call session according to one or more implementations described herein.
- devices may be used to locally generate security keys.
- 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).
- IP voice over Internet Protocol
- VoIP voice over Internet Protocol
- 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 an example overview 100 of an implementation described herein. As depicted, overview 100 may include calling device 110 , called device 120 , network registration architecture 130 , and application authentication architecture 140 . In some implementations, the systems and devices of FIG. 1 may correspond to one or more systems or device discussed elsewhere in this specification.
- Calling device 110 and called device 120 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.
- calling device 110 and called device 120 may each be a smart phone.
- calling device 110 may include a tablet computer
- called device 120 may include a network application server.
- calling device 110 and called device 120 may each be application servers.
- Calling device 110 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 called device 120 may include a device that receives the communication session invitation.
- a communication session invitation e.g., a call session invitation, a session initiation protocol (SIP) INVITE message, etc.
- called device 120 may also be capable of sending a communication session invitation
- calling device 110 may be capable of receiving the communication session invitation.
- a particular device e.g., a smart phone
- calling device 110 and called device 120 may include communication applications.
- the communication applications may enable calling device 110 and called device 120 to communicate with one another via a particular type of network service.
- 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.
- application authentication architecture 140 may perform one or more authentication or authorization processes to verify that calling device 110 or called device 120 are authorized to use the communication applications and/or corresponding network service.
- calling device 110 and called device 120 may include key generation functions.
- the key generation functions may enable calling device 110 and called device 120 to generate a security key based on one or more security parameters.
- the key generation function of the calling device 110 and the key generation function of the called device 120 may be the same. For example, in some implementations, if the same parameters are inputted into the key generation function of the calling device 110 and the key generation function of the called device 120 , the outputs of both key generation functions may be the same.
- Network registration architecture 130 may include one or more of a variety of computing devices.
- network registration architecture 130 may include a desktop computer, a server, a cluster of servers, or one or more other types of computing or communication devices.
- network registration architecture 130 may be capable of registering calling device 110 or called device 120 with a network (e.g., an IP multimedia subsystem (IMS) network).
- IMS IP multimedia subsystem
- network registration architecture 130 may include one or more IMS network devices (not shown in FIG.
- CSCF call session control function
- P-CSCF proxy-CSCF
- I-CSCF interrogating-CSCF
- S-CSCF serving-CSCR
- HSS home subscriber server
- application authentication architecture 140 may include one or more of a variety of computing devices.
- application authentication architecture 140 may include a desktop computer, a server, a cluster of servers, or one or more other types of computing or communication devices.
- application authentication architecture 140 may provide one or more of a variety of authentication and/or authorization services to enable calling device 110 and called device 120 to communicate with one another via a particular network service and/or a particular communication application.
- application authentication architecture 140 may include a generic bootstrap architecture (GBA). Additionally, or alternatively, application authentication architecture 140 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 architecture 140 may communicate or otherwise cooperate with the devices of network registration architecture 130 (e.g., a HSS) in order to provide authentication and authorization services.
- GBA generic bootstrap architecture
- application authentication architecture 140 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.
- BSFs bootstrapping server functions
- NAFs network application functions
- application authentication architecture 140 may communicate or otherwise cooperate with the devices of network registration architecture 130 (e.g., a HSS) in order to provide authentication and authorization services.
- HSS network registration architecture
- calling device 110 or called device 120 may receive one or more security parameters from network registration architecture 130 .
- the security parameters from network registration architecture 130 may be received during, or in response to, calling device 110 or called device 120 registering with a network via network registration architecture 130 .
- calling device 110 or called device 120 may receive one or more security parameters from application authentication architecture 140 .
- the security parameters from application authentication architecture 140 may be received in response to application authentication architecture 140 (e.g., a BSF) verifying that calling device 110 or called device 120 is authorized to access a particular network communication service or in response to application authentication architecture 140 (e.g., a NAF) verifying that calling device 110 or called device 120 is authorized to use a particular communication application.
- application authentication architecture 140 e.g., a BSF
- application authentication architecture 140 e.g., a NAF
- Calling device 110 may communicate one or more of the security parameters received from network registration architecture 130 and application authentication architecture 140 to called device 120 .
- called device 120 may communicate one or more of the security parameters received from network registration architecture 130 and application authentication architecture 140 to calling device 110 . In some implementations, this may ensure that calling device 110 and called device 120 apply the same security parameters to the key generation functions in order to generate security keys that complement one another. Additionally, or alternatively, calling device 110 or called device 120 may use security keys to encrypt and decrypt a communication session (e.g., a VoIP call session).
- a communication session e.g., a VoIP call session
- FIG. 2 is a diagram of an example environment 200 in which systems and/or methods, described herein, may be implemented.
- environment 200 may include calling device 110 , called device 120 , network registration architecture 130 , application authentication architecture 140 , and network 210 .
- FIG. 2 shows a particular number and arrangement of networks and devices, in alternative implementations, environment 200 may include additional networks or devices, fewer networks or devices, different networks or devices, or differently arranged networks or devices than those depicted in FIG. 2 .
- Network 210 may include any type of network or combination of networks.
- network 210 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).
- LAN local area network
- WLAN wireless LAN
- WAN wide area network
- WWAN wireless WAN
- LTE Long-Term Evolution
- HSPA High-Speed Packet Access
- eHRPD Evolved High Rate Packet Data
- Network 210 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)).
- a fiber optic e.g., a fiber optic service (FiOS)
- VoIP Voice over IP
- MAN metropolitan area network
- MAN metropolitan area network
- ad hoc network e.g., a wireless local area network (WLAN)
- PSTN Public Switched Telephone Network
- network 210 may include one or more LTE access networks connected to an IMS network.
- calling device 110 or called device 120 may include one or more LTE-enabled user devices (e.g., a smart phone, a tablet computer, a laptop computer, etc.).
- network registration architecture 130 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.
- application authentication architecture 140 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 a device 300 according to one or more implementations described herein.
- Device 300 may correspond to calling device 110 , called device 120 , network registration architecture 130 , and/or application authentication architecture 140 .
- Each of calling device 110 , called device 120 , network registration architecture 130 , and/or application authentication architecture 140 may include one or more devices 300 or one or more of the components of device 300 .
- device 300 may include bus 310 , processor 320 , memory 330 , input device 340 , output device 350 , and communication interface 360 .
- device 300 may include fewer components, additional components, different components, or differently arranged components than those illustrated in FIG. 3 .
- Bus 310 may include one or more component subsystems or communication paths that enable the components of device 300 to communicate.
- Processor 320 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.
- Processor 320 may control the overall operation, or a portion thereof, of device 300 , based on, for example, an operating system and/or various applications.
- Processor 320 may access instructions from memory 330 , from other components of device 300 , or from a source external to device 300 (e.g., a network or another device).
- Memory 330 may include memory and/or secondary storage.
- memory 330 may include random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), programmable ROM (PROM), flash memory, or some other type of memory.
- RAM random access memory
- DRAM dynamic RAM
- ROM read-only memory
- PROM programmable ROM
- Memory 330 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 device 340 may include one or more components that permit a user to input information into device 300 .
- input device 340 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 device 350 may include one or more components that permit device 300 to output information to a user.
- output device 350 may include a display, light-emitting diodes (LEDs), an output port, a speaker, or some other type of output component.
- LEDs light-emitting diodes
- Communication interface 360 may include one or more components that permit device 300 to communicate with other devices or networks.
- communication interface 360 may include some type of wireless or wired interface.
- Communication interface 330 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.
- RF radio frequency
- device 300 may perform certain operations in response to processor 320 executing software instructions contained in a computer-readable medium, such as memory 330 .
- the software instructions may be read into memory 330 from another computer-readable medium or from another device via communication interface 360 .
- the software instructions contained in memory 330 may cause processor 320 to perform one or more processes described herein.
- hardwired circuitry may be used in place of, or in combination with, software instructions to implement processes described herein.
- implementations described herein are not limited to any specific combination of hardware circuitry and software.
- FIG. 4 is a diagram of example functional components 400 corresponding to one or more implementations described herein.
- calling device 110 or called device 120 may include functional components 400 .
- functional components 400 may include registration module 410 , communication application module 420 , security parameters module 430 , and key generation module 440 .
- one or more of modules 410 - 440 may be implemented as a combination of hardware and software based on the components illustrated and described with respect to FIG. 3 .
- modules 410 - 440 may each be implemented as hardware based on the components illustrated and described with respect to FIG. 3 .
- FIG. 4 shows a particular number and arrangement of modules, in alternative implementations, functional components 400 may include additional modules, fewer modules, different modules, or differently arranged modules than those depicted.
- Registration module 410 may provide calling device 110 or called device 120 with functionality regarding network registration.
- network registration module 410 may communicate with network registration architecture 130 to register with network 210 , which may include establishing a communication session (e.g., a SIP session) with network 210 .
- network 210 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.
- a RAND may also be used as a security parameter for generating a security key.
- calling device 110 or called device 120 may be granted access to one or more network services (e.g., standard calling services, Internet access, etc.).
- network services e.g., VoIP services, SMS services, IM services, video conferencing services, etc.
- VoIP services e.g., VoIP services, SMS services, IM services, video conferencing services, etc.
- application authentication architecture 140 may perform one or more application authentication procedures as described herein.
- Communication application module 420 may provide calling device 110 or called device 120 with functionality regarding communication applications.
- communication application module 420 may include a VoIP application that enables calling device 110 or called device 120 to communicate over network 210 via VoIP.
- communication application module 420 may communicate with application authentication architecture 140 to complete the authentication process.
- Application authentication architecture 140 may communicate with network registration architecture 130 (e.g., HSS) to determine whether calling device 110 or called device 120 is authorized for a particular network service (e.g., a VoIP service, SMS service, etc.).
- Application authentication architecture 140 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.
- a transaction identifier e.g., a bootstrapping transaction identifier (B-TID)
- a NAF identifier e.g., a NAF_ID
- a NAF key e.g., an external NAF key, Ks_ext_NAF, etc.
- a NAF key may be submitted to a NAF so that calling device 110 or called device 120 may, for example, use a stored communication application to gain access to a particular network service.
- Security parameters module 430 may provide calling device 110 or called device 120 with functionality regarding security parameters. For instance, security parameters module 430 may collect security parameters (e.g., a RAND_ID) received by network registration module 410 during a network registration process, or security parameters (e.g., a B-TID, Ks_ext_NAF, etc.) received by communication application module 420 during an authentication or authorization process. Security parameters module 430 may also, or alternatively, collect one or more security parameters that may be available locally.
- security parameters e.g., a RAND_ID
- security parameters e.g., a B-TID, Ks_ext_NAF, etc.
- Examples of such parameters may include a telephone number or another type of identifier associated with calling device 110 (e.g., a CALLING_ID), a telephone number or another type of identifier associated with called device 120 , and/or an identifier associated with a network service or network application function (e.g., a NAF_ID).
- a telephone number or another type of identifier associated with calling device 110 e.g., a CALLING_ID
- a telephone number or another type of identifier associated with called device 120 e.g., a telephone number or another type of identifier associated with called device 120
- an identifier associated with a network service or network application function e.g., a NAF_ID
- Security parameters module 430 may communicate one or more security parameters to called device 120 and, in response, receive one or more security parameters from called device 120 .
- security parameters module 430 may receive one or more security parameters from calling device 110 and, in response, collect and communicate security parameters to the calling device 110 .
- security parameters collected by, communicated by, or otherwise corresponding to calling device 110 may be identified as calling security parameters (e.g., CALLING_RAND_ID, CALLING_B-TID, etc.).
- security parameters collected by, communicated by, or otherwise corresponding to called device 120 may be identified as called security parameters (e.g., CALLED_RAND_ID, CALLED_B-TID, etc.).
- Key generation module 440 may provide calling device 110 or called device 120 with functionality regarding security keys. For example, key generation module 440 may generate a security key based on one or more of the security parameters collected or otherwise obtained by security parameters module 430 . In some implementations, key generation module 440 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.
- KDF key derivation function
- 3GPP 3rd Generation Partnership Project
- FIG. 5 is a diagram of an example data flow 500 for generating a security key according to one or more implementations described herein.
- Example data flow 500 is presented from the perspective of calling device 110 collecting or otherwise obtaining security parameters.
- a similar or analogous data flow could be applicable to called device 120 .
- security parameters may be obtained by calling device 110 from different sources and at different times.
- calling device 110 may receive a CALLING_RAND parameter or another type of security parameter from network registration architecture 130 while registering with network 210 .
- calling device 110 may receive a CALLING_B-TID parameter, a CALLING_Ks-ext-NAF parameter, or one or more other types of security parameters while communicating with application authentication architecture 140 to, for example, obtain authorization to access a particular network service or use a particular communication application.
- Calling device 110 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 called device 120 .
- one or more security parameters may be locally available to calling device 110 (e.g., a NAF_ID parameter, a CALLING_ID parameter, a CALLED_ID parameter, etc.).
- 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 called device 120 .
- data flow 500 provides an example for generating a security key from the perspective of calling device 110 .
- an analogous data flow could be applied to called device 120 .
- FIG. 6 is a diagram of an example process 600 for generating a security key according to one or more implementations described herein.
- Process 600 may be performed by, or otherwise correspond to, calling device 110 .
- process 600 may be performed by one or more components of calling device 110 .
- one or more blocks of process 600 may be performed by one or more other components/devices, or a group of components/devices, including or excluding calling device 110 .
- Process 600 may include registering with network 210 (block 610 ).
- calling device 110 may communicate with network registration architecture 130 to register with network 210 .
- registering with network 210 may enable calling device 110 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.
- some network services may require calling device 110 , or one or more communication applications of calling device 110 , to be authenticated by application authentication architecture 140 .
- Calling security parameters may be obtained (block 620 ). For instance, calling device 110 may obtain calling security parameters from various sources or at various times. In some implementations, calling device 110 may obtain a CALLING_RAND parameter from network registration architecture 130 in response to registering with network 210 . Calling device 110 may also, or alternatively, obtain a CALLING_B-TID parameter or a CALLING_Ks-ext-NAF parameter from interacting with application authentication architecture 140 . Calling device 110 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 (block 630 ).
- calling device 110 may send parameters to called device 120 .
- calling device 110 may communicate one or more calling security parameters using a session initiation message, such as a SIP INVITE message.
- security parameters may be included in the SIP INVITE message by using session description protocol (SDP).
- SDP session description protocol
- Called security parameters may be received (block 640 ).
- calling device 110 may receive called security parameters from called device 120 .
- 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.
- one or more of the security parameters sent by called device 120 may already be locally available to calling device 110 . However, calling device 120 may use such security parameters (e.g., redundant security parameters) to verify that calling device 110 and called device 120 will be applying the same parameters to the key generation function.
- a security key may be generated (block 650 ). For instance, calling device 110 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 calling device 110 .
- FIG. 6 shows a flowchart diagram of an example process 600 for generating a security key
- a process for generating a security key may include fewer operations, different operations, differently arranged operations, or additional operations than depicted in FIG. 6 .
- FIG. 7 is a diagram of an example process 700 for generating a security key according to one or more implementations described herein.
- process 700 may include one or more operations that are similar or analogous to the process of FIG. 6 .
- process 700 may be performed by called device 120 .
- process 700 may be performed by one or more components of called device 120 .
- one or more blocks of process 700 may be performed by one or more other components/devices, or a group of components/devices, including or excluding called device 120 .
- Process 700 may include registering with network 210 (block 710 ).
- called device 120 may register with network 210 .
- called device 120 may register with network 210 by communicating with network registration architecture 130 .
- registering with network 210 may enable called device 120 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.
- network services such as standard calling services, Internet services, television services, or one or more other types of network services.
- some network services may require called device 120 , or a communication application of called device 120 , to be authenticated by application authentication architecture 140 .
- Calling security parameters may be received (block 720 ).
- called device 120 may receive one or more calling security parameters from calling device 110 .
- the calling security parameters may be included in a session initiation message (e.g., a SIP INVITE message).
- 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.
- one or more of the security parameters sent by calling device 110 may already be locally available to called device 120 . However, called device 120 may use the security parameters (e.g., the redundant security parameters) to verify that calling device 110 and called device 120 are applying the same parameters to the key generation function.
- Called security parameters may be obtained (block 730 ).
- called device 120 may obtain called security parameters from one or more sources or at one or more times.
- called device 120 may obtain a CALLED_RAND parameter from network registration architecture 130 in response to registering with network 210 .
- Called device 120 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 with application authentication architecture 140 .
- Called device 120 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 (block 740 ).
- called device 120 may send, or otherwise communicate, called security parameters to calling device 110 .
- called device 120 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 calling device 110 .
- calling device 110 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 (block 750 ). For instance, called device 120 may generate a security key. In some implementations, called device 120 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, called device 120 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.
- a key generation function e.g., a KDF
- FIG. 7 shows a flowchart diagram of an example process 700 for generating a security key
- a process for generating a security key may include fewer operations, different operations, differently arranged operations, or additional operations than depicted in FIG. 7 .
- FIGS. 8A-8C are diagrams of an example call session 800 (referenced individually by 800 A, 800 B, and 800 C, respectively) according to one or more implementations described herein.
- call session 800 may involve calling device 110 , called device 120 , gateway 810 - 1 , gateway 810 - 2 , P-CSCF device 820 , I-CSCF device 830 , S-CSCF device 840 , HSS 850 , telephony application server (TAS) 860 - 1 , TAS 860 - 2 , policy charging and rules function (PCRF) device 870 - 1 , PCRF device 870 - 2 , and call delivery application server (CDAS) 880 . While FIGS.
- TAS telephony application server
- PCRF policy charging and rules function
- CDAS call delivery application server
- 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 in FIGS. 8A-8C .
- call session 800 A may begin with calling device 110 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).
- GBA parameters e.g., a CALLING_B-TID parameter, a CALLING_Ks-ext_NAF parameter, or other types of security parameters.
- this may include calling device 110 communicating with application authentication architecture 140 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.
- calling device 110 may register with network 210 before triggering the GBA (see, for example, FIG. 6 , blocks 610 and 620 ).
- Calling device 110 may send a session initiation message that includes the GBA parameters (event 1 ).
- the session initiation message may include a SIP INVITE 100rel, timer message that is modified with SDP to include the GBA parameters.
- the session invitation message may be routed to various devices, including P-CSCF device 820 , S-CSCF device 840 , TAS 860 - 1 (which may perform number completion from 7 digits to E.164 format), TAS 860 - 2 , and CDAS 880 (events 2 - 9 ).
- the session initiation message may arrive at called device 120 via gateway 810 - 2 (event 10 ).
- called device 120 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 , block 730 ).
- called device 120 may communicate a SIP RINGING message (180) that has been modified with SDP to include the GBA parameters obtained by called device 120 (event 11 ).
- the SIP RINGING message may be passed to several network devices, including P-CSCF device 820 , S-CSCF device 840 , CDAS 880 , TAS 860 - 2 , and TAS 860 - 1 (events 12 - 19 ).
- the SIP RINGING message may arrive at calling device 110 via gateway 810 - 1 (event 20 ), which may result in calling device 110 generating a local ringing tone.
- calling device 110 and calling device 120 may each derive or otherwise calculate a security key using, for example, a KDF.
- calling device 110 may produce a SIP provisional acknowledgement (PRACK) message in response to the SIP RINGING message from called device 120 (event 21 ).
- 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 device 820 , S-CSCF device 840 , TAS 860 - 1 , TAS 860 - 2 , and CDAS 880 (events 22 - 29 ).
- the SIP PRACK message may arrive at called device 120 via gateway 810 - 2 (event 30 ).
- Called device 120 may communicate a SIP OK message (200) in response to the SIP PRACK message of calling device 110 . 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 device 820 , S-CSCF device 840 , CDAS 880 , TAS 860 - 2 , and TAS 860 - 1 (events 31 - 39 ).
- the SIP OK message from called device 120 may arrive at calling device 110 via gateway 810 - 1 (event 40 ).
- Called device 120 may also, or alternatively, communicate a SIP OK (200) message corresponding to the SIP INVITE message of calling device 110 , which may be received by P-CSCF 820 (event 41 ).
- an authentication authorization request (AAR) message and an authentication authorization answer (AAA) message may be exchanged between P-CSCF 820 and PCRF 870 - 2 via an Rx interface.
- a re-authentication request (RAR) message and re-authentication answer (RAA) message may be exchanged between PCRF device 870 - 2 and gateway 810 - 2 via a Gx interface.
- the SIP OK message corresponding to the SIP INVITE message may be sent to S-CSCF 840 , CDAS 880 , TAS 860 - 2 , TAS 860 - 1 , and again to S-CSCF device 840 and P-CSCF device 820 (events 42 - 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-CSCF 820 and PCRF 870 - 1 via an Rx interface. Additionally, a re-authentication request (RAR) message and re-authentication answer (RAA) message may be exchanged between PCRF device 870 - 1 and gateway 810 - 1 via a Gx interface.
- AAR authentication authorization request
- AAA authentication authorization answer
- RAR re-authentication request
- RAA re-authentication answer
- the SIP OK message corresponding to the SIP INVITE message may be received by calling device 110 (event 50 ).
- calling device 110 and called device 120 may begin encrypting and decrypting a voice payload of the call session using the previously generated security keys.
- a SIP acknowledgement (ACK) message may be sent from calling device 110 to called device 120 via a sequence of transmissions (events 51 - 60 ) that is similar to the communications described above.
- a SIP BYE message may also be sent from calling device 110 to called device 120 using a similar sequence of transmission (events 61 - 70 ).
- session termination request (STR) messages and session termination answer (STA) messages may be exchanged between P-CSCR device 820 and PCRF device 870 - 1 and between P-CSCR device 820 and PCRF device 870 - 1 , via Rx interfaces.
- RAR message and RAA messages may be exchanged between PCRF 870 - 1 and GW 810 - 1 and between PCRF 870 - 2 and GW 810 - 2 , via Gx interfaces.
- called device 120 may communicate a SIP OK (200) message, which may use a sequence of transmissions similar to those discussed above (events 71 - 81 ).
- devices may be used to generate security keys locally.
- calling device 110 may receive calling security parameters by registering with network 210 and interacting with application authentication architecture to demonstrate that calling device 110 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).
- Calling device 110 may communicate the calling security parameters to called device 110 and, in response, receive called security parameters from called device 110 .
- Calling device 110 and called device 120 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 calling device 110 and called device 120 .
- 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.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
- 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.
-
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. - 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 overview 100 of an implementation described herein. As depicted,overview 100 may includecalling device 110, calleddevice 120,network registration architecture 130, andapplication authentication architecture 140. In some implementations, the systems and devices ofFIG. 1 may correspond to one or more systems or device discussed elsewhere in this specification. -
Calling device 110 and calleddevice 120 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, callingdevice 110 and calleddevice 120 may each be a smart phone. However, in another example,calling device 110 may include a tablet computer, and calleddevice 120 may include a network application server. In yet another example, callingdevice 110 and calleddevice 120 may each be application servers. -
Calling device 110 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 calleddevice 120 may include a device that receives the communication session invitation. However, in some implementations, calleddevice 120 may also be capable of sending a communication session invitation, and callingdevice 110 may be capable of receiving the communication session invitation. In certain implementations, therefore, a particular device (e.g., a smart phone) may operate ascalling device 110 in one scenario and calleddevice 120 in another scenario. - As depicted, calling
device 110 and calleddevice 120 may include communication applications. The communication applications may enable callingdevice 110 and calleddevice 120 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 architecture 140 may perform one or more authentication or authorization processes to verify that callingdevice 110 or calleddevice 120 are authorized to use the communication applications and/or corresponding network service. - Additionally, or alternatively, calling
device 110 and calleddevice 120 may include key generation functions. The key generation functions may enable callingdevice 110 and calleddevice 120 to generate a security key based on one or more security parameters. In certain implementations, the key generation function of thecalling device 110 and the key generation function of the calleddevice 120 may be the same. For example, in some implementations, if the same parameters are inputted into the key generation function of thecalling device 110 and the key generation function of the calleddevice 120, the outputs of both key generation functions may be the same. -
Network registration architecture 130 may include one or more of a variety of computing devices. For example,network registration architecture 130 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 architecture 130 may be capable of registeringcalling device 110 or calleddevice 120 with a network (e.g., an IP multimedia subsystem (IMS) network). In some implementations,network registration architecture 130 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 architecture 140 may include one or more of a variety of computing devices. For example,application authentication architecture 140 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 architecture 140 may provide one or more of a variety of authentication and/or authorization services to enable callingdevice 110 and calleddevice 120 to communicate with one another via a particular network service and/or a particular communication application. - In certain implementations,
application authentication architecture 140 may include a generic bootstrap architecture (GBA). Additionally, or alternatively,application authentication architecture 140 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 architecture 140 may communicate or otherwise cooperate with the devices of network registration architecture 130 (e.g., a HSS) in order to provide authentication and authorization services. - As depicted, calling
device 110 or calleddevice 120 may receive one or more security parameters fromnetwork registration architecture 130. In some implementations, the security parameters fromnetwork registration architecture 130 may be received during, or in response to, callingdevice 110 or calleddevice 120 registering with a network vianetwork registration architecture 130. Additionally, or alternatively, callingdevice 110 or calleddevice 120 may receive one or more security parameters fromapplication authentication architecture 140. In some implementations, the security parameters fromapplication authentication architecture 140 may be received in response to application authentication architecture 140 (e.g., a BSF) verifying that callingdevice 110 or calleddevice 120 is authorized to access a particular network communication service or in response to application authentication architecture 140 (e.g., a NAF) verifying that callingdevice 110 or calleddevice 120 is authorized to use a particular communication application. -
Calling device 110 may communicate one or more of the security parameters received fromnetwork registration architecture 130 andapplication authentication architecture 140 to calleddevice 120. Similarly, calleddevice 120 may communicate one or more of the security parameters received fromnetwork registration architecture 130 andapplication authentication architecture 140 to callingdevice 110. In some implementations, this may ensure that callingdevice 110 and calleddevice 120 apply the same security parameters to the key generation functions in order to generate security keys that complement one another. Additionally, or alternatively, callingdevice 110 or calleddevice 120 may use security keys to encrypt and decrypt a communication session (e.g., a VoIP call session). -
FIG. 2 is a diagram of anexample environment 200 in which systems and/or methods, described herein, may be implemented. As depicted,environment 200 may includecalling device 110, calleddevice 120,network registration architecture 130,application authentication architecture 140, andnetwork 210. WhileFIG. 2 shows a particular number and arrangement of networks and devices, in alternative implementations,environment 200 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 device 110, calleddevice 120,network registration architecture 130, andapplication authentication architecture 140 are each described above with reference toFIG. 1 . Network 210 may include any type of network or combination of networks. For example,network 210 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). Network 210 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,
network 210 may include one or more LTE access networks connected to an IMS network. In such implementations, callingdevice 110 or calleddevice 120 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 architecture 130 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 architecture 140 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 adevice 300 according to one or more implementations described herein.Device 300 may correspond to callingdevice 110, calleddevice 120,network registration architecture 130, and/orapplication authentication architecture 140. Each of callingdevice 110, calleddevice 120,network registration architecture 130, and/orapplication authentication architecture 140 may include one ormore devices 300 or one or more of the components ofdevice 300. As depicted,device 300 may includebus 310,processor 320,memory 330,input device 340,output device 350, andcommunication interface 360. However, in other implementations,device 300 may include fewer components, additional components, different components, or differently arranged components than those illustrated inFIG. 3 . -
Bus 310 may include one or more component subsystems or communication paths that enable the components ofdevice 300 to communicate.Processor 320 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.Processor 320 may control the overall operation, or a portion thereof, ofdevice 300, based on, for example, an operating system and/or various applications.Processor 320 may access instructions frommemory 330, from other components ofdevice 300, or from a source external to device 300 (e.g., a network or another device). -
Memory 330 may include memory and/or secondary storage. For example,memory 330 may include random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), programmable ROM (PROM), flash memory, or some other type of memory.Memory 330 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 device 340 may include one or more components that permit a user to input information intodevice 300. For example,input device 340 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 device 350 may include one or more components that permitdevice 300 to output information to a user. For example,output device 350 may include a display, light-emitting diodes (LEDs), an output port, a speaker, or some other type of output component. -
Communication interface 360 may include one or more components that permitdevice 300 to communicate with other devices or networks. For example,communication interface 360 may include some type of wireless or wired interface.Communication interface 330 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,
device 300 may perform certain operations in response toprocessor 320 executing software instructions contained in a computer-readable medium, such asmemory 330. The software instructions may be read intomemory 330 from another computer-readable medium or from another device viacommunication interface 360. The software instructions contained inmemory 330 may causeprocessor 320 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 components 400 corresponding to one or more implementations described herein. For example, callingdevice 110 or calleddevice 120 may includefunctional components 400. As depicted,functional components 400 may includeregistration module 410,communication application module 420,security parameters module 430, andkey generation module 440. Depending on the implementation, one or more of modules 410-440 may be implemented as a combination of hardware and software based on the components illustrated and described with respect toFIG. 3 . Alternatively, modules 410-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 components 400 may include additional modules, fewer modules, different modules, or differently arranged modules than those depicted. -
Registration module 410 may provide callingdevice 110 or calleddevice 120 with functionality regarding network registration. For example,network registration module 410 may communicate withnetwork registration architecture 130 to register withnetwork 210, which may include establishing a communication session (e.g., a SIP session) withnetwork 210. Additionally, or alternatively,network 210 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 with
network 210, callingdevice 110 or calleddevice 120 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 architecture 140 to perform one or more application authentication procedures as described herein. -
Communication application module 420 may provide callingdevice 110 or calleddevice 120 with functionality regarding communication applications. For instance,communication application module 420 may include a VoIP application that enables callingdevice 110 or calleddevice 120 to communicate overnetwork 210 via VoIP. In implementations where a communication application requires authentication,communication application module 420 may communicate withapplication authentication architecture 140 to complete the authentication process. -
Application authentication architecture 140 may communicate with network registration architecture 130 (e.g., HSS) to determine whether callingdevice 110 or calleddevice 120 is authorized for a particular network service (e.g., a VoIP service, SMS service, etc.).Application authentication architecture 140 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 callingdevice 110 or calleddevice 120 may, for example, use a stored communication application to gain access to a particular network service. -
Security parameters module 430 may provide callingdevice 110 or calleddevice 120 with functionality regarding security parameters. For instance,security parameters module 430 may collect security parameters (e.g., a RAND_ID) received bynetwork registration module 410 during a network registration process, or security parameters (e.g., a B-TID, Ks_ext_NAF, etc.) received bycommunication application module 420 during an authentication or authorization process.Security parameters module 430 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 device 110 (e.g., a CALLING_ID), a telephone number or another type of identifier associated with calleddevice 120, and/or an identifier associated with a network service or network application function (e.g., a NAF_ID). -
Security parameters module 430 may communicate one or more security parameters to calleddevice 120 and, in response, receive one or more security parameters from calleddevice 120. Alternatively,security parameters module 430 may receive one or more security parameters from callingdevice 110 and, in response, collect and communicate security parameters to thecalling device 110. In some implementations, security parameters collected by, communicated by, or otherwise corresponding to callingdevice 110 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 calleddevice 120 may be identified as called security parameters (e.g., CALLED_RAND_ID, CALLED_B-TID, etc.). -
Key generation module 440 may provide callingdevice 110 or calleddevice 120 with functionality regarding security keys. For example,key generation module 440 may generate a security key based on one or more of the security parameters collected or otherwise obtained bysecurity parameters module 430. In some implementations,key generation module 440 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 flow 500 for generating a security key according to one or more implementations described herein.Example data flow 500 is presented from the perspective of callingdevice 110 collecting or otherwise obtaining security parameters. A similar or analogous data flow could be applicable to calleddevice 120. - As depicted, security parameters may be obtained by calling
device 110 from different sources and at different times. For example, callingdevice 110 may receive a CALLING_RAND parameter or another type of security parameter fromnetwork registration architecture 130 while registering withnetwork 210. Additionally, or alternatively, callingdevice 110 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 architecture 140 to, for example, obtain authorization to access a particular network service or use a particular communication application. - Calling
device 110 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 calleddevice 120. In some implementations, one or more security parameters may be locally available to calling device 110 (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 called
device 120. As mentioned above,data flow 500 provides an example for generating a security key from the perspective of callingdevice 110. As described below with reference toFIGS. 7-8C , an analogous data flow could be applied to calleddevice 120. -
FIG. 6 is a diagram of anexample process 600 for generating a security key according to one or more implementations described herein.Process 600 may be performed by, or otherwise correspond to, callingdevice 110. In one or more implementations,process 600 may be performed by one or more components of callingdevice 110. In other implementations, one or more blocks ofprocess 600 may be performed by one or more other components/devices, or a group of components/devices, including or excludingcalling device 110. -
Process 600 may include registering with network 210 (block 610). For example, callingdevice 110 may communicate withnetwork registration architecture 130 to register withnetwork 210. In some implementations, registering withnetwork 210 may enable callingdevice 110 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 callingdevice 110, or one or more communication applications of callingdevice 110, to be authenticated byapplication authentication architecture 140. - Calling security parameters may be obtained (block 620). For instance, calling
device 110 may obtain calling security parameters from various sources or at various times. In some implementations, callingdevice 110 may obtain a CALLING_RAND parameter fromnetwork registration architecture 130 in response to registering withnetwork 210. Callingdevice 110 may also, or alternatively, obtain a CALLING_B-TID parameter or a CALLING_Ks-ext-NAF parameter from interacting withapplication authentication architecture 140. Callingdevice 110 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 (block 630). For example, calling
device 110 may send parameters to calleddevice 120. In certain implementations, callingdevice 110 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 (block 640). For example, calling
device 110 may receive called security parameters from calleddevice 120. 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 calleddevice 120 may already be locally available to callingdevice 110. However, callingdevice 120 may use such security parameters (e.g., redundant security parameters) to verify that callingdevice 110 and calleddevice 120 will be applying the same parameters to the key generation function. - A security key may be generated (block 650). For instance, calling
device 110 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 callingdevice 110. - While
FIG. 6 shows a flowchart diagram of anexample process 600 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 process 700 for generating a security key according to one or more implementations described herein. As depicted,process 700 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 callingdevice 110,process 700 may be performed by calleddevice 120. For instance, in one or more implementations,process 700 may be performed by one or more components of calleddevice 120. In other implementations, one or more blocks ofprocess 700 may be performed by one or more other components/devices, or a group of components/devices, including or excluding calleddevice 120. -
Process 700 may include registering with network 210 (block 710). For example, calleddevice 120 may register withnetwork 210. In some implementations, calleddevice 120 may register withnetwork 210 by communicating withnetwork registration architecture 130. In certain implementations, registering withnetwork 210 may enable calleddevice 120 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 calleddevice 120, or a communication application of calleddevice 120, to be authenticated byapplication authentication architecture 140. - Calling security parameters may be received (block 720). For instance, called
device 120 may receive one or more calling security parameters from callingdevice 110. 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 callingdevice 110 may already be locally available to calleddevice 120. However, calleddevice 120 may use the security parameters (e.g., the redundant security parameters) to verify that callingdevice 110 and calleddevice 120 are applying the same parameters to the key generation function. - Called security parameters may be obtained (block 730). For example, called
device 120 may obtain called security parameters from one or more sources or at one or more times. For example, calleddevice 120 may obtain a CALLED_RAND parameter fromnetwork registration architecture 130 in response to registering withnetwork 210.Called device 120 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 architecture 140.Called device 120 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 (block 740). For instance, called
device 120 may send, or otherwise communicate, called security parameters to callingdevice 110. In some implementations, calleddevice 120 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 callingdevice 110. In such implementations, callingdevice 110 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 (block 750). For instance, called
device 120 may generate a security key. In some implementations, calleddevice 120 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, calleddevice 120 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. - While
FIG. 7 shows a flowchart diagram of anexample process 700 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 session 800 (referenced individually by 800A, 800B, and 800C, respectively) according to one or more implementations described herein. As depicted, call session 800 may involve callingdevice 110, calleddevice 120, gateway 810-1, gateway 810-2, P-CSCF device 820, I-CSCF device 830, S-CSCF device 840,HSS 850, telephony application server (TAS) 860-1, TAS 860-2, policy charging and rules function (PCRF) device 870-1, PCRF device 870-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 to
FIG. 8A , callsession 800A may begin with callingdevice 110 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 callingdevice 110 communicating withapplication authentication architecture 140 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, callingdevice 110 may register withnetwork 210 before triggering the GBA (see, for example,FIG. 6 , blocks 610 and 620). - Calling
device 110 may send a session initiation message that includes the GBA parameters (event 1). 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 device 820, S-CSCF device 840, TAS 860-1 (which may perform number completion from 7 digits to E.164 format), TAS 860-2, and CDAS 880 (events 2-9). The session initiation message may arrive at calleddevice 120 via gateway 810-2 (event 10). - Similar to calling
device 110, calleddevice 120 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 , block 730). As depicted, calleddevice 120 may communicate a SIP RINGING message (180) that has been modified with SDP to include the GBA parameters obtained by called device 120 (event 11). The SIP RINGING message may be passed to several network devices, including P-CSCF device 820, S-CSCF device 840,CDAS 880, TAS 860-2, and TAS 860-1 (events 12-19). The SIP RINGING message may arrive at callingdevice 110 via gateway 810-1 (event 20), which may result in callingdevice 110 generating a local ringing tone. - At this point, calling
device 110 and callingdevice 120 may each derive or otherwise calculate a security key using, for example, a KDF. As depicted, callingdevice 110 may produce a SIP provisional acknowledgement (PRACK) message in response to the SIP RINGING message from called device 120 (event 21). 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 device 820, S-CSCF device 840, TAS 860-1, TAS 860-2, and CDAS 880 (events 22-29). The SIP PRACK message may arrive at calleddevice 120 via gateway 810-2 (event 30). -
Called device 120 may communicate a SIP OK message (200) in response to the SIP PRACK message of callingdevice 110. 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 device 820, S-CSCF device 840,CDAS 880, TAS 860-2, and TAS 860-1 (events 31-39). - Referring to
FIG. 8B , the SIP OK message from calleddevice 120 may arrive at callingdevice 110 via gateway 810-1 (event 40).Called device 120 may also, or alternatively, communicate a SIP OK (200) message corresponding to the SIP INVITE message of callingdevice 110, which may be received by P-CSCF 820 (event 41). - As depicted, an authentication authorization request (AAR) message and an authentication authorization answer (AAA) message may be exchanged between P-
CSCF 820 and PCRF 870-2 via an Rx interface. Additionally, a re-authentication request (RAR) message and re-authentication answer (RAA) message may be exchanged between PCRF device 870-2 and gateway 810-2 via a Gx interface. - The SIP OK message corresponding to the SIP INVITE message may be sent to S-
CSCF 840,CDAS 880, TAS 860-2, TAS 860-1, and again to S-CSCF device 840 and P-CSCF device 820 (events 42-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-CSCF 820 and PCRF 870-1 via an Rx interface. Additionally, a re-authentication request (RAR) message and re-authentication answer (RAA) message may be exchanged between PCRF device 870-1 and gateway 810-1 via a Gx interface. - The SIP OK message corresponding to the SIP INVITE message may be received by calling device 110 (event 50). At this stage, calling
device 110 and calleddevice 120 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 callingdevice 110 to calleddevice 120 via a sequence of transmissions (events 51-60) that is similar to the communications described above. - Referring to
FIG. 8C , a SIP BYE message may also be sent from callingdevice 110 to calleddevice 120 using a similar sequence of transmission (events 61-70). As the SIP BYE message is being transmitted to calleddevice 120, session termination request (STR) messages and session termination answer (STA) messages may be exchanged between P-CSCR device 820 and PCRF device 870-1 and between P-CSCR device 820 and PCRF device 870-1, via Rx interfaces. Similarly, RAR message and RAA messages may be exchanged between PCRF 870-1 and GW 810-1 and between PCRF 870-2 and GW 810-2, via Gx interfaces. In response to the SIP BYE message, calleddevice 120 may communicate a SIP OK (200) message, which may use a sequence of transmissions similar to those discussed above (events 71-81). - In one or more implementations, described herein, devices may be used to generate security keys locally. For instance, calling
device 110 may receive calling security parameters by registering withnetwork 210 and interacting with application authentication architecture to demonstrate that callingdevice 110 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). Callingdevice 110 may communicate the calling security parameters to calleddevice 110 and, in response, receive called security parameters from calleddevice 110. Callingdevice 110 and calleddevice 120 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 callingdevice 110 and calleddevice 120. - 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)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/174,644 US9270453B2 (en) | 2011-06-30 | 2011-06-30 | Local security key generation |
US13/412,141 US9154527B2 (en) | 2011-06-30 | 2012-03-05 | Security key creation |
US13/584,226 US8990554B2 (en) | 2011-06-30 | 2012-08-13 | Network optimization for secure connection establishment or secure messaging |
US15/049,407 US10142305B2 (en) | 2011-06-30 | 2016-02-22 | Local security key generation |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/174,644 US9270453B2 (en) | 2011-06-30 | 2011-06-30 | Local security key generation |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/412,141 Continuation-In-Part US9154527B2 (en) | 2011-06-30 | 2012-03-05 | Security key creation |
US15/049,407 Continuation US10142305B2 (en) | 2011-06-30 | 2016-02-22 | Local security key generation |
Publications (2)
Publication Number | Publication Date |
---|---|
US20130007434A1 true US20130007434A1 (en) | 2013-01-03 |
US9270453B2 US9270453B2 (en) | 2016-02-23 |
Family
ID=47391892
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/174,644 Active 2033-12-03 US9270453B2 (en) | 2011-06-30 | 2011-06-30 | Local security key generation |
US15/049,407 Active 2032-03-25 US10142305B2 (en) | 2011-06-30 | 2016-02-22 | Local security key generation |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/049,407 Active 2032-03-25 US10142305B2 (en) | 2011-06-30 | 2016-02-22 | Local security key generation |
Country Status (1)
Country | Link |
---|---|
US (2) | US9270453B2 (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150113602A1 (en) * | 2012-05-08 | 2015-04-23 | Serentic Ltd. | Method and system for authentication of communication and operation |
WO2016056986A1 (en) * | 2014-10-09 | 2016-04-14 | Kelisec Ab | Improved installation of a terminal in a secure system |
US10079814B2 (en) | 2014-09-23 | 2018-09-18 | Kelisec Ab | Secure node-to-multinode communication |
US10116448B2 (en) | 2013-03-22 | 2018-10-30 | Meontrust Inc | Transaction authorization method and system |
US10356090B2 (en) | 2014-10-09 | 2019-07-16 | Kelisec Ab | Method and system for establishing a secure communication channel |
US10356062B2 (en) * | 2012-03-27 | 2019-07-16 | Amazon Technologies, Inc. | Data access control utilizing key restriction |
US10374800B1 (en) | 2014-09-10 | 2019-08-06 | Amazon Technologies, Inc. | Cryptography algorithm hopping |
CN110225517A (en) * | 2018-04-08 | 2019-09-10 | 华为技术有限公司 | A kind of method for sending information, key generation method and device |
US10425223B2 (en) | 2012-03-27 | 2019-09-24 | Amazon Technologies, Inc. | Multiple authority key derivation |
US10511596B2 (en) | 2014-10-09 | 2019-12-17 | Kelisec Ab | Mutual authentication |
US10523707B2 (en) | 2014-09-10 | 2019-12-31 | Amazon Technologies, Inc. | Secure transport channel using multiple cipher suites |
US10567434B1 (en) * | 2014-09-10 | 2020-02-18 | Amazon Technologies, Inc. | Communication channel security enhancements |
US10733309B2 (en) | 2014-10-09 | 2020-08-04 | Kelisec Ab | Security through authentication tokens |
US20230254342A1 (en) * | 2022-02-09 | 2023-08-10 | Nbcuniversal Media, Llc | Cryptographic binding of data to network transport |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10951564B1 (en) | 2020-04-17 | 2021-03-16 | Slack Technologies, Inc. | Direct messaging instance generation |
US11784949B2 (en) | 2020-10-06 | 2023-10-10 | Salesforce, Inc. | Limited functionality interface for communication platform |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030177401A1 (en) * | 2002-03-14 | 2003-09-18 | International Business Machines Corporation | System and method for using a unique identifier for encryption key derivation |
US20060205387A1 (en) * | 2005-03-09 | 2006-09-14 | Nokia Corporation | User authentication in a communications system |
US20080133761A1 (en) * | 2006-12-01 | 2008-06-05 | Cisco Technology, Inc. | Establishing secure communication sessions in a communication network |
US20090067628A1 (en) * | 2005-04-26 | 2009-03-12 | Vodafone Group Plc | Telecommunications networks |
US20100054472A1 (en) * | 2008-08-27 | 2010-03-04 | Qualcomm Incorporated | Integrity protection and/or ciphering for ue registration with a wireless network |
US20110091036A1 (en) * | 2008-06-06 | 2011-04-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Cryptographic Key Generation |
US20110206206A1 (en) * | 2008-09-16 | 2011-08-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Key Management in a Communication Network |
Family Cites Families (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09153099A (en) | 1995-09-29 | 1997-06-10 | Toshiba Corp | Method and system for transferring information, and method and device for information input |
US6502614B1 (en) | 1999-05-25 | 2003-01-07 | Silverbrook Research Pty Ltd | Printed media transverse binder |
US7299357B2 (en) | 2002-08-07 | 2007-11-20 | Kryptiq Corporation | Opaque message archives |
US7386878B2 (en) | 2002-08-14 | 2008-06-10 | Microsoft Corporation | Authenticating peer-to-peer connections |
US7269731B2 (en) | 2003-01-29 | 2007-09-11 | Hewlett-Packard Development Company, L.P. | Message authorization system and method |
US7136651B2 (en) | 2004-08-30 | 2006-11-14 | Tatara Systems, Inc. | Mobile services control platform providing a converged voice service |
BRPI0517521B1 (en) | 2004-10-26 | 2019-04-09 | Telecom Italia S.P.A. | METHOD AND SYSTEM FOR AUTHENTICING A FIRST NETWORK SUBSCRIBER TO ACCESS AN APPLICATION SERVICE THROUGH A SECOND NETWORK |
CN100574185C (en) * | 2005-01-07 | 2009-12-23 | 华为技术有限公司 | The method that in the IP multimedia service subsystem network, ensures media stream safety |
US8353011B2 (en) | 2005-06-13 | 2013-01-08 | Nokia Corporation | Apparatus, method and computer program product providing mobile node identities in conjunction with authentication preferences in generic bootstrapping architecture (GBA) |
US20090063851A1 (en) | 2006-03-20 | 2009-03-05 | Nijdam Mark J | Establishing communications |
JP4860756B2 (en) | 2006-12-08 | 2012-01-25 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | User device, control method thereof, and IMS user apparatus |
CN101207613B (en) | 2006-12-21 | 2012-01-04 | 松下电器产业株式会社 | Method, system and apparatus for authentication of striding network area information communication |
GB2441399B (en) | 2007-04-03 | 2009-02-18 | Cvon Innovations Ltd | Network invitation arrangement and method |
US7957533B2 (en) | 2007-10-02 | 2011-06-07 | Alcatel-Lucent Usa Inc. | Method of establishing authentication keys and secure wireless communication |
US8230035B2 (en) | 2007-10-04 | 2012-07-24 | Alcatel Lucent | Method for authenticating mobile units attached to a femtocell that operates according to code division multiple access |
ES2589112T3 (en) | 2007-11-30 | 2016-11-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Key management for secure communication |
KR100958110B1 (en) | 2007-12-17 | 2010-05-17 | 한국전자통신연구원 | Apparatus of authentication gateway for accessing ubiquitous service and method thereof |
CN101822035B (en) | 2007-12-27 | 2013-01-30 | 株式会社Ntt都科摩 | Server device and message transmission method |
US20090180614A1 (en) | 2008-01-10 | 2009-07-16 | General Instrument Corporation | Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network |
EP2283430B1 (en) | 2008-05-23 | 2018-08-01 | Telefonaktiebolaget LM Ericsson (publ) | Ims user equipment, control method thereof, host device, and control method thereof |
CN101621772B (en) | 2008-07-02 | 2012-06-06 | 中国移动通信集团公司 | Session control method and equipment |
EP2415231B1 (en) | 2009-04-01 | 2016-05-18 | Telefonaktiebolaget LM Ericsson (publ) | Security key management in ims-based multimedia broadcast and multicast services (mbms) |
US8301883B2 (en) | 2009-08-28 | 2012-10-30 | Alcatel Lucent | Secure key management in conferencing system |
US8296836B2 (en) | 2010-01-06 | 2012-10-23 | Alcatel Lucent | Secure multi-user identity module key exchange |
CN102948185A (en) | 2010-06-21 | 2013-02-27 | 诺基亚西门子通信公司 | Method for establishing a secure and authorized connection between a smart card and a device in a network |
US20120109830A1 (en) | 2010-10-29 | 2012-05-03 | Matt Vogel | Apparatus, system and method for a decentralized social network system and decentralized payment network system |
WO2012077999A2 (en) | 2010-12-08 | 2012-06-14 | Lg Electronics Inc. | Traffic encryption key management for machine to machine multicast group |
KR20120091635A (en) | 2011-02-09 | 2012-08-20 | 삼성전자주식회사 | Authentication method and apparatus in wireless communication system |
US9350769B2 (en) * | 2011-03-10 | 2016-05-24 | Genband Us Llc | SIP device-level call/session/service management |
US8958559B2 (en) | 2011-06-03 | 2015-02-17 | Apple Inc. | System and method for secure instant messaging |
US8619986B2 (en) | 2011-07-21 | 2013-12-31 | Patton Protection Systems LLC | Systems and methods for secure communication using a communication encryption bios based upon a message specific identifier |
US20130060708A1 (en) | 2011-09-06 | 2013-03-07 | Rawllin International Inc. | User verification for electronic money transfers |
US9037511B2 (en) | 2011-09-29 | 2015-05-19 | Amazon Technologies, Inc. | Implementation of secure communications in a support system |
-
2011
- 2011-06-30 US US13/174,644 patent/US9270453B2/en active Active
-
2016
- 2016-02-22 US US15/049,407 patent/US10142305B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030177401A1 (en) * | 2002-03-14 | 2003-09-18 | International Business Machines Corporation | System and method for using a unique identifier for encryption key derivation |
US20060205387A1 (en) * | 2005-03-09 | 2006-09-14 | Nokia Corporation | User authentication in a communications system |
US20090067628A1 (en) * | 2005-04-26 | 2009-03-12 | Vodafone Group Plc | Telecommunications networks |
US20080133761A1 (en) * | 2006-12-01 | 2008-06-05 | Cisco Technology, Inc. | Establishing secure communication sessions in a communication network |
US20110091036A1 (en) * | 2008-06-06 | 2011-04-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Cryptographic Key Generation |
US20100054472A1 (en) * | 2008-08-27 | 2010-03-04 | Qualcomm Incorporated | Integrity protection and/or ciphering for ue registration with a wireless network |
US20110206206A1 (en) * | 2008-09-16 | 2011-08-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Key Management in a Communication Network |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10425223B2 (en) | 2012-03-27 | 2019-09-24 | Amazon Technologies, Inc. | Multiple authority key derivation |
US11146541B2 (en) | 2012-03-27 | 2021-10-12 | Amazon Technologies, Inc. | Hierarchical data access techniques using derived cryptographic material |
US10356062B2 (en) * | 2012-03-27 | 2019-07-16 | Amazon Technologies, Inc. | Data access control utilizing key restriction |
US20150113602A1 (en) * | 2012-05-08 | 2015-04-23 | Serentic Ltd. | Method and system for authentication of communication and operation |
US10116448B2 (en) | 2013-03-22 | 2018-10-30 | Meontrust Inc | Transaction authorization method and system |
US10567434B1 (en) * | 2014-09-10 | 2020-02-18 | Amazon Technologies, Inc. | Communication channel security enhancements |
US10374800B1 (en) | 2014-09-10 | 2019-08-06 | Amazon Technologies, Inc. | Cryptography algorithm hopping |
US10523707B2 (en) | 2014-09-10 | 2019-12-31 | Amazon Technologies, Inc. | Secure transport channel using multiple cipher suites |
US10079814B2 (en) | 2014-09-23 | 2018-09-18 | Kelisec Ab | Secure node-to-multinode communication |
US10291596B2 (en) | 2014-10-09 | 2019-05-14 | Kelisec Ab | Installation of a terminal in a secure system |
US10511596B2 (en) | 2014-10-09 | 2019-12-17 | Kelisec Ab | Mutual authentication |
US10356090B2 (en) | 2014-10-09 | 2019-07-16 | Kelisec Ab | Method and system for establishing a secure communication channel |
US10693848B2 (en) | 2014-10-09 | 2020-06-23 | Kelisec Ab | Installation of a terminal in a secure system |
US10733309B2 (en) | 2014-10-09 | 2020-08-04 | Kelisec Ab | Security through authentication tokens |
WO2016056986A1 (en) * | 2014-10-09 | 2016-04-14 | Kelisec Ab | Improved installation of a terminal in a secure system |
WO2019196668A1 (en) * | 2018-04-08 | 2019-10-17 | 华为技术有限公司 | Information sending method, key generating method, and device |
CN110225517A (en) * | 2018-04-08 | 2019-09-10 | 华为技术有限公司 | A kind of method for sending information, key generation method and device |
US20230254342A1 (en) * | 2022-02-09 | 2023-08-10 | Nbcuniversal Media, Llc | Cryptographic binding of data to network transport |
Also Published As
Publication number | Publication date |
---|---|
US20160173463A1 (en) | 2016-06-16 |
US9270453B2 (en) | 2016-02-23 |
US10142305B2 (en) | 2018-11-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10142305B2 (en) | Local security key generation | |
US9871656B2 (en) | Encrypted communication method and apparatus | |
US8705743B2 (en) | Communication security | |
CN100571134C (en) | The method of authenticated user terminal in IP Multimedia System | |
KR101516909B1 (en) | Discovery of security associations for key management relying on public keys | |
US20150089220A1 (en) | Technique For Bypassing an IP PBX | |
CN104683304B (en) | A kind of processing method of secure traffic, equipment and system | |
WO2007104909A1 (en) | Sim based authentication | |
WO2007062689A1 (en) | Method and apparatus for distributing keying information | |
CN101635823A (en) | Method and system of terminal for encrypting videoconference data | |
CN104683291B (en) | Session key negotiation method based on IMS system | |
CN104683098B (en) | A kind of implementation method of secure traffic, equipment and system | |
US20080307518A1 (en) | Security in communication networks | |
CN108833943B (en) | Code stream encryption negotiation method and device and conference terminal | |
US20030097584A1 (en) | SIP-level confidentiality protection | |
US10893414B1 (en) | Selective attestation of wireless communications | |
US20150350899A1 (en) | AUTHENTICATION METHOD OF VoLTE | |
CN100544247C (en) | The negotiating safety capability method | |
WO2017197968A1 (en) | Data transmission method and device | |
US10848471B2 (en) | Communication apparatus, communication method, and program | |
Chen et al. | An efficient end-to-end security mechanism for IP multimedia subsystem | |
CN105827661B (en) | Method and device for secure communication | |
CN101854630A (en) | Method, system and user equipment for realizing card authentication | |
CN107801186B (en) | Non-access stratum abstract authentication method in trunking communication system | |
Chang et al. | Design and implementation of SIP security |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KING, WILLIAM C;LAU, PRISCILLA;LEE, KWAI YEUNG;REEL/FRAME:026533/0288 Effective date: 20110630 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |