Security key creation

A device may obtain calling security parameters, may communicate the calling security parameters to a network device, and may receive, from the network device, a calling parameters identifier associated with the calling security parameters. The device may communicate the calling parameters identifier to a called device, may receive a called parameters identifier from the called device, and may communicate the called parameters identifier to the network device. The device may receive called security parameters from the network device, may create a security key based on the calling security parameters and the called security parameters, and may communicate with the called device using the security key.

BACKGROUND

Currently available network technologies include various solutions for attempting to ensure that communications between devices within a network are secure. For instance, some solutions include the use of security keys to encrypt and decrypt information that is communicated between devices. However, currently available network technologies are inadequate. For example, current solutions for generating security keys involve risky procedures, such as passing security keys between devices, require a prohibitive quantity of network resources, etc.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

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

A system and/or method, described herein, may provide solutions to creating security keys. For example, client devices, such as mobile telephones, may each generate a security key based on parameters from a variety sources. Examples of such parameters may include information that results from an authentication process (e.g., a bootstrapping authentication process), information that is generated locally by each client device, information that is received from a network application server, etc. As such, the client devices may each create an identical security key for encryption and/or decryption purposes without ever having to communicate, to one another, the encryption key, a portion of the encryption key, and/or the set of parameters upon which the encryption key is based.

Accordingly, the system and/or method, described herein, may be used to enhance network performance by distributing the responsibility of creating security keys among client devices (as opposed to, for example, a centralized server). Additionally, or alternatively, since the security keys may be created by each client device locally, the system and/or method may enhance security by eliminating the transfer of security keys between client devices. Further, the system and/or method may also, or alternatively, enhance security by even eliminating the transfer of security key parameters between client devices.

FIG. 1is a diagram of an example environment100in which systems and/or methods, described herein, may be implemented. As shown inFIG. 1, environment100may include client devices110-1, . . . ,110-N (where N≧1) (hereinafter referred to collectively as “client devices110,” and, in some instances, individually as “client device110”), a group of base stations120-1, . . . ,120-M (where M≧1) (hereinafter referred to collectively as “base stations120,” and, in some instances, individually as “base station120”), a serving gateway130(hereinafter referred to as a “SGW130”), a mobility management entity device140(hereinafter referred to as a “MME140”), a packet data network (PDN) gateway150(hereinafter referred to as a “PGW150”), a home subscriber server (HSS)/authentication, authorization, accounting (AAA) server160(hereinafter referred to as a “HSS/AAA server160”), a call session control function (CSCF) server170(hereinafter referred to as a “CSCF server170”), a network180, a bootstrap system190, and an application system195.

Also, in some implementations, one or more of the devices or systems of environment100may perform one or more functions described as being performed by another one or more of the devices or systems of environment100. Devices or systems of environment100may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Further, one or more implementations are described as being performed within a radio access network (RAN) that is based on a long term evolution (LTE) network for explanatory purposes. In other implementations, the implementations may be performed within a RAN that is not based on a LTE network.

Environment100may include an evolved packet system (EPS) that includes a LTE network and/or an evolved packet core (EPC) network that operate based on a third generation partnership project (3GPP) wireless communication standard. The LTE network may be a RAN that includes one or more base stations120that take the form of evolved Node Bs (eNBs) via which client device110communicates with the EPC network. The EPC network may include SGW130, MME140, and/or PGW150that enable client device110to communicate with network180and/or an Internet protocol (IP) multimedia subsystem (IMS) core network. The IMS core network may include HSS/AAA server160and/or CSCF server170and may manage authentication, session initiation, account information, profile information, etc. associated with client devices110.

