Key Agreement for EAPOL Handshake Using Distributed Computing

Abstract

1. Field of the Invention [0002] Embodiments herein relate to the field of communications, and more particularly, embodiments herein relate to key agreement for extensible authentication protocol over local area network (EAPOL) handshakes using distributed computing. Other embodiments may also be described and claimed.

Description

[Technical Field]

[0001]

[0002] TECHNICAL FIELD Embodiments herein relate to the field of communications, and more particularly to key agreement for extensible authentication protocol over local area network (EAPOL) handshakes using distributed computing.

[0002]

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 069,553, filed August 24, 2020, entitled "KEY MATCHING FOR EAPOL HANDSHAKE USING DISTRIBUTED COMPUTING," the entire disclosure of which is incorporated by reference. [Background technology]

[0003]

[0003] In a local area network (LAN), including a wireless local area network (WLAN) and / or a wired LAN, a client device (e.g., called a supplicant) authenticates with an access point using the Extensible Authentication Protocol over LAN (EAPOL) four-way handshake process. Summary of the Invention

[0004]

[0004] Embodiments will be readily understood from the following detailed description taken in conjunction with the accompanying drawings and appended claims, and are illustrated by way of example, and not limitation, in the figures of the accompanying drawings. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 illustrates an example of an EAPOL four-way handshake process according to various embodiments. [Figure 2A] FIG. 1 illustrates an example of a distributed key matching process according to various embodiments. [Figure 2B]FIG. 1 illustrates an example of a distributed key matching process according to various embodiments. [Figure 2C] FIG. 1 illustrates an example of a distributed key matching process according to various embodiments. [Figure 3] FIG. 1 illustrates an exemplary computing device for implementing various aspects of the present disclosure. [Figure 4] FIG. 1 is a block diagram illustrating a computer-readable storage medium and programming instructions for performing any one or more of the methodologies discussed herein. [Figure 5A] FIG. 1 illustrates an example of a process according to various embodiments. [Figure 5B] FIG. 1 illustrates an example of a process according to various embodiments. [Figure 5C] FIG. 1 illustrates an example of a process according to various embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0006]

[0010] In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and which show, by way of illustration, embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. Therefore, the following detailed description is not to be taken in a limiting sense.

[0007]

[0011] Although various operations may be described in sequence as multiple discrete operations, which may be helpful in understanding the embodiments, the order of description should not be construed to imply that these operations are order dependent.

[0008]

[0012] The present description may use perspective-based descriptions such as up / down, back / front, and top / bottom, etc. Such descriptions are used for ease of discussion only and are not intended to limit the application of the disclosed embodiments.

[0009]

[0013] The terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Rather, in particular embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other.

[0010]

[0014] For purposes of description, a phrase in the form "A / B" or in the form "A and / or B" means (A), (B), or (A and B). For purposes of description, a phrase in the form "at least one of A, B, and C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). For purposes of description, a phrase in the form "(A)B" means (B) or (AB), i.e., A is an optional element.

[0011]

