Devices and methods for secure communication in wireless local area network

Abstract

A Multi-Link Device, MLD, (110; 120) with a plurality of affiliated access points, APs, (113a, b) or non-AP stations (123a, b) is disclosed for communication via a plurality of links (115a, b) with a further MLD (120; 110) with a plurality of affiliated non-AP stations (123a, b) or APs (113a, b). The MLD (110; 120) is configured to generate a link protection key for each of the plurality of links (115a, b) with the further MLD (120; 110) and encrypt and / or digitally sign at least a portion of one or more frames based on the link protection key of the plurality of link protection keys associated with a selected link of the plurality of links (115a, b). Moreover, the MLD (110; 120) is configured to transmit the one or more frames to the further MLD (120; 110) via the selected link. The MLD (110; 120) provides an improved per-link security.

Description

DEVICES AND METHODS FOR SECURE COMMUNICATION IN WIRELESS LOCAL AREA NETWORKTECHNICAL FIELD

[0001] The present invention relates to wireless communications. More specifically, the present invention relates to devices and methods for secure communication in a wireless local area network.BACKGROUND

[0002] Wireless Local Area Network (WLAN) technology as defined by the IEEE 802.11 framework of standards is being enhanced with an objective of improving both throughput and reliability. As part of this effort, there is a need for stations (STAs) to exchange control information to optimize traffic flow during data exchanges. There is a greater need to protect in particular this control information so that an attacker cannot compromise the performance of a high reliability network.SUMMARY

[0003] It is an objective of the present disclosure to provide devices and methods for secure communication in a wireless local area network.

[0004] The foregoing and other objectives are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

[0005] According to a first aspect a Multi-Link Device, MLD, with a plurality of affiliated access points, APs, or non-AP stations is provided for communication via a plurality of links with a further MLD with a plurality of affiliated non-AP stations or APs in a wireless local area network, WLAN, in particular an IEEE 802.11 based WLAN (also referred to as a Wi-Fi network) , using a Multi-Link Operation, MLO, mode. The MLD is configured to generate a link protection key for each of the plurality of links with the further MLD and encrypt and / or digitally sign at least a portion of one or more frames based on the link protection key of the plurality of link protection keys associated with a selected link of the plurality of links. The MLD is further configured to transmit the one or more encrypted or digitally signed frames to the further MLD via the selected link. Thus, the MLD according to the first aspect provides an improved per-link security.

[0006] In a further possible implementation form, the MLD is further configured to receive via each of the plurality of links with the further MLD one or more further frames from the further MLD, wherein the MLD is further configured to decrypt and / or authenticate the one or more further frames based on the link protection key of the associated link.

[0007] In a further possible implementation form, the one or more frames and / or the one or more further frames comprise one or more data frames, one or more control frames and / or one or more management frames.

[0008] In a further possible implementation form, the MLD is further configured to perform a 4-way handshake with the further MLD for establishing a pairwise transient key security association, PTKSA, between the MLD and the further MLD and for generating a key derivation key, KDK, wherein the MLD is further configured to generate, i.e. derive each link protection key based on the KDK.

[0009] In a further possible implementation form, the MLD is configured to delete a link protection key of the plurality of link protection keys, if the associated link is deleted.

[0010] In a further possible implementation form, if a further link is added to the plurality of links between the MLD and the further MLD, the MLD is configured to generate a further link protection key for the further link.

[0011] In a further possible implementation form, the further link may be added to the plurality of links between the MLD and the further MLD in response to an exchange of protected management frames between the MLD and the further MLD.

[0012] In a further possible implementation form, the MLD is further configured to generate, i.e. derive each link protection key using a key derivation function, KDF, based on the KDK and one or more of the following: a unique key identifier of the link protection key; a key type of the link protection key; an address of the MLD; an address of the further MLD; a link identifier identifying the link associated with the link protection key; an address of the affiliated AP using the link associated with the link protection key; an address of the affiliated non-AP station using the link associated with the link protection key; and one or more nonces exchanged between the MLD and the further MLD during the 4-way handshake.

[0013] In a further possible implementation form, the one or more nonces exchanged between the MLD and the further MLD during the 4-way handshake comprise at least one unique nonce for each link of the plurality of links.

[0014] In a further possible implementation form, during the 4-way handshake the MLD is configured to exchange one or more Extensible Authentication Protocol over Local Area Network, EAPOL, Key frames with the further MLD, wherein each of the one or more EAPOL Key frames comprises a Key Data field and wherein the MLD is configured to include the at least one unique nonce for each link of the plurality of links in a respective MLO Link Key Data Encapsulation, KDE, of the Key Data field.

[0015] In a further possible implementation form, each MLO Link KDE further comprises a message integrity check, MIC, element.

[0016] In a further possible implementation form, the link information field of each MLO Link KDE contains an indication (in particular, a flag bit) indicative of the presence of a unique nonce in the respective MLO Link KDE and / or an indication (in particular, a flag bit) indicative of the presence of the MIC element in the respective MLO Link KDE.