Client device110may include any computing device, such as a wireless mobile computation and communication device that is capable of communicating with base station220and/or a network (e.g., network180). For example, client device110may include a radiotelephone, a personal communications system (PCS) terminal (e.g., that may combine a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (PDA) (e.g., that can include a radiotelephone, a pager, Internet/intranet access, etc.), a smart phone, a laptop computer, a tablet computer, a camera, a personal gaming system, or another type of mobile computation and communication device. Client device110may send traffic to and/or receive traffic from network180.

Base station120may include one or more devices that receive, process, and/or transmit traffic, such as audio, video, text, and/or other data, destined for and/or received from client device110. In an example implementation, base station120may be an eNB associated with the LTE network that receives traffic from and/or sends traffic to network180via SGW130and PGW150. Base station120may send traffic to and/or receive traffic from client device110via an air interface. Alternatively, or additionally, one or more other base stations120may be associated with a RAN that is not associated with the LTE network.

SGW130may include one or more computation and communication devices that gather, process, search, store, and/or provide information in a manner described herein. For example, SGW130may include one or more data processing and/or traffic transfer devices, such as a gateway, a router, a modem, a switch, a firewall, a network interface card (NIC), a hub, a bridge, a proxy server, an optical add-drop multiplexer (OADM), or some other type of device that processes and/or transfers traffic. In one example implementation, SGW130may aggregate traffic received from one or more base stations120associated with the LTE network, and may send the aggregated traffic to network180(e.g., via PGW150) and/or other network devices associated with the IMS core network and/or the EPC network. SGW130may also receive traffic from the other network devices and/or may send the received traffic to client device110via base station120. SGW130may perform operations associated with handing off client device110from and/or to the LTE network.

MME140may include one or more devices that gather, process, search, store, and/or provide information in a manner described herein. For example, MME140may perform operations associated with handing off client device110, from a first base station120to a second base station120, when client device110is exiting a cell associated with the first base station120. Alternatively, or additionally, MME140may perform an operation to handoff client device110from the second base station120to the first base station120when client device110is entering the cell associated with first base station120.

PGW150may include one or more devices that gather, process, search, store, and/or provide information in a manner described herein. For example, PGW150may include one or more data processing and/or traffic transfer devices, such as a gateway, a router, a modem, a switch, a firewall, a NIC, a hub, a bridge, a proxy server, an OADM, or some other type of device that processes and/or transfers traffic. In one example implementation, PGW150may include a device that aggregates traffic received from one or more SGWs130, etc. and may send the aggregated traffic to network180. Alternatively, or additionally, PGW150may receive traffic from network180and may send the traffic toward client device110via SGW130.

HSS/AAA server160may include one or more server devices, or other types of computation and communication devices, that gather, process, search, store, and/or provide information in a manner described herein. For example, HSS/AAA server160may manage, update, and/or store, in a memory associated with HSS/AAA server160, profile information associated with client device110that identifies applications and/or services that are permitted for and/or accessible by client device110, information associated with a user of client device110(e.g., a username, a password, a personal identification number (PIN), etc.), rate information, minutes allowed, and/or other information. Additionally, or alternatively, HSS/AAA server160may include a device that performs AAA operations associated with a communication session with client device110.

CSCF server170may include one or more server devices, or other types of computation and communication devices, that gather, process, search, store, and/or provide information in a manner described herein. CSCF server170may process and/or route calls to and from client device110via the EPC network. For example, CSCF server170may process calls, received from network180, that are destined for client device110. Alternatively, or additionally, CSCF server170may process calls, received from client device110, that are destined for network180.

Network180may include one or more wired and/or wireless networks. For example, network180may include a cellular network, a public land mobile network (PLMN), a second generation (2G) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5G) network, and/or another network. Additionally, or alternatively, network180may include a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), an ad hoc network, an intranet, the Internet, a fiber optic-based network, a backhaul and/or management network, a voice over IP (VoIP) network, and/or a combination of these or other types of networks.

Bootstrap system190may include one or more types of computing devices. For example, bootstrap system190may include a server, a cluster of servers, or one or more other types of computing devices. Bootstrap system190may be capable of functioning in accordance with any of the implementations described herein. For instance, bootstrap system190may include a network server capable of providing one or more types of authentication services. In one example, bootstrap system190may include a bootstrapping server function (BSF) that provides application-specific, authentication services for communications between client device110and application system195. Depending on the implementation, bootstrap system190may include, or be part of, any type of generic bootstrapping architecture (GBA) and/or any type of generic authentication architecture (GAA).

