WO2018183943A1 - Methods and apparatus for initializing a secure network connection - Google Patents

Abstract

Improved methods and apparatus for initializing a secure network link between two or more network nodes are disclosed. In an exemplary embodiment, the two or more network nodes comprise a user equipment (for example, end-user devices) and a Wi-Fi access point (AP) configured to connect the user equipment to a Long Term Evolution (LTE) core network. A LTE Mobility Management Entity (MME) sends a Non-Access Stratum (NAS) Security Mode Command to the UE via the Wi-Fi AP. The UE and the AP can each independently derive a shared secret based on the NAS Security Mode Command. The shared secret is used as a pre-shared key (PSK) for subsequent Internet Protocol Security (IPsec) and Internet Key Exchange (IKE) transactions.

Description

METHODS AND APPARATUS FOR INITIALIZING A SECURE NETWORK

CONNECTION

Priority Application

This application claims priority to co-pending U.S. Patent Application Serial No. 15/940,857 filed on March 29, 2018, which claims priority to U.S. Provisional Patent Application Serial No. 62/479,121 filed on March 30, 2017 and entitled "METHODS AND APPARATUS FOR INITIALIZING A SECURE NETWORK CONNECTION", each of the foregoing being incorporated herein by reference in its entirety.

Related Applications

This application is related to co-owned and co-pending U.S. Provisional Patent

Application Serial No. 62/437,587 entitled "METHODS AND APPARATUS FOR AGGREGATING NETWORK ACCESS WITHIN A SINGLE UNIFIED PLATFORM FOR A MYRIAD OF DEVICES", filed December 21, 2016, co-owned and co-pending U.S. Provisional Patent Application Serial No. 62/442,848 entitled "METHODS AND APPARATUS FOR AGGREGATING NETWORK ACCESS WITHIN A SINGLE UNIFIED PLATFORM FOR A MYRIAD OF DEVICES", filed January 5, 2017, co-owned and co-pending U.S. Patent Application Serial No. 14/863,239 entitled "METHODS AND APPARATUS FOR HYBRID ACCESS TO A CORE NETWORK BASED ON PROXIED AUTHENTICATION", filed September 23, 2015, and co-owned U.S. Patent Application Serial No. 14/156,339 entitled "METHODS AND APPARATUS FOR HYBRID ACCESS TO A CORE NETWORK", filed January 15, 2014, each of the foregoing being incorporated herein by reference in its entirety. Copyright

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

Background

1. Field of Invention

The present invention relates generally to the field of network security. More particularly, in one exemplary aspect, the disclosure is directed to methods and apparatus for initializing a secure network connection. 2. Description of Related Technology

Internet Protocol (IP) is a networking protocol used for computer communication that is in widespread use by organizations and consumers alike (e.g., user equipment, user devices). To provide secure communications within an IP network, an additional network protocol suite, known as Internet Protocol Security (IPsec), is used to authenticate and encrypt data sent over a network. Standards information about IPsec is documented in a series of Requests for Comments (RFCs) by the Intemet Engineering Task Force (IETF), with the overall IPsec implementation being captured by "Security Architecture for the Intemet Protocol," RFC 2401, available at http:/ywwvv.rfc-base.org/rfc-2401.h.tm¾ (last accessed March 23, 2017), and incorporated herein by reference in its entirety.

Generally, the IPsec protocol suite is capable of mutually authenticating a pair of network nodes, as well as encrypting and authenticating the exchanges between them. IPsec includes protocols for establishing mutual authentication between the nodes at the start of the session and facilitating generation and/or exchange of cryptographic keys during a session. IPsec protocol nodes can be a pair of hosts (host- to-host communication), a pair of security gateways (network-to-network communication), or a security gateway and a host (network-to-host communication). IPsec uses cryptographic security services to protect communications over IP networks, and supports network-level peer authentication, data-origin authentication, data integrity, data confidentiality (e.g., via encryption), and replay protection.

Internet Key Exchange (IKE) is a protocol used to set up a security association in the IPsec protocol suite. Existing IPsec uses IKE (which is further versioned into: IKEvl or IKEv2) to handle negotiation of protocols and algorithms based on the local policy. IKE may also be used to generate encryption and authentication keys to be used by IPsec. By providing authentication of peers, IKE negotiates the security associations in IPsec, and establishes IPsec keys.

