On-demand serving network authentication

METHOD AND APPARATUS FOR ON-DEMAND RE-AUTHENTICATION OF A SERVICE NETWORK BY USER EQUIPMENT (EU)

DESCRIPTIVE MEMORY

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority and benefit from Provisional Application No. 62/056,387 filed in the United States Patent and Trademark Office on September 26, 2014, and Non-Provisional Application No. 14/675,676, filed in the United States Patent and Trademark Office on March 31, 2015, the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

[0002] The present description refers generally to communication systems and, more particularly, to a system for authentication between user equipment and a service network in a wireless communication system.

BACKGROUND

[0003] Wireless communication systems are widely implemented to provide various telecommunications services such as telephony, video, data, messaging and broadcasting. Typical wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources (eg, bandwidth, transmission power). Examples of these multiple access technologies include code division access (CDMA)^ time division multiple access (TOMA) systems, frequency division multiple access (FDMA) systems, frequency division multiple access (FDMA) systems orthogonal (OFDMA) and single carrier frequency division multiple access (SOFDMA) systems and time division synchronous code division multiple access (TDSCDMA) systems.

[0904] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that allows different wireless devices to communicate at municipal, national, regional and even global levels As multiple access technologies are improved and increased , new telecommunications standards emerge. An example of an emerging telecommunications standard is fourth generation Long Term Evolution (LTE). LTE is a set of improvements to the mobile standard of the Universal Mobile Telecommunications System! (UMTS) promulgated by the Third Generation Partnership Project (3GPP). It is designed to better support mobile broadband internet access by improving spectral efficiency, reducing costs, improving services, utilizing new spectrum, and better integrating with other open standards through the use of QFDMA in the link. downlink (DL), SG-FDMA on the uplink, and multiple-entry multiple-output (MIMO) antenna technology. However, as the demand for mobile broadband access continues to increase, there is a need for further improvements in LTE technology, and/or for new generations of fefecommunications standards with enhanced capabilities.

[ooos] Security setup is an initial stage in setting up a carrier or channel! logical (for example, a communication link between a mobile communication device and a network entity or access point) in LTE networks. Key derivation and setting is part of this security setup. Most of the keys generated are encryption and integrity keys for non-access stratum security mode configuration (ÑAS) (ÑAS SMC) and access stratum security mode configuration (AS SMC) (AS). As new generations of communications technology are implemented, vulnerabilities to attack can be exposed in security configuration processes. Consequently, there is a need for improvements in security processes. Preferably, the enhancements should be applicable to other muStnacoeso technologies and the telecommunications standards employing these technologies,

[00061 wo 2013/009508 Al describes a method and apparatus for attaching a wireless device to an external wireless domain of a 3GPP communication system using an alternative authentication mechanism, where the wireless device performs the method, including: sending a first request message attached to an infrastructure device in the external wireless domain; receiving an attachment reject message from the infrastructure device upon making an unsuccessful attempt to obtain authentication credentials for the wireless device from a home wireless domain, or wireless device using the standard 3GPP authentication mechanism; in response to the attachment rejection message, sending a second attachment request message to the infrastructure device, wherein the second attachment request message indicates an alternative authentication mechanism to the 3GPP authentication mechanism; and receiving an accompanying acceptance message from the infrastructure device when the wireless device is successfully authenticated using the alternate authentication mechanism.

SYNTHESIS

[0007] In one aspect of the disclosure, a method, a computer program product, and an apparatus are provided.

>008] In accordance with certain aspects described herein, a method for securing wireless communication between a user equipment (UE) and a serving network includes the transmission by the UE of a connection request to a monitoring area request to a network function in a serving network after a security association has been established between the UE and the serving network where the request includes a nonce value and a signature request, and receives a response from the UE to the network function connection request or tracking area request where the response includes a network function signature, and authenticating the UE of the serving network on the basis of the signature of the network function and a public key certificate corresponding to the network function where the public key certificate is signed by using a private key of the service network provided by a network operator associated with the service network.

[0009] In accordance with certain aspects described herein, an apparatus has a wireless transceiver, and a processor coupled to the transceiver. The processor may be configured to transmit a connection request or tracking area request to a network function in a serving network after a security association has been established between the UE and the serving network where the request includes a nonce value and a signature request, receive a response to the connection request or trace area request from the network function where the response includes a signature from the network function, and authenticating the serving network based on the signature of the network function and a public key certificate corresponding to the network function, where the public key certificate is signed using a private key of the serving network provided by a network operator associated with the service network.

>010] According to certain aspects described herein, a method for providing membership of a serving network includes receiving a first message from a UE after the UE has established a secure connection with a home network, where the message is addresses a network function of the serving network and may include a nance value and a signature request, generating a signature using an operator-affiliated certificate maintained by the network function of the serving network, and transmitting a second message to the UE, where the signature is attached to the second message.

[0011 ] According to certain aspects described herein, an apparatus includes means for receiving a first message from a UE after a secure connection to a home network has been established, where the message is directed to a network function of the network and includes a nonce value and a signature request, means for generating a signature by using an operator-signed certificate maintained by the network function of the serving network, and means for transmitting a second message to the UE, where the signature is attached to the second message. The signature attached to the second message may be generated to demonstrate to the UE that the device is a member of a service network. The operator-signed certificate may be a public key certificate signed by an operator of the serving network.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1 is a diagram illustrating an example of a network architecture.

[0013] FIG. 2 is a diagram illustrating an example of an access network.

[0014] FIG. 3 is a diagram illustrating an example of a radio protocol architecture for user and control planes.

[0015] FIG. 4 is a diagram illustrating an example of an evolved Node B and user equipment (UE) in an access network.

[0016] FIG, 5 illustrates an example of the E-UTRAN key hierarchy that can be implemented within a network such as an LTE wireless network.

[0017] FIG. 6 illustrates a protocol stack that can be implemented in a communication device operating on an LTE packet-switched network.

[0018] FIG. 7 is a message flow diagram illustrating authentication in the example of an LTE wireless network.

[0010] FIG. 8 illustrates a network environment in which a UE connects to a serving network in order to obtain services from a home network.

[0020] FIG. 9 is a diagram illustrating a first example of vulnerability in a wireless network.

[0021] FIG. 10 is a message flow diagram illustrating a first example of connection request messages used for on-demand authentication of the serving network through an eNodeB in accordance with certain aspects described herein, [022] FIG. eleven is a message flow diagram illustrating a second example of connection request messages used for on-demand authentication of the serving network through an eNodeB in accordance with certain aspects described herein.

[0023] FIG. 12 is a message flow diagram illustrating a first example of tracking area update (TAU) messages used for on-demand authentication of the serving network through a mobility management entity (MME) according to certain aspects described herein.

[0024] FIG. 13 is a message flow diagram illustrating a third example of connection request messages used for on-demand authentication of the serving network through an eNodeB in accordance with certain aspects described herein.

[0025] FIG. 14 is a message flow diagram illustrating a fourth example of connection request messages used for on-demand authentication of the serving network through an eNodeB in accordance with certain aspects described herein.

[0020] FIG. 15 is a message flow diagram illustrating a second example of TAU messages used for serving network demand authentication via an MME in accordance with certain aspects described herein.

[0027] FIG. 16 is a diagram illustrating a second example of vulnerability in a wireless network.

[0028] FIG. 17 is a diagram illustrating a wireless network environment for overcoming the vulnerabilities illustrated in FIG. 16 according to certain aspects described herein.

[0029] FIG. 18 is a message flow diagram illustrating a fifth example of connection request messages used for on-demand authentication of the serving network through an eNodeB in accordance with certain aspects described herein.

[0030] FIG. 19 is a message flow diagram illustrating a sixth example of connection request messages used for on-demand authentication of the serving network through an eNodeB in accordance with certain aspects described herein.

[0031] FIG. 20 is a message flow diagram illustrating a third example of TAU messages used for on-demand authentication of the serving network via an MME in accordance with certain aspects described herein.

[0032] FIG. 21 is a block diagram illustrating an example of an apparatus employing processing circuitry that may be adapted in accordance with certain aspects described herein.

[0033] FIG, 22 is a flow chart of a wireless communication method performed in a UE according to certain aspects described herein;

[0034] FIG, 23 illustrates a first example of a hardware implementation for an apparatus adapted according to one or more aspects described herein,

[0030] FIG. 24 is a flow chart of a wireless communication method performed at a network node in accordance with certain aspects described herein.

[0036} FIG. 25 illustrates a second example of a hardware implementation for an apparatus adapted in accordance with one or more aspects described herein.

DETAILED SPECIFICATION

[0037] The detailed description set forth below in connection with the accompanying drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a complete understanding of various concepts. However, it will be apparent to those in the mid-level trade that these concepts can be practiced without these specific details. In some cases, well-known structures and components are shown in block diagram form in order to avoid obscuring these concepts.

[0038] Various aspects of telecommunication systems will now be presented with reference to various apparatuses and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as elements). These elements may be implemented through the use of electronic hardware, computer software, or any combination of these. Whether these elements are implemented as hardware or software depends on the particular application and design constraints imposed on the overall system.