Application system195may include one or more types of computing devices. For example, application system195may include a server, a cluster of servers, or one or more other types of computing devices. Application system195may be capable of functioning in accordance with any of the implementations described herein. For instance, application system195may include a network application function (NAF) server that provides or enables a network service. In one example, application system195may enable client devices110to download a VoIP application (or another type of communication application), and/or use the VoIP application to communicate with one another via VoIP services.

While implementations herein are described primarily in the context of broadband services via a LTE network, other wireless standards may be used. For example, components conforming to LTE standards described herein may be replaced by components conforming to other network standards, such as, for example, Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), High Speed Packet Access (HSPA), 802.11, or other network standards.

FIG. 2is a diagram of example components of device200that may be used within environment ofFIG. 1. For example, device200may correspond to client device110, base station120, SGW130, MME140, PGW150, HSS/AAA server160, CSCF server170, bootstrap system190, and/or application system195. Each of client device110, base station120, SGW130, MME140, PGW150, HSS/AAA server160, CSCF server170, bootstrap system190, and/or application system195may include one or more devices200and/or one or more of the components of device200.

As depicted, device200may include a bus210, a processor220, memory230, an input device240, an output device250, and a communication interface260. However, the precise components of device200may vary between implementations. For example, depending on the implementation, device200may include fewer components, additional components, different components, or differently arranged components than those illustrated inFIG. 2.

Bus210may permit communication among the components of device200. Processor220may 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 components that may interpret or execute instructions or data. Processor220may control the overall operation, or a portion thereof, of device200, based on, for example, an operating system (not illustrated) and/or various applications. Processor220may access instructions from memory230, from other components of device200, or from a source external to device200(e.g., a network or another device).

Memory230may include memory and/or secondary storage. For example, memory230may include random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), programmable ROM (PROM), flash memory, or some other type of memory. Memory230may 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 device240may include one or more components that permit a user to input information into device200. For example, input device240may 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 device250may include one or more components that permit device200to output information to a user. For example, output device250may include a display, light-emitting diodes (LEDs), an output port, a speaker, or some other type of output component.

Communication interface260may include one or more components that permit device200to communicate with other devices or networks. For example, communication interface260may include some type of wireless or wired interface. Communication interface230may 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, device200may perform certain operations in response to processor220executing software instructions contained in a computer-readable medium, such as memory230. The software instructions may be read into memory230from another computer-readable medium or from another device via communication interface260. The software instructions contained in memory230may cause processor220to 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. 3is a diagram of example functional components of client device110according to one or more implementations described herein. As illustrated, client device110may include a security parameters module310and a security key module320. Depending on the implementation, one or more of modules310-320may be implemented as a combination of hardware and software based on the components illustrated and described with respect toFIG. 2. Alternatively, modules310-320may each be implemented as hardware based on the components illustrated and described with respect toFIG. 2.

Security parameters module310may provide functionality with respect to security parameters. For example, security parameters module310may enable client device110to obtain security parameters from one or more of a variety of sources. For instance, security parameters module310may enable client device110to obtain security parameters from one or more authentication and/or authorization processes (involving, for example, HHS/AAA server160, bootstrap system190, network application system195, etc.), from one or more operations that are performed locally, and/or by communicating with a network device, such as application system195. Examples of security parameters may include a network application function (NAF) identifier (e.g., a NAF_ID), a bootstrapping transaction identifier (B-TID), a NAF key (e.g., an external NAF key, Ks_ext_NAF, etc.), an identifier of the device making the call (e.g., a CALLING_ID), an identifier of the device receiving the call (e.g., a CALLED_ID), etc.

Security key module320may provide functionality with respect to security keys110. For example, security key module320may enable client device110to produce, generate, or otherwise create a security key for encrypting and/or decrypting communications that involve another client device110. For instance, in one example, security key module320may create the security key based on one or more of the security parameters obtained by security parameters module310. As such, while the security key may be capable of encrypting and/or decrypting communications involving another client device110, client device110may be capable of creating the security key by using security parameters that are obtained or derived from sources other than the other client device110.