[0017] In a further possible implementation form, the header of the EAPOL-Key frame comprises an indication (in particular, a flag bit) indicative of the 4-way handshake being performed for generating the plurality of link protection keys.

[0018] In a further possible implementation form, the MLD is configured to implement for each affiliated AP a separate MAC layer, wherein the MAC layer is configured to use, e.g. store the link protection key of the associated link.

[0019] In a further possible implementation form, the plurality of link protection keys comprise one or more unicast keys and / or one or more group keys.

[0020] In a further possible implementation form, the MLD is configured to implement a Wake-Up-Radio, WUR, mode and to use the plurality of link protection keys as WUR security keys.

[0021] In a further possible implementation form, the MLD is an MLD AP, i.e. implements the plurality of affiliated APs for communication via the plurality of links with the further MLD implementing the plurality of affiliated non-AP stations, wherein the MLD AP is configured to signal the capability to generate and / or use the plurality of link protection keys in a beacon frame and / or a probe response frame.

[0022] In a further possible implementation form, the MLD is an MLD station, i.e. implements the plurality of affiliated non-AP stations for communication via the plurality of links with the further MLD implementing the plurality of affiliated APs stations, wherein the MLD station  is configured to signal the capability to generate and / or use the plurality of link protection keys by means of a robust security network extension element, RSNXE, of a management frame.

[0023] According to a second aspect a method for operating a Multi-Link Device, MLD, with a plurality of affiliated access points, APs, or non-AP stations is provided for communication via a plurality of links with a further MLD with a plurality of affiliated non-AP stations or APs in a wireless local area network, WLAN, using a Multi-Link Operation, MLO, mode. The method according to the second aspect comprises the following steps:

[0024] generating a link protection key for each of the plurality of links with the further MLD;

[0025] encrypting and / or digitally signing at least a portion of one or more frames based on the link protection key of the plurality of link protection keys associated with a selected link of the plurality of links; and

[0026] transmitting the one or more encrypted or digitally signed frames to the further MLD via the selected link.

[0027] The method according to the second aspect of the present disclosure can be performed by MLD according to the first aspect of the present disclosure. Thus, further features of the method, according to the second aspect of the present disclosure, result directly from the functionality of the MLD according to the first aspect of the present disclosure as well as its different implementation forms described above and below.

[0028] According to a third aspect a computer program product is provided, comprising program code which causes a computer or a processor to perform the method according to the second aspect, when the program code is executed by the computer or the processor.

[0029] Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In the following, embodiments of the present disclosure are described in more detail with reference to the attached figures and drawings, in which:

[0031] Fig. 1 shows a Multi-Link Device, MLD, according to an embodiment with a plurality of affiliated access points, APs, in communication via a plurality of links with a further MLD according to an embodiment with a plurality of affiliated non-AP stations;

[0032] Fig. 2 shows a portion of a RSNXE of a frame exchanged between the MLD and the further MLD according to an embodiment;

[0033] Fig. 3 shows an MLO Link KDE of a frame exchanged between the MLD and the further MLD according to an embodiment;

[0034] Fig. 4 shows a Link Information field of an MLO Link KDE of a frame exchanged between the MLD and the further MLD according to an embodiment;

[0035] Fig. 5 shows a group key KDE of a frame exchanged between the MLD and the further MLD according to an embodiment; and

[0036] Fig. 6 shows a flow diagram illustrating steps of a method of operating an MLD according to an embodiment.

[0037] In the following, identical reference signs refer to identical or at least functionally equivalent features.

[0038] DETAILED DESCRIPTION OF THE EMBODIMENTS

[0039] In the following description, reference is made to the accompanying figures, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0040] For instance, it is to be understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the  plurality of steps) , even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units) , even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and / or aspects described herein may be combined with each other, unless specifically noted otherwise.

[0041] Figure 1 shows a Multi-Link Device, MLD, 110 with a plurality of affiliated access points, APs, 113a, b communicating via a plurality of links 115a, b (for instance a 2.4 GHz link 115a and a 5 GHz link 115b) with a plurality of non-AP stations 123a, b affiliated with a further MLD 120 in a wireless local area network, WLAN, 100 in particular an IEEE 802.11 based WLAN (also referred to as Wi-Fi network 100) , using a Multi-Link Operation, MLO, mode. The MLD 110 with the affiliated APs 113a, b is herein also referred to as AP MLD 110, while the further MLD 120 with the affiliated non-AP stations 123a, b is referred to as non-AP MLD 120 or MLD station 120. For the most part, data and most management traffic may be exchanged directly between the MLDs 110, 120. Control traffic, however, is usually exchanged between the affiliated non-AP STAs 123a, b and the affiliated APs 113a, b on a given link 115a or 115b. The AP MLD 110 and the non-AP MLD 120 may establish a Security Association, SA, as illustrated in figure 1, while the affiliated STAs 113a, b and123a, b do not take part in the SA between the MLDs 110, 120. In the MLO mode communications between the two MLDs 110, 120 may use either one of the independently operating radio links 115a, b.

[0042] As will be appreciated, Multi-link Operation (MLO) at the MAC layer together with a multi-link device (MLD) , such as the AP MLD 110 and the non-AP MLD 120, has been introduced in IEEE P802.11be. MLO provides requirements for MLDs to maintain multiple WLAN connections across multiple links. A multiple link may also include a single radio STA that is able to multiplex between different frequency bands providing multiple logical WLAN connections. It allows traffic to flow on multiple links and provides a performance gain of using multiple channels. As already described above, each link, such as the links 115a, b shown in figure 1, is established between STAs affiliated with the MLDs.

[0043] In an embodiment, the MLDs 110, 120 may each comprise processing circuitry, for instance, one or more processors or CPUs for processing data (as well as implementing a respective MLD controller 111, 121) and one or more wireless communication interfaces,  in particular one or more wireless communication interfaces in accordance with the IEEE 802.11 framework of standards. The processing circuitry may be implemented in hardware and / or software and may comprise digital circuitry, or both analog and digital circuitry. Digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable gate arrays (FPGAs) , digital signal processors (DSPs) , or general-purpose processors. The MLDs 110, 120 may further each comprise a memory configured to store executable program code which, when executed by the processing circuitry, causes the respective MLD 110, 120 to perform the functions and methods described herein.

[0044] Before describing different embodiments of the AP MLD AP 110 and the non-AP MLD 120 in more detail, in the following some technical background as well as terminology will be introduced making use of one or more of the following abbreviations: AP          Access Point AKM         Authentication and Key Management BIGTK       Beacon Integrity Group Temporal Key BSS         Basic Service Set EAPOL       Extensible Authentication Protocol over Local Area Network FILS        Fast Initial Link Setup FT          Fast Transition GTK         Group Temporal Key IGTK        Integrity Group Temporal Key KDE         Key Data Encapsulation KDF         Key Derivation Function KDK         Key Derivation Key LCP         Link Control Protection MAC         Medium Access MIC          Message Integrity Check MLD          Multi-Link Device MLO          Multi-Link Operation PTK          Pairwise Transient Key RSNA         Robust Security Network Association RSNXE        Robust Security Network Extension Element SA           Security Association STA          Station WLAN         Wireless Local Area Network WUR          Wake-Up-Radio WIGTK        Wake-up radio (WUR) Integrity Group Temporal Key

[0045] As used herein, an access point (AP) is a special type of wireless station (STA) that provides access to other networks. An AP can support many connected non-AP STAs. APs use control information to control traffic flow over the wireless medium among all connected non-AP STAs.

[0046] As used herein, there are three main types of information communicated between WLAN STAs, namely data, management, and control. Data traffic is exchanged between stations (STAs) in a WLAN to facilitate communication. This traffic is secured when the STAs negotiate a cryptographic encapsulation method and keys to encrypt the data traffic. Management traffic is exchanged between STAs in a WLAN to establish and maintain state of communications. Security can be negotiated to encrypt or sign management traffic. Control traffic is exchanged between STAs in a WLAN to control the flow of information and the state of communications in a frame exchange. The frame could be a data frame or a management frame. Conventionally, there is no security associated with control traffic.

[0047] WLAN security is negotiated between STAs when they establish a connection. A secure connection is referred to as a security association (SA) between the STAs. When a connection is initiated, the STAs negotiate a cryptographic encapsulation method, along  with keys, to protect the data. WLAN security schemes offer mutual authentication, data integrity (signing) , and data confidentiality (encryption) for the protection of data and management traffic. The state of the SA is tied to the WLAN state of the device (i.e. authenticated, authenticated / associated) . The SA is established and maintained when the STAs are authenticated and associated.

[0048] The IEEE 802.11 framework of standards defines authentication and key management (AKM) schemes to allow STAs to negotiate and establish security keys. It also defines cryptographic encapsulation protocols (also known as cipher suites) to specify the encryption and signing of data. When STAs establish a connection, they negotiate an AKM and one or more cipher suites to protect communications. They also derive encryption keys that are valid for the duration of the SA.

[0049] There are two types of keys that are derived as part of these WLAN security schemes, namely group keys and unicast keys. Group keys are keys used by a STA to protect broadcast information to multiple other STAs, while unicast keys are keys that are mutually derived between STAs to protect communications.

[0050] For MLO, the SA is established between MLD peers and used to protect unicast management and data traffic between them. Unicast traffic is encrypted at the MLD and may be transported over any link. For group-addressed traffic, a set of encryption keys are maintained for each link independently but are communicated using the encrypted link between the MLDs.

[0051] As will be described in more detail in the following, embodiments disclosed herein allow deriving per-link keys for the protection of frames on a given link 115a or 115b based on keying material mutually derived between the MLDs 110, 120. In an embodiment, the frames are control frames and the per-link keys are also referred to as Link Control Protection (LCP) keys. It will be appreciated, however, that many of the embodiments disclosed herein may be applied as well to data frames and / or management frames exchanges between the MLDs 110, 120. Moreover, embodiments disclosed herein extend the standardized 4-way handshake to derive the LCP keys. In an embodiment, the LCP keys may be derived by the MLDs 110, 120 based on the pairwise transient key (PTK) and the Key Derivation Key (KDK) . In an embodiment, the LCP keys may be valid as long as the links 115a, b and the PTKSA between the MLDs 110, 120 is valid. Since the links for the MLDs 110, 120 can change, embodiments disclosed herein provide a re-keying protocol for deriving and associating one or more new LCP keys with a new link.

[0052] More specifically, both the AP MLD 110 affiliated with the APs 113a, b and the non-AP MLD 120 affiliated with the non-AP STAs 123a, b (illustrated in figure 1) are configured to generate a link protection key for each of the plurality of links 115a, b. Moreover, both the AP MLD 110 and the non-AP MLD 120 are configured to encrypt and / or digitally sign at least a portion of one or more frames based on the link protection key of the plurality of link protection keys associated with a selected link of the plurality of links 115a, b and to transmit the one or more encrypted and / or digitally signed frames via the selected link. In other words, both the AP MLD 110 and the non-AP MLD 120 generate at least one unique link protection key for each link 115a or 115b and cryptographically secure the communication over a respective link 115a or 115b with the link protection key of that link 115a or 115b. In an embodiment, both the AP MLD 110 and the non-AP MLD 120 are configured to cryptographically secure one or more control frames with the link protection key of the links 115a, b selected for the transmission of the control frames. For this reason, the link-specific keys are herein also referred to as Link Control Protection, LCP, keys.

[0053] In an embodiment, the AP MLD 110 and the non-AP MLD 120 are configured to derive the plurality of LCP keys based on the Pairwise Transient Key Security Association, PTKSA, between the AP MLD 110 and the non-AP MLD 120 in that the plurality of LCP keys may be derived and negotiated by the AP MLD 110 and the non-AP MLD 120 as part of the standardized 4-way handshake. In an embodiment, the LCP keys disclosed herein may be negotiated between the AP MLD 110 and the non-AP MLD 120 as an add-on feature to the standardized Authentication and Key Management, AKM, and cipher suite negotiation.

[0054] In an embodiment, the plurality of LCP keys may be tied to the PTKSA and may generally have the same lifetime as the PTKSA. In other words, in an embodiment, the AP MLD 110 and the non-AP MLD 120 are configured to use the plurality of LCP keys only for the lifetime of the PTKSA between the AP MLD 110 and the non-AP MLD 120. In a further embodiment, if a link is disabled / enabled, the LCP key associated with this link may persist as long as the PTKSA persists. If a link is deleted, the AP MLD 110 and the non-AP MLD 120 may be configured to delete the associated LCP key as well. If a link is added, the AP MLD 110 and the non-AP MLD 120 may be configured to generate an LCP key for the new link.

[0055] In an embodiment, the MLDs 110, 120 are configured to implement the LCP keys in the MAC layer of the affiliated STAs 113a, b and 123a, b, which may be implemented as lower MAC layers of the respective MLD 110, 120. As already described above, there is a different LCP key per link 115a and 115b and cryptographic encapsulation of particular control traffic is independent on different links 115a, b. In an embodiment, the MLDs 110,  120 are configured to assign a key type parameter and / or a link ID parameter to each LCP key. In an embodiment, these parameters may be added to the MLME-SetKeys to install the key in the lower MAC of the respective MLD 110, 120 for a particular affiliated STAs 113a, b and 123a, b.

[0056] As will be appreciated, Authentication and Key Management, AKM, schemes defined by the IEEE 802.11 framework of standards provide different protocols and key management properties depending on the WLAN deployment. In an embodiment, the MLDs 110, 120 may use extended AKM schemes (based on standardized AKM schemes) for generating and / or managing the link protection keys, as will be described in more detail in the following.

[0057] As illustrated in figure 2, the MLDs 110, 120 may be configured to include a new bit field as well as a corresponding bit in the Robust Security Network Extension Element, RSNXE, for advertising the capability to generate and use the LCP keys. In an embodiment, this new bit field 205 may be, for example, Bit 15 or another reserved or available bit of the Extended RSN Capabilities field 200, which may further include the standardized fields 201 and 203 as well as a plurality of reserved bits 207. In an embodiment, the AP MLD 110 may be configured to set this field 205 in the beacon frames and / or probe response frames to advertise support of LCP keys. The non-AP MLD 120 may set the field in the RSNXE in the (re-) association request frame to request LCP. The exchange of the LCP field set to 1 during the (re-) association request and response frames may trigger the non-AP MLD 120 and the AP MLD 110 to negotiate the plurality of LCP keys.

[0058] As will be described in more detail in the following, in an embodiment, the MLDs 110, 120 are configured to derive the LCP keys based on the standardized Key Derivation Key, KDK, and bound to the link addresses of the affiliated STAs 113a, b and 123a, b. Each LCP key may be bound to the affiliated STAs 113a, b and 123a, b that operate on the respective links 115a, b.

[0059] In an embodiment, the MLDs 110, 120 are configured to determine the LCP key for the i-th link 115a, b as:

[0060] LCP_i = KDF-Hash-Length (KDK, “Link Control Protection key” , Min (AA, SPA) || Max (AA, SPA) || LinkID (i) || Min (Affiliated_STA_MAC (i) , Affiliated_AP_MAC (i) ) || Min (AANonce (i) , ASNonce (i) ) || Max (AANonce (i) , ASNonce (i) ) )

[0061] where:

[0062] AA, SPA denote the Authenticator MLD address the and Supplicant MLD address;

[0063] LinkID denotes the link ID identifying the links 115a, b between the affiliated APs 113a, b and the affiliated STAs 123a, b;

[0064] Affiliated_AP_MAC, Affiliated_STA_MAC denote the MAC addresses of the affiliated STAs 123a, b and the affiliated APs 113a, b;

[0065] AANonce and ASNonce denote nonces exchanged during the protocol exchange (e.g. the 4-way handshake) , wherein the AANonce and ASNonce are the nonces of the affiliated APs 113a, b and the nonces of the affiliated STAs 123a, b, respectively.

[0066] As used herein, an Authenticator is an entity at one end of a point-to-point local area network (LAN) segment that facilitates authentication of the entity attached to the other end of that link, while A supplicant, in turn, is an entity at one end of a point-to-point local area network (LAN) segment that is being authenticated by the Authenticator attached to the other end of that link.

[0067] In an embodiment, the process for deriving the LCP keys may be implemented by the MLDs 110, 120 in the following way. In a first stage the Authenticator MLD and the Supplicant MLD perform the 4-way handshake. During the handshake, the authenticator MLD and the supplicant MLD generate and exchange a different nonce per link. In a second stage, the MLDs derive the PTK and use the per-link nonces to derive the LCP keys. When the 4-way handshake is complete, each MLD 110, 120 may use the MLME-SetKeys to implement the LCP key for each affiliated STAs 113a, b and 123a, b in the lower MAC layer for that STA.

[0068] As already described above, in an embodiment, the AP MLD 110 (which by way of example is the Authenticator MLD 110) and the non-AP MLD 120 (which by way of example is the Supplicant MLD 120) exchange for each link 115a, b, a nonce as further input to the LCP key derivation. The standardized MLO Link Key Data Encapsulation, KDE, already contains per-link information in the 4-way handshake. According to an embodiment, the AP MLD 110 and the non-AP MLD 120 may use the MLO KDE 300 shown in figure 3. In addition to the Link information 301, the MAC address 303, the Robust Security Network Element, RSNE, 305, and the Robust Security Network Extension Element, RSNXE, 307, as defined for a standardized MLO KDE, the MLO KDE 300 shown in figure 3 comprises a nonce 309 and a Message Integrity Code, MIC, 311 (or more specifically a corresponding nonce field 309 and a MIC field 311) . As indicated in  figure 3, the nonce field 309 may have, by way of example, a size of 32 octets / bytes and the size of the MIC field 311 may be variable.

[0069] As will be appreciated, the purpose of the Link Information field 301 of the MLO Link KDE 300 is to indicate which fields are present in the MLO Link KDE 300, as illustrated in figure 4. As illustrated in figure 3, the standardized Link Information field has a size of one byte. As illustrated in figure 4, in addition to the LinkID 401 and the RSNXEInfo 403, as defined for the standardized Link Information field, in an embodiment the Link Information field 301 generated by the AP MLD 110 and the non-AP MLD 120 may comprise a Nonce presence field 405 and a MIC presence field 407 for indicating by means of a respective flag bit, the presence of the link-specific nonce 309 and the presence of the MIC 311 in the MLO Link KDE 300 (as well as one or more reserved bits 409) .

[0070] In an embodiment, the AP MLD 110 and the non-AP MLD 120 are configured to derive the plurality of LCP keys in the 4-way handshake in the exchange of MLO Link KDEs, such as the MLO Link KDE 300 shown in figure 3. In an embodiment, the AP MLD 110 and the non-AP MLD 120 will exchange one MLO Link KDE, such as the MLO Link KDE 300 shown in figure 3, for every link 115a, b. As will be appreciated, this requires no modification of the standardized 4-way handshake (which also applies to the FT protocol and FILS protocol) .

[0071] For the scenario that a new link is added to be plurality of existing links 115a, b between the AP MLD 110 and the non-AP MLD 120 and / or for the scenario that a new LCP key is needed, in an embodiment the AP MLD 110 and the non-AP MLD 120 are configured to implement the key exchange protocol for deriving a further LCP key, which will be described in the following and is based on Extensible Authentication Protocol over Local Area Network, EAPOL, key frames. As will be appreciated, a standardized EAPOL key frame used in the 4-way handshake comprises a Key Data field. In an embodiment, the Key Data field of the EAPOL key frame exchanged during the 4-way handshake between the AP MLD 110 and the non-AP MLD 120 comprises for each link the MLO Link KDEs, such as the MLO Link KDE 300 of figure 3, including the per-link Nonce 309 and MIC information 311.

[0072] In comparison with a standardized EAPOL key frame, the MLDs 110, 120 may be configured to generate and exchange EAPOL key frames with a modified header indicating an LCP key derivation. In an embodiment, the MLDs 110, 120 may use a new bit, B4, Link Key, in the Key Information field of the EAPOL key frame, which signals the LCP key derivation and exchange of Nonce and MIC data in the MLO Link KDE. A unicast  LCP key may be exchanged when the existing B3 (Key Type) = 1, and the new B4 (Link Key) = 1 in the Key Information field of the EAPOL key frame. A group LCP key may be exchanged when B3 (Key Type) = 0, and B4 (Link Key) = 1. Alternatively, the LCP key derivation could be implicitly signaled by just including the nonce field 309 and the MIC field 311 in the MLO Link KDE 300.

[0073] In an embodiment, the AP MLD 110 and the non-AP MLD 120 are configured to implement the following EAPOL key handshake with the LCP keys:

[0074] Message 1: Authenticator –Supplicant:

[0075] EAPOL-Key (1, 1, 1, 1, P, P_L, 0, 0, MIC, { [OCI KDE] , MLO_LINKi} )

[0076] i–the setup link for the LCP key derivation

[0077] MLO_LINKi contains the AANonce

[0078] Message 2: Supplicant –Authenticator:

[0079] EAPOL-Key (0 or 1, 1, 0, 1, P, P_L, 0, 0, MIC, { [OCI KDE] , MLO_LINKi} )

[0080] MLO_LINKi contains the ASNonce, and a MIC of the MLO_LINK KDE using the LCP key

[0081] Message 3: Authenticator –Supplicant:

[0082] EAPOL-Key (1, 1, 0, 1, P, P_L, 0, 0, 0, MIC, { [OCI KDE] , MLO_LINKi} ) .

[0083] MLO_LINKi contains the MIC of the MLO_LINK KDE using the LCP key

[0084] Message 4: Supplicant –Authenticator:

[0085] EAPOL-Key (1, 1, 0, 0, P, P_L 0, 0, 0, MIC, { [OCI KDE] , MLO_LINKi} ) .

[0086] MLO_LINKi contains the MIC of the MLO_LINK KDE using the LCP key

[0087] The EAPOL handshake for the LCP key exchange may take place on any link 115a, b between the MLDs 110, 120. After the LCP key exchange completes successfully, the Authenticator and Supplicant MLD 110, 120 may call the MLME-Set-Keys primitive to install the LCP key in the MAC layer of the affiliated STAs 113a, b and 123a, b, as already described above.

[0088] During the lifetime of an association between the non-AP MLD 120 and the AP MLD 110, links can be re-negotiated or changed. Furthermore, it may become necessary to update LCP keys on a given link (e.g. due to a packet number (PN) exhaustion) . Rather than triggering a new PTK derivation, in an embodiment, the MLDs 110, 120 are configured to update the existing LCP keys in a separate handshake using protected management frames. With MLO, protected management frames (PMF) may be negotiated during (re-) association to ensure that management frame exchanges are protected. In the scenario  where a link is added or modified, the MLDs 110, 120 according to an embodiment may generate and transmit a management frame to negotiate this behavior, i.e. to add a new link or modify an already existing link 115a or 115b. In such a scenario, the LCP key derivation may be performed by the MLDs 110, 120 using the existing PTKSA and the updated parameters exchanged in the MLO_KDE. A new Key Data field may be defined for carrying the encrypted MLO_KDE, wherein the new Key Data field follows the format of the Key Data field in the EAPOL-Key frame. The LCP Key derivation can be embedded in a management frame exchange for adding or modifying a link. The embedded handshake for LCP keys in management frames may be implemented in the following way:

[0089] Message 1: (Add Link Request frame) non-AP MLD 120 –AP MLD 110:

[0090] Key Data ( { [OCI KDE] , MLO_LINKn} )

[0091] n –the setup link for the key derivation

[0092] MLO_LINKn contains ASNonce

[0093] Message 2: (Add Link Response frame) AP MLD 110 –non-AP MLD 120:

[0094] Key Data ( { [OCI KDE] , MLO_LINKn} )

[0095] MLO_LINKn contains the AANonce, and a MIC of the MLO_LINK KDE using the LCP key

[0096] Message 3: (Add Link Confirm frame) non-AP MLD 120 –AP MLD 110

[0097] Key Data ( { [ [MLO Link KDE] , MLO_LINKn} ) .

[0098] MLO_LINKn contains the MIC of the MLO_LINK KDE using the LCP key

[0099] The third message may be sent as an EAPOL frame, as described above, or not used (i.e. both parties assume that the key derivation is complete) .

[0100] On a given link, the affiliated APs 113a, b of the AP MLD 110 may configure, distribute, and use group LCP keys. Currently for MLO, the keys: GTK, IGTK, WIGTK, and BIGTK are managed on a per-link basis. In this case, the Authenticator MLD may generate an LCP group key (LCPGTK) and distribute this group key to the Supplicant for the associated non-AP MLDs, in the same manner as the other group keys.

[0101] In an embodiment, this process may be implemented in the following way. In a first stage, the AP MLD Authenticator 110 derives the LCPGTK. The key should be unique for a given link 115a or 115b. In a second stage, the AP MLD Authenticator 110 distributes the LCPGTK in the 4-way handshake and Group key handshake. In both of these scenarios, the AP MLD Authenticator 110 may distribute the LCPGTK along with the other group keys. As illustrated in figure 5, in an embodiment, the AP MLD Authenticator 110 may  include the LCPGTK 507 and the packet number, PN, 503 in the LCPGTK KDE 500, which may further include a key ID 501 and a link ID 505.

[0102] In an embodiment, the LCPGTK KDE 500 may be included in the Key Data field of a management frame that is defined to add or modify a link. In an embodiment, the AP MLD 110 may use the existing group key handshake mechanisms to distribute the LCPGTK. In an embodiment, the LCPGTK may be distributed by including the LCPGTK KDE in message exchanges that include the group key, such as the 4-way handshake, the Group key handshake, protocols such as FILS and FT, as well as management frames that are defined to add or modify a link.

[0103] Wake-up-Radio, WUR, is a feature to enhance WLAN power management. For security reasons peers may derive a WIGTK for encryption of WUR messages. If WUR is configured on a per-link basis, a link specific WIGTK can be generated in the same manner as the LCP keys described above. The Key Derivation and protocol defined for the embodiments above may be used to generate and manage WUR security keys as well.

[0104] Figure 6 shows a flow diagram illustrating steps of a method 600 for operating a Multi-Link Device, MLD, such as the AP MLD 110 shown in figure 1 with the affiliated APs 113a, b for communication via the plurality of links 115a, b with a further MLD, such as the non-AP MLD 120 shown in figure 1, with the affiliated non-AP STAs 123a, b. The method 600 comprises a step 601 of generating by the AP MLD 110 a link protection key for each of the plurality of links 115a, b between the AP MLD 110 and the non-AP MLD 120. Moreover, the method 600 comprises a step 603 of encrypting and / or digitally signing at least a portion of one or more frames based on the link protection key of the plurality of link protection keys associated with a selected link of the plurality of links 115a, b. The method 600 further comprises a step 605 of transmitting the one or more frames to the non-AP MLD 120 via the selected link. As already described above, in an embodiment the one or more frames may be one or more control frames.

[0105] As the method 600 can be implemented by the AP MLD 110 and the non-AP MLD 120, further features of the method 600 result directly from the functionality of the AP MLD 110 and the non-AP MLD 120 as well as their different embodiments described above and below.

[0106] The person skilled in the art will understand that the "blocks" ( "units" ) of the various figures (method and apparatus) represent or describe functionalities of embodiments of the present disclosure (rather than necessarily individual "units" in hardware or software)  and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step) .

[0107] In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described embodiment of an apparatus is merely exemplary. For example, the unit division is merely logical function division and may be another division in an actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0108] The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

[0109] In addition, functional units in the embodiments of the invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.

Claims

1.A Multi-Link Device, MLD, (110; 120) with a plurality of affiliated access points, APs, (113a, b) or non-AP stations (123a, b) for communication via a plurality of links (115a, b) with a further MLD (120; 110) with a plurality of affiliated non-AP stations (123a, b) or APs (113a, b) , wherein the MLD (110; 120) is configured to:generate a link protection key for each of the plurality of links (115a, b) with the further MLD (120; 110) ;encrypt and / or digitally sign at least a portion of one or more frames based on the link protection key of the plurality of link protection keys associated with a selected link of the plurality of links (115a, b) ; andtransmit the one or more frames to the further MLD (120; 110) via the selected link.2.The MLD (110; 120) of claim 1, wherein the MLD (110; 120) is further configured to receive via each of the plurality of links (115a, b) with the further MLD (120; 110) one or more further frames from the further MLD (120; 110) and wherein the MLD (110; 120) is further configured to decrypt and / or authenticate the one or more further frames based on the link protection key of the associated link.3.The MLD (110; 120) of claim 2, wherein the one or more frames and / or the one or more further frames comprise one or more data frames, one or more control frames and / or one or more management frames.4.The MLD (110; 120) of any one of the preceding claims, wherein the MLD (110; 120) is further configured to perform a 4-way handshake with the further MLD (120; 110) for establishing a pairwise transient key security association, PTKSA, between the MLD (110; 120) and the further MLD (120; 110) and generating a key derivation key, KDK, and wherein the MLD (110; 120) is further configured to generate each link protection key of the plurality of link protection keys based on the KDK.5.The MLD (110; 120) of claim 4, wherein each link protection key of the plurality of link protection keys is valid, as long as the associated link of the plurality of links (115a, b) is enabled or disabled.6.The MLD (110; 120) of claim 4 or 5, wherein the MLD (110; 120) is configured to delete a link protection key of the plurality of link protection keys, if the associated link of the plurality of links (115a, b) is deleted.7.The MLD (110; 120) of any one of claims 4 to 6, wherein, if a further link is added to the plurality of links (115a, b) between the MLD (110; 120) and the further MLD (120; 110) , the MLD (110; 120) is configured to generate a further link protection key for the further link.8.The MLD (110; 120) of claim 7, wherein the further link is added to the plurality of links (115a, b) between the MLD (110; 120) and the further MLD (120; 110) in response to an exchange of protected management frames between the MLD (110; 120) and the further MLD (120; 110) .9.The MLD (110; 120) of any one of claims 4 to 8, wherein the MLD (110; 120) is further configured to generate each link protection key using a key derivation function, KDF, based on the KDK and one or more of the following: a key identifier of the link protection key; a key type of the link protection key; an address of the MLD (110; 120) ; an address of the further MLD (120; 110) ; a link identifier identifying the link associated with the link protection key; an address of the affiliated AP (113a, b) using the link associated with the link protection key; an address of the affiliated non-AP station (123a, b) using the link associated with the link protection key; and / or one or more nonces (405) exchanged between the MLD (110; 120) and the further MLD (120; 110) during the 4-way handshake.10.The MLD (110; 120) of claim 9, wherein the one or more nonces (405) exchanged between the MLD (110; 120) and the further MLD (120; 110) during the 4-way handshake comprise at least one unique nonce for each link of the plurality of links (115a, b) .11.The MLD (110; 120) of claim 10, wherein during the 4-way handshake the MLD (110; 120) is configured to exchange one or more Extensible Authentication Protocol over Local Area Network, EAPOL, Key frames with the further MLD (120; 110) , wherein each of the one or more EAPOL Key frames comprises a Key Data field and wherein the MLD (110; 120) is configured to include the at least one unique nonce (405) for each link of the plurality of links (115a, b) in a respective MLO Link Key Data Encapsulation, KDE, of the Key Data field.12.The MLD (110; 120) of claim 11, wherein each MLO Link KDE (400) further comprises a message integrity check, MIC, element (407) .13.The MLD (110; 120) of claim 11 or 12, wherein the link information field (301) of each MLO Link KDE contains an indication indicative of the presence of the unique nonce in the respective MLO Link KDE and / or an indication indicative of the presence of the MIC element (407) in the respective MLO Link KDE.14.The MLD (110; 120) of any one of claims 11 to 13, wherein a header of the EAPOL-Key frame comprises an indication indicative of the 4-way handshake being performed for generating the plurality of link protection keys.15.The MLD (110; 120) of any one of the preceding claims, wherein the MLD (110; 120) is configured to implement for each affiliated AP (113a, b) or non-AP station (123a, b) a MAC layer, wherein the MAC layer is configured to use the link protection key of the associated link.16.The MLD (110; 120) of any one of the preceding claims, wherein the plurality of link protection keys comprise one or more unicast keys and / or one or more group keys.17.The MLD (110; 120) of any one of the preceding claims, wherein the MLD (110; 120) is configured to implement a Wake-Up-Radio, WUR, mode and to use the plurality of link protection keys as WUR security keys.18.The MLD (110) of any one of the preceding claims, wherein the MLD (110) implements the plurality of affiliated APs (113a, b) for communication via the plurality of links (115a, b) with the further MLD (120) implementing the plurality of affiliated non-AP stations (123a, b) and wherein the MLD (110) is configured to signal in a beacon frame and / or a probe response frame the capability to generate and / or to use the plurality of link protection keys.19.The MLD (120) of any one of claims 1 to 17, wherein the MLD (120) implements the plurality of affiliated non-AP stations (123a, b) for communication via the plurality of links (115a, b) with the further MLD (110) implementing the plurality of affiliated APs (113a, b) and wherein the MLD (120) is configured to signal by means of a robust security  network extension element, RSNXE, of a management frame the capability to generate and / or to use the plurality of link protection keys.20.A method (600) for operating a Multi-Link Device, MLD, (110; 120) with a plurality of affiliated access points, APs, (113a, b) or non-AP stations (123a, b) for communication via a plurality of links (115a, b) with a further MLD (120; 110) with a plurality of affiliated non-AP stations (123a, b) or APs (113a, b) , wherein the method (600) comprises:generating (601) a link protection key for each of the plurality of links (115a, b) with the further MLD (120; 110) ;encrypting (603) and / or digitally signing at least a portion of one or more frames based on the link protection key of the plurality of link protection keys associated with a selected link of the plurality of links (115a, b) ; andtransmitting (605) the one or more frames to the further MLD (120; 110) via the selected link.21.A computer program product comprising a computer-readable storage medium for storing program code which causes a computer or a processor to perform the method (600) of claim 20 when the program code is executed by the computer or the processor.

Images