Mac header protection with preexisting keys

Abstract

To provide systems and methods for network traffic protection, including protection of MAC headers.SOLUTION: In a system 200, a sender device is configured to: compute, using a temporal key programmed in hardware, a first key for a body of a frame and a second key for a header of the frame, different from the first key; encrypt the body of the frame at a machine access control (MAC) layer using the first key, and encrypt the header of the frame at the MAC layer using the second key; compute a first MIC of the encrypted frame using the first key, and compute a second MIC of a content of the header at the MAC layer using the second key; and transmit the frame with the first MIC and the second MIC to a receiver device. The receiver device is configured to determine integrity of the header of the frame based on the second MIC.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] Cross - reference to related applications This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 601438, filed on November 21, 2023, U.S. Provisional Patent Application No. 63 / 558838, filed on February 28, 2024, and U.S. Provisional Patent Application No. 63 / 563092, filed on March 8, 2024, all of which are hereby incorporated by reference in their entirety.

[0002] Technical Field The present disclosure generally relates to systems and methods for network traffic protection, including, for example, the protection of MAC headers.

[0003] Background When engaging in network communication, network devices can use Media Access Control (MAC) addresses to identify or distinguish the devices involved in the communication. In various network communications, devices can use MAC addresses to route data to their intended destinations.

Summary of the Invention

[0004] The technical solution provided in this specification is directed to providing security and integrity in a Machine Access Control (MAC) header in a wireless communication frame. In wireless communication, the MAC header is vulnerable to tampering, access, or unauthorized access by adversaries who may intercept network packets and modify the MAC header data. The present technical solution uses a hardware-programmed Temporal Key (TK) to derive separate keys for the body and header of a communication frame at the MAC layer, such that the integrity of network packets is improved in a computationally efficient manner. For example, in a situation where a wireless device exchanges sensitive information over a network, the MAC header data of any intercepted network packet can be manipulated to gain unauthorized access to the system. The present technical solution provides a computationally efficient and secure technique for protecting the MAC header using existing systems and network infrastructure, thereby reducing the risk of unauthorized access or data manipulation without adding design complexity.

[0005] One aspect of the present technical solution is directed to a system. The system can include one or more processors coupled to a memory. The one or more processors can be configured to calculate a first key for the body of a frame and a second key for the header of the frame using a temporary key (TK) programmed in hardware, where the second key is different from the first key. The one or more processors can be configured to encrypt the body of the frame in a Machine Access Control (MAC) layer using the first key and encrypt the header of the frame in the MAC layer using the second key. The one or more processors can be configured to calculate a first Message Integrity Code (MIC) of the encrypted frame using the first key and calculate a second MIC for the content of the header of the frame in the MAC layer using the second key. The one or more processors can be configured to transmit the frame to a receiver together with the first MIC and the second MIC, and the receiver is configured to determine the integrity of the header of the frame based at least on the second MIC.

[0006] The one or more processors can be configured to generate a composite MIC from the first MIC and the second MIC. The one or more processors can be configured to transmit the composite MIC to the receiver to determine the integrity of the frame. The composite MIC can be generated using one of a concatenation of the first MIC and the second MIC, a bitwise exclusive OR (XOR) calculation applied to the first MIC and the second MIC, or any reversible calculation applied to the first MIC and the second MIC.

[0007] One or more processors may be configured to calculate a first key using a HMAC (Hash-based Message Authentication Code) operation with a first input of TK and a first fixed pattern. One or more processors may be configured to calculate a second key using a HMAC operation with a second input of TK and a second fixed pattern. The first fixed pattern may include a packet number (PN) of a network packet of a frame, and the second fixed pattern may include one or more characters of a body. Encryption of the body of the frame in the MAC layer using the first key may be performed simultaneously with encryption of the header of the frame in the MAC layer using the second key.

[0008] The frame may correspond to a first network packet of a plurality of network packets. The first network packet may include a first packet number in the header of the frame. One or more processors may be configured to determine to retransmit the first network packet as a second network packet having a second packet number in a second header of a second frame of the second network packet. The second packet cipher may be different from the first packet number. One or more processors may be configured to calculate, using TK, a first key for a second body of a second frame of the second network packet and a second key for a second header of the second frame. The first key of the first network packet may be different from the first key of the second network packet.

[0009] The first key for the second body of the second frame of the second network packet can be the same as the first key for the body of the frame of the first network packet. One or more processors may be configured to identify one or more frames in the MAC layer to be encrypted for wireless communication. One or more processors may be configured to encrypt the second frame of the second network packet in the MAC layer using the first key of the second body and the second key for the second header.

[0010] One or more processors may be configured to obtain a Pairwise Master Key (PMK) during communication via a wireless network between a device including the one or more processors and a receiver. One or more processors may be configured to generate a Temporary Key (TK) using the PMK. The receiver may be configured to determine the integrity of the header based on verification of the integrity of the header using the second MIC before decrypting the frame.

[0011] One or more processors may be configured to include a second MIC in the header of the frame and transmit the frame with the second MIC included in the header of the frame. One or more processors may be configured to calculate at least one of the first key or the second key using the AES (Advanced Encryption Standard) algorithm and at least one of the Cipher Block Chaining-MAC Protocol (CCMP) or the Galois / Counter Mode Protocol (GCMP) using at least one of the first MIC or the second MIC. The receiver may be configured to verify the integrity of the header of the frame using the second MIC before processing the body of the frame.

[0012] One aspect of the present technical solution is directed to a method. The method can be a method for providing protection for a machine access control (MAC) header of a frame. The method can include identifying, by one or more processors, a temporary key (TK) programmed in hardware for encrypting a frame in a machine access control (MAC) layer for wireless communication. The method can include calculating, by one or more processors, a first key for encrypting the body of the frame and a second key for encrypting the header of the frame using the TK, where the second key is different from the first key. The method can include identifying, by one or more processors, one or more frames in the MAC layer to be encrypted for wireless communication. The method can include encrypting, by one or more processors, the body of one or more frames in the MAC layer using the first key and encrypting the header of one or more frames in the MAC layer using the second key.

[0013] The method can include calculating the first key using an HMAC (Hash-based Message Authentication Code) operation with a first input of the TK and a first fixed pattern. The method can include calculating the second key using an HMAC operation with a second input of the TK and a second fixed pattern. The first fixed pattern can include a packet number (PN) of a network packet of the frame, and the second fixed pattern can include one or more characters of the body.

[0014] The frame can correspond to a first network packet of a plurality of network packets, and the first network packet includes a first packet number in the header of the frame. The method can include determining, by one or more processors, to retransmit the first network packet as a second network packet having a second packet number in a second header of a second frame of the second network packet. The second packet number can be different from the first packet number. The method can include calculating, by one or more processors, using TK, a first key for a second body of a second frame of the second network packet and a second key for a second header of the second frame. The first key of the first network packet can be different from the first key of the second network packet. The first key for the second body of the second frame of the second network packet can be the same as the first key for the body of the frame of the first network packet. The method can include identifying, by one or more processors, one or more frames in the MAC layer to be encrypted for wireless communication. The method can include encrypting, by one or more processors, a second frame of the second network packet in the MAC layer using the first key of the second body and the second key for the second header.

[0015] The method can include calculating the first key for the body using the AES (Advanced Encryption Standard) operation with a first input of TK and a first fixed pattern, and calculating the second key for the header of the frame using the same AES operation with a second input of TK and a second fixed pattern. The method can include calculating the second key for the header using the AES operation with a first input of TK and a first fixed pattern and using TK as the first key for the body of the frame.

[0016] The encryption of one or more frames can include applying CMAC (Cipher-based Message Authentication Code) or GMAC (Galois / Counter Code) technology in association with AES (Advanced Encryption Standard) encryption. The method can include selecting between CMAC technology and GMAC technology based on at least one of the security settings of the wireless communication or the state of the wireless communication network. The method can include generating an initialization vector (IV) for encryption based on frame parameters and using the IV to encrypt the frame body.

[0017] One aspect of the technical solution is directed to a system. The system can include one or more processors coupled to a memory and configured to identify a temporary key (TK) programmed in hardware for encrypting frames in a machine access control (MAC) layer for wireless communication. The one or more processors can be configured to calculate a first key for encrypting the frame body and a second key for encrypting the frame header using the TK, where the second key is different from the first key. The one or more processors can be configured to identify one or more frames in the MAC layer to be encrypted for wireless communication. The one or more processors can be configured to encrypt the body of one or more frames in the MAC layer using the first key and encrypt the header of one or more frames in the MAC layer using the second key.

[0018] These and other aspects and features of the present embodiment will become apparent to those skilled in the art when reviewing the following description of specific embodiments together with the accompanying drawings.

Brief Description of the Drawings

[0019]

Fig. 1A

[0020]

Fig. 1B

Fig. 1C

[0021]

Fig. 2

[0022]

Fig. 3

[0023]

Fig. 4

[0024]

Fig. 5

[0025]

Fig. 6

[0026]

Fig. 7

DETAILED DESCRIPTION OF THE INVENTION

[0027] Detailed Description Now, this embodiment will be described in detail in relation to the drawings. The drawings are provided as exemplary examples of the embodiment to enable those skilled in the art to implement the embodiment and to clarify alternatives to those skilled in the art. The drawings and the following examples are not intended to limit the scope of this embodiment to a single embodiment, but other embodiments are possible by replacing some or all of the described or illustrated elements, or are obvious to those skilled in the art. Specific elements of this embodiment can be implemented partially or fully using known components, and only those parts of such known components necessary for understanding this embodiment will be described, and detailed descriptions of other parts of such known components will be omitted so as not to obscure this embodiment. The embodiments described in these exemplified contexts should not be limited thereto. As will be obvious to those skilled in the art, unless otherwise specifically defined herein, embodiments described as being implemented, for example, in software should not be limited to such embodiments, but they can include embodiments implemented in hardware, or combinations of software and hardware, and vice versa. In this specification, embodiments showing a single component should not be considered limiting, but rather the present disclosure is intended to cover other embodiments including a plurality of the same components, unless otherwise explicitly specified herein, and vice versa. Furthermore, the applicant does not intend that any term in this specification or the claims be considered to have a rare or special meaning unless explicitly stated as such. Furthermore, this embodiment includes current and future known equivalents to the known components referred to herein by way of example.

[0028] The following IEEE standards, including any draft(s) of the IEEE standard(s), namely, Wi-Fi Alliance standards, and including, but not limited to, the IEEE 802.11a® standard, the IEEE 802.11b® standard, the IEEE 802.11g® standard, the IEEE P802.11n® standard, the IEEE 802.11ac® standard, and the IEEE 802.11be® draft version D3.0 standard, are hereby incorporated by reference in their entirety and made a part of this disclosure for all purposes. This disclosure may refer to aspects of these standard(s), but this disclosure is not limited in any way by these standard(s).

[0029] For reading the descriptions of the following various embodiments, the descriptions of the following sections regarding this specification and their individual contents can be useful. That is, - Section A describes a network environment and a computing environment that can be useful for implementing the embodiments described in this specification, and - Section B describes MAC header protection using a pre-shared key.

[0030] A. Computing and Network Environment Before considering specific embodiments of this solution, it can be beneficial to describe aspects of the operating environment and related system components (e.g., hardware components) in connection with the methods and systems described in this specification.

[0031] Referring to FIG. 1A, an embodiment of a network environment is shown. In general, the network environment includes a wireless communication system including one or more access points (APs) or network devices 106, one or more stations or wireless communication devices 102, also referred to as STAs, and network hardware components or network hardware 192. The wireless communication devices or STAs 102 can include, for example, laptop computers, tablets, personal computers, and / or mobile phone devices. Details of an embodiment of each station or wireless communication device 102 and AP or network device 106 (e.g., their internal hardware configuration and software configuration) can be described in more detail in relation to FIGS. 1B and 1C. In one embodiment, the network environment can be an ad hoc network environment, an infrastructure wireless network environment, a subnet environment, etc. The network device 106 or AP can be operably coupled to the network hardware 192 via a local area network connection.

[0032] The network device 106 or AP can include, for example, a Wi-Fi device providing a WLAN or a 5G base station for providing a cellular network. The network hardware 192, which can include routers, gateways, switches, bridges, modems, system controllers, electrical appliances, etc., can provide a local area network connection to the communication system. Each of the network devices 106 or APs can have an associated antenna or antenna array for communicating with wireless communication devices in its area. The wireless communication device 102 can register with a specific network device 106 or AP to receive services from the communication system (e.g., via a SU-MIMO or MU-MIMO configuration). In the case of direct connection (e.g., two-point communication), some wireless communication devices can communicate directly via an assigned channel and communication protocol. Some of the wireless communication devices 102 can be mobile or relatively stationary with respect to the network device 106 or AP.

[0033] In some embodiments, network device 106 or AP includes a device or module (including a combination of hardware and software) that enables wireless communication device 102 to connect to a wired network using Wireless Fidelity (WiFi) or other standards. Network device 106 or AP may sometimes be referred to as a wireless access point (WAP). Network device 106 or AP may be implemented (e.g., configured, designed, and / or constructed) to operate in a wireless local area network (WLAN). In some embodiments, network device 106 or AP can be connected to a router as a stand-alone device (e.g., via a wired network). In other embodiments, network device 106 or AP can be a component of a router. Network device 106 or AP can provide multiple device accesses to the network. Network device 106 or AP can be connected to, for example, a wired Ethernet connection and can provide a wireless connection using a radio frequency link to other devices 102 for utilizing that wired connection. Network device 106 or AP can be implemented to support a standard for transmitting and receiving data using one or more radio frequencies. These standards and frequencies they use can be defined by IEEE (e.g., IEEE 802.11 standard). Network device 106 or AP can be configured and / or used to support a public Internet hotspot and / or to extend the Wi-Fi signal range of the network on the network.