In addition to the functionality described above, functional components of client device110may also, or alternatively, provide functionality as described elsewhere in this specification. Further, whileFIG. 3shows a particular number and arrangement of modules, in alternative implementations, client device110may include additional modules, fewer modules, different modules, or differently arranged modules than those depicted. For example, client device110may include an applications module that enables client device110to download and execute software applications, including a VoIP application or another type of communications-oriented software application.

FIG. 4is diagrams illustrating an example process400for creating security keys according to one or more implementations described herein. In one example, process400may be performed by one or more components of client device110. Alternatively, or additionally, some or all of process400may be performed by one or more other components/devices, or a group of components/devices, including or excluding client device110.

The description provided below makes reference to calling device110and called device110. Each of calling device110and called device110may include examples of client device110. For instance, calling device110may include a particular client device110that is being used to call or otherwise initiate communications with another client device110. Similarly, called device110may include a particular client device110that is being called by, or is otherwise receiving communications from, calling device110.

The description provided below also makes reference calling security parameters and called security parameters. Each of the calling security parameters and the called security parameters may include one or more types of security parameters as described herein. For instance, the calling security parameters may include security parameters that are provided to application system195by calling device110. Similarly, the called security parameters may include security parameters provided to application system195by called device110.

Process400may include obtaining calling security parameters (block410). For example, calling device110may obtain calling security parameters from one or more of a variety of sources. In one example, calling device110may obtain calling security parameters from information that is stored locally by calling device110. Calling device110may also, or alternatively, obtain calling security parameters via an authentication and/or authorization process involving a network device, such as bootstrap system190, network application system195, etc. Additionally, or alternatively, calling device110may obtain calling security parameters by executing one or more operations that are based on information stored by calling device110or information received from another device (e.g., bootstrap system190, network application system195, etc.

As illustrated inFIG. 4, process400may include providing calling security parameters to a network (block420). For instance, calling device110may communicate the calling security parameters to network application system195. In some implementations, calling device110may also provide additional information to network application system195, such as a calling device identifier (e.g., a telephone number associated with calling device110, a network identifier associated with calling device110, etc.), a called device identifier (e.g., a telephone number associated with called device110, a network identifier associated with called device110, etc.), and/or a call or other type of communication session between calling device110and called device110.

Process400may also include exchanging parameter identifiers with called device (block430). For example, calling device110may receive a calling parameters identifier from network application system195. Calling device110may provide the calling parameters identifier to called device110, and called device110may respond by providing a called parameters identifier to calling device110. The calling parameters identifier may include identification information associated with the calling security parameters, the calling device identifier, the called device identifier, etc. Similarly, the called parameters identifier may include identification information corresponding to called parameters identifier or other types of information associated with called device110.

As illustrated inFIG. 4, process400may include obtaining called security parameters (block440). For instance, calling device110may communicate with network application system195to retrieve called security parameters. In some implementations, calling device110may obtain the called security parameters by communicating the called parameters identifier to network application system195.

Process400may also include creating a security key (block450). For example, calling device110may produce a security key based on one or more of the types of information generated, received, or otherwise obtained by calling device110. In some implementations, calling device110may create the security key based on some or all of the calling security parameters and the called security parameters. As mentioned above, the security key may enable calling device110to communicate with called device110in a secure manner (e.g., by enable calling device110to encrypt and decrypt communications to and from called device110). Accordingly, calling device110may be capable of creating a security key without ever having to communicate the security key, or the security parameters used to generate the security key, to called device110.

WhileFIG. 4shows a flowchart diagram of an example process400for creating a security key, in other implementations, a process for creating a security key may include fewer operations, different operations, differently arranged operations, or additional operations than depicted inFIG. 4. For example, in some implementations, a process for creating a security key may include calling device110communicating the calling parameters identifier to a network device, such as network applications system195, and the network device communicating the calling parameters identifier to called device110. Additionally, or alternatively, two or more of the operations, described above, may be implemented in parallel.

FIG. 5is diagram illustrating another example process500for creating security keys according to one or more implementations described herein. In one example, process500may be performed by one or more components of client device110. Alternatively, or additionally, some or all of process500may be performed by one or more other components/devices, or a group of components/devices, including or excluding client device110.

Each ofFIG. 4andFIG. 5includes example processes for creating a security key. Process400ofFIG. 4is described from the perspective of calling device110, and process500ofFIG. 500is described from the perspective of called device110. As such, as described below, process500may include operations that are similar to, or otherwise complementary to, one or more of the operation discussed above with reference toFIG. 4.

As illustrated inFIG. 5, process500may include receiving a calling parameters identifier (block510). For example, called device110may receive a calling parameters identifier from calling device110. In some implementations, called device110may receive the calling parameters identifier as part of an attempt from calling device110to establish a telephone call or another type of communication session with called device110. As mentioned above, the calling parameters identifier may be associated with calling security parameters that are stored by application system195.

Process500may include obtaining called security parameters (block520). For example, called device110may obtain called security parameters from one or more of a variety of sources. In some implementations, called device110may obtain called security parameters from information that is stored locally by called device110. Called device110may also, or alternatively, obtain called security parameters via an authentication and/or authorization process involving a network device, such as bootstrap system190, network application system195, etc. Additionally, or alternatively, called device110may obtain called security parameters by executing one or more operations that are based on information stored by called device110or information received from another device (e.g., bootstrap system190, network application system195, etc.).

Process500may also include providing called security parameters to a network (block530). For instance, called device110may communicate the called security parameters to network application system195. In some implementations, called device110may also provide additional information to network application system195, such as a calling device identifier, a called device identifier, or another type of information relating to calling device110, called device110, and/or a call or other type of communication session between calling device110and called device110. As described in greater detail below, doing so may enable network application system195to ensure that the called security parameters are later provided to the proper client device110(e.g., calling device110).

Process500may also include obtaining calling security parameters (block540). For instance, called device110may communicate with network application system195to retrieve calling security parameters. In some implementations, called device110may obtain the calling security parameters by communicating the calling parameters identifier to network application system195. Additionally, or alternatively, called device110may obtain the calling security parameters by communicating a called device identifier (e.g., a telephone number of called device, etc.) or another type of information that network application system195may use in one or more of a variety of ways, such as identifying the calling security parameters, verifying that called device110is, in fact, the device that calling device110intends to contact, etc.

As depicted inFIG. 5, process500may include communicating a called parameters identifier to calling device110(block550). For example, called device110may receive a calling parameters identifier from network application system195and/or may communicate the called parameters identifier to calling device110. As mentioned above, the called parameters identifier may include identification information corresponding to the called parameters identifier or other types of information relating to called device110. The called parameters identifier may enable calling device110to obtain the called security parameters from the network (e.g., network application system195).

Process500may also include creating a security key (block560). For example, called device110may produce a security key based on one or more of the types of information generated, received, or otherwise obtained by called device110. In some implementations, called device110may create the security key based on the some or all of the called security parameters and the calling security parameters. As mentioned above, the security key may enable called device110to encrypt and decrypt communications to and from calling device110. Accordingly, called device110may be capable of creating a security key without ever having to communicate the security key, or the security parameters used to generate the security key, to calling device110.

WhileFIG. 5shows a flowchart diagram of an example process500for creating a security key, in other implementations, a process for creating a security key may include fewer operations, different operations, differently arranged operations, or additional operations than depicted inFIG. 5. For example, in some implementations, a process for creating a security key may include called device110communicating the called parameters identifier to a network device, such as network applications system195, and the network device communicating the called parameters identifier to calling device110. Additionally, or alternatively, two or more of the operations, described above, may be implemented in parallel.

FIGS. 6A-6Care diagrams of an example data flow600for creating security keys according to one or more implementations described herein. As illustrated inFIGS. 6A-6C, data flow600may occur between calling device110, called device110, bootstrap system190, and network application system195.

As illustrated inFIG. 6A, calling device110may execute a communication application (block602). For example, calling device110may execute a software application, such as a VoIP application, a video conferencing application, etc., that enables calling device110to contact called device110via a network, such as one or more of the networks described above with reference toFIG. 1. Additionally, or alternatively, calling device110may use another feature or component of calling device110(e.g., functionality made available via an operating system of calling device110) to communicate with called device110.

Calling device110may communicate with bootstrap system190to perform an authorization process and/or an authentication process with bootstrap system190(block604). This may include calling device110communicating with a BSF or another type of authentication service made available by bootstrap system190. For instance, calling device110may communicate with bootstrap system190to demonstrate that calling device110is capable of using a particular network to communicate using a service corresponding to the communication application.

As illustrated inFIG. 6A, calling device110may also obtain calling parameters (block606), which may include information stored locally by calling device110and/or information received from authorizing and/or authenticating with bootstrap system190. Calling device110may perform an authentication and/or authorization process involving network application system195. For instance, calling device110may communicate with network application system195to demonstrate that calling device110is permitted to use the communication application (block608). Calling device110may also, or alternatively, communicate the calling security parameters to network application system195(block610). As mentioned above, calling device110may also, or alternatively, communicate one or more other types of information to network application system195, such as a calling device identifier, a called device identifier, etc.

Network application system195may store the calling security parameters and/or other types information received from calling device110(block612). In some implementations, network application system195may also, or alternatively, associate the calling security parameters with the called device identifier (e.g., the telephone number of called device110). Network application system195may enhance security by ensuring that the calling security parameters are only communicated to called device110. Network application system195may also assign a calling parameter identifier to the calling security parameters (block614). Network application system195may communicate the assigned calling parameters identifier to calling device110(block616).

Referring toFIG. 6B, calling device110may send a message, such as a session invitation protocol (SIP) INVITE message, to called device110(block618). The message may invite called device110to establish a call or another type of communication session with called device110. Additionally, or alternatively, the message may include the calling parameters identifier. Called device110may perform one or more authorization and/or authentication operations with bootstrap system190(block620), which may be similar to the authorization and/or authentication operations executed by calling device110. For instance, called device110may communicate with a BSF or another type of authentication service made available by bootstrap system190.

Also, similar to calling device110, called device110may obtain called security parameters (block622), which may include information stored locally by called device110and/or information received from authorizing and/or authenticating with bootstrap system190. Called device110may perform an authentication and/or authorization process involving network application system195(block624). For instance, called device110may communicate with network application system195to demonstrate that called device110is permitted to use a communication application similar to the communication application being used by calling device110. Called device110may also, or alternatively, communicate the calling parameters identifier626to network application system195(block626), and network application system195may communicate the calling security parameters to called device110(block628).

As further depicted inFIG. 6B, called device110may use the calling security parameters and the called security parameters to create a security key (block630). Additionally, or alternatively, called device110may communicate the called security parameters to network application system195(block632). As shown inFIG. 6C, network application system195may store the called security parameters (block634), may assign a called parameters identifier to the store called security parameters (block636), and may communicate the called parameters identifier to called device110(block638).

As further shown inFIG. 6C, called device110may communicate a reply message to calling device110(block640). The reply message may include a200OK message or another type of SIP message. The reply message may also include the called parameters identifier, which calling device110may communicate to network application system195(block642). Network application system195may respond by providing calling device110with the called security parameters (block644), and calling device110may use the called security parameters, along with the calling security parameters, to create a security key (block646). As such, calling device110and called device110may use the newly created security keys to have secured communications between the calling device110and the called device110(block648).

Systems and/or methods, described herein, may provide solutions to creating security keys. For example, client devices110may each generate a security key based on parameters from a variety sources, such as results from an authentication process (e.g., a bootstrapping authentication process), information that is generated locally by each client device110, information that is received from a network application server, etc. As such, client devices110may each create a security key for encryption and/or decryption purposes without ever having to communicate to one another the encryption key or the parameters upon which the encryption key is based.

Systems and/or methods, described herein, may be used to enhance network performance by distributing the responsibility of creating security keys amongst client devices110(as opposed to, for example, a centralized server). Additionally, or alternatively, since the security keys may be created by each client device110locally, the systems and/or methods may enhance security by eliminating the transfer of security keys between client devices110. Further, the systems and/or methods may also, or alternatively, enhance security by even eliminating the transfer of security key parameters between client devices.

For example, while series of blocks have been described with regard toFIGS. 4 and 5, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.

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.