Environmental iot dos and ddos attack remediation

Abstract

This document describes systems, methods, and means related to remediation of distributed denial-of-service attacks in the Environmental Internet of Things (AIoT). A network node may include a processor. The network node may be configured to receive a service request message from a Wireless Transmit / Receive Unit (WTRU). The network node may generate a puzzle based on the service request message. The network node may send a service message response to the WTRU. The service message response may include an indication of the puzzle. The network node may receive an evidence request message including an indication of evidence. The evidence may be associated with a solution to the puzzle. The network node may verify the solution to the puzzle based on the indication of the evidence. The network node may process the service request message based on the verification.

Description

Cross-reference to related applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 557,053, filed February 23, 2024, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth generation can be referred to as 5G. Previous (traditional) generations of mobile communications could be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This document describes systems, methods, and means related to remediation of distributed denial-of-service (DDoS) attacks on environmental Internet of Things (AIoT). A network node may include a processor. The network node may be configured to receive a service request message from a wireless transmit / receive unit (WTRU). The network node may generate a puzzle based on the service request message. The network node may send a service message response to the WTRU. The service message response may include an indication of the puzzle. The network node may receive an evidence request message including an indication of evidence. The evidence may be associated with a solution to the puzzle. The network node may verify the solution to the puzzle based on the indication of the evidence. The network node may process the service request message based on the verification.

[0004] This document may disclose one or more features. For example, the service message response may include an indication of a freshness parameter configured to prevent WTRU identity impersonation or to prevent a second WTRU from replaying the evidence. The puzzle may be a timed puzzle based on the freshness parameter. The network node may send the service message response based on determining that the number of failed authentication attempts meets a threshold.

[0005] The network node can send the service message response based on determining that a DDoS attack has been fixed. The puzzle can be at least one of a reverse cryptographic puzzle or a one-way cryptographic hash function puzzle. The indication of the evidence can include the solution to the cryptographic reverse puzzle or the solution to the hash function puzzle. The puzzle can be a reverse cryptographic puzzle. The indication of the evidence can include plaintext associated with the encryption key. The solution can be verified based on determining that a portion of the plaintext associated with the encryption key is the same as a portion of the solution. The puzzle can be a cryptographic hash function puzzle. The indication of the evidence can include hash function input text associated with the hash function argument. The solution can be verified based on determining that a portion of the hash function input text associated with the hash function argument is the same as a portion of the solution. The processor can select a puzzle strength parameter. The puzzle strength parameter can be configured to adjust the level of input the WTRU spends to generate the evidence. The puzzle can be generated based on the puzzle strength parameter. The puzzle strength parameter can be associated with the encryption key length or a portion of the cryptographic hash function argument.

[0006] The WTRU may include a processor. The WTRU may be configured to send a service request message to a network node. The WTRU may receive a service message response from the network node. The service message response may include an indication of a puzzle. The WTRU may generate evidence based on the puzzle. The evidence may be associated with the solution to the puzzle. The WTRU may send an evidence request message to the network node. The evidence request message may include an indication of the evidence and / or a request for the network node to verify the evidence based on the solution to the puzzle. The WTRU may receive an authentication response including an indication that the service request message is being processed.

[0007] This document may describe one or more features. The service message response may include an indication of a freshness parameter configured to prevent WTRU identity impersonation or to prevent a second WTRU from replaying the evidence. The puzzle may be a timed puzzle based on the freshness parameter. The puzzle may be at least one of a reverse cryptographic puzzle or a one-way cryptographic hash function puzzle. The indication of the evidence may include a solution to the cryptographic reverse puzzle or a solution to the hash function puzzle. The puzzle may be a reverse cryptographic puzzle. The indication of the evidence may include a portion of plaintext associated with the encryption key. A portion of the solution to the puzzle and / or a portion of the plaintext associated with the encryption key may be the same. The indication of the puzzle may be associated with the encryption key length or a portion of the cryptographic hash function argument.

[0008] This paper describes systems, methods, and means related to AIoT (D)DOS attack remediation, such as by implementing cryptographic puzzles when processing service provisioning requests.

[0009] A device (e.g., an AIoT device) may (e.g., be configured to) perform one or more actions. The device may send a service request. The device may receive a cryptographic puzzle based on the service request. The device may generate evidence based on the solution to the cryptographic puzzle. The device may send the evidence.

[0010] An intermediate node (e.g., a WTRU) may (e.g., be configured to) perform one or more actions. The intermediate node may receive a service request. The intermediate node may generate a cryptographic puzzle based on the service request. The intermediate node may (e.g., send the puzzle to the requesting entity). The intermediate node may receive evidence indicating a solution to the puzzle. The intermediate node may determine whether the evidence is validated. The intermediate node may allow further processing of the service request based on the validation of the evidence.

[0011] The puzzle can be one or more of a one-time puzzle or a timed puzzle. The puzzle may include a freshness parameter configured to prevent device identity spoofing. Attached Figure Description

[0012] Figure 1A This is a system diagram illustrating an example communication system that can implement one or more of the disclosed embodiments.

[0013] Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0014] Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A The diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system.

[0015] Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown is for another example RAN and another example CN used in the communication system.

[0016] Figure 2 An example activity / sleep cycle of WTRU is depicted.

[0017] Figure 3 The signaling flow and components used for remediating example attacks are described.

[0018] Figure 4 Example configurations and assembly of puzzles based on reverse cryptography are depicted.

[0019] Figure 5 An example configuration and assembly of a cryptographic puzzle based on a reverse cryptographic hash function is depicted.

[0020] Figure 6 Example operations for solving cryptographic reverse engineering puzzles are described.

[0021] Figure 7 Example operations for solving hash function inversion puzzles are described.

[0022] Figure 8 Example operations for processing evidence received from an uncertified entity (UnEn) are described.

[0023] Figure 9 An example of AIoT (D)DOS repair is depicted in the context of EAP guidance via the control plane of a (e.g., cellular) network.

[0024] Figure 10 Example 5G AKA (D)DOS repair operation is described.

[0025] Figures 11A to 11B Example 5G AKA (D)DOS repair operation is described.

[0026] Figures 12A to 12B Example (D)DOS repair operation is described for the EAP-AKA certification process.

[0027] Figures 13A to 13E An example (D)DOS fix is ​​described for the PC5 security establishment process used for 5G ProSe WTRU to network relay communication via the control plane.

[0028] Figure 14 The example edge service provides requests and responses. Detailed Implementation

[0029] Figure 1A This diagram illustrates an example communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 can employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0030] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0031] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106 / 115, Internet 110, and / or other networks 112). As an example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0032] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for radio services for a specific geographic area, which may be relatively fixed or may vary over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0033] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0034] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0035] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish air interface 116.

[0036] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0037] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0038] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN), etc.

[0039] Figure 1ABase station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, residence, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0040] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although in Figure 1A Although not shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may be utilizing NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0041] CN 106 / 115 can also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

[0042] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks on different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0043] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0044] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated into an electronic package or chip.

[0045] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0046] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0047] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals to be received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

[0048] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)).

[0049] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0050] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. As a supplement to or alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0051] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, FM radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0052] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe used for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe used for either UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0053] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0054] RAN 104 may include eNode-B 160a, 160b, 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-B 160a, 160b, 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In one embodiment, eNode-B 160a, 160b, 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0055] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0056] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0057] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting specific serving gateways, etc., during the initial attachment of WTRUs 102a, 102b, and 102c. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0058] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0059] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0060] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0061] Although Figures 1A to 1D The WTRU is described as a wireless terminal, but it is conceivable that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0062] In a representative embodiment, the other network 112 may be a WLAN.

[0063] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that loads traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send a traffic flow to the AP, and the AP can deliver the traffic flow to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA (e.g., directly between them) via Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0064] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, each STA, including the AP, can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0065] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0066] Very High Throughput (VHT) STAs can support wide channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, data can flow through a segmentation parser, which divides the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0067] 802.11af and 802.11ah support sub-1 GHz operating modes. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0068] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and available.

[0069] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah varies from 6 MHz to 26 MHz depending on the country code.

[0070] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0071] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0072] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various or scalable lengths or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

[0073] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without simultaneously accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0074] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0075] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0076] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0077] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure service flow routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0078] UPF 184a and 184b can be connected to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0079] CN 115 can facilitate communication with other networks. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to DNs 185a and 185b via the N3 interface with UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and local data networks (DNs) 185a and 185b.

[0080] Given Figures 1A to 1D as well as Figures 1A to 1D As described herein, one or more of the following functions may be performed by one or more emulation devices (not shown): WTRU 102a to 102d, base stations 114a and 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a and 182b, UPF 184a and 184b, SMF 183a and 183b, DN 185a and 185b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0081] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more functions, fully or partially implemented and / or deployed as part of a wired and / or wireless communication network, to test other devices within the communication network. One or more simulation devices can perform one or more functions, temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes, and / or can use over-the-air wireless communication to perform tests.

[0082] One or more emulation devices can perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be utilized in test scenarios within test laboratories and / or non-deployed (e.g., for testing) wired and / or wireless communication networks to perform testing on one or more components. One or more emulation devices can be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0083] The Internet of Things in the Environment (AIoT) can refer to one or more of the following device types: devices that can operate without energy storage (e.g., device type A), where transmission can be performed by a WTRU using only backscatter; devices that use backscatter (similar to device type A) (e.g., device type B), but which can perform power boosting by using some stored energy at the device (e.g., derived from some energy harvesting); or devices that can perform autonomous transmission (e.g., without backscattering) for a period of time when sufficient energy may have been stored through energy harvesting.

[0084] Figure 2 An example activity / sleep cycle of a device (e.g., a WTRU) is depicted. In an example combining device types B and / or C, the WTRU can operate during short activity cycles, while performing energy harvesting, for example, during sleep cycles. Figure 2 As shown.