[0034] In some embodiments, the access point or network device 106 can be used for a wireless network (e.g., within a home, in a vehicle, or in a building) (e.g., IEEE 802.11, Bluetooth, ZigBee®, any other type of radio frequency based on a network protocol and / or variations thereof). Each of the wireless communication devices 102 can include a built-in radio and / or be coupled to a radio. Such wireless communication devices 102, and / or the access point or network device 106, can operate according to various aspects of the present disclosure as presented herein to enhance performance, to reduce cost and / or size, and / or to enhance broadband applications. Each wireless communication device 102 can have the ability to function as a client node that searches for access to resources (e.g., data, and connections to networked nodes such as servers) via one or more access points or network devices 106.

[0035] The network connection can include any type and / or form of network and can include any of the following, namely, a point-to-point (between two points) network, a broadcast network, a telecommunications network, a data communication network, a computer network. The topology of the network can be a bus, star, or ring network topology. The network can consist of any such network topology known to those skilled in the art that can support the operations described herein. In some embodiments, different types of data can be transmitted via different protocols. In other embodiments, the same type of data can be transmitted via different protocols.

[0036] The communication device(s) 102 and the access point(s) or network device 106 can be arranged as and / or executed by a computing device of any type and form, such as a computer, a network device, or an electronic product, that can communicate on any type and form of network and execute the operations described herein. FIGS. 1B and 1C show block diagrams of a computing device 100 useful for implementing one embodiment of the wireless communication device 102 or the network device 106. As shown in FIGS. 1B and 1C, each computing device 100 includes a processor 121 (e.g., a central processing unit) and a main memory device 122. As shown in FIG. 1B, the computing device 100 can include a storage device 128, an installation device 116, a network interface 118, an I / O controller 123, display devices 124a-124n, a keyboard 126, and a pointing device 127 such as a mouse. The storage device 128 can include an operating system and / or software. As shown in FIG. 1C, each computing device 100 can also include additional optional elements such as a memory port 103, a bridge 170, one or more input / output devices 130a-130n, and a cache memory 140 that communicates with the central processing unit or processor 121.

[0037] The central processing unit or processor 121 is any logic circuit that responds to and processes instructions fetched from the main memory device 122. In many embodiments, the central processing unit or processor 121 is provided by a microprocessor device such as one manufactured by Intel Corporation of Santa Clara, California, one manufactured by International Business Machines of White Plains, New York, or one manufactured by Advanced Micro Devices of Sunnyvale, California. The computing device 100 can be based on any of these processors, or any other processor capable of operating as described herein.

[0038] The main memory device 122 can be one or more memory chips capable of storing data and enabling any storage location to be directly accessed by the microprocessor or processor 121, such as any type or variety of static RAM (SRAM), dynamic RAM (DRAM), ferroelectric memory (FRAM), NAND flash memory, NOR flash memory, and semiconductor drive (SSD). The main memory device 122 can be based on any of the memory chips described above, or any other available memory chip capable of operating as described herein. In the embodiment shown in FIG. 1B, the processor 121 communicates with the main memory device 122 via the system bus 150 (described in more detail later). FIG. 1C shows an embodiment of a computing device 100 in which the processor communicates directly with the main memory device 122 via the memory port 103. For example, in FIG. 1C, the main memory device 122 can be DRDRAM.

[0039] Figure 1C shows one embodiment in which main processor 121 communicates directly with cache memory 140 via a secondary bus, sometimes called a backside bus. In other embodiments, main processor 121 communicates with cache memory 140 using system bus 150. Cache memory 140 generally has a faster response time than main memory device 122 and is provided, for example, by SRAM, BSRAM, or EDRAM. In the embodiment shown in Figure 1C, processor 121 communicates with various I / O devices 130 via local system bus 150. Various buses can be used to connect the central processing unit or processor 121 to any of the I / O devices 130 and include, for example, the VESA VL bus, ISA bus, EISA bus, Micro Channel Architecture (MCA) bus, PCI bus, PCI-X bus, PCI-Express bus, or NuBus. For embodiments in which the I / O device is video display 124, processor 121 can use an AGP (Advanced Graphics Port) to communicate with display 124. Figure 1C shows one embodiment of a computer or computer system 100 in which main processor 121 can communicate directly with I / O device 130b via, for example, HyperTransport, RapidIO, or InfiniBand communication technology. Figure 1C also shows one embodiment in which direct communication with the local bus is mixed, i.e., processor 121 communicates directly with I / O device 130b while at the same time communicating with I / O device 130a using a local interconnect bus.

[0040] A variety of I / O devices 130a - 130n can exist in the computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, dials, touchpads, touchscreens, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, projectors, and sublimation printers. The I / O devices can be controlled by the I / O controller 123 as shown in FIG. 1B. The I / O controller can control one or more I / O devices such as the keyboard 126 and the pointing device 127 (e.g., mouse or optical pen). Further, the I / O devices can also provide storage devices and / or installation media to the computing device 100. In yet other embodiments, the computing device 100 can provide a USB connection (not shown) for accepting portable USB storage devices such as the USB flash drive product line of devices manufactured by Twintech Industry, Inc. of Los Alamitos, California.

[0041] Referring again to FIG. 1B, computing device 100 can support any suitable installation device 116, such as a disk drive, a CD-ROM drive, a CD-R / RW drive, a DVD-ROM drive, a flash memory drive, tape drives in various formats, a USB device, a hard drive, a network interface, or any other device suitable for installing software and programs. Computing device 100 can further include a storage device, such as one or more hard disk drives or redundant arrays of independent disks, for storing an operating system and other related software, and for storing application software programs, such as any program or software 120 (e.g., configured and / or designed for the system and method) for implementing the systems and methods described herein. Optionally, any of the installation devices 116 can also be used as a storage device. Further, the operating system and software can be executed from a bootable medium.

[0042] Furthermore, computing device 100 can include a network interface 118 for coupling to a network through various connections, which can include, but are not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECnet), broadband connections (e.g., ISDN, frame relay, ATM, gigabit Ethernet, Ethernet over SONET), wireless connections, or any combination of any or all of the above. The connections can be established using various communication protocols (e.g., TCP / IP, IPX, SPX, NetBIOS, Ethernet, Arcnet, SONET, SDH, FDDI (Fiber Distributed Data Interface), RS232, IEEE802.11, IEEE802.11a, IEEE802.11b, IEEE802.11g, IEEE802.11n, IEEE802.11ac, IEEE802.11ad, CDMA, GSM, WiMax, and direct asynchronous connections). In one embodiment, computing device 100 communicates with other computing devices 100' via any type and / or form of gateway or tunneling protocol, such as SSL (Secure Sockets Layer) or TLS (Transport Layer Security). Network interface 118 can include a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for coupling a computing device 100 capable of communicating and performing the operations described herein to any type of network.

[0043] In some embodiments, computing device 100 can include or be connected to one or more display devices 124a - 124n. Accordingly, any of I / O devices 130a - 130n and / or I / O controller 123 can include any type and / or form of suitable hardware, software, or a combination of hardware and software to support, enable, or perform the connection and use of display device(s) 124a - 124n by computing device 100. For example, computing device 100 can include any type and / or form of video adapter, video card, driver, and / or library for interfacing (mediating the connection), communicating with, connecting to, or otherwise using display device(s) 124a - 124n. In one embodiment, the video adapter can include a plurality of connectors for interfacing with display device(s) 124a - 124n. In other embodiments, computing device 100 can include a plurality of video adapters, in which case each video adapter is connected to display device(s) 124a - 124n. In some embodiments, some portion of the operating system of computing device 100 can be configured to use a plurality of display devices 124a - 124n. In a further embodiment, I / O device 130 can serve as a bridge between system bus 150 and an external communication bus, which can be, for example, a USB bus, Apple Desktop Bus, RS - 232 serial connection, SCSI bus, FireWire bus, FireWire 800 bus, Ethernet bus, AppleTalk bus, Gigabit Ethernet bus, Asynchronous Transfer Mode bus, Fibre Channel bus, optical fiber bus, SAS (Serial Attached SCSI) bus, USB connection, or HDMI bus.

[0044] The computing device 100 of the type shown in FIGS. 1B and 1C can operate under the control of an operating system that controls the scheduling of tasks and access to system resources. The computing device 100 can execute any operating system, and the operating system can be, for example, any version of the Microsoft Windows® operating system, various open-source Unix® and Linux operating systems, any version of MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open-source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system that can be executed on the computing device and perform the operations described herein. Representative operating systems include, but are not limited to, Android® made by Google Inc.; Windows® 7, 8, and 10 made by Microsoft Corporation of Redmond, Washington; MAC OS made by Apple Computer of Cupertino, California; WebOS made by Research In Motion (RIM); OS / 2 made by International Business Machines of Armonk, New York; and Linux, a freely available operating system distributed by Caldera Corp. of Salt Lake City, Utah, or any type and / or form of Unix operating system.

[0045] The computer system or computing device 100 can be any workstation, telephone, desktop computer, laptop or notebook computer, server, portable computer, cellular phone or other portable communication device, media playback device, gaming console, mobile computing device, or any other type and / or form of computing device, communication device or media device capable of communicating. In some embodiments, the computing device 100 can have various processors, operating systems, and input devices compatible with the device. For example, in one embodiment, the computing device 100 is a smartphone, mobile device, tablet or personal digital assistant. Further, the computing device 100 can be any workstation, desktop computer, laptop or notebook computer, server, portable computer, cellular phone, any other computer, or other form of computing device or communication device capable of communicating and having sufficient processor capabilities and memory capacity to perform the operations described herein.

[0046] The aspects of the operating environment and components described above will become apparent in connection with the systems and methods disclosed herein.

[0047] B. MAC Header Protection Using a Pre-Shared Key During network communication, data packets are retransmitted by a transmitter, and some header fields in the Media Access Control (MAC) header of the data packet may be modified by a threat actor. In some types of network communication, such as wireless local area network (WLAN) communication (e.g., Wi-Fi (registered trademark)), the MAC header may contain unencrypted data. These unencrypted header fields can first be masked, but may be intercepted and modified during retransmission of the transmission, enabling potential attacks on the system. This vulnerability opens a potential attack door to the system because an adversary can manipulate fields such as the power management state and the aggregation state. Encryption mechanisms such as the Counter Mode Cipher Block Chaining-MAC Protocol (CCMP) and the Galois / Counter Mode Protocol (GCMP) can be used to encrypt the frame and calculate the Integrity Check Value (ICV) / Message Integrity Code (MIC) (hereinafter referred to as the message integrity code) indicating the integrity of the frame. However, some of the MAC header fields remain unencrypted and may remain vulnerable to attacks.

[0048] To address this problem, the present technical solution can use a pre-existing cryptographic key to generate or calculate the MIC on the MAC header, whereby the original state of the MAC address is captured for network packet integrity verification upon reception by the receiving device. In some examples, the calculated MIC can be integrated with that calculated for the entire frame, maintaining existing security measures. This mechanism can be efficient as it can be reused multiple times for a given frame without introducing additional state or keys, thus providing additional security without burdening additional computing resources.

[0049] The lack of protection for certain fields within the MAC header, such as Power Management (PM) bits and sequence numbers, can pose security issues for network traffic. This lack of protection in these MAC header fields can lead to potential unauthorized changes by attackers, affecting device performance and disrupting the aggregation state. Using an alternative key set to address this security flaw may be undesirable as it may require maintaining additional hardware (HW) and software (SW) states to support such keys. Furthermore, the defined mechanisms are used for maintaining and managing the replay state of the MAC header, along with the procedures for defining and deriving these keys and managing their rotation or change, all of which increase complexity beyond the current security measures being implemented.

[0050] The technical solution of the present disclosure aims to extend existing mechanisms for other purposes, resulting in an existing key mechanism for MAC header protection. This approach minimizes the HW state and firmware (FW) state for development to provide protection to the MAC header and utilizes existing replay checks to enable replay detection in the context of MAC header protection. The CCMP and GCMP mechanisms can be used or extended to seamlessly integrate the MIC calculated for MAC header protection. This integration can be done without changing the frame format and eliminates the need for additional space. If encryption of the MAC header protection is desired, the same key can be used, but the frame can carry supplementary encrypted data. To avoid security concerns, the present technical solution utilizes an Initialization Vector (IV) (16 octets) with a separate Packet Number (PN) (6 octets). This overall approach positions the solution to efficiently address newly emerging issues in the 11bn deployment.

[0051] The present technical solution can use different sets of keys. For independent replay checks for MAC header protection, the header protection can utilize additional space / fields within the frame to carry header field information encrypted with the same key. UHR / 11bn can be relevant to Wi-Fi customers and respond to a lower cost and higher level of security.