[0015] The terms "embodiment" or "embodiments" may be used herein, and may each refer to one or more of the same or different embodiments. Furthermore, terms such as "comprising," "including," and "having," when used with respect to embodiments, are intended to be synonymous and generally "open" terms (e.g., the term "comprising" should be interpreted as "including, but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "including, but not limited to," etc.).

[0012]

[0016] With respect to the use of any plural and / or singular terms herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural as appropriate to the context and / or application. For clarity, the various singular / plural permutations may be expressly set forth herein.

[0013]

[0017] Embodiments herein provide techniques for distributed key reconciliation across multiple computing elements (e.g., including one or more processors). In embodiments, a key reconciliation manager may receive a reconciliation request from a local area network (LAN) access point as part of an Extensible Authentication Protocol over LAN (EAPOL) process associated with a client device. The reconciliation request may include an offered key provided by the client device and key information used to generate the offered key (e.g., a station nonce (SNonce) value generated by the client device, an access point nonce (ANonce) value generated by the access point, a media access control (MAC) address of the client device, a MAC address of the access point, a service set identifier (SSID) of the LAN and / or the access point, and / or other information).

[0014]

[0018] The key match manager may determine the number of keys that may be valid for authentication with the LAN. For example, the key match manager may request the number of valid keys from a service area information server. The key match manager may determine indexing information based on the number of keys, where the indexing information is for assigning keys to multiple partitions based on a portion (e.g., prefix) of each key. In some embodiments, the size (e.g., in bits) of the portion of the key used for the indexing information may be determined by the key match manager to separate the keys into subgroups of desired sizes that may be assigned to each partition. For example, the size of the portion of the key may be determined based on the number of valid keys.

[0015]

[0019] In various embodiments, each partition may be assigned to a different computational element for matching against the provided key. In some embodiments, the indexing information may be determined based on the computational capacity of the computational element. Thus, different computational elements may be assigned different numbers of valid keys and / or may be used in the matching process depending on their respective computational capacities.

[0016]

[0020] In various embodiments, the key match manager may send the submitted key, the indexing information for each partition, and the key information (e.g., SNonce value, ANonce value, etc.) to a computation element to perform matching of the key with each partition. If a match is successfully found, the key match manager may receive a notification of the match (e.g., including the matched key) from the computation element that successfully found the match.

[0017]

[0021] Although embodiments are described herein with reference to the EAPOL four-step handshake process, the techniques described herein may be used for key matching in other processes or contexts, particularly where the set of valid keys has randomly distributed values ​​(e.g., bit strings).

[0018]

[0022] 1 illustrates an example of an EAPOL four-way handshake process 100 (hereinafter "process 100") according to various embodiments. Process 100 may be performed by a client device 102 (e.g., a supplicant) and an access point 104. In various embodiments, process 100 may further include a key reconciliation service 106 for offloading key reconciliation, as discussed further below. An example of the key reconciliation service 106 is discussed in more detail with respect to FIG. 2A.

[0019]

[0023] The client device 102 may be provided with a pre-shared key (PSK) for establishing a connection with the access point 104. The access point 104 may support multiple PSKs (e.g., for the same SSID). For example, different PSKs may be used by different client devices 102 and / or groups of client devices 102 to access the access point 104's network. In some embodiments, the PSK may be used to generate a pairwise master key (PMK). For example, the PMK may be generated based on the PSK and the SSID of the access point 104.

[0020]

[0024] At 108 of the process 100, the client device 102 may generate a first random sequence (e.g., referred to as a station nonce (SNonce)). At 110 of the process 100, the access point 104 may generate a second random sequence (e.g., referred to as an access point nonce (ANonce)). At 112 of the process 100, the access point 104 may transmit a first frame (frame 1) to the client device 102. Frame 1 may include the ANonce value generated by the access point 104.

[0021]

[0025] The client device 102 may generate a pairwise transient key (PTK) based on the SNonce, the ANonce, and the PMK (which may be generated based on the PSK and the SSID). In some embodiments, the PTK may be generated further based on the MAC address of the client device 102 and / or the MAC address of the access point 104. For example, the PTK may be a pseudo-random function (e.g., a hash function) of the SNonce, the ANonce, the PMK, the MAC address of the client device 102, and the MAC address of the access point 104. The client device 102 may further generate a message integrity check (MIC). The MIC may be generated, for example, based on a checksum of the frame 2 message using the PTK.

[0022]

[0026] At 114 of process 100, client device 102 may transmit a second frame (frame 2) to access point 104. Frame 2 may include an SNonce generated by client device 102. In some embodiments, frame 2 may further include a MIC and / or other information, such as a protocol, a replay counter, extended data, and / or key information.

[0023]

[0027] At 116 of process 100, the access point 104 may send a match request to the key match service 106. The match request may include the ANonce value and some or all of the contents of frame 2 (e.g., the SNonce value) addressed to the key match service 106. The match request may further include the MAC address of the access point 104, the MAC address of the client device 102, and / or the SSID of the LAN. The key match service 106 may use this information to generate a MIC for each PMK and / or PSK and match the generated MIC against a set of valid keys that are valid for authentication. As further described with respect to FIG. 2A, the key match service 106 may allocate valid keys among multiple computational elements to search for a match with the PMK and / or PSK generated from the ANonce value, frame 2 information, and / or other information (e.g., the MAC addresses of the access point 104 and / or client device 102, and / or the SSID of the LAN).

[0024]

[0028] At 118 of process 100, the key matching service 106 may send a matching result, e.g., a notification of whether or not it was successful in finding a PMK and / or PSK match among the valid keys, to the access point 104. Thus, the access point 104 does not need to perform the computationally intensive matching process itself. In some embodiments, the matching result at 118 may further include the PMK and / or PSK and / or other information to identify the PMK and / or PSK. Thus, the access point 104 may not need to calculate the PMK and / or PSK from the ANonce and SNonce values ​​itself.

[0025]

[0029] At 120 of process 100, the access point 104 may send a result message (e.g., referred to as frame 3) to the client device 102. The result message may indicate whether the match was successful or not. If the match was successful, the result message may include further information, such as a group temporal key (GTK), which may be generated based on a group master key (GMK).

[0026]

[0030] At 122 of process 100, client device 102 may send an acknowledgment of the result message (e.g., referred to as frame 4). If the match is successful, client device 102 is authenticated by process 100 and may thereafter access network services via access point 104 (e.g., using one or more keys generated as part of process 100).

[0027]

[0031] 2A illustrates a process 200 and associated architecture for performing distributed key reconciliation, according to various embodiments. Process 200 may be performed by key reconciliation service 106 of FIG. 1. The key reconciliation architecture may include, for example, a key reconciliation manager 202, a service area information server 204, a key storage server 206, and / or a distributed computing element 208. Key reconciliation manager 202 may include, for example, an application programming interface (API). Distributed computing element 208 may include multiple separate computing elements, each including one or more processors. In some embodiments, at least some of computing elements 208 may be cloud-based.

[0028]

[0032] The service area information server 204 may store information related to the LAN, such as the number of keys associated with the LAN's SSID. In some embodiments, the service area information server 204 may be combined with the key matching manager 202 or may be included in a separate device / entity. The service area information server 204 may store information about sites that are authorized to utilize the EAPOL matching service and the settings for those sites. In addition to the SSID and key count, other tags and / or attributes (e.g., metadata) may be stored with the site information.

[0029]

[0033] The key storage servers 206 may store valid keys (e.g., PSKs and / or PMKs) for SSIDs / access points. In some embodiments, the key storage servers 206 may be organized hierarchically by PMK prefix.

[0030]

[0034] At 210 of process 200, key match manager 202 may receive a match request. The match request may be received from an access point of the LAN. For example, the match request may correspond to the match request at 116 of process 100. The match request may include the ANonce value generated by the access point and frame 2 information provided by the client device (e.g., the SNonce value and / or other frame 2 information). The match request may further include other information necessary to determine the PTK, PMK, and / or PSK, such as the MAC address of the client device and / or the MAC address of the access point.

[0031]

[0035] At 212 of process 200, key match manager 202 may send a request for information related to the LAN to service area information server 204. The request may include an identifier for the LAN, such as the SSID of the LAN.

[0032]

[0036] At 214 of process 200, service area information server 204 may send a response to the request to key match manager 202. The response may include the number of valid keys for the LAN / SSID. In some embodiments, the response may include additional information, such as the status of the LAN (e.g., an indication of whether the site was found and / or metadata intended to affect the processing of the match request or the content of the response to the request (in addition to the matched key)), and / or metadata associated with the LAN.

[0033]

[0037] At 216 of process 200, key match manager 202 may determine indexing information based on the number of keys. The indexing information may assign keys to multiple partitions based on a prefix of the key (e.g., the first one or more bits and / or bytes of the key). Although process 200 is described herein with respect to a prefix of the key, it will be understood that other portions of the key may be used instead to divide the key.

[0034]

[0038] In various embodiments, key matching manager 202 may not own or receive the keys themselves. However, PMK values ​​are randomly distributed by the cryptographic operations that generate them. Therefore, key matching manager 202 uses this property of PMKs to distribute PMKs into partitions based on key prefixes.

[0035]

[0039] In some embodiments, the indexing information may assign keys to partitions further based on the computational capacity of the distributed computational elements. For example, the key match manager 202 may determine the maximum number of keys that an individual computational element can process for the matching process while meeting latency requirements for providing matching results. In some embodiments, the maximum number of keys may be a predefined value (e.g., based on the configuration of the computational element and / or other parameters of the matching system). In some embodiments, the computational elements may have the same computational capacity (e.g., the maximum number of keys that can be processed within the latency requirements). The key match manager 202 may determine the minimum number of computational elements that can be used to match submitted keys based on the number of valid keys and the maximum number of keys that can be processed by each computational element. The key match manager 202 may determine the size of the prefix used to partition valid keys based on the determined minimum number of computational elements. For example, the minimum number of computational elements required may be determined by dividing the number of valid keys by the maximum number of keys that can be processed by each computational element, and rounding up to the next integer. For example, if there are 150 valid keys and the maximum number of keys processed by each computation element is 50, then three computation elements are required. However, if there are 151 (or 152-200) valid keys, then four computation elements are required.

[0036]

[0040] In some embodiments, the determined prefix size may correspond to a bit sequence having a lowest number of possible values ​​that is greater than the minimum number of computational elements required. For example, if it is determined that four computational elements are required, a two-bit prefix (with four possible values) may be used to divide valid keys into four partitions that are processed by four computational elements. If it is determined that five computational elements (or six, seven, or eight computational elements) are required, a three-bit prefix (with eight possible values) may be used to divide valid keys into eight partitions that are processed by eight computational elements.

[0037]

[0041] For example, the size of the prefix may be determined based on a base-N logarithmic function of the minimum number of computational elements required. The value of N may correspond to the number of different values ​​of each element (e.g., bit) in the prefix (e.g., N=2 for a binary key). To determine the size of the prefix, the result of the base-N logarithmic function may be rounded up to the next integer.

[0038]

[0042] Alternatively, in some embodiments, different distributed computing elements may have different computing capacities (e.g., based on the configuration of the computing elements and / or their current processing loads). The key match manager 202 may assign keys to partitions to balance the processing loads, e.g., to optimize overall throughput / latency.

[0039]

[0043] The key match manager 202 may determine the computational capacity of the distributed computational elements based on traffic monitoring information and / or capacity information associated with the individual computational elements 208. The computational capacity may include one or more parameters such as network performance metric(s), call latency, and / or processing capacity / capability.

[0040]

[0044] In various embodiments, key match manager 202 may determine the length of the prefix used to divide the keys based on the number of keys and / or the computational capacity of the distributed computational elements. The length of the prefix determines the granularity (e.g., the number of one or more keys) at which the corresponding keys can be assigned to groups. Thus, key match manager 202 may determine the desired granularity of the distribution of valid keys searched by each of several computational elements 208 and determine the prefix length based on the desired granularity. If the computational capacity of the computational elements is the same (e.g., if the computational capacity is predefined), each value of the prefix may be assigned to a different computational element. However, in some embodiments where the computational capacity varies among the computational elements and / or is dynamically determined, two or more prefix values ​​may be assigned to one or more computational elements.

[0041]

[0045] In various embodiments, key match manager 202 may generate indexing information that includes one or more prefix values ​​(e.g., having a determined length) that are assigned to each partition (and thus different computational elements 208). For example, the indexing information may include a list of one or more prefixes and / or prefix ranges that are assigned to each computational element 208.

[0042]

[0046] At 218 of process 200, key matching manager 202 may send matching instructions (e.g., requests for simultaneous processing of key partitions) to multiple computation elements 208. The matching instructions may include the key (e.g., PMK and / or PSK) presented by the client device to be matched and / or information that enables the individual computation elements 208 to determine the key to be matched. For example, the matching instructions may include the ANonce value, the SNonce value, the SSID of the LAN, the MAC address of the client device (STA MAC) and / or the MAC address of the access point (AP MAC), and / or other information necessary to determine the key to be matched. The individual computation elements 208 may determine the presented key to be matched based on the information in the matching instructions.

[0043]

[0047] In various embodiments, the matching instructions may further include indexing information to indicate to each computational element 208 the partition of valid keys (e.g., PMKs and / or PSKs) that the computational element 208 should attempt to match against the presented key. For example, as discussed above, the indexing information may indicate a list of one or more prefixes and / or ranges of valid keys for each partition.

[0044]

[0048] At 220 of process 200, individual computational elements 208 may request keys for their respective partitions from the key storage server 206. The request may indicate one or more prefixes (e.g., a list or range) for which associated keys are requested. The request may further include identification information associated with the LAN (e.g., SSID, access point information, site information, and / or location information). The key storage server 206 may provide the requested keys to each computational element 208 at 222 of process 200.

[0045]

[0049] In various embodiments, key storage server 206 may enable efficient retrieval of keys by scope (e.g., access point, site, and / or location) and prefix. For example, key storage server 206 may implement relational database managed storage (RDBMS), non-relational table storage, and / or hierarchical object storage. In some embodiments, key storage server 206 may provide an ordered mapping from string keys to string values.

[0046]

[0050] At 224 of process 200, each individual computational element 208 may attempt to match the submitted key with the partition of valid keys assigned to the respective computational element. Matching may be performed by a cryptographic testing process, such as calculating a checksum of the submitted key and comparing it with the checksum of the respective valid key. If the checksum of the submitted key matches the checksum of the valid key, the computational element 208 determines that a match exists.

[0047]

[0051] At 226 of process 200, one or more of the computational elements 208 may provide matching information to the key matching manager 202. For example, a computational element 208 that successfully finds a match may send matching information indicating a successful match. The matching information may further include the matched key (e.g., the PMK and / or associated PSK) and / or other information that enables the key matching manager 202 and / or the access point to determine the matched key. The matching information may be provided when a match is found (rather than continuing to search for the remaining keys and then sending the matching information). This may improve the response time of the matching process.

[0048]

[0052] In some embodiments, a computational element 208 that is not successful in finding a match for a submitted key may send matching information to the key matching manager 202 indicating the matching failure.

[0049]

[0053] At 228 of process 200, key match manager 202 may send (e.g., to the access point) a match result. The match result may correspond to the match information provided by key match service 106 to access point 104 at 118 of process 100. The match result may include some or all of the match information (e.g., the matched key and / or other information that allows the matched key to be determined) provided by the computational element 208 that successfully found a match.

[0050]

[0054] Thus, processes 100 and / or 200 and related architectures may reduce the required complexity / cost of access points by offloading key matching from the access points. Furthermore, distributing the matching among multiple computational elements allows cryptographic calculations to be performed in parallel, thereby significantly improving response time compared to systems that use the same processing resources to match a submitted key against all valid keys. Furthermore, the number of keys in each partition, the number of partitions, and / or the distribution of keys among different partitions may be determined to optimize performance and / or meet certain metrics (e.g., latency of the matching process). Processes 100 and / or 200 and related architectures may improve performance (e.g., latency) and / or allow for an increased number of valid keys to be used compared to conventional systems.

[0051] End-to-end batch processing

[0055] In some embodiments, networking hardware (access points or controllers) may communicate with the key agreement service via RADIUS, a UDP protocol. Embodiments of the present disclosure may also operate in conjunction with other UDP protocols or other suitable communication protocols. The nature of RADIUS is such that authentication requests (also known as access requests) are received as asynchronous, standalone messages. These messages may arrive at a very high rate if authentication is centralized (e.g., in the cloud), which may be the case in some embodiments.

[0052]

[0056] Existing RADIUS server software (e.g., FreeRADIUS and Microsoft's NPS / IAS) implements a wide variety of RADIUS features. Some of these features require stateful message processing, which has led to implementations that involve a queue of serialized messages that are processed in order, with each response sent before processing of the next message begins. While efficient and useful for supporting complex protocol variants like EAP-TLS, this "one-at-a-time" message processing imposes economic and scalability constraints when unnecessary.

[0053]

[0057] Embodiments of the present disclosure address these and other problems by processing batches of messages asynchronously, alleviating the constraints imposed by serial processing. Among other things, processing multiple messages according to some embodiments provides economies of scale achieved by reusing computational resources (e.g., memory, network, and CPU). The overall result is that fewer demands are placed on each layer of the system (e.g., in FIG. 2B , RADIUS layer 234, key match API 202, and concurrent match worker 240), resulting in a proportional reduction in computational capacity and memory usage with the size of the batch. In some cases, this can result in up to a 99% cost reduction over similar systems based on "one-at-a-time" message processing.

[0054]

[0058] 2B illustrates an example of a key matching process 230 utilizing batch processing according to various embodiments. In this example, at 242, a UDP message is received by the UDP proxy layer 232. The UDP proxy layer 232 may receive individual messages from multiple access points and buffer them internally until a preset number of messages (or a predetermined elapsed time) is reached. The buffered messages are then passed as a single "batch" to the RADIUS layer 234 at 244.

[0055]

[0059] The intervening RADIUS layer 234 converts the binary UDP packet data into semantic RADIUS message content. Invalid messages are removed from the batch, as are messages for which a known response exists (cached or canned). The remaining converted messages are sent to the Matching API layer 202 at 246, and a response is returned to the UDP layer at 264.

[0056]

[0060] The match API layer 202 determines (at 248, 250, 252, and 254) the maximum number of PSKs to be searched based on the scope and SSID pairs, the distinct scope / SSID pairs, the configuration information (e.g., from the configuration server 236), and the partition prefixes represented in the batch of requests. The match API layer 202 then sends the message and the appropriate key partition prefixes at 256 to the set of concurrent match workers 240 needed to search that number of keys within the designed (configured) time.

[0057]

[0061] At 258, each match worker instance retrieves the set of PSKs that match its assigned prefix from key storage 238. Then, at 260, each key in the batch is compared to its set of candidate matches, which is returned (at 262 and 264) to the coordinator (key match API 202), the RADIUS layer, and finally to the UDP layer, which returns a response to the access point.

[0058]

[0062] Embodiments of the present disclosure can provide efficient batching based on knowledge of key (PSK) segmentation in the key storage service 238. The key splitting approach taken by embodiments of the present disclosure (match on scope + ssid + computed prefix) allows for grouping of requests into sets based on scope and SSID.

[0059] Attribute-Based Hinting

[0063] In some embodiments, some use cases involving a very large number of PSKs involve large, widely distributed networks, where the population of devices that may associate is similarly widely distributed. In other words, networks with a very large number of potential clients are geographically dispersed. Similarly, due to physical limitations, the number of devices that may connect to a single access point is relatively small. Embodiments of the present disclosure may address this by identifying a small set of PSKs that are most likely to match on initial connection to help better support a large number of PSKs.

[0060]

[0064] Figure 2C illustrates an example of a key matching process 280 that utilizes attribute-based "hinting" to support the multiple PSK use case described above. In this example, the components are as described above with reference to Figure 2A, but with some notable improvements. For example, in some embodiments, the key storage service may be improved to store arbitrary string tags (e.g., single named labels) as well as attributes (e.g., key / value pairs). These data items may be provided when a PSK is added to storage or when an existing PSK is added / updated / deleted.

[0061]

[0065] In some embodiments, when a match request is made, the response includes tags and attributes associated with the matched PSK. Among other things, these data items serve to provide a way to configure PSK-specific connection properties such as VLAN, bandwidth limits, session time, etc., as well as store application-specific data along with the PSK for use by external systems.

[0062]

[0066] A lookup request (e.g., a request for simultaneous processing of key partitions in process 280) may contain any "extra" information not utilized by the core lookup mechanism described above. This extra information may be specific to the protocol used to communicate with the service (IP addresses, ports, etc.) or may be encoded in the message content (HTTP headers, RADIUS AVPs and VSAs).

[0063]

[0067] In some embodiments, the key matching API may be enhanced from FIG. 2A to allow for rules to be set that allow for "extra" information to be mapped to attributes stored about the PSK.

[0064]

[0068] Upon receiving a match request by one or more distributed computation elements, the mapping may be used to form a query filter to identify the "most likely" matching PSKs (e.g., having a likelihood or probability above a predetermined threshold) by comparing the value of the "additional" data with the values ​​of the identified attributes. A "fuzzy match" may be used in the comparison to provide prioritization of the PSKs, or an "exact match" may be used to provide filtering of the PSKs that may match. At 282, a subset of this most likely matching PSKs is retrieved and searched first. If no match is found, the remaining PSKs are retrieved and searched at 284.

[0065]

[0069] In this manner, embodiments of the present disclosure provide order matching comparisons that search for likely matching PSKs first to reduce the time to find a match. Additionally, embodiments of the present disclosure help filter PSKs to reduce the overall number that need to be searched.

[0066]

[0070] In one particular example, in integration with a key matching service via RADIUS, the request includes the network ID (BSSID) of the access point. To utilize the hint, an attribute may be added to the PSK to hold the value of the BSSID most likely to be used (sometimes called "Home AP"). The matching service can then be configured to have a "hint" that the BSSID in the RADIUS request should map to the "Home AP" attribute of the PSK. When a matching request is received, the query to the key storage service is modified to first identify PSKs where "Home AP" matches the AP's BSSID, and only search other keys if a match is not found among them.

[0067] Active VLAN Management

[0071] 1 and 2A, when the key lookup service responds to a key lookup request with an affirmative response (e.g., by returning the matched key to the requesting device or service), it may, if configured to do so, include a VLAN (virtual LAN) value in the response. The system that requested the key lookup then applies the provided VLAN value to all network traffic generated using that WPA-2 key, segregating traffic on the network from each key or group of keys into separate virtual networks.

[0068]

[0072] IEEE 802.1Q specifies that the maximum number of VLANs on a given Ethernet network is 4,094. Some embodiments of the present disclosure may provide cloud-based access management to the network, where a separate VLAN is assigned to each user of the network. A user may be assigned one or more WPA-2 keys, and depending on the system configuration, each key may have its own unique VLAN, or some or all of the keys may share the same VLAN.

[0069]

[0073] Therefore, managing the availability of VLANs as network users onboard and offboard is one challenge for embodiments of the present disclosure. Traditionally, there are two main methods for managing VLANs: 1) static mapping and 2) dynamic allocation from a pool. In the static mapping method, the network is divided into logical "units," such as apartments, and all available units are assigned VLAN values ​​in a static map. Each network user is then assigned to a logical unit, and any keys generated or assigned to users in that unit use the VLAN value mapped to that unit in the map. In the dynamic pool method, there is no map. Instead, each user of the network is assigned a VLAN value from a defined pool of available values ​​(which cannot exceed the total number of VLANs, 4094). When a user onboards, a VLAN from the pool is assigned to the user (and included in the EKMS key reconciliation response), and that VLAN is no longer available for allocation to other users. When a user goes offboard (and the key is revoked), the VLAN assigned to the user is released back into the pool and becomes available for allocation to another network user again. This 1:1 relationship between VLANs and network users limits the number of users that can be onboarded to the network to the number of available VLANs in the pool.