Although IPsec has been successfully used to provide secure communications in computer networks, there are a number of weaknesses that can be exploited by a hacker. For example, it has been reported that a so-called "Logjam" attack on widely used Diffie-Hellman keys could threaten 66% of virtual private network (VPN) servers, 18% of the top million HTTPS (Hypertext Transfer Protocol Secured) domains, and 26% of Secure Shell (SSH) servers. IPsec is also reported to be vulnerable to Man-in-the-Middle (MITM) attacks, where the identity of an intermediary node is compromised between two endpoints. Other configurations such as Rivest-Shamir-Adelman (RSA) algorithms also suffer from vulnerabilities such as false X.509 certificates, and dictionary or brute-force attacks using EAP-MSCHAP (Extensible Authentication Protocol, Microsoft Challenge Handshake Authentication Protocol) for authentication. Perhaps the most secure mode of IPsec authentication schemes is via pre-shared key (PSK), where no request for key exchange is required for authentication. However, even under such scenarios, if a more robust authentication such as Extensible Authentication Protocol - Authentication and Key Agreement (EAP-AKA) is not also used, then PSK authentication is vulnerable to security breaches, as PSKs are static (i.e., they never change) and are kept in a file (such as within a "ipsec. secrets" file) that can be viewed by a third party with root access (e.g., a technician or IT personnel).

Given the widespread use of IP networks (e.g., using wireless devices and corporate networks) and concern for security by consumers, these weaknesses pose a challenge to service providers. Hence, improvements are needed to the IPsec protocol suite that overcome the aforementioned security vulnerabilities of IKE.

Summary

The present disclosure satisfies the aforementioned needs by providing, inter alia, improved apparatus and methods for initializing a secure network connection.

In one aspect of the present disclosure, a method for initializing a secure connection within a network is disclosed. In another aspect of the present disclosure, a non-transitory computer-readable medium is disclosed.

In another aspect of the present disclosure, an apparatus configured to initialize a secure connection within a network is disclosed.

In another aspect of the present disclosure, a wireless access point is disclosed.

In another aspect of the present disclosure, a user equipment in communication with a secure network is disclosed.

Other features and advantages of the present invention will immediately be recognized by persons of ordinary skill in the art with reference to the attached drawings and detailed description of exemplary embodiments as given below.

Brief Description of the Drawings

FIG. 1A is a flow diagram of a security association set up in Internet Protocol Security (IPsec) using Internet Key Exchange (IKE), illustrative of the prior art.

FIG. IB is a flow diagram of an Internet Key Exchange (IKE) protocol using an Extensible Authentication Protocol (EAP) protocol, illustrative of the prior art.

FIG. 2A is a block diagram of an exemplary network architecture comprising a Wi-Fi access point in communication with an exemplary user equipment (UE) using an exemplary stack arrangement, in accordance with the principles described herein.

FIG. 2B is a block diagram of an exemplary network architecture comprising a gateway apparatus in communication with an exemplary user equipment (UE) via a wireline Ethernet link using an exemplary stack arrangement, in accordance with the principles described herein.

FIG. 3 is a flow diagram of an exemplary exchange of authentication messages useful in conjunction with the exemplary wireline system depicted in FIG. 2B.

FIG. 4A is a block diagram of an exemplary user equipment (UE), in accordance with the principles described herein.

FIG. 4B is a block diagram of an exemplary Internet Protocol Security (IPsec) tunnel for data that is encrypted by an exemplary user equipment (UE) agent, in accordance with the principles described herein. Detailed Description of the Invention

Reference is now made to the drawings, wherein like numerals refer to like parts throughout.

As used herein, the term "access point" refers generally and without limitation to a network node which enables communication between a user or client device and another entity within a network, such as for example a Wi-Fi AP, or a Wi-Fi-Direct enabled device acting as a Group Owner (GO).

As used herein, the terms "Internet" and "internet" are used interchangeably to refer to inter-networks including, without limitation, the Internet. Other common examples include but are not limited to: a network of external servers, "cloud" entities (such as memory or storage not local to a device, storage generally accessible at any time via a network connection, and the like), service nodes, access points, controller devices, client devices, etc.

As used herein, the term "network" refers generally to any type of data, telecommunications or other network including, without limitation, data networks (including MANs, PANs, WANs, LANs, WLANs, micronets, piconets, internets, and intranets), satellite networks, cellular networks, and telco networks.

As used herein, the term "user equipment" refers to an end-user device that provides data services to a user. Common examples of user equipment include without limitation: smartphones, laptop computers, mobile devices with wireless capabilities.