[0052] These technical solutions can maintain the same frame format without introducing a specific MAC Header Protection (MHP) header. The number of unicast keys can still remain unchanged. Combining the MHP header with tags from body encryption can be used to prevent potential attacks because the lack of combination could lead to mixing the MHP header of one frame with the body of another frame, potentially resulting in the loss of protection of the modified header fields. While the same key, metadata algorithm, and PN with MHP can be provided without alternating for the protocol like in a 4-way handshake, additional replay checks and the corresponding transmission and reception states of the MHP key can be avoided. The Operating Channel Validation (OCV) function can help eliminate man-in-the-middle (MITM) attacks. These solutions bring minor changes to the current protocol and can support both CCMP and GCMP while reducing security vulnerabilities and aligning with block chaining using the same characteristics shared with the same key, CCMP, and GCMP.

[0053] FIG. 2 shows an exemplary system 200 for providing MAC header protection. The system 200 can include a transmitter device 202 that communicates with a receiver device 204 via a communication link 206. The transmitter device 202 can include one or more key generators 208, a Packet Transmission Manager (PTM) 220, a Message Integrity Code (MIC) engine 240, a MIC synthesizer 250, and a coordinator 260. The key 210 can include one or more Temporal Keys (TKs) 212, a body key 214, a header key 216, and a parent key 218. The MIC engine 240 can include, generate, process, or provide one or more frame MICs 242 and header MICs 244 to be transmitted in a frame 230 to enable the receiver device 204 to verify the integrity of the transmission. The PTM 220 can include one or more encryption engines 222 for encrypting the frame 230 using the key 210. Each frame 230 can at least include a body 232 and a header 234 having one or more header parameters 236 (e.g., data bits for encryption and protection). The MIC synthesizer 250 can include or generate one or more synthesized MICs (hereinafter referred to as synthesized MICs) 252 to be used for communicating with the receiver device 204.

[0054] Beyond link 206, the receiver device 204 can include one or more coordinators 260 for establishing and communicating network communication, and one or more PTMs 220 for processing network packets (e.g., frame 230). The receiver device 204 can also include one or more MIC engines 242, and the MIC engine 242 includes or generates one or more predicted frame MICs 272, predicted header MICs 274, and predicted composite MICs 276. The receiver device 204 can inspect and verify the integrity of the frame 230 received by the receiver device 204 by comparing the frame MIC 242 of the incoming frame 230 with the predicted frame MIC 272 generated by the MIC engine 242, by comparing the header MIC 244 of the incoming frame 230 with the predicted header MIC 274 generated by the MIC engine 242, or by comparing the composite MIC 252 of the incoming frame 230 with the predicted composite MIC 276, including one or more Integrity Check Functions (ICFs) 270.

[0055] The transmitter device 202 and the receiver device 204 (collectively referred to as device 202 and device 204) can each include some combination of hardware and software configured for network communication via a wired network or a wireless network. The transmitter device 202 and the receiver device 204 can each be, or include, a function provided by any network device 106 (e.g., a Wi-Fi access point), a client device 102 (e.g., a computer or a smartphone), or a node 192 (e.g., a router or a gateway), or a cloud-based system. The transmitter device 202 and the receiver device 204 can include or utilize the computing system 100, can include and utilize one or more processors (e.g., 121) coupled to a memory (e.g., 122), and can utilize instructions stored in the memory or software 120 for implementing the functions of the transmitter device 202 or the receiver device 204.

[0056] The link 206 can include any physical or logical connection that facilitates data transmission between devices 202 and 204. The link 206 can include a wide range of wired and wireless network technologies or communication technologies, including WLAN, Wi-Fi, cellular networks, and various forms of wired connections. For example, in a Wi-Fi network, the link 206 can include a radio wave signal transmitted between an access point and a client device that facilitates wireless data transmission. For example, the communication link 206 can include a radio frequency signal transmitted between a base station and a mobile device that supports long-distance voice and data communication. For example, the link 206 can be, or include a part of, an Ethernet (registered trademark) or fiber optic connection network that includes a physical cable for transmitting data packets between devices. The communication link functions as a medium through which a frame 230 (e.g., data or a network packet) is transmitted.

[0057] A frame 230 (also referred to as a network packet) can include any discrete unit of data transmitted over a network (e.g., link 206). Each frame 230 can include a body 232 and a header 234, and can encapsulate payload data and control information for routing and processing of the network packet. For example, in a wireless communication system, the frame 230 can include payload data (e.g., text data, video data, sensor measurement data, or any other data to be transmitted) in the body 232 portion, while the header 234 portion can include information such as a packet sequence number and addressing information. The frame 230 can be a frame of the link layer (e.g., MAC layer), internet layer or network layer, transport layer, session layer, presentation layer, or application layer in the Open Systems Interconnection (OSI) model or TCP / IP model.

[0058] The body 232 of the frame 230 can include any data payload to be transmitted over the network (e.g., via link 206). The body 232 can include various types of application-dependent information such as sensor measurements, audio / video streams, text content of an email or document, or any application-specific data. The body 232 can include payload data regarding a temperature measurement from a sensor, data from an application running on a computing device, a portion of an image or video, or any other information being transmitted. The body 232 can be encrypted using various encryption techniques such as, for example, key 210 including body key 214.

[0059] Header 234 can be any part of a frame 230 (e.g., a network packet) that contains control information for the frame, such as source and destination Internet protocol addresses, protocol information, error detection codes, and other metadata. Header 234 can include parameters 236 of any information or data (e.g., control signals or metadata) for the routing and processing of frame 230. Header 234 can include parameters 236 such as packet sequence numbers, source and destination addresses, and data bits that indicate, represent, or correspond to frame control bits. Header 234 can be a MAC layer header. Header 234 can include information that provides context to the frame and facilitates devices on the network to accurately interpret and process the transmitted data. For example, the header 234 of frame 230 in a Wi-Fi network can include information regarding the type of frame, transmission speed, and frame duration.

[0060] Parameters 236 can include any value or indicator within header 234. Parameters 236 can include specific fields or attributes that are protected to facilitate data integrity during transmission. Parameters 236 can include packet numbers, frame control bits, and other header fields essential for network protocol operation. Protecting parameters 236 from tampering by third parties can prevent unauthorized changes that could jeopardize the integrity of the transmitted data. For example, in a wireless communication system, parameters 236 such as frame sequence numbers and frame types can be protected to maintain the reliability of the communication.

[0061] The key 210 can include any type and form of cryptographic key used to protect communication between the devices 202 and 204. The key 210 can include any cryptographic key used by the system, including a temporary key (TK) 212, a body key 214, a header key 216, and a parent key 218. The TK 212 can be a temporary key implemented in the system's hardware (e.g., a permanent storage device) and can be used by the devices 202 and 204 for various communication sessions. The body key 214 and the header key 216 can be used to encrypt at least a portion of themselves in the entire body 232 and header 234 of the frame 230, as well as for any layer (e.g., the data link layer or the MAC layer). The parent key 218 can function as a root key from which the TK can be derived during the handshake and negotiation between the devices 202 and 204.

[0062] The temporary key (TK) 212 can include any cryptographic key stored, programmed, or embodied in hardware. The TK 212 can be generated or derived from the parent key 218 and can be used to protect data transmission between the devices 202 and 204. For example, in a Wi-Fi network, the TK is generated during the authentication and key establishment process between a client device and an access point to facilitate the confidentiality and integrity of data exchanged between the devices over a time period, such as after a handshake or session.

[0063] The body key 214 can include any cryptographic key used to encrypt the body 232 of the frame 230 for transmission (sending) of the frame (e.g., a network packet). The body key 214 can be derived from the TK 212 that can be stored in a storage device. The body key 214 can be utilized to protect the confidentiality of the payload data contained within the body of the frame. For example, in a wireless communication system, the body key 214 can be used to encrypt a portion of text, image, video, sensor measurements, or other confidential information before transmission over the network.

[0064] The header key 216 can include any encryption key used to encrypt the header of a frame being transmitted. Similar to the body key 214, the header key 216 can be derived from the TK 212 and can be used to facilitate the confidentiality and integrity of the header information (e.g., parameter 236) within the frame 230. For example, in a wireless network, the header key 216 can be used to encrypt control information such as packet sequence numbers and frame control bits, preventing unauthorized access or manipulation of the header data.

[0065] The parent key 218 can include any encryption key that functions as a root key. The temporary key (TK) 212 can be derived from the parent key. The parent key 218 can be established during the initial setup of a secure communication environment and can be used to generate the TK 212 for subsequent communication sessions between two network devices. For example, in a wireless network, the parent key 218 can be distributed during the authentication and key establishment process between devices and provides a secure basis for generating the TK 212 from the parent key 218 used during data transmission.

[0066] The key generator 208 can include any combination of hardware and software for generating the key 210. The key generator 208 can include functions for generating the encryption key 210 used to protect communication between devices. The key generator 208 combines hardware elements and software elements to create the key 210, such as the temporary key (TK) 212, the body key 214, the header key 216, and the parent key 218. For example, in a wireless network, the key generator 208 can utilize an algorithm to derive the TK 212 from the parent key 218 during a handshake or the establishment of a secure connection between devices 202 and 204.

[0067] The key generator 208 can include functions for calculation using a temporary key (TK) 212 programmed in hardware, a body key 214 for the body of the frame 230, and a header key 216 from the header of the frame 230. The header key 216 can be different from the body key 214. The key generator 208 can calculate the body key 214 or the header key 216 using the HMAC (Hash-based Message Authentication Code) operation with the first input of the TK 212 and a specific (e.g., first) fixed pattern. The fixed pattern can include any predetermined series of values (e.g., parameter 236 or characters). The fixed pattern can be used to derive the header key 216 or the body key 214 for the encryption process. The key generator 208 can include functions for calculating another key using the HMAC operation with the second input of the TK 212 and a second fixed pattern. The first fixed pattern can include the packet number (PN) of the header 234 of the network packet of the frame or any other content, and the second fixed pattern can include one or more characters (e.g., content) of the body.

[0068] The key generator 208 can include functions for calculating the body key 214 or the header key 216 using the AES (Advanced Encryption Standard) algorithm. The key generator 208 can include functions for calculating the frame MIC 242 or the header MIC 244 using the Cipher Block Chaining-MAC Protocol (CCMP) and the Galois / Counter Mode Protocol (GCMP) or any other alternative protocol.

[0069] The key generator 208 can include functionality for processing a retransmitted frame 230 (hereinafter referred to as a retransmission frame) that protects the header 234. When the frame 230 is retransmitted, the key generator 208 can calculate a body key 214 for the second body 232 of the second frame 230 of the retransmitted second network packet using TK212. The key generator 208 can calculate a header key 216 for the second header 234 of the second frame 230. The first header key 216 of the header 234 of the previous frame 230 can be different from the new or second header key 216 of the header 234 of the retransmitted frame 230.

[0070] Since each frame 230 can have a different packet number, the key generator 208 can utilize the packet number from the sequence to create a header key 216 that is unique to each frame 230 in the frame sequence. The body key 214 for the second body 232 of the second frame 230 of the second network packet can be the same as the body key 214 of the body 232 of a previous (e.g., previously transmitted) frame 230. Since the key generator 208 can utilize the content of the retransmission frame 230 that may be identical to a previously transmitted frame (hereinafter referred to as a transmission frame) 230, the body key 214 can be the same, but the header key 216 (e.g., based on a different packet number or other identifier of the packet) can be different for each retransmission frame 230.

[0071] The key generator 218 can include a function for determining a pairwise master key (PMK) 218 during negotiation or handshake between devices. For example, the key generator 208 can include a function for determining the PMK 218 during the interaction via the wireless network between devices 202 and 204. For example, the PMK 218 can be determined based on the data, content or control signals exchanged between devices 202 and 204 during the sequence. The key generator 218 can use the PMK 218 to generate the TK212. The TK212 can be stored in hardware such as a storage device (e.g., 128), and the key generator 208 can read the TK212 from the hardware for use in generating the body key 214 and the header key 216 based on the content of the body 232 and the header 234.

[0072] The packet transmission manager (PTM) 220 can include any combination of hardware and software for managing or controlling packet transmission. The PTM 220 can include one or more components or circuits for managing and implementing the transmission and reception of network packets (e.g., frame 230) between the transmitter device 202 and the receiver device 204. The PTM 220 can include functions for facilitating reliable and efficient transmission of data over the network. For example, in a wireless communication system, the PTM can utilize the encryption engine 222 to associate the encryption and transmission of the frame 230 between the transmitter device and the receiver device to protect the data during transmission.

[0073] PTM220 can include a function for transmitting a frame having a first MIC (e.g., frame MIC 242) and a second MIC (e.g., header MIC 244) to the receiver device 204. The receiver device 204 can be configured to determine the integrity of the header 234 of the frame based on at least the second MIC (e.g., header MIC 244), for example, by using the integrity check function 270 of the receiver device 204. PTM220 can be configured to transmit a combined MIC (hereinafter referred to as a combined MIC) 252 to the receiver device 204 to determine the integrity of the frame 230.