[0070]

[0074] Embodiments of the present disclosure help address the above-mentioned problems. For example, in some embodiments, when using a dynamic pool method with a key matching system, it is not necessary to keep a VLAN assigned to a key that is not actively being used to connect a device to the network. Thus, the system may assign a VLAN from the pool to a key only when the key becomes active, and release the VLAN back to the pool when the key becomes inactive. This allows for more network users than available VLANs, as long as there are not more active users than available VLANs.

[0071]

[0075] In some embodiments, when a user is onboarded to the network, if the user decides to connect a device but does not have a VLAN value assigned, a unique key is generated and added to the key match service, making it available for matching. When a device connects to the network using the user's key, a key match request is sent to the key match service. If the key match service finds a match, it proceeds in one of the following ways:

[0072]

[0076] (1) If a VLAN is not assigned to the key, the system allocates a VLAN from the pool, remembers the VLAN for use in subsequent key match requests, and responds to the requesting service with the matching key and VLAN attributes.

[0073]

[0077] (2) If a VLAN has previously been assigned to a key and is remembered for future use, the EKMS responds to the requesting service with the matching key and the previously assigned VLAN value.

[0074]

[0078] In this way, the key lookup service responds to subsequent key lookup requests using the previously assigned VLAN (if any), so that network traffic from all of the user's active devices is tagged with the same VLAN while they are active.

