U.S. patent application number 13/174644 was filed with the patent office on 2013-01-03 for local security key generation.
This patent application is currently assigned to VERIZON PATENT AND LICENSING INC.. Invention is credited to William C. KING, Priscilla Lau, Kwai Yeung Lee.
Application Number | 20130007434 13/174644 |
Document ID | / |
Family ID | 47391892 |
Filed Date | 2013-01-03 |
United States Patent
Application |
20130007434 |
Kind Code |
A1 |
KING; William C. ; et
al. |
January 3, 2013 |
LOCAL SECURITY KEY GENERATION
Abstract
A calling device may obtain a first calling security parameter
by registering with a network and obtain a second calling security
parameter in response to causing an application authentication
architecture of the network to verify that that the calling device
is authorized to access a network service corresponding to a
communication application stored by the calling device. The calling
device may communicate the first and second calling security
parameters to a called device and receive first and second called
security parameters from the called device in response to
communicating the first and second calling security parameters. The
calling device may generate a security key based on the first
calling security parameter, the second calling security parameter,
first called security parameter, and the second called security
parameter, and use the security key to encrypt or decrypt
communication between the calling device and the called device.
Inventors: |
KING; William C.;
(Lafayette, CA) ; Lau; Priscilla; (Fremont,
CA) ; Lee; Kwai Yeung; (Pittsburg, CA) |
Assignee: |
VERIZON PATENT AND LICENSING
INC.
Basking Ridge
NJ
|
Family ID: |
47391892 |
Appl. No.: |
13/174644 |
Filed: |
June 30, 2011 |
Current U.S.
Class: |
713/2 ; 713/169;
713/171 |
Current CPC
Class: |
H04L 9/0866 20130101;
H04L 63/062 20130101; H04L 63/08 20130101 |
Class at
Publication: |
713/2 ; 713/171;
713/169 |
International
Class: |
H04L 9/32 20060101
H04L009/32; G06F 9/00 20060101 G06F009/00 |
Claims
1. A method, comprising: obtaining, by a calling device, a first
calling security parameter by registering with a network;
obtaining, by the calling device, a second calling security
parameter in response to causing an application authentication
architecture of the network to verify that that the calling device
is authorized to access a network service corresponding to a
communication application stored by the calling device;
communicating the first calling security parameter and the second
calling security parameter to a called device; receiving a first
called security parameter and a second called security parameter
from the called device in response to communicating the first
calling security parameter and the second calling security
parameter; generating a security key based on the first calling
security parameter, the second calling security parameter, first
called security parameter, and the second called security
parameter; and using the security key to encrypt or decrypt
communication between the calling device and the called device.
2. The method of claim 1, further comprising: establishing a
communication session with the called device; and using the
security key to encrypt information communicated to the called
device and decrypt information received from the called device
during the communication session.
3. The method of claim 1, further comprising: obtaining a third
calling security parameter comprising a data structure used to
demonstrate to the application authentication architecture that the
calling device is authorized to use the communication application
to establish a communication session within the network; and
communicating the third calling security parameter to the called
device with the first calling security parameter and the second
calling security parameter.
4. The method of claim 3, further comprising: receiving a third
called security parameter, from the called device, with the first
called security parameter and the second called security parameter,
where the third called security parameter comprises a data
structure used to demonstrate to the application authentication
architecture that the called device is authorized to use a
communication application that corresponds to the communication
application of the calling device.
5. The method of claim 1, where the first calling security
parameter comprises a data structure identifying a network session
associated with the calling device upon registering with the
network.
6. The method of claim 1, where: the first called security
parameter comprises a data structure identifying a network session
associated with the called device upon registering with the
network, and the second called security parameter comprises a
security parameter type and security parameter format consistent
with the second calling security parameter.
7. The method of claim 1, where communicating the first calling
security parameter and the second calling security parameter
comprises sending a session communication invitation, comprising
the first and second calling security parameters, to the called
device.
8. The method of claim 1, where generating the security key
comprises executing a key generation function, where: an input of
the key generation function comprises the first calling security
parameter, the second calling security parameter, first called
security parameter, and the second called security parameter, and
an output of the key generation function is the security key.
9. The method of claim 8, where the key generation function
comprises a key derivation function (KDF) that is identical to a
KDF used by the called device to generate security keys.
10. The method of claim 1, where: the network comprises an Internet
Protocol (IP) multimedia subsystem (IMS) network, the application
authentication architecture comprises a generic bootstrap
architecture (GBA) of the IMS network, and the second calling
security parameter comprises a bootstrap transaction identifier
(B-TID).
11. A first device, comprising: a memory to: store a communication
application to enable the first device to establish a first
communication session with a second device using a selected network
service, and store a first key generation function to enable the
first device to generate a security key; and a processor, connected
to the memory, to: register the first device with a network, where
registering with the network comprises receiving a first network
session identifier from the network, communicate with an
application authentication architecture of the network to
demonstrate that the first device is authorized to use the selected
network service, where communicating with the application
authentication architecture comprises receiving a first transaction
identifier from the application authentication architecture,
communicate the first network session identifier and the first
transaction identifier to the second device, receive a second
network session identifier and a second transaction identifier from
the second device, and execute the first key generation function to
generate a security key based on the first network session
identifier, the first transaction identifier, the second network
session identifier, and the second transaction identifier.
12. The first device of claim 11, where the first device obtains
access to at least one network service, other than the selected
network service, upon registering with the network.
13. The first device of claim 11, where the processor is to:
establish a communication session, with the second device, using
the selected network service, and use the security key to encrypt
information sent to the second device via the selected network
service and decrypt information received from the second device via
the network service.
14. The first device of claim 11, where the processor is to: obtain
a first data structure used to demonstrate to the application
authentication architecture of the network that the calling device
is authorized to use the communication application to establish a
communication session within the network, and communicate the first
data structure, to the called device, with first network session
identifier and the first transaction identifier.
15. The first device of claim 14, where the first transaction
identifier comprises a data structure that associates the first
device with a first authentication process, performed by the
application authentication architecture, to verify that the first
device is authorized to use the communication application.
16. The first device of claim 14, where the processor is to:
receive a second data structure, from the called device, with the
second network session identifier and the second transaction
identifier, where the second data structure comprises information
used to demonstrate to the application authentication architecture
that the second device is authorized to use a communication
application that corresponds to the communication application
stored by the first device.
17. The first device of claim 11, where the second transaction
identifier comprises a data structure that associates the second
device with a second authentication process, performed by the
application authentication architecture, to verify that the second
device is authorized to use a communication application that
corresponds to the communication application stored by the first
device.
18. The first device of claim 11, where, to communicate the first
network session identifier and the first transaction identifier to
the second device, the processor is to: generate a communication
session invitation directed to the second device, include the first
network session identifier and the first transaction identifier in
the communication session invitation, and send the communication
session invitation to the second device.
19. The first device of claim 11, where: the network comprises an
Internet Protocol (IP) multimedia subsystem (IMS) network, and the
application authentication architecture comprises a generic
bootstrap architecture (GBA) of the IMS network.
20. A non-transitory computer-readable medium storing a program for
causing a first device to perform a method, the method comprising:
obtaining a first security parameter by communicating with a
generic bootstrapping architecture (GBA) to demonstrate that the
calling device is authorized to use a selected network
communication service for establishing a communication session
within a network, where the first security parameter is generated
by the GBA to associate the first device with a first GBA
authentication process; obtaining a second security parameter from
a second device in response to communicating the first security
parameter to the second device, where the second security parameter
is obtained by the second device by communicating with the GBA to
demonstrate that the second device is authorized to use the
selected network communication service, where the second security
parameter is generated by the GBA to associate the second device
with a second GBA authentication process; generating a security key
based on the first security parameter and the second security
parameter; and using the security key to establish an encrypted
communication session, using the selected network communication
service, with the second device.
21. The computer-readable medium of claim 20, where the method
further comprises: obtaining a third security parameter by
registering with the network, where: registering with the network
enables the first device to communicate with the GBA, and the third
security parameter is generated by a network registration
architecture of the network to identify a network session
associated with the first device; and generating the security key
based on the first security parameter, the second security
parameter, and the third security parameter.
22. The computer-readable medium of claim 20, where: the network
comprises an Internet Protocol (IP) multimedia subsystem (IMS)
network, and the network communication service corresponds to voice
over IP (VoIP) communication service.
Description
BACKGROUND
[0001] Current network communication technologies include various
approaches to network security. For example, in many networks, user
devices are assigned security keys (also referred to as cipher
keys) for encrypting and decrypting messages communicated over the
network. However, such technologies often include various
deficiencies. For instance, assigning security keys to user devices
often involves a third device (e.g., a key management system) to
assign the security keys, which can introduce security risks and
increase operational complexity within the network.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] FIG. 1 is a diagram of an example overview of an
implementation described herein;
[0003] FIG. 2 is a diagram of an example environment in which
systems and/or methods, described herein, may be implemented;
[0004] FIG. 3 is a diagram of example components of a device
according to one or more implementations described herein;
[0005] FIG. 4 is a diagram of example functional components
corresponding to one or more implementations described herein;
[0006] FIG. 5 is a diagram of an example data flow according to one
or more implementations described herein;
[0007] FIG. 6 is a diagram of an example process for generating a
security key according to one or more implementations described
herein;
[0008] FIG. 7 is a diagram of another example process for
generating a security key according to one or more implementations
described herein; and
[0009] FIGS. 8A-8C are diagrams of an example call session
according to one or more implementations described herein.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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. For
example, calling device 110 and called device 120 may each be a
smart phone. However, in another example, calling device 110 may
include a tablet computer, and called device 120 may include a
network application server. In yet another example, calling device
110 and called device 120 may each be application servers.
[0014] 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. However, in some implementations,
called device 120 may also be capable of sending a communication
session invitation, and calling device 110 may be capable of
receiving the communication session invitation. In certain
implementations, therefore, a particular device (e.g., a smart
phone) may operate as calling device 110 in one scenario and called
device 120 in another scenario.
[0015] As depicted, 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. 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 calling
device 110 or called device 120 are authorized to use the
communication applications and/or corresponding network
service.
[0016] Additionally, or alternatively, 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. In certain implementations, 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.
[0017] 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 registering
calling device 110 or called device 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 in FIG. 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.
[0018] 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 calling device 110 and called
device 120 to communicate with one another via a particular network
service and/or a particular communication application.
[0019] 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.
[0020] As depicted, calling device 110 or called device 120 may
receive one or more security parameters from network registration
architecture 130. In some implementations, 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. Additionally, or alternatively, calling device 110 or called
device 120 may receive one or more security parameters from
application authentication architecture 140. In some
implementations, 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.
[0021] 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. Similarly, 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).
[0022] FIG. 2 is a diagram of an example environment 200 in which
systems and/or methods, described herein, may be implemented. As
depicted, environment 200 may include calling device 110, called
device 120, network registration architecture 130, application
authentication architecture 140, and network 210. While 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.
[0023] Calling device 110, called device 120, network registration
architecture 130, and application authentication architecture 140
are each described above with reference to FIG. 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)).
[0024] For example, in some implementations, network 210 may
include one or more LTE access networks connected to an IMS
network. In such implementations, 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.).
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.
[0025] 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. As
depicted, device 300 may include bus 310, processor 320, memory
330, input device 340, output device 350, and communication
interface 360. However, in other implementations, device 300 may
include fewer components, additional components, different
components, or differently arranged components than those
illustrated in FIG. 3.
[0026] 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).
[0027] 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.
[0028] Input device 340 may include one or more components that
permit a user to input information into device 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 permit device 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.
[0029] Communication interface 360 may include one or more
components that permit device 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.
[0030] As described herein, 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. 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.
[0031] FIG. 4 is a diagram of example functional components 400
corresponding to one or more implementations described herein. For
example, calling device 110 or called device 120 may include
functional components 400. As depicted, functional components 400
may include registration module 410, communication application
module 420, security parameters module 430, and key 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 to FIG. 3. Alternatively, modules 410-440 may each be
implemented as hardware based on the components illustrated and
described with respect to FIG. 3. While 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.
[0032] Registration module 410 may provide calling device 110 or
called device 120 with functionality regarding network
registration. For example, 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. 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.
[0033] In some implementations, by registering with network 210,
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.). 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 require application authentication architecture 140 to perform
one or more application authentication procedures as described
herein.
[0034] Communication application module 420 may provide calling
device 110 or called device 120 with functionality regarding
communication applications. For instance, 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. In implementations where a communication application requires
authentication, communication application module 420 may
communicate with application authentication architecture 140 to
complete the authentication process.
[0035] 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. 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 calling device 110 or
called device 120 may, for example, use a stored communication
application to gain access to a particular network service.
[0036] 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. 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).
[0037] 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.
Alternatively, 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. In some implementations, 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.). Similarly, 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.).
[0038] 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.
[0039] 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.
[0040] As depicted, security parameters may be obtained by calling
device 110 from different sources and at different times. For
example, 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. Additionally,
or alternatively, 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.
[0041] 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. 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.).
[0042] 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 calling device 110. As described below with
reference to FIGS. 7-8C, an analogous data flow could be applied to
called device 120.
[0043] 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. In one or more implementations, process 600
may be performed by one or more components of calling device 110.
In other implementations, 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.
[0044] Process 600 may include registering with network 210 (block
610). For example, calling device 110 may communicate with network
registration architecture 130 to register with network 210. In some
implementations, 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. As
mentioned above, however, 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.
[0045] 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.
[0046] Calling security parameters may be communicated (block 630).
For example, calling device 110 may send parameters to called
device 120. In certain implementations, calling device 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).
[0047] Called security parameters may be received (block 640). For
example, calling device 110 may receive called security parameters
from called device 120. As discussed above with reference to FIG.
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
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.
[0048] 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.
[0049] While FIG. 6 shows a flowchart diagram of an example 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 in FIG. 6.
[0050] FIG. 7 is a diagram of an example 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 of FIG. 6. However,
while the process of FIG. 6 may be performed by calling device 110,
process 700 may be performed by called device 120. For instance, in
one or more implementations, process 700 may be performed by one or
more components of called device 120. In other implementations, 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.
[0051] Process 700 may include registering with network 210 (block
710). For example, called device 120 may register with network 210.
In some implementations, called device 120 may register with
network 210 by communicating with network registration architecture
130. In certain implementations, 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. However, some network services may require called
device 120, or a communication application of called device 120, to
be authenticated by application authentication architecture
140.
[0052] Calling security parameters may be received (block 720). For
instance, 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). 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 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.
[0053] 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,
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.
[0054] Called security parameters may be communicated (block 740).
For instance, called device 120 may send, or otherwise communicate,
called security parameters to calling device 110. In some
implementations, 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. In such
implementations, 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.
[0055] 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.
[0056] While FIG. 7 shows a flowchart diagram of an example 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 in FIG. 7.
[0057] 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 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. 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 in FIGS.
8A-8C.
[0058] Referring to FIG. 8A, call session 800A 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). In some implementations, 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. Additionally, or
alternatively, calling device 110 may register with network 210
before triggering the GBA (see, for example, FIG. 6, blocks 610 and
620).
[0059] 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 called device 120 via gateway 810-2 (event 10).
[0060] Similar to calling device 110, 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). As depicted,
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.
[0061] At this point, calling device 110 and calling device 120 may
each derive or otherwise calculate a security key using, for
example, a KDF. As depicted, 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).
[0062] 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).
[0063] Referring to FIG. 8B, 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).
[0064] 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.
[0065] 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.
[0066] 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 called device 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 calling device 110 to called device 120
via a sequence of transmissions (events 51-60) that is similar to
the communications described above.
[0067] Referring to FIG. 8C, 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). As the SIP BYE message is
being transmitted to called device 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, 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).
[0068] 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 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
* * * * *