[0074] When transmitting a series of frames 230, PTM220 can retransmit a frame 230 that was not successfully transmitted in a previous attempt. In such a case, the frame 230 can include a parameter 236 of the packet number (PN) of the frame 230 that uniquely identifies the frame 230 from other frames 230 in the series and includes the same frame 230 that was previously transmitted in the series. When it is determined that the first network packet has not been received, PTM220 can decide to retransmit the first network packet as a second network packet, and the second network packet has a parameter 236 that uses a second packet number (different from the first PN of the previous frame 230) in the second header 234 of the second frame of the second network packet. Therefore, the second packet number (e.g., parameter 236) of the retransmitted frame 230 can be different from the first packet number (e.g., parameter 236) of the original transmitted frame 230 even if the payloads of the two frames 230 are the same. Since each of these two frames 230 can have their headers 234 with different PN parameters 236, the header MICs 244 of these two frames 230 are different, whereby the ICF 270 of the receiver 204 can detect any tampered frame 230 because their expected header MIC 274 does not match the header MIC 244 received in the incoming frame 230.

[0075] For example, PTM220 can utilize the encryption engine 222 to encrypt each header 234 of the frame 230 transmitted using the header key 216. PTM220 can utilize the encryption engine 222 to encode a unique PN (e.g., parameter 236) of the frame 230 with respect to the header 234 of each frame 230. PTM220 can utilize the MIC engine 240, and the MIC engine 240 can generate the header MIC 244 of the header 234 with respect to the encryption of the header 234. For example, PTM220 can transmit the header MIC 244 to the receiver device 204 together with the frame 230. In some cases, the header MIC 244 may be included in the header 234 of the transmitted frame 230. When receiving the frame 230, the ICF 270 can utilize the MIC engine 242 of the receiver device 204 to generate an expected frame (referred to as the expected frame) MIC 272, an expected header (referred to as the expected header) MIC 274, or an expected composite (referred to as the expected composite) MIC 276. If an attacker intercepts and tampers with the parameter 236 of the header 234 of the incoming frame 230, the header MIC 244 will not match the expected header MIC 274, and the ICF 270 will determine that the integrity of the incoming frame 230 has failed based on the failure of the match. In response to such a determination, the ICF 270 can send a message to the transmitter device 202 to notify the transmitter device 202 to retransmit the frame 230 again.

[0076] The encryption engine 222 can include any combination of hardware and software for performing encryption and decryption operations on data transmitted via a network. The encryption engine 222 can facilitate the confidentiality and integrity of the transmitted data by utilizing an encryption algorithm such as AES (Advanced Encryption Standard). For example, in a wireless communication system, the encryption engine is utilized to encrypt the frame body and header using a key 210 that can be derived from a temporary (TK) key 212, protecting the data from unauthorized access or eavesdropping. The encryption engine 222 can encrypt the frame body 232 of a frame in the MAC layer using the body key 214 and encrypt the frame header 234 in the MAC layer using the header key 216. Encrypting the frame body 232 of the frame 230 in the MAC layer using the body key 214 can be performed simultaneously with encrypting the frame header 234 in the MAC layer using the header key 216.

[0077] The encryption engine 222 can include a function for identifying one or more frames 230 in the MAC layer to be encrypted for wireless communication and encrypting a second frame 230 (e.g., a retransmission frame) of a second network packet in the MAC layer using the body key 214 of a second body 232 and the header key 216 of a second header 234 (e.g., of the second frame 230). For example, the retransmission frame 230 can have its header key 216 and its header MIC 244 recalculated to account for any changes in header parameters 236 such as packet number parameters or any other parameters within the header 234 that may be changed.

[0078] The Message Integrity Code (MIC) engine 240 can include any combination of hardware and software for calculating or generating a Message Integrity Code (MIC) for any part of the frame 230. The MIC engine 240 can include functionality for generating any encryption code used to verify the integrity of the transmitted frame. The MIC engine 240 can calculate the MIC of any frame 230 or header 234 (e.g., frame MIC 242, header MIC 244, predicted frame MIC 272, or predicted header MIC 274). The MIC engine 240 can generate the frame MIC 242 and the header MIC 244 that can be attached to the transmitted data to detect unauthorized changes or tampering during transmission between the transmitter device 202 and the receiver device 204. The MIC engine 240 can calculate the MIC (e.g., 242, 244, 252, or 272, 274, 276) for a frame encrypted using a hash-based algorithm (referred to as an encrypted frame). For example, the MIC engine 240 can calculate the frame MIC 242 of the encrypted frame 230 using the body key 214 and calculate the header MIC 244 of the frame in the MAC layer using the header key 216. The MIC engine 240 can generate any MIC (e.g., 242, 244, 252, 272, 274, or 276) that can include an encrypted checksum generated for a part of the frame (e.g., a part of the body 232 or the header 234) or a part of the entire frame 230.

[0079] Frame MIC242 can include any encryption code calculated by MIC engine 240 for verifying the integrity of frame 230 transmitted from transmitter 202 to receiver 204. Frame MIC242 can be transmitted in frame 230 or attached to the encrypted frame data. Frame MIC242 can be used by the receiver to compare with an expected frame MIC272 that can be separately calculated to detect whether the received frame contains any unauthorized changes or tampering. For example, in a wireless communication system, frame MIC242 can be calculated using a hash-based algorithm applied to the encrypted frame, providing a means for the receiver to inspect the integrity of the received data.

[0080] Header MIC244 can include any encryption code calculated by MIC engine 240 for verifying the integrity of header 234 of frame 230 transmitted from transmitter 202 to receiver 204. Header MIC244 can include an encryption code calculated by MIC engine 240 for verifying the integrity of the header information within frame 230 during transmission. Header MIC244 can be attached to the encrypted header data and can be used by receiver device 204 to detect any unauthorized changes or tampering of the header. This enables the MIC engine 240 of receiver device 204 to compare with an expected header MIC274 that can be generated for comparison with the received header MIC244 in incoming frame 230. For example, in a wireless network, header MIC244 can be calculated using a hash-based algorithm attached to the encrypted header, enabling the receiver to verify the integrity of the header data.

[0081] The predicted frame MIC272 can include any encryption code calculated by the MIC engine 240 of the receiver device 204 that is to be used as a reference value for comparing and verifying the integrity of the received frame 230. The predicted frame MIC272 can be generated or calculated based on the content of the received frame, including, for example, both the body 232 and the header 234 of the frame 230. The predicted frame MIC272 can be calculated using a predetermined algorithm and TK212 that can be previously shared with the receiver device 204. The predicted frame MIC272 can be calculated using TK212 generated from the session key 218 that can be exchanged between these two devices during the handshake or negotiation sequence between the devices 202 and 204. For example, upon receipt of the frame 230, the receiver device 204 can recalculate the frame MIC242 using the same algorithm and compare it to the predicted frame MIC272. If the calculated frame MIC matches the predicted frame MIC, the ICF270 can indicate that it has determined that the content of the frame was not tampered with during transmission. This comparison mechanism can be used to inspect the integrity of the entire frame and provide assurance against unauthorized changes.

[0082] The predicted header MIC274, which is also generated by the MIC engine 240 of the receiver device 204, can include any encryption code that will be used as a reference value for comparing and verifying the integrity of the received header 234. The predicted header MIC274 can be generated by the MIC engine 240 as an independent derivation of the header 234 by the receiver device 204 for comparison with the header MIC244 of the received frame 230. Similar to the predicted frame MIC272, the predicted header MIC274 can be calculated using a predetermined algorithm based on the content of the header 234. When the frame 230 is received, the receiver device 204 can extract the header MIC244 transmitted in the frame 230 and compare the header MIC244 with the predicted header MIC274 that can be generated from the data of the received header 234. If the received header MIC244 matches the predicted header MIC274, the ICF270 can determine and indicate that the content of the header 234 has not been tampered with during transmission, and the frame 230 can be authenticated or confirmed as safe to process.

[0083] The MIC synthesizer 250 can include any combination of hardware and software for integrating the individual frame MICs 242 and header MICs 244 of the frame 230 to form a synthesized MIC 252 that includes a header 234 and a body 232. The synthesized MIC 252 can include any encryption code formed by integrating the MICs of the individual frames and headers using the MIC synthesizer 250. The MIC synthesizer 250 can combine hardware elements and software elements to perform operations (actions) for synthesizing two or more MICs (e.g., 242 and 244). The operations that the MIC synthesizer 250 can utilize to generate the synthesized MIC 252 can include any reversible operation, such as an XOR operation in which the frame MIC 242 and the header MIC 244 are synthesized by a bitwise exclusive OR operation, in which each bit of the output is the result of applying the XOR operation to two operands of the two MICs. The operations can include any reversible operation in which each bit of the output is the result of applying the operation to the input operands of the two MICs. The operations can include the concatenation of the frame MIC 242 and the header MIC 244 into a single character string. For example, in a wireless communication system, the MIC synthesizer 250 can apply an XOR operation to the frame MIC 242 and the header MIC 244 to form a synthesized MIC 252 that can be transmitted to a receiver for integrity verification. For example, the synthesized MIC can be generated using one or more of the following, or any combination thereof, i.e., the concatenation of a first MIC and a second MIC, a bitwise exclusive OR (XOR) calculation applied to the first MIC and the second MIC, or a bitwise logical AND calculation applied to the first MIC and the second MIC.

[0084] The predicted synthesized MIC 276, which is also generated by the MIC engine 240 of the receiver device 204, can include any encryption code that will be used as a reference value for comparing and verifying the integrity of the received synthesized MIC 252. The predicted synthesized MIC 276 can be generated by the MIC engine 240 as the derivation of the predicted frame MIC 272 and the predicted header MIC 274. The predicted synthesized MIC 276 can be synthesized from the predicted frame MIC 272 and the predicted header MIC 274 using the same or similar operations (e.g., bitwise exclusive OR (XOR) operation or bitwise logical AND (AND) operation of two MICs, or concatenation) as those used to create the synthesized MIC 252, using the MIC synthesizer 250 (e.g., disposed in the receiver device 204). For example, upon receiving the frame 230, the receiver device 204 can extract the synthesized MIC 252 and compare it with the predicted synthesized MIC 276 separately derived at the receiver device 204 (e.g., using the MICs 272 and 274). If the received synthesized MIC 252 matches the predicted synthesized MIC 276, the ICF 270 can determine and indicate that the frame 230 is authenticated or confirmed to be safe for use and processing.

[0085] The coordinator 260 can include any combination of hardware and software for establishing, configuring, and managing communication between devices in a network. The coordinator 260 can combine hardware elements and software elements to ensure the proper functioning of the network by correlating data exchanges. For example, in a wireless communication system, the coordinator 260 can facilitate the establishment of secure connections between devices, manage network resources, and resolve communication conflicts to maintain smooth operation.

[0086] The Integrity Check Function (ICF) 270 can include any hardware and software for checking and verifying the integrity of incoming frames using the MIC of the transmitter device 202 and the expected MIC of the receiver device 204. For example, the ICF 270 can include a function for extracting either the MIC of the incoming frame (e.g., 242, 244, or 252) from the frame 230 and comparing such MIC with the expected frame MIC 272 or the expected header MIC 274 of the receiver device 204. In response to the determination that the MIC of the transmitter device 202 (e.g., 242, 244, or 252) matches the MIC of the receiver device 204 (e.g., 272, 274, or 276), the ICF 270 can determine that the incoming frame 230 has not been tampered with. For example, in a wireless network, the ICF compares the received combined MIC with the calculated MIC of the frame or header and verifies the integrity of the transmitted data before further processing. For example, the receiver device 204 can be configured to determine the integrity of the header 234 based on verification of the integrity of the header 234 using the header MIC 244 before decrypting the frame. The receiver device 204 can be configured to verify the integrity of the header 234 of the frame using the header MIC 244 before processing the body of the frame.

[0087] FIG. 3 shows an exemplary flowchart of a method 300 for providing encryption for MAC header protection according to the present technical solution. The method 300 can be implemented, for example, using at least the functions described in connection with FIGS. 1A-2, and can include processes or operations (actions) 302-320 that represent actions taken or performed by an exemplary system (e.g., 200) during the course of an encryption process.

[0088] In one example, method 300 can start by initializing with a specific value and defining blocks based on the length of the Initialization Vector (IV). This can be followed by data encryption using AES-ECB with a given key, and the output is processed through a hash function. The resulting hash value can be utilized in a GHASH operation along with additional header data and ciphertext to provide an output. Also, block J can be constructed based on the IV and other parameters, and the ciphertext can be encrypted using AES-CTR. A frame MIC can be generated, and the synthesis operation can be executed to obtain a final synthesized MIC that may include the components of the frame for integrity verification. Finally, an additional MIC shown as MHP MIC (T2) can be generated.

[0089] In 302, the method can include input processing according to 0^128 (standard). JPEG2025084084000002.jpg7165 The method can include processing input data, such as generating an Initialization Vector (IV) that can include one or more unique values for initializing an encryption mechanism, such as AES in counter mode. The IV can then be combined with other data to generate an output.

[0090] In 304, the method can include AES ECB (Electronic Codebook) mode encryption. This block performs AES encryption in ECB (Electronic Codebook) mode using the key (K). The ECB mode encrypts each data block independently, making it suitable for parallel processing.

[0091] In 304, the method can include the AES-ECB encryption algorithm along with the key (K). AES-ECB can include block cipher modes of operation that encrypt each individual block of the plaintext separately in order to provide security by introducing a certain level of randomness into the encryption. The input data can be encrypted using the AES algorithm to create the ciphertext.

[0092] In 306, the method can apply a hash function to the data output in operation 302. The hash function can be a hash-subkey function that can process the data provided in operation 304 to generate a hash value. This hash function can generate a unique fixed-size hash value for input data of any size. The output can be provided to operation 310.

[0093] In 308, the method can utilize header-data processing, including the manipulation or analysis of header information within the communication frame. The header data can include parameters and metadata, including any control information for routing and processing the data payload. The output can be provided to operation 310.

[0094] In 310, the method can utilize an encryption function, such as the GHASH function. The GHASH function can be based on the Galois / Counter Mode (GCM) encryption algorithm and can be used for the encryption authentication and integrity verification of data. This encryption function can calculate a Message Authentication Code (MAC) using Galois field multiplication and provide its output to operation 314.

[0095] At 312, the method can generate a counter (CTR) value that can be used for AES encryption in counter-mode operation. The CTR value can be derived from an initialization vector (IV) and a packet number (PN) that can be used to generate the key used for encryption. The output can be provided to operation 314.

[0096] At 314, the method can perform AES-CTR encryption that utilizes counter (CTR) mode operation with the AES algorithm. AES-CTR can encrypt the plaintext by taking the exclusive OR with a key (e.g., a key stream) generated from the CTR value. This resulting output of the combined or exclusive-ORed data generates a ciphertext along with an encoded counter value, providing an additional level of integrity. For example, if a packet number (PN) parameter from the header of a frame in a series of frames is utilized, the output is unique to the transmission instance, and as a result, a retransmitted frame can be detected at the receiving device if it has been tampered with by an adversary.

[0097] At 316, the method can calculate a Frame Message Integrity Code (MIC) that can include an encrypted checksum generated for all frames to verify the integrity of all frames during transmission. The Frame MIC can facilitate verification that the transmitted frame has not been maliciously altered or corrupted during transmission.

[0098] At 318, the method can synthesize the Frame MIC from operation 316 with the data output from operation 314 using a specific synthesis function (e.g., AES-CTR encryption). The synthesis function can include operations such as exclusive logical sum (exclusive OR) or concatenation to merge the Frame MIC with the data output from operation 314. The resulting output can be a synthesized MIC for the frame or can include the synthesized MIC, which can function as a comprehensive integrity verification measure for the transmission frame to be verified for frame integrity at the receiver device.

[0099] At 320, the method can include the generation of another MHP MIC (Message Integrity Code) that functions as an encrypted checksum for the MHP protocol. This MIC can be used to verify the integrity and authenticity of data transmitted using the MHP protocol.

[0100] Now, referring to FIG. 4, an exemplary block diagram of a method 400 for implementing Galois Counter Mode (GCM) encryption to generate a MIC according to the present technical solution is shown. The method 400 can be implemented using, for example, at least the functions described in relation to FIGS. 1A - 2, and can include processes or operations (actions) 402 - 426 that represent actions taken or performed by an exemplary system (e.g., 200) during encryption.

[0101] For example, in method 400, a system or configuration for GCMP MIP determination in the Wi-Fi standard can include a Pairwise Transient Key (PTK) or a Group Temporal Key (GTK) for the UHRMAC header MIC. In GCM, since the GHASH subkey can include the AES-encrypted text of plaintext 0 even if the text is known and even if an attacker knows the subkey, it can still be difficult to obtain the key (K) and corrupt the data. Similarly, patterns such as "5555" or "ffff" can be used as AES inputs, and their ciphertexts can be used as keys for header MIC calculation. In the case of 256-bit GCMP, the solution may include two patterns.

[0102] At 402, the method identifies a key as an input. The key (e.g., TK) can function as an encryption key for the method. The key can be input to or used by the functions of a plurality of blocks or block 404, and "AES(K)" performs AES encryption using the provided key. At 408, "AES(K)" processes the output of operation 406, which can provide a bit output of "0" using the AES encryption function. The output of operation 408 can be input to a specified operation 410 that can generate a sub-key. The sub-key can be utilized by an operation 412 that can perform a GHASH operation, and operation 412 receives an additional input from an operation 420 (e.g., AAD + Cipher Text) that can synthesize additional authenticated data with the ciphertext. At 414, the AES(K) operation can receive inputs from operation 402 (e.g., the key) and operation 422. Operation 422 can provide an IV that can include blocks 424 (e.g., A2(6)) and 426 (e.g., the packet number parameter of the header) used to generate an initialization vector (IV). The output of operation 414 can be supplied to an operation 416 that synthesizes signals from operations 412 and 414. At 418, the synthesized output from operation 416 is provided, which represents the generation of the MIC.

[0103] Now, referring to FIG. 5, another exemplary block diagram of a method 500 for implementing Galois Counter Mode (GCM) encryption for generating a MIC in accordance with the present technical solution is shown. The method 500 can be implemented using, for example, at least the functions described in connection with FIGS. 1A - 2, and can include processes or operations (calculations) 502 - 528 that indicate actions taken or performed by an exemplary system (e.g., 200) during encryption.

[0104] Method 500 can correspond to a diagram of the operation (computation) by system 200 that uses a configuration for key generation and GCMP for header MIC. In one aspect, the illustrated example can provide key generation and GCMP for header MIC where the same GCMP is still used and key generation can be utilized. For 256 bits, two patterns can be defined with respect to the upper and lower 128 bits of key K'. For example, if the frame does not contain a payload, it can have a MIC outside the MAC header (existing PTK / GTK can be used), and a frame with a payload can be protected using existing mechanisms. In such an example, there may not be two levels of authentication information verification for a single frame (e.g., one MIC verification for the header and another verification for decrypting the payload).

[0105] At 502, an input stream for the AES function can be identified. The input stream can include a predetermined fixed pattern. The output from 502 can be used as the input to 504, which can include the AES(K) function. The output from 504 can be the input to 506, which can correspond to the K' output of the AES encryption algorithm. The output from 506 (e.g., K') can be used as the input to 510 and 524. Function 510 can include the AES encryption of K' along with another input from 508 that can include the value "0" (e.g., padding).