[0085] Service parameters (e.g., requirements) for environmental functional IoT may include (e.g., include) one or more of the following security parameters (e.g., requirements): the system (e.g., a 5G system) may enable security protections applicable to AIoT without compromising overall security protection; the system (e.g., a 5G system) may be able to provide mechanisms to protect the privacy of information (e.g., location and identity) exchanged during communication between AIoT devices and 5G networks or AIoT-enabled WTRUs; or, based on subscription and operator policies, the 5G system may authorize AIoT-enabled WTRUs to communicate with specific AIoT devices or groups of AIoT devices.

[0086] Performance service parameters (e.g., requirements) may include communication service availability. For example, for some services, communication service availability may be 99%.

[0087] Confidentiality, integrity, and / or availability can be guiding models in information security. A comprehensive information security strategy can include strategies and / or security controls that minimize threats to these three key components. Confidentiality can refer to protecting information from unauthorized access. Integrity can refer to data being trustworthy, complete, and / or unaltered by unauthorized users (e.g., accidental alteration or modification). Availability can refer to data being accessible (e.g., on demand / when needed). Availability (e.g., in the context of AIoT) can be part of AIoT security.

[0088] Architecture (such as security architecture) can impact availability. Access control can protect system availability (e.g., where authentication and authorization of temporary visitors can be done by a receptionist at the office door) and / or can be a vehicle for potential attacks on availability (such as DoS and DDoS attacks) (e.g., where authentication and authorization are performed or assisted by office staff behind the receptionist). Excessively high security levels may require (e.g., demand) significant resources and / or may reduce availability (e.g., make the system more difficult to use).

[0089] An uncertified entity (UnEn) can be, for example, a WTRU or an AIoT device. UnEn can be referred to interchangeably as WTRU, AIoT, device, entity, etc. in this document.

[0090] Edge network nodes (ENNs) can be, for example, base stations or access points. In this document, ENNs may be referred to interchangeably as network nodes, etc.

[0091] Remediation and / or rate limiting against DoS / DDOS attacks may require (e.g., mandate) the authentication and / or rate limiting of the attacking entity (e.g., based on its authorization status). Such remediation (e.g., requiring authentication) may be impossible if / when the attacking entity is involved in an attack against network entities and / or links involved in authentication and / or authorization. For example, since the authentication process can be used to launch DoS / DDOS attacks, rate limiting (e.g., only for) authenticated entities may not be a useful remediation for such DoS / DDOS attacks. For example, if (e.g., only) an ENN is involved in authentication and / or authorization, that node may be a potential DoS / DDOS victim. If core network nodes are involved in authentication and / or authorization, the attack may affect core network functions and / or interfaces (e.g., UDM / UDR in 5GS) and may not be limited to edge nodes.

[0092] Malicious AIoT devices and / or other entities impersonating AIoT devices can be perpetrators of attacks on the availability of AIoT systems. A lack of availability of the AIoT authentication and authorization subsystem when AIoT devices are ready to communicate (e.g., sufficient energy is recycled / saved, policy-driven scheduling) can exacerbate DoS attacks, for example, by further delaying AIoT device communication sessions. Remediation for such availability attacks can be achieved, for example, by selecting a system architecture where the ENN (e.g., fully) is responsible for entity authentication and authorization, and / or implementing a rate-limiting mechanism that allows for mitigation of availability attacks (e.g., DoS) while impacting malicious / attacking entities (e.g., in a more disproportionate way than legitimate entities).

[0093] This document describes systems, methods, and means related to remediation of distributed denial-of-service (DDoS) attacks on environmental Internet of Things (AIoT). A network node may include a processor. The network node may be configured to receive a service request message from a wireless transmit / receive unit (WTRU). The network node may generate a puzzle based on the service request message. The network node may send a service message response to the WTRU. The service message response may include an indication of the puzzle. The network node may receive an evidence request message including an indication of evidence. The evidence may be associated with a solution to the puzzle. The network node may verify the solution to the puzzle based on the indication of the evidence. The network node may process the service request message based on the verification.

[0094] This document may disclose one or more features. For example, the service message response may include an indication of a freshness parameter configured to prevent WTRU identity impersonation or to prevent a second WTRU from replaying the evidence. The puzzle may be a timed puzzle based on the freshness parameter. The network node may send the service message response based on determining that the number of failed authentication attempts meets a threshold.

[0095] The network node can send the service message response based on determining that a DDoS attack has been fixed. The puzzle can be at least one of a reverse cryptographic puzzle or a one-way cryptographic hash function puzzle. The indication of the evidence can include the solution to the cryptographic reverse puzzle or the solution to the hash function puzzle. The puzzle can be a reverse cryptographic puzzle. The indication of the evidence can include plaintext associated with the encryption key. The solution can be verified based on determining that a portion of the plaintext associated with the encryption key is the same as a portion of the solution. The puzzle can be a cryptographic hash function puzzle. The indication of the evidence can include hash function input text associated with the hash function argument. The solution can be verified based on determining that a portion of the hash function input text associated with the hash function argument is the same as a portion of the solution. The processor can select a puzzle strength parameter. The puzzle strength parameter can be configured to adjust the level of input the WTRU spends to generate the evidence. The puzzle can be generated based on the puzzle strength parameter. The puzzle strength parameter can be associated with the encryption key length or a portion of the cryptographic hash function argument.

[0096] The WTRU may include a processor. The WTRU may be configured to send a service request message to a network node. The WTRU may receive a service message response from the network node. The service message response may include an indication of a puzzle. The WTRU may generate evidence based on the puzzle. The evidence may be associated with the solution to the puzzle. The WTRU may send an evidence request message to the network node. The evidence request message may include an indication of the evidence and / or a request for the network node to verify the evidence based on the solution to the puzzle. The WTRU may receive an authentication response including an indication that the service request message is being processed.

[0097] This document may describe one or more features. The service message response may include an indication of a freshness parameter configured to prevent WTRU identity impersonation or to prevent a second WTRU from replaying the evidence. The puzzle may be a timed puzzle based on the freshness parameter. The puzzle may be at least one of a reverse cryptographic puzzle or a one-way cryptographic hash function puzzle. The indication of the evidence may include a solution to the cryptographic reverse puzzle or a solution to the hash function puzzle. The puzzle may be a reverse cryptographic puzzle. The indication of the evidence may include a portion of plaintext associated with the encryption key. A portion of the solution to the puzzle and / or a portion of the plaintext associated with the encryption key may be the same. The indication of the puzzle may be associated with the encryption key length or a portion of the cryptographic hash function argument.

[0098] This article provides features associated with UnEn DOS and / or DDOS remediation and increased availability of AIoT and (e.g., other 5G) systems.

[0099] AIoT (D)DOS repair (e.g., in the context of EAP booting via the control plane of a network (e.g., a cellular network)) can be achieved by one or more of the following:

[0100] AIoT devices can send service request messages to intermediate nodes (e.g., network nodes). In the example, intermediate nodes can be nodes particularly associated with satellites, base stations, servers, etc. Service request messages can be used for EAP guidance via the control plane of a (e.g., cellular) network.

[0101] Intermediate nodes can generate and / or acquire (e.g., compose) puzzles (e.g., with a freshness parameter). For example, intermediate nodes can generate and / or acquire (e.g., compose) puzzles with parameters that can prevent the impersonation of AIoT devices and / or replay evidence from other entities. This can be achieved, for example, by creating individual one-time puzzles and / or time-limited puzzles (e.g., by implementing a short lifespan parameter). Intermediate nodes can send (e.g., compose / select) puzzles to AIoT devices.

[0102] AIoT devices can solve the puzzle. AIoT devices can generate evidence (e.g., evidence corresponding to the solved puzzle). AIoT devices can send (e.g., forward) the evidence corresponding to the solved puzzle to intermediate nodes.

[0103] Intermediate nodes can analyze and / or verify evidence corresponding to a solved puzzle. Intermediate nodes can (e.g., upon successful verification) allow further processing of authentication and / or authorization requests. For example, processing of authentication and / or authorization requests can be conditional upon successful verification by an intermediate node. For instance, proactive screening of authentication / authorization requests can be performed by the ENN.

[0104] This document provides features associated with authentication and / or key management (AKA), for example, for (D)DOS repair. For example, (e.g., 5G) AKA (D)DOS repair may include one or more of the following operations.

[0105] The Secure Anchor Function (SEAF) can (e.g., upon receiving a registration request) determine the puzzle to be provided, for example, to rate limit (D)DOS attacks. The SEAF can generate and / or obtain (e.g., compose) cryptographic puzzles. The SEAF can bind the cryptographic puzzle to a WTRU identity (e.g., SUCI or 5G-GUTI) and / or add (e.g., optional) freshness parameters, for example, to prevent puzzle replay attacks. The SEAF can send messages with encapsulated puzzles (e.g., NAS messages).

[0106] A WTRU (e.g., the WTRU that sent the registration request) can solve the puzzle. The WTRU can generate evidence of the solved puzzle. The WTRU can, for example, send (e.g., forward) the evidence of the solved puzzle to the SEAF.

[0107] SEAF can verify proof of a puzzle solution (e.g., proof of a solved puzzle) and / or its binding to a WTRU identity (e.g., SUPI or 5G-GUTI). SEAF can initiate an authentication service (e.g., Nausf_UEAuthentication service) for example, by sending a message (e.g., Nausf_UEAuthentication_Authenticate request) to an Authentication Server Function (AUSF) after successful verification.

[0108] In the example, an AKA (D)DOS fix (e.g., a 5G AKA (D)DOS fix) may include one or more of the following operations.

[0109] SEAF can (e.g., after receiving an authentication response message from AUSF) generate and / or obtain (e.g., compose) cryptographic puzzles. SEAF can, for example, bind the cryptographic puzzles to WTRU identities (e.g., SUCI or 5G-GUTI) and / or add (e.g., optional) freshness parameters, for example, to prevent puzzle replay attacks. SEAF can send messages with encapsulated puzzles (e.g., NAS messages).

