Patent ID: 12238080

Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

DETAILED DESCRIPTION

Examples disclosed herein are directed to a method comprising: establishing an association with a communications network in a first connection time period; via an authentication session with an authentication server of a communications network in an authentication time period following the first connection time period, obtaining at least one key value for use in accessing the communications network; storing reauthentication data associated with the at least one key value; responsive to disconnecting from the communications network, discarding the at least one key value and retaining the reauthentication data; responsive to a reconnection command: deriving the at least one key value from the reauthentication data, establishing a further association with the communications network in a second connection time period by sending an association request to the communications network, the association request containing the at least one key value, and accessing network resources via the communications network following the second connection time period.

Additional examples disclosed herein are directed to a computing device, comprising: a memory; a communications interface; and a controller configured to: establish an association with a communications network in a first connection time period; via an authentication session with an authentication server of the communications network in an authentication time period following the first connection time period, obtain at least one key value for use in accessing the communications network; store, in the memory, reauthentication data associated with the at least one key value; responsive to detecting a disconnection from the communications network, discard the at least one key value and retaining the reauthentication data; responsive to a reconnection command; derive the at least one key value from the reauthentication data, establish a further association with the communications network in a second connection time period by sending an association request to the communications network, the association request containing the at least one key value, and access network resources via the communications network following the second connection time period.

Further examples disclosed herein are directed to a non-transitory computer readable medium storing instructions executable by a controller of a computing device having a memory and a communications interface, to: establish an association with a communications network in a first connection time period; via an authentication session with an authentication server of the communications network in an authentication time period following the first connection time period, obtain at least one key value for use in accessing the communications network; store, in the memory, reauthentication data associated with the at least one key value; responsive to detecting a disconnection from the communications network, discard the at least one key value and retaining the reauthentication data; responsive to a reconnection command: derive the at least one key value from the reauthentication data, establish a further association with the communications network in a second connection time period by sending an association request to the communications network, the association request containing the at least one key value, and access network resources via the communications network following the second connection time period.

FIG.1illustrates a communications system100implementing an authenticated network. For example, the network implemented by the system100can be a private corporate or other institutional network. In the system100, network resources104such as data, application servers, or the like, are accessible to a client device108via one or more access points (APs)112, such as a wireless access point implementing a WiFi or other suitable network. Although a single AP112is shown inFIG.1, it will be apparent that the system100can include a plurality of APs112, disposed throughout a facility or other physical area according to the size and other physical characteristics of the facility. Further, it will be understood that a plurality of client devices108can be present in the system100, although a single device108is shown for illustrative purposes. The client device108can be a mobile computer such as a laptop, a tablet, a smart phone, or the like.

The network implemented by the system100is an authenticated network, in which the client device108(and any other client devices attempting to access the network resources104) is permitted to access the network resources104only after completing an authentication process, also referred to herein as an authentication session. To that end, the system100includes an authentication server116connected to the AP112. The AP112is configured, in response to receiving a connection request from the device108(also referred to as an association request), to determine whether the device108has been authenticated (e.g. granted permission by the authentication server116to access the network resources104). When the device108has not yet been authenticated, the AP112permits the device108to communicate only with the authentication server116, to perform an authentication process.

The authentication process can be conducted according to the Extensible Authentication Protocol (EAP), which specifies various methods of authenticating the device108to access the network resources104. In general, the authentication process includes a sequence of messages exchanges between the device108and the authentication server116, via the AP112. The messages provide an identity associated with the device108(e.g. an account name or the like) to the authentication server116, and can also include a challenge response such as a password or the like. At the conclusion of the authentication process, presuming that authentication was successful, the client device108and the AP112are provisioned by the authentication server116with at least one key value for subsequent use in accessing the network resources104.

The authentication process mentioned above can involve an exchange of about 20 frames of data, and can extend over a time period of about two seconds, dependent on the specific implementation of the system100. During the authentication process, certain computational load is imposed on the authentication server116, the AP112, and the client device108. Further, the exchange of messages contributes to at least a certain degree to congestion in the network. Still further, during the authentication process, the device108is unable to access the network resources104.

If the device108disconnects from the network (e.g. disassociates from the AP112without associating with another AP in the same network), the above-mentioned key values, which are not stored persistently, are automatically discarded by the device108. Therefore, when the device108attempts to reconnect to the AP112, the authentication process is repeated, consuming further system resources, even when the disconnection was brief and/or accidental (e.g. due to physical interference, loss of power at the device108, or the like).