[0039] By way of example, an element, or any part of an element, or any combination of elements, may be implemented with a computer or 'processing system' that includes one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs). programmable logic devices 6 (PLPs), state machines, closed logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this description. One or more processors in the processing system may execute the software. Software shall be broadly construed to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables , threads, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise,

[09403 Accordingly, in one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, functions may be stored or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media. Computer-readable media can include non-transient and transient storage media that can be read and/or manipulated by one or more processors. Storage media can be any available media that can be accessed by a computer. By way of example, and without limitation, these computer readable media may include random access memory (RAM), read only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM:), electronically erasable PROM (EEPROM). ), compact disk read-only (CD-ROM) or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other medium that can be used to transport or store the desired program code in the form of instructions or data structures and that can be accessed by a computer. Disc and disk, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk in which disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer readable media.

[0041} Some aspects described herein refer to systems and methods by means of which radio link setup processes and/or carrier establishment processes can be ensured. Certain aspects of the description address security issues 7 that may arise in new generations of radio access technologies (RATs), including fifth generation (SG) and later networks, as well as fourth generation networks. (4G) and earlier.. The configuration and operation of a 4GLTE network architecture is described herein by way of example, and for the purpose of simplifying descriptions of certain aspects that can be applied to multiple RATs,

[0042] FIG. 1 is a diagram illustrating an architecture of LTE network 100. The architecture of LTE network 100 may be referred to as an evolving packet system (EPS). The EPS may include one or more user equipment (UE) 102, an evolved UMTS terrestrial radio access network (E-UTRAN) 104, an evolved packet core (EPC) 110, a home subscriber server (HSS) 120 and an Internet Protocol (IP) service operator 122. The EPS can be interconnected with other access networks. Interfaces are not shown. As shown, the EPS provides packet-switched services, but for simplicity these entities*/interfaces are not shown. As shown, the EPS provides packet-switched services, however, as those of the mid-level trade will readily appreciate, the various concepts presented throughout this description can be extended to networks that provide circuit-switched services.

[0043] The E-UTRAN includes the evolved node B (eNodeB) 106 and other eNodeBs 108. The eNodeB 106 provides user protocol and control plane terminations to the UE 102. The eNodeB 106 may be connected to the other eNodeBs. 108 through a backtracking (For example, an X2 interface). The eNodeB 106 may also be referred to as a base station, a transceiver base station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSSX an extended service set (ESS), an eNB, or some other suitable terminology, The eNodeB 106 provides an access point to the EPC 110 for a UE 102. Examples of UE 102 include a cell phone, a smartphone, a Session Initiation Protocol (SIP) phone, a laptop computer, a personal digital assistant (PDA), a satellite radio, a global positioning system, a device multimedia, a video device, a digital audio player (for example, MP3 player), a camera, a game console, a virtual reality device, a tablet device, a media player, a device, a gaming device, a wearable computing device such as a smart watch or head-mounted optical display 8, or any other similarly functional device. The UE 102 may also be referred to by those in the mid-level trade as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote device, a mobile device, a wireless device, a mobile device. of wireless communication, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a mobile telephone, a user agent, a mobile client, a client or any other suitable terminology,

[0044] The eNodeB 106 is connected via an "81" interface to the EPC TIO. The EPC 110 includes an MME 112, other MMEs 114, a serving gateway 116 and a packet data network (PDN) gateway 1T8. MME 112 is the control node that processes signaling between UE 102 and EPC 110. In general, MME 112 provides bearer and connection management. All user IP packets are transferred through the service gateway 116, which is connected to the PDN gateway 118. PDN gateway 118 provides UE IP address assignment, as well as other functions. PDN gateway 118 is connected to carrier IP services 122. Carrier IR services 122 may include the Internet, an Intranet, an IR Multimedia Subsystem (IMS), and a PS Streaming Service (PSS).

[0045] The RG. 2 is a diagram illustrating an example of an access network 200 in an LTE network architecture. In this example, the access network 200 is divided into a number of cell regions (cells) 262. One or more lower power class eNodeBs 208 may have cell regions 210 that overlap with one or more of the cells 202. The lower power class eNodeB 208 may be a femtocell (eg, home eNodeB (HeNB)), pico cell, microcell, or remote radio head (RRH). The macro eNodeBs 204 are each assigned to a respective cell 202 and are configured to provide an access point to the EPC 110 for all UEs 206 in the cells 202. There is no centralized controller in this example of an access network 200, but a centralized controller can be used in alternative configurations. The eNodeBs 204 are responsible for all radio-related functions, including radio bearer control, admission control, mobility control, scheduling, security, and connectivity to the serving gateway 116.

[0046] The multiple access and modulation scheme employed by the access network 200 may vary according to the particular telecommunications standard being implemented. In LTE applications, OFpM is used in the DI and SG-FDMA is used in the UL to support frequency division duplexing (FDD) and time division duplexing (TDD). As persons of the mid-level trade will readily appreciate from the following detailed description, the various concepts presented here are well suited for LTE applications. However, these concepts can be easily extended to other telecommunications standards that employ other modulation and multiple access techniques. As an example, these concepts can be extended to Evolution Data Optimized (BADO) or Ultra Mobile Broadband (UMB). EV-DO and UMB are air interface standards promulgated by the 3rd Generation Partnership Project 2 (3GPP2). ) as part of the GDMA20O0 family of standards and employs CDMA to provide broadband Internet access to mobile stations. These concepts can also be extended to Universal Terrestrial Radio Access (UTRA) using Wideband CDMA (W-CDMA) and other variants of CDMA, such as TD-SCDMA; Global System for Mobile Communications (GSM) used by TOMA; and Evolved UTRA (E-UTRA), IEEE 802J1 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, and Flash-OFDM using OFDMA.UTRA, E-UTRA, UMTS, LTE, and GSM. 3GPP. CDMA2000 and UMB are described in 3GPP2 organization documents. CDMA2000 and UMB are described in 3GPP2 organization documents. The actual wireless communication standard and multiple access technology employed will depend on the specific application and the general design limitations imposed on the system.

[0047] The eNodeBs 204 may have multiple antennas that support MIMO technology. The use of MIMO technology allows eNodeBs 204 to take advantage of the spatial domain to support spatial multiplexing, beamforming, and transmit diversity. Spatial multiplexing can be used to transmit different data streams simultaneously on the same frequency. Data streams can be transmitted to a single UE 206 to increase the data rate to multiple UEs 206 to increase the overall capacity of the system. This is accomplished by spatially precoding each data stream (ie, by applying one amplitude and one phase scaling) and then transmitting each spatially precoded stream through multiple transmit antennas in the DL. Spatially precoded data streams arrive at UE(s) 206 with different spatial signatures, allowing each of UE(s) 206 to retrieve one or more data streams destined for that UE 206. In the 10

UL, each UE 206 transmits a spatially pre-encoded data stream, which allows the eNodeB 204 to identify the source of each spatially pre-encoded data stream.

[0048] Spatial mapping is generally used when channel conditions are good. When channel conditions are less favourable, beamforming can be used to focus the transmission energy in one or more directions. This can be achieved by spatially precoding the data for transmission over multiple antennas. To achieve good coverage at the cell edges, single stream beamforming transmission can be used in combination with transmit diversity.

[0040] In the following detailed description, various aspects of an access network will be described with reference to a MIMO system supporting OFDM in the DL. OFDM is a spread spectrum technique that modulates data across numerous subcarriers within an OFDM symbol. The subcarriers are spaced at precise frequencies. The spacing provides an orthogonality*' that allows a receiver to recover the data from the subcarriers. In the time domain, a guard interval (eg, cyclic prefix) can be added to each OFDM symbol to combat interference between OFDM symbols. The UL can use SC-FDMA in the form of a DFT-spreading OFDM signal to compensate for the high peak-average power ratio (PAPR). [0058] FIG. 3 is a diagram 300 illustrating an example of a radio protocol architecture for user and control planes in LTE. The radio protocol architecture for the UE and eNodeB is shown with three layers: Layer 1, Layer 2, and Layer 3. Layer 1 (layer L1) is the lowest layer and implements various radio signal processing functions. physical layer. The L1 layer will be referred to herein as the physical layer 306. Layer 2 (L2 layer) 308 is on top of the physical layer 306 and is responsible for the link between the UE and eNodeB over the physical layer 306.

[8051] At the user level, the L2 layer 308 includes a media access control sublayer (Media Access Sublayer) 310, a radio link control (RLC) sublayer 312, and a protocol sublayer packet data convergence (PDCP) 314 that are terminated at the eNodeB on the network side. Although not shown, the UE may have several higher layers above the L2 layer 308 including a network layer (eg, IP layer) terminating at the PDN gateway 118 on the network side and an application layer terminates at the other end of the connection (eg, far-end UE, server, etc.).

PSS2J PDCP sublayer 314 provides multiplexing between different radio bearers and logical channels. PDCP sublayer 314 also provides header compression for higher layer data packets to reduce radio transmission overhead, security by encrypting data packets, and handover support for UEs between eNodeBs. RLO sublayer 312 provides upper layer data packet segmentation and reassembly, retransmission of lost data packets, and reordering of data packets to compensate for out-of-order reception due to hybrid auto re-request (HARQ). ). The media access sublayer 310 provides multiptexing between logical and transport channels. The media access sublayer 310 is also responsible for allocating the various radio resources (eg, resource blocks) in a cell between UEs. Media access sublayer 310 is also responsible for HARQ operations.