As used herein, the term "Wi-Fi" refers to, without limitation and as applicable, any of the variants of IEEE-Std. 802.11 or related standards including 802.11 a/b/g/n/s/v/ac or 802.11-2012/2013, as well as Wi-Fi Direct (including inter alia, the "Wi-Fi Peer-to-Peer (P2P) Specification", incorporated herein by reference in its entirety).

As used herein, the term "wireless" means any wireless signal, data, communication, or other interface including without limitation Wi-Fi (IEEE 802.11 and its derivatives such as "b", "a", "g", "n", "ac", etc.), Bluetooth, 3G (e.g., 3 GPP, 3GPP2, and UMTS), 4G (LTE, LTE-A, WiMax), HSDPA/HSUPA, TDMA, CDMA (e.g., IS-95A, WCDMA, etc.), FHSS, DSSS, GSM, PAN/802.15, WiMAX (802.16), 802.20, narrowband/FDMA, OFDM, PCS/DCS, analog cellular, CDPD, satellite systems, millimeter wave or microwave systems, acoustic, and infrared (i.e., IrDA). Overview

Improved methods and apparatus are disclosed for initializing a secure network link between nodes (e.g., a user equipment (UE) and a Wi-Fi access point (AP)) in an IPsec context. In one exemplary embodiment of the present disclosure, a user equipment (e.g., a smartphone, laptop computer, or other mobile device with wireless capabilities) is connected to a cellular core network (such as for e.g., Long Term Evolution (LTE)) via a Wi-Fi access point (AP). The UE, AP, and an MME (Mobility Management Entity) of the core network enable a secure link between the UE and AP using e.g., an IKE protocol (to provide encryption and authentication for IPsec). In other embodiments, the UE and a gateway apparatus may be in communication via a wired access (e.g., Ethernet). The various aspects of the present disclosure may be used with virtually any connectivity protocol.

In one exemplary embodiment, the UE and AP authenticate each other by leveraging LTE authentication information. So-called non-access stratum (NAS) Security Mode Setup procedures are performed after successful authentication. During the NAS Security Mode Setup, the LTE Mobility Management Entity (MME) sends a first key to the UE through the AP; the first key is a shared secret key that encrypts packets exchanged between the UE and AP. An IKE security association is set up after successfully completing the NAS security mode setup, during which the MME transfers a second key to the AP (which is functionally treated as an eNB). This second key is an eNB (evolved NodeB) key that may be used to provide a secure bidirectional communication link to transmit encrypted packets into the core network. In some implementations, the IKE security association must successfully complete before LTE authentication in order to protect against e.g., third-party eavesdropping of private information, such as a globally unique identifier (e.g., International Mobile Subscriber Identity (IMSI)) that is stored on user equipment (UEs) of the LTE network.

These and other mechanisms disclosed herein are configured to, inter alia, increase security and reduce vulnerabilities present within current IPsec systems. Various other advantages of the disclosed embodiments are described in greater detail hereinafter. Detailed Description of Exemplary Embodiments

Exemplary embodiments of the present disclosure are now described in detail. While these embodiments are primarily discussed in the context of a fourth generation Long Term Evolution (4G LTE) wireless network in combination with an Institute of Electrical and Electronics Engineers (IEEE) 802.11 and/or IEEE 802.3 network, it will be recognized by those of ordinary skill that the present invention is not so limited. In fact, the various aspects of the disclosure are useful in any hybrid network that can support the initialization schemes described herein.

Other features and advantages of the present disclosure will immediately be recognized by persons of ordinary skill in the art with reference to the attached drawings and detailed description of exemplary embodiments as given below.

Existing Internet Protocol Security (IPsec) using Internet Key Exchange (IKE) -

FIG. 1A is a flow diagram of a setup of a security association in Internet Protocol Security (IPsec) using Internet Key Exchange (IKE). The illustrated IKE implementation corresponds to IKEv2 defined in e.g., RFC 7296, entitled "Internet Key Exchange Protocol Version 2 (IKEv2)," available at http://www.rfc-base.org/rfc- 7296.html (last accessed March 29, 2017) and incorporated herein by reference in its entirety. As previously noted, other embodiments may use IKEvl to negotiate the security associations in IPsec. As shown, the transaction includes four (4) messages to set up a security association by IKEv2 in two (2) phases.

As shown, the first phase includes a IKE SA INIT request and a IKE_SA_INIT response (messages 1 and 2) that initiates the security association between an IKEv2 initiator (e.g., a user equipment (UE)) and an IKEv2 responder (e.g., a Wi-Fi access point (AP) or a gateway). The initiator may comprise an end-user communication device e.g., smartphone, laptop computer, or other mobile device with wireless capabilities. The responder may comprise an access point or other gateway device.