The device108therefore also implements additional functionality, as discussed below, to mitigate the need to repeat the authentication process upon reconnecting to the network, thus reducing downtime for the device108(i.e. time during which the network resources104are unavailable to the device108) as well as reducing load on the remainder of the system100.

Certain internal components of the device108are also illustrated inFIG.1. Specifically, the device108includes a central processing unit (CPU), also referred to as a processor150, interconnected with a non-transitory computer readable storage medium, such as a memory154. The memory154includes any suitable combination of volatile (e.g. Random Access Memory (RAM)) and non-volatile (e.g. read only memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash) memory. The processor150and the memory154each comprise one or more integrated circuits (ICs).

The device108also includes a communication interface158, enabling the device108to exchange data with other computing devices, including the AP112and (via the AP112) the authentication server116and the network resources104. The communication interface158includes any suitable hardware (e.g. transmitters, receivers, network interface controllers and the like) and associated firmware, software and the like allowing the client device108to communicate as set out above. As illustrated inFIG.1, the interface158includes a controller160, such as an integrated circuit distinct from the processor150, that is configured to execute the authentication process mentioned above, and to obtain and store the key value(s) while the device108is connected to the network.

The memory154stores a plurality of applications, each including a plurality of computer readable instructions executable by the processor150. The execution of the above-mentioned instructions by the processor150causes the device104to implement certain functionality, as discussed herein. The memory154and the processor150can also implement a secure storage subsystem, e.g. including a secure memory164and a cryptographic controller or other suitable execution hardware element with exclusive access to the secure memory164. The specific implementation of the secure storage subsystem may vary between different client devices108. For example, in some implementations the memory164and controller168can be implemented as a separate circuit distinct from the memory154and the processor150.

The secure storage subsystem is configured to store cryptographic keys, and to control access to such keys. For example, the Android Keystore implementation of the secure storage subsystem prevents release of key material stored therein to other portions of the device108. That is, other applications executing on the device108, such as applications stored in memory154, or the controller160, can send requests to the controller168that make use of key material stored therein, and be provided the output of such operations, but may be prevented from accessing the key material itself.

The device108can be configured to make use of the secure storage subsystem to facilitate reconnection to authenticated networks when authentication has previously been completed, as will be described below in greater detail.

The client device108can also include at least one input device, and at least one output device (not shown) interconnected with the processor150. The input device(s) can include any suitable one, or any suitable combination of, a microphone, a camera, a touch screen, a keypad, a trigger (e.g. to initiate the performance of any encoding task), and the like. The output device(s) can include any suitable one, or any suitable combination of a display (e.g., integrated with the above-mentioned touch screen), a speaker, and the like.

The components of the device108are interconnected by communication buses, and powered by a battery or other power source, over the above-mentioned communication buses or by distinct power buses.

Turning now toFIG.2, a method200of accelerated reconnection in authenticated networks. The method200will be described in conjunction with its performance in the system100. More specifically, the method200as described below is performed by the client device108.

At block205, the device108is configured to associate with the AP112and initiate the authentication process. More specifically, when the device108sends an association request to the AP112, the AP112is configured to determine whether the AP112has been provisioned (by the server116) with authentication data for the device108, in the form of the above-mentioned key value(s). It is assumed in this example that the device108has not previously authenticated with the network. Therefore, the AP112directs the device108to the authentication server116, and the device108and server116exchange the message sequence mentioned earlier. As will be apparent, the association process itself, establishing a link between the device108and the AP112, consumes a first time period, also referred to as a connection time period. The authentication process described below, when required, consumes a second time period (also referred to as an authentication time period) following the first time period.

If the authentication process fails, the device108is denied access to the network, and the performance of the method200ends. When the authentication process is successful, at block210the device108obtains at least one key value. In the context of an EAP-based authentication process, the key value includes a pairwise master key (PMK), which is also provided to the AP112. From the PMK, the AP112can assign a PMKID to the device108. The PMKID can be derived (e.g. via a hashing algorithm) from a combination of the PMK, a network address of the AP112, and a network address of the client device108(e.g. MAC addresses of the AP112and device108). The PMKID is an identifier unique to the device108, and indicates to the AP112in subsequent communications that the device108has been authenticated. Other examples of key values obtained by the device108at block210can include a PMK security association (PMKSA), which associates the PMKID with other information, such as a lifetime of the PMK. The device108can maintain a distinct PMKSA (based on the same underlying PMKID) for each AP112in the network with which the device108has associated, to enable roaming without reauthentication.

