A multi-access edge computing (MEC) communication protection method, apparatus, and medium

Abstract

This application provides a method, apparatus, and medium for protecting communication in multi-access edge computing (MEC), which can provide protection for communication between a UE and an MEC server, and between a UE and an AF deployed in the MEC server. The method includes: a terminal determining the security level of a first AF deployed in a multi-access edge computing (MEC) server, wherein the MEC server has at least one AF deployed, and the first AF is one of the at least one AF; the terminal encrypting a data packet to be sent according to the security level of the first AF and a target key to obtain an encrypted data packet, wherein the target key is derived by the terminal, and the encrypted data packet carries the identifier of the first AF; and the terminal sending the encrypted data packet to the first AF.

Description

Technical Field

[0001] This application relates to the field of network security, and in particular to a method, apparatus, and medium for protecting communication in multi-access edge computing (MEC). Background Technology

[0002] When a user equipment (UE) or terminal accesses a 5G network, both the 5G network and the UE will derive a confidentiality key (CK) and an integrity key (IK) based on the user's root key (Key, K), and use CK and IK to ensure the security of communication between the UE and the 5G network.

[0003] In addition, 5G networks can also assign application layer security protection keys to terminals and application functions (AFs) that communicate with terminals through Authentication and Key Management for Applications (AKMA). However, these application layer security protection keys are only assigned to terminals and AFs by the 5G network.

[0004] However, with the application of edge computing, in the 5G multi-access edge computing (MEC) scenario, at least one AF is deployed on the MEC server. There is currently no solution for how to protect the communication between the UE and the MEC server, as well as between the UE and the AF deployed in the MEC server. Summary of the Invention

[0005] This application provides a method, apparatus, and storage medium for protecting MEC communication, which can provide protection for communication between the UE and the MEC server, as well as between the UE and the AF deployed in the MEC server.

[0006] Firstly, this application provides a method for protecting MEC communication, the method comprising:

[0007] The terminal determines the security level of a first AF deployed in a multi-access edge computing (MEC) server, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF.

[0008] The terminal encrypts the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived by the terminal and the encrypted data packet carries the identifier of the first AF;

[0009] The terminal sends the encrypted data packet to the first AF.

[0010] Furthermore, the terminal derives the target key by:

[0011] The terminal derives the first process key based on the user root key;

[0012] The terminal derives a second process key based on the first process key and the identifier of the terminal;

[0013] The terminal derives a target key based on the second process key and the identifier of the multi-access edge computing (MEC) server. The target key is used for communication between the terminal and the MEC server.

[0014] Further, the terminal determines the security level of the first AF deployed in the MEC server, including:

[0015] The terminal sends an AF security level query request to the MEC server;

[0016] The terminal receives an AF security level query response from the MEC server, the AF security level query response including the security level of each of the at least one AF;

[0017] The terminal queries the response based on the AF security level to find the security level of the first AF.

[0018] Further, the terminal encrypts the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, including:

[0019] If the security level of the first AF is normal, the terminal encrypts the data packet according to the target key to obtain the encrypted data packet;

[0020] If the security level of the first AF is important, the terminal obtains the enhanced key of the first AF; and encrypts the data packet according to the target key and the enhanced key to obtain the encrypted data packet, wherein the enhanced key is derived by the MEC server according to the target key and the identifier of the first AF.

[0021] Furthermore, the terminal derives a first process key based on the user root key, including:

[0022] The terminal derives an integrity key IK and a confidentiality key CK based on the user root key.

[0023] The terminal derives the first process key based on the IK and the CK.

[0024] Secondly, this application provides another method for protecting MEC communication, which includes:

[0025] The MEC server receives encrypted data packets sent by the terminal, wherein the encrypted data packets carry the identifier of a first AF, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF;

[0026] The MEC server obtains the target key of the terminal;

[0027] The MEC server decrypts the encrypted data packet based on the target key;

[0028] The MEC server sends a data packet decrypted using the target key to the first AF.

[0029] Further, the MEC server obtains the target key of the terminal, including:

[0030] The MEC server sends a key acquisition request to the MEC anchor function network element. The key acquisition request includes the identifier of the terminal and the identifier of the MEC server.

[0031] The MEC server receives the target key sent by the MEC anchor function network element, wherein the target key is derived by the MEC anchor function network element based on the second process key and the identifier of the MEC server, the second process key is derived by the Authentication Service Function (AUSF) network element based on the first process key and the identifier of the terminal, the first process key is derived based on the user root key of the terminal, and the target key is used for communication between the MEC server and the terminal.

[0032] Furthermore, the method also includes:

[0033] The MEC server receives the enhanced key derivation request of the first AF, wherein the security level of the first AF is important.

[0034] The MEC server derives an enhanced key based on the target key and the identifier of the first AF;

[0035] The MEC server sends the enhancement key to the terminal and the first AF. The enhancement key is used by the terminal to encrypt data packets, and the enhancement key is also used by the first AF to decrypt the data packets decrypted using the target key.

[0036] Thirdly, this application provides a MEC communication protection device, which includes:

[0037] The transceiver module is used to determine the security level of a first AF deployed in a multi-access edge computing (MEC) server, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF;

[0038] The processing module is further configured to encrypt the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived from the terminal and the encrypted data packet carries the identifier of the first AF;

[0039] The transceiver module is used to send the encrypted data packet to the first AF.

[0040] Furthermore, the processing module is specifically configured to derive a first process key based on the user root key; derive a second process key based on the first process key and the identifier of the terminal; and derive a target key based on the second process key and the identifier of the MEC server, the target key being used for communication between the terminal and the MEC server.

