FIELD OF TECHNOLOGY

[0001 ] The present disclosure relates generally to mobile communications and, more particularly, to devices and methods for secure communications and authentication of connected devices.

BACKGROUND

[0002| In order for two parties to establish a TLS session between two communication devices using pre-shared keys (e.g. , using a cipher suite for the Transport-Layer Security (TLS) protocol, such as TLS_PSK_WITH_AES_256_CBC_SHA), both parties must have previously established a shared key. For example, pre-shared key (PSK) is a shared secret key that was previously shared between the two parties using some secure channel before the shared secret needs key to be used.

[0003] Some existing techniques for establishing the key for TLS sessions use asymmetric cryptography (e.g. , using a Diffie-Hellman key exchange). At least one existing approach is based on using the Universal Mobi le Telecommunications Service (UMTS) authentication and key agreement process. This existing approach, however, requires the addition of two IP multimedia services identity module (ISIM) application-dedicated fi les (ADFs) to a standard universal integrated circuit card (UICC). The UMTS authentication and key agreement process is then run on each of these two ADFs and the resultant data is used as the new shared key.

SUMMARY

[0004] The following introduces a selection of concepts in a simplified form in order to provide a foundational understanding of some aspects of the present disclosure. The fol lowing is not an extensive overview of the disclosure, and is not intended to identify key or critical elements of the disclosure or to delineate the scope of the disclosure. The fol lowing merely presents some of the concepts of the disclosure as a prelude to the more detailed description provided thereafter. |0005| An embodiment of the present disclosure relates to a system comprising a secure element of a mobile device, and a network gateway device in communication with the mobi le device via a first communication network, where the secure element is configured to: receive a first authentication token from the network gateway device, determine whether the first authentication token is valid based on a sequence number included in the first authentication token, and in response to determining that the first authentication token is val id: generate a second authentication token, where the second authentication token indicates a status of an authentication operation performed by the secure element, send the second authentication token to the network gateway device, and derive a pre-shared key using a key derivation function, where the pre-shared key is usable to establ ish a secure commun ication channel with the network gateway device.

[0006] Another embodiment of the present disclosure relates to a method comprising: receiving, at a secure element of a mobile device, a first authentication token; determ ining, at the secure element, whether the first authentication token is val id based on a sequence number included in the first authentication token; in response to determining that the first authentication token is valid: generating, at the secure element, a second authentication token, where the second authentication token indicates a result of an authentication operation performed by the secure element, sending the second authentication token to a network gateway device, and deriving, at the secure element, a pre-shared key using a key derivation function, where the pre-shared key is usable to establish a secure communication channel with the network gateway device.

[0007] Yet another embodiment of the present disclosure relates to a non-transitory, computer-readable medium or media storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a first authentication token; determining whether the first authentication token is valid based on a sequence number included in the first authentication token; in response to determining that the first authentication token is valid: generating a second authentication token, where the second authentication token indicates a result of an authentication operation performed by the one or more processors, sending the second authentication token to a network gateway device, and deriving a pre-shared key using a key derivation function, where the pre-shared key is usable to establ ish a secure communication channel with the network gateway device.

[0008| Further scope of applicability of the apparatuses and methods of the present disclosure wi ll become apparent from the more detailed description given below. It should be understood that the following detailed description and specific examples, whi le indicating em bod iments of the apparatus and methods, are given by way of il lustration only, since various changes and modifications with in the spirit and scope of the concepts disclosed herein wil l become apparent to those ski lled in the art from the fol lowing detai led description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] These and/or other aspects will become apparent and more readily appreciated from the fol lowing description of the embodiments, taken in conjunction with the accompanying drawings of which:

[0010] Fig. 1 is a block diagram illustrating an example system for authenticating a connected device and establishing a pre-shared key, according to one or more embodiments described herein.

[001 1 1 Fig. 2 is a block diagram illustrating an example connected device and an example secure element of the system of Fig. 1 , according to one or more embodiments described herein.

|0012| Fig. 3 is a diagram illustrating an example authentication token that may be sent from an authentication center to a secure element in a mobile device, according to one or more embodiments described herein.

|0013] Fig. 4 is a diagram il lustrating an example authentication token that may be sent from a secure element in a mobi le device to an authentication center, according to one or more embodiments described herein.

|0014] Fig. 5 is a diagram il lustrating example data flows in a system for authenticating a mobi le device and establishing a pre-shared key when there is a successful authentication, according to one or more embodiments described herein. [0015] Fig. 6 is a diagram illustrating example data flows in a system for authenticating a mobi le device and establishing a pre-shared key when a resynchronization request is made, according to one or more embodiments described herein.

[0016] Fig. 7 is a flow diagram illustrating an example method for authenticating a mobi le device and establ ishing a pre-shared key, according to one or more embodiments described herein.

[0017] Fig. 8 is a block diagram illustrating an example system for authenticating a connected device and establishing a pre-shared key, according to one or more embodiments described herein.