The first phase uses unencrypted messages for negotiating and selecting parameters for the security association. For instance, these messages may contain a message authentication algorithm (e.g. HMAC-MD5-96 or HMAC-SHA256), a pseudo-random function for key generation (e.g. HMAC-MD5 or HMAC-SHA1), an encryption algorithm (e.g. DES, 3DES or AES), and/or Diffie-Hellman (D-H) group information (e.g., group 1, group 2, group 5 or group 14). The first phase may also include a Diffie-Hellman Key Exchange, where the IKEv2 initiator and responder together create an encryption key based on a shared secret number which is then used to encrypt traffic exchanged between the initiator and responder (e.g., between UE and AP). Other information such as nonce numbers may also be exchanged.

The second phase includes an IKE AUTH Request message and an IKE AUTH Response message (messages 3 and 4) that are used for mutual authentication of the initiator and responder nodes. In one embodiment, the authentication may be a certificate-based authentication e.g., using Rivest-Shamir- Adelman (RSA) algorithms. In another variant, the second phase is a key-based authentication e.g., using a pre-shared key (PSK).

While the illustrated IKEv2 scheme of FIG. 1A may be performed via, inter alia, RSA and PSK authentication methods, some alternative implementations use a more robust authentication, such as the Extensible Authentication Protocol - Authentication and Key Agreement (EAP-AKA). Existing AKA (and EAP-AK) is based on a Universal Subscriber Identity Module (USIM) for authentication and key generation and is generally believed to offer better security when compared to non- SIM based techniques. Moreover, AKA has a long history of successful use in e.g., 3 GPP LTE (Long Term Evolution), and EAP-AKA is also commonly used with Wi- Fi Hotspot 2.0 deployments. FIG. IB shows one such flow diagram of an IKEv2 protocol that has been modified for use with an Extensible Authentication Protocol (EAP) protocol. The initial two (2) IKEv2 messages are performed in the same manner as the first phase as discussed above with reference to FIG. 1A; however, the second phase is modified for EAP protocol operation. As shown, the IKE AUTH Request (message 3) indicates the preferred authentication method to be based on EAP by sending an "EAP ONLY AUTHENTICATION" option notification. In response to the EAP_ONLY_AUTHENTICATION message option, the responder (e.g., a Wi-Fi AP or a gateway) initiates an EAP messaging sequence by transmitting an "EAP (Request)" message. The initiator and responder negotiate the EAP protocol according to e.g., RFC 5998 entitled "An Extension for EAP-Only Authentication in IKEv2," available at http://www.rfc-base.org/rfc-5998.html (last accessed March 29, 2017) and incorporated herein by reference in its entirety. When the EAP protocol has succeeded in establishing a security association, the responder transmits an "EAP(Success)" message.

Some EAP-AKA implementations may use pre-shared keys that are mutually generated by the AKA protocol for authentication. Artisans of ordinary skill in the art will appreciate, given the contents of the present disclosure, that EAP-AKA authentication for IPsec may be advantageous because the generated pre-shared keys are "dynamically" generated each time, and thus are not accessible in a file as opposed to the aforementioned "static" PSK credential and keys. Moreover, while the aforementioned RFC 5998 scheme is the Internet Engineering Task Force (IETF) recommended solution, other EAP authentication protocols modified for IKEv2 may be used with equal success.

Exemplary Secure Initialization Protocol -

Various solutions for overcoming the security vulnerabilities of IKE and/or IPsec are presented herein. While the described solutions are presented within the context of hybrid networks that enable a user equipment (UE) to access a cellular core network via e.g., a Wi-Fi access point (AP) and/or a gateway apparatus, those of ordinary skill in the related arts will readily appreciate that the described solutions are broadly applicable to other hybrid and/or monolithic networks, the following being purely illustrative.