[0041] Further, the transceiver module is specifically used to send an AF security level query request to the MEC server; receive an AF security level query response from the MEC server, the AF security level query response including the security level of each of the at least one AF; and find the security level of the first AF based on the AF security level query response.

[0042] Further, the processing module is specifically configured to: if the security level of the first AF is normal, encrypt the data packet according to the target key to obtain the encrypted data packet; if the security level of the first AF is important, obtain the enhanced key of the first AF; encrypt the data packet according to the target key and the enhanced key to obtain the encrypted data packet, wherein the enhanced key is derived by the MEC server according to the target key and the identifier of the first AF.

[0043] Furthermore, the processing module is specifically configured to derive an integrity key IK and a confidentiality key CK based on the user root key; and to derive the first process key based on the IK and the CK.

[0044] Fourthly, this application also provides another MEC communication protection device, which includes:

[0045] A transceiver module is used to receive encrypted data packets sent by a terminal, wherein the encrypted data packets carry the identifier of a first AF, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF;

[0046] The transceiver module is also used to obtain the target key of the terminal;

[0047] The processing module is used to decrypt the encrypted data packet according to the target key;

[0048] The transceiver module is also used to send data packets decrypted using the target key to the first AF.

[0049] Further, the transceiver module is specifically configured to send a key acquisition request to the MEC anchor function network element, the key acquisition request including the identifier of the terminal and the identifier of the MEC server; and receive the target key sent by the MEC anchor function network element, wherein the target key is derived by the MEC anchor function network element based on a second process key and the identifier of the MEC server, the second process key is derived by the Authentication Service Function (AUSF) network element based on a first process key and the identifier of the terminal, the first process key is derived based on the user root key of the terminal, and the target key is used for communication between the MEC server and the terminal.

[0050] Furthermore, the transceiver module is also configured to receive an enhanced key derivation request from the first AF, wherein the security level of the first AF is an important level; the processing module is also configured to derive an enhanced key based on the target key and the identifier of the first AF; the transceiver module is also configured to send the enhanced key to the terminal and the first AF, wherein the enhanced key is used by the terminal to encrypt data packets, and the enhanced key is also used by the first AF to decrypt the data packets decrypted using the target key.

[0051] Fifthly, this application provides an electronic device, which includes at least a processor and a memory, wherein when the processor executes a computer program or instructions stored in the memory, it implements the methods of the first and second aspects described above.

[0052] Sixthly, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed by a processor, implement the methods of the first and second aspects described above.

[0053] In this application, by determining the security level of the first AF deployed in the MEC server, the terminal can encrypt the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived by the terminal and the encrypted data packet carries the identifier of the first AF; and send the encrypted data packet to the first AF, thereby providing protection for the communication between the UE and the MEC server, and between the UE and the AF deployed in the MEC server. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a schematic diagram of a framework for allocating keys between the UE and AF via AKMA as provided in an embodiment of this application.

[0056] Figure 2 This is a flowchart of a MEC communication protection method provided in the embodiments of this application.

[0057] Figure 3 This is a flowchart of a key derivation method provided in the embodiments of this application.

[0058] Figure 4 This is a flowchart illustrating another possible MEC communication protection method provided in the embodiments of this application.

[0059] Figure 5 This is a flowchart of another possible key derivation method provided in the embodiments of this application.

[0060] Figure 6a This is a schematic diagram of a key derivation process provided in an embodiment of this application.

[0061] Figure 6b This is a schematic diagram of another possible key derivation process provided in the embodiments of this application.

[0062] Figure 6c This is a schematic diagram illustrating a possible key usage process provided in an embodiment of this application.

[0063] Figure 7 This is a schematic diagram of a framework for allocating keys between the UE and AF using the method described in this application, as provided in an embodiment of this application.

[0064] Figure 8 This is a schematic diagram of a key derivation device provided in an embodiment of this application.

[0065] Figure 9 This is a schematic diagram of another key derivation device provided in the embodiments of this application.

[0066] Figure 10 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0067] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0068] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0069] In this application, the terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings are used to distinguish similar or related objects or textual entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0070] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0071] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0072] When a UE accesses a 5G network, the Universal Subscriber Identity Module (USIM) card or the 5G network server derives CK and IK for each terminal based on the user root key K. Additionally, although the latest standard also allocates application-layer security protection keys to the terminal and the AF communicating with it via AKMA, these application-layer security protection keys are only allocated by the 5G network to the terminal and the AF.

[0073] For example, Figure 1 This is a schematic diagram illustrating a framework for allocating keys between the UE and AF using the AKMA method, as provided in an embodiment of this application. Figure 1As shown, after a UE successfully connects to the core network, the AKMA AnchorFunction (AAnF) network element of the core network can assign a key to each AF (Automatic Front-End). This key can be assigned to the AF and the UE communicating with that AF. The core network can send the key to the UE through the Access and Mobility Management Function (AMF) network element or the Radio Access Network (RAN). Additionally, the core network may also include Unified Data Management (UDM) network elements and Authentication Server Function (AUSF) network elements. The UDM network element can be used to manage data such as user root keys and terminal identifiers, while the AUSF network element can be used for terminal authentication.

[0074] In other words, the 5G network does not assign keys between the terminal and the MEC server, and therefore does not assign keys between the AF deployed in the MEC server and the terminal. Consequently, there is currently no solution for protecting communication between the UE and the MEC server, and between the UE and the AF deployed in the MEC server.