[0075]

[0079] When a key becomes inactive, the system may remove the key's VLAN assignment and return it to the pool, freeing up the VLAN to be assigned to another user of the network. If the key is used again to join the network after a period of inactivity, the system will reallocate a VLAN from the pool of available VLANs and store it for future requests.

[0076]

[0080] This cycle of allocating VLANs to keys when they are active and releasing them back into the pool when they become inactive may continue as long as the key is valid for lookup in the key lookup service.

[0077]

[0081] 3 illustrates an exemplary computing device for implementing various aspects of the present disclosure, including the components and operational flow / algorithmic structures described herein. In various embodiments, computing device 300 may be implemented as one or more components of client device 102, access point 104, and / or key match service 106 illustrated and described with respect to FIG. 1. Computing device 300 may also or alternatively be implemented as key match manager 202, service area information server 204, key storage server 206, and / or distributed computing element 208 illustrated and described with respect to FIGS. 2A and 2C, as well as any suitable component shown in FIG. 2B.

[0078]

[0082] Computing device 300 may include one or more processors 302 and memory 304. For purposes of this application, including the claims, the terms "processor" and "processor core" may be considered synonymous unless the context clearly requires otherwise.

[0079]

[0083] Memory 304 may include any combination of volatile and non-volatile memory. For example, memory 304 may include random access memory (e.g., dynamic random access memory, synchronous dynamic random access memory, static random access memory, non-volatile random access memory, etc.), read-only memory (e.g., masked read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, flash memory, etc.), cache, etc. Some elements of memory 304, e.g., mass storage, may be physically separate or remote from computing device 300.