[00531 In the control plane, the radio protocol architecture for the UE and eNodeB is substantially the same for the physical layer 306 and layer 12 308 with the exception that there is no header compression function for the control plane. . The control plane includes a radio resource control (RRC) sublayer 316 at Layer 3 (layer L3). The RRC sublayer 318 is responsible for obtaining radio resources (i.e., radio bearers) and configuring the lower layers by using RRC signaling between the eNodeB and the UE,

[0054] FIG. 4 is a block diagram of an eNodeB410 in communication with a ÜE450 in an access network. In the DL, packets from the upper layer of the core network are provided to a controller/processor 475. The controller/processor 475 implements the functionality of the L2 layer. In the DL, the controller/processor 475 provides header compression, encryption, packet segmentation and reordering, multiptexing between logical and transport channels, and radio resource allocations to the UE450 based on various priority metrics. Controller/processor 475 is also responsible for HARQ operations, retransmission of lost packets, and signaling to UE450.

[OQSS] The transmit (TX) processor implements various signal processing functions for the L1 layer (ie physical layer). Signal processing functions include encoding and interleaving to facilitate forward error correction (FEC) in the UE450 and mapping into signal constellations based on 12 different modulation schemes (e.g. binary phase shift keying). (BPSK), Quadrature Phase Shift Keying (QPSK), M-Phase Shift Keying (M-PSK), M-Quadrature Amplitude Modulation (M~QAM), The encoded and modulated symbols are then divided into parallel streams. Each stream is then mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g. pilot) in the time and/or frequency domain and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time-domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. The channel estimates from a channel estimator 474 can be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate may be derived from a channel condition reference and/or feedback signal transmitted by the UE450. Each spatial stream is then provided to a different antenna 420 via a separate transmitter 418TX. Each 418TX transmitter modulates an RF carrier with a respective spatial stream for transmission.

[0056] In the UE450, each receiver 454RX receives a signal through its respective antenna 452. Each receiver 454RX retrieves information modulated on an RF carrier and provides the information to the receive (RX) processor 456. The RX processor 456 I implement various signal processing functions of the L1 layer. The RX processor 456 performs spatial processing on the information to retrieve any spatial stream destined for the UE450. If multiple spatial streams are destined for the UE450, these may be combined by the RX processor 456 into one symbol stream. Unique OFDM. The RX processor 456 then converts the OFDM symbol stream from the time domain to the frequency domain through the use of a Fast Fourier Transform (FFT). The frequency domain signal comprises a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier and the reference signal are recovered and demodulated by determining the most likely signal constellation points transmitted by the eNodeB410. These soft decisions can be based on channel estimates calculated by the channel estimator 458. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the eNodeB410 on the physical channel. The data and control signals are then provided to the controller/processor 459.

[0057] The controller/processor 459 implements layer 12. The controller/processor may be associated with a memory 460 that stores program codes and data. The memory 460 can be referred to as a computer readable medium. In the UL, the controller/processor 459 provides demultiplexing between the logical and transport channels, packet reassembly, decryption, header decompression, core processing to retrieve packets from the upper layer of the core network. The upper layer packets are then provided to a data sink 462, which represents all protocol layers above the L2 layer. Various control signals may also be provided to the data sink 462 for L3 processing. The Zprocessor controller 459 is also responsible for detecting errors by using a reclosing (ACK) and/or negative acknowledgment (NACK) protocol to support HARGL operations.

[0058] In the UL, a data source 467 is used to provide upper layer packets to the controller/processor 459. The data source 467 represents all protocol layers above the LL layer. Similar to the functionality described in connection with the DL transmission by the eNodeB410, the controller/processor 459 implements the L2 layer for the user plane and the control plane providing header compression, encryption, segmentation and ordering of packets and multiplexing between logical and transport channels based on radio resource allocations by the eNodeB41O. The controller/processor 459 is also responsible for HARQ operations, retransmission of lost packets, and signaling to the eNode8410.

>0S9] The channel estimates derived by a channel estimator 458 from a feedback α reference signal transmitted by the eNodeB410 may be used by the TX processor 466 to select the appropriate coding and modulation schemes and to facilitate spatial processing. . The spatial streams generated by the TX processor 468 are provided to different antennas 452 via separate transmitters 454TX. Each transmitter 454TX modulates an RF carrier with a respective spatial stream for transmission.

[0060] The UL transmission is processed in the eNadeB4 W in a similar manner as described in relation to the receiver function in the UE450, Each receiver 418RX receives a signal through its respective antenna 420. Each receiver 418RX retrieves information 14 modulated on an RF carrier and provides the information to an RX processor 470. The RX processor 470 may implement the L1 layer.

[0061] The controller/processor 475 implements the L2 layer. The controller/processor 475 may be associated with a memory 476 that stores program codes and data. Memory 476 can be referred to as a computer readable medium. In the UL, the control/processor 475 provides demultiplexing between the transport and logical channels, packet reassembly, decryption, header decompression, control signal processing to retrieve upper layer packets from UE450. Upper layer packets may be provided from controller/processor 475 to the core network. Controller/processor 475 is also responsible for error detection by using an ACK and/or HACK protocol to support HARQ operations.

Carrier configuration in LTE networks

[0062] The configuration of the radio link in an LTE network may involve the establishment of one or more radio bearers between an access node providing access to a network and a communication device. The radio link setup typically includes a security activation exchange. A session bearer, which may be a logical bearer or a logical channel, may then be established over the radio link and one or more services and/or communications may be established on the session bearer. The session bearer, services and/or communications can be secured by means of one or more security keys.

[0063] As part of the session bearer setup, an authentication request and/or one or more key exchanges may take place. In networks operating in accordance with an LTE compatible protocol, keys may be derived by the communication device based on algorithms provided by one or more network entities.

E-ÜTRAN Key Hierarchy Example

[0064] FIG. 5 illustrates a typical E-UTRAN key hierarchy 500 that may be implemented within a typical LTE network. In the communication device, a Universal Subscriber Identity Module (USIM) and an authentication center (AuG) in a network entity on the network side use a master key (K) 502 to generate an encryption key 15 ( CK) 504 and an integrity key) 506. The encryption key (CK) 504 and integrity key (IK) 506 may be used by the communication device and a home subscriber server (HSS) at the network entity to generate a network security management entity key. access (Kasme) 508. Security activation of a communication device operating on an LTE network can be achieved through an authentication and key agreement (AKÁ) procedure, non-access stratum (ÑAS) security mode configuration (NAS SMC), and configuration. stratum security mode (AS SMC), AKA is used to derive Καρ«508, which is then used as the base key for computation of ÑAS keys 510 and 512 and AS keys 514, 516, 518 and 520. The communicating device and an MME on the network side can then use Kasme$Ó8 to generate one or more of these security keys.

[QW] LTE packet-switched networks can be structured in multiple hierarchical protocol layers, where lower protocol layers provide services to higher layers and each layer is responsible for different tasks. For example, FIG. 6 illustrates an example of a protocol stack 600 which may be implemented in a communication device operating on an LTE packet-switched network. In this example, an LTE protocol stack 600 includes a Physical Layer (PHY) 604, a Media Access Control Layer 606, a Radio Link Control (RLC) Layer 608, a Network Convergence Protocol Layer (PDCP) layer 611, an RRC layer 612, a NAS layer 614, and an application (APP) layer 616. The layers below the NAS layer 614 are often referred to as the access stratum (AS) layer. 602.

[0066] RLC layer 608 may include one or more channels 610. RRC layer 612 may implement various control modes for the UE, including connected state and idle state. The NAS layer 614 may maintain the communication device's mobility management context, packet data context, and/or its IP addresses. It should be noted that they may be present in the protocol stack 600 (eg, above, below, and/or between the illustrated layers), but have been omitted for illustration purposes. The radio/session bearers 613 may be established, for example, in the RRC layer 612 and/or NAS layer 614. Accordingly, the NAS layer 614 may be used by the communication device and an MME to generate the security keys. Kíías_w510 and K^as«512. Similarly, the RRC layer 612 can be used by the communication device and an eNodeB to generate the security keys Kup^nc 516, Krrc^bc 518, 16 and Krrcm 520, while the security keys Kup-enc 516 , Krr» 518,and K^_nt 520 may be generated at RRC layer 612, these keys may be used by PDCP layer 611 to secure signaling and/or user/data communications. For example, the key Kue^nc 516 may be used by the PDCP Layer 611 to secure user/data plane (UP) communications, while the keys Krrc^g 51A and Kaac^nt 520 may be used to secure the UP communications. signaling (i.e. control) communications at the PDCP layer 611,

[0067] In one example, before establishing these security keys (keys 5W, KnaSM 512, tW-w 516, KRRG-enc 518, and/or Kfww 520), communications to/from a communication device (unprotected or unencrypted) over a non-secure common control channel (CCCH). After these security keys are established, these same user data and/or control/signaling communications may be transmitted over a dedicated control channel (CCCH). DCCH).