[0075] Based on this, this application provides a method, apparatus, device, and storage medium for MEC communication protection, which can provide protection for communication between the UE and the MEC server, as well as between the UE and the AF deployed in the MEC server.

[0076] Figure 2 This is a flowchart of a MEC communication protection method provided in this application embodiment. The method can be applied to terminals such as smartphones, computers, and tablets. The method includes:

[0077] S201: The terminal determines the security level of a first AF deployed in a multi-access edge computing (MEC) server, wherein the MEC server has at least one AF deployed, and the first AF is one of the at least one AF.

[0078] The terminal can obtain the AF security level lookup table corresponding to the MEC server from its local storage, the storage of other electronic devices, and the MEC server. This AF security level lookup table records the security level of any AF deployed on the MEC server. After receiving the AF security level lookup table, the terminal can determine the security level of the first AF based on the information recorded in the table.

[0079] S202: The terminal encrypts the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived from the terminal and the encrypted data packet carries the identifier of the first AF.

[0080] The security level of the first AF can be divided based on user needs or business requirements. Different security levels can correspond to different encryption methods. For example, when the security level is not set, the target key can be used to encrypt the data packets to be sent by default, or the data packets to be sent can not be encrypted. When the security level is medium, only the target key can be used to encrypt the data packets to be sent. When the security level is high, the data packets to be sent can be encrypted based on the target key and other pre-configured keys.

[0081] Specifically, the terminal can determine the encryption method corresponding to the first AF based on the security level of the first AF, and encrypt the data packet to be sent according to the target key and the encryption method corresponding to the first AF to obtain an encrypted data packet.

[0082] S203: The terminal sends the encrypted data packet to the first AF.

[0083] The terminal can send encrypted data packets to the MEC server, and the MEC server will then send the encrypted data packets to the first AF.

[0084] In one possible implementation, a method is provided for a terminal to send the encrypted data packet to the first AF, the method comprising:

[0085] The terminal sends a communication request to the MEC server. The communication request includes an identifier of a first application function (AF) for requesting communication with the first AF. The MEC server is deployed with at least one AF for requesting communication with the first AF, and the first AF is one of the at least one AF.

[0086] The terminal sends an encrypted data packet corresponding to the first AF to the MEC server, wherein the encrypted data packet is encrypted according to the target key.

[0087] After establishing a communication connection with the MEC server, the terminal can send a communication request to the MEC server. The communication request may include an identifier of a first AF (Automatic AF), used to request communication with that first AF. The identifier of the first AF in the communication request is used by the MEC server to determine the AF for which the terminal is requesting communication. The terminal can use a target key to encrypt the data packet corresponding to the first AF, obtaining an encrypted data packet corresponding to the first AF, and then send this encrypted data packet to the MEC server through the communication link between the terminal and the MEC server.

[0088] As an example, a terminal can send a communication request to the MEC server, which includes at least an identifier of a first AF requesting data interaction. The MEC server receives the communication request and, after determining that communication between the terminal and the first AF is permitted, sends a communication request feedback to the terminal, instructing the terminal to send data packets. Upon receiving the communication request feedback, the terminal encrypts the data packets corresponding to the first AF using a target key, obtaining an encrypted data packet for the first AF, and sends this encrypted data packet to the MEC server. Upon receiving the encrypted data packet, the MEC server decrypts it using the target key and sends the decrypted data packet to the first AF. The MEC server can obtain the target key from MEC Anchor Function (MAF) network elements in the core network or from the terminal; alternatively, the MEC server can obtain the target key from the communication request sent by the terminal.

[0089] In this application, by determining the security level of the first AF deployed in the MEC server, the terminal can encrypt the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived by the terminal and the encrypted data packet carries the identifier of the first AF; and send the encrypted data packet to the first AF, thereby providing protection for the communication between the UE and the MEC server, and between the UE and the AF deployed in the MEC server.

[0090] Figure 3 This is a flowchart of a key derivation method provided in an embodiment of this application. The method includes:

[0091] S301: The terminal derives the first process key based on the user root key.

[0092] When a terminal first connects to the core network or in other situations requiring key derivation, it can generate a first-process key based on the user root key using relevant key derivation algorithms. For example, after powering on or restarting, the terminal can send a connection request to the core network, which may include information such as the terminal's identifier. Upon receiving the connection request, the core network initiates an authentication process for the terminal and, after completing authentication, sends a connection success message. This message may include a key derivation instruction and the user root key. After receiving the connection success message, the terminal can derive the first-process key based on the user root key. The terminal can use a key derivation function to derive the first-process key from the user root key. For example, key derivation functions may include the Password-Based Key Derivation Function (PBKDF), bcrypt, and scrypt.

[0093] The core network can assign a user root key to the terminal based on the terminal's identifier. This user root key is unique to the terminal. Alternatively, the user root key can be pre-configured in the terminal and stored in the terminal's storage unit.

[0094] In one possible implementation, the terminal derives the first process key based on the user root key, including:

[0095] The terminal derives an integrity key IK and a confidentiality key CK based on the user root key.

[0096] The terminal derives the first process key based on the IK and the CK.

[0097] As an example: A terminal sends a connection request to the core network, which may include the terminal's identifier. The core network receives the connection request and, after completing primary authentication of the terminal, can send an authentication success message to the terminal. Upon receiving this message, the terminal's USIM card derives IK and CK based on the user root key. Then, the terminal's Mobile Equipment (ME) portion derives the first process key based on IK and CK. Specifically, the USIM card can derive IK and CK using a key derivation function based on the user root key, and the ME can also derive the first process key using a key derivation function based on IK and CK. The key derivation functions used by the USIM card and the ME can be the same or different.