[0080]

[0084] The memory 304 may be used to store component logic 322, including, for example, working or permanent copies of programming instructions for implementing operations associated with the described components (e.g., client device 102, access point 104, key matching service 106, key matching manager 202, service area information server 204, key storage server 206, and / or distributed computation element 208). Various elements of the computation logic 322 may be implemented by assembler instructions supported by the processor(s) 302, or a high-level language such as C, and / or any other suitable high-level language that can be compiled into such instructions.

[0081]

[0085] A permanent copy of the programming instructions may be placed in a persistent storage device at a factory or in the field, for example, via tangible distribution media (not shown) or via communications interface 310 (from a distribution server (not shown)). That is, one or more distribution media having an implementation of the operational flow / algorithmic structures described herein may be used to distribute the programming instructions to program various computing devices.

[0082]

[0086] The processor 302 may include any combination of processing circuitry for executing computational logic 322 from memory 304 to implement various aspects of the embodiments described herein. The processor 302 may include a central processing unit, a graphics processing unit, a digital signal processor, an accelerator, etc. The processor 302 may be implemented on a common motherboard, a dedicated card, etc. The processor 302 may further include various units dedicated to specific processing tasks, such as, but not limited to, a power management unit, a bus interface, a memory controller, device drivers, a display interface, a computing / graphics array, registers, combinatorial logic, etc.