[0110] A WTRU (e.g., the WTRU that sent the registration request) can solve the puzzle. The WTRU can generate evidence of the solved puzzle. The WTRU can then forward the evidence of the solved puzzle to SEAF.

[0111] SEAF can verify proof of a puzzle solution (e.g., proof of a solved puzzle) and / or its binding to a WTRU identity (e.g., SUPI or 5G-GUTI). SEAF can follow up with an authentication request message (e.g., after successful verification).

[0112] In the example, the (D)DOS repair for the EAP-AKA' authentication process may include one or more of the following operations.

[0113] SEAF can (e.g., after receiving an EAP-Request / AKA'-Challenge message from AUSF) determine the puzzle to provide, for example, to rate limit (D)DOS attacks. SEAF can generate and / or obtain (e.g., compose) cryptographic puzzles. SEAF can, for example, bind the puzzle to a WTRU identity (e.g., SUCI or 5G-GUTI) and / or add a freshness parameter, for example, to prevent puzzle replay attacks.

[0114] SEAF can transparently forward EAP-Request / AKA'-Challenge messages, along with generated and / or acquired (e.g., composition / selection) cryptographic puzzles, to WTRUs (e.g., the WTRU that sent the registration request) in messages such as NAS messages and authentication request messages. The management entity (ME) can forward the random challenge (RAND) and authentication token (AUTN) received in the EAP-Request / AKA'-Challenge message to the Universal User Identification Module (USIM).

[0115] A WTRU (e.g., the WTRU that sent the registration request) can solve the provided cryptographic puzzle (e.g., by expending some of its computational resources). The WTRU can send an EAP-Response / AKA'-Challenge message to SEAF, for example, including evidence of the solution to the cryptographic puzzle.

[0116] The User Identity De-Hidden Function (SIDF) can verify evidence of solved puzzles. SIDF can verify the freshness of solved puzzles and / or their binding to WTRU identities (e.g., SUCI or 5G-GUTI).

[0117] SEAF can send (e.g., pass-through forward) an EAP-Response / AKA'-Challenge message to AUSF (e.g., in a Nausf_UEAuthentication_Authenticate request message).

[0118] This document provides features associated with (D)DOS repair for the PC5 secure establishment process used for 5G ProSe WTRU-to-network relay communication via the control plane. For example, (D)DOS repair for the PC5 secure establishment process may include one or more of the following operations.

[0119] SEAF can (for example, after discovering a 5G ProSe WTRU to a network relay) identify the puzzle to provide, for example, to rate limit against (D)DOS attacks.

[0120] SEAF can generate and / or obtain (e.g., compose) cryptographic puzzles. SEAF can bind cryptographic puzzles to WTRU identities (e.g., SUCI or 5G-GUTI) and / or add freshness parameters, for example, to prevent puzzle replay attacks. SEAF can send messages with encapsulated puzzles (e.g., NAS messages).

[0121] A WTRU (e.g., the WTRU that sent the registration request) can solve the puzzle. The WTRU can generate evidence of the solved puzzle. The WTRU can send (e.g., forward) the evidence of the solved puzzle to SEAF.

[0122] SEAF can verify puzzle solution evidence (e.g., evidence of a solved puzzle) and / or its binding to WTRU identity (e.g., SUPI or 5G-GUTI). SEAF can, for example, send a relay key request to the AMF of a 5G ProSe WTRU to network relay.

[0123] Edge (D)DOS repair can be performed. For example, edge (D)DOS repair may include one or more of the following operations.

[0124] Edge Configuration Server (ECS) / Edge Enabled Server (EES) can (for example, upon receiving a service provisioning request) decide to provide a puzzle, such as to rate-limit (D)DOS attacks.

[0125] ECS / EES can generate and / or obtain (e.g., compose) cryptographic puzzles. ECS / EES can (e.g., optionally) bind the cryptographic puzzles to an Edge Enabled Client (EEC) identity (e.g., ECSP ID or GPSI) and / or add (e.g., optionally) a freshness parameter, for example, to prevent puzzle replay attacks. ECS / EES can send messages with encapsulated puzzles to application clients (ACs) / EECs (e.g., ACs / EECs that sent service provision requests).

[0126] AC / EEC can solve the puzzle. AC / EEC can generate evidence of the solved puzzle and / or send (e.g., forward) evidence of the solved puzzle to ECS / EES.

[0127] ECS / EES can verify proof of a puzzle solution (e.g., proof of a solved puzzle) and / or its binding to an EEC identity (e.g., ECSP ID or GPSI). ECS can (e.g., after successful verification) perform an authorization check to verify whether the EEC is authorized to perform the operation.

[0128] (For example, a DOS and / or (D)DOS attack) Attachment remedy may include one or more of the following operations: UnEn (e.g., an unauthenticated WTRU and / or an unauthenticated device) may send an authentication request to ENN. ENN may determine an appropriate task (e.g., a puzzle). ENN may generate and / or obtain (e.g., compose / generate) the assigned task and may (e.g., optionally) bind the assigned task to an identity freshness parameter. ENN may forward the assigned task to UnEn. UnEn may complete the assigned task (e.g., the puzzle) and may forward evidence (e.g., a result) associated with completing the assigned task to ENN. ENN may compare the received result with the expected result. ENN may (e.g., if the comparison is successful, such as a portion of the received result matching a portion of the expected result) forward the authentication request from UnEn to the authentication function.

[0129] Figure 3 The signaling flow and components used for remediating example attacks are described. For example... Figure 3 As shown in section 1, UnEn (e.g., a device, WTRU, etc.) can send authentication requests to ENN (e.g., a network node).

[0130] At two points, the ENN can determine to use a puzzle to remedy a potential (D)DOS attack. Determining to remedy a potential DDoS attack can be based on a request from a core network node (e.g., a network node). For example, a core network node can indicate to the ENN that a potential DDoS attack may be underway. The core network node can make this determination after observing a relatively large number of authentication attempt failures (e.g., a network node can determine that a DDoS attack is occurring based on the number of authentication attempt failures meeting a threshold).

[0131] At point 3, ENN can generate and / or obtain (e.g., compose) puzzles and / or (e.g., optionally) bind puzzles to identities, such as UnEn identities.

[0132] At point 4, ENN can respond to UnEn with a puzzle (e.g., a puzzle from point 3).

[0133] At 5 locations, UnEn can solve puzzles (e.g., received at 4 locations). UnEn can obtain (e.g., optionally) evidence bound to UnEn's identity.

[0134] At point 6, UnEn can send an authentication request to ENN, for example, including (e.g., containing) evidence of a solved puzzle (e.g., which may optionally be bound to, for example, an UnEn identity).

[0135] At point 7, ENN can verify that the received evidence corresponds to the puzzle (e.g., from point 4, which can be bound to the UnEn identity).

[0136] At point 8, the ENN can, for example, send (e.g., forward) an authentication request to the authentication function after successful verification at point 7.

[0137] Parameters can be introduced (for example, additionally). For example, UnEn (e.g., WTRU, device, etc.) and service networks (e.g., ENN) can share common values, such as pre-configured parameters or parameters known during the subscription period.

[0138] Additional parameters can vary, for example, by SUPI or group. These parameters can be used to generate and / or obtain (e.g., compose) puzzles and / or solve puzzles. Edge nodes can (e.g., by incorporating additional parameters) develop (e.g., more) puzzle variability. For example, incorporating additional parameters can make UnEn (e.g., malicious entities such as WTRU) more difficult to solve puzzles.

[0139] This article provides features associated with puzzles (e.g., cryptographic puzzles), the corresponding elements or parameters of puzzles, different example puzzle types, and / or example operations that constitute puzzles.

[0140] A puzzle can be a request (e.g., a demand) (e.g., a brute-force attack) to reverse-engineer (e.g., any) cryptographic primitive (e.g., encryption, hash function, etc.). A puzzle can include one or more of the following: reverse engineering of encryption or reverse engineering of a one-way cryptographic hash function.

[0141] The reverse engineering of encryption can be enhanced (e.g., increasing or decreasing difficulty) by finding plaintext or a portion of plaintext (e.g., a part of plaintext) without knowledge of the encryption key, with partial key knowledge, and / or with a reduced key size. In the example, increasing or decreasing the key size and / or other parameters can adjust the strength of the puzzle and / or the amount of work / input that may be required to solve the puzzle (e.g., via a chosen puzzle strength parameter).

[0142] Processor productivity can have a significant impact on the time required to reverse-engineer the encryption. Puzzle parameters can include the key length (e.g., 128 for AES-128). In the example, the puzzle parameters can include a known key length (e.g., 120), leaving a portion of the key length (e.g., 8 bits) for brute-force attacks. In the example, the puzzle parameters can include ciphertext. The cleartext corresponding to the ciphertext can be the puzzle evidence obtained through a brute-force attack.

[0143] Figure 4An example of the configuration and assembly of a cryptographic puzzle based on reverse encryption is depicted. Figure 4 An example process can be represented (e.g., in...) Figure 3 (3 locations) generate and / or obtain (e.g., compose) puzzles.

[0144] Figure 4 An example process for configuring and / or assembling a cryptographic puzzle (e.g., one that can be triggered by an ENN) is shown. This process can be triggered if / when the ENN receives an authentication request. The ENN can determine that it can use the puzzle to remedy (e.g., a potential) DDoS attack. The ENN can trigger this process (e.g., determining to use the puzzle to remedy a potential DDoS attack) so that it can obtain the puzzle to send to the UnEn.

[0145] like Figure 4 As shown at point 1, UnEn identities can be (e.g., randomly) selected, pre-configured, and / or received in an authentication request.

[0146] At point 2, you can select anti-replay parameters (e.g., timestamp or serial number).

[0147] At point 3, you can choose a constant value string, for example, to help select the correct key during brute-force reverse encryption.

[0148] At point 4, you can select (e.g., randomly select or pre-configure) an encryption key with a strength (e.g., full strength) corresponding to the encryption function.

[0149] At point 5, a hash function can be generated and / or obtained (e.g., implemented). The hash function can bind the UnEn identity, anti-replay parameters, and / or a constant value string, for example, by encrypting one or more of them together. For example, the output from point 5 could be HASH(UnEn ID || Anti-Replay par || Constant string). If a hash function is not generated and / or obtained (e.g., implemented), the output from point 5 can be represented by one or more of the values ​​from points 1-4 (e.g., input concatenation), such as UnEn ID || Anti-Replay par || Constant string.

[0150] At position 6, the cryptographic encryption function can generate a puzzle for position 9. The cryptographic encryption function can (optionally, for example) be used to protect privacy, confidentiality, and / or prevent the evidence used for verification from being replayed. It can protect the parameters obtained at positions 1-4 from being disclosed to an untrusted UnEn.

[0151] At point 7, the results of point 5 can be retained (e.g., stored) for use in verifying evidence.

[0152] At position 8, an incomplete encryption key can be selected, for example, based on the value obtained from position 4. For instance, if the full-strength key from position 4 is 128 bits long, the key selected at position 8 could be a key with a length / strength less than 128 bits. A resulting length of 1 to 127 bits allows for adjustment of the puzzle strength and / or for reversing the input required for encryption. In the example, a portion of the key can be sent to UnEn based on the selected puzzle strength and / or the determined input used to generate the evidence (e.g., via the puzzle strength parameter).

[0153] At point 9, the puzzle can be assembled. For example, the puzzle can be assembled by concatenating encrypted text, an incomplete encryption key from point 8, and / or an optional constant from point 3.

[0154] At point 10, the assembled puzzle can be prepared to be solved by UnEn. The assembled puzzle may include (e.g., contain) encrypted text, an incomplete encryption key from point 8, a string from point 3 (e.g., known ciphertext—optional element), and / or (e.g., optionally) an UnEn identity from point 1.

[0155] The inverse of a one-way cryptographic hash function can be enhanced (e.g., by increasing or decreasing its difficulty). This paper can describe how to find the input independent variable using partial knowledge of the input hash function's independent variable. In the example, increasing and / or decreasing the ratio between the known and unknown parts of the hash function's input can adjust the strength of the puzzle and / or the entity (e.g., WTRU) to the amount of work / input that might have to be spent solving it (e.g., via a puzzle strength parameter).

[0156] RAM productivity can have a significant impact on the time required to reverse engineer a hash function.

[0157] Partially known arguments of a cryptographic hash function can be input parameters. For example, when using SHA-256 cryptographic hashing, the input string for the hash can have a total length N and a known input length Nm. The hash output can be provided as an input parameter (e.g., one of the input parameters, such as the specified length 256 for SHA-256). The puzzle can include (e.g., composed of) m unknown bits in the hash function input. It may be necessary to feed (e.g., the feed level can be determined by network nodes) to use a brute-force attack and / or discover the unknown m-bit input such that output = HASH-256 (e.g., known input || unknown input). The unknown input (e.g., in the full-length input) can be evidence.

[0158] Figure 5 Examples of configuration and / or assembly of cryptographic puzzles based on reverse cryptographic hash functions are depicted. Figure 5 Example operations can represent generating and / or obtaining (e.g., composing) puzzles (e.g., Figure 5 It can include and Figure 3 (One or more related examples in 3 places).

[0159] like Figure 5 As shown in point 1, UnEn identities can be randomly selected or pre-configured.

[0160] At point 2, anti-replay parameters (e.g., timestamp or sequence number) can be selected (e.g., the network can select anti-replay parameters).

[0161] At point 3, a hash function can be implemented. The hash function can be bound together by hashing the UnEn identity and the anti-replay parameter. For example, the output from point 3 could be HASH(UnEn ID || Anti Replay par).

[0162] At point 4, a cryptographic hash function (e.g., another cryptographic hash function) can (optionally) be used to protect privacy, confidentiality, and / or prevent the evidence used for verification from being replayed. The cryptographic hash function can, for example, protect the parameters obtained in points 1 and / or 2 from being disclosed to an untrusted UnEn.

[0163] At point 5, the expected evidence value can be saved (e.g., stored). If point 4 is not implemented, the output of point 3 can be used as expected evidence (e.g., a portion of the output of point 3 can be used as expected evidence).

[0164] At position 6, you can choose an n-bit value and / or replace the character S.

[0165] At position 7, the n bits of the output (e.g., leading, trailing, or random) can be replaced with the selected character S (e.g., from position 6).

[0166] At point 8, a puzzle to be solved by UnEn can be assembled. The puzzle output may include (for example, containing) the output of 7, (for example, optionally) the selected S character and / or the UnEn identity from 1.

[0167] This document may describe one or more operations used for puzzle solving and related processes, including (e.g., intended) methods, operations, inputs and / or outputs.

[0168] Brute-force attacks can be used to solve one or more puzzles.

[0169] Cryptographic reverse engineering puzzles can be solved, for example, by one or more of the following operations (e.g., a device can solve a cryptographic reverse engineering puzzle).

[0170] Solving cryptographic reverse puzzles can be based on brute-force operations and / or may include (e.g., including) finding plaintext and / or part of plaintext without cryptographic key knowledge, with partial key knowledge and / or with reduced key size.

[0171] Processor productivity (e.g., the processing power of a device) can have an impact (e.g., a significant impact) on the time / effort required to reverse-engineer encryption.

[0172] The process of solving one or more cryptographic reverse puzzles can be constructed around traversing one or more existing permutations of the cryptographic key (e.g., the entire cryptographic key), for example, when a portion of the cryptographic key is known.

[0173] Figure 6 Example operations for solving cryptographic reverse engineering puzzles are described.

[0174] like Figure 6 As shown at point 1, operation can begin (for example, the device can begin solving a cryptographic reverse-engineering puzzle).

[0175] At point 2, UnEn can, for example, receive the puzzle and / or corresponding parameters from ENN. For example, the puzzle and / or parameters can correspond to... Figure 4 The generated content in 10 locations (e.g., puzzles and / or parameters can be as shown in the reference) Figure 10 The puzzle output mentioned in point 4). UnEn receives puzzles that can correspond to Figure 3 Four locations in the middle (for example, the equipment can be as referenced) Figure 3 (The receiving puzzle mentioned in the four places).

[0176] At point 3, UnEn can select an initial value (e.g., the starting value of an unknown part of the encryption key). UnEn can be used with an initial value, for example, with a known part of the key.

[0177] At point 4, UnEn can execute encryption functions.

[0178] At point 5, UnEn can check whether the encryption can be brute-forced (e.g., whether the plaintext to be brute-forced includes (e.g., contains) the corresponding...). Figure 4 (The three input fields contain optional known plaintext text).

[0179] At point 6, if the encryption is not brute-forced, UnEn can increment the unknown part of the key and / or use that part together with the known part to try brute-forcing the encryption again at point 4.

[0180] At point 7, if the encryption is brute-forced, the evidence can include (for example, consisting of) the decrypted (i.e., brute-forced) encrypted text. UnEn can send evidence to ENN. Sending evidence can correspond to... Figure 3 There are 6 locations in the middle.

[0181] The operation can be completed at point 8.

[0182] Solving a one-way cryptographic hash function (e.g., SHA-256) inverse puzzle can be based on brute-force operations and / or may include (e.g., including) using (e.g., only) partial input hash function argument knowledge to find the complete hash function input text. In the example, solving a one-way cryptographic hash function inverse puzzle may include finding a portion of the hash function input text based on partial input hash function argument knowledge. Increasing / decreasing the ratio between the known and unknown parts of the hash function input can adjust the puzzle strength and entity (e.g., WTRU) of the amount of work / input that may have to be spent solving it (e.g., via a puzzle strength parameter).

[0183] RAM productivity can have a significant impact on the time required to reverse-engineer a hash function (e.g., to solve a one-way cryptographic hash function).

[0184] Partially known arguments of a cryptographic hash function can be input parameters. For example, when using SHA-256 cryptographic hashing, the input string to the hash can include (e.g., having) a total length N and a known input length Nm. The hash output can be provided as an input parameter (e.g., one of the input parameters, such as the specified length 256 for SHA-256). The puzzle can include (e.g., containing) m unknown bits in the input of the hash function. A brute-force attack can be requested to solve (e.g., to discover) the unknown m bits in the input such that the output = HASH-256(known input || unknown input). Evidence generated during the process of solving the puzzle can include (e.g., containing) the full-length hash input.

[0185] Figure 7 Example operations for solving hash function inversion puzzles are described.

[0186] like Figure 6 As shown at point 1 in the diagram, the method can begin.

[0187] At point 2, UnEn can, for example, receive the puzzle and / or corresponding parameters from ENN. For example, the puzzle and / or parameters can correspond to... Figure 5 The content generated in the 8 locations (e.g., puzzles and / or parameters can be as shown in the reference) Figure 5 (As mentioned in point 8). The UnEn receiving puzzle can correspond to... Figure 3 There are 4 locations in the middle.

[0188] At point 3, UnEn can select an initial value (e.g., the starting value for the unknown part of the hash input). UnEn can use the initial value with the known part of the hash input.

[0189] At point 4, UnEn can execute a hash function.

[0190] At point 5, UnEn can check whether the hash can be brute-forced (e.g., whether the hash output corresponds to the entire hash input and / or a portion of the hash input to be solved).

[0191] At point 6, if the hash is not brute-forced, UnEn can increment the unknown part of the hash input and / or use that part together with the known part to try brute-forcing the hash again at point 4.

[0192] At point 7, if the hash is brute-forced, the evidence can include (e.g., containing) the solved (e.g., brute-forced) complete hash input text (e.g., or a solved portion of the input text). UnEn can send evidence to ENN. Sending evidence can correspond to... Figure 3 There are 6 locations in the middle.

[0193] The operation can be completed at point 8.

[0194] ENN can process evidence received from UnEn. UnEn can solve puzzles and / or recover evidence (e.g., ...). Figure 6 and Figure 7 As shown). If the evidence (e.g., recovered plaintext) matches the UnEn identity and / or replay prevention parameters (e.g., see...) Figure 4 and Figure 5 If an identity is bound to another UnEn, then it can (e.g., still) be bound to the UnEn identity and can be replay resistant (e.g., another entity cannot present the evidence and / or the evidence cannot be replayed by the same UnEn or a different UnEn).