[0098] S302: The terminal derives a second process key based on the first process key and the identifier of the terminal.

[0099] Since the first process key is derived solely from the user root key, in order to further enhance the security and privacy of the key, after the terminal derives the first process key based on the user root key, the terminal can also derive the second process key based on the first process key and the terminal's identifier.

[0100] Specifically, the terminal can derive the key using relevant key derivation algorithms, such as the Hash-based Message Authentication Code (HMAC) algorithm and the Secure Hash Algorithm (SHA). As an example, the HMAC-SHA-256 algorithm can be used, where the terminal can use the first-stage key and its identifier as input to the HMAC-SHA-256 algorithm to obtain the second-stage key. Alternatively, the input to the HMAC-SHA-256 algorithm can be a string concatenated from the first-stage key, the terminal identifier, and other parameters, such as a random number generated by the terminal or attributes corresponding to the terminal.

[0101] S303: The terminal derives a target key based on the second process key and the identifier of the multi-access edge computing (MEC) server. The target key is used for communication between the terminal and the MEC server.

[0102] In some implementations, the terminal may be pre-configured with the MEC server's identifier, or the terminal may obtain the identifier of the MEC server it needs to communicate with from the network side (such as the access network or core network side), or the MEC server's identifier may be stored in an application running on the terminal. The terminal can use a key derivation algorithm to derive a target key from the second process key. The input to the key derivation algorithm may include the second process key and the MEC server's identifier. The derived target key can provide protection for communication between the terminal and the MEC server.

[0103] Furthermore, when the terminal communicates with the AF deployed on the MEC server, since the MEC server acts as a communication node between the terminal and the AF, it needs to forward data from the terminal to the AF. This could lead to data leakage when the MEC server receives data from the terminal. To address this, the terminal can also use the target key to encrypt the data sent to the AF, obtaining the corresponding encrypted data for the AF. The terminal then sends this encrypted data to the MEC server, which can use the target key to decrypt the encrypted data and send the decrypted data to the AF. This reduces the possibility of data leakage between the terminal and the AF on the path between the terminal and the MEC server, thereby protecting the communication between the terminal and the AF deployed on the MEC server.

[0104] As an example, when the terminal derives the second process key, it obtains the stored MEC server identifier and uses the HMAC-SHA-256 algorithm to derive the target key corresponding to the terminal and the MEC server. The input to the HMAC-SHA-256 algorithm can be a string concatenated with the second process key, the MEC server identifier, and other parameters. These other parameters can be random numbers generated by the terminal, attributes corresponding to the MEC server, etc.

[0105] Alternatively, after receiving the identifier of the MEC server entered by the user and the operation instruction to derive the target key for the MEC server, the terminal can use the HMAC-SHA-256 algorithm or other key derivation algorithms to derive the second process key to obtain the target key corresponding to the terminal and the MEC server.

[0106] In one possible implementation, the terminal determines the security level of the first AF deployed in the MEC server, including:

[0107] The terminal sends an AF security level query request to the MEC server;

[0108] The terminal receives an AF security level query response from the MEC server, the AF security level query response including the security level of each of the at least one AF;

[0109] The terminal queries the response based on the AF security level to find the security level of the first AF.

[0110] When a terminal establishes a communication connection with the MEC server for the first time, or when the terminal receives an AF security level query command sent by the user, the terminal can send an AF security level query request to the MEC server. Based on this AF security level query request, the MEC server sends an AF security level query response to the terminal. The AF security level query response includes the security level of any one of the at least one AFs deployed on the MEC server. This security level can be a normal level or a critical level, and the security level can also be set based on user needs or business requirements.

[0111] As an example, before a terminal accesses an AF deployed on an MEC server for the first time, it can send an AF security level query request to the MEC server. The MEC server receives this request and sends an AF security level query response to the terminal. For instance, the response could be an AF security level lookup table, which records the security level of any AF deployed on the MEC server. Upon receiving this lookup table, the terminal can determine the security level of the first AF based on its contents.

[0112] Optionally, the terminal can also save the AF security level query response or AF security level lookup table from the MEC server locally. This allows the terminal to search locally for the corresponding AF security level lookup table the next time it accesses an AF deployed on the MEC server, saving communication time and reducing the waste of communication resources.

[0113] If the terminal cannot find the corresponding AF security level lookup table for the MEC server locally, it will send an AF security level lookup request to the MEC server to obtain the AF security level lookup table. Furthermore, if the generation time of the locally stored AF security level lookup table is greater than a preset time interval from the current time, the terminal can also send an AF security level lookup request to the corresponding MEC server to update the locally stored AF security level lookup table.

[0114] Further, the terminal encrypts the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, including:

[0115] If the security level of the first AF is normal, the terminal encrypts the data packet according to the target key to obtain the encrypted data packet;

[0116] If the security level of the first AF is important, the terminal obtains the enhanced key of the first AF; and encrypts the data packet according to the target key and the enhanced key to obtain the encrypted data packet, wherein the enhanced key is derived by the MEC server according to the target key and the identifier of the first AF.

[0117] When the terminal determines that the security level of the first AF is normal based on the AF security level query response, the terminal can directly use the target key to encrypt the data packet corresponding to the first AF.

[0118] When the terminal determines that the security level of the first AF is important based on the AF security level query response, in order to further improve the security of communication between the terminal and the first AF, the terminal can obtain an enhanced key for the first AF from the local machine or the MEC server. Specifically, the key management network element of the MEC server can use a key derivation algorithm to derive the enhanced key for the first AF from the target key. The input to the key derivation algorithm includes at least the target key and the identifier of the first AF.

[0119] The terminal can encrypt data packets using the target key and the enhancement key in sequence, or it can synthesize the target key and the enhancement key and use the synthesized key to encrypt data packets.

[0120] Specifically, after determining the security level of the first AF to be important based on the AF security level lookup table, the terminal can send an enhanced key request to the MEC server. This enhanced key request includes at least the identifier of the first AF. The MEC server receives the enhanced key request, retrieves the enhanced key of the first AF from its key management network element, and distributes this enhanced key to the terminal. The enhanced key of the first AF can be stored in the MEC server's key management network element. The terminal receives the enhanced key of the first AF from the MEC server and stores it locally. Then, for data packets to be sent to the first AF, the terminal can first encrypt the data packet using the enhanced key, then re-encrypt the data packet using the target key, and send the double-encrypted encrypted data packet to the MEC server. Furthermore, after receiving the encrypted data packet, the MEC server can use the target key to perform an initial decryption of the encrypted data packet and send the initially decrypted data packet to the first AF. The first AF then needs to re-decrypt the initially decrypted data packet using the enhanced key to complete the encrypted communication between the terminal and the first AF.

[0121] The above describes one MEC communication protection method with the terminal as the main focus. Correspondingly, the following describes another MEC communication protection method provided by this application with the MEC server as the main focus. Figure 4This is a flowchart illustrating another possible MEC communication protection method provided in this application embodiment. The method can be applied to an MEC server and includes:

[0122] S401: The MEC server receives an encrypted data packet sent by the terminal, wherein the encrypted data packet carries the identifier of a first AF, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF.

[0123] S402: The MEC server obtains the target key of the terminal;

[0124] The MEC server can obtain the target key of the terminal from the MEC anchor function network element or terminal.

[0125] In one possible implementation, the MEC server obtains the target key of the terminal, including:

[0126] The MEC server sends a key acquisition request to the MEC anchor function network element. The key acquisition request includes the identifier of the terminal and the identifier of the MEC server.

[0127] The MEC server receives the target key sent by the MEC anchor function network element, wherein the target key is derived by the MEC anchor function network element based on the second process key and the identifier of the MEC server, the second process key is derived by the Authentication Service Function (AUSF) network element based on the first process key and the identifier of the terminal, the first process key is derived based on the user root key of the terminal, and the target key is used for communication between the MEC server and the terminal.

[0128] S403: The MEC server decrypts the encrypted data packet according to the target key;

[0129] S404: The MEC server sends the data packet decrypted using the target key to the first AF.

[0130] In one possible implementation, the method further includes:

[0131] The MEC server receives the enhanced key derivation request of the first AF, wherein the security level of the first AF is important.

[0132] The MEC server derives an enhanced key based on the target key and the identifier of the first AF;

[0133] The MEC server sends the enhancement key to the terminal and the first AF. The enhancement key is used by the terminal to encrypt data packets, and the enhancement key is also used by the first AF to decrypt the data packets decrypted using the target key.

[0134] If the security level of the first AF is important, the first AF can send an enhanced key derivation request to the MEC server to request an enhanced key. This enhanced key derivation request may include the identifier of the first AF. After receiving the enhanced key derivation request, the MEC server's key management network element can derive the enhanced key based on the target key and the identifier of the first AF, and send the enhanced key to the first AF. The key management network element can use a key derivation algorithm, such as HMAC-SHA-256, to derive the enhanced key from the target key. The input to the key derivation algorithm can be the target key and the identifier of the first AF, or it can be a string concatenated from the target key, the identifier of the first AF, and other parameters, such as a random number generated by the MEC server or attributes corresponding to the first AF.

[0135] When the terminal encrypts the data packet using the enhancement key and the target key to obtain an encrypted data packet, the terminal sends the encrypted data packet to the MEC server. After receiving the encrypted data packet, the MEC server can use the target key to decrypt the encrypted data packet for the first time and send the decrypted data packet to the first AF. The first AF then needs to decrypt the decrypted data packet again using the enhancement key to complete the encrypted communication between the terminal and the first AF.

[0136] To better illustrate the process by which the MEC server obtains the target key of the terminal from the MEC anchor function network element, we will now use the MEC anchor function network element as the main example. Figure 5 This is a flowchart illustrating another possible key derivation method provided in the embodiments of this application. For example... Figure 5 As shown, the method includes:

[0137] S501: The MEC anchor function network element receives a key acquisition request from the MEC server, the key acquisition request including the identifier of the terminal and the identifier of the MEC server.

[0138] The MEC anchor function network element is a network element in the core network that can be used to derive target keys for MEC servers and store the target keys corresponding to MEC servers.

[0139] S502: The MEC anchor function network element obtains the second process key corresponding to the terminal from the AUSF network element, wherein the second process key is derived by the AUSF network element based on the first process key and the identifier of the terminal, and the first process key is derived based on the user root key of the terminal.

[0140] The MEC anchor function network element can obtain the second process key corresponding to the terminal from the Authentication Server Function (AUSF) network element based on the terminal's identifier. The AUSF network element can derive the second process key based on the first process key and the terminal's identifier, while the Unified Data Management (UDM) network element derives the first process key based on the user root key.

[0141] For example, one possible implementation of deriving a second process key from an AUSF network element is provided. This method includes: a core network receiving a connection request from a terminal, wherein the connection request may include the terminal's identifier; the AUSF network element of the core network sending an Authentication Vector (AV) request to a UDM network element, the AV request may include the terminal's identifier; the UDM network element receiving the AV request from the AUSF network element and sending an authentication vector corresponding to the terminal to the AUSF network element; the AUSF network element obtaining the authentication vector and completing primary authentication of the terminal based on the terminal's authentication vector; after primary authentication of the terminal is completed, the UDM network element derives IK and CK based on the user root key in the same manner as the terminal's USIM card, and further derives a first process key based on IK and CK; the UDM network element sends the first process key and a key derivation instruction to the AUSF network element, the key derivation instruction being used to instruct the AUSF network element to derive a second process key based on the first process key. After obtaining the key derivation instruction and the first process key, the AUSF network element derives the second process key from the first process key through the key derivation algorithm.

[0142] S503: The MEC anchor function network element derives the target key based on the second process key and the identifier of the MEC server.

[0143] The MEC anchor function network element uses a key derivation algorithm to derive a target key from the second process key. The input to the key derivation algorithm can include the second process key and the identifier of the MEC server. The derived target key can protect the communication between the terminal and the MEC server, as well as the communication between the terminal and the AF deployed in the MEC server.

[0144] For example, the MEC anchor function network element can use the HMAC-SHA-256 algorithm to derive a target key corresponding to the MEC server, and save the target key and the identifier of the MEC server corresponding to the target key. The input of the HMAC-SHA-256 algorithm can be a string composed of the second process key, the identifier of the MEC server and other parameters. The other parameters can be random numbers generated by the terminal, attributes corresponding to the MEC server, etc.

[0145] S504: The MEC anchor function network element sends a key acquisition response to the MEC server. The key acquisition response includes the target key, which is used for communication between the MEC server and the terminal.

[0146] The above describes the key derivation method provided in this application from the perspectives of MEC anchor function network elements in the terminal and core network, respectively. To better illustrate the key derivation process of the terminal and core network in this application, several process diagrams are used as examples below.

[0147] Figure 6a This is a schematic diagram illustrating a key derivation process provided in an embodiment of this application. For example... Figure 6a As shown, the UDM network element or Authentication Credential Repository and Processing Function (ARPF) network element in the core network derives CK and IK based on the user root key K. Simultaneously, the terminal's USIM card derives CK and IK based on K in the same manner. Similarly, the UDM network element or ARPF network element derives the first process key, K, based on CK and IK. AUSF Meanwhile, the terminal's ME derives K from CK and IK in the same way. AUSF AUSF network elements are based on K AUSF The second process key, K, is derived from this. MAF Meanwhile, the terminal's ME is based on the same method according to K. AUSF K is derived from MAF MAF network element, i.e., MEC key management network element, is based on K MAF The target key, K, is derived from this. MEC Meanwhile, the terminal's ME is based on the same method according to K. MAF K is derived from MEC The key management network element of the MEC server is based on K MEC The enhanced key K is derived from this. AF Meanwhile, the terminal's ME is based on the same method according to K. MECThe enhanced key K is derived from this. AF To ensure the consistency of keys derived from the core network side and the terminal side, the same key derivation method is used on both sides for the derivation of any key.

[0148] Figure 6b This is a schematic diagram illustrating another possible key derivation process provided in an embodiment of this application. For example... Figure 6b As shown, the process includes:

[0149] 1. The AUSF network element sends an authentication vector request to the UDM network element.

[0150] 2. The UDM network element sends an authentication response to the AUSF network element, which may include the authentication vector of the terminal.

[0151] 3. After completing the primary authentication of the terminal, the AUSF network element uses the first process key K. AUSF Derivation of the second process key K MAF Simultaneously, the terminal uses the first process key K. AUSF Derivation of the second process key K MAF .

[0152] 4. The AUSF network element sends the terminal identifier, the second process key, and the identifier corresponding to the second process key to the MAF network element.

[0153] 5. The MEC server sends a target key derivation request to the MAF network element to request the target key.

[0154] 6. The MAF network element derives the target key, K, based on the second process key and the terminal's identifier. MEC Simultaneously, the terminal derives the target key based on the second process key and the terminal's identifier.

[0155] 7. The MAF network element responds to the target key derivation request and returns the target key to the MEC server.

[0156] 8. AF sends an Enhanced Key Derivation Request to the MEC server to request the Enhanced Key.

[0157] 9. The MEC server derives the enhanced key, K, based on the target key and the identifier of AF. AF .

[0158] 10. The MEC server responds to the enhanced key derivation request and returns the enhanced key to the AF.

[0159] Specifically, the target key is used to establish secure communication capabilities between the terminal and the MEC server. This means that data packets exchanged between the terminal and the MEC server are encrypted using the target key, or the terminal and the MEC server establish a secure encrypted channel based on a block cipher algorithm and the target key, achieving security capabilities such as authentication and data encryption. The target key is also used to establish secure communication capabilities between the terminal and the AF (Automatic Front-End). This means that data packets exchanged between the terminal and the AF are encrypted as if using an enhanced key, or the terminal and the AF establish a secure encrypted channel based on a block cipher algorithm and the enhanced key, achieving security capabilities such as authentication and data encryption. The block cipher algorithm can include SM4 or AES, among others.

[0160] Figure 6c This is a schematic diagram illustrating a possible key usage process provided in an embodiment of this application. For example... Figure 6c As shown, the UE and MEC server have obtained the target key respectively through the key derivation method provided in this application embodiment. The MEC server is equipped with ordinary level AF1, ordinary level AF2, and important level AF3.