As an aside, methods and apparatus for hybrid access to a network, such as a core network, as well as methods and apparatus for using an arbitrary access technology such as Wi-Fi, Bluetooth, or even wireline access technologies such as Ethernet, to attach and connect a user device (e.g., a smartphone) to an LTE Evolved Packet Core (EPC), are described in, e.g., co-owned U.S. Patent Application Serial No. 14/863,239 entitled "METHODS AND APPARATUS FOR HYBRID ACCESS TO A CORE NETWORK BASED ON PROXIED AUTHENTICATION" filed September 23, 2015; co-owned U.S. Patent Application Serial No. 14/156,339 entitled "METHODS AND APPARATUS FOR HYBRID ACCESS TO A CORE NETWORK" filed January 15, 2014; and co-owned U.S. Patent Application Serial No. 14/156,174, entitled "METHODS AND APPARATUS FOR A NETWORK- AGNOSTIC WIRELESS ROUTER" filed January 15, 2014, each of the foregoing incorporated herein by reference in its entirety. FIG. 2A illustrates one exemplary network architecture comprising a Wi-Fi access point (AP) 204 in communication with an exemplary user equipment (UE) 206 and a Serving Gateway (S-GW) of a Long Term Evolution (LTE) Core Network. As shown, an access tunnel (e.g., a so-called "Wi-Fi PIPE") enables a user equipment (UE) 204 to access a cellular core network via a Wi-Fi access point (AP) 206. The Wi-fi AP 206 is configured to directly connect to the core network, using protocols similar (or identical) to existing network entities (e.g., evolved NodeBs (eNBs)). The UE and AP are connected via the Wi-Fi PIPE access tunnel. The AP executes a translation process (e.g., a UE medium access control (MAC), virtual physical layer (VPHY), and access point (AP) MAC), thereby seamlessly connecting the UE to the LTE core network.

As previously noted, existing solutions for IKE connectivity via IPsec is susceptible to many potential vulnerabilities (Logjam, Man-In-The-Middle, etc.) Consequently, an improved IPsec protocol suite for the aforementioned system connectivity is disclosed. Specifically, the underlying access technology arbitrates LTE protocols between a user equipment and the core network of the LTE system; thus, the access technology is modified and/or configured to support LTE protocols such as an AKA authentication and key generation.

Referring back to FIG. 2A, an exemplary stack arrangement for the exemplary UE and AP is depicted. As shown, the UE non-access stratum (NAS) layer is split between a dedicated application labelled "NAS Authenticate Telephony" executed in the UE (herein referred to as the "UE Agent") that supports NAS operations, authentication, and telephony, on the UE side, and a dedicated application labelled "Agent" executed in the AP (herein referred to as the "AP Agent") that supports NAS operations and authentication on the Wi-Fi AP side. In alternative implementations, the entire NAS layer may reside in either the UE or in the AP, given appropriate modifications made by one of ordinary skill, given the contents of the present disclosure.

The exemplary NAS layer is split between two (2) nodes (UE 206 and AP 204) and thus should provide security for the messages exchanged between the two (2) NAS layer portions (or generally for all messages exchanged between the UE Agent and AP Agent) before a Wi-Fi security mode is set up and available. In one embodiment, the system implements such security by using a NAS message which can only be generated at MME (Mobility Management Entity, the main signaling node in the EPC) and the UE.

As a brief aside, prior art NAS messages contain a NAS-MAC (Message Authentication Code for NAS for Integrity) that is exchanged during the NAS Security Mode Command, such as is defined by the LTE standard body in exemplary releases: (i) 3 GPP TS 33.401 V14.0.0, published September 2016, and (ii) 3GPP TS 24.301, VI 4.0.0, published June 2016, and incorporated herein by reference in their entireties. As described therein, the NAS-MAC is generated by the MME (hereafter referred to as an "original NAS-MAC message") by applying the NAS integrity key ("KNASint" key), along with the Security Mode Command message, and a number of other variables which are known to both the MME and the UE, such as COUNT, BEARER-ID and DIRECTION, to Integrity algorithm EIA. The KNASint is generated from a KASME; the KASME is provided as part of a fresh authentication vector that is dynamically generated at each authentication attempt.

Since the intermediary AP 204 receives both the NAS Security Mode

Command message and the augmented original NAS-MAC message, the exemplary NAS layer portion (in the AP) can also extract the original NAS-MAC message. In one variant, the original NAS-MAC message is further modified (hereafter referred to as a "modified NAS-MAC message"), with the modification known to (or previously agreed upon by) the UE 206 and the intermediary AP 204. Common examples of modifications include e.g., hashes, scrambles, or other obfuscation techniques. The modification may be applied before augmenting the NAS Security Mode Command message with the modified NAS-MAC, and transmission of both from AP 204 to UE 206.