The key values mentioned above, which are employed by the device108to subsequently access the network resources104(as described below in connection with block220), are themselves derived from underlying key material. For example, in response to successful authentication at block205, the performance of block210can include the generation of an intermediate key, such as the root key in the EAP process. Subsequent key values, including a master session key (MSK), from which the above-mentioned PMK is derived, are in turn derived from the root key or other suitable intermediate key. In some systems, such intermediate keys are discarded upon use to generate the MSK, PMK and the like. The device108, however, as will be seen below, is configured to retain an intermediate key for later use during a reconnection process.

Turning briefly toFIG.3, an example performance of blocks205and210are illustrated. As shown inFIG.3, the device108establishes, via the communications interface158, a link with the AP112, and is directed to complete an sequence300of messages with the authentication server116. Completion of the authentication process represented by the sequence300results in the AP112and the communications interface158being provisioned with at least one key value304, as described above. The at least one key value304is maintained in volatile memory at the communications interface158. That is, the at least one key value304is not stored persistently. As noted above, obtaining the at least one key value304is accomplished by obtaining intermediate key value(s)308, such as the above-mentioned root key, from which the key value(s)304are derived. The intermediate key value(s) are therefore retained, temporarily, at the communications interface158for use in generating the key value(s)304.

Returning toFIG.2, following completion of block210the device108proceeds to block215. At block215, the device108stores, in a persistent storage element (as opposed to the volatile storage of the key value(s)304mentioned above), reauthentication data that is associated with the key value(s)304. To mitigate the introduction of security risks by persistent storage of the key value(s)304, the reauthentication data is not the key values304themselves, but rather at least one intermediate key associated with the key value(s)304. For example, the controller160or the processor150can be configured, instead of discarding the intermediate key value(s)308after generation of the key value(s)304, to persistently store the intermediate key value(s)308as reauthentication data.

The device108is configured to store the reauthentication data in the secure memory164. As will be apparent in the discussion below, storage of the reauthentication data in the secure memory164, which is a persistent storage device, such as flash memory, enables the use of the reauthentication data after the device108has disconnected from the AP112. In contrast, the key value(s)304stored at the communication interface158are not stored persistently, and are therefore discarded automatically when the connection between the device108and the AP112ends.

At block220, the device108is configured to access the network resources104via the AP112. In particular, as will be apparent, following the successful completion of the authentication process, the key value(s)304can be used in a handshake process (e.g. a four-way handshake) between the device108and the AP112to generate additional cryptographic keys that are used to encrypt communications between the device108and the network. For example, the PMK can be employed during the handshake process to generate either or both of a pairwise transient key (PTK) and a group transient key (GTK) for encrypting further communications.

Referring toFIG.4, the controller160and/or the processor150can generate a request400, e.g. using a suitable application programming interface (API), to the controller168to store reauthentication data associated with the key value(s)304. In the illustrated example, the reauthentication data includes the intermediate key(s)308, and is stored in the secure memory164as shown, although no longer stored at the communications interface158itself (having been discarded upon successful generation of the key value(s)304). Meanwhile, the device108is enabled, via completion of the authentication process and the keys obtained via the handshake process above, to access the network resources104in a communication session408.

At block225, the device108is configured to determine whether a disconnection event has occurred. A disconnection event is a loss of connection to the network, rather than a disassociation from the AP112and association with another AP of the network. That is, a disconnection event is distinct from a roaming event. The disconnection event can occur because of a loss of signal from the AP112, e.g. due to physical interference imposed by objects near the device108. In other examples, the disconnection event can result from a loss of power to the device108, whether resulting from a loss of battery power or from a shutdown command selected by an operator of the device108. Various other types of disconnection events will also be apparent from the above.

In general, the disconnection event results in the device108having no remaining association with the AP112or any other AP of the network in the system100. When no disconnection event is detected, access of the network resources104can continue at block220. When a disconnection event is detected, however, the device108proceeds to block230.

In addition, as mentioned above, upon the occurrence of a disconnection event, the key value(s)304are automatically discarded at the communications interface158, because the key value(s)304are not stored persistently. For example, the key value(s)304may be stored only in volatile memory at the communications interface158, which is cleared upon a connection loss. Therefore, as shown inFIG.5, the loss of connection between the AP112and the device108results in the communications interface158discarding the key values304. The reauthentication data in the form of the key value(s)308, however, is maintained in the secure memory164after the disconnection. As also shown inFIG.5, the AP112continues to store the key value(s)304, e.g. for a configurable period of time, after which the key value(s)304are also discarded from the AP112if there has been no further activity by the device108on the network.