[0083]

[0087] The computing device 300 may further include input / output (I / O) devices 308 (eg, a display, a keyboard, a cursor controller, a remote controller, a game controller, an image capture device, etc.).

[0084]

[0088] Computing device 300 may further include communication interface(s) 310 that include one or more hardware devices that enable computing device 300 to communicate with other devices (e.g., devices shown and described with respect to FIGS. 1, 2A, 2B, and 2C). In an embodiment, each of communication interfaces 310 may include one or more processors (e.g., baseband processors, etc.) dedicated to a particular wireless communication protocol (e.g., Wi-Fi and / or IEEE 802.11 protocols), cellular communication protocols (e.g., Long Term Evolution (LTE), 5G, etc.), wireless personal area network (WPAN) protocols (e.g., IEEE 802.15.4-802.15.5 protocols, Bluetooth®, or Bluetooth® Low Energy (BLE), etc.), or wired communication protocols (e.g., Ethernet®, Fiber Distributed Data Interface (FDDI), Point-to-Point (PPP), etc.). Communications interface 310 may also include hardware devices that enable communication with wireless / wired networks and / or other computing devices over solid or non-solid media using modulated electromagnetic radiation. Such hardware devices may include switches, filters, amplifiers, antenna elements, receptacles / ports for receiving plugs / connectors, and / or the like to facilitate wireless or wired communication by generating or otherwise producing radio waves for transmitting data to one or more other devices and converting received signals into usable information, such as digital data, that can be provided to one or more other components of computing device 300.