[0195] Figure 8 Example operations for processing evidence received from UnEn (e.g., by ENN) are described. ENN can process evidence parameters received from UnEn (e.g., corresponding to...). Figure 3 (7 locations in the middle).

[0196] like Figure 8 As shown, you can start the operation at point 1.

[0197] At point 2, ENN can receive evidence from UnEn (e.g., Figure 3 (6 locations in the middle).

[0198] In three places, ENN can retrieve the saved expected evidence (e.g., Figure 4 7 places or Figure 5 (5 locations in the middle).

[0199] At point 4, the ENN can compare the received evidence with the expected evidence. If the comparison is successful (e.g., a portion of the received evidence matches a portion of the expected evidence), the ENN can proceed to point 5. A violation of UnEn binding and / or replay protections may result in the UnEn submitting evidence not being equal to the expected evidence (e.g., and / or the UnEn being rejected for further processing of the UnEn authentication request).

[0200] At point 5, ENN allows for further processing of UnEn authentication requests.

[0201] At point 6, exception handling can be performed, for example, if the evidence does not equal the expected evidence. Exception handling may include sending an additional message to UnEn or silently discarding the authentication request (e.g., ending the process). Figure 3 (6 locations in the middle).

[0202] The operation can be completed at point 7.

[0203] An ENN (e.g., a network node) can perform one or more of the following actions.

[0204] ENN can receive authentication requests from UnEn (e.g., as referenced). Figure 3 (As described in section 1). The request may include UnEn's identity.

[0205] ENN can determine the procedures to be performed for rate limiting and / or mitigation of (D)DoS attacks (e.g., as referenced). Figure 3 (As described in section 2). This determination can be based on a request from a core network node.

[0206] ENNs can determine puzzles (e.g., as referenced). Figure 3 2 places in the middle Figure 4 or Figure 5 The puzzle may include encrypted text, incomplete encryption keys, and / or strings.

[0207] ENN can send puzzles to UnEn (e.g., as referenced) Figure 3 (As mentioned in 4 places in the middle).

[0208] ENN can receive a second authentication request from UnEn (e.g., as referenced). Figure 3 (As described in section 6). The second authentication request may include evidence.

[0209] ENN can determine to send a second authentication request to the authentication function based on evidence of a correct solution to the puzzle (e.g., as referenced). Figure 3 (As mentioned in sections 7 and 8).

[0210] UnEn can perform one or more of the following actions.

[0211] UnEn can send authentication requests to the network (e.g., as referenced). Figure 3 (As described in section 1). The request may include UnEn's identity.

[0212] UnEn can receive puzzles from the network (e.g., as referenced). Figure 3 (As described in section 4). Puzzles may include encrypted text, incomplete encryption keys, and / or strings.

[0213] UnEn can provide evidence for solving the puzzle (e.g., as seen in references). Figure 3 5 places and / or Figure 5 (as described).

[0214] UnEn can send a second authentication request to the network (e.g., as referenced). Figure 3 (As described in section 6). The second authentication request may include evidence.

[0215] This document describes AIoT(D)DOS repair in the context of EAP-guided operation via a control plane of a (e.g., cellular) network. For example, (D)DOS repair in the context of EAP-guided operation can be performed via an intermediate node.

[0216] (D) DOS protection can be applied to AIoT devices that interact with intermediate nodes (e.g., WTRU or RAN). Figure 9 An example of AIoT (D)DOS repair is depicted in the context of EAP guidance via the control plane of a (e.g., cellular) network.

[0217] like Figure 9 As shown in section 1, AIoT devices can (for example, in the context of EAP guidance via the control plane of a cellular network) send service request messages to intermediate nodes.

[0218] At point 2, the intermediate node can determine which puzzle to provide (e.g., to an AIoT device) to fix a DOS / DDOS attack.

[0219] At point 3, intermediate nodes can generate and / or acquire (e.g., compose) puzzles (e.g., with freshness parameters that can prevent impersonation of AIoT device identities and / or prevent other entities from replaying evidence). This can be achieved, for example, by creating individual one-time puzzles and / or time-limited puzzles (e.g., through short lifespan parameters) (e.g., preventing impersonation and / or preventing replaying evidence). In the example, network nodes can generate puzzles based on WTRU identities and / or based on time-limited time periods.

[0220] At point 4, the intermediate node can send the selected puzzle to the AIoT device.

[0221] In five locations, AIoT devices can solve puzzles and generate evidence.

[0222] At point 6, AIoT devices can send (e.g., forward) evidence corresponding to the solved puzzle to intermediate nodes.

[0223] At point 7, intermediate nodes can analyze and verify evidence corresponding to the solved puzzle. Intermediate nodes can (e.g., after successful verification) allow progression to point 8.

[0224] In can be with Figure 4 Locations 8 to 13, corresponding to locations 1 to 6, include EAP guidance via the control plane of a (e.g., cellular) network.

[0225] 5G AKA (D)DOS repair can be performed (e.g., based on using cryptographic puzzles to initiate the authentication process and / or select the authentication method).

[0226] Figure 10 An example of a 5G AKA (D)DOS repair operation is depicted.

[0227] like Figure 10 As shown at point 1, WTRU (e.g., UnEn) can initiate a registration request (e.g., to SEAF) using, for example, SUCI or 5G-GUTI in the registration request.

[0228] At point 2, SEAF can determine to provide (e.g., send) a puzzle (e.g., to WTRU) to rate-limit (D)DOS attacks.

[0229] At point 3, SEAF can generate and / or obtain (e.g., compose) cryptographic puzzles. SEAF can, for example, bind the cryptographic puzzles to WTRU identities (e.g., via SUCI or 5G-GUTI) and / or add freshness parameters to prevent puzzle replay attacks.

[0230] At point 4, SEAF can send NAS messages with encapsulated puzzles.

[0231] At 5 locations, WTRU can solve puzzles and / or generate evidence of solved puzzles.

[0232] At point 6, WTRU can send (e.g., forward) evidence of the solved puzzle to SEAF.

[0233] At 7 locations, SEAF can verify puzzle solution evidence (e.g., evidence of a solved puzzle) and / or its binding to WTRU identity (e.g., SUPI or 5G-GUTI).

[0234] At point 8, after successful verification at point 7, the SEAF can (e.g., when the SEAF wishes to initiate authentication) initiate an authentication service (e.g., the Nausf_UEAuthentication service) by sending an authentication request (e.g., a Nausf_UEAuthentication_Authenticate request message) to the AUSF. If the SEAF is unaware of SUPI, it can include SUCI.

[0235] At point 9, a Nudm_UEAuthentication_Get request can be sent from AUSF to UDM.

[0236] At point 10, the UDM (e.g., after receiving a Nudm_UEAuthentication_Get request) can invoke the SIDF if it receives n. Before the UDM processes the request, the SIDF can remove the hidden SUCI to obtain the SUPI. The UDM and / or ARPF can, for example, select the authentication method based on the SUPI.

[0237] 5G AKA (D)DOS repair may include one or more of the following operations.

[0238] Figures 11A to 11B An example of a 5G AKA (D)DOS repair operation is depicted.

[0239] like Figure 11A As shown in sections 1 to 5, an authentication process (e.g., for 5G AKA) can be performed.

[0240] At 6 locations, SEAF can identify puzzles to rate-limit (D)DOS attacks.

[0241] At point 7, SEAF can generate and / or obtain (e.g., compose) cryptographic puzzles. SEAF can bind cryptographic puzzles to WTRU identities (e.g., SUCI or 5G-GUTI) and / or add freshness parameters, for example, to prevent puzzle replay attacks.

[0242] At point 8, SEAF can send messages with puzzles (e.g., encapsulated puzzles) to WTRU (e.g., NAS messages).

[0243] At 9 locations, WTRU can solve puzzles and generate evidence of solved puzzles.

[0244] At point 10, WTRU can send (e.g., forward) evidence of the solved puzzle to SEAF.

[0245] At point 11, SEAF can verify evidence of a puzzle solution (e.g., evidence of a solved puzzle) and / or its binding to a WTRU identity (e.g., SUPI or 5G-GUTI). Operation can proceed to point 12 after successful verification at point 11.

[0246] At points 12 to 18, the certification process for 5G AKA can be performed.

[0247] In the example, 8 to 10 and / or 12 to 14 can be combined / overlapped (e.g., for simplicity).

[0248] (D)DOS fixes can be performed for the EAP-AKA' authentication process, for example, based on the use of one or more cryptographic puzzles in the EAP-AKA' authentication process.

[0249] Figures 12A to 12B An example (D)DOS repair operation is depicted for the EAP-AKA' certification process.

[0250] like Figure 12A As shown at point 1, UDM / ARPF can generate an authentication vector (e.g., with the authentication management field delimiter bit = 1). UDM / ARPF can (e.g., then) compute CK' and IK' (e.g., according to normative Annex A) and / or replace CK and IK with CK' and IK'.

[0251] At point 2, the UDM may (e.g., subsequently) send a transformed authentication vector AV' (e.g., RAND, AUTN, XRES, CK', IK') and / or an indication that AV' can be used for EAP-AKA' to the AUSF (e.g., from which it receives a Nudm_UEAuthentication_Get request) using a Nudm_UEAuthentication_Get response message.

[0252] The exchange of Nudm_UEAuthentication_Get request and response messages between AUSF and UDM / ARPF can be similar to trusted access using EAP-AKA (e.g., identical) (e.g., except that the input parameter for key derivation can be the network name, e.g., ...).<network name> The network name can be carried in the AT_KDF_INPUT attribute of 'EAP-AKA'. The network name (e.g.,<network name> The value of the parameter can be defined in the 3GPP specification. For example, for EPS, the network name can be defined as the access network identity. For example, for 5G, the network name can include (for example, defined as) the serving network name.

[0253] If SUCI is included in the Nudm_UEAuthentication_Get request, then UDM can include SUPI in the Nudm_UEAuthentication_Get response.

[0254] If the subscriber has an AKMA subscription, the UDM can include an AKMA indication and / or a routing indicator in the Nudm_UEAuthentication_Get response.

[0255] At point 3, AUSF can send an EAP-Request / AKA'-Challenge message to SEAF in the Nausf_UEAuthentication_Authenticate response message.

[0256] At four locations, SEAF can identify puzzles to rate-limit (D)DOS attacks.

[0257] At point 5, SEAF can generate and / or obtain (e.g., compose) cryptographic puzzles. SEAF can bind cryptographic puzzles to WTRU identities (e.g., SUCI or 5G-GUTI) and / or add freshness parameters (e.g., to prevent puzzle replay attacks).

[0258] At point 6, the SEAF can send (e.g., pass-through forwarding) an EAP-Request / AKA'-Challenge message to the WTRU in a NAS message authentication request message with a selected cryptographic puzzle. The ME can forward the RAND and AUTN received in the EAP-Request / AKA'-Challenge message to the USIM. This message may include the ngKSI and / or ABBA parameters. The SEAF can include the ngKSI and / or ABBA parameters (e.g., only in the EAP authentication request message). The ngKSI can be used by the WTRU and / or AMF to identify the partially native security context created upon successful authentication. The SEAF can set the ABBA parameter. The values ​​of the ngKSI and / or ABBA parameters sent by the SEAF to the WTRU during EAP authentication may remain unchanged.

[0259] SEAF can (for example, needs to) understand that the authentication operation used is an EAP operation, for example, by evaluating the type of authentication operation based on the Nausf_UEAuthentication_Authenticate response message.

[0260] At point 7, USIM can (for example, after receiving RAND and AUTN) verify the freshness of AV' by checking whether AUTN is acceptable.

[0261] The USIM can (e.g., if AUTN is acceptable) calculate the response RES. The USIM can return RES, CK, and IK to the ME. If the USIM calculates Kc (e.g., GPRS Kc) from CK and IK (e.g., using the conversion function c3) and / or sends it to the ME, the ME can (e.g., then) ignore this GPRS Kc and not store it on the USIM or in the ME. The ME can derive CK' and IK'.

[0262] USIM and ME can continue (e.g., if AUTN verification on USIM fails).

[0263] At point 8, WTRU can solve the provided cryptographic puzzles (e.g., by expending some of its computational resources).

[0264] At point 9, WTRU can send an EAP-Response / AKA'-Challenge message to SEAF in the NAS message Auth-Resp message, including evidence of the solution to the cryptographic puzzle.

[0265] At 10 locations, SIDF verifies evidence of the solved puzzle (e.g., optionally), its freshness, and / or its binding to a WTRU ID (e.g., SUCI or 5G-GUTI).

[0266] At point 11, SEAF can send (e.g., pass-through forward) the EAP-Response / AKA'-Challenge message to AUSF in the Nausf_UEAuthentication_Authenticate request message.

[0267] At point 12, AUSF can verify the message by comparing XRES and RES. If AUSF has successfully verified the message, it can proceed to point 13. Otherwise, AUSF can return an error to SEAF. AUSF can then notify UDM of the authentication result.

[0268] At point 13, AUSF and WTRU can exchange EAP-Request / AKA'-Notification and EAP-Response / AKA'-Notification messages (e.g., via SEAF). SEAF can send (e.g., pass-through forward) these messages.

[0269] EAP notifications and / or EAP-AKA notifications can be used at any time during EAP-AKA exchanges. These notifications can be used, for example, to indicate protected results and / or when the EAP server detects an error in a received EAP-AKA response.

[0270] At point 14, the AUSF can derive the EMSK from CK' and IK'. The AUSF can use the most significant 256 bits of the EMSK as the KAUSF and / or can compute the KSEAF from the KAUSF. The AUSF can send an EAP success message to the SEAF within the Nausf_UEAuthentication_Authenticate response, which the SEAF can then pass-through and forward to the WTRU. The Nausf_UEAuthentication_Authenticate response message can include the KSEAF. If the AUSF receives a SUCI from the SEAF at the time of authentication initiation, the AUSF can include a SUPI in the Nausf_UEAuthentication_Authenticate response message. The AUSF can store the KAUSF based on the home network operator's policy.

[0271] Sending a SUPI from the AUSF to the SEAF may occur (e.g., it may be necessary for legitimate interception) but may not be sufficient. By including the SUPI as an input parameter for key derivation from the KSEAF to derive the KAMF, the serving network can provide additional guarantees for the correctness of the SUPI from the home network and / or WTRU side.

[0272] At point 15, SEAF can send an EAP success message to WTRU in the N1 message. This message can also include the ngKSI and / or ABBA parameters. SEAF can set the ABBA parameter.

[0273] It can perform (D)DOS repair for the PC5 security establishment process used for 5G ProSe WTRU to network relay communication via the control plane.

[0274] Message 2 from the remote WTRU to the relay WTRU may be subject to a DDoS attack. Techniques to slow down and / or mitigate DDoS attacks can be used after message 2 (e.g., providing a puzzle in 2a, the WTRU solving the puzzle in 2b, and / or the remote WTRU allowing message 3a (e.g., only when the puzzle is solved)).

[0275] Figures 13A to 13E An example (D)DOS fix is ​​described for the PC5 security establishment process used for 5G ProSe WTRU to network relay communication via the control plane.

[0276] like Figure 13AAs shown at point 0, a 5G ProSe remote WTRU and / or a 5G ProSe WTRU to network relay can register with the network. A 5G ProSe WTRU to network relay can be authenticated and / or authorized by the network to provide WTRU to network relay services. A 5G ProSe remote WTRU can be authenticated and / or authorized by the network to receive WTRU to network relay services. During this authorization and information configuration process, PC5 security policies can be configured (e.g., provided) separately for the 5G ProSe remote WTRU and / or the 5G ProSe WTRU to network relay.

[0277] At point 1, a 5G ProSe remote WTRU or relay WTRU can initiate a discovery process using an operation (e.g., any method, such as Model A or Model B operation). If the remote WTRU receives an NCGI from the relay WTRU, it can (e.g., temporarily) store the NCGI.

[0278] At point 2, after discovering the 5G ProSe WTRU to the network relay, the 5G ProSe remote WTRU can send a direct communication request to the 5G ProSe WTRU to the network relay (e.g., to establish a secure PC5 unicast link). The 5G ProSe remote WTRU can include security capabilities (e.g., its security features) and / or PC5 signaling security policies in the DCR message. This message can (e.g., also) include the relay service code and Nonce_1.

[0279] If the 5G ProSe remote WTRU does not have a valid 5G ProSe remote user key (CP-PRUK), the 5G ProSe remote WTRU can include a SUCI in the DCR to trigger 5G ProSe remote WTRU-specific authentication and / or establish the CP-PRUK.

[0280] If the 5G ProSe remote WTRU (e.g., already has) a valid CP-PRUK for the relay service code, the 5G ProSe remote WTRU can include the associated CP-PRUK ID in the DCR to indicate that the 5G ProSe remote WTRU wants to obtain (e.g., request to obtain) a relay connection using the CP-PRUK. Privacy and / or integrity protections of the DCR can be used.

[0281] At three points, SEAF can determine that it provides puzzles to rate-limit (D)DOS attacks.

[0282] At point 4, SEAF generates and / or obtains (e.g., composes) cryptographic puzzles, (e.g., optionally) binds them (e.g., the puzzles) to WTRU identities (SUCI or 5G-GUTI), and / or adds optional freshness parameters to prevent puzzle replay attacks.

[0283] At point 5, SEAF can send NAS messages with encapsulated puzzles.

[0284] At 6 locations, WTRU can solve the puzzle and generate evidence of the solved puzzle.

[0285] At point 7, WTRU can send (e.g., forward) evidence of the solved puzzle to SEAF.

[0286] At 8 locations, SEAF can verify puzzle solution evidence (e.g., evidence of a solved puzzle) and / or its binding to WTRU identity (SUPI or 5G-GUTI).

[0287] like Figure 13B As shown, at point 9, after receiving the DCR message, the 5G ProSe WTRU to Network Relay can send a relay key request to the AMF of the 5G ProSe WTRU to Network Relay, including the SUCI or CP-PRUKID, RSC, and Nonce_1 received in the DCR message. The 5G ProSe WTRU to Network Relay can also include a transaction identifier in the message (e.g., which identifies the 5G ProSe remote WTRU for subsequent messages via the NAS message of the 5G ProSe WTRU to Network Relay).

[0288] At 10 locations, the AMF of the 5G ProSe WTRU to network relay can verify with the UDM whether the 5G ProSe WTRU to network relay can be authorized to provide WTRU to network relay services.

[0289] At point 11, the AMF of the 5G ProSe WTRU to network relay can select an AFS based on the SUCI or CP-PRUK ID, and forward the parameters received in the relay key request to the AFS in the Nausf_UEAuthentication_ProseAuthenticate request message. The Nausf_UEAuthentication_ProseAuthenticate request message may include (e.g., contain) the SUCI or CP-PRUK ID of the 5G ProSe remote WTRU, the relay service code, Nonce_1, and / or the service network name of the 5G ProSe WTRU to network relay. If the CP-PRUK ID is received from the AMF of the 5G ProSe WTRU to network relay, the AFS of the 5G ProSe remote WTRU may (e.g., temporarily) store the Nonce_1 and can skip points 6 to 9. If the SUCI of the 5G ProSe WTRU is received from the AMF of the 5G ProSe WTRU to network relay, the AFS of the 5G ProSe remote WTRU may (e.g., temporarily) store the Nonce_1 and the relay service code and can skip point 10.

[0290] AUSF can obtain (e.g., receive and / or acquire) the routing indicator of the 5G ProSe remote WTRU from its SUCI or CP-PRUK ID, and can (e.g., temporarily) store the routing indicator.

[0291] At point 12, the AUSF of the 5G ProSe remote WTRU can initiate 5G ProSe remote WTRU (e.g., specific) authentication using received ProSe (e.g., specific) parameters (e.g., RSC, etc.). The serving network name can be handled, for example, as described herein.

[0292] The AUSF of a 5G ProSe remote WTRU can retrieve the AV from the UDM via a Nudm_UEAuthentication_GetProseAv request message. The AUSF can include the service network name of the 5G ProSe WTRU to network relay in the Nudm_UEAuthentication_GetProseAV request message. Upon receiving the Nudm_UEAuthentication_GetProseAv request, the UDM can invoke the SIDF to hide the SUCI to obtain the SUPI (e.g., before the UDM processes the request). The UDM can check whether the WTRU is authorized to use the ProSe WTRU to network relay service based on the authorization information in the WTRU subscription data. If the WTRU is authorized, the UDM can select the EAP-AKA authentication operation based on the received Nudm_UEAuthentication_GetProseAv request. The UDM can (e.g., then) generate an EAP-AKA authentication vector for ProSe and / or send a Nudm_UEAuthentication_GetProseAv response with the AV and SUPI to the AUSF.

[0293] At 13a, the AUSF of the 5G ProSe remote WTRU can (e.g., temporarily) store XRES and SUPI. The AUSF of the 5G ProSe remote WTRU can trigger authentication of the 5G ProSe remote WTRU based on EAP-AKA'. The AUSF of the 5G ProSe remote WTRU can generate an EAP-Request / AKA'-Challenge message and / or send the EAP-Request / AKA'-Challenge message to the AMF of the 5G ProSe WTRU to the network relay in a Nausf_UEAuthentication_ProSeAuthenticate response message.

[0294] At 13b, the AMF of the 5G ProSe WTRU to network relay can forward relay authentication requests (e.g., including EAP-Request / AKA'-Challenge) to the 5G ProSe WTRU to network relay via NAS messages, for example, including the transaction identifier of the 5G ProSe remote WTRU in the message. NAS messages can be protected using the NAS security context created for the 5G ProSe WTRU to network relay.

[0295] At 13c, based on the transaction identifier, the 5G ProSe WTRU to the network relay can send (e.g., forward) EAP-Request / AKA'-Challenge to the 5GProSe remote WTRU via PC5 messages.

[0296] The USIM in a 5G ProSe remote WTRU can verify the freshness of the received value by checking whether the AUTN is acceptable.

[0297] For EAP-AKA', USIM can calculate the response RES. USIM can then return RES, CK, and IK to ME. ME can then derive CK' and IK'.

[0298] If the remote WTRU requests (e.g., requires) network name verification (e.g., difference comparison) and / or receives an NCGI from the relay WTRU at point 1, the remote WTRU can perform verification using the SNN information received in the EAP-Request / AKA'-Challenge and / or the SN ID information in the NCGI. If verification fails, the remote WTRU can abort authentication. If the remote WTRU does not receive an NCGI from the relay, the remote WTRU can skip network name verification.

[0299] At 13d, the 5G ProSe remote WTRU can return EAP-Response / AKA'-Challenge to the 5G ProSe WTRU to the network relay via PC5 messages.

[0300] At 13e, the 5G ProSe WTRU to network relay can send (e.g., forward) the EAP-Response / AKA'-Challenge and the transaction identifier of the 5G ProSe remote WTRU to the AMF of the 5G ProSe WTRU to network relay in the NAS message relay authentication response.

[0301] At 13f, the AMF of the 5G ProSe WTRU to the network relay can send (e.g., forward) EAP-Response / AKA'-Challenge to the ASF of the 5G ProSe remote WTRU via the Nausf_UEAuthentication_ProSeAuthenticate request.

[0302] The AUSF of the 5G ProSe remote WTRU can perform WTRU authentication by verifying the received information.

[0303] For EAP-AKA', the AUSF of the 5G ProSe remote WTRU and the 5G ProSe remote WTRU can exchange EAP-Request / AKA'-Notification and EAP-Response / AKA'-Notification messages via the AMF of the 5G ProSe WTRU to the network relay and the 5G ProSe WTRU to the network relay. After the exchange, the AUSF of the 5G ProSe remote WTRU and / or the 5G ProSe remote WTRU can use the highest valid 256 bits of the EMSK as KAUSF_P in a similar manner to obtaining KAUSF for EAP-AKA' (e.g., the same manner).

[0304] At point 14, after successful authentication, the AUSF of the 5G ProSe remote WTRU and / or the 5G ProSe remote WTRU can generate a CP-PRUK as specified in the CP-PRUK ID.

[0305] The CP-PRUK ID can be in NAI format (e.g., username@realm). The username portion can include a routing indicator from 5 and the CP-PRUK ID. The domain portion may include the home network identifier. CP-PRUK ID It can be regulated.

[0306] At 15a, the AUSF of the 5G ProSe remote WTRU can select the PAnF (ProSe Anchor Function) based on the CP-PRUK ID, and sends SUPI, RSC, CP-PRUK, and / or the CP-PRUK ID to the PAnF in the Npanf_ProseKey_Register request message. The PAnF can be selected based on the routing indicator in the CP-PRUK ID.

[0307] At 15b, PAnF can store ProSe context information (e.g., SUPI, RSC, CP-PRUK, CP-PRUK ID) for 5G ProSe remote WTRU and / or send an Npanf_ProseKey_Register response message to AUSF.

[0308] At 16a, the AUSF of the 5G ProSe remote WTRU can select PAnF based on the CP-PRUK ID and / or send the received CP-PRUK ID and RSC in the Npanf_ProseKey_get request message. PAnF can be selected based on the routing indicator in the CP-PRUK ID.

[0309] At 16b, the PAnF can retrieve the CP-PRUK based on the CP-PRUK ID and can check whether the 5G ProSe remote WTRU is authorized to use the WTRU-to-network relay service based on the received RSC (e.g., the PAnF can use the Nudm_SDM operation to use SUPI and UDM to check whether the remote WTRU is authorized to use the ProSe WTRU-to-network or WTRU-to-network relay service). If the ProSe remote WTRU (e.g., the 5G ProSe remote WTRU) is authorized and / or the retrieved CP-PRUK is valid, the PAnF can send an Npanf_ProseKey_get response message with the CP-PRUK to the AUSF.

[0310] If the CP-PRUK is obsolete, PAnF can treat it as invalid based on a policy such as (e.g., local). When an Npanf_ProseKey_get request is received, PAnF can respond that the CP-PRUK was not found.

[0311] like Figure 13D As shown, at position 17, the AUSF of the ProSe remote WTRU can generate Nonce_2, and derive the KNR_ProSe key using CP-PRUK, Nonce_1, and Nonce_2.

[0312] At point 18, the AUSF of the ProSe remote WTRU can send KNR_ProSe, Nonce_2 to the ProSe WTRU to network relay via the AMF of the ProSe WTRU to network relay in the Nausf_UEAuthentication_ProseAuthenticate response message. If step 7 (e.g., puzzle solving) is successfully executed, an EAP success message can be included. The AUSF of the ProSe remote WTRU can also include the CP-PRUK ID in the message.

[0313] At point 19, when the AMF of the ProSe WTRU to network relay receives KNR_ProSe from the ASF of the 5G ProSe remote WTRU, the ProSe WTRU to network relay can derive the PC5 session key Krelay-sess, the confidentiality key Krelay-enc (e.g., if applicable), and / or the integrity key Krelay-int from KNR_ProSe. The KNR_ProSe ID and / or Krelay-sess ID can be established similarly to (e.g., in the same manner as) the KNRP ID and KNRP-sess ID. The CP-PRUKID can be sent from the AMF of the ProSe WTRU to network relay to the WTRU to network relay. If an EAP success message is received from the ASF, that EAP success message can (e.g., also) be sent from the AMF of the ProSe WTRU to network relay to the WTRU to network (e.g., UE to network) relay.

[0314] At point 20, the ProSe WTRU to network relay can send the received Nonce_2 and the PC5 signaling security policy of the 5G ProSe remote WTRU to the ProSe remote WTRU in a direct security mode command message (e.g., which can use Krelay-int for integrity protection). If an EAP success message is received from the AMF of the ProSe WTRU to network relay, the EAP success message can be included.

[0315] At point 21, the 5G ProSe remote WTRU can generate a KNR_ProSe key (e.g., as defined in 11) to be used for remote access to the network relay via the ProSe WTRU. The ProSe remote WTRU can derive the PC5 session key Krelay-sess and / or confidentiality and integrity key (e.g., as defined in 13) from the KNR_ProSe.

[0316] ProSe remote WTRU can verify Direct Secure Mode command messages. Successful verification of Direct Secure Mode command messages assures the ProSe remote WTRU that it can be authorized to provide relay services to the network trunk.

[0317] At point 22, the ProSe remote WTRU can send a direct security mode completion message to the ProSe WTRU to network relay, including (e.g., containing) its PC5 user plane security policy, which can be protected by Krelay-int or / and Krelay-enc derived from Krelay-sess, based on the PC5 signaling policy negotiated between the ProSe remote WTRU and the ProSe WTRU to network relay.

[0318] At point 23, based on the receipt of the Direct Security Mode Completion message, the ProSe WTRU to Network Relay can verify the Direct Security Mode Completion message. Successful verification of the Direct Security Mode Completion message enables the 5G ProSe WTRU to Network Relay to determine that the ProSe remote WTRU is authorized to obtain (e.g., retrieve and / or acquire) relay services.

[0319] After successful message verification in direct security mode, the ProSe WTRU to network relay can respond to the ProSe remote WTRU with direct communication to complete the PC5 connection establishment process, and store the CP-PRUK ID in the security context associated with the PC5 link of the ProSe remote WTRU.

[0320] At point 24, when the conditions for sending a remote WTRU report are met, the ProSe Layer 3 WTRU to Network Relay can send a remote WTRU report (e.g., remote user ID, remote WTRU information, etc.) message to the ProSe WTRU to Network Relay's SMF. The ProSe Layer 3 WTRU to Network Relay can include the remote user ID (e.g., the CP-PRUKID received in point 13) in the message.

[0321] At point 25, if the mapping between the remote user ID and the SUPI of the ProSe remote WTRU is not available in the ProSe WTRU to network relay SMF, the ProSe WTRU to network relay SMF can discover the PAnF of the ProSe remote WTRU based on the remote user ID (e.g., CP-PRUKID) and can send a remote user ID resolution request to the PAnF in the Npanf_ResolveRemoteUserId_Get request message, which includes the remote user ID of the 5G ProSe remote WTRU.

[0322] The PAnF of the ProSe remote WTRU can send a remote user ID resolution response to the SMF of the ProSe WTRU to network relay in the Npanf_ResolveRemoteUserId_Get response message, which includes the SUPI of the ProSe remote WTRU.

[0323] The SMF of a ProSe WTRU to network trunk can store the remote user ID, the SUPI of the ProSe remote WTRU, and remote WTRU information in the SM context of the PDU session associated with the trunk. The SMF can send remote WTRU report acknowledgment messages to the ProSe WTRU to network trunk.

[0324] In the example, communication between the ProSe remote WTRU and the network can be securely relayed to the network via the ProSe WTRU.

[0325] If a ProSe remote WTRU receives a direct connection rejection from the ProSe WTRU to network trunk due to the CP-PRUKID not being found in the network, the ProSe remote WTRU may not attempt to reconnect to the ProSe WTRU to network trunk using the CP-PRUKID. The ProSe remote WTRU may instead attempt to connect to the ProSe WTRU to network trunk using its SUCI.

[0326] If the PAnF fails to find the ProSe context information corresponding to the received CP-PRUK ID for the ProSe remote WTRU, the PAnF can detect the absence of the CP-PRUK ID. The ProSe WTRU to network relay can learn of this situation via the AUSF of the 5G ProSe remote WTRU and the AMF of the ProSe WTRU to network relay.

[0327] Edge (D)DOS repair can be performed (e.g., based on initiating edge access using cryptographic puzzles).

[0328] Figure 14 The example edge service provides requests and responses.

[0329] like Figure 14 As shown at point 1, the EEC can send a service provision request to the ECS / EES. The service provision request may include security credentials received by the EEC during the EEC authorization process and may include WTRU identifiers, such as GPSI, connectivity information, WTRU location, EEC service continuity support, and AC profile information. The EEC may include its requested ECSP identifier in the service provision request based on EEC preferences.

[0330] At two points, ECS / EES can determine the puzzle to rate-limit (D)DOS attacks.

[0331] At three points, ECS / EES generates and / or acquires (e.g., composes) cryptographic puzzles. ECS / EES can bind the cryptographic puzzles to EEC identities (e.g., ECSP ID or GPSI) and / or add freshness parameters to prevent puzzle replay attacks.

[0332] At point 4, ECS / EES can send messages with puzzles (e.g., encapsulated puzzles).

[0333] At 5 locations, AC / EEC can solve the puzzle and generate evidence of the solved puzzle.

[0334] At point 6, AC / EEC can send (e.g., forward) evidence of the solved puzzle to ECS / EES.

[0335] At 7 locations, SEAF can verify puzzle solution evidence (e.g., evidence of a solved puzzle) and / or its binding to WTRU identity (e.g., ECSP ID or GPSI).

[0336] At point 8, after completing the checks (e.g., verifying that the evidence for the solved puzzle is similar to the solution), the ECS can perform an authorization check to verify whether the EEC has the authorization to perform the operation.

[0337] At point 9, if the request is successfully processed, the ECS / EES can respond to the EEC's request with a service provision response. If the ECS has identified the relevant EES information, the service provision response may include a list of EDN configuration information (e.g., the EDN identifier, the EDN service area, and the requested (e.g., required) information (e.g., URI, IP address) for establishing a connection with an NF that the AC / EEC can access).

[0338] Although the above features and elements are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in a variety of combinations with other features and elements or without other features and elements.

[0339] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and can be applied to other wireless systems. For example, while the schemes described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the schemes described herein are not limited to this scenario and can also be applied to other wireless systems.

[0340] The above processes can be implemented in computer programs, software, and / or firmware incorporated into computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as optical disc (CD)-ROM discs and / or digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A network node, comprising: The processor is configured as follows: Receive service request messages from the Wireless Transmit / Receive Unit (WTRU); The puzzle is generated based on the service request message; Send a service message response to the WTRU, wherein the service message response includes an indication of the puzzle; Receive an evidence request message that includes an indication of evidence, wherein the evidence is associated with a solution to the puzzle; The solution to the puzzle is verified based on the indications of the evidence. as well as Based on the verification, the service request message is processed.

2. The network node of claim 1, wherein the service message response includes an indication of a freshness parameter configured to prevent WTRU identity spoofing or to prevent a second WTRU from replaying the evidence.

3. The network node of claim 2, wherein the puzzle is a timed puzzle based on the freshness parameter.

4. The network node as described in any one of claims 1-3, wherein the network node sends the service message response based on determining that the number of authentication attempt failures meets a threshold.

5. The network node as described in any one of claims 1-4, wherein the network node sends the service message response based on determining that a distributed denial-of-service (DDOS) attack has been rectified.

6. The network node as claimed in any one of claims 1-5, wherein the processor is further configured to: Select a puzzle strength parameter configured to adjust the level of input required by the WTRU to generate the evidence, wherein the puzzle is generated based on the puzzle strength parameter, and wherein the puzzle strength parameter is associated with the cryptographic key length or a portion of the cryptographic hash function argument.

7. The network node of any one of claims 1-6, wherein the indication of the evidence includes a solution to a cryptographic reverse-engineering puzzle or a solution to a hash function puzzle.

8. The network node of any one of claims 1-7, wherein the puzzle is a reverse encryption puzzle, wherein the indication of the evidence comprises plaintext associated with an encryption key, and wherein the solution is verified based on determining that a portion of the plaintext associated with the encryption key is the same as a portion of the solution.

9. The network node of any one of claims 1-7, wherein the puzzle is a cryptographic hash function puzzle, wherein the indication of the evidence includes a hash function input text associated with a hash function argument, and wherein the solution is verified based on determining that a portion of the hash function input text associated with the hash function argument is the same as a portion of the solution.

10. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Send a service request message to the network node; Receive a service message response from the network node, wherein the service message response includes an indication of the puzzle; Evidence is generated based on the puzzle, wherein the evidence is associated with the solution to the puzzle; Send an evidence request message to the network node, wherein the evidence request message includes an indication of the evidence and includes a request for the network node to verify the indication of the evidence based on the solution to the puzzle; as well as Receive an authentication response that includes an indication that the service request message is being processed.

11. The WTRU of claim 10, wherein the service message response includes an indication of a freshness parameter configured to prevent WTRU identity spoofing or to prevent a second WTRU from replaying the evidence.

12. The WTRU of claim 11, wherein the puzzle is a timed puzzle based on the freshness parameter.

13. The WTRU of any one of claims 10-12, wherein the puzzle is at least one of a reverse encryption puzzle and a one-way cryptographic hash function puzzle.

14. The WTRU of any one of claims 10-13, wherein the indication of the evidence comprises a solution to a cryptographic reverse-engineering puzzle or a solution to a hash function puzzle.

15. The WTRU of any one of claims 10-14, wherein the indication of the puzzle is associated with the cryptographic key length or with a portion of the argument of the cryptographic hash function.

16. A method comprising: Receive service request messages from the Wireless Transmit / Receive Unit (WTRU); The puzzle is generated based on the service request message; Send a service message response to the WTRU, wherein the service message response includes an indication of the puzzle; Receive an evidence request message that includes an indication of evidence, wherein the evidence is associated with a solution to the puzzle; The solution to the puzzle is verified based on the indications of the evidence. as well as Based on the verification, the service request message is processed.

17. The method of claim 16, wherein the service message response includes an indication of a freshness parameter configured to prevent WTRU identity spoofing or to prevent a second WTRU from replaying the evidence.

18. The method of claim 17, wherein the puzzle is a timed puzzle based on the freshness parameter.

19. The method of any one of claims 16-18, wherein the method further comprises: The service message response is sent based on whether the number of failed authentication attempts meets a threshold or based on whether a distributed denial-of-service (DDoS) attack has been rectified.

20. The method of any one of claims 16-19, wherein the method comprises: Select a puzzle strength parameter configured to adjust the level of input required by the WTRU to generate the evidence, wherein the puzzle is generated based on the puzzle strength parameter, and wherein the puzzle strength parameter is associated with the cryptographic key length or a portion of the cryptographic hash function argument.

Images