[0060] During connection setup/session setup procedures on an LTE-enabled network, the AKA and NAS SMC procedures are optional if there is an existing native ÑAS security context already present from previous setup sessions. The existing ÑAS context can be reused at the time of service requests, join requests and TAU requests, TAU requests can be sent periodically by a UE or when the UE enters a tracking area that was not associated with the UE, where the tracking area (or enrollment area) may be an area in which a UE is able to move without first updating the network, [6066] The security keys used for the encryption and integrity algorithms, both in the AS (user plane and RRC) and in the ÑAS, can be derived using an individual algorithm identity! provided as one of the inputs. At the NAS level (eg, NAS layer 614), it is provided to the communicating device by the access node (eNodeB) in the NAS security mode command during the NAS SMC procedure. At the AS level, the algorithms to be used are provided by the Radio Resource Control (RRC) Security Mode Command. Key generation can be performed with a key derivation function (KDF), such as the HMAC-SHA~256 function. In the generation of security keys ÑAS Knas^c 510 and Integrity key Kna^m 512 and RRC security keys RRC Kup^c 516, 518 and integrity key IWkm»? 520, the KDF key derivation function takes various types of input, including an input algorithm identity provided by the network during a security activation exchange. For example, the input algorithm identity may identify Advanced Encryption Standard (AES) or ”$N0W-3G,

[0070] It should be noted what, in some implementations. all security keys (for example, ÑAS encryption and integrity keys and RRG encryption and integrity keys) are generated using the same key derivation function (KDF), for example HMAC-SHA-256, which uses a root/base key (for example, K_Ask< cna or more fixed inputs, and one of the plurality of possible input algorithm identities (ie security key = KDF(rabdbase key, identity algorithm)).

An example of an AKA procedure

[S071] FIG. 7 is a flowchart 700 illustrating an example of authentication in an LTE wireless network. A UE 782 may connect to the network through a serving network 704 in order to obtain services from a home network 706 provided by a network operator. During bearer setup, the UE 702 may establish a secure connection with an HSS 712 of the home network 706. The UE 702 may trust the HSS 712, while the eNodeB 708 of the serving network 704 may not be trusted. The UE 702 may transmit a NAS join request 720 with identification information such as an International Mobile Subscriber Identity (IMS!). The MME 710 receives the ÑAS join request 720 and sends the request 720 in an authentication information request message 722 to the HSS 712. The authentication information request message 722 may include the IMS! of the UE 702 and a serving network identifier (SNJd). The HSS712 may respond with an authentication information response message 724 that includes an authentication value (AÜTNX, an expected result value (XRES), a random number, and a Kasme- The AUTN is generated by an AúC and, together with the RAND, authenticates the HSS 712 to the UE 702, Messages 722, 724 between the MME 710 and the HSS 712 communicate on a link 740 and protect an authentication, authorization, and accounting protocol (Diameter),

[00721 ​​The MME 710 transmits a ÑAS authentication request 726 to the UE 702, which responds with a ÑAS authentication response message 728. The ÑAS authentication request 726 includes the AUTN, RANO, and a key set identifier (KSUs^h ). The MME 710 may transmit a non-access stratum (NAS) security mode configuration (NAS BMC) message 730 to the UE 702. The UE 702 then transmits a "NAS Security Mode Complete" message 732 to the MME 710, which signals the eNodeB 708 an Initial Context Configuration message of $1AF 734. The eNodeB 708 may then transmit a "NAS Security Mode Complete" message 736. (RRC) no access stratum security (RRC SMC) to the UE 702, which responds with a security mode complete message 738 when ready,

[0073] In certain network implementations, the serving network 704 is trusted for a certain period of time after authentication has been performed. In one example, the serving network 704 may be trusted after authentication until another authentication process (AKA) is performed with the HSS 712. The time that the established trust survives may be determined by a network operator. The network operator can configure the trust period to last several hours, days or weeks.

Examples of security concerns in the evolution of network technologies [0074] Due to the development of 4G, 5G and other network technologies, certain network functions may be pushed to the edge of the network. In some cases, the relocation of one or more network functions can degrade and invalidate trust in a cellular core network.

[0075] In one example, a femtocell or home eNodeB (HeNB) may be implemented to provide localized wireless service over a broadband connection. A femtocell can be characterized as a small, low-power cellular base station, typically designed for use in a home or small business environment. A femtocell can be any small cell, typically with limited range and/or a limited number of active bonded UEs that connects to a network operator's network via a wide area network or connection. The femtocell may be operable on one or more networks, including WCDMA, GSM, CDMA2000, TDSCDMA, WiMAX, and LTE networks. The implementation of new technologies and/or the use of femtocells can produce management of network functions in less protected and/or isolated places that are more susceptible to attack. For these and other reasons, the level of security provided by a small cell or relay node can be significantly degraded relative to the security provided by a macro cell. An increase in the implementation of small cells and relays to support multiple hops within a network can be expected.

[0078] In another example, network functions in certain newer technologies may be located on shared systems, and/or provided in a cloud environment. In such 19

Systems and Environments Computing and networking functions can be virtualized and often handled by a third-party vendor. While network operators may be able to secure access paths to the cloud, the security of the Cloud Interior cannot be guaranteed. In some cases, trade-offs are made between the internal security of the virtual environment (cloud) and the performance of the virtualized system. In some cases, network operators do not need to own the network equipment used to connect UEs, and/or different network equipment components in a network may be owned by different operators. Reduced isolation between operators may result, and some network operators may have easier access to another network operator's credentials. For example, the credentials of a first network operator may be more easily misappropriated by a second network operator when both operators share a common eNodeB or MME,

[0077] Networks can be assumed to be insecure when certain security assumptions are invalidated. In 4G AKA, for example, the HSS is a trusted network entity, and the HSS can be a root of trust. Mutual authentication between a UE and a serving network may depend on the security between the HSS and the serving network. The HSS authenticates the serving network on behalf of the UE and provides the authentication credentials for the UE to the serving network through a secure channel.

ΕΘ078] FIG, 8 is a simplified block diagram 800 illustrating a network environment in which a UE 802 connects with a serving network 804 to obtain services from a home network 812. In the example shown, the UE 802 can establish a wireless connection 814 with an MME 810 through an eNodeB 808 provided in an E-UTRAN operating as part of an 804 serving network. The MME 810 is connected via an 818 link to an HSS 808 of the 812 home network.

[0079] The eNodeB 808 and/or MME 810 of the service network may be compromised due to shared use of network hardware, relocation of network functions to the network edge, and/or placement of the eNodeB 808 and/or MME 810 in a public location or otherwise not physically secure.

[0080] FIG. 9 is a simplified block diagram 900 illustrating certain vulnerabilities in the serving network 804, An attacker 902 can exploit certain protocol and/or software vulnerabilities to acquire session credentials, The attacker 902 may include functions that can use the session credentials to Impersonate (via a communications link 904) a valid serving network of the 804 operator and to capture information from a UE 802 attempting to establish a connection to the network. of operator 804 compromised by attacker 902.

>081] In one example, an attack can be characterized as a heartbleed attack when the attacker 902 exploits an implementation flaw in an otherwise healthy security protocol. The attacker 902 can take advantage of network equipment collocation or network functions to acquire credentials such as authentication vectors (AV) 908 transmitted to an MME 810 and/or encryption keys (KeNB) 906 used, maintained or generated by the eNodeB 808. Credentials may be obtained from the eNodeB 80S, the MME 810 and/or from portions of interconnects 814, 816 available to collocated hardware providing shared equipment or network functions.

[0082] Session credentials are retrieved from the HSS 806 infrequently and can remain valid for a period of time that can be measured in hours or days. A 902 attacker who has intercepted the credentials can impersonate an 804 serving network until the next authentication procedure with the 806 HSS is performed.

>083] In one example, the attacker 902 can intercept the credentials after an AKA procedure, the attacker 902 can be a fake public land mobile network (PLMN) that can impersonate a serving network 804 provided by a valid network operator . The vulnerabilities in the eNodeB 808, the MME 810 and/or the interconnects 814, 816 can be controlled by the attacker in order to capture an IMSI associated with it UE 802. information including keys 906 and other credentials such as authentication vectors 908 related to establishing a connection by or on behalf of the UE 802. In some cases, an MME in the attacker 902 may impersonate an MME 810 in the attacker's network. valid service 804 and establishing a communications link 904 with the IUE 802 using intercepted I MS I, authentication vectors 908, and keys 90S. Attacker network entities 902 may then have access to information about the UE802 and may control communications coming from the UE802.

Enhanced Service Network Authentication >084] In accordance with certain aspects described herein, the security of a network can be enhanced by authenticating the service network 804 while establishing network connections. The UE 802 can be adapted or configured to authenticate a serving network 804 as fully as possible, and as needed. That is, the UE 802 can be configured to avoid unnecessary authentication procedures when connections to the serving network are active and the serving network can be trusted on the basis of prior authentication.