[0018| Fig. 9 is a block diagram illustrating an example system for authenticating a connected device and establishing a pre-shared key, according to one or more embodiments described herein.

[0019[ The headings provided herein are for convenience only and do not necessarily affect the scope or meaning of what is claimed in the present disclosure.

[0020| Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numbers are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.

DETAILED DESCRIPTION

[0021 ] Various examples and embodiments of the present disclosure wil l now be described. The fol lowing description provides specific details for a thorough understanding and enabl ing description of these examples. One of ordinary ski ll in the relevant art wi l l understand, however, that one or more embodiments described herein may be practiced without many of these detai ls. Likewise, one skilled in the relevant art will also understand that one or more embodiments of the present disclosure can include other features and/or functions not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, so as to avoid unnecessarily obscuring the relevant description. [0022] Embodiments of the present disclosure relate to methods, systems, and devices for generating secure keys for confidential communications and authentication of connected devices. The secure keys may be used, for example, to establish secure TLS communications between a connected communication device and a network gateway that is used by the communication device to access Internet-based service providers and services, according to an embodiment. It should be noted that the secure TLS communication provided by the methods and systems described herein may be in addition to any application layer security that is also being used.

|0023] According to an embodiment, an authentication and key agreement (AKA) appl ication (sometimes referred to herein as the "AKA application") may be configured to run on a secure element present in a communication device (e.g., mobi le device, mobile term inal client, etc.) to establish a pre-shared key between the communication device and a secure network gateway (or secure communication gateway, or simply "secure gateway" for purposes of brevity). For example, in a particular embodiment, the network gateway establishes the shared key with the mobile device using the secure element in the mobile device and an authentication center (e.g., server). The network gateway may periodically request sets of authentication data or credentials (e.g. , authentication tuples) from the authentication center such that the process for authenticating the mobi le device and establ ish ing a pre-shared key may be performed even when the authentication center is unavailable or inaccessible.

[0024] As wi l l be described in greater detail below, the methods, systems, and devices of the present disclosure allow a pre-shared key (PSK) to be initially establ ished and then rotated as necessary. In order to establish this pre-shared key, a network gateway may be assisted by an authentication center entity that already shares a symmetric key with the secure element of the mobile device. In at least one such embodiment, symmetric cryptography is used. For example, the authentication and key agreement process (sometimes referred to herein simply as the "AKA process") described herein may utilize symmetric key techniques to establish a master key that the connected device (e.g., mobile device) may use to set up a secure communication channel (e.g., TLS-PSK channel) with the network gateway. In at least one embodiment, the AKA process results in mutual authentication of the secure element in the mobile device and the authentication center. [0025] The AKA process of the present disclosure may use, for example, advanced encryption standard as the block cipher, according to an embodiment. The individual key used by the secure element of the mobile device may be, for example, 256-bits in length. For example, the individual key of the secure element may be randomly generated during manufacture of the secure element, and stored in the secure element. This individual key of the secure element may be securely distributed or provided to the authentication center in any suitable manner.

[0026] The methods and systems of the present disclosure provide numerous advantages over existing AKA-based approaches. For example, the AKA application described herein may be implemented as an applet that is independent of the Mobile Network Operator's (MNO) application that runs on the mobile device. Also, in contrast to existing approaches that generate half of the pre-shared key using one ADF and generate the second half of the pre-shared key using a second ADF, the methods and systems of the present disclosure may generate the pre-shared key in a single step. In addition, the system described herein for authenticating a mobi le terminal client (e.g. , mobi le device) and establ ishing a pre-shared key may be particularly suited to operate in an environment where there are multiple authentication centers and network gateways, the identities of which may be used in the key derivation function to generate the pre-shared key.

[0027| FIG. 1 i llustrates an exemplary embodiment of system 100 for authenticating a mobi le terminal client (e.g. , mobile device) and establishing a pre-shared key. For example, the AKA process may involve various communications between a mobile device 102 (e.g. , mobi le equipment, mobile terminal cl ient, etc.), a secure element 108, a network gateway 120, and an authentication center (e.g. , server) 140. In at least one embodiment, network gateway 120 and authentication center 140 may together constitute a single authentication entity with in system 1 00. For example, at least from the perspective of mobi le device 1 02 and/or secure element 108, authentication center 140 may not be a separate entity from network gateway 120. In other words, to mobile device 102 and/or secure element 108, authentication center 140 may be network gateway 120.

[0028] Mobi le device 102 (which may also be referred to herein as the "connected" device) is the entity that may access various network services via network gateway 120. For example, mobi le device 102 may communicate with network gateway 120 via a mobi le network operator (MNO) data service. Examples of mobile device 1 02 include, but are not l imited to, mobi le telephones, personal digital assistants, smart phones, tablet computers, laptops and other computers, walkie-talkies, automobiles, household appliances, drones, as wel l as any other device that may conceivably connect with a telecommunications network. According to an embodiment, the mobile device 102 is authenticated, and a pre-shared key is establ ished, in order to establish a secure communication channel (e.g. , TSL(PSK)) between mobi le device 1 02 and network gateway 120. As described in greater detai l herein, the transport keys for the communications between mobile device 102 and network gateway 120 may be derived in the AKA process, and may be received by mobi le device 102 from secure element 108.

|0029| Secure element 1 08 may be located or installed in mobile device 102. In an exemplary embodiment, all messages sent to (e.g., intended for) secure element 108 may be routed through mobile device 102. According to an embodiment, secure element 108 is a universal integrated circuit card (UICC) or subscriber identification module (SIM), which may be used to authenticate to a MNO and provide the cellular data link for mobile device 1 02. It should be noted that the AKA application of the present disclosure is separate from any MNO appl ication installed on secure element 108, and is independent of any USIM/ISIM functional ity that may be provided by secure element 108. The AKA application described herein may be implemented as an applet (e.g. , JavaCard applet configured to run correctly on standards compliant with JavaCard implementations). The secure element may be configured to store an individual key that is used in the AKA process (described in greater detail below). In at least one embodiment, this individual key stored by secure element 108 may also be shared by network gateway 120 and/or authentication center 140.

|0030| Network gateway 120 is the interface between mobi le device 1 02 and a commun ications network 1 1 6 (e.g. , the Internet). For example, the mobile device 1 02 may uti l ize the network gateway 120 to access Internet-based service providers 132- 1 , 132-2 and services. Network gateway 1 20 may also be connected to (e.g., in direct and/or secure communication with) authentication center 140. Network gateway 120 may exchange secure communications with authentication center 140 and/or one or more service providers 132- 1 , 1 32-2 according to public key infrastructure (PKI), for example. [0031 1 In an exemplary embodiment, network gateway 1 20 periodical ly sends to the authentication center 140 requests for tokens and various other data that may be used in the A A process, and the authentication center 140 may provide such tokens and other data to the network gateway 1 20 in response to such requests. When network gateway 120 periodical ly receives tokens and other authentication data from the authentication center 1 40 in th is manner, the AKA process described herein may be performed even when authentication center 140 is not avai lable or accessible (i. e. , when authentication center 140 is offl ine).

[0032] In an exemplary embodiment, authentication center 140 is a server located in a secure environment such that authentication center 140 may contain (e.g. , store) the individual keys of secure element 108.

[0033] It should be noted that, in some embodiments, system 100 includes more than one network gateway 120 and/or more than one authentication center 140. In such embodiments, each of the one or more network gateways 120 may be associated with a distinct identifier, and each of the one or more authentication centers 140 may also be associated with a distinct identifier.

[0034] FIG. 2 is a block diagram illustrating various components of mobile device 102 and secure element 108, according to one or more embodiments. As described above, the secure element 108 may be installed in the mobile device 102. In at least one embodiment, the mobi le device 1 02 includes a memory 210, a central processing un it (CPU) 220, and an input/output (I/O) device 230. Memory 21 0 may include instruction memory 212 configured to store computer-readable instructions that may instruct mobile device 102 to perform various processes or operations. Memory 21 0 may also include a cache 214 configured to stored data obtained from secure element 1 08. It should be understood that mobile device 102 may include other components in addition to or instead of the example components shown and described above. Similarly, mobile device 102 may include fewer components than the number of example components shown, or one or more of the example components shown may be combined, without departing from the operations, features, or functionalities of the system and/or mobile device as described herein. For example, CPU 220 of mobile device 102 may serve as secure element 108. [0035| When executed by CPU 220, the computer-readable instructions stored with in instruction memory 212 cause CPU 220 to operate as one or more of a plural ity of functional components configured to perform one or more of the processes described herein. In some embodiments, such functional components may be implemented on different CPUs 220 within mobile device 102, on different mobile devices 102 altogether, or some combination thereof. I/O device 230 is configured to, for example, transmit information between mobile device 1 02 and other devices within a telecommunications network, to receive input from a user of mobile device 102, to provide output for a user of mobile device 102, to obtain data and information from and provide data and information to secure element 108, as well as perform various other input/output related tasks involving processes for authenticating mobi le device 1 02 and establishing a PSK.

[0036| Secure element 108 (which may be, for example, a UICC or SIM) may function as a memory with a plurality of memory areas. These memory areas may be configured to, for example, store a globally unique identifier (GUID) 252 for secure element 1 08, store shared key information 254 related to authentication processes for mobile device 102, and store various other data such as authentication token data and identifiers. Secure element 108 may include a processing component, such as CPU 258, an interpreter, a control ler, an appl ication specific integrated circuit (ASIC), or other component capable of perform ing various computational tasks. Examples of secure element 1 08 include, but are not lim ited to, SI M cards and any other data carriers that may provide information to the mobile device 1 08.

[0037J In an exemplary embodiment, secure element 108 includes a sequence counter 256 configured to maintain a l ist of all the authentication centers/network gateways with which secure element 108 has successfully performed the AKA process. A maximum sequence counter increment, L, may be set to control the maximum increase that secure element 108 will allow in a sequence number associated with a network gateway/authentication center combination (GW/AuC). For example, when the authentication center {e.g. , authentication center 140 shown in FIG. 1) is requested (e.g. , by network gateway 120) to generate a new set of authentication tokens, the authentication center will increment its copy of the sequence counter. As described above, the sequence number, (which wil l be denoted below by NB), protects against replay attacks. The length of the sequence number may be fixed at, for example, 4 bytes. In such an embodiment, the maximum value for any of the sequence numbers, N _max , may be 2 ³² - l = OxFFFFFFFF.

[0038] In some embodiments, the AKA process of the present disclosure implements a two-pass mutual authentication in accordance with the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) Standard 9798-2 for Information Technology, Security Techniques, and Entity Authentication, and is modeled after the UMTS AKA implementation, but with various changes and improvements as described in greater detail below. In an exemplary embodiment, various system parameters and fields of the 9798-2 two pass mutual authentication process are modified and specialized in the AKA process described herein.

[0039] In the fol lowing description of FIGS. 3-7, the authentication center (e.g. , authentication center 140 shown in FIG. 1 and described in detail above) is denoted as entity "A", and the secure element (e.g. , secure element 108 shown in FIGS. 1-2, and described in detai l above) is denoted as entity "B".

10040] FIG. 3 il lustrates an example authentication token 300 that may be sent from the authentication center to the secure element. Authentication token 300 may be referred to herein as "Tokert iZ?" since it is provided from communication entity A (authentication center, network gateway, combination AuC/GW, etc.) to communication entity B (secure element). Token 300 may include various parameters and/or fields. In an exemplary embodiment, token 300 includes a first text field 3 10, a second text field 304, a random number generated by entity A (RandomA) 306, and an identity (e.g. , identifier) of entity B (B-ID) 308. First text field 3 10, B-ID 308, and RandomA 306 may be included in an encrypted portion 302 of token 300. It should be noted that the contents of the text fields (Textl , Text2) are not defined in the ISO Standard 9798-2, and the inclusion of the identity for entity B (B-ID 308) in encrypted portion 302 of token 300 is optional. It should also be understood that encrypted portion 302 of token 300, which includes first text field 3 10, is securely transported with token 300, and the values of the parameters and fields contained therein cannot be changed or read by an attacker.

|0041 | The random number generated by the authentication center (RandomA) 306 is included in the token 300 in order to bind the token 300 to the token that is sent from the secure element to the authentication center (TokenZL4, which is represented by token 400 in FIG. 4, described in greater detail below). The distinct identifier for the secure element (B-ID 308) is included in token 300 to prevent its re-use (e.g. , the re-use of TokenAB) on entity A by an adversary masquerading as the secure element (entity B).

[0042] Since the secure element does not determ ine which authentication center (or authentication center/network gateway (AuC/GW) combination) the secure element is authenticating, the identity of the authentication center (A-ID 3 14) is included in the token 300, accord ing to an embodiment. To protect against replay attacks, a sequence number 3 1 6 for the secure element may be included in token 300. In an exemplary embodiment, the agreed transport key (pre-shared key) is generated once the authentication of the secure element has been completed. For this purpose, the authentication center generates some secret data, or a shared secret value 3 1 8, which is included in token 300. Shared secret value 3 1 8 may be used in a key derivation function, which will be described in greater detail below. In an exemplary embodiment, the identity of the authentication center (A-ID 3 14), sequence number 3 1 6, and shared secret value 3 18 are included in first text field 3 10. A version number for the authentication protocol (protocol version 3 12) being used in the AKA process may be included in second text field 304.

|0043| Another representation 340 of token 300 shows example notations used for the token itself (TokenAB), as well as for various fields of the token described above. The random number generated by the authentication center (RandomA) 306 may be denoted as RA, the identity of the secure element (B-ID 308) may be denoted as B, the identity of the authentication center (A-ID 3 14) may be denoted as A, the sequence number 3 16 for the secure element to use to protect against replay attacks may be denoted as Νβ, the version number for the authentication protocol being used may be denoted as Protocol- Version, and shared secret value 3 1 8 for use in a key derivation function may be denoted as ZAH- Some or al l of these notations may be referred to in the descriptions that follow.

[0044] FIG. 4 i l lustrates an example authentication token 400 that may be sent from the secure element to the authentication center, according to one or more embodiments. Authentication token 400 may be referred to herein as "ToksnBA" since it is provided from communication entity B (secure element) to communication entity A (authentication center, network gateway, combination AuC/GW, etc.). Token 400 may include various parameters and/or fields. In an exemplary embodiment, token 400 includes a third text field 456, a fourth text field 454, sequence number 3 16 (e.g. , included in token 300 shown in FIG. 3 and descri bed in detai l above) from the authentication center for use in defending against replay attacks, and the identity {e.g. , identifier) of entity A (A-ID) 3 14. Third text field 456, A-ID 3 14, and the sequence number 3 1 6 may be included in an encrypted portion 452 of the token 400. It should be noted that the contents of the text fields (Text3, Text4) are not defined in the ISO Standard 9798-2, and the inclusion of the identity for entity A (A-ID 3 14) in encrypted portion 452 of the token 400 is optional. It should also be understood that encrypted portion 452 of token 400, which includes third text field 456, is securely transported with token 400, and the values of the parameters and fields contained therein cannot be changed or read by an attacker.

[0045] As discussed above, the random number generated by the authentication center (Random A) 306 is included in token 400 in order to bind token 400 to the token that was sent from the authentication center and received at the secure element (Token Z?, which is represented by token 300 in FIG. 3, described in detail above). The distinct identifier for the authentication center (A-ID 3 14) is included in the token 400 to prevent the re-use of the token 400 (e.g., the re-use of Token.&4) on entity B by an adversary masquerading as the authentication center (entity A).

|0046| If the sequence number from the authentication center 3 16 sent in Jo aAB (token 300 of FIG. 3) is incorrect or inval id, then that may be interpreted by the secure element as indicating that the authentication center has an unsynchronized value and resynchron ization is thus necessary. To achieve this, the secure element may include a new sequence number 41 6 i n token 400 in place of sequence number 3 16 that was sent by the authentication center. For example, when the secure element (entity B) receives sequence number 3 1 6 from token 300 sent by the authentication center (entity A), the secure element compares the sequence number 3 1 6 to a current value stored in a sequence counter of the secure element (e.g. , sequence counter 256 in secure element 108 shown in FIG. 2). If the value of sequence number 3 1 6 is no more than L larger (e.g., where L is the maximum sequence counter increment, as described above) than the current value stored in the sequence counter, then the secure element may accept sequence number 3 16 as valid/correct. It should be noted that if the current value stored in the sequence counter of the secure element is close to the maximum perm itted value N _max permitted by the system, then this comparison/check al lows the value to wraparound back to 0.

|0047] For example, if c denotes the current value of sequence counter of the secure element, then received sequence number 3 16 may be determined valid (e.g. , correct, acceptable, etc.) if either:

c < NB < mm(N _MAX , c+L) or

0 < Νβ < c+L-N _max (wraparound case)

If received sequence number 3 16 is accepted, the secure element will update the sequence counter accordingly. It should be noted that if there is no current value stored in the sequence counter for a given authentication center/network gateway, the secure element may assume a default value of 0 for the current sequence counter. If the secure element has insufficient space to al locate a sequence counter, then an error may be returned.

[0048] If al l other validations other than the check on the sequence number 3 16 pass, then, according to an embodiment, the authentication will fail and a ^synchronization request will be returned to the network gateway/authentication center. The value of the new sequence number 41 6 that may be returned with the resynchronization request may be 1 number higher than the current value stored in the sequence counter of the secure element for the particular authentication center/network gateway involved, according to an embodiment. In em bodiments where there secure element stores the current sequence number for al l authentication center/network gateway pairs, the number of such authentication center/network gateway pairs may be limited.

|0049| In some embodiments, the authentication center is configured to keep track of a set of sequence numbers for each secure element/network gateway pair that may be involved in commun ications with the authentication center. For example, the authentication center may maintain secure numbers for each secure element/network gateway pair in a manner similar to that of the secure element, described in detail above. It should be understood by those of ordinary skill in the art that this is a natural consequence of the system allowing for offline authentication center operation, and to deterministically prevent replay attacks. [0050] In at least one embodiment, a result (or status) of authentication result 458 is included in token 400. Examples of the authentication result 458 that may be indicated in token 400 include "Success" (i. e. , if the authentication was successfully completed), "Resync" (i. e. , if resynchronization is necessary), and "Fail" (i. e. , if the authentication failed completely).

|0051 ] In an embodiment, the identity of the secure element (B-ID 308), the random number generated by the authentication center (RandoniA) 306, and the result/status of authentication 458 are included in third text field 456. In at least one embodiment, the result of authentication 458 is also included fourth text field 454, together with protocol version 3 12 for the authentication protocol being used in the AKA process. Including the result of authentication 458 in third text field 456 ensures that a resynchronization token cannot be used as a success token, for example. It should be noted that in the case where the authentication fails completely, token 400 may not include any encrypted portion 452. It shou ld also be noted that if it is determ ined that a resynchronization is needed, the AKA process described herein is restarted with updated sequence number 416 (e.g. , provided in Tokens).

[0052| Additional representations 440, 442, and 444 of token 400 show example notations that may be used for the token itself (TokenZL4), as well as for various fields of the token described above. Representation 440 shows notations that may be used in the case of a successful authentication, representation 442 shows notations that may be used when resynchronization is needed, and representation 444 shows notations that may be used when authentication has failed completely. It should be noted that various notations used in representations 440, 442 are similar to those used in representation 340 of token 300. One notable difference is that new sequence number 416 (denoted as A¾ may be generated when resynchronization is needed.

[0053] It should be noted that in the case of a successful authentication, there may be no contribution from the secure element (entity B) in the encrypted part of the token 400 (e.g. , in the encrypted part of TokenZL4 ). In the resynchronization case, the secure element suppl ies new sequence number 416 (e.g., denoted Λ¾. In such an embodiment, this allows the network gateway to check the response token from the secure element and be sure that it has authenticated the secure element even when the authentication center is off-line. In at least one embodiment, the acceptable tokens will have been provided to the network gateway in advance (e.g. , by the authentication center).

[0054] In some embodiments, if the authentication was successful, both the authentication center (or network gateway or combination AuC/GW) (entity A) and the secure element (entity B) wi ll be in possession of the shared secret value ZAH- This shared secret value, together with the identities of the authentication center and the secure element, may be used to generate the pre-shared key. For example, these values may be used with the ANSI X9.63 key derivation function (e.g., the key derivation provided in ANSI X9.63-201 1 , Publ ic Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport using El liptic Curve Cryptography) to generate the pre-shared key. In an em bodiment, the process described in BSI, Technical Guideline TR-03 1 1 1 , Elliptic Curve Cryptography, Version 2.0 (June 28, 2012) may be used. In an embodiment, the hash function to be used may be SHA-256 and the sharedlnfo used may be A || B. This ensures that the key derivation function is only used to generate a PSK for the specific entities involved {e.g. , the secure element and the authentication center). In the following description, the pre-shared key that is generated may be denoted as KPSK-

[0055] In one or more embodiments, the encryption that may be used to calculate the authentication tokens (e.g. , the encrypted portions 302, 452 in FIGS. 3-4, respectively) may be AES-256 in CBC mode, and using a padding method from International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) Standard 9798- 1 for Information Technology, Security Techniques, Message Authentication Codes (MACs), Part 1 : Mechanisms using a block cipher (second edition). For example, the data may be padded with a single 1 bit and then as many 0 bits to make a full block.

|0056| FIG. 5 i llustrates exemplary data flows between various components in a system for authenticating a mobile terminal cl ient (e.g. , mobile device) and establishing a pre-shared key, for a successful authentication. For example, the data flows are shown between a secure element 508, a mobi le device 502, a network gateway 520, and an authentication center 540. In at least one embodiment, one or more of secure element 508, mobi le device 502, network gateway 520, and authentication center 540 are sim i lar in form and/or function to secure element 108, mobile device 102, network gateway 120, and authentication center 140, respectively, as shown in FIG. 1 and described in detail above.

[0057| Mobi le device 502 may send a signal (e.g. , request) to trigger the generation of a new pre-shared key (532) to network gateway 520. In response to receiving trigger (532) from mobile device 502, network gateway 520 may check (534) to see whether one or more sets of authentication tuples (e.g. , authentication tokens, identities of entities, secret shared val ues, etc.) are avai lable locally at the network gateway 520. In an exemplary embodiment, the system for authenticating mobi le device 502 and establishing a pre-shared key is designed to operate even when authentication center 540 is unavai lable or inaccessible (i.e., offline). As such, network gateway 520 is configured to periodically request sets of authentication data (e.g. , authentication tuples) from authentication center 540 and store these sets of authentication data for instances when the authentication center is unavailable. Network gateway 520 may use the stored sets of authentication data to run the system in a normal manner, provided that resynchronization is not needed. For example, network gateway 520 may request the fol lowing sets of tuples from the authentication center:

(B, Tokens, Token&4, K _PSK )

The secure element identity, B, is included in the requested sets of tuples, for management purposes at network gateway 520.

|0058| In response to receiving the trigger (532) from mobi le device 502, if network gateway 520 determines (534) that one or more sets of authentication tuples are avai lable local ly, network gateway 520 can send Tdk&xvAB to secure element 508 (e.g. , via the mobi le device 502) and simply verify that the secure element 508 responds with Tokens and a "success" indication (e.g. , where a status included in the TokenZL4 indicates a successful authentication). In such an instance, the new pre-shared key value to use is K/>SK- It should be noted that since TokenBA includes the original sequence number (e.g. , sequence number 3 1 6, or N _/ i), the comparison serves as a verification of the sequence number by network gateway 520, according to an embodiment.

[0059] If network gateway 520 determines (534) that new authentication tuples are needed, network gateway 520 may send a request for authentication tuples (536) to authentication center 540. In response to receiving the request for authentication tuples (536) from network gateway 520, authentication center 540 may generate new authentication tuples (538). In an exemplary embodiment, authentication center 540 generates (538) a set of tuples such as (B, Token/45, TokenZL4, KPSK), and returns (542) the set of generated tuples to the network gateway 520. Upon receiving the set of authentication tuples from authentication center 540, network gateway 520 may save (544) an extended set of tuples. Network gateway 520 may saves (544) an extended set of tuples such as (A, B, Token^I?, TokenBA, KPSK), which includes the identity, A, of authentication center 540/network gateway 520. Network gateway 520 sends an authentication request (546) to mobile device 502, where the authentication request includes TokenAB, together with an identity A of network gateway 520/authentication center 540.

[0060] Upon receiving authentication request (546) from network gateway 520, mobile device 502 may send an AKA command (548) to secure element 508, where the AKA command is sent with Token^i? and identity A. Secure element 508 validates (552) the structure of To enAB {e.g. , in the manner described above) and calculates (e.g. , generates) an authentication token TokenZW ' together with a pre-shared key (KPSK). Secure element 508 returns an AKA response (554) to the mobile device 502 along with TokenBA ' and KPSK- Mobi le device 502 saves (556) K SK for later use, and sends an authentication response (558) back to network gateway 520, where the authentication response includes TokenBA ' generated by secure element 508. Network gateway 520 determines (562) whether the received Tokens ' matches Tokens, which was previously stored in the extended tuples (544). If network gateway 520 determines that TokenBA ' matches TokenBA, network gateway 520 sends (564) an indication back to mobile device 502 that the authentication is successful .

[0061 ] FIG. 6 is a diagram il lustrating exemplary data flows in a system for authenticating a mobile device and establishing a pre-shared key when a resynchronization request is made. For example, the data flows are shown between a secure element 608, a mobi le device 602, a network gateway 620, and an authentication center 640. In at least one embodiment, one or more of the secure element 608, the mobile device 602, the network gateway 620, and the authentication center 640 is similar in form and/or function to secure element 108, mobile device 102, network gateway 120, and authentication center 140, respectively, as shown in FIG. 1 and described in detail above. |0062] In an embodiment, the mobile device 602 sends an AKA command (672) to secure element 608, where the AKA command is sent with Tokeru4jB (token 300 of FIG. 3) and identity _^ 4. For example, mobile device 602 sends the AKA command (672) in response to (or upon) receiving an authentication request from network gateway 620 (e.g., in response to receiving authentication request (546) from network gateway 520 as shown in FIG. 5). Upon analyzing a sequence number (e.g., N#) included in TokenAB, secure element 608 may determine that there is a sequence error in TokerL45, and thus reject TokenAB (674). For example, if the sequence number (e.g. , which is provided for inclusion in TokenAB by authentication center 640) sent in TokenAB is determ ined by secure element 608 to be incorrect or invalid, then that may be interpreted or understood by secure element 608 as indicating that authentication center 640 has an unsynchronized value and resynchronization is thus necessary.

|0063| In an exemplary embodiment, when secure element 608 receives AKA command (672) with TokenAB from mobile device 602, secure element 608 may compare the sequence number (e.g. , N _# ) included in Token^Z? to a current value stored in a sequence counter of the secure element 608 (e.g. , sequence counter 256 in secure element 108 shown in FIG. 2). If the value of the sequence number (Λ¾) is no more than L larger (e.g. , where L is the maximum sequence counter increment, as described above) than the current value stored in the sequence counter (or, stated differently, is with in a threshold difference of the current value stored in the sequence counter), then secure element 608 may accept the sequence number as val id/correct. On the other hand, if secure element 608 determines that the sequence number included in TokenAB does not satisfy such a criteria, secure element 608 may reject (674) TokenAB.

|0064| To achieve resynchronization, secure element 608 may generate (674) Tokens ' to include a new sequence number (N _# ) in place of the sequence number (N _¾ ) that was sent in TokenAB. For example, the value of the new sequence number (N _# ) that may be included in TokenBA ' may be 1 number higher than the current value stored in the sequence counter of the secure element 608 for the particular authentication center 640/network gateway 620 pair involved. [0065] Secure element 608 returns an AKA response (676) to mobile device 602 along with TokenBA '. It should be noted that, unlike the scenario where the secure element val idates the TokenAB (e.g. , data flow/operation (552) in FIG. 5), when secure element 608 determines that resynchronization is needed, the AKA response (676) sent to the mobile device 602 only includes TokeixZL4 ' and does not include the pre-shared key K SK)- Mobi le device 602 sends an authentication response (678) back to network gateway 620, where the authentication response includes Tokens ' generated by the secure element 608. Network gateway 620 determ ines (682) based on, for example, the Status or Result indicator included in Tokens ', that a synchronization error was detected by secure element 608. Network gateway 620 sends a resynchronization request (684) to authentication center 640, where the resynchron ization request includes TokenBA ' together with the identity B of secure element 608.

|0066| In response to receiving the resynchronization request (684) from network gateway 620, authentication center 640 may val idate the resynchronization request, perform a resynchron ization operation, and generate new authentication tuples (686). Authentication center 640 may generate (686) a set of authentication tuples such as (B, TokenAB, TokenBA, KPSK), and return (688) the set of generated tuples to network gateway 620. Upon receiving the set of authentication tuples from authentication center 640, network gateway 620 may save (692) an extended set of authentication tuples. For example, the network gateway 620 may save (692) an extended set of tuples (A, B, Token^i?, Tokens, KPSK), which includes the identity A of the authentication center 640 network gateway 620 pair. Network gateway 620 then sends (694) an indication back to mobile device 602 that the resynchronization was successful .

[0067] FIG. 7 illustrates an exemplary process 700 for authenticating a mobile device and establ ish ing a pre-shared key. For example, process 700 may be performed by a secure element located or installed in a mobile device (e.g. , secure element 108 of mobile device 102, as shown in FIGS. 1-2). In such an embodiment, the secure element may be a UICC or SIM installed in the mobile device.

[0068] At block 705, the secure element of the mobile device may receive an authentication token. For example, the secure element may receive an authentication token sim i lar to token 300 shown in FIG. 3 and described in detail above. In an embodiment, the authentication token received at block 705 may be TokenAB, as described above.

[0069| At block 7 10, the secure element may determine whether the authentication token received at block 705 is valid or correct based on a sequence number included in the first authentication token. For example, the secure element may analyze the sequence number (e.g., N _/ i) included in the received token to determine whether there is a sequence error in the received token . For example, if the sequence number included in the received token is determined by the secure element to be incorrect or invalid, then that may be interpreted or understood by the secure element as indicating that a resynchronization operation is necessary (e.g. , that an authentication center from which the sequence number was provided has an unsynchronized value).

[0070] The secure element may determine (at block 710) whether the authentication token received at block 705 is valid or correct by comparing the sequence number (e.g. , Νβ) included in the received token (e.g., token 300, which may correspond to TokenAB) to a current value stored in a sequence counter of the secure element (e.g. , sequence counter 256 in secure element 108 shown in FIG. 2). If the value of the sequence number (Ng) is no more than L larger (e.g. , where L is the maximum sequence counter increment, as described above) than the current value stored in the sequence counter (or, stated differently, is within a threshold difference of the current value stored in the sequence counter), then the secure element may determine that the sequence number is acceptable and thus the received authentication token is valid. On the other hand, if the secure element determines that the sequence number included in the received token does not satisfy such a criteria, the secure element may determ ine that the received token is invalid (e.g. , resynchronization is needed). j 00 ^* 71 ] In response to determ ining at block 710 that the received authentication token is val id, the secure element may generate a second authentication token (e.g. , token 400, wh ich may also correspond to TokenBA) at block 71 5, where the second authentication token includes an indication of a result of an authentication operation performed by the secure element. [0072 | At block 720, the second authentication token generated at block 71 5 may be sent to a network gateway device. For example, the second authentication token may be sent to a network gateway device simi lar to network gateway device 1 20.

[00731 At block 725, the secure element may derive a pre-shared key (e.g., KI> _S K)- In an exemplary embodiment, the secure element derives the pre-shared key using a key derivation function such as, for example, the ANSI X9.63 key derivation function. The derived key may be usable to establish a secure communication channel (e.g. , TLS) between the mobile device and the network gateway device.

|0074| FIGS. 8 and 9 are block diagrams illustrating additional exemplary systems for authenticating a connected device and establishing a pre-shared key. It should be noted that one or more of the components in the example systems 800 and 900 shown in FIGS. 8-9, respectively, may be similar in function and/or form to one or more corresponding components in the example system 1 00 shown in FIG. 1 and described in detail above.

[0075] FIG. 8 shows an example system 800 for authenticating a connected device and establishing a pre-shared key, where the system 800 is implemented in a motor vehicle (e.g., car, truck, bus, motorcycle, etc.). In accordance with an embodiment, a mapping appl ication 870 instal led in a vehicle 850 is configured to utilize a modem 876 that includes a secure element (e.g. , UICC) 808. Mapping appl ication 870 communicates via a radio interface 822 with a network gateway 820 to the Internet 816.

|0076| I n an embodiment, the A A application (as described above) is configured to run on secure element 808 present in modem 876 to establish a pre-shared key between the modem 876 (or mapping application 870) and secure network gateway 820. It should be noted that whi le the present example is described in the context of mapping application 870, a pre-shared key may also be provided for use by various other applications running in the veh icle 850 in addition to or instead of mapping application 870. For example, the pre-shared key may be provided for use by a telemetry application or some other application that typically rel ies on a secure data communication channel.

[0077] In an embodiment, the AKA application running on the secure element 808 may be used together with an authentication center 840 (e.g. , server) to establish a secure TLS communication channel between mapping application 870 and network gateway 820. In at least one embodiment, a USIM application running on secure element 808 acts as the authentication module for the cellular radio link within vehicle 850.

|0078| FIG. 9 shows an exemplary system 900 for authenticating a connected device and establishing a pre-shared key, where system 900 is implemented in a home security application running on a smart hub 960, which may include a secure element 908 (e.g. , UICC) that is connected to or includes a plurality of sensor devices 966- 1 , 966-2, and 966-3. It should be noted that while the present example is described in the context of a home security appl ication running on a smart hub 960, system 900 may be implemented in the broader "Internet of Things" (IoT) context, and encompass various other types of inter-networked devices.

|0079| In an embodiment, smart hub 960 is configured to operate on a wireless local area network (e.g., in accordance with one or more communication protocols that conform to the I EEE 802. 1 1 Standards or other wireless standards) of a house, and connect, via Wi-Fi Router 972 and the Internet 91 6 to a server 980 of the home security system provider associated with the home security appl ication. In at least one embodiment, smart hub 960 uti l izes TLS to secure this connection to home security server 980. Smart hub 960 may also be configured to use a cel lular modem 974 to communicate to home security server 980 where, for example, the Wi-Fi connection is unavailable.

[0080) The A A appl ication runn ing on secure element 908 may be used together with an authentication center 940 (e.g. , server) to establish a secure TLS communication channel between smart hub 960 and home security server 980. In at least one embodiment, the system 900 does not include the cellular modem 974, and thus, secure element 908 need not contain a USIM appl ication.

[00811 In some embodiments, the secure element (e.g. , secure element 108, 808, 908, etc.) containing the AKA appl ication described above may be a removable UICC in any of a variety of form factors including, but not lim ited to, 2FF (e.g. , mini-SIM card), 3FF (e.g. , m icro-SIM card), and 4FF (e.g. , nano-SIM card). The secure element may also be a UICC in any of a variety of embedded form factors, including, but not limited to, MFF2 (e.g. , chip SIM, a QFN8 package), DFN8, and WLCSP. [0082] At least some of the various blocks, operations, and techniques described above may be implemented utilizing hardware, a processor executing firmware instructions, a processor executing software instructions, or any combination thereof. When implemented uti l izing a processor executing software or firmware instructions, the software or firmware instructions may be stored in any non-transitory computer readable memory such as on a magnetic disk, an optical disk, or other storage medium, in a RAM or ROM or flash memory, processor, hard disk drive, optical disk drive, tape drive, etc. The software or firmware instructions may include mach ine readable instructions that, when executed by one or more processors, cause the one or more processors to perform various acts such as those described above.

|0083] When implemented in hardware, the hardware may comprise one or more of discrete components, an integrated circuit, an application-specific integrated circuit (ASIC), a programmable logic device (PLD), etc.

[0084] Al l references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

|0085] For the purposes of promoting an understanding of the principles of the invention, reference has been made to the embodiments illustrated in the drawings, and specific language has been used to describe these embodiments. No limitation of the scope of the invention is intended by this specific language, and the invention should be construed to encompass all embodiments that would normally occur to one of ordinary skill in the art. Descriptions of features or aspects within each embodiment should typically be considered as available for other similar features or aspects in other embodiments unless stated otherwise. The term inology used herein is for the purpose of describing the particular embodiments and is not intended to be l imiting of exemplary embodiments of the invention. In the description of the embodiments, certain detai led explanations of related art are omitted when it is deemed that they may unnecessari ly obscure the essence of the invention.

[0086| The use of any and al l examples, or exemplary language (e.g. , "such as") provided herein, is intended merely to better i l lum inate the invention and does not pose a lim itation on the scope of the invention unless otherwise claimed. Numerous modifications and adaptations wil l be readily apparent to those of ordinary skill in this art without departing from the scope of the invention as defined by the following claims. Therefore, the scope of the invention is defined not by the detai led description of the invention but by the following claims, and al l differences with in the scope wi l l be construed as being included in the invention.

[0087| No item or component is essential to the practice of the invention un less the element is specifical ly described as "essential" or "critical". It wil l also be recogn ized that the terms "comprises," "comprising," "includes," "including," "has," and "having," as used herein, are specifically intended to be read as open-ended terms of art. The use of the terms "a" and "an" and "the" and sim i lar referents in the context of describing the invention (especially in the context of the fol lowing claims) are to be construed to cover both the singular and the plural, unless the context clearly indicates otherwise. In addition, it should be understood that although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms, which are only used to distinguish one element from another. Furthermore, recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value fal ling with in the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein.