Privacy parameter obfuscating method with multiple trust levels

Abstract

A method of communication in a wireless network carried out by a station in a basic service set (BSS). The station determines a trust level enabled between itself and another station 300 and obfuscates a current value of a privacy parameter (e.g. OTA MAC address, sequence number, packet number, traffic identifier) 310. The station then exchanges with the other station a frame comprising the obfuscated privacy parameter 320. If a first trust level is enabled then the obfuscation is carried out using a key shared with the other station only, whereas if a second trust level is enabled the obfuscation is carried out using a key shared with multiple other stations in the BSS. The key shared with multiple other stations may be shared between the entire BSS and may be derived from a key derivation key (KDK) forming a subpart of a group transient key (GTK). A method of communication between an access point (AP) station and a non-AP station, wherein a privacy parameter is generated using a function shared between the AP and non-AP stations and then is exchanged between the AP and non-AP stations, is also disclosed.

Description

FIELD OF THE INVENTION The present invention relates to wireless communications and more specifically to user privacy during wireless communications. BACKGROUND OF THE INVENTION The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section. Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks. The 802.11 family of standards adopted by the Institute of Electrical and Electronics Engineers (IEEE - RTM) provides a great number of mechanisms for wireless communications between stations. Today, the evolution of wireless systems has brought privacy concerns at the forefront, driven by user demand and requirements of the General Data Protection Regulation (GDPR). The global wireless industry is faced with the growing need to protect users’ personally identifiable information from increasingly sophisticated user tracking and user profiling activities, while continuing to improve wireless services and the user experience. The Personally Identifiable Information (PH) corresponds to any data that identifies an individual or from which identity or contact information of an individual can be derived. A device’s MAC address is an example of PH. A dedicated task group 802.11 bi has been initiated in 2019 to address those privacy concerns. Its objective is to specify Privacy Enhancements (PE) features to be added in the current standard to increase privacy. Some of the PE features are relative to the obfuscation of multiple identified PH, also referred to as transmitted PE parameters or privacy parameters below, contained in the frames exchanged by the stations (STA). The obfuscation consisting in performing a simultaneous change of the transmitted PE parameters (which are transmitted in clear in the frames) by the stations, to uncorrelated new values (with the previous ones) without any loss of connection. SUMMARY OF THE INVENTION The obfuscation procedure involves several mechanisms to be implemented which are at the current stage specific to each PE client. For example, the computation procedure may be based on the PRF standardized in section 12.7.1.2 of IEEE Std 802.11-2020, which is executed in parallel by the PE Client (non-AP station) and the PE AP (AP station) with a shared private encryption key and a shared public information (e.g., a MAC address) without explicit exchange over the air. As the procedure is specific to each client, the PE AP has to perform similar computations for multiple PE Clients, leading to unnecessary computation load. Thus, there is a need to reduce computation loads for the stations. Also, a similar level of obfuscation is obtained for each PE Client. However, this may not be always necessary. Hence, a need exists for enhanced procedures that allow the level of obfuscation to be adapted to various levels of risks. In particular, the inventors have noticed that while it is often necessary not to be tracked by a third-party station typically not associated with the PE AP, it may not be the case for stations yet associated with the PE AP: authorizing or even permitting the tracking between the PE Clients associated with the PE AP may appear to be relevant for some uses cases. As apparent from below, benefits of allowing tracking between the PE Clients may include reducing the complexity of the obfuscation procedure (i.e., computation loads). In this context, a method of communication in a wireless network is proposed. The method comprises, at a station of a Basic Station Set, BSS: determining a trust level enabled between the station and another station of the BSS. Usually, however not necessarily, they include the AP station of the BSS and a non-AP station of the BSS; obfuscating a current value of a privacy parameter using an encryption key shared with the sole other station if a first trust level is enabled or using an encryption key shared with multiple other stations of the BSS if a second trust level is enabled; and exchanging with the other station a frame comprising the obfuscated privacy parameter value. At least two trust levels are therefore defined, one of which (the second trust level) allowing the same encryption key to be used by multiple stations to obfuscate a privacy parameter against third-party stations not yet associated with the BSS. It turns out that the computation load at the AP station of the BSS can be drastically reduced since a single key is stored and used for these multiple stations, and a time to initialize an obfuscating function (such as a PRF) is also reduced. Such a trust level can be used when the BSS is highly trusted, i.e. there is no privacy issue throughout the stations belonging to the BSS. More than two trust levels can be provided, each having an encryption key shared with a different number / group of stations. The method of the invention also allows the stations to have obfuscating procedure adapted to the level of risks because they adapt their encryption key to the trust level defined. Mechanisms to activate / enable a trust level or the other are described below. Optional features of the invention are defined below with reference to a method, while they can be transposed into device features. The various embodiments below can be combined, unless obvious incompatibility. In some embodiments, if a second trust level is enabled, the current value of the privacy parameter is obfuscated using an encryption key shared with the entire BSS, i.e., with all the stations belonging to the BSS. The processing loads at the AP station is further reduced. In some embodiments, the same encryption key can even be used for multiple BSSs, e.g., BSSs manages by virtual APs belonging to the same physical AP. In some embodiments, obfuscating the current value includes executing a function that is shared within the other station (more generally with all the stations of the BSS) to generate a value for a privacy parameter, the shared function receiving the shared encryption key and a current value of at least one shared parameter as inputs. In some embodiments, the encryption key shared with the sole other station is derived from a Key Derivation Key, KDK, forming subpart of a Pairwise Transient Key, PTK, agreed between the two stations. By deriving the encryption key from the PTK, though the KDK, the stations reduce complexity to obtain an efficient encryption key that is strongly secured. In specific embodiments, the derivation is further based on MAC addresses of both stations. The derivation may be computed by each station at its own end, or alternatively the derivation may be made by the AP station and the shared private encryption key so generated is then provided by the AP station to the non-AP station. The derivation may be based on a KDF-Hash-256 function. In some embodiments, the encryption key shared with multiple other stations is derived from a Key Derivation Key, KDK, forming subpart of a Group Transient Key, GTK, available for the BSS. Again, by deriving the encryption key from the GTK, though the KDK, the stations reduce complexity to obtain an efficient encryption key that is strongly secured. In some embodiments, the encryption key shared with multiple other stations is generated by an access point, AP, station of the BSS and transmitted by it to the stations of the BSS. In some embodiments, an access point, AP, station of the BSS signals supported trust level or levels in a beacon frame (i.e., signaled to all stations of BSS) or a probe response frame (i.e., signaled to one specific or more stations). This is to signal the AP’s capabilities to the various stations, forthem to agree or negotiate on one or more trust levels. In some embodiments, a trust level is enabled between an access point, AP, station of the BSS and a non-AP station by exchanging (e.g., by transmitting from the non-AP station to the AP station) an Action frame including a trust level subfield set to the trust level to enable. Operations can therefore be conducted overtime to change, adapt or adjust the trust level, hence the way the privacy parameters are obfuscated. Privacy is therefore dynamically adjusted. In some embodiments, a single trust level amongst the first and second trust levels is enabled for all multiple privacy parameters comprised in the frame. In other words, the same encryption key shared with multiple other stations (or even the entire BSS) or with the sole other station is used to obfuscate the values of all the multiple privacy parameters. This highly simplifies the obfuscation procedure at the stations. In variants, the first trust level is enabled for a first subpart of multiple privacy parameters comprised in the frame and the second trust level is enabled for a second subpart of the multiple privacy parameters. In other words, the encryption key shared with the sole other station is used to obfuscate the values of the first subpart of the multiple privacy parameters while the encryption key shared with multiple other stations (or the entire BSS) is used to obfuscate the values of the second subpart of the multiple privacy parameters. Two levels (or more) of privacy are provided simultaneously to the privacy parameters embedded in the frame. Indeed, some of them can be more sensitive even within the BSS, while others are not. In some embodiments, one of the first and second subsets is made of one or more privacy parameters that are obfuscated by directly obtaining respective obfuscating values from an output of a shared pseudo-random function, and the other subset is made of one or more privacy parameters that are obfuscated by obtaining respective encoding parameter values from the output of the shared pseudo-random function and encoding a current value of the one or more privacy parameters using their respective encoding parameter values. In some embodiments, one of the first and second subsets is made of one or more privacy parameters that are obfuscated by using a first shared pseudo-random function, and the other subset is made of one or more privacy parameters that are obfuscated by using a second and different shared pseudo-random function. A shared function may have parameter inputs that are common to all (or some) stations while other parameter inputs are specific to each station (hence different from one station to the other), e.g., MAC Address, SN, PN, AID. Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured to execute any communication method as defined above. Given the above context, a method of communication between an AP station and a non-AP station in a wireless network is also proposed that reduces computation loads at both side. The method comprises, at one of the two stations (preferably both stations perform the same): executing a function that is shared with the other station to generate a value for a privacy parameter, the shared function receiving a shared private encryption key and a current value of at least one shared parameter as inputs; and exchanging with the other station a frame comprising the generated privacy parameter value, wherein the shared private encryption key is derived from a Key Derivation Key, KDK, forming subpart of a Pairwise Transient Key, PTK, agreed between the two stations. By deriving the encryption key from the PTK, though the KDK, the stations reduce complexity to obtain an efficient encryption key that is strongly secured. Optional features of the invention are defined below with reference to a method, while they can be transposed into device features. The various embodiments below can be combined, unless obvious incompatibility. In some embodiments, the derivation is further based on MAC addresses of both stations. This allows keeping an encryption key specific to relationship between the two stations, usually the AP and a specific non-AP station. In some embodiments, the derivation is computed by each station at its own end, i.e., without exchanging the shared private encryption key so generated over the air. This increases privacy. In a variant, the derivation is made by the AP station and the shared private encryption key so generated is provided by the AP station to the non-AP station. Preferably, the provision is made in an encrypted fashion (e.g., based on a session key) to keep privacy. In some embodiments, the derivation is based on a KDF-Hash-256 function. In some other embodiments, the shared parameter used as an input of the shared function includes the privacy parameter for which a value is generated. In variants, the shared parameter used as an input of the shared function includes any privacy parameter a value of which is included in the frame. Also an obfuscating new value for such privacy parameter can be obtained from the shared function. In some embodiments, the PTK is agreed between the two stations during a four-way handshake. It is recalled that the PTK is used as a session key in order to encrypt unicast frames between the AP station and the non-AP station. Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured to execute any communication method as defined above. Another aspect of the invention relates to a non-transitory computer-readable medium storing a program for causing a computer to execute any communication method as defined above. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solidstate memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Some embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which: - Figure 1 illustrates an example of a network system in which embodiments of the invention may be used; - Figure 2 illustrates exemplary Privacy Enhancements IE to be included in frames to negotiate a Trust Level between a PE Client and a PE AP; - Figure 3 illustrates, using flowcharts, operations at stations to perform an ERCM procedure according to embodiments of the invention; - Figure 4 illustrates exemplary Action frame formats allowing a PE Client to modify a Trust Level, according to embodiments of the invention; and - Figure 5 illustrates an example of a communication device of a wireless network, configured to implement at least one embodiment of the present invention. DESCRIPTION OF SOME EMBODIMENTS In a continuation to the introduction of the Randomized and Changing MAC (RCM) procedure by the IEEE 802.11 working group, the present invention regards the computation procedure used to obfuscate the values of the PE parameters (e.g., OTA MAC Address, Sequence Number, Packet Number, Traffic IDentifier). An exemplary computation procedure is based on the standardized pseudo-random function - PRF (section 12.7.1.2 of IEEE Std 802.11-2020) executed in parallel by the PE Client and the PE AP with a shared private information (encryption key) and a shared public information (e.g., PE STA’s MAC Address) without explicit exchange over the air Co-pending UK application No 2303578.5, entitled “COMMUNICATION METHOD OBFUSCATING MULTIPLE PRIVACY PARAMETERS” discloses a procedure through which only one execution of the computation procedure is necessary to generate at once the values of multiple PE parameters. For each PE parameter, two obfuscation procedures are considered: - a reset-based procedure for which the OTA value of the PE parameter is obfuscated by resetting directly its “internal” value with a new uncorrelated (and randomized) one obtained through an execution of the PRF, and - a reset-free procedure for which the OTA value of the PE parameter is obfuscated by applying an obfuscation, such as an XOR, addition or Offset with an encoding parameter value obtained through an execution of the PRF. In such a case, its “internal” value is not reset. To do so, the computation procedure is to assign at once a new reset value for each reset-based PE parameter and a new encoding parameter value (e.g., mask for XOR) for each reset-free PE parameter. It is executed in parallel by the PE Client and the PE AP with the shared private encryption key and the shared public information by using the standardized PRF. For instance, the output PE_PARAM (n+1) from the execution of the PRF is split into predetermined chunks, each chunk corresponding either to a new reset value for each resetbased PE parameter or a new shared encoding parameter value for each reset-free PE parameter. As an example, PE_PARAM (n+1) = PRF-256\250( Shared Encryption Key, “ERCM”, @MAC (n)) where “ERCM” is a string and @MAC(n) is the current value of the MAC Address considered. The chunks of the output may provide successively the following values for a given station: a new MAC address (SMAC) for outgoing OTA transmissions, a new MAC address (DMAC) for ingoing OTA transmissions, a new mask (UL-SN) for a Sequence Number (SN) used in uplink transmissions, a new mask (DL_SN) for a SN used in downlink transmissions, a new mask (UL_PN) for a Packet Number (PN) used in uplink transmissions, a new mask (DL_PN) for a PN used in downlink transmissions, a new Association Identifier (AID), a new Scrambler Seed (SS) (UL_SS) used in uplink transmissions, a new SS (DL_SS) used in downlink transmissions, a new mask (UL_TID) for a Traffic Identifier (TID) used in uplink transmissions, and a new mask (DL_TID) fora TID used in downlink transmissions. Once the PE parameters are obfuscated, they can be used, in clear, in the frame transmitted OTA. Improved computation procedures are sought to reduce computation loads at the stations, in particular at the AP station. Proposals are made herein in which the shared private encryption key used in the PRF is derived from a Key Derivation Key, KDK, forming subpart of a Pairwise Transient Key, PTK, agreed between the AP station and the non-AP station. This simplified the obtaining of the encryption key. Other proposals are made in which a trust level enabled between a station and another station of the BSS (e.g., the AP) is determined, and then a current value of a privacy parameter is obfuscated using an encryption key shared with the sole other station if a first trust level is enabled or is obfuscated using an encryption key shared with multiple other stations of the BSS if a second trust level is enabled. Two trust levels are therefore defined, one of which (the second trust level) allowing the same encryption key to be used by multiple stations, hence reducing computation loads at the AP station. The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e. wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. While the examples and embodiments are described in the context of Wi-Fi networks, the invention may be used in any type of wireless networks, like, for example, mobile phone cellular networks that implement very similar mechanisms. Figure 1 illustrates an example of a network system in which embodiments of the invention may be used. Figure 1 represents an 802.11 network (i.e. a Wi-Fi network) system 100 comprising four wireless devices: an access point (AP) station 110 and three non-AP stations (non-AP STAs) 120a, 120b, 120c. Of course, the number of non-AP stations 120a, 120b, 120c may be different from three. The AP station 110 provides wireless connections between the non-AP stations 120a, 120b, 120c and a wider network, such as the Internet. The connection of a non-AP station120a, 120b, 120c to the AP station 110 is performed by a standardized process called association. Once a non-AP station 120a, 120b, 120c is associated with the AP station 110, the non-AP station 120a, 120b, 120c can send data to the network and receive data from the network through the AP station 110. The AP station 110 may comprise, be implemented as, or known as a Node B, Radio Network Controller (RNC), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (BSC), Base Transceiver Station (BTS), Base Station (BS), Transceiver Function (TF), Radio Router, Radio Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Radio Base Station (RBS), or some other terminology. It can be a standalone product or it may be integrated in a device, for instance a broadband remote access server (BRAS). A non-AP station 120a, 120b, 120c may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, a user equipment (UE), a user station (STA), or some other terminology. In some implementations, a non-AP station 120a, 120b, 120c may be or may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or a smartphone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station 120a, 120b, 120c may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. The AP station 110 manages a set of stations that together organize their accesses to the wireless medium for communication purposes. All the stations (AP station 110 and non-AP station 120a, 120b, 120c associated with the AP station) form a service set, which may be referred to as basic service set, BSS (although another terminology can be used). It is noted that the AP station 110 can manage more than one BSS: each BSS is thus uniquely identified by a specific basic service set identifier (BSSID) and managed by a separate virtual AP station implemented in the physical AP station 110. A dedicated task group 802.11 bi has been initiated in 2019 to specify Privacy Enhancements (PE) features to be added in the standard to ensure a given level of privacy. The addressed PE features are notably relative to the obfuscation of multiple identified PE parameters when the stations send frame. The obfuscation consists in performing a simultaneous change of transmitted PE parameters or “privacy parameters” (which are transmitted in clear in the frames) to uncorrelated new values (with the previous ones) without any loss of connection. An AP station implementing PE features is referred to as PE-capable AP or PE AP and a non-AP station implementing PE features is referred to as PE-capable non-AP STA or PE non-AP STA or PE Client. The PE capability is exchanged during the association procedure of a Client with an AP. If both the Client is a PE Client and the AP is a PE AP, the PE features are activated or enabled. The PE features involving the obfuscation of multiple PE parameters relative to a PE Client or / and PE AP are here implemented through a procedure referred to as “ERCM procedure”. An exemplary list of PE parameters includes MAC addresses of PE Clients / AP, Sequence Numbers (SN), Packet Number (PN), Association Identifier (AID), Scramble Seed, Traffic Identifier (TID), Beacon Interval. This list of PE parameters is not exhaustive. Also, the ERCM procedure may be used to obfuscate only a part of this list of PE parameters. Back to Figure 1, AP STA 110 managing a BSS is a PE AP and non-AP STA 120a, 120b, 120c belonging to the same BSS are PE Clients to implement an ERCM procedure In this BSS, PE AP 110 may offer different trust levels within the BSS and assign or negotiate different trust levels with its PE Clients. As explained below, the trust levels allow the AP PE to specify a PE scope to each PE Client with respect to the other STAs (including those of the BSS but also not associated stations). The “PE scope” can be understood as the amount of stations from which the PE features protect the privacy parameters of a given station. Two trust levels are specified for illustrative purposes. However, a greater number of trust levels can be defined, corresponding to different set of stations as apparent from the explanations below. A first trust level, referred to as zero-trust level, is defined that ensures privacy of a PE client against any STAs, meaning the STAs not associated with the PE AP but also the STAs associated with the PE AP. In other words, it means that the ERCM procedure allows a full privacy of the PE STA against any STA. It is achieved by using a private encryption key for the ERCM procedure that is specific to the PE STA, hence shared between the PE STA and the PE AP only. A second trust level, referred to as BSS-trust level, is defined that ensures privacy of a PE client only against STAs not associated with the PE AP, but not against the STAs associated with the PE AP. It is achieved by using a private encryption key for the ERCM procedure that is common to the entire BSS, hence shared between the PE STAs associated with the PE AP and the PE AP itself. Indeed, one understands that, knowing the common private encryption key, the PE STAs of the BSS can track the privacy parameters of any other PE STA of the BSS despite the obfuscation. Any other trust level can therefore be defined with a private encryption key that is shared with any other grouping of PE STAs. The private encryption key to be used when the first or zero-trust level is enabled can be referred P_ERCM (by reference to “Paiwise”) in the following for ease of explanation. In some embodiments, the P_ERCM key may be a key obtained during the authentication and association procedures between the non-AP station (PE Client) and the AP station (PE AP). For example, after a successful authentication, the PE Client and the PE AP have a shared key called Pairwise Master Key (PMK), which is common to all the non-AP stations of the BSS. After authentication, a 4-Way handshake is performed, during which a key specific to each non-AP station is derived from the PMK, called Pairwise Transient Key (PTK), which is the key to be used for ciphering communications between the non-AP station and the AP station. In one or several embodiments, the PTK or a derivative thereof is used as P_ERCM key. More precisely, the P_ERCM key may be derived from a Key Derivation Key, KDK, forming subpart of the Pairwise Transient Key, PTK, agreed between the AP station and the non-AP station. Indeed, the PTK may be partitioned into EAPOL-Key confirmation key (KCK), EAPOL-Key encryption key (KEK), a Temporal Key (TK) and a Key Derivation Key (KDK), hence it includes a KDK. The length of the PTK is equal to KCK_bits + KEK_bits + TK_bits + KDK_bits wherein KCK_bits, KEK_bits, TK_bits and KDK_bits are respectively the lengths of the keys KCK, KEK, TK and KDK. The KCK_bits, KEK_bits and TK_bits depend on the negotiated Authentication and Key Management (AKM). The length KDK_bits is set to 256. KDK can therefore be retrieved from the next KDK_bits bits of the PTK (next to KCK_bits, KEK_bits and TK_bits): KDK = L(PTK, KCK_bits+KEK_bits+TK_bits, KDK_bits) where L(S, F, N) extracts bits F to F+N-1 of bit string S, starting from the left. In embodiments, the P_ERCM key is derived from the KDK by the following formula: P_ERCM Key = KDF-Hash-256(KDK, "ERCMK", @MAC_Client || @MAC_AP), with KDK extracted from the PTK. where x || y is the concatenation of x and y, KDF-Hash-256 is the key derivation function as defined in 12.7.1.6.2 (Key derivation function (KDF) of the standard IEEE Std 802.11-2020), "ERCMK” is a string name for ERCM purpose and is treated as an ASCII string, @MAC_Client is the MAC address of the PE Client and @MAC_AP is the MAC address of the PE AP. The key derivation is therefore based on a KDF-Hash-256 function. As the function can be shared by all the stations of the BSS, the derivation can be computed by each station at its own end, hence avoiding directly exchanging the P_ERCM key. Although the derivation can be made during authentication and association, it may also be performed later on, upon detecting the P_ERCM is needed. Of course, alternatives may be contemplated, including the scenario where the derivation is made by the AP station itself and the private encryption key P_ERCM so generated is then provided by the AP station to the non-AP station concerned. In alternative embodiments to a KDK-based key, the P_ERCM key is a sequence of 256 random bits generated by the PE AP with any PRF. The PE AP then provides the generated key to the PE Clients in the third message exchanged during the 4-way handshake. The message may be encrypted / cyphered using the KEK of the generated PTK (the KEK key is therefore used as a session key). The private encryption key to be used when the second or BSS-trust level is enabled can be referred G_ERCM (by reference to “Group”) in the following for ease of explanation. As it is a general key for multiple stations, the PE AP generates such G_ERCM key common to all the PE Clients associated with the PE AP, locally stores it and provides it to the multiple PE Clients. In some embodiments, the G_ERCM key is a sequence of 256 random bits generated by the PE AP with any PRF. The PE AP then provides the generated key to the PE Clients in the third message during their respective 4-way handshake. The message sent to a specific PE Client may be encrypted / cyphered using the KEK of the generated PTK for that specific PE Client. In other embodiments, the G_ERCM key may be a key obtained during the authentication and association procedures between the non-AP station (PE Client) and the AP station (PE AP). For example, the PE AP manages the BSS by defining a shared key called Group Master Key (PMK), which is common to the BSS, and deriving thereof a Group Transient Key (GTK), which is the key to be used for ciphering multicast or broadcast communications from the AP station. In one or several embodiments, the GTK or a derivative thereof is used as G_ERCM key. The G_ERCM key is therefore inherited from the GTK. More precisely, the G_ERCM key may be derived from a Key Derivation Key, KDK, forming subpart of the Group Transient Key, GTK, of the BSS. Indeed, the GTK may be partitioned into Temporal Key (TK) and Key Derivation Key (KDK). The length of the GTK is equal to TK_bits + KDK_bits wherein TK_bits and KDK_bits are respectively the lengths of the keys TK and KDK. The TK_bits depends on the negotiated Authentication and Key Management (AKM). The length KDK_bits is set to 256. KDK can therefore be retrieved from the next KDK_bits bits of the GTK: KDK = L(GTK, TK_bits, KDK_bits). In embodiments, the G_ERCM key is derived from the KDK by the following formula: G_ERCM Key = KDF-Hash-256(KDK, "ERCMK", @MAC_AP), with KDK extracted from the GTK. As the KDF-Hash-256 function can be shared by all the stations of the BSS, the derivation of G_ERCM can be computed by each station at its own end, hence avoiding directly exchanging the G_ERCM key. Although the derivation can be made during authentication and association, it may also be performed later on, upon detecting the G_ERCM is needed. Of course, alternatives may be contemplated, including the scenario where the derivation is made by the AP station itself and the private encryption key G_ERCM so generated is then provided by the AP station to the non-AP stations. In other words, the encryption key G_ERCM shared by multiple stations is generated by the access point, AP, station of the BSS and transmitted by it to the stations of the BSS. In some embodiments, the PE AP operates with only one trust level, either the zero-trust level or the BSS-trust level. In that case, the PE Clients can only select the trust level supported by the PE AP. In case only the zero-trust level is enabled, the stations only obtain and use their respective P_ERCM key for their ERCM procedures, i.e. to generate obfuscated values for the privacy (PE) parameters. In case only the BSS-trust level is enabled, the stations only obtain and use the G_ERCM key fortheir ERCM procedures. In other embodiments, the PE AP operates with two trust levels, i.e. it supports the two trust levels, namely the zero-trust level and the BSS-trust level in the example. In such a case, the PE Clients can select one of the trust levels if needed or also operate with both (as described below). If only one trust level can be used at a time, the corresponding key (P_ERCM or G_ERCM) is obtained and used for the ERCM procedures. In that case, a single trust level amongst the first and second trust levels is enabled for all multiple privacy parameters of a station. If the two trust levels can be used simultaneously, the two keys (the P_ERCM is specific to the PE Client) are obtained and used for the ERCM procedures, respectively to obfuscate corresponding PE parameters. In that case, the first trust level is enabled for a first subpart of the multiple privacy (PE) parameters of a station and the second trust level is enabled for a second subpart of the multiple privacy parameters. In some embodiments, the PE AP indicates / signals its trust level(s) (i.e., those it supports) either continuously in the Beacon frames it broadcasts or in a Probe Response frame only during the association procedure of a PE Client. Preferably, the trust levels are signalled using a dedicated IE (Information Element), referred to as PE IE, in either management frame sent by the PE AP. Exemplary PE lEs are shown in Figure 2, for use either in a Beacon frame or a Probe Response frame to signal one or more supported trust levels. Such frame can be used by a PE Client to start negotiating a trust Level with the PE AP, e.g., during the association procedure. In some embodiments, PE IE 200 contains an Element ID field 201, a Length field 202 and a Trust Level field 204. The Element ID field is set to a specific value in the range [245,254] as specified in Table 9-92 of the IEEE Std 802.11-2020, so far reserved. According to other embodiments, PE IE 210 contains an Element ID field 211, a Length field 202, an Element ID Extension 213 and a Trust Level field 204. PE IE 210 is identified by an Element ID field 111 set to 255 and an Element ID Extension 213 assigned to a specific value in the range [94,113] or [177,255] as specified in Table 9-92 of the IEEE Std 802.11-2020, so far reserved. Trust Level field 204 is set to indicate the trust level or levels supported by the PE AP. For example, Trust Level field 204 set to 0 means the PE AP supports both the zero-trust level and the BSS-trust level; while Trust Level field 204 set to 1 signals the PE AP supports only the zero-trust level and Trust Level field 204 set to 2 signals the PE AP supports only the BSS-trust level. Of course, other arrangements can be contemplated, in particular when more than two trust levels are available. The same PE IE (200 or 210) can be used by the PE Clients to select or negotiate one or more trust levels with the PE AP, given the supported trust levels. For example, PE IE may be included in the Probe Request frame or the Association Request frame sent by the PE Client. The PE Client selects one (or more) of the supported trust level or levels based on local criteria and sends a management frame to the PE AP in which it signals the selected trust level or levels. The same values for Trust Level field 204 as above can be used. However, a different matching may be implemented: Trust Level field 204 set to 1 may mean the PE Client selects the zero-trust level; while Trust Level field 204 set to 2 replies the PE Client selects the BSS-trust level, and Trust Level field 204 set to 3 signals the PE Client selects both trust levels. Value 0 is reserved in that case. The PE Client may apply the negotiated trust level to all its PE parameters or only to a subset of its PE parameters. For example, as mentioned above, a first trust level can be used to obfuscate a first subpart of these PE parameters, while a second trust level can be used to obfuscate a second and distinct subpart of these PE parameters. The two subparts (or sets) may be predetermined and known in advance by the PE AP and the PE Client(s). Figure 3 illustrates, using flowcharts, operations at the stations to perform an ERCM procedure according to embodiments of the invention. In these flowcharts, a transmitting station may be a PE Client or a PE AP; a receiving station may conversely be a PE AP or a PE Client. The process at the transmitting station starts at step 300 with the determining of a trust level enabled between the transmitting station and the receiving station. This step may merely consist in retrieving the trust level negotiated between the two stations. To be noted that when multiple trust levels are simultaneously enabled, the operations of the Figure regards a specific one of the PE parameters to obfuscate, i.e., the determining of which trust level applies for this PE parameter. Once the trust level is known, the process goes to step 310 which consists in obfuscating a current value of one or more privacy parameters using the ERCM computation. Preferably, multiple privacy parameters can be obfuscated simultaneously. Step 310 may first includes obtaining or retrieving (step 311) the shared private encryption key to be used for the ERCM computation. In embodiments, if the first or zero-trust level is enabled, the encryption key P_ERCM is retrieved. On the other hand, if the second or BSS-trust level is enabled, the encryption key G_ERCM shared with multiple other stations of the BSS is retrieved. The retrieval may merely consist in reading a local memory or register. Step 311 is followed by step 312 consisting in executing the PRF shared between the two stations. The shared PRF receives the retrieved encryption key and a current value of at least one shared PE parameter as inputs. For illustrative purposes, the following obfuscation operated by the ERCM procedure is considered. It consists in changing the values of the PE parameters transmitted in clear in 802.11 frames to a new value uncorrelated with the previous ones. Two obfuscation operations are conducted on separate PE parameters. The first one is referred to as a reset-based obfuscation operation: a new value is obtained for the PE parameter considered and is used to reset the PE parameter itself. This is the new (reset) value that is the transmitted (OTA) PE parameter included in the exchanged 802.11 frames. The second one is referred to as a reset-free obfuscation operation: rather than resetting the value of the PE parameter considered, it operates an encoding of the PE parameter in order to generate an encoded PE parameter which is used as the new value for the corresponding transmitted (OTA) PE parameter included in the exchanged 802.11 frames. The reset-free obfuscation operation may thus also be considered as an encoding-based obfuscation operation. The encoding operation may take as inputs the local current value of the PE parameter considered and an encoding parameter shared by the encoder and the decoder. The encoding operation may be a mere masking, in which case the shared encoding parameter is a shared mask having the same binary length as the PE parameter considered. Alternative to the masking (e.g., XOR) includes the binary addition or an offset, both being based on a shared encoding parameter. To perform these obfuscation operations, the ERCM procedure executes the shared PRF to generate the new reset values and the new masks (or more generally new shared encoding parameter values), each time the PE parameters need to be changed with a new obfuscation. The shared function is executed in parallel by the PE Client and the PE AP with a shared public information and the shared encryption key in order to generate on both side the same new reset values and the new masks without exchanging them in clear. Preferably, the same and single execution of the shared function simultaneously generates the new reset value or values for one or more PE parameters (here below referred to as reset-based PE parameters) to obfuscate and the new mask or masks (or more generally encoding parameter values) for one or more PE parameters to obfuscate through encoding or masking (here below referred to as encoding or reset-free PE parameters). The shared function is a function locally implemented in the PE STA and the PE AP. It is a pseudorandom function which generates a sequence of pseudorandom bits of a given length from a set of input parameters. In one or several embodiments, it is the pseudorandom function (PRF) specified in the section 12.7.1.2 of the standard IEEE Std 802.11-2020. Alternatively, any block cipher algorithm allowing to cipher a block, with similar input parameters (shared key and shared parameter having a value varying overtime) may be used. The description below mostly concentrates on the PRF for ease of explanation. However, similar considerations can be made with respect to any block cipher algorithm. The PRF is based on three main input parameters, denoted K, A, B, as well as an auxiliary parameter Len (also referred to as M) specifying the number of pseudorandom bits (128, 192, 256, ...) generated by the PRF. Section 12.7.1.2 of the standard IEEE Std 802.11-2020 specifies six PRF functions: PRF-128, PRF-192, PRF-256, PRF-384, PRF-512 or PRF-704, generating respectively 128, 192, 256, 384, 512, or 704 randomized bits. The choice of the PRF functions depends on the desired length of the output binary sequence. K is the share private information and typically corresponds to the P_ERCM key if the first trust level is enabled or to the G_ERCM key if the second trust level is enabled. The two keys are generally referred to as ERCM key for ease of explanation. It is worth to note that it is more efficient in terms of memory and processing by a PE AP to operate with the G_ERCM Key with a maximum of PE Clients in order to reduce the number of keys to be stored and the time to initialize the PRF. Parameter A is a text string specific to the application for which the ERCM PRF is used. In the scope of the ERCM procedure, it may be set to string “ERCM”. Obviously, any other text strings may be used. Parameter B is the shared public information and is a variable-length string which is known by the two stations (and more stations if for example a PE parameter of the PE AP is to be obfuscated). It is a shared parameter for the generation of the PE output by the shared function (hence it is a shared generation parameter). The shared parameter may be the current MAC address of one of the stations or the current value of a PE parameter to be changed. Alternatively, it may correspond to any PE parameter of the one station, or may be any predefined value such as the current time, and so on. According to some embodiments, when the stations use a first trust level for a first set of PE parameters and a second trust level for a second set of PE parameters, they perform two distinct execution of the shared function or functions. The same PRF with different inputs can be used, or different PRF can be used. For example, if the first trust level is the zero-trust level and the second one is the BSS-trust level, the first set of PE parameters is obfuscated with an ERCM procedure using a shared function operating with the P_ERCM Key and the second set of PE parameters is obfuscated with an ERCM procedure using a shared function operating with the G_ERCM Key. At step 312, the PE client and the PE AP execute the PRF with the input parameters set as described above. A result value or “PE output”, denoted PE_PARAM(n+1), is thus generated corresponding to a sequence of pseudo random bits from which only the L leftmost bits are extracted. L defines the number of bits required and corresponds to the sum of the lengths of the PE parameters to obfuscate. In case of the PE features are relative only to the obfuscation of one PE Client, this one is referred to as CPE Client and the PE parameters referred to as CPE parameters. In such a case, an illustrative execution of the ERCM procedure is the following one: CPE_PARAM (n+1) = PRF-M / L(ERCM Key, “Client ERCM”, @CLIENT_MAC(n)) where ERCM Key is either P_ERCM or G_ERCM depending on the enabled trust level; @CLIENT_MAC(n) is the current MAC Address of the CPE Client; M is an integer equal to 128, 192, 256, 384, 512 or 704 and L is the leftmost bits extracted from the output CPE_PARAM (n+1) corresponding to the sum of the lengths of the CPE parameters. Output CPE_PARAM (n+1) is the new set of obfuscation parameters (values or masks) to obfuscate the CPE Parameters of the CPE Client. Therefore, at step 313, the obfuscation parameters (values or masks) are retrieved from output CPE_PARAM (n+1) and the obfuscated PE parameters (i.e. their new values) are calculated where needed. In embodiments, chunks are retrieved from output CPE_PARAM (n+1) that each corresponds to a different new value for a reset-based PE parameter or to a new mask (or encoding parameter value) for a reset-free PE parameter. For illustrative purposes only, the new obfuscated PE parameters can be computed from CPE_PARAM (n+1) = PRF-256\250 (ERCM Key, “ERCM”, @MAC (n)), as follows: OTASMAC (n+1) = CPE_PARAM (n+1) [1..46] OTADMAC (n+1) = CPE_PARAM (n+1) [47..92] OTA UL_SN (n+1) = UL_SN (n) + CPE_PARAM (n+1) [93..104] OTA DL_SN (n+1) = DL_SN (n) + CPE_PARAM (n+1) [105..116] OTA UL_PN (n+1) = UL_PN (n) + CPE_PARAM (n+1) [117..164] OTA DL_PN (n+1) = DL_PN (n) + CPE_PARAM (n+1) [165..212] OTA AID (n+1) = CPE_PARAM (n+1) [213..228] OTA UL_SS (n+1) = CPE_PARAM (n+1) [229..235] OTA DL_SS (n+1) = CPE_PARAM (n+1) [236..242] OTA UL_TID (n+1) = UL_TID (n) + CPE_PARAM (n+1) [243..246] OTA DL_TID (n+1)    = DL_TID (n) + CPE_PARAM (n+1) [247..250] where CPE_PARAM (n+1) [x..y] means the chunk from bit x to bity. Once the obfuscated PE parameters are known, any frame can be prepared that includes such obfuscated PE parameters and then be sent at step 320 to the receiving station. The process at the receiving station starts at step 350, similar to step 300: determining a trust level enabled between the transmitting station and the receiving station. Once the trust level is known, the process goes to step 360, similarto step 310, which consists in obfuscating a current value of one or more privacy parameters using the ERCM computation and retrieving the masks (or encoding parameter values). This step includes substeps 311, 312 and 313. Steps 350 and 360 may be performed early to receiving (step 370) the frame sent by the transmitting station at step 320. The step of receiving 370 may be based on one or more of the obfuscated PE parameters. For example, the receiving frame may discard the frame if the RA or TA field of the MAC header does not match an obfuscated MAC address of either station. In case of reset-free PE parameter, the received PE parameter may be deobfuscated, i.e. decoded using the corresponding encoding parameter value. As an example, the received (obfuscated) PE parameter may be XORed using the corresponding mask. The deobfuscated value of the PE parameter can then be used in a conventional manner. Once the frame has been received, the receiving station processes it at step 380. Such step may also be based on one or more of the obfuscated PE parameters. For example, the receiving station uses the obfuscated reset-based PE Parameters or may deobfuscate the received reset-free PE Parameters using the corresponding masks or encoding parameter values (e.g., forTID - UL_TID or DL_TID) to process the frame accordingly. This ends the process. It has been explained above how the PE Client and the PE AP can negotiate the trust level (or levels) given the trust levels supported by the PE AP. In some embodiments, the PE Client may request a change of Trust Level at any time, from amongst the supported trust levels. This may be performed by transmitting a dedicated management frame, e.g., a specific PE Action frame (Trust Level Change Request), to the PE AP. Conversely, the PE AP can confirm the change or makes a counterproposal by transmitting also a specific PE Action frame (Trust Level Change Response). When a negotiation is possible through PE Action frames, a PE Action frame of the Trust Level Confirmation type may also be used to provide an agreement on the last received proposal, hence ending the negotiation. Whatever the scenario, a trust level is enabled between the PE AP and the PE Client by exchanging (e.g., by transmitting from the PE Client to the PE AP) an Action frame including a trust level subfield set to the trust level to enable. This is illustrated by Figure 4 which shows exemplary PE Action frames allowing a station, e.g., a PE Client, to modify its Trust Level. The proposed frames follow the Action frame format as specified in IEEE Std 802.11- 2020. An Action frame identified by a ‘Category’ field 411 assigned to a specific value k in the range [31,125] as specified in Table 9-51 of the IEEE Std 802.11-2020, so far reserved. For the purpose of illustration, a reserved value, e.g. 31, is used to define a new category value corresponding to “PE Action frames”. Of course, any other value in the above range than 31 can be used. The frame formats shown in the Figure are identified by the one-byte ‘PE Action’ field 412 which follows immediately the Category field 411. The values of the PE Action field 412 may be defined to distinguish between a Trust Level Change Request, a Trust Level Change Response, and optionally a Trust Level Confirmation. As an example, the following table can be used: Action Field value 412 Meaning 1 Trust Level Change Request 2 Trust Level Change Response A PE Action field value set to 1 thus signals a Trust Level Change Request shown under reference 410 in the Figure. A PE Action field value set to 2 signals a Trust Level Change Response shown under reference 420 in the Figure. The exemplary Trust Level Change Request 410 includes, in addition to Category field 411 set to value 31 and PE Action field 412 set to value 1, a Trust Level field 413, the value of which signals one or more trust levels to enable. For example, Trust Level field 413 is set to 0 to signal a switch from the zero-trust level to the BSS-trust level; while Trust Level field 413 is set to 1 to signal a switch from the BSS-trust level to the zero-trust level. Of course, another signaling may be used, e.g., to only signal the targeted trust level, rather than signaling a switch. For example, another trust level can be enabled while keeping a yet-enabled trust level, to have both trust levels simultaneously applying. A station may also request switching to two other trust levels than a currently-enabled one. The exemplary Trust Level Change Response 420 includes, in addition to Category field 411 set to value 31 and PE Action field 412 set to value 2, a Trust Level Status field 423, the value of which signals either a counterproposal or a mere acceptance or refusal. In the last scenario, Trust Level Status 423 may be set to 1 to signal the PE AP accepts the requested Trust Level switch; while Trust Level Status field 423 may be set to 0 to signal the PE AP refuses the requested Trust Level switch. In another embodiment, Trust Level Change Response 420 may further include optional Trust Level field 413 in case a counterproposal is made. For example, Trust Level Status field 423 may be set to 2 to signal a counterproposal, in which case Trust Level field 413 is added that signal the trust level or levels elected for the counterproposal. As apparent from the above, two or more trust levels can be implemented that allow switching between various encryption keys to obfuscate, using a PRF, PE parameters. The ERCM Key is specific to each CPE client. In such a case, it is derived from the PTK and more particularly from a KDK generated especially for ERCM procedure: ERCM Key = KDF-Hash-256(KDK, "ERCMK", @MAC_Client || @MAC_AP) wherein the KDF-Hash-256 generates the 256 bits of the ERCM Key, KDK derived from PTK is generated specifically for ERCM procedure, @MAC_Client and @MAC_AP are the MAC addresses of the CPE Client and CPE AP used for 4-way Handshake, “ERCMK” is a context string name for ERCM and is treated as an ASCII string. Alternatively, the ERCM Key is a common group temporal key known by all CPE Clients. It is a 256-bits random value shared during the 4-way Handshake generated by the AP and encrypted by the KEK of the PTK in the message 3 (with GTK, IGTK and BIGTK). Figure 5 schematically illustrates a communication device 500, typically any of the stations of Figure 1, of a wireless network, configured to implement at least one embodiment of the present invention. The communication device 500 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 500 may comprise a communication bus 513 to which may be connected: - a central processing unit 501, such as a processor, denoted CPU; - a memory 503, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and - at least two communication interfaces 502 and 502’ connected to the wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 504 and 504’, respectively. Preferably the communication bus 513 may provide communication and interoperability between the various elements included in the communication device 500 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 500 directly or by means of another element of the communication device 500. The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 502 or 502’, in order to be stored in the memory 503 of the communication device 500 before being executed. In an embodiment, the device 500 may be a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Embodiment(s) of the present invention can also be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g., one or more programs) recorded on a storage medium (which may also be referred to more fully as a “non-transitory computer-readable storage medium”) to perform the functions of one or more of the above-described embodiment(s) and / or that includes one or more circuits (e.g., application specific integrated circuit (ASIC)) for performing the functions of one or more of the abovedescribed embodiment(s), and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the above-described embodiment(s) and / or controlling the one or more circuits to perform the functions of one or more of the above-described embodiment(s). The computer may comprise one or more processors (e.g., central processing unit (CPU), micro processing unit (MPU)) and may include a network of separate computers or separate processors to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium. The storage medium may include, for example, one or more of a hard disk, a random-access memory (RAM), a read only memory (ROM), a storage of distributed computing systems, an optical disk (such as a compact disc (CD), digital versatile disc (DVD), etc.), a flash memory device, a memory card, and the like. Expressions such as “comprise”, “include”, “incorporate”, “contain”, “is” and “have” are to be construed in a non-exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. Reference to the singular is also to be construed in be a reference to the plural and vice versa. A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed may be combined without departing from the scope of the invention.

Claims

1. A method of communication in a wireless network, comprising, at a station of a Basic Station Set, BSS:determining a trust level enabled between the station and another station of the BSS;obfuscating a current value of a privacy parameter using an encryption key shared with the sole other station if a first trust level is enabled or using an encryption key shared with multiple other stations of the BSS if a second trust level is enabled; andexchanging with the other station a frame comprising the obfuscated privacy parameter value.

2. The method of Claim 1, wherein if a second trust level is enabled, the current value of the privacy parameter is obfuscated using an encryption key shared with the entire BSS.

3. The method of Claim 1, wherein obfuscating the current value includes executing a function that is shared within the other station to generate a value for a privacy parameter, the shared function receiving the shared encryption key and a current value of at least one shared parameter as inputs.

4. The method of Claim 1, wherein the encryption key shared with the sole other station is derived from a Key Derivation Key, KDK, forming subpart of a Pairwise Transient Key, PTK, agreed between the two stations.

5. The method of Claim 4, wherein the derivation is further based on MAC addresses of both stations.

6. The method of Claim 4, wherein the derivation is computed by each station at its own end.

7. The method of Claim 4, wherein the derivation is made by the AP station and the shared private encryption key so generated is provided by the AP station to the non-AP station.

8. The method of Claim 4, wherein the derivation is based on a KDF-Hash-256 function.

9. The method of Claim 1, wherein the encryption key shared with multiple other stations is derived from a Key Derivation Key, KDK, forming subpart of a Group Transient Key, GTK, available for the BSS.

10. The method of Claim 1, wherein the encryption key shared with multiple other stations is generated by an access point, AP, station of the BSS and transmitted by it to the stations of the BSS.

11. The method of Claim 1, wherein an access point, AP, station of the BSS signals supported trust level or levels in a beacon frame or a probe response frame.

12. The method of Claim 1, wherein a trust level is enabled between an access point, AP, station ofthe BSS and a non-AP station by exchanging an Action frame including a trust levelsubfield set to the trust level to enable.

13. The method of Claim 1, wherein a single trust level amongst the first and second trust levels is enabled for all multiple privacy parameters comprised in the frame.

14. The method of Claim 1, wherein the first trust level is enabled for a first subpart of multiple privacy parameters comprised in the frame and the second trust level is enabled for a second subpart of the multiple privacy parameters.

15. The method of Claim 1, wherein one of the first and second subsets is made of one or more privacy parameters that are obfuscated by directly obtaining respective obfuscating values from an output of a shared pseudo-random function, and the other subset is made of one or more privacy parameters that are obfuscated by obtaining respective encoding parameter values from the output of the shared pseudo-random function and encoding a current value of the one or more privacy parameters using their respective encoding parameter values.