[0161] When a terminal accesses the MEC server for the first time, it can query the locally stored AF security level lookup table to determine the security level of an AF. If the terminal does not have the AF security level lookup table stored locally for that MEC server, it sends an AF security level query request to the MEC server. The MEC server queries the security level configured for each AF in the MEC server's system and returns the AF security level lookup table to the terminal. The terminal can then determine the security level of each AF based on the AF security level lookup table.

[0162] When the terminal determines that the security level of AF1 is normal, the terminal accesses AF1 as follows: The terminal encrypts the data packet using the target key to obtain an encrypted data packet, and sends the encrypted data packet to the MEC server. The MEC server then decrypts the encrypted data packet using the target key to obtain a decrypted data packet. The MEC server sends the decrypted data packet to AF1.

[0163] When the terminal determines that the security level of AF2 is also normal, the process of the terminal accessing AF2 is similar to the process of accessing AF1.

[0164] When the terminal determines that the security level of AF3 is important, the terminal accesses AF3 as follows: The terminal first encrypts the data packet using the enhanced key, and then encrypts it a second time using the target key, resulting in a double-encrypted data packet. The terminal sends the encrypted data packet to the MEC server. The MEC server decrypts the encrypted data packet using the target key, obtaining the first decrypted data packet, which is the data packet decrypted using the target key. The MEC server sends the data packet decrypted using the target key to AF3. AF3 then decrypts the data packet again using the enhanced key, completing the encrypted communication between the terminal and AF3. AF3 can send an enhanced key derivation request to the MEC server to request the MEC server to derive an enhanced key for AF3. Upon receiving the enhanced key derivation request, the MEC server derives the enhanced key for AF3 based on the target key and the identifier of AF3, and securely sends the enhanced key to AF3. AF3 receives the enhanced key and securely stores it.

[0165] Finally, with Figure 1 This is in contrast to the framework that uses AKMA to allocate keys between the UE and AF. Figure 7 This is a schematic diagram illustrating a framework for allocating keys between the UE and AF using the method described in this application, as provided in an embodiment of this application. Figure 7 As shown, the newly added MAF network element in this embodiment has a communication connection with the MEC server. After receiving a target key derivation request from the MEC server, the MAF network element can use the stored second process key K. MAF , derive the target key K for this MEC server MEC Additionally, the newly added MEC Key Management (MKM) network element in this embodiment is located on the MEC server. After receiving an enhanced key derivation request from the AF, the MEC Key Management network element can, based on the stored target key K... MEC , for this AF, derive the enhanced key K AF In addition, the core network may also include UDM network elements, AUSF network elements, AMF network elements, and RAN.

[0166] Based on the above-described MEC communication protection method, this application provides an MEC communication protection device. Figure 8 This is a schematic diagram of the structure of an MEC communication protection device provided in an embodiment of this application. The device includes:

[0167] Transceiver module 801 is used to determine the security level of a first AF deployed in a multi-access edge computing (MEC) server, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF;

[0168] The processing module 802 is further configured to encrypt the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived from the terminal and the encrypted data packet carries the identifier of the first AF;

[0169] The transceiver module 801 is used to send the encrypted data packet to the first AF.

[0170] Further, the processing module 802 is specifically used to derive a first process key based on the user root key; derive a second process key based on the first process key and the identifier of the terminal; and derive a target key based on the second process key and the identifier of the MEC server, wherein the target key is used for communication between the terminal and the MEC server.

[0171] Further, the transceiver module 801 is specifically used to send an AF security level query request to the MEC server; receive an AF security level query response from the MEC server, the AF security level query response including the security level of each of the at least one AF; and find the security level of the first AF based on the AF security level query response.

[0172] Further, the processing module 802 is specifically configured to: if the security level of the first AF is normal, encrypt the data packet according to the target key to obtain the encrypted data packet; if the security level of the first AF is important, obtain the enhanced key of the first AF; encrypt the data packet according to the target key and the enhanced key to obtain the encrypted data packet, wherein the enhanced key is derived by the MEC server according to the target key and the identifier of the first AF.

[0173] Further, the processing module 802 is specifically used to derive the integrity key IK and the confidentiality key CK based on the user root key; and to derive the first process key based on the IK and the CK.

[0174] Based on the above-described MEC communication protection method, this application provides another MEC communication protection device. Figure 9 This is a schematic diagram of another MEC communication protection device provided in this application embodiment. The device includes:

[0175] The transceiver module 901 is used to receive encrypted data packets sent by the terminal, wherein the encrypted data packets carry the identifier of a first AF, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF;

[0176] The transceiver module 901 is also used to obtain the target key of the terminal;

[0177] Processing module 902 is used to decrypt the encrypted data packet according to the target key;

[0178] The transceiver module 901 is also used to send a data packet decrypted using the target key to the first AF.

[0179] Further, the transceiver module 901 is specifically used to send a key acquisition request to the MEC anchor function network element, the key acquisition request including the identifier of the terminal and the identifier of the MEC server; and to receive the target key sent by the MEC anchor function network element, wherein the target key is derived by the MEC anchor function network element based on a second process key and the identifier of the MEC server, the second process key is derived by the Authentication Service Function (AUSF) network element based on a first process key and the identifier of the terminal, the first process key is derived based on the user root key of the terminal, and the target key is used for communication between the MEC server and the terminal.

[0180] Furthermore, the transceiver module 901 is also configured to receive an enhanced key derivation request from the first AF, wherein the security level of the first AF is an important level; the processing module 902 is also configured to derive an enhanced key based on the target key and the identifier of the first AF; the transceiver module 901 is also configured to send the enhanced key to the terminal and the first AF, wherein the enhanced key is used by the terminal to encrypt data packets, and the enhanced key is also used by the first AF to decrypt the data packets decrypted using the target key.