[0085]

[0089] The elements of computing device 300 may be coupled to each other via an internal connection interface 316, which may represent one or more buses or other connections. If there are multiple buses, they may be bridged by one or more bus bridges (not shown).

[0086]

[0090] The number, capabilities, and / or capacity of the elements of computing device 300 may vary depending, for example, on how computing device 300 is used. Their configuration is otherwise known and will not be described further.

[0087]

[0091] 4 illustrates an example of at least one computer-readable storage medium 404 having instructions configured to perform all or selected operations associated with the techniques described herein. As illustrated, the at least one computer-readable storage medium 404 may include a number of programming instructions 408. The programming instructions 408 may be configured to enable a device, such as computing device 300, to perform various operations of process 100 and / or process 200, etc., in response to execution of the programming instructions. In alternative embodiments, the programming instructions 408 may instead be located on multiple computer-readable storage media 404.

[0088]

[0092] The computer-readable media (including at least one computer-readable media), methods, apparatus, systems, and devices for performing the techniques described above are illustrative examples of embodiments disclosed herein. Additionally, other devices in the above-described interactions may be configured to perform various of the disclosed techniques.

[0089]

[0093] While particular embodiments have been illustrated and described herein, those skilled in the art will recognize that a wide variety of alternative and / or equivalent embodiments or implementations calculated to achieve the same purpose may be substituted for the illustrated and described embodiments without departing from the scope of the invention. Those skilled in the art will readily appreciate that the embodiments may be implemented in a very wide variety of ways. This application is intended to cover any adaptations or variations of the embodiments discussed herein. It is manifestly intended, therefore, that the embodiments be limited only by the claims and equivalents thereof.