More directly, the UE 206 does not know the original NAS-MAC message until after the UE 206 has received the NAS Security Mode Command message. After receiving the NAS Security Mode Command message, the UE 206 can also calculate the original NAS-MAC message (originally sent by the MME), in similar manner to the MME, by applying the KNASint key, and the received NAS Security Mode Command message, and a number of other variables which is also known to both the UE and MME, such as COUNT, BEARER-ID and DIRECTION, to Integrity algorithm EIA. Since the original NAS-MAC message (which was replaced by a modified NAS-MAC message) is not directly transmitted to UE 206, it is only recoverable by the UE 206 and the Wi-Fi AP 204 (and known by MME). Therefore, the original NAS-MAC is a shared secret between UE 206 and AP 204, and can be used as a key for encryption of the exchanged messages between the two (2) portions of the NAS layer, residing in the UE 206 and the AP 204.

In modified variants, the UE 206 can apply the same modification to the original NAS-MAC message that the AP 204 made to the original NAS-MAC message in order to construct or reconstruct the modified NAS-MAC message and to compare with the received modified NAS-MAC. The resulting comparison result can be used to check the integrity of the received NAS Security Mode Command from the AP 204.

In another variant, the original NAS-MAC message augmented with the NAS Security Mode Command can be used, directly or indirectly, to encrypt the original NAS-MAC message, before transmission from AP 204 to UE 206.

After receiving the NAS Security Mode Command message, the UE 206 can calculate the original NAS-MAC message; the UE 206 can then use calculated original NAS-MAC message to decrypt the encrypted NAS-MAC message, to recover the original NAS-MAC value transmitted by the AP 204 for integrity check. Since the original NAS-MAC is only transmitted from AP 204 to UE 206 in an encrypted mode, it is only known to UE 206 and AP 204 (and the MME), and therefore can be used a secret key for encryption of future exchanged messages between AP 204 and UE 206.

Once the exemplary NAS layer (both portions at the UE 206 and AP 204) has successfully processed the NAS Security Mode Command, it responds to the MME with a NAS Security Mode Complete message. Normally, the MME will transfer eNB keys to the eNB when it receives the NAS Security Mode Complete message; here, the portions of the eNB functionality are performed by the Wi-Fi AP 204. Specifically, the eNB keys can be used in the Wi-Fi (or IKEv2) encryption/decryption engine for providing bi-directional secure communication over e.g., a Wi-Fi radio interface or Ethernet cable. In one embodiment, the eNB keys may be used to derive or augment the NAS-MAC key (mentioned above), to make it longer than 32 bits, which may then be utilized for additional encryption of NAS and system messages exchanged between the UE Agent and AP Agent.

The foregoing discussion of FIG. 2A is presented within the context of a UE 206 that is connected to the LTE core network (EPC) via the Wi-Fi AP 204 using, e.g., a Wi-Fi wireless link for the two-way communications with the EPC. As noted therein, the UE's USIM (used for the authentication and key generation as noted above) also exchanges messages with an EPC Home Subscriber Server (HSS) and the MME via the Wi-Fi wireless link. Artisans of ordinary skill in the related arts will readily appreciate that the foregoing technique may be used regardless of the underlying access technology; for example, an Ethernet wireline connection may be used with equivalent success to a Wi-Fi wireless connection. FIG. 2B illustrates one such wireline embodiment. As shown in FIG. 2B (and in contrast to the system of FIG. 2A), a gateway apparatus 208 in communication with a UE 206 via a wireline Ethernet link uses an exemplary stack arrangement. In this case, the link is based on a wired access technology e.g., wireline Ethemet. Since the link is an Ethernet link, a different security scheme such as IPsec may be needed to replace the Wi-Fi security scheme.

FIG. 3 illustrates a flow diagram of an exemplary exchange of authentication messages for the system depicted in FIG. 2B, where the link in the system is a wireline Ethernet connection (and not a wireless link e.g., the Wi-Fi link of FIG. 2A). In an exemplary embodiment, various messages are exchanged between the UE (e.g., 206) and the Gateway (e.g., 208). Initially, the UE initiates an attach request, after which an LTE authentication procedure is performed in "open" exchanges (not encrypted). After successful authentication, "LTE NAS Security Mode Setup" procedures are followed. These messages are not encrypted, but rather, they are integrity protected by inclusion of a NAS-MAC. After successfully completing the NAS security mode setup (and the connection is encrypted and/or integrity protected), the LTE eNB keys (KENB) are passed from the MME to an eNB unit of the Gateway.

Artisans of ordinary skill in the related arts will readily appreciate, given the contents of the present disclosure, that some of the aforementioned messages propagate to, and are terminated at, other network elements e.g., the Mobility Management Entity (MME) and/or the Home Subscriber Server (HSS). The message exchanges of FIG. 3 have been abbreviated for clarity, and include LTE (AKA) and IPsec (IKEv2) authentications which are not shown.