[0181] Figure 10 This is a schematic diagram of an electronic device structure. (Example) Figure 10 As shown, the electronic device includes: a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004, wherein the processor 1001, the communication interface 1002, and the memory 1003 communicate with each other through the communication bus 1004.

[0182] The memory 1003 stores a computer program, which, when executed by the processor 1001, causes the processor 1001 to implement the steps of any of the MEC communication protection methods described above.

[0183] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0184] The communication interface 1002 is used for communication between the above-mentioned electronic device and other devices.

[0185] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0186] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0187] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program executable by an electronic device. When the program is run on the electronic device, it causes the electronic device to implement the steps of any of the above-described MEC communication protection methods.

[0188] The aforementioned computer-readable storage medium can be any available medium or data storage device that can be accessed by the processor in an electronic device, including but not limited to magnetic storage such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), optical storage such as CDs, DVDs, BDs, HVDs, etc., and semiconductor storage such as ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.

[0189] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0190] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

[0191] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0192] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0193] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0194] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0195] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for protecting communication in multi-access edge computing (MEC), characterized in that, The method includes: The terminal determines the security level of a first AF deployed in a multi-access edge computing (MEC) server, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF. The terminal encrypts the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived by the terminal and the encrypted data packet carries the identifier of the first AF; The terminal sends the encrypted data packet to the first AF; The terminal encrypts the data packet to be sent according to the security level of the first AF and the target key to obtain the encrypted data packet, including: The terminal determines the encryption method corresponding to the first AF based on the security level of the first AF, and encrypts the data packet to be sent according to the target key and the encryption method corresponding to the first AF to obtain the encrypted data packet.

2. The method according to claim 1, characterized in that, The terminal derives the target key, including: The terminal derives the first process key based on the user root key; The terminal derives a second process key based on the first process key and the identifier of the terminal; The terminal derives a target key based on the second process key and the identifier of the MEC server. The target key is used for communication between the terminal and the MEC server.

3. The method according to claim 1, characterized in that, The terminal determines the security level of the first AF deployed in the MEC server, including: The terminal sends an AF security level query request to the MEC server; The terminal receives an AF security level query response from the MEC server, the AF security level query response including the security level of each of the at least one AF; The terminal queries the response based on the AF security level to find the security level of the first AF.

4. The method according to claim 1 or 3, characterized in that, The terminal encrypts the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, including: If the security level of the first AF is normal, the terminal encrypts the data packet according to the target key to obtain the encrypted data packet; If the security level of the first AF is important, the terminal obtains the enhanced key of the first AF; encrypts the data packet according to the target key and the enhanced key to obtain the encrypted data packet, wherein the enhanced key is derived by the MEC server according to the target key and the identifier of the first AF.

5. A method for protecting MEC communication, characterized in that, The method includes: The MEC server receives encrypted data packets sent by the terminal, wherein the encrypted data packets carry the identifier of a first AF, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF; The MEC server obtains the target key of the terminal; The MEC server decrypts the encrypted data packet based on the target key; The MEC server sends a data packet decrypted using the target key to the first AF.

6. The method according to claim 5, characterized in that, The MEC server obtains the target key of the terminal, including: The MEC server sends a key acquisition request to the MEC anchor function network element. The key acquisition request includes the identifier of the terminal and the identifier of the MEC server. The MEC server receives the target key sent by the MEC anchor function network element, wherein the target key is derived by the MEC anchor function network element based on the second process key and the identifier of the MEC server, the second process key is derived by the Authentication Service Function (AUSF) network element based on the first process key and the identifier of the terminal, the first process key is derived based on the user root key of the terminal, and the target key is used for communication between the MEC server and the terminal.

7. The method according to claim 5, characterized in that, The method further includes: The MEC server receives the enhanced key derivation request of the first AF, wherein the security level of the first AF is important. The MEC server derives an enhanced key based on the target key and the identifier of the first AF; The MEC server sends the enhancement key to the terminal and the first AF. The enhancement key is used by the terminal to encrypt data packets, and the enhancement key is also used by the first AF to decrypt the data packets decrypted using the target key.

8. A MEC communication protection device, characterized in that, The device includes: The transceiver module is used to determine the security level of a first AF deployed in a multi-access edge computing (MEC) server, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF; The processing module is also configured to encrypt the data packet to be sent according to the security level of the first AF and the target key to obtain an encrypted data packet, wherein the target key is derived from the terminal and the encrypted data packet carries the identifier of the first AF; The transceiver module is also used to send the encrypted data packet to the first AF; The processing module is specifically used to determine the encryption method corresponding to the first AF based on the security level of the first AF, and to encrypt the data packet to be sent according to the target key and the encryption method corresponding to the first AF to obtain the encrypted data packet.

9. A MEC communication protection device, characterized in that, The device includes: A transceiver module is used to receive encrypted data packets sent by a terminal, wherein the encrypted data packets carry the identifier of a first AF, wherein the MEC server is deployed with at least one AF, and the first AF is one of the at least one AF; The transceiver module is also used to obtain the target key of the terminal; The processing module is used to decrypt the encrypted data packet according to the target key; The transceiver module is also used to send data packets decrypted using the target key to the first AF.

10. A computer-readable storage medium, characterized in that, It stores a computer program or instructions, which, when executed by a processor, implement the method as described in any one of claims 1 to 7.

Images