As discussed below, beginning at block230, the device108performs certain actions to attempt to reconnect to the network without needing to repeat the authentication process mentioned earlier. The performance of block230can follow the affirmative determination at block225by a wide variety of time periods. For example, in the case of an interference-related loss of connectivity, the performance of block230may occur only a few seconds, or even less, after block225. However, in some cases, the disconnection event may result from the device108being turned off, and the performance of block230can occur minutes or hours later, e.g. the next day.

At block230, following a command to reconnect to the AP112(or another AP in the network of the system100), the device108is configured to determine whether reauthentication data corresponding to the network is stored in the secure memory164. For example, the AP112can broadcast (e.g. in beacon frames or the like) a basic service set identifier (BSSID) that identifies the network of which the AP112is a part. The device108, e.g. the controller160, can store a list of identifiers of network identifiers, and can automatically attempt to connect to any networks on the list when such network identifiers are detected in beacons or other broadcasts from access points.

The reauthentication data (e.g. the intermediate keys308) can be stored in the secure memory164along with a network identifier, such as the above-mentioned BSSID. Therefore, upon detecting a broadcast from the AP112containing the BSSID, the controller160and/or the processor150can query the secure memory (via the controller168) to determine whether the secure memory164contains any entries corresponding to the BSSID. When the determination at block230is negative, the device108returns to block205, and begins the authentication process mentioned above. In some examples the secure memory164can be configured to purge key material after a certain period of time, and therefore if sufficient time has elapsed between blocks225and230, the reauthentication data may no longer be present in the secure memory164.

In other examples, when the determination at block230is affirmative, the device108is configured to proceed to block235. At block235, the device108is configured to retrieve the key value(s)304using the reauthentication data. The device108can therefore retrieve the intermediate key value(s)308from the secure memory164via a suitable API call, and derive the key value(s)304from the intermediate key value(s)308. In other examples, the device108can instead be configured to send a request to the controller158to perform a derivation operation on the reauthentication data within the secure storage164. A request600is shown inFIG.6, causing the controller168to perform an operation on the reauthentication data that yields, as an output, either the intermediate key value(s)308themselves, or the key value(s)304, or at least a portion thereof. For example, the request can be a request to decrypt the intermediate keys308and send the intermediate keys308to the communications interface158, whereupon the controller160of the communications interface158can use the intermediate keys308to generate the key values304, e.g. the PMK, the PMKID and PMKSA.

As also shown inFIG.6, the communications interface158once again stores the key value(s)304, recovered from the reauthentication data. Returning toFIG.2, at block235the device108also generates and sends an association request to the AP112, to reconnect to the network. The association request can include an information element, such as a robust security network information element (RSNIE) containing the key value(s)304, or at least a portion thereof. For example, the association request can include an RSNIE containing the PMKID.

At block240, the device108is configured to determine whether reauthentication is necessary. The determination at block240is made according to the access point's response to the association request from block235. In particular, the AP112is configured, in response to receiving an association request containing the PMKID, to determine whether a matching PMKID is still stored at the AP112, indicating that the client device108has been authenticated. When the key value(s)304are still stored at the AP112, the device108and the AP112repeat the handshake process mentioned above, and the device108can then resume accessing the network resources104, without reauthenticating. In that case, the determination at block240is negative, and the device108can proceed to block220. As will now be apparent, when the determination at block240is negative, the device108can resume access of the network resources104following only a connection time period equivalent to the association time period mentioned in connection with block205. That is, the reconnection process does not consume both a connection time period and an authentication time period.

The AP112can also maintain a rule specifying a time period beyond which any inactive key value(s) (e.g. authentication data corresponding to a device that has not communicated with the AP112in the above time period) are discarded. In some cases, therefore, the response from the AP112to the association request indicates that reauthentication is required. The determination at block240is therefore affirmative, and the device108returns to block205.

As will now be apparent, performance of the method200enables the device108to avoid, under at least some conditions, reauthenticating with the server116after a disconnection event. Therefore, the device108may restore access to the network resources104by performing a handshake process to obtain the PTK and GTK, without the additional sequence of messages exchanged with the server116at block205. Reconnection may therefore consume less time, e.g. about 0.5 seconds, in comparison to reauthentication. Reconnection may therefore also impose reduced demands on the system100than reauthentication.

In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.

The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

It will be appreciated that some embodiments may be comprised of one or more specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.

Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.