In existing systems, the four (4) message security association according to IPsec IKEv2 is performed after the LTE authentication and the NAS security mode setup (see e.g., FIG. 1A). However, various embodiments of the present disclosure have modified the second phase. Specifically, messages 3 and 4 that are used for a PSK-based IKEv2 authentication are based on the LTE eNB key (KENB) or a derivative thereof. In other words, the KeNB serves as a pre-shared key (PSK). The KeNB key is available at both the UE and the Gateway (which serves the functions normally provided by an eNB). Regardless of whether the KeNB or a derivative is used for PSK authentication, the existing IPsec IKEv2 procedure can be used for PSK authentication without modification. Moreover, artisans of ordinary skill in the related arts will appreciate that using a session key based on a newly generated eNB key advantageously eliminates the chance of permanent-key exposure and theft, and/or a brute-force or dictionary attack.

Internet of Things (IoT) Variants -

FIG. 4A is a block diagram of an exemplary user equipment device (UE) which has been further adapted to support an Internet of Things (IoT) application. External device communications may occur through the aforementioned wireless Wi- Fi and/or wireline Ethernet paradigms via the IPsec tunnel. In FIG. 4A, the device provides internet, security, communication and other services within an operating system that is accessed through the IPsec kernel. As a brief aside, IoT enables an internet of computing devices embedded in everyday objects, to allow them to send and receive data. IoT applications are not human driven and thus may be implemented cheaply, usually on very power efficient platforms that are intermittently operated. Security for IoT has been a growing concern, and the single-authentication procedure performed either by LTE or IKE in isolation is likely inadequate. To these ends, a joint (double) authentication procedure that is specifically tailored to the intermittent and/or non-user specific nature of IoT devices may be required.

In the illustrated embodiment of FIG. 4A, an operating system is used to manage the IPsec tunnel for delivery of data packets to the IoT Application and the UE Agent. For example, a Linux operating system may be used, however any suitable operating system may be used with equivalent success. FIG. 4A illustrates an embodiment where the IoT and UE Agent packets are supported independently through the IPsec tunnel. In other embodiments, the IoT packets may be passed via the UE Agent. In one such variant, the IoT packets are passed through the UE Agent, independent of the OS or its services (see also FIG. 4B and corresponding discussion below), directly via the tunnel.

FIG. 4B shows a block diagram of an exemplary embodiment of a IPsec tunnel where data passes through and is encrypted by the UE agent. LTE-generated keys (e.g., KeNB) may be used for IKEv2 authentication and/or for IPsec encryption. In some implementations, the LTE-generated keys (e.g., KeNB) may be used for encryption and/or integrity protection at the user domain (e.g., application level). As shown in FIG. 4B, all packets entering and exiting the device, e.g., via Wi-Fi, Ethernet, and/or any other access technology, pass through the UE agent, where the packets are decrypted or encrypted (e.g., with KeNB). Encryption and decryption thereby become independent of the operating system (e.g., Linux) and its available kernel and services. This "pass through" arrangement may require lower data throughput and volume and thus may be suitable for relatively smaller IoT devices. In various other embodiments, similar modifications as described with respect to FIG. 4A may be made to the UE Agent bolster security measures.

Artisans of ordinary skill in the related arts will readily appreciate that the applications for IoT span a multitude of uses. Thus, IoT applications may require specific variants of operation, the following being provided as illustrative examples of such considerations.

KeNB Key Replacement Variant -

During the first phase of the four (4) message security association for IKEv2, a Diffie-Hellman Key Generation/Exchange is performed using messages 1 and 2 of the initial IKEv2 security association procedure. However, there have been reports of Diffie-Hellman algorithm vulnerability (such as with the Logjam attack as noted previously). Thus instead of using a Diffie-Hellman key, one exemplary IoT variant uses encryption session keys from a newly generated KeNB (or its derivative). The KeNB keys are available before the exchange of IKEv2 messages 1 and 2 (the first phase); thus modifications may be made to the IKEv2 procedure encrypt messages 1 and 2 to provide additional protection. In other variants, the Diffie-Hellman key generation during the first phase may be bypassed or discarded entirely. These steps reduce any vulnerabilities detected in the Diffie-Hellman algorithm. Diffie-Hellman Key Assisted LTE Authentication Variant -