[0106] The output from 510 can be provided as the input to 512, and 512 can correspond to a SubKey. The output from the SubKey can be provided as the first input to the GHASH function at 516. The second input to 516 can be provided from 514, where additional authentication data (AAD) is identified. The output from GHASH can be provided as the first of two inputs to 526, and 526 can include a signal combiner for combining two signals. The second input to the 526 combiner function can come from the AES(K') operation at 525. 525 can receive the IV from 522 as its input. At 522, two blocks can be included to provide the IV. The first block is operation 518 with A2(6), and the second block is operation 520 with the packet number (PN(6))), and they can be used to generate the IV. The second input to 524 that results in the AES(K') function can be the input from 506 (e.g., K'). The output from 526 can be the MIC provided in operation 528 using the output from 526.

[0107] Now, referring to FIG. 6, an example 600 of an array of the header 234 of the frame 230 is shown. In example 600, the IV - Body can indicate whether MAC Header Protection (MHP) is applied. In an example where MHP is applicable, the IV - Body can represent whether it necessarily involves an integrated IV and ICV or a separate Header IV and Header ICV configuration.

[0108] Header 234 can be represented as a table of bytes, in which case each field or slot of the table corresponds to a specific set of bytes or bits within header 234. Header 234 can include a plurality of parameters 236 arranged in various slots of header 234. The parameters 236 can include packet numbers (PN) such as PN0, PN1, a shorter version of the PN (e.g., Short-PN-Header), and IV data such as extended initialization vector plus (EXT IV+) data. The parameters 236 of header 234 can include slots arranged in a series of packet numbers to track packet numbering within a communication stream.

[0109] The "EXT IV+" slot is expanded to show the bit-level information of EXT IV+. The bits of EXT IV+ can correspond to bits reserved for various functions such as RSVD[B0], MHP, RSVD[B2], Integrated ICV, FTM, EXT IV, and Key ID. In some examples, these bits can represent different attributes or flags associated with an extended initialization vector (IV). For example, the "MHP" bit can indicate whether header 234 has the ability of the MHP function. In such a configuration, an MHP of 0 may indicate that MHP is not applicable to this frame 230, while an MHP of 1 may indicate that MHP can be utilized. For example, the Integrated ICV bit can specify whether header 234 includes an integrated Integrity Check Value (ICV) that can be used to verify the integrity of the header data. For example, the Key ID bit can be implemented to indicate a specific encryption key 210 that can be used for the frame or the body of the frame.

[0110] Now, referring to FIG. 7, an exemplary method 700 for providing MAC address protection is shown. Method 700 can be a method for providing protection for the Machine Access Control (MAC) header of a frame. Method 700 can be implemented using, for example, systems 100 and 200, along with any of the features described in relation to FIGS. 1A - 6. Method 700 can include operations (actions) 705 - 720. At 705, the method can include identifying a temporary key. At 710, the method can include calculating a first key for the frame body and a second key for the frame header. At 715, the method can include encrypting the body using the first key and encrypting the header using the second key. At 720, the method can include calculating a first Message Integrity Check (MIC) for the frame and a second MIC for the header using the first and second keys.

[0111] At 705, the method can include identifying a temporary key. The method can include one or more processors of a transmitter device that identify (specify) a temporary key (TK) programmed in hardware. The TK can be stored, for example, in a storage device (e.g., non - volatile memory), or programmed in a special hardware module. The TK can be generated during initialization of the transmitter device, or during negotiation or handshake between the transmitter device and the receiver device. The TK can be generated based on a parent key negotiated between those devices during the start or establishment of a connection or session between the transmitter device and the receiver device.

[0112] The transmitter device can identify or use the TK to encrypt the frame in the Machine Access Control (MAC) layer for wireless communication. For example, one or more processors of the transmitter device can use the TK as an input to one or more cryptographic functions or algorithms, such as AES, to generate one or more keys for encrypting one or more parts of the frame (e.g., network packets). For example, the TK can be used to generate a body key for encrypting the body of the frame and a header key for encrypting the header of the frame. The header key and the body key can be customized or configured to protect (cover) the body and the header in any layer, including the MAC layer of a frame such as a data link or a frame of a WLAN or Wi-Fi network.

[0113] In 710, the method can include calculating a first key for the frame body and a second key for the frame header. The method can include one or more processors of the transmitter device that use the TK to calculate a first key (e.g., body key) for encrypting the body of the frame and a second key (e.g., header key) for encrypting the header of the frame. In some embodiments, the first key and the second key can be the same. In some embodiments, the second key can be different from the first key.

[0114] The method can include one or more processors that calculate a first key using a HMAC (Hash-based Message Authentication Code) operation. The HMAC operation can include a first input of the TK and a first fixed pattern. The method can include calculating the first key using either a HMAC (Hash-based Message Authentication Code) operation or an AES encryption operation using the first input of the TK and the first fixed pattern. The first pattern can include a character string. The character string can be a predetermined character string shared between the transmitter device and the receiver device. The method can include one or more processors that calculate a second key using a HMAC operation with a second input of the TK and a second fixed pattern. The second fixed pattern can include a character string that can be shared between the transmitter device and the receiver device. The first fixed pattern can include a packet number (PN) of a network packet of the frame, and the second fixed pattern can include one or more characters of the body.

[0115] One or more processors can include calculating a first key for the body using an AES (Advanced Encryption Standard) operation. The AES operation can include a first input of the TK and a first fixed pattern. The method can include one or more processors that calculate a second key for the header of the frame. The second key for the header of the frame can be calculated using the same AES operation with a second input of the TK and a second fixed pattern. One or more processors can calculate the second key for the header using an AES operation with the first input of the TK and the first fixed pattern and using the TK as the first key for the body of the frame.

[0116] At 715, the method can include encrypting the body using a first key and encrypting the header using a second key. The method can include one or more processors in the MAC layer that identify one or more frames to be encrypted for wireless communication. For example, a transmitter device can identify frames that were not successfully received by a receiver device. In response to a determination that a frame was not received at the receiver device, the transmitter device can identify frames for retransmission to the receiver.

[0117] The method can include one or more processors of a transmitter device that encrypt the body of one or more frames in the MAC layer using a first key (e.g., a body key). The method can include one or more processors of a transmitter device that encrypt the header of one or more frames in the MAC layer using a second key (e.g., a header key). The method can include encrypting one or more values in one or more fields of the header that include a packet number that identifies the frame of the header within a series of frames transmitted from the transmitter device to the receiver device.

[0118] The method can include generating an initialization vector (IV) for encryption. The IV can be generated using one or more parameters of the frame. The one or more parameters can include the packet number of the frame. The IV can be generated using a concatenation of the packet number (PN) with additional parameters such as a fixed pattern. This can result in a unique initialization vector for each frame and enable detection of frames in which the header has been intercepted and tampered with by a third party (e.g., an attacker or hacker). The IV can be derived from the header data itself. The IV can incorporate specific fields such as the packet number and other header parameters to facilitate uniqueness and cryptographic strength in the initialization process. The method can use the IV to encrypt the body of the frame. The method can use the IV to encrypt the header of the frame.

[0119] At 720, the method can include calculating a first MIC for a frame and a second MIC for a header using first and second keys. The method can include one or more processors of a transmitter device that calculate, obtain, or generate a first Message Integrity Code (MIC) of an encrypted frame. The first MIC of the frame can be calculated, obtained, or generated using a first key (e.g., a body key). The method can include one or more processors that calculate, obtain, or generate a second MIC of the contents of the header of the frame in the MAC layer using a second key.

[0120] The method can include one or more processors that transmit a frame comprising a first MIC (e.g., the MIC of the frame) and a second MIC (e.g., the MIC of the header) to a receiver. The method can include one or more processors that transmit the first MIC (e.g., the MIC of the frame) and the second MIC (e.g., the MIC of the header) via a transceiver of the transmitter device (e.g., a communication chain circuit comprising an antenna configured for wireless transmission). The frame and the receiver are configured to determine the integrity of the header of the frame based at least on the second MIC (e.g., the MIC of the header). For example, the receiver device can include an integrity checking function and a MIC engine that can generate an expected header MIC. The integrity checking function of the receiver device can compare the expected header MIC with the MIC of the header received in the frame. If the MIC of the header matches the expected header MIC, the integrity checking function can determine that the incoming frame has not been tampered with and may decrypt and process the frame and its payload (e.g., the body).

[0121] The method can include one or more processors that generate a combined MIC from a first MIC (e.g., a MIC of a frame) and a second MIC (e.g., a MIC of a header). The frame can correspond to a beacon transmission. The combined MIC can include the first MIC, and the second MIC can include a timestamp. For example, the second MIC can be a timestamp. The combined MIC can be based on or include at least a portion of the first MIC and at least a portion of the second MIC. The method can include one or more processors that transmit the combined MIC to a receiver to determine the integrity of the frame. The combined MIC can be generated using any reversible operation. For example, the combined MIC can be generated using any one or more of a concatenation of the first MIC and the second MIC, a bitwise exclusive OR (XOR) calculation applied to the first MIC and the second MIC, or some bitwise reversible calculation applied to the first MIC and the second MIC.

[0122] For example, the method can include a transmitter device that calculates the first MIC once, such as once for a given body of data or a beacon. The method can include a transmitter that calculates the second MIC for each retransmission or beacon transmission. The second MIC can be combined with the first MIC for each transmission or retransmission or beacon transmission such that the first MIC is not updated for a transmission or beacon transmission, but the second MIC and / or the combined MIC are updated for each retransmission.

[0123] The method can include a receiver that determines the integrity of the header and the body by calculating a first predicted MIC using a second predicted MIC and then verifying that the first predicted MIC (of the body) is correct. For example, the second predicted MIC can be independently calculated at the receiver using the same process or a similar process as that by which the second MIC is generated at the transmitter. The receiver can compare the second predicted MIC with the second MIC received in the frame. For example, the transmitter can include a combined MIC with the transmitted frame, where the combined MIC includes a combination of the first MIC and the second MIC in the same space or portion of the frame. The receiver can be configured to verify the integrity of the incoming frame by calculating a first predicted MIC using the second predicted MIC and then verifying that the first predicted MIC (of the body) is correct. The header MIC can be considered correct, and the body MIC can be used to verify the header MIC and, depending on the determination that the body MIC is correct, to determine that the header MIC is correct.

[0124] The method can include using a first fixed pattern that includes at least a portion of the content of the body. The second fixed pattern can include one or more packet numbers (PNs) used for the body of the frame's network packets. The PNs of the body used for the fixed pattern can be used for all retransmissions of the frame. For example, the first fixed pattern or the second fixed pattern can include a frame type, such as information indicating a control frame that may have different keys from management frames and data frames. The second fixed pattern can include one or more link addresses, such as a link address related to a multilink operation that the link can use to transmit the frame. The PN can include one or more bytes. For example, a 1-byte PN can be used with the first key or the second key. For example, the second key can be derived based on a PN for the body that can be longer than 1 byte and still remain unchanged for multiple retransmissions (e.g., pre-existing). The frame can correspond to a first network packet of a plurality of network packets. The first network packet can include a first packet number in the header of the frame. The method can include one or more processors that determine to retransmit the first network packet when a second network packet has a second packet number in a second header of a second frame of the second network packet. The second packet number can be different from the first packet number. The second network packet can uniquely identify a network packet to be transmitted from a transmitter device from any other network packet in a series of network packets being transmitted over a time period.

[0125] One or more processors can include calculating, using TK, a first key for a second body of a second frame of a second network packet and a second key for a second header of the second frame. The first key of the first network packet can be different from the first key of the second network packet. The first key for the second body of the second frame of the second network packet can be the same as the first key for the body of the frame of the first network packet. The method can include one or more processors that identify one or more frames in the MAC layer to be encrypted for wireless communication. The method can include one or more processors that encrypt a frame of a second network packet in the MAC layer using the first key for the second body and the second key for the second header.

[0126] In one example, during network communication exchanges, when a transmission retry occurs (e.g., a second attempt to send data after an initial unsuccessful attempt), some MAC header fields may be altered by a threat actor without system authentication. In some cases, the altered fields may be masked with Additional Authentication Data (AAD). This vulnerability can facilitate malicious attacks by unauthorized actors, such as when a hacker skillfully utilizes fragmented frames. For example, some of the affected fields can include the Power Save Bit, More Bit, and SPP / Aggregation. Both CCMP and GCMP can calculate the MIC based on chaining, such as by using Cipher Block Hashing (CBC MIC in CCMP) or GHASH for the last cipher block. It can be beneficial to calculate the MIC based on the originally calculated packet MIC and provide authentication for the altered fields, as such a solution can be easily calculated within the SIFS (Short Interframe Space) and maintain the same or a similar format that is consistent with the conventional format.

[0127] Aspects of the technical solution are directed to extending existing security mechanisms to reuse encryption keys for MAC header protection. The technical solution minimizes the creation of additional hardware and firmware for MAC header protection. Current CCMP and GCMP mechanisms can be used or extended to integrate the MIC for MAC header protection without changing the frame format. This can reduce space or architecture. If encryption is desired, the same key can be used with the frame carrying the additional encrypted data. The technical solution can enable different IVs to be generated using PN. This can facilitate addressing the challenges of WLAN standards, such as 11bn deployments. Different sets of keys can be used for Wi-Fi communication to provide a balance between higher security and lower cost, utilizing space / fields in the encrypted header field information.

[0128] The technical solution can utilize CCMP and GCMP functions that can be used in the same way as conventional configurations or infrastructure. For example, the system can be configured not to include encryption of the frame body 232 when retransmitting network packets (e.g., frame 230). The technical solution can include a key K214 for MHP (MAC header protection). The key K210 can be derived from the original key K (e.g., TK212) used for transmission. For example, the key K is JPEG2025084084000003.jpg11165

[0129] For example, in the GCMP configuration of the solution, if encryption is not used, K is the same K origIt can be. H can be the seed hash of GHASH H = E(K, P1), where P1 is a fixed pattern. The technical solution can transmit the MIC original CCMP / GCMP T that can be exclusive-ORed (e.g., processed by exclusive OR) with the MHP T (e.g., header MIC 244) calculated over the header 234 as the MIC for transmission. This technical solution can use the same PN as in the embodiment of the conventional system and can perform a replay check.

[0130] In some examples, if a transmission retry (e.g., retransmission) is to be encrypted or tested for the MIC before the entire frame 230, the solution can transmit the MHP IV along with the retry number (small PN), and can also transmit the encryption block along with the small PN, or at the time of decryption, it can be determined that the retry is unique using the small PN. In some examples, this technical solution can calculate the MHP T (e.g., header MIC 244) and take the exclusive-OR of the MHP T with the received information (e.g., the previously transmitted common key 210). The result can be the original T, thereby making it possible to determine the integrity of the transmission by comparison. This technical solution can use the original CCMP / GCMP decryption, and the replay check can verify whether the MHP has been replayed.

[0131] At a high level, the key derivation process can be extended to derive K-MHP (K MAC header protection), while in some embodiments, only K-Body can be utilized. Encryption and integrity protection can be achieved via an Authenticated Encryption with Associated Data (AEAD) scheme and can remain consistent with respect to the body along with the IV-Body, C-Body, and T-Orig components. In some examples, header encryption can be performed and header integrity can be protected. This can include, for example, an IV-Header element, a C-Header element, and a T-Header element. A transmitted or received frame after protection (a Frame Check Sequence (FCS) is not shown) can include the following structure. That is JPEG2025084084000004.jpg24165

[0132] In the key derivation process, the key derivation process can include the concatenation of several components, including a Key Confirmation Key (KCK), a Key Encryption Key (KEK), a Temporal Key (TK), and a Key Derivation Key (KDK). Such concatenation can be performed using the HMAC-KDF-NNN (Hash-based Message Authentication Code using Key Derivation Function) function with a Pairwise Master Key (PMK) as the input key material. The function parameters can include "Pairwise key expansion" as the information parameter and various combinations of values derived from AA (Authentication Algorithm), SPA (Selected Pairwise Algorithm), ANONCE (Authentication Nonce), and SNONCE (Supplicant Nonce). These values can be manipulated and fed into the HMAC-KDF-NNN function to generate the derived keys. The process can be expressed as follows. That is, JPEG2025084084000005.jpg16165

[0133] In one example, the technical solution can include a TK212 that can function as a K-Body (e.g., body key 214) without a K-Header being provided. In one aspect, the technical solution can include the TK212 as a combination of a K-Header (e.g., header key 216) and a K-Body (e.g., body key 214). In one aspect, the technical solution can include the derivation of a K-Header and a K-Body by an HMAC-KDF-NNN that can utilize one or more different fixed patterns. For example, the K-Header can be obtained using HMAC-KDF-NNN(TK, FixedPattern (fixed pattern) 1), and the K-Body can be obtained by HMAC-KDF-NNN(TK, FixedPattern2). In one aspect, the technical solution can include K-Header = AES(TK, FixedPattern3), K-Body = AES(TK, FixedPattern4); 0123^0128 for FixedPattern3, and 0128 for FixedPattern4; "Header" for FixedPattern1 and "Body" for FixedPattern2.

[0134] In one aspect, the technical solution can include a PMK not exposed to hardware by using an existing AES engine in the hardware, using different keys for improved security, and using temporary key programming in the hardware. In one aspect, the technical solution can use a pattern to use an AES-based derivation for the K-Header and use the TK for the K-Body. For example, the solution can utilize the feature that can be represented as K-Header = AES(TK, FixedPattern5), K-Body = TK; 0123^0128 for FixedPattern5.

[0135] Regarding transmission and reception, in some aspects, an IV-Header and a C-Header can be used. The IV-Header can enable MIC checking and replay checking before body processing. For example, the C-Header can provide a header encryption field and / or obfuscation. In some examples, a stand-alone T-Header can be included. The technical solution can enable MIC checking and replay checking before body processing. In some aspects, a combined (coupled, synthesized) header can be used without or with minimal changes to the frame format. For example, the T-Header can be used to calculate T-Orig, and existing processes can be used to verify T-Orig. Current replay checking can be used to trust the Header, and the result is output as <header>It can be inside.

[0136] General security considerations can provide a basic configuration for preventing security attacks and minimizing the number of keys required. For example, although the counter / IV may not be the same, the keys can be the same. Masked fields can be authenticated. In some examples, the fields may not be encrypted. A replay check may or may not be performed. Encrypted payloads may not be re-encrypted. MAC header protection can be combined with MPDU encryption to reduce additional key material. The technical solution may not include changes to CCMP / GCMP.

[0137] CCMP can include M which represents a MAC length that can be 8 octets or 16 octets. Ke can be a key of 16, 24, or 32 octets. The MIC key can be an encryption key. For example, the technical solution can use, as 128-bit and 256-bit K of MHP CCMP, JPEG2025084084000006.jpg7165 can be used. P1 and P2 are fixed patterns, for example, that is JPEG2025084084000007.jpg7165 For example, the technical solution can include the following configuration. That is ·Si := E(K, Ai), i = 0, 1, 2, ···; Ai = <flags:1> <nonce:13><Block Counter i:2>, which can represent the encryption of data block (Ai) using key (K) in the sequence, where each block Ai can include parameters such as flags, nonces, and block counters that can be combined to form an input for encryption. · X1 := E(K, B0); B0 is the CCM flag, length(AAD), AAD (last block padded with 0), JPEG2025084084000008.jpg6165 For i = 1, …, n, which can represent the encryption process for the CCM (Counter with CBC - MAC) mode, including encrypting the first block (B0) using key (K), and then repeatedly encrypting subsequent blocks (Xi) by taking the exclusive - OR of the subsequent block (Xi) with the previous block (Bi) before encryption. · Auth Code := JPEG2025084084000009.jpg6165 This can represent the authentication code (Auth Code) calculated based on the last encrypted block (Xn + 1) and the length of the message (M). This code can be combined with the derived value (S0) to generate an ICV or Auth Tag. · Plaintext: P; Ciphertext: JPEG2025084084000010.jpg5165 This can represent the conversion of plaintext (P) to ciphertext (Ci) using the above - mentioned encryption process, where each block of the ciphertext is derived by taking the exclusive - OR (XOR) of the corresponding block of the plaintext with the output of the encryption function.

[0138] The technical solution can include transmission from a transmitter device 202 to a receiver device 204, which can be represented as A(IV), C (Ciphertext), and T1 (ICV). For example, A(IV) can mean the IV used for encryption, C (Ciphertext) can indicate the encrypted message or data, and T1 (ICV) can indicate the Integrity Check Value (ICV), or the authentication tag associated with the encrypted frame.

[0139] The Galois / Counter Mode Protocol (GCMP) can include an encryption protocol used for secure communication, such as in a wireless network, and provides encryption and integrity protection for data frames. GCMP can include the following configurations. That is, ·H = E(K, 0 128 ); The Hash key is the 0-block encrypted with the key; the 0-block can include JPEG2025084084000011.jpg7165 other selected ones for H. For example, the technical solution can use JPEG2025084084000012.jpg6165 128-bit and 256-bit K of MHP GCMP. JPEG2025084084000013.jpg7165 P1 and P2 can be fixed patterns such as ·Y0 = JPEG2025084084000014.jpg6165 This can show the initialization of the counter value (Yi) used in the encryption process. When the length of the initialization vector (IV) is 96 bits, Y0 can be formed by concatenating the IV with 32 bits of the value of 0. Otherwise, it can be calculated with the subsequent counter value (Yi) derived by incrementing the previous counter using the GHASH function together with the hash key (H) and the IV. ·Ci = JPEG2025084084000015.jpg7160 This can represent the encryption process in GCMP, where each block of the ciphertext (Ci) is obtained by taking the exclusive OR (XOR) of the corresponding plaintext block (Pi) with the output of the encryption of the counter value (Yi) using the encryption key (K). The last block of the ciphertext (C*) can be derived similarly with an additional XOR operation including the most significant bits of the encryption output. ·T1 = JPEG2025084084000016.jpg7160 This can correspond to the determination of the integrity check value (T1) or the authentication tag of the transmitted data. It can include the GHASH function that calculates the hash value based on the hash key (H), the related data (A), and the ciphertext (C). Then, the bits of this hash value can be combined with the encryption output of the first counter value (Y0) to generate the final authentication tag. ·The technical solution can be transmitted from the transmitter device 202 to the receiver device 204 as represented by A (IV), C (Ciphertext), T1 (ICV).

[0140] The technical solution can include a separate MHP key. For example, the technical solution can insert an MHP header protected by the MHP key. For example, packet X JPEG2025084084000017.jpg7159 It can include. For example, packet Y can include JPEG2025084084000018.jpg7160 It can include. For example, JPEG2025084084000019.jpg6159 The modified header protection can be between MHPHX and TX, and the connection between MHPHX and TX may be used. The technical solution can include a parallel mechanism for HW key state, replay check state, algorithm negotiation, and key rotation.

[0141] The technical solution can construct octet counters D0…Dk-1. For example, the AES block size is 16 octets, and the key can be 16, 24, or 32 octets. For example, the zero in 4 octets / MHP prefix or D0- can be used for the verification of T2 before T1. For example, JPEG2025084084000020.jpg6159 provides the uniqueness of the counter. For example, A2, PN, Changeable fields can already exist in the frame. PN can be reused, but the counter value may not be used for security.

[0142] For example, the technical solution can JPEG2025084084000021.jpg12167 include configurations such as. When receiving, for example, as before, JPEG2025084084000022.jpg8163 The technical solution can send :~A(IV), C (Ciphertext), T2 (ICV). Only after decrypting C and verifying T1, the modified fields are trusted.

[0143] For example, the technical solution can include advertising the MAC header protection (MHP) of RSNXE. For example, beacons, probe responses, associations, and 4-way M2 / M2 can be used. Bits can be allocated (e.g., 15 is the maximum value). The UHR can use MHP. Keys can be reused. The Validation Order can include Validate T1 and then trust only the Header fields that are changed and included in the T2 calculation. For example, if MHP replay detection should be done first, the prefix and E(K,D) are sent first and the replay is inspected before processing all frames using the current protection (CCMP, GCMP). Replay inspections can be combined.

[0144] For example, the technical solution can include validating T2 and the changed fields before validating T1. For example, the solution can change the frame format by including another field (e.g., MAC Security Header). Another set of keys may or may not be used in the same way as the original PN that is later verified. There may be more bits for the payload, and 1 bit can be used to set up so that the counter is not reused (e.g., the multicast bit of A2).

[0145] The technical solution can include multiple advantages. For example, the technical solution can maintain a consistent frame format without incorporating a MAC Header Protection (MHP) header. The number of unicast keys can be left unchanged, and synthesizing (combining, merging) the MHP header with tags from body encryption can be emphasized in terms of security. Without this synthesis, there may be vulnerabilities where the MHP header of one frame can be mixed with another body, leading to a loss of protection for the modified header fields. The same keys, metadata algorithms, and packet numbers (PNs) can be intended to be used with MHP without changing protocols such as the 4-way handshake. To enhance security, there is no extra replay check and corresponding transmit / receive states for MHP keys, and the Operating Channel Validation (OCV) feature may help eliminate multi-channel Man-In-The-Middle (MITM) attacks. The technical solution introduces minimal changes to the current protocol and supports both CCMP and GCMP. The security weaknesses are minimized by chaining blocks using the same key, similar to the CCMP and GCMP approaches.

[0146] In some embodiments, the technical solution can include enhancements to a beacon frame protection mechanism within a wireless network, including improvements with key derivation, frame formatting, and message integrity. The technical solution can include using CMAC (Cipher-based Message Authentication Code) or GMAC (Galois / Counter Code) techniques, along with AES (Advanced Encryption Standard) encryption to provide integrity and authenticity of beacon frames. Key derivation can be used to perform shared Beacon Integrity Protection (BIP) key distribution during the association or handshake process and can be used for encryption and calculation of the Message Authentication Code (MAC). Frame format adjustment can include a Management MIC Element (MME) that includes a CMAC or GMAC tag, along with a Timestamp Field (TSF) that can be carried within the beacon. The technical solution can include updates to the MME, replacing existing MIC elements with AES encrypted blocks derived from timestamps and keys to improve security against tampering. A hash function or keyed hash function can be used to verify timestamps within the beacon frame, facilitating improved data integrity and authenticity in the wireless communication process.

[0147] TSFs such as the Timestamp Element can be included in the solution. CMAC or GMAC can be utilized within the Beacon Integrity Protection (BIP) framework. BIP can be used to calculate the MIC sent to the MME. CMAC and GMAC can each use AES encryption or GHASH (Galois Hash) to protect the beacon frame. The technical solution can include replacing the existing BIP mechanism with an encrypted AES block.

[0148] The issue can include key negotiation, including situations where the key remains unchanged and backward compatibility where new elements carry the MIC along with the TSF. Also, the calculation per TTBT can be avoided, similar to calculating T and incrementally updating the MIC with T and SSF.

[0149] In some examples, the frame format can include an MME that can include an 8-byte or 16-byte CMAC tag T, or a 16-byte GMAC. The MME can be an administrative MIC element. The TSF can include an 8-byte timestamp field. The TSF can be carried in a Beacon. An authentication tag for T / MIC can be included. For BIP-GMAC, the tag can be 128 bits or 16 bytes. For BIP-CMAC, it can be 8 bytes for BPI-CMAC-128 or 16 bytes for BIP-CMAC-256. T can be calculated once for the beacon. The TSF can be changed per beacon and may not be included in T.

[0150] The technical solution can include key derivation. The same BIP key K can be used for encryption. For example, the same BIP (Beacon Integrity Protection) key (Key), denoted as K, can be used for both the operations of encryption and cryptography, such as calculating the MIC (Message Integrity Code) using CMAC (Cipher-based Message Authentication Code) or GMAC (Galois / Counter Mode). Such a key K can be distributed as part of an association or a four-way handshake procedure. For example, the key K can serve a dual purpose of facilitating secure encryption of data and calculation of the MIC to verify the integrity and authenticity of the transmitted message.

[0151] In the frame format specification, the MME (Management MIC Element) can include an 8- or 16-byte CMAC tag, or a 16-byte GMAC tag. The MME can function as a management component that plays a role in integrity checking within the frame. The frame can include an 8-byte TSF (Timestamp Field) and can be carried within a beacon frame. In the context of BIP (Beacon Integrity Protection) using GMAC, the current authentication tag or MIC (Message Integrity Protection) can include a tag that can be set to 128 bits or 16 bytes. In the case of BIP-CMAC, the length of the tag can vary such that it has 8 bytes assigned to BIP-CMAC-128 and 16 bytes assigned to BIP-CMAC-256. The Tag (T) can be calculated once for each beacon frame. The TSF (Timestamp Field) can vary for each beacon and may or may not be included in the calculation of the Tag.

[0152] The technical solution can include changes or updates to the MME (Management MIC Element) using the AES encryption block. For example, the TSF (Timestamp Field) found within the beacon frame can JPEG2025084084000023.jpg7163 function as a timestamp. For example, within the MIC field of the MME, the same timestamp element can be encapsulated. The encryption process can include applying AES encryption using the key K to the XOR operation between the Tag and the padding version of the TSF appended with zero, resulting in a 16-byte fixed-size AES block. The TSF can be padded with zero to the size of T. Then, the XOR function is applied to T, and the result can be padded with zero up to one AES block. Then, it can be encrypted using K to generate one encryption block.

[0153] Upon reception, the encrypted block can JPEG2025084084000024.jpg7163 be decrypted using the key K to extract. The expected tag (T) can be obtained using the TSF extracted from the beacon frame. Then, the expected T can undergo cryptographic verification using the conventional BIP (Beacon Integrity Protection) mechanism. This verification can fail if the TSF / Timestamp within the beacon frame has been tampered with or changed.

[0154] Also, the technical solution can update the MME (Management MIC Element) using an additional hash function denoted as H, or a keyed hash function represented as KH (e.g., CMAC, GMAC, SHA * ). The TSF (Timestamp Field) can JPEG2025084084000025.jpg6163 can be used to fulfill the function of the timestamp within the beacon frame. Within the MIC field of the MME, the same timestamp element may be included. The process can include concatenating the timestamp (T) with the TSF. Such a process can include JPEG2025084084000026.jpg7163 the calculation of or can be followed by such calculation. Such calculation can generate a new value T2, which can then be transmitted in place of T within the MIC. Upon reception, the receiver can utilize the existing BIP mechanism to extract T using the key K. Then, T can be concatenated with the TSF from the beacon frame, and the expected T2 can be calculated using H or KH. The received T2 from the MME can be compared with the expected T2, and upon their match, acceptance can be made, and otherwise, the frame can be rejected. Encryption can be implemented when the 802.11 hardware can include AES compatibility.

[0155] In some embodiments, an actor knowledgeable about the BIP key can spoof the AP with a beacon or a MIC as defined. Some considerations can include using a public and private key pair for signing, in which case the MIC at the MME (e.g., element) can be a signature. For example, an EC NIST P256 signature can include 64 bytes. Considerations can include transmitting an additional element AIMIC to avoid spoofed MICs using public key signatures, such that spoofing by anyone with the BIP key can be avoided. Considerations can include replacing the MIC or, to avoid updating the public key signature for each TBTT / Beacon interval for which the TSF / Timestamp is also verified, AES and / or JPEG2025084084000027.jpg7163 It is possible to have a new MIC that covers AIMIC with the hash of .

[0156] The technical solution can include improvements related to MAC header protection (MHP), including key derivation and frame formatting. Regarding key derivation, the technical solution can include the use of a single key (TK) programmed in hardware from which a K-Header and a K-Body can be derived. For MHP, the current solution can use an IV-body (IV body) that includes the current security header (IV) for the frame (body), and an IV-header (IV header) can be added and used for MAC header protection so that it can be defined and used. This approach can rationalize key management and reduce the memory footprint of the hardware. The frame format can include a synthetic MIC, an IV-Header, and an ICV-Header configuration, taking into account header protection, body decryption, and integrated MIC support. An investigation can be carried out to evaluate support for these proposed enhancements, addressing the key derivation method, the basic settings of the frame format, and the use of the IV-Body to show MHP and ICV configurations.

[0157] For example, MHP can be used for MAC header protection, including improvements to key derivation and frame formatting. Regarding the frame format, options can exist, such as a fixed format with a synthetic MIC or with an initialization vector for the header (IV-Header) and an integrity check value for the header (ICV-Header) (MIC). A smaller PN of the header can be used, and an indication of a reserved field of the IV-Body, such as 1 byte, can be utilized. Additional authentication data (Additional Authentication Data: AAD) for the ICV-Header can include the packet number original (PN-Orig), but it should be noted that a smaller PN may not support header encryption.

[0158] Key derivation can include approximate matches with various keys. Using the same key can be done, but may require additional work to specify, for example, due to different counter configurations. One key can be programmed into hardware, aiming to prevent an increase in hardware memory for keys at the access point. For example, a single TK can be programmed into hardware, and the K-Body and K-Header can be derived using a single AES (ECB) operation, leveraging existing hardware support for AES. The K-Body and K-Header can be derived and programmed into hardware. The PMK (Pairwise Master Key) may not leave the supplicant / authenticator, and the hardware may not support hash calculations.

[0159] In the frame format, one example (e.g., Option A) is <header> 、 <iv-body> 、 <c-body>and can include synthetic ICV / MIC. The short packet number (PN) for the header can potentially vary for the same body PN. The header key can be calculated using the large PN from the IV-Body using JPEG2025084084000028.jpg8165 The Body PN, unlike the nonce, can be represented in little-endian format, and the key for the Body, K-Body, can be calculated similarly using JPEG2025084084000029.jpg7165 The header replay check can use a 7-byte PN that concatenates the body PN with the short PN. The format option and the short PN can be carried in reserved bits within the body-IV. The synthetic ICV can be calculated by taking the exclusive logical OR of the ICV-Header and the ICV-Body. The header AAD (Additional Authentication Data) can include various parameters, but some similar fcs and seqs can be masked in the body AAD. The header nonce can include A2 concatenated with the Short PN.

[0160] For example, (e.g., in Option B), <header> 、 <iv-body> 、 <c-body>, and optional <iv-header>and <icv-header> <icv-body>It may be included. This option can enable the separation of the IV-Header and the IV-Body. In this case, the IV-Header is defined by a larger separate PN or TSF (Time Stamp Field) as needed without encrypting any part of the header protection.

[0161] In one example, k_body can be left unchanged, so k_body is or functions as TK. For example, <fc>may not be used for the K-Header. For example, the k_header can create different header keys for each frame. In some examples, the K_Header can derive the header key only once per TK. For example, if it is not coupled to the header MIC / ICV, a malicious user can interfere with and mix two frames, namely the <i,j> frame with header PNi and body PNj, such as the <1,1> and <2,2> frames being sent, and at the same time, the malicious user can interfere and send <1,2>. For example, if the integrated MIC is not used, <1,1> can be sent, but a malicious user can intercept and send <1,1 with bodychanged (with a changed body)>. If the body MIC is not verified before affecting the header MIC, the transmitter state may collide with the receiver state. For example, the technical solution can provide body PN binding in different ways. For example, the technical solution can JPEG2025084084000030.jpg7165 be implemented. For example, the technical solution can use a slight variant of GCM (used by 11be) along with the Header Nonce. For example, the technical solution can JPEG2025084084000031.jpg7165 include or be used. The Short PN can be new, and the Block Counter can be 3 bytes as opposed to 4 bytes of the standard GCM. Among the things that can be protected, there can be up to 2 to the 24th power (2 24 ) number of 16-byte blocks. Since the header can be made smaller, different frames can have the same short PN but different Body PNs. The Current IV (current IV) can be used as detailed elsewhere in this specification.

[0162] The technical solution can include an embodiment of a synthesized integrated ICV that may use body decryption before an acknowledgment (ACK) is issued. This process can be embodiment-dependent, but a particular embodiment can be executed and utilized accordingly. For example, the ACK procedure may not include the completion of body processing. RSNXE (Robust Security Network Exchange) could notify support for a MIC integrated with MAC header protection (MHP), such as when both endpoints of the communication support this feature. Existing IV-Body reserved bits can function as indicators of the frame format in use.

[0163] Header ICV calculation can include calculating the header nonce using a standard nonce format along with a short PN or packet number (PN) from the optional IV header, and calculating the header AAD (Additional Authentication Data) without masking. The header ICV (Integrity Check Value) can be calculated using the CCMP / GCMP MAC algorithm incorporating the header key, header nonce, header AAD, and null data. Regarding the MHP Bits, a value of 0x20 for IV-Body[3] can indicate the use of MAC header protection (MHP), while 0x80 can indicate the utilization of an integrated MIC (Integrated Message Integrity Code). In the case where the integrated MIC is used, the absence of set bits can indicate that the IV-Header and ICV-Header are separate. The short PN can be represented by IV-Body[2] when the integrated MIC is used. The technical solution may include or use a strawpoll. The strawpoll can include one or more inquiries regarding various aspects of the protocol. First, in Strawpoll I, the strawpoll or field survey can include a question regarding whether there is support for programming one key (TK) into hardware from which the K-Header and K-Body can be derived. Participants can be given the option to indicate (vote) "Yes", "No", or "Abstain". For example, in Strawpoll II, the focus can be on whether the frame format supports an Integrity Check Value (ICV). Again, participants can choose "Yes", "No", or "Abstain". For example, in Strawpoll III, the use of MAC Header Protection (MHP), integrated ICV, use of a shorter Header PacketNumber (PN), and use of the IV-Body to notify the presence of the IV-Header can be inquired about. Similarly, participants can respond with "Yes", "No", or "Abstain".

[0164] In one example, the Message Integrity Code (MIC) can be kept in its current form, but a modified version is transmitted using AES encryption. In particular, the transmission can include encrypting the MIC that is exclusive-ORed with the Timestamp Field (TSF) using a predetermined key. Upon reception, the receiver can decrypt the encrypted MIC and utilize the timestamp extracted from the Beacon to access or verify the TSF or MIC, which is similar to the current process. This AES operation can be performed at each Beacon and can help reduce the processing of all Beacons and avoid repeatedly calculating the MIC.

[0165] As used herein, when an element is referred to as being "connected" or "coupled" to another element, it should be understood that the element can be directly connected or coupled to the other element, or can have intervening elements that exist between the connected or coupled elements. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, it should be understood that there are no intervening elements in the "direct" connection between the elements. However, the presence of a direct connection does not exclude other connections where intervening elements may be present.

[0166] References to "or" may be construed as inclusive in that any terms described using "or" may indicate any one, more than one, and all of the terms being described. References to at least one of a connective list of terms may be construed as an inclusive disjunction to indicate any one, more than one, and all of the terms being described. For example, a reference to "at least one of 'A' and 'B'" can include only 'A', only 'B', and both 'A' and 'B'. Such references used in connection with "comprising" or other open terms can include additional items.

[0167] It should be noted that certain sections of the present disclosure may refer to terms such as "first" and "second" in connection with the transmission of spatial streams, sounding frames, responses, and subsets of devices to identify or distinguish one thing from another (singular or plural). These terms are not intended to simply relate entities temporarily or in sequence (e.g., a first substrate and a second substrate), although in some cases, these entities can include such a relationship. Or, these terms do not limit the number of possible entities (e.g., delay circuits, filters, peak detectors) that can operate within a system or environment. It should be understood that the systems described above can provide any one or a plurality of each of these components, and these components can be provided as stand-alone structures or devices, or in some embodiments, as a plurality of structures or devices in a distributed system.

[0168] From the above description of the method and system, those skilled in the art will be able to make and use its embodiments, but those skilled in the art will understand and recognize the existence of variations, combinations, and equivalents of the specific embodiments, methods, and examples in this specification. Therefore, the present method and system should not be limited by the above-described embodiments, methods, and examples, but should be limited by all embodiments and methods within the scope of the present disclosure and within the scope of the idea.< / fc> < / icv-header> < / iv-body> < / header> < / iv-body> < / header> < / flags:1> < / header>

Claims

1. 1. A system comprising: One or more processors coupled to a memory, the one or more processors comprising: using a temporal key (TK) programmed into hardware to calculate a first key for the body of the frame and a second key for the header of the frame, the second key being different from the first key; encrypting a body of the frame at a Machine Access Control (MAC) layer with the first key and encrypting a header of the frame at the MAC layer with the second key; calculating a first Message Integrity Code (MIC) of the encrypted frame using the first key and a second MIC on the contents of the frame's header at the MAC layer using the second key; 4. A system comprising: a first MIC for transmitting the frame together with the first MIC and the second MIC to a receiver; the receiver configured to determine integrity of a header of the frame based on at least the second MIC.

2. The one or more processors: generating a composite MIC from the first MIC and the second MIC; The system of claim 1 , further comprising transmitting the composite MIC to the receiver for determining the integrity of the frame.

3. 3. The system of claim 2, wherein the composite MIC is generated using a reversible operation applied to the first MIC and the second MIC, the reversible operation comprising at least one of a concatenation of the first MIC and the second MIC, or a bitwise exclusive-or (XOR) calculation applied to the first MIC and the second MIC.

4. 3. The system of claim 2, wherein the composite MIC is generated using at least one of a concatenation of the first MIC and the second MIC, or a bitwise exclusive-or (XOR) calculation applied to the first MIC and the second MIC.

5. The one or more processors: calculating the first key using at least one of a Hash-based Message Authentication Code (HMAC) operation or an Advanced Encryption Standard (AES) encryption operation with a first input of the TK and a first fixed pattern; 2. The system of claim 1, further comprising: computing the second key using the HMAC operation with a second input of the TK and a second fixed pattern.

6. 6. The system of claim 5, wherein the first fixed pattern includes at least a portion of the contents of the body of the frame, and the second fixed pattern includes a packet number (PN) of the body of the frame, a type of the frame, or a link address for multi-link communications.

7. the frame corresponds to a first network packet of a plurality of network packets, the first network packet including a first packet number in the header of the frame, and the one or more processors: determining to retransmit the first network packet as a second network packet having a second packet number in a second header of a second frame of a second network packet, the second packet number being different from the first packet number; 2. The system of claim 1, wherein the TK is used to calculate a first key for a second body of the second frame of the second network packet and a second key for the second header of the second frame, the first key for the first network packet being different from the first key for the second network packet.

8. the first key for the second body of the second frame of the second network packet is the same as the first key for the body of the frame of the first network packet, and the one or more processors: Identifying one or more frames at the MAC layer that are to be encrypted for wireless communication; 8. The system of claim 7, further comprising: encrypting the second frame of the second network packet at the MAC layer using the first key for the second body and the second key for the second header.

9. The one or more processors: determining a pairwise master key (PMK) during communication over a wireless network between the device including the one or more processors and a receiver; The system of claim 1 , further comprising: generating said temporal key (TK) using said PMK.

10. 2. The system of claim 1, wherein the receiver is further configured to determine the integrity of the header based on verifying the integrity of the header with the second MIC prior to decrypting the frame.

11. The one or more processors: including the second MIC in the header of the frame; The system of claim 1 , further comprising: transmitting the frame with the second MIC included in the header of the frame.

12. 2. The system of claim 1, wherein the one or more processors calculate at least one of the first key or the second key using an Advanced Encryption Standard (AES) algorithm and at least one of the first MIC or the second MIC using at least one of a Cipher Block Chaining-MAC Protocol (CCMP) or a Galois / Counter Mode Protocol (GCMP).

13. 2. The system of claim 1, wherein the receiver is configured to verify the integrity of the header of the frame using the second MIC before processing the body of the frame.

14. 1. A method for providing protection for a Machine Access Control (MAC) header of a frame, comprising: identifying, by one or more processors, a temporal key (TK) programmed into hardware for encrypting frames at a Machine Access Control (MAC) layer for wireless communication; calculating, by the one or more processors, a first key for encrypting a body of the frame and a second key for encrypting a header of the frame using the TK, the second key being different from the first key; identifying, by the one or more processors, one or more frames at the MAC layer to be encrypted for wireless communication; encrypting, by the one or more processors, a body of the one or more frames at the MAC layer with the first key and encrypting the header of the one or more frames at the MAC layer with the second key.

15. calculating, by the one or more processors, a first Message Integrity Code (MIC) of the encrypted frame using the first key and a second MIC on contents of the header of the frame at the MAC layer using the second key; 15. The method of claim 14, comprising transmitting, by the one or more processors, the frame with the first MIC and the second MIC to a receiver, the receiver configured to determine integrity of the header of the frame based on at least the second MIC.

16. calculating, by the one or more processors, the first key using at least one of a Hash-based Message Authentication Code (HMAC) operation or an Advanced Encryption Standard (AES) encryption with a first input of the TK and a first fixed pattern; calculating, by the one or more processors, the second key using the HMAC operation with a second input of the TK and a second fixed pattern; 15. The method of claim 14, wherein the first fixed pattern includes at least a portion of the contents of the body of the frame, and the second fixed pattern includes a packet number (PN) of the body of the frame, a type of the frame, or a link address in a multi-link communication.

17. The frame corresponds to a first network packet of a plurality of network packets, the first network packet including a first packet number in the header of the frame, and the method further comprises: determining, by the one or more processors, to retransmit the first network packet as the second network packet having a second packet number in a second header of a second frame of a second network packet, the second packet number being different from the first packet number; calculating, by the one or more processors, a first key for a second body of the second frame of the second network packet and a second key for the second header of the second frame using the TK, wherein the first key for the first network packet is different from the first key for the second network packet and the first key for the second body of the second frame of the second network packet is the same as the first key for the body of the frame of the first network packet; identifying, by the one or more processors, one or more frames at the MAC layer to be encrypted for wireless communication; 15. The method of claim 14, comprising: encrypting, by the one or more processors, the second frame of the second network packet at the MAC layer using the first key for the second body and the second key for the second header.

18. calculating, by the one or more processors, the first key for the body using an Advanced Encryption Standard (AES) operation with a first input of the TK and a first fixed pattern, and calculating the second key for the header of the frame using the same AES operation with a second input of the TK and a second fixed pattern; 15. The method of claim 14, comprising calculating, by the one or more processors, the second key for the header using an AES operation with a first input of the TK and a first fixed pattern and using the TK as the first key for the body of the frame.

19. generating an Initialization Vector (IV) for encryption based on the parameters of the frame; 15. The method of claim 14, comprising using the IV to encrypt the body of the frame.

20. 1. A system comprising: One or more processors coupled to a memory, the one or more processors comprising: Identifying a temporal key (TK) programmed into the hardware for encrypting frames at a Machine Access Control (MAC) layer for wireless communication; using said TK to calculate a first key for encrypting a body of the frame and a second key for encrypting a header of the frame, said second key being different from said first key; Identifying one or more frames at the MAC layer to be encrypted for wireless communication; a first key for encrypting the body of the one or more frames at the MAC layer and a second key for encrypting the header of the one or more frames at the MAC layer.

Images