[GOSS] In order to authenticate the serving network and prevent attacks based on the acquisition of session secrets such as authentication vectors for the UE 802, a list of trusted networks may be maintained in the UE 802, in which the list identifies public or shared keys, certificates, and/or other credentials corresponding to trusted networks. In one example, the UE 802 may have a list of trusted PLMNs and corresponding public key certificates. The eNodeB 80S and MME 810 may have public key certificates signed by their respective operators, which may be the same operator and may include the service network operator 804. The private key corresponding to the public key used by the network , which include the eNodeB 808 and MME 810, is kept in a secure storage or secure execution environment, such as a TrE, and an attacker cannot acquire the private key in the TrE.

[0Q86] FIGs. 10; 11 and 12 are message flow diagrams 1000, 1100, 1200 illustrating examples of on-demand processes for authenticating serving network 804 using a public key-based approach. A public key signed by the operator is used to authenticate the serving network 804. The serving network 804 may have a certificate signed by a trusted third party (TIP), such as Verisign or Internet Assigned Numbers Authority (IANA). ). In some cases, the serving network 804 may employ a self-signed certificate that is provided by the home network 812 to the UE 802 in a list of trusted certification authorities (CAs). The list of trusted CAs may include operators and their corresponding public keys. The list of trusted CAs and public key or certificates can be distributed to roaming partners through a secure channel.

[0067] Network functions, including the MME 810 and the eNodeB 808 can prove their membership to the serving network 804 using a certificate signed by the operator. An attacker who does not possess the private key corresponding to the public key issued for networking cannot authenticate to the UE 802.

[0088] In accordance with certain aspects described herein, signaling and/or messages initiated by the UE. 802 can be leveraged to allow on-demand authentication of the 804 serving network. Baseline overhead is avoided and idle-state overhead can be eliminated through “by-overlay” authentication of the 804 serving network on that network. signaling.

[0089] RRC messages can be used to authenticate the eNodeBSOS. Examples of such RRC messages include RRC connection request, and RRC connection reset. The UE 802 may request that connection messages exchanged with the eNodeB 808 be signed. In some cases, the UE 802 may request the public key of the eNodeB 808.

[0090] TAU or service request messages may be used to authenticate the MME 810. In one example, the UE 802 may request that the TAU or service request accept signed messages exchanged with the MME 810. In some cases, the UE 802 may request the public key from the MME 810,

[0091] FIG. 10 is a message flow diagram 1000 illustrating a first example of the use of RRC messages 1004 for on-demand authentication of serving network 804 via eNodeB 808. UE 802 may initiate an AKA procedure 1002. Once complete With the AKA 1002 procedure successful, the UE 802 can authenticate the serving network 804 using the RRC 1004 messages. An RRC connection request (or connection establishment request) 1010 may be used as part of the authentication. In one example, an RRC connection request 1010 may be transmitted to eNodeB 808 during transitions from idle mode. When a UE 802 enters sleep mode, the eNodeB 808 may leave the security context for UE802 for power saving reasons. In accordance with certain aspects, the UE 802 may transmit an RRC connection request 1010 that includes additional fields. The additional fields may include a Nonce and a request for the signature of the eNodeB 808. In some cases, the additional fields may also include a request for the public key of the eNodeB 808. The Nonce value can be an arbitrary, random, or pseudorandom number used to ensure that previous communications cannot be reused in replay attacks. The eNodeB 808 may transmit an RRC connection setup response 1012 that is signed using its private key and, upon verification of the authenticity of the eNodeB 808, the UE 802 may indicate the complete RRC connection setup 1014.

[0092] FIG. 11 is a message flow diagram 1100 illustrating a second example of the use of RRC messages 1104 for on-demand authentication of serving network 804 via eNodeB 808. UE 802 may initiate an AKA procedure 1102.

After successfully completing the AKA procedure 112, the UE 802 may authenticate the serving network 804 using the RRC messages 1104. An RRC connection reset request 1110 may be used, for example, during connection failure recovery. In accordance with certain aspects, the UE 802 may transmit an RRC connection reset request 1110 that includes additional fields. The additional fields may include a Nonce value and a request for the signature of the eNodeB 808. In some cases, the additional fields may also may include a request for the public key of the eNodeB 808. The eNodeB 808 may transmit a connection reset response 1112 which it signs using its private key and, after verification of the authenticity of the eNodeB 808, the UE 802 may indicate a complete RRC connection setup 1114. The process illustrated by the example of RG message flow diagram ÍW0. 11 can prevent an attack that causes a disconnection to intercept credentials during failover procedures.

[0093] The UE 802 may authenticate the serving network 804 using RRC messages as necessary when there is data to transmit, data to receive before or after a handover to another network function. RRC connection, establishment and/or reestablishment requests are initiated by the UE 802 and these requests require a response from the eNodeB808. In some cases, the UE 802 may determine that it is not necessary to continually authenticate the serving network 804. For example, there is no need to perform authentication when the UE 802 is in an idle state and no handover is indicated. The overhead associated with the baseline protocol can be minimized when signatures are provided on demand. The eNodeB 808 normally provides the network function certificate only after request.

>994] FIG. 12 is a message flow diagram 1200 illustrating a first example of TAU messages 1204 used for on-demand authentication of the serving network via MME 810. UE 802 may initiate an AKA procedure 1202. After successful completion AKA procedure 1202, UE 802 may authenticate serving network 804 using TAU messages. A TAU 1210 request can be used, for example, during periodic registration or after a handover. In accordance with certain aspects, the UE 802 may transmit the TAU request 1210 with additional fields that may include a Nonce value and a request for the signature of the MME 810. In some cases, the additional fields may also include a request for the key. public key 24 of the MME 810. The MME 810 may transmit a response 1212 which is signed using its private key and, after verification of the authenticity of the MME 810. the UE 802 may signal RRC connection setup complete 1214.

[0095] FIGs. 13, 14, and 15 are message flow diagrams 1300, 1400, 1500 illustrating examples of on-demand processes for authenticating the serving network 804 using a shared key-based approach to thwart attacks in which an attacker can compromise and exploit the system or protocol vulnerabilities in order to acquire session secrets, such as ÑAS and AS keys. Network functions, such as the eNodeB 808 and MME 810, can have a trusted execution environment, which can be used to maintain key derivation keys for network functions. Typically, an attacker cannot acquire the keys stored in the trusted execution environment. In one example, the key derivation key stored in the trusted execution environment for the MME 810 is the key Kasms and the key derivation key stored in the trusted execution environment for the eNodeB 808 is the key K^ a. Key derivation keys are not used directly for encryption and integrity protection, and are typically used to generate keys that can be used for encryption and integrity protection. Network functions can prove their membership in the 804 serving network using their respective key derivation keys. Attackers who do not have access to key derivation keys stored in the trusted execution environment cannot prove impersonated membership to the 804 serving network.

[0096] Certain on-demand procedures for authenticating the serving network 804 using shared keys may leverage UE-initiated messages 802. The authentication process may be implemented as an on-demand process in order to limit the protocol overhead. baseline and potentially eliminate the overhead of idle state,

[0097] RRC messages can be used to authenticate the eNodeB 808. Examples of such RRC messages include RRC connection request and RRC connection reset. The UE 802 may request that connection messages exchanged with the eNodeB 808 be signed. In some cases, the eNodeB 808 may not be in possession of the KeNB when an RRC connection setup message is transmitted. Therefore, the signature or a message authentication code (MAC) is sent to the UE 802 after the security mode control procedure. A MAC code may include information produced using a hash (digest) function or the like, where the MAC code may authenticate and/or ensure the integrity of a message.

[OOSS] TAU messages may be used to authenticate the MME 810. In one example, the UE 802 may request to accept TAU ​​Accept messages exchanged with the MME 810,

[0888] FIG. 13 is a message flow diagram 1300 illustrating a third example where RRC messages are used for on-demand authentication of serving network 804 via eNodeB 808. UE 802 may initiate an AKA procedure 1302. Once successfully completed the AKA 1302 procedure. The UE 802 can authenticate the serving network 804 using the RRC 1304 messages. An RRC 1310 connection request may be used, for example, during transitions from idle mode. In accordance with certain aspects, the UE 802 may transmit an RRC connection request 1310 that includes additional fields. Additional fields can include a Monee value and a signature request. The eNodeB 808 signs its response 1312 using KeNB, and after verifying the authenticity of the eN^ 808, the ÜE 802 can acknowledge completion of the procedure by signaling RRC connection setup complete 1314,

[80180] The F1G. 14 is a message flow diagram 1400 illustrating a fourth example of RRC messages 1404 used for on-demand authentication of serving network 804 via eNodeB 808. UE 802 may initiate an AKA procedure 1402 and, after completing With the AKA procedure 1402 successful, the UE 802 can authenticate the serving network 804 using the RRC messages 1404. An RRC 1410 connection reset request may be used, for example, during connection failure recovery. In accordance with certain aspects, the UE 802 may transmit a connection reset request RRC 1410 that includes additional fields. Additional fields can include a Nonce value and a signature request. The eNodeB 808 may transmit a response 1412 that is signed using KeNB and, upon verification of the authenticity of the eNodeB 808, the UE 802 may indicate the complete RRC connection setup 1414.