While the Diffie-Hellman vulnerabilities raise potential issues, there may be IoT applications where the Diffie-Hellman exchange provides sufficient protection. For example: in one such variant, an additional replica procedure of the first two (2) messages of IKEv2 (messages 1 and 2) may be added to the beginning of the LTE Authentication procedure (before the "Attach Request" message as shown in FIG. 3). Replication allows generation of a Diffie-Hellman key to protect the entire LTE Authentication and LTE NAS Security Mode Setup procedures. This approach may protect against third-party eavesdropping of private information e.g., the exchange of an International Mobile Subscriber Identity (IMSI), which is a globally unique identifier stored on a SIM card (e.g., on a mobile device on an LTE network) that identifies and allows for authentication of a mobile subscriber on the mobile network.

Identification Protection for Man-in-the-Middle Variant - As a brief aside, Man-in-the-Middle (MITM) attacks are attacks where an attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. Within the context of the LTE systems described above, MITM attacks are able to obtain an LTE IMSI and/or an IKEv2 ID. Specifically, a MITM can pose as a valid server, reject temporary subscriber IDs (e.g., Globally Unique Temporary ID (GUTI)), or intercept the subscriber IMSI used in the attach message. If the GUTI is rejected by the server, the UE may attempt to attach to the network with IMSI instead. Thus, it is possible for a MITM attack to obtain a USIM IMSI, even if the entire LTE Authentication process is protected by Diffie-Hellman encryption keys (see e.g., discussion of Diffie-Hellman Key Assisted LTE Authentication Variant). For instance, the MITM may negotiate the initial Diffie-Hellman keys with the subscriber. Similarly, a MITM may obtain the IKEv2 initiator ID. Hence, updating subscriber IDs as discussed above may advantageously address vulnerabilities related to MITM attacks.

In order to address MITM attacks, the IMSI or the entire USIM information after each attach procedure may be changed e.g., by changing the IMSI or providing a new USIM for each attachment procedure to the MME. By requiring different IMSI (or USIM) for each attachment, previously exposed IMSI are not valid for subsequent attachments. The protocol for changing the IMSI (or the USIM) takes into account various scenarios e.g., a successful or unsuccessful attach, or whether the attach is associated with an actual subscriber or a "fake" or invalid subscriber.

In one variant, one or more previous IMSI (or USIMs) information are kept on both sides for added security. For example, both sides can continue to interrogate the other side to, e.g., ensure a correct IMSI (or USIM) history. Updating a subscriber's ID in this manner provides protection against certain vulnerabilities, such as Man-in- the-Middle (MITM) attacks, replay attacks, brute force attacks, and other attacks that do not have access to previous transactional history.

Although the joint authentication procedure may provide greater security than a single-authentication procedure performed either by LTE or IKEv2 in isolation, the mechanisms described above provide a number of modifications that may be made to the joint authentication procedure in accordance with the present disclosure to offer even greater security in the IPsec context.

Myriad other schemes for initializing a secure network connection will be recognized by those of ordinary skill given the present disclosure. It will be recognized that while certain aspects of the invention are described in terms of a specific sequence of steps of a method, these descriptions are only illustrative of the broader methods of the invention, and may be modified as required by the particular application. Certain steps may be rendered unnecessary or optional under certain circumstances. Additionally, certain steps or functionality may be added to the disclosed embodiments, or the order of performance of two or more steps permuted. All such variations are considered to be encompassed within the invention disclosed and claimed herein.

While the above detailed description has shown, described, and pointed out novel features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the invention. The foregoing description is of the best mode presently contemplated of carrying out the invention. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the invention. The scope of the invention should be determined with reference to the claims.

Claims

WHAT IS CLAIMED IS :

1. A method for initiating a secure connection within a network, the method comprising:

sending an authentication request to an access point within the network;

deriving a first encryption key based on a shared information received from a network entity via the access point;

using the first encryption key to encrypt packets transmitted to the access point;

wherein the first encryption key corresponds to a second encryption key that the access point has independently derived based on the shared information; and enabling a secure bi-directional communication link with the access point, the communication link being configured to transfer the packets encrypted using the first and second encryption keys.

2. The method of Claim 1 , wherein the method comprises executing a portion of a non-access stratum (NAS) software layer of a Long Term Evolution

(LTE) network.

3. The method of Claim 2, wherein executing the portion of the NAS software layer network entity comprises communicating with a Mobility Management Entity (MME) NAS software entity.

4. The method of Claim 3, wherein the shared information comprises a

NAS Security Mode Command.

5. The method of Claim 4, wherein the first encryption key is used as a pre-shared key (PSK) for an Internet Key Exchange (IKE) protocol.