Claims

1. One or more non-transitory computer-readable storage media having instructions stored thereon, The instruction: When executed by one or more processors, the computing device: receiving a verification request from a local area network (LAN) access point as part of an Extensible Authentication Protocol over LAN (EAPOL) process associated with a client device, the verification request including a proposed key provided by the client device, a station nonce (SNonce) value generated by the client device, and an access point nonce (ANonce) value generated by the access point; determining a number of possible keys valid for authentication with said LAN; determining indexing information based on the number of keys, the indexing information being for allocating the keys to a plurality of partitions based on a portion of each key; sending the submitted key, the indexing information for the respective partitions, the SNonce value, and the ANonce value to a plurality of computation elements to perform matching of the key with the respective partitions; receiving notification of a match from a first computational element of the plurality of computational elements; is an instruction to execute One or more non-transitory computer-readable storage media.

2. The one or more non-transitory computer-readable storage media of claim 1 , wherein the indexing information is determined further based on computational capacities of the plurality of computational elements.

3. 10. The one or more non-transitory computer-readable media of claim 1, wherein the portion of the respective key is a prefix of the respective key.

4. The recording medium is instructions to cause the computing device to determine a size of the portion of the key based on the number of keys; 10. The one or more non-transitory computer-readable storage media of claim 1, further storing:

5. The recording medium is the computing device; determining a minimum number of computational elements required to perform the match based on the number of keys; determining a size of the portion of the key based on a base-N logarithmic function of the smallest number, where N is the number of possible values ​​of individual elements of the portion of the key; An instruction to execute 5. The one or more non-transitory computer-readable storage media of claim 4, further storing:

6. One or more non-transitory computer-readable recording media as described in claim 5, wherein the individual elements are bits and N is 2.

7. the SNonce value and the ANonce value are included in key information used to generate the presented key; 2. The one or more non-transitory computer-readable storage media of claim 1, wherein the key information further includes one or more of a media access control (MAC) address of the access point, a MAC address of the client device, and a service set identifier (SSID) of the LAN.

8. the key is a Pairwise Master Key (PMK) or a Pre-Shared Key (PSK); the PMKs are associated with the same SSID and different PSKs; Or, the notification of the match includes the matched PSK or PMK.

10. One or more non-transitory computer-readable storage media according to claim 1.

9. The recording medium is instructions to cause the computing device to provide a match to the access point based on the notification of the match; 10. The one or more non-transitory computer-readable storage media of claim 1, further storing:

10. The recording medium is instructions to cause the computing device to determine a value associated with a virtual local area network (VLAN); Further memorize the value associated with the VLAN is included in the match result; 10. One or more non-transitory computer-readable storage media according to claim 9.

11. Determining the value associated with the VLAN determining that no VLAN is currently assigned to the key; Allocating a VLAN from the pool to the key for subsequent key lookup requests; 11. The one or more non-transitory computer-readable storage media of claim 10, comprising:

12. Determining the value associated with the VLAN Identifying the VLAN currently assigned to the key; 11. The one or more non-transitory computer-readable storage media of claim 10, comprising:

Images