[00101] The UE 802 may authenticate the serving network 804 using RRC messages as necessary when there is data to be transmitted, received, or before or after a handover to another network function. RRC connection establishment, RRC connection, and/or RRC reset requests are initiated by the UE 802 and such requests require a response from the eNodeB 808. In some cases, the UE 802 may determine that it is not necessary to continuously authenticate the connection. serving network 804, For example, authentication is not required when UE 802 is in an idle state and no handover is indicated. The overhead associated with the baseline protocol can be minimized when signatures are provided on demand. The eNodeB 808 normally provides the network function certificate only after request.

[00102] FIG. 15 is a message flow diagram 1500 illustrating a second example of TAU messages 1504 used for on-demand authentication of the serving network via MME 810. UE 802 may initiate an AKA procedure 1502. Once completed with If the AKA procedure 1502 is successful, the UE 802 may authenticate the serving network 804 using the TAU messages 1504. A TAU request 1510 may be used, for example, during periodic registration or after a handover. In accordance with certain aspects, the UE 802 may transmit the TAU request 1510 with additional fields that may include a Nonce value and a ta request The MME 810 may transmit a response 1512 that is signed using the Kasve key and, upon verification of the authenticity of the MME 810, the UE 802 may signal a complete RRC connection setup 1514.

Security concerns related to physically accessible network functions

[00103] FIG. 16 is a simplified block diagram 1600 illustrating certain serving network vulnerabilities 804 that can arise when an attacker 1602 has physical access to network equipment that provides certain network functions (eg, the eNodeB 808 and/or the MME 810) of a service network 804. Under this form of attack, the attacker 1602 may gain access to permanent credentials including permanent keys 1606, 1608, as well as session credentials. For example, the attacker 1602 may have access to a permanent key 1666 and/or 1608, such as the private key of the network equipment and/or a network function, such as the eNpdeB 808 or the MME 810. The private key is can use to sign messages. Under this form of attack, the attacker 1602 can spoof the serving network 804 persistently, with respect to communications 1604 with the UE 802 and with respect to communications 1610 with the HSS 806.

[001043 An attacker 1602 who has physical access to network equipment may be able to acquire all credentials issued for network functions by compromising network equipment associated with those network functions. The network functions may hold, provide, or be associated with credentials such as authentication vectors for a UE 802 and/or a private key attached to the certificate signed by the network operator.

1001051 With reference to Fig. 17, the security of a network can be improved when the network operator provides network functions (for example, the eNpdeB 1708 and/or the MME 1710) with a public key certificate and uses the services of a certificate observatory (Certób ) 1714. The CertOb 1714 can be operated by a trusted third party that cannot be compromised; The CertOb 1714 can be used to test the integrity of network function certificates issued by the operator. ΕΓ CertOb 1714 can be identified and/or accessed using a certificate observatory identifier that includes an IP address and/or a Universal Resource Locator (URL). The service network can be authenticated using a public key based authentication process, with verification of the status of the network foundation certificate (for example, the eNodeB 1708 or the MME 1710).

[00106] A certificate server function (OSE) 1712 manages network function certificates and provides network function certificates to a UE 1702 on demand. The CSF 1712 reports certificate status changes in the CertOb 1714. The status changes can include issuance events, revocation events, and so on. The CertOb 1714 stores the integrity information of the operators certificate and provides the information to the HSS 1706 and the UE 1702. Certificate integrity information may be provided as a hash of all current certificates for a serving network 1704. In one example, the hash may be provided as a hash tree of WfK< which provides efficient and secure verification of the certificate. associated with multiple domains corresponding to the operator's networks.

PH071 A UE 1702 may initially validate a certificate by comparing a first copy of the certificate integrity information provided by the serving network with a second copy of the certificate integrity information received at the UE 1702 from the CertOb 1714. If the first and second copies of the certificate integrity information do not match, the UE 1702 may request the CSF 1712 to provide one or more certificates for the serving network 1704 in order to authenticate 28 a network function with which the UE 1702 actively communicates.

(0010^ Figs. 18, 19 and 20 are message flow diagrams 1800, 1900, 2000 illustrating examples of on-demand processes for authenticating the serving network 1704 using an operator-signed public key-based approach that is used to authenticate the serving network 1704. The serving network 1704 may be provided with a certificate signed by a trusted third party (TTP) such as Verisign or Internet Number Assignment Authority (JANA). In some cases, the serving network 1704 may employ a self-signed certificate that is provided to the UB 1702 on a list of trusted certificate authorities (CAs) by the home network. The list of trusted CAs can include operators and their corresponding public keys. The list of CAs and the public key or certificates can be distributed to roaming partners through a secure channel.

(ÓQiOOj FIG. 18 is a message flow diagram 1800 illustrating a fifth example of RRC messages 1804 used for on-demand authentication of serving network 1704 via eNodeB 1708. The UE 1702 may initiate an AKA1802 procedure, The UE 1702 may receive service network certificate integrity information 1704 from the HSS 1706 during or after the AKA 1802 procedure, After successful completion of the AKA 1802 procedure, the UE 1702 may authenticate the serving network 1704 using the RRC messages 1804. An RRC connection request 1810 may be used, for example, during transitions from the idle mode. When a UE 1702 goes to sleep mode, the eNodeB 1708 may leave the security context for the UE 1702 for power saving reasons. In accordance with certain aspects, the UE 1702 may transmit an RRC connection request 1810 that includes additional fields. The additional fields may include a Nonce value and a request for the signature of the eNodeB 1708. In some cases, the additional fields may also include a request for the public key of the eNodeB 1708. The Nonce value may be an arbitrary, random, or pseudo-random number used to ensure that previous communications cannot be reused in replay attacks. The eNodeB 1708 may transmit a response 1812 that is signed using its private key and, after verification of the authenticity of the eNodeB 1708. the UE 1702 may signal a complete RRC connection setup 1814.

[00110] The UE 1702 can retrieve 1806 the current Certificate Integrity information of the serving network 1704 from the CertOb 1714. The UE 1702 can then verify 29 that the integrity information of the! certificate acts! is the same as the current certificate integrity information supplied by the HSS 1706, If the current certificate integrity information of the serving network is different from the integrity information of the ! certificate supplied by the HSS 1706 during the initial bonding, e! UE 1702 verifies the network function certificate of the eNodeB 1700, for example, by consulting 1808 of the CSF 1712.

[00111] FIG. 19 is a message flow diagram 1900 illustrating a sixth example of RRC messages 1904 used for on-demand authentication of serving network 1704 via eNodeB 1708. UE 1702 may initiate an AKA procedure 1902, UE 1702 may receive service network certificate integrity information 1704 from the HSS 1706 during or after the AKA 1802 procedure. After successfully completing the AKA procedure 1902, the UE 1702 may authenticate the serving network 1704 using the RRC messages 1904. An RRC connection reset request 1910 may be used, for example, during connection failure recovery. In accordance with certain aspects, the UE 1702 may transmit an RRC connection reset request 1910 that includes additional fields. The additional fields may include a Nonce and a request for the signature of the eNodeB 1708. In some cases, the additional fields may also include a request for the public key of the eNodeB 1708, and the eNodeB 1708 may transmit a 1912 response that is signed using its private key and, after verifying the authenticity of the eNodeB 1708, the UE 1702 may indicate the complete RRC connection setup 1914.

[00112] The UE 1702 can retrieve 1906 the current certificate integrity information of the serving network 1704 from it CertOb 1714, The UE 1702 may then verify that the current certificate integrity information is the same as the Certificate Integrity information supplied by the HSS 1706 If the current certificate integrity information of the serving network is different from the certificate integrity information of the current certificate provided by the HSS 1706 during the initial join, the UE 1702 verifies the network function certificate of the eNodeB 1708 by, for example, querying 1908 the CSF 1712.

[00113] The UE 1702 may authenticate the serving network 1704 using RRC messages as necessary when there is data to be transmitted, received, or before or after a handover to another network function. RRC connect/reset requests are initiated by the UE 1702 and such requests 30 require a response from the eNodeB 1708. In some cases, the UE 1702 may determine that it is not necessary to continually authenticate the serving network 1704. For example, authentication is not required when the UE 1702 is in an idle state and no handover is indicated. The overhead associated with the baseline protocol can be minimized when signatures are provided on demand. The eNodeB 1708 normally provides the network function certificate only after the request.

[60114] FIG. 20 is a flow diagram of messages 2000 illustrating a third example of TAU messages 2004 used for on-demand authentication of the serving network via MME 1710. UE 1702 may initiate an AKA procedure 2002. UE 1702 may receive service network certificate integrity information 1704 from the HSS 1706 during or after the AKA 2002 procedure. After successfully completing the AKA procedure 2002, the UE 1702 may authenticate the serving network 1704 using TAU messages. A TAU 1210 request can be used, for example, during periodic registration or after a handover. In accordance with certain aspects, the UE 1702 may transmit the TAU request 2010 with additional fields that may include a Nonce value and a request to sign the MME 1710. In some cases, the additional fields may also include a request for the public key of the MME 1710. The MME 1710 may transmit a response 2012 that is signed using its private key and, upon verification of the authenticity of the MME 1710, the UE 1702 can indicate the complete RRC connection configuration 2014.

[00115] The UE 1702 may retrieve 2006 the current certificate integrity information of the serving network 1704 from the CertOb 1714. The UE 1702 may then verify that the current certificate integrity information is the same as the certificate integrity information supplied by the HSS 1706 If the current certificate integrity information of the serving network is different from the certificate integrity information of the certificate supplied by the HSS 1706 during the initial connection, the UE 1702 verifies the network function certificate of the MME 1710 eg by querying the 2008 CSF 1712

Additional descriptions of certain aspects

[00116] FIG. 21 is a conceptual diagram 2100 illustrating a simplified example of a hardware implementation for an apparatus employing a processing circuit 31 2102 that may be configured to perform one or more functions described herein. In accordance with various aspects of the description, an element, or any part of an element, or any combination of elements as described herein, may be implemented using processing circuitry 2102. Processing circuitry 2102 may include one Or more 2104 processors that are controlled by some combination of hardware and software modules. Examples of 2104 processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, sequencers, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this description. One or more processors 2104 may include specialized processors that perform specific functions and which may be configured, augmented, or controlled by one of the software modules 2116. One or more processors 2104 may be configured through a combination of software modules 2116 loaded during initialization and further configure by uploading or downloading one or more 2116 software modules during operation.

[00117] In the illustrated example, processing circuit 2102 may be implemented with a bus architecture, generally represented by bus 2110. Bus 2110 may include any number of interconnecting buses and bridges according to the specific application of the circuit. processing 2102 and the general limitations of the design. Bus 2110 links various circuits including one or more processors 2104 and storage 2106. Storage 2106 may include memory devices and mass storage devices, and may be referred to herein as computer-readable media and/or processor-readable media. The 2110 bus can also link various other circuits such as timing sources, timers, peripherals, voltage regulators, and power management circuits. A bus interface 2108 may provide an interface between the bus 2110 and one or more transceivers 2112. A transceiver 2112 may be provided for each network technology supported by the processing circuitry. In some cases, multiple network technologies may share some or all of the processing circuitry or modules found in a 2112 transceiver. Each transceiver 2112 provides a means to communicate with various other devices over a transmission medium. Depending on the nature of the device, a user interface 2118 may also be provided (eg, keyboard, display, speaker, microphone, joystick). and can be communicatively coupled to the 2110 bus directly or through the 2108 bus interface>

[00118] A processor 2104 may be responsible for managing the bus 2110 and for general processing which may include the execution of software stored on a computer readable medium which may include storage 2106. In this regard, the processing circuit 2102, which includes processor 2104, may be used to implement any of the methods, functions, and techniques described herein. Storage 2106 may be used to store data that is manipulated by processor 2104 when software is executed, and the software may be configured to implement any of the methods described herein. [00119] One or more processors 2104 in processing circuitry 2102 may execute software. The software may reside in computer-readable form on storage 2106 or on external computer-readable media. The external computer readable medium and/or storage 2106 may include a non-transient computer readable medium. A non-transient computer-readable medium includes, but is not limited to, a magnetic storage device (for example, hard drive, floppy disk, magnetic stripe), an optical disc (for example, a CD or a DVD), a smart card, a flash memory device (for example, a “flash drive”, a card, a pen or a USB key), RAM, ROM, PROM. EPROM, EEPROM. a registry, a removable disk, and any other suitable medium for storing software and/or instructions that can be accessed and read by a computer. Computer readable medium and/or storage 2106 may also include, by way of example, a carrier wave, a transmission line, and any other means suitable for transmitting software and/or instructions that can be accessed and read by a computer. . Media and/or computer-readable storage 2106 may reside in processing circuitry 2102, in processor 2104, external to processing circuitry 2102, or distributed across multiple entities including processing circuitry 2102. The medium and/or or computer readable storage 2106 may be embedded in a computer program product. By way of example, a computer program product may include a computer-readable medium in packaging materials. Those skilled in the art will recognize the best way to implement the described functionality presented throughout this description according to the particular application and the general design constraints imposed on the overall system.

[00120J Storage 2106 may hold software maintained and/or organized into loadable code segments, modules, applications, programs, etc., which may be referred to herein as software modules 2116. Each of the software modules 2116 may include instructions and data that, when installed or loaded into processing circuitry 2102 and executed by one or more processors 2104, contribute to a runtime image 2114 that controls the operation of one processor. or more 2104 processors. When executed, certain instructions may cause processing circuitry 2102 to perform functions in accordance with certain methods, algorithms, and processes described herein.

[00121] Some of the software modules 2116 may be loaded during the initialization of the processing circuit 2102, and these software modules 2116 may configure the processing circuit 2102 to enable performance of the various functions described herein. For example, some software modules 2116 may configure internal devices and/or logic circuits 2122 of processor 2104 and may manage access to external devices such as transceiver 2112, bus interface 2108, user interface 2118, timers, coprocessors math, and the like. Software modules 2116 may include a control program and/or an operating system that interacts with interrupt handlers and device drivers, and controls access to various resources provided by processing circuitry 2102. Resources may include memory, processing time, access to transceiver 2112, user interface 2118, and the like.

P0122] One or more processors 2164 of processing circuitry 2102 may be multifunctional, whereby some of the software modules 2116 are loaded and configured to perform different functions or different instances of the same function. One or more processors 2104 may additionally be adapted to handle background tasks initiated in response to input from, for example, the User Interface 2118, transceiver 2112, and device drivers. To support performing multiple functions, one or more processors 2104 may be configured to provide a multitasking environment, whereby each of a plurality of functions is implemented as a set of tasks that are performed by one or more processors 2104 depending on is necessary or desired. In one example, the multitasking environment may be implemented using a timesharing program 2120 that passes control of one processor 2104 between different tasks, whereby each task returns control of one or more processors 2104 to the timesharing program 2120 once. upon completion of pending operations and/or in response to input such as an interrupt. When a task is in control of one or more processors 2104, the processing circuitry is effectively specialized for the purposes directed by the function associated with the controlling task. The timesharing program 2120 may include an operating system, a main loop that transfers control on a round-robin basis, a function that: assigns control to one or more processors 2104 according to a prioritization of functions, and/or an interrupt-driven main loop that responds to external events by providing control of one or more processors 2104 to a handling function.

[00123] The following flowcharts illustrate methods and processes carried out or operating on elements of r0d adapted or configured in accordance with certain aspects described herein. The methods and processes can be implemented on any suitable network technology, including 3G, 4G, and 5G technologies, to name just a few. Therefore, the claims are not limited to a single network technology. In this regard, it can be understood that a reference to a "UE" also includes a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a mobile telephone, a user agent, a mobile client, a client, or any other suitable terminology. A reference to an "eNodeB" may be understood to refer to a base station, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set, an extended service set or some other suitable terminology. A reference to an MME may also refer to an entity acting as an authenticator in the serving network and/or a primary service management node, such as, for example, a Mobile Switching Center. A reference to HSS may also refer to a database containing information related to the user and the subscriber providing support functions in mobility management, call and session setup, and/or user authentication and access authorization. , including, for example, Home Location Registry (HLR), Authentication Center (AüC), and/or an Authentication, Authorization, and Accounting (AAA) server.

[00124] FIG. 22 is a flowchart 2200 of a method of securing wireless communication between a UE and a serving network.

[00125] At block 2202, the UE may transmit a connection request or tracking area request to a network function in a serving network after a security association between the UE and the serving network has been established. . The request may include a nonce value and a signature request. The request sent to the serving network may be sent while the UE is transitioning from an idle mode or after such transition from idle mode. In some cases, the request sent to the serving network may be an RRC message. The RRC message may be an RRC connection request, an RRC connection re-establishment request, and/or an RRC reconfiguration complete message. In some cases, the request sent to the serving network may be a TAU request.

[0M2S] At block 2204, the UE may receive a response to the connection request or tracking area request from the network function. The response may include a network function signature.

[00127] In block 2206, the UE can authenticate the serving network based on the signature of the network function and a public key certificate corresponding to the network function-B public key certificate can be signed using a private key of the service network provided by a network operator associated with the service network. The UE may maintain a list of trusted networks that identifies the public keys or certificate of public keys corresponding to the trusted networks. The UE may authenticate the serving network by using the list of trusted networks to verify the public key. of the network function and the signature generated by the network function. The service network can be authenticated using a trusted third party to verify the public key certificate corresponding to the network function.

[00128] In some examples, a request for certificate integrity information may be transmitted to the network, and first certificate integrity information received in a response from the network may be verified using second certificate integrity information received from a home subscriber server. The certificate integrity information request may include an identifier of a certificate observatory 36 (such as CertOb 1714 of FIG, 17) corresponding to the second certificate integrity information. The CertOb 1714 can be configured to maintain the integrity of a set of certificates for a network. The CertOb 1714 identifier can be an IP address or URL. The first Certificate Integrity Information can be verified by authenticating a response to the Certificate Integrity Information request using a public key of the CertOb 1714. In some cases, the first certificate integrity information may be verified by comparing the first certificate integrity information with the second certificate integrity information, sending a certificate status request to a CSF 1712 when a certificate is determined. difference between the first Certificate Integrity Information and the second Certificate Integrity Information, and verifying the status of a network function certificate based on a response from the CSF 1712. The certificate status request may include first identification information identifying the network function, second identification information identifying the network function certificate, network function, and a version number of the network function certificate. A response from the CSF 1712 may include a certificate status response that includes the status of the network function certificate, a network public key, and a signature of the certificate status response created by the CSF 1712 using a network private key. Verification of the certificate status response can be performed using the public key of the network.

[00129] FIG. 23 is a diagram illustrating a simplified example of a hardware implementation for apparatus 2300 employing processing circuitry 2302. The processing circuit typically has a processor 2316 which may include one or more of a microprocessor, microcontroller, digital signal processor, a sequencer, and a state machine. The processing circuit 2320 may be implemented with a bus architecture, represented generally by bus 2310. Bus 2310 may include any number of interconnect buses and bridges according to the specific application of processing circuit 2302 and general design constraints. Bus 2320 links various circuits including one or more processors 2104 and/or hardware modules, represented by processor 2316, modules or circuits 2304, 2306, and 2308, a wireless transceiver 2312 adapted to communicate via an antenna 2314, and the 2318 computer-readable storage medium. Bus 2320 may also link various other circuits such as timing supplies, peripherals, voltage regulators, and power management circuitry, which are well known in the art and, therefore, will not be described further.

[00130] Processor 2316 is responsible for general processing, including execution of software stored on computer-readable storage medium 2318. The software, when executed by processor 2316, causes processing circuitry 2302 to perform the various functions described above for any particular apparatus. Computer-readable storage medium 2318 may also be used to store data that is manipulated by processor 2316 when executing software, including data decoded from symbols transmitted by antenna 2314, which may be configured as data lanes and clock rails. Processing circuit 2302 further includes at least one of modules 2304, 2306 and 2308. Modules 2304, 2306, and 2308 may be software modules running on processor 2316, resident/stored on computer-readable storage medium 2318, one or more hardware modules coupled to processor 2316, or some combination of these. Modules 2304, 2306, and/or 2308 may include microcontroller instructions, state machine configuration parameters, or some combination of these.

[00131] In one configuration, the device 2300 for wireless communication includes a module and/or circuit 2304 that is configured to authenticate and/or secure a connection to a home network, a module and/or circuit 2306 that is configured to authenticate a service network and a module and/or circuit 2308 that is configured to transmit and receive messages to the service network.

[00132] In one example, wireless transceiver 2312 may be configured to transmit messages to a wireless base station in the serving network and to receive messages from the wireless base station. The module and/or circuit 2304 may include means for establishing a secure connection between the appliance and a home network. The authenticated connection can be established in response to a first authentication message transmitted through the wireless transceiver ai HSS. After the secure connection is established and before a second authentication request is transmitted to the HSS of the home network, the modules and/or circuits 2308. 2312 may include means for transmitting a request to a network function on the home network. service, the request having a nance value and a signature request attached to it, and receiving a response to the request from the network function, where the response includes a signature from the network function. The module and/or circuit 2306 may include means to authenticate the service network based on the signature of the network function and a public key certificate corresponding to the network function and signed by a network operator. The public key certificate corresponding to the network function may be included in a list of trusted networks and their respective public key certificates maintained by the apparatus.

[00133] Modules and/or circuits 2308, 2312 may include means for transmitting a request for certificate integrity information to the network, and module and/or circuit 2306 may include means for verifying the first received certificate integrity from the network using the second certificate integrity information received from the HSS. The certificate integrity information request includes an identifier of a CertOb 1714 corresponding to the second certificate integrity information. The CertOb 1714 can be configured to maintain the integrity of a set of certificates for a network.

[0Θ134] Module and/or circuit 2306 may be configured to compare the first certificate integrity information with the second certificate integrity information, cause modules and/or circuits 2308, 2312 to send a certificate status request to a CSF 1712 when a difference between the first certificate integrity information and the second certificate integrity information is determined, and verify the status of a network function certificate based on a response from the CSF 1712. The certificate status request may include a network function identifier, a network function certificate identifier, and a certificate number. version of the network function certificate.

[QC13S] FIG. 24 is a flowchart 2400 of a method of demonstrating membership of a service network. The method can be performed by a network node (or network function) of a service network.

[δδ138] At block 2202, the network node may receive a first message from the UE after the UE has established a secure connection with a home network. The message may be directed to a network function of the serving network. The message can include a nonce value and a signature request,

[00137] At block 2204, the network node may generate a signature using an operator-signed certificate maintained by the network function of the serving network. The operator-signed certificate may be an operator-signed public-key certificate. of the service network. A private key corresponding to the operator signed certificate 39 may be maintained in a secure storage or execution environment and/or in a trusted environment.

[00138] At block 2206, the network node may transmit a second message to the UE. The signature can be attached to the second message,

[00139] In some examples, the signature includes a MAC created using a shared session key between the UE and the network function. A symmetric cipher can be used to sign the second response of the message.

[00140] In some cases, the network node can be an MME and the session key can be a Kasme- The MME can receive the Kasme from an HSS in an encrypted message using a public key of the MME, decrypt the Kasme using a private key stored in a trusted environment, and store the decrypted Kasme in the trusted environment. The authentication request can be received in a TAU request.

[00141] In some cases, the network node may be an eNodeB and the session key may be a KeNB. The eNodeB may receive the KeNB from an MME in an encrypted message using a public key from the eNodeB, decrypt the KeNB using a private key stored in a trusted environment, and store the decrypted KeNB in ​​a trusted environment. The first message may be a radio resource control (RRC) message and the second message may be a response to the RRC message. For examples, the RRC message may be an RRC connection establishment request, an RRC connection reestablishment request, or an RRC reconfiguration complete message.

[00142] In some examples, the signature includes a digital signature created using a private key of the network node. An asymmetric cipher can be used to sign the authentication response. The private key of the network node can be stored in a trusted environment and the signature is created within the trusted environment,

[00143] FIG. 25 is a diagram illustrating a simplified example of a hardware implementation for a 2500 appliance employing a 2502" processing circuitry The processing circuitry typically has a 2516 processor which may include one or more of a microprocessor, microcontroller, digital signal processor , a sequencer, and a state machine, The 2502 processing circuit can be implemented with a bus architecture, generally represented by the 2520 bus. Bus 2520 may include any number of interconnect buses and jumpers according to the specific application of processing circuitry 2502 and general design constraints. Bus 2520 links several circuits including one or more processors and/or hardware modules, represented by processor 2516, modules or circuits 2504, 2506, and 2508, a wireless transceiver 2512 adapted to communicate via an antenna 2514, and the 2518 computer readable storage medium. Bus 2520 may also link various other circuitry such as timing sources, peripherals, voltage regulators, and power management circuitry, which are well known in the art and therefore will not be described further.

[80144] The 2616 processor is responsible for general processing, including the execution of software stored on the 2518 computer-readable storage medium. The software, when executed by the 2516 processor, causes the 2302 processing circuitry to perform the various functions described above for any particular apparatus. Computer-readable storage medium 2518 may also be used to store data that is manipulated by processor 2516 when executing software, including data decoded from symbols transmitted by antenna 2514, which may be configured as data lanes and clock rails. Processing circuit 2302 further includes at least one of modules 2504, 2506, and 2508. Modules 2504, 2506, and 2508 may be software modules running on processor 2516, resident/stored on computer-readable storage medium 2518, one or more hardware modules coupled to processor 2516, or some combination of these. Modules 2504, 2506, and/or 2508 may include microcontroller instructions, state machine configuration parameters, or some combination of these.

[00145] In one configuration, the apparatus 2500 for wireless communication includes a module and/or circuit 2504 that is configured to generate authentication signatures, a module and/or circuit 2506 that is configured to transmit messages to a UE, and a module and/or circuit 2508 that is configured to receive messages from a UE,

[00146] In one example, module and/or circuit 2508 may provide a means of receiving a first message from a UE after the UE has established a secure connection with a home network. The message may be directed to a network function of the serving network and includes a nonce value and a signature request, module and/or circuit 2504 may provide a means of generating a signature using an operator-signed certificate maintained by the network. network function of the serving network, and the module and/or circuit 2506 may provide a means to transmit a second message to the UE, 41 where the signature may be attached to the second message, The signature attached to the second message may be generated to prove to the UE that the handset 2500 is a member of a serving network. The operator-signed certificate can: be a public key certificate signed by a service network operator.

[00147] In some examples, the network node is an eNodeB, the first message is an RRC message, and the second message is a response to the RRC message.

[00148] In some examples, the network node is an MME, and the authentication request is received in a TAU request.

[QQ14S] It is understood that the specific order or hierarchy of the steps in the processes described is an illustration of exemplary approaches. Based on design preferences, it is understood that the specific order or hierarchy of specific steps in the processes can be rearranged. Also, some stages can be combined or omitted. The appended method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[OOI 50] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Therefore, the claims are not to be considered limited to the aspects shown herein, but the full scope consistent with the language claims should be accorded, where reference to an element in the singular is not intended to mean one and only one" unless specifically indicated in this way, but rather one or more”. Unless otherwise specified, the term 'some *' refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this description that are known or later become known to those skilled in the art are hereby expressly incorporated by reference and are intended to be embraced. for the claims. Furthermore, nothing set forth herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element shall be construed as a further function of means unless the element is expressly recited using the phrase means to.