16. The method of Claim 1, wherein one of the first and second subsets is made of one or more privacy parameters that are obfuscated by using a first shared pseudo-random function, and the other subset is made of one or more privacy parameters that are obfuscated by using a second and different shared pseudo-random function.

17. A method of communication between an AP station and a non-AP station in a wireless network, comprising, at one of the two stations:executing a function that is shared with the other station to generate a value for a privacy parameter, the shared function receiving a shared private encryption key and a current value of at least one shared parameter as inputs; andexchanging with the other station a frame comprising the generated privacy parameter value,wherein the shared private encryption key is derived from a Key Derivation Key, KDK, forming subpart of a Pairwise Transient Key, PTK, agreed between the two stations.

18. The method of Claim 17, wherein the derivation is further based on MAC addresses of both stations.

19. The method of Claim 17, wherein the derivation is computed by each station at its own end.

20. The method of Claim 17, wherein the derivation is made by the AP station and the shared private encryption key so generated is provided by the AP station to the non-AP station.

21. The method of Claim 17, wherein the derivation is based on a KDF-Hash-256 function.

22. The method of Claim 17, wherein the shared parameter used as an input of the shared function includes the privacy parameter for which a value is generated.

23. The method of Claim 17, wherein the shared parameter used as an input of theshared function includes any privacy parameter a value of which is included in the frame.

24. The method of Claim 17, wherein the PTK is agreed between the two stations during a four-way handshake.

25. A wireless communication device comprising at least one microprocessor configured 5 to execute the method of Claim 1 or 17.

26. A non-transitory computer-readable medium storing a program for causing a computer to execute the method of Claim 1 or 17.

Images