Safety method and device based on homomorphic encryption

Abstract

The invention provides a security method and device based on homomorphic encryption, in the method, a hierarchical homomorphic calculation mode is low in bootstrap delay in a fully homomorphic encryption scheme at present, so that AES encryption / decryption can be applied to the hierarchical homomorphic calculation mode, and the security is improved. For example, the homomorphic calculation of round key encryption, row shift and column confusion of AES encryption / decryption is executed in the level 0 of the hierarchical homomorphic calculation mode, and the byte substitution of AES encryption / decryption is executed in the level 1 of the hierarchical homomorphic calculation mode, so that compared with the homomorphic calculation AES encryption / decryption scheme in the prior art, the time delay and memory consumption can be reduced, and the cost is reduced. The calculation efficiency is improved.

Description

A security method and device based on homomorphic encryption Technical Field

[0001] The present application relates to the technical field of cryptography, and in particular to a security method and device based on homomorphic encryption. Background Art

[0002] Homomorphic encryption (such as fully homomorphic encryption) allows for direct homomorphic computation on ciphertext, and the decrypted ciphertext produces the same result as the plaintext. However, currently, the ciphertext size of fully homomorphic encryption is often thousands or even millions of times larger than the plaintext size. This places high performance demands on the data sender and incurs significant communication overhead, making it unsuitable for small embedded devices with limited computing power and memory resources.

[0003] Therefore, how to reduce the performance requirements and communication overhead of homomorphic encryption on the data sender is an urgent problem to be solved.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a security method and device based on homomorphic encryption, which can reduce the performance requirements and communication overhead of homomorphic encryption on the data sender.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, a security method based on homomorphic encryption is provided, comprising: obtaining a first state of ciphertext data; performing homomorphic computations of round key addition, row shifting, and column obfuscation for AES encryption / decryption at level 0 of a hierarchical homomorphic computation mode based on the first state to obtain a second state; computing a multi-valued function bootstrapping from level 0 to level 2 and a privacy key switching from level 2 to level 1 based on the second state to obtain a third state at level 1; and performing a homomorphic computation of byte substitution for AES encryption / decryption at level 1 of the hierarchical homomorphic computation mode based on the third state to obtain a fourth state.

[0008] Based on the method described in the first aspect, it can be seen that the hierarchical homomorphic computing mode currently has the lowest bootstrap delay among fully homomorphic encryption schemes. Therefore, AES encryption / decryption can be applied to the hierarchical homomorphic computing mode, such as performing homomorphic calculations of round key addition, row shift, and column confusion for AES encryption / decryption in level 0 of the hierarchical homomorphic computing mode, and performing byte replacement for AES encryption / decryption in level 1 of the hierarchical homomorphic computing mode. Compared with the homomorphic calculation scheme of AES encryption / decryption in the prior art, it can reduce delay and memory consumption and improve computing efficiency.

[0009] In one possible design, the byte-substitution homomorphic computation for AES encryption / decryption is performed using a hybrid packed lookup table. For example, the hybrid packed lookup table includes: the S-box input is in the third state, and the S-box output is packed into two TRLWE ciphertexts using a pre-packing technique. Based on the TRGSW ciphertext of the most significant bit of the S-box input, a target TRLWE ciphertext is selected from the two TRLWE ciphertexts using a CMUX gate. Based on the TRGSW ciphertext of the remaining bits of the S-box input, the target TRLWE ciphertext is blindly rotated using seven CMUX gates to obtain the fourth state.

[0010] In one possible design, the homomorphic computation of column obfuscation for AES encryption / decryption is performed based on homomorphic computation of XOR and shift. For example, by setting the plaintext modulus to 2, the XOR operation in the homomorphic computation of AES encryption / decryption can be mapped to a ciphertext addition operation, such as the round key addition and the XOR operation in column obfuscation.

[0011] In one possible design, the multi-valued function bootstrapping from level 0 to level 2 is a programmable bootstrap PBSmanyLUT that can evaluate multiple lookup tables simultaneously. The test polynomial used in the PBSmanyLUT has a negative cyclic property.

[0012] In a possible design scheme, the method described in the fourth aspect may further include: extracting samples from the fourth state and switching the key from level 1 to level 0 to obtain a new first state of level 0.

[0013] In a second aspect, a security method based on homomorphic encryption is provided, which is applied to a homomorphic computing entity (i.e., a homomorphic computing party, or a homomorphic evaluator), and the method includes: the homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data; the homomorphic computing entity performs homomorphic computing on the ciphertext data to obtain mixed ciphertext data; the homomorphic computing entity performs homomorphic computing on the mixed ciphertext data to perform symmetrical or asymmetric decryption to obtain first homomorphic ciphertext data; the homomorphic computing entity performs homomorphic computing function f on the first homomorphic ciphertext data to obtain second homomorphic ciphertext data; and the homomorphic computing entity sends the second homomorphic ciphertext data.

[0014] Based on the method described in the second aspect, it can be seen that the homomorphic computing entity is usually a device with relatively powerful performance. The homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data sent by the data entity (i.e., the data sender), rather than the homomorphic ciphertext, and the homomorphic computing entity obtains the mixed ciphertext data through homomorphic encryption. By executing the efficient homomorphic computing method based on Boolean homomorphic encryption and AES decryption designed by this application, the homomorphic computing entity obtains the homomorphic ciphertext for subsequent homomorphic computing, which can reduce the performance requirements of homomorphic encryption on the data sender and the communication overhead.

[0015] In one possible design, a homomorphic computing entity performs homomorphic encryption on symmetrically or asymmetrically encrypted ciphertext data to obtain mixed ciphertext data, including: the homomorphic computing entity uses a homomorphic encryption key to homomorphically encrypt the symmetrically or asymmetrically encrypted ciphertext data to obtain mixed ciphertext data for homomorphic computing. The symmetrically or asymmetrically encrypted ciphertext data refers to ciphertext encrypted using a symmetrical or asymmetrical cryptographic algorithm that does not have homomorphic properties.

[0016] Optionally, the method described in the second aspect may also include: the homomorphic computing entity obtains the homomorphic encryption key from the key management entity to achieve on-demand acquisition, or the homomorphic encryption key may also be pre-configured or pre-defined by protocol locally in the homomorphic computing entity, which is not limited.

[0017] In one possible design scheme, the homomorphic computing entity performs homomorphic computing symmetric or asymmetric decryption on the mixed ciphertext data to obtain first homomorphic ciphertext data, including: the homomorphic computing entity uses the homomorphic ciphertext with a symmetric or asymmetric decryption key to perform homomorphic computing symmetric or asymmetric decryption on the mixed ciphertext data to obtain the first homomorphic ciphertext data, so as to facilitate subsequent homomorphic computing on the first homomorphic ciphertext data.

[0018] Optionally, the method described in the second aspect may also include: the homomorphic computing entity obtains the homomorphic ciphertext of the symmetric or asymmetric decryption key from the key management entity to achieve on-demand acquisition, or the homomorphic ciphertext of the symmetric or asymmetric decryption key may also be pre-configured or pre-defined by protocol locally in the homomorphic computing entity, and there is no limitation on this.

[0019] In one possible design, a homomorphic computing entity performs a homomorphic computation function f on first homomorphic ciphertext data to obtain second homomorphic ciphertext data, including: using a homomorphic computation key, the homomorphic computing entity performs a homomorphic computation function f on the first homomorphic ciphertext data to obtain the second homomorphic ciphertext data, i.e., obtaining a result consistent with a direct computation on the plaintext in the ciphertext state. Function f can be an artificial intelligence algorithm or a compressed sensing algorithm, which is not limited here.

[0020] Optionally, the method described in the second aspect may also include: the homomorphic computing entity obtains the homomorphic computing key from the key management entity to achieve on-demand acquisition, or the homomorphic computing key may also be pre-configured or pre-defined by protocol locally in the homomorphic computing entity, which is not limited.

[0021] In a possible design scheme, the method described in the second aspect may also include: the homomorphic computing entity receives a homomorphic task configuration message from the homomorphic task management entity, wherein the homomorphic task configuration message is used to instruct the homomorphic computing entity to execute the corresponding homomorphic computing task, so as to trigger homomorphic computing on demand and avoid executing invalid redundant homomorphic computing and wasting resource overhead.

[0022] In one possible design, the homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data, including: the homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data from a data entity or a ciphertext data storage entity. That is, the data entity can directly send the symmetrically or asymmetrically encrypted ciphertext data to the homomorphic computing entity, or can also send the symmetrically or asymmetrically encrypted ciphertext data to the ciphertext data storage entity cache, so that the ciphertext data storage entity can send the symmetrically or asymmetrically encrypted ciphertext data to the homomorphic computing entity only when necessary, thereby avoiding wasted communication overhead due to the erroneous sending of symmetrically or asymmetrically encrypted ciphertext data.

[0023] In one possible design, the homomorphic computing entity sends the second homomorphic ciphertext data, including: the homomorphic computing entity sends the second homomorphic ciphertext data to the user entity or the decryption entity. That is, if the user entity has homomorphic decryption capabilities, such as if the user entity and the decryption entity are the same entity (jointly established), then the homomorphic computing entity can directly send the second homomorphic ciphertext data to the user entity. Otherwise, the homomorphic computing entity needs to send the second homomorphic ciphertext data to the decryption entity. The specific choice can be made based on actual circumstances and is not specifically limited to this.

[0024] In one possible design scheme, the symmetrically or asymmetrically encrypted ciphertext data is the ciphertext data sent by the terminal to the network, that is, it is applicable to the communication scenario between the terminal and the network, or it can also be applicable to other communication scenarios, without specific limitation.

[0025] In one possible design scheme, the homomorphic computing entity is any one of the following: base station BS, core network CN network element, edge node computing MEC entity, which can be selected according to actual conditions and is not specifically limited.

[0026] In a third aspect, a security method based on homomorphic encryption is provided, which is applied to a key management entity. The method includes: the key management entity receiving a homomorphic task key request message from a homomorphic task management entity, and the key management entity sending a key related to the homomorphic task to a homomorphic computing entity that executes the homomorphic task based on the homomorphic task key request message. The homomorphic task key request message is used to request the key management entity to derive and allocate a key related to the homomorphic task.

[0027] The keys associated with homomorphic tasks include at least one of the following: homomorphic ciphertext of a symmetric or asymmetric key, a homomorphic encryption key, or a homomorphic computation key.

[0028] In one possible design, the method described in the third aspect may further include: the key management entity receiving cryptographic capability information from the data entity, and sending a symmetric or asymmetric encryption key to the data entity based on the cryptographic capability information of the data entity. The cryptographic capability information of the data entity is used to indicate whether the data entity supports symmetric or asymmetric encryption capabilities. That is, the key management entity only sends the symmetric or asymmetric encryption key if the data entity supports symmetric or asymmetric encryption capabilities, thereby avoiding wasting communication overhead by sending the symmetric or asymmetric encryption key even if the data entity does not support symmetric or asymmetric encryption capabilities.

[0029] In a possible design scheme, the method described in the third aspect may also include: the key management entity receives the cryptographic capability information from the decryption entity, and sends the symmetric or asymmetric encryption key and the homomorphic decryption key to the decryption entity according to the cryptographic capability information of the decryption entity. The cryptographic capability information of the decryption entity is used to indicate that the decryption entity supports homomorphic decryption capability and symmetric or asymmetric encryption capability. That is, the key management entity only issues the symmetric or asymmetric encryption key and the homomorphic decryption key when the decryption entity supports the homomorphic decryption capability and the symmetric or asymmetric encryption capability, so as to avoid wasting communication overhead by still sending the symmetric or asymmetric encryption key and the homomorphic decryption key when the decryption entity does not support the homomorphic decryption capability and the symmetric or asymmetric encryption capability.

[0030] The decryption entity is an entity different from the homomorphic computation entity. That is, homomorphic computation and homomorphic decryption can be performed by different entities to achieve privacy protection.

[0031] Optionally, the method described in the third aspect may further include: the key management entity receiving cryptographic capability information from the user entity, and sending a symmetric or asymmetric decryption key to the user entity based on the cryptographic capability information of the user entity. The cryptographic capability information of the user entity is used to indicate that the user entity supports symmetric or asymmetric decryption capabilities. That is, the key management entity only sends the symmetric or asymmetric decryption key if the user entity supports symmetric or asymmetric decryption capabilities, thereby avoiding wasting communication overhead by sending the symmetric or asymmetric decryption key even if the user entity does not support symmetric or asymmetric decryption capabilities.

[0032] In one possible design scheme, the method described in the third aspect may also include: the key management entity receives cryptographic capability information from the user entity, and sends a homomorphic decryption key to the user entity based on the cryptographic capability information of the user entity. The cryptographic capability information of the user entity is used to indicate that the user entity supports homomorphic decryption capability. That is, the key management entity will only issue the homomorphic decryption key if the user entity supports homomorphic decryption capability, so as to avoid wasting communication overhead by still sending the homomorphic decryption key if the user entity does not support homomorphic decryption capability.

[0033] In addition, other technical effects of the method described in the third aspect can refer to the technical effects of the method described in the second aspect, and will not be repeated here.

[0034] In a fourth aspect, a security method based on homomorphic encryption is provided, which is applied to a homomorphic task management entity. The method includes: the homomorphic task management entity receives a homomorphic task request message from a user entity, and sends a homomorphic task key request message to a key management entity based on the homomorphic task request. The homomorphic task request message indicates the homomorphic task requested by the user entity; the homomorphic task key request message is used to request the key management entity to derive and allocate relevant keys for the homomorphic task. In other words, the homomorphic task management entity only requests the key management entity to allocate relevant keys when the user entity has a demand, so as to avoid communication redundancy.

[0035] In one possible design solution, the method described in the fourth aspect may further include: the homomorphic task management entity sends a ciphertext sending task configuration message to the ciphertext data storage entity. The ciphertext sending task configuration message is used to trigger the ciphertext data storage entity to send ciphertext data to the homomorphic computing entity.

[0036] In addition, other technical effects of the method described in the fourth aspect can refer to the technical effects of the method described in the second aspect, and will not be repeated here.

[0037] In a fifth aspect, a security device is provided. The security device includes: a module for executing the method described in any one of aspects 1 to 4, such as a transceiver module and a processing module. For example, the transceiver module is configured to perform the transceiver function of the security device, and the processing module is configured to perform functions other than the transceiver function of the security device.

[0038] Optionally, the transceiver module may include a sending module and a receiving module, wherein the sending module is used to implement the sending function of the security device described in the third aspect, and the receiving module is used to implement the receiving function of the security device described in the third aspect.

[0039] Optionally, the security device described in the fifth aspect may further include a storage module, wherein the storage module stores a program or instruction. When the processing module executes the program or instruction, the security device can execute the method described in any one of the first to fourth aspects.

[0040] It can be understood that the security device described in the fifth aspect can be a terminal, or a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in a terminal, or a network device, or other device that can perform homomorphic tasks, or a device that includes a terminal, or a network device, or other device that can perform homomorphic tasks. This application does not limit this.

[0041] In addition, the technical effects of the safety device described in the fifth aspect can refer to the technical effects of the method described in the first aspect, and will not be repeated here.

[0042] In a sixth aspect, a security device is provided, comprising: a processor configured to execute the method described in any one of the first to fourth aspects.

[0043] In one possible design solution, the security device described in the fourth aspect may further include a transceiver. The transceiver may be a transceiver circuit or an interface circuit. The transceiver may be used to enable the security device described in the fourth aspect to communicate with other devices.

[0044] In one possible design, the security device described in the sixth aspect may further include a memory. The memory may be integrated with the processor or provided separately. The memory may be used to store the computer program and / or data involved in the method described in the first aspect.

[0045] In an embodiment of the present application, the security device described in the sixth aspect may be a terminal, or a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in the terminal, or the network device, or other device that can perform homomorphic tasks, or a device that includes the terminal, or the network device, or other device that can perform homomorphic tasks.

[0046] In addition, the technical effects of the safety device described in the sixth aspect can refer to the technical effects of the method described in the first aspect, and will not be repeated here.

[0047] In a seventh aspect, a security device is provided, comprising: a processor coupled to a memory, the processor configured to execute a computer program stored in the memory, so that the security device executes the method described in any one of the first to fourth aspects.

[0048] In one possible design solution, the security device described in the seventh aspect may further include a transceiver. The transceiver may be a transceiver circuit or an interface circuit. The transceiver may be used to enable the security device described in the seventh aspect to communicate with other devices.

[0049] In an embodiment of the present application, the security device described in the seventh aspect may be a terminal, or a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in the terminal, or the network device, or other device that can perform homomorphic tasks, or a device that includes the terminal, or the network device, or a device with homomorphic encryption capabilities.

[0050] In addition, the technical effects of the safety device described in the seventh aspect can refer to the technical effects of the method described in the first aspect, and will not be repeated here.

[0051] In an eighth aspect, a security device is provided, comprising: a processor and a memory; the memory is used to store a computer program, and when the processor executes the computer program, the security device executes the method described in any one of the first to fourth aspects.

[0052] In one possible design solution, the security device described in the eighth aspect may further include a transceiver. The transceiver may be a transceiver circuit or an interface circuit. The transceiver may be used to enable the security device described in the eighth aspect to communicate with other devices.

[0053] In an embodiment of the present application, the security device described in the eighth aspect may be a terminal, or a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in the terminal, or the network device, or other device that can perform homomorphic tasks, or a device that includes the terminal, or the network device, or other device that can perform homomorphic tasks.

[0054] In addition, the technical effects of the safety device described in the eighth aspect can refer to the technical effects of the method described in the first aspect, and will not be repeated here.

[0055] In a ninth aspect, a computer-readable storage medium is provided, comprising: a computer program or instructions; when the computer program or instructions are run on a computer, the computer is caused to execute the method described in any one of the first to fourth aspects.

[0056] In a tenth aspect, a computer program product is provided, comprising a computer program or instructions, which, when executed on a computer, causes the computer to execute the method described in any one of the first to fourth aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 is a schematic diagram of the architecture of the homomorphic encryption scheme;

[0058] Figure 2 is a schematic diagram of the process of the homomorphic encryption scheme;

[0059] Figure 3 is a schematic diagram of the structure of the ciphertext in the homomorphic encryption scheme;

[0060] FIG4 is a schematic diagram of the circuit bootstrapping architecture of a TFHE;

[0061] FIG5 is a schematic diagram of the architecture of the hierarchical homomorphic computing model of TFHE;

[0062] FIG6 is a schematic diagram of the flow of the AES encryption algorithm;

[0063] FIG7 is a schematic diagram of the S-box calculation process based on BGV de-homomorphic calculation;

[0064] FIG8 is a schematic diagram of the state;

[0065] FIG9 is a schematic diagram of row shifting;

[0066] Figure 10 is a schematic diagram of column confusion;

[0067] FIG11 is a schematic diagram of the simulation results of the homomorphic evaluation AES algorithm;

[0068] FIG12 is a schematic diagram of the architecture of a security system provided in an embodiment of the present application;

[0069] FIG13 is a flowchart of a security method based on homomorphic encryption according to an embodiment of the present application;

[0070] FIG14 is a first schematic diagram of a scenario of a security method based on homomorphic encryption provided in an embodiment of the present application;

[0071] FIG15 is a second schematic diagram of a scenario of a security method based on homomorphic encryption provided in an embodiment of the present application;

[0072] FIG16 is a second flow chart of a security method based on homomorphic encryption provided in an embodiment of the present application;

[0073] FIG17 is a third flow chart of a security method based on homomorphic encryption provided in an embodiment of the present application;

[0074] FIG18 is a third schematic diagram of a scenario of a security method based on homomorphic encryption provided in an embodiment of the present application;

[0075] FIG19 is a schematic diagram of column obfuscation in a security method based on homomorphic encryption provided in an embodiment of the present application;

[0076] FIG20 is a schematic diagram of a hybrid packaged table lookup in a security method based on homomorphic encryption provided in an embodiment of the present application;

[0077] FIG21 is a structural diagram of a safety device according to an embodiment of the present application;

[0078] FIG22 is a second structural diagram of the safety device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0079] For ease of understanding, the technical terms involved in the embodiments of this application are first introduced below.

[0080] 1. Homomorphic encryption:

[0081] Homomorphic encryption (such as fully homomorphic encryption (FHE)) is a cryptographic technique that allows computations to be performed on ciphertext, and the results of the computations on the ciphertext, when decrypted, are identical to those on the plaintext. This means that even in an encrypted state, data can still be processed and manipulated without revealing the original data. Homomorphic encryption schemes typically consist of four parts: key generation, homomorphic encryption, homomorphic evaluation, and homomorphic decryption, which are described below.

[0082] Key generation:

[0083] As shown in Figure 1, the key generator can input the key material into the key generator and obtain the public key (pk) output by the key generator, that is, the homomorphic encryption key, such as K enc , secret key (sk), that is, the homomorphic decryption key, such as K dec , and homomorphic evaluation key (evk), or homomorphic computation key, such as K eval (KSK, bootstrapping key (BSK)). As shown in Figure 2, step S1: the key generator can send the homomorphic encryption key to the homomorphic encryption party, send the homomorphic decryption key to the homomorphic decryption party, and send the homomorphic computation key to the homomorphic computation party.

[0084] Homomorphic encryption:

[0085] As shown in Figure 1, the homomorphic encryption party can use the homomorphic encryption key to encrypt a single bit of plaintext data, such as m∈{0,1}, into ciphertext data, which can be expressed as c=E pk (m), if multiple bits of plaintext data, such as m1, m2, ... m l, l is an integer greater than 1, then the corresponding multiple bits of ciphertext data can be expressed as c=E pk (m1,m2,…m l As shown in FIG2 , step S2: the homomorphic encryption party may send the ciphertext data (eg, c1) to the homomorphic computing party.

[0086] It can be understood that the ciphertext data can be expressed in different forms. For example, as shown in Figure 3, in the fully homomorphic encryption scheme over the torus (TFHE), the ciphertext data can be expressed in the form of b=[a·s+m+e] Q .in, is a uniformly distributed random matrix. s is a key, such as a homomorphic encryption key, and s∈R Q , the positive integer n is the polynomial dimension, m is the plaintext data. Q and q both refer to the ciphertext modulus, R Q yes Omit the superscript expression, The superscript of represents the matrix / vector dimension. e is the noise, and e∈χ n , the noise distribution χ=χ(n) is The noise distribution can be selected as a discrete Gaussian distribution, and the noise upper limit |χ|≤B. The ring polynomial whose modulus is a prime number modulus Q, that is, the ciphertext data can also be called ciphertext data in the form of learning with errors over ring (RLWE).

[0087] Homomorphic computation:

[0088] As shown in Figure 1, the homomorphic computing party can use the homomorphic computing key to perform homomorphic computing on a single bit of ciphertext data, if the homomorphic computing function is C f , or function f, to get the ciphertext result For example, for multiple bits of ciphertext data, the corresponding ciphertext result is As shown in FIG2 , step S3 : the homomorphic computing party may send the ciphertext result to the homomorphic decryption party.

[0089] It can be understood that, as shown in Figure 3, b=[a·s+m+e] Q , for the homomorphic computing party, a and b are known parameters, and the rest are unknown parameters.

[0090] Homomorphic decryption:

[0091] As shown in Figure 1, the homomorphic decryption party can use the homomorphic decryption key to decrypt the ciphertext result into the plaintext result f(m). For example, for a ciphertext result of multiple bits, the corresponding plaintext result f(m1,m2,…m l ). At this time, if the plaintext data is directly calculated by function f, the result is also f(m), and the two are consistent.

[0092] As can be seen, homomorphic encryption adds a random "noise" component to the ciphertext data, namely the e mentioned above. Performing homomorphic calculations on the ciphertext data will cause this noise to grow. For example, when multiple ciphertext data are superimposed together for homomorphic calculation, the noise inherent in each ciphertext data will be superimposed and amplified, possibly reaching exponential expansion, and a cross term will appear where the noise is multiplied by the ciphertext data. If only a relatively simple homomorphic calculation is performed on the ciphertext data, that is, the noise is still within the controllable range (critical value), then homomorphic decryption can still restore the ciphertext data to the plaintext result. However, if the homomorphic calculation is too complex, that is, the noise may exceed the controllable range, destroying or even overwriting the original plaintext data, causing homomorphic decryption to fail.

[0093] 2. Ciphertext

[0094] There are many forms of ciphertext, such as LWE form ciphertext, or LWE torus version TLWE ciphertext, or ring learning with errors assumption (RLWE) form ciphertext, or RLWE torus version TRLWE ciphertext (Torus version of the ring-LWE problem), or RGSW form ciphertext, or RGSW torus version TRGSW ciphertext. identifies a set of integers, Identifies the set of real numbers. is the set of real numbers modulo 1. Represents the binary set {0,1}. is the ciphertext modulus q. 2N-th cyclotomic ring is modulo X N +1 integer polynomial. express Polynomials with binary coefficients in . is a torus polynomial Where N is a power of 2.

[0095] LWE:

[0096] Define the plaintext message as m, and define positive integers n and q, the LWE encryption of m∈Z is a vector such that b=-a·sk+m+e. Where a is an n-dimensional vector, The key sk is an n-dimensional vector sampled from the key distribution χ (e.g., Gaussian distribution). The error e is sampled from the error distribution χ′ (e.g., Gaussian distribution). The dimensions of b, m, and e are all 1.

[0097] TLWE:

[0098] The TLWE ciphertext is the Torus version of LWE and can be expressed as Specifically, b=<a,s> +m+e, where vector a is from uniformly sampled from B, the key s is n uniform sampling, is the plaintext message, and the error e is sampled from a Gaussian distribution with mean 0 and standard deviation σ.

[0099] RLWE:

[0100] RLWE is R q The ring version of LWE. q The RLWE encryption is a pair b=-a·sk+m+e. Among them, vector a is The key sk is sampled uniformly in the key distribution χ (such as Gaussian distribution), and each coefficient ei of the error e is sampled from the error distribution χ′ (such as Gaussian distribution).

[0101] TRLWE:

[0102] The TRLWE ciphertext is the Torus version of RLWE and can be expressed as Specifically, b=<a,s> +m+e, where a is from The key s is uniformly sampled from uniform sampling, is the plaintext message polynomial. Error is a polynomial with random coefficients, Sample from a Gaussian distribution with mean 0 and standard deviation σ.

[0103] RGSW:

[0104] If the message is m, then m∈R qThe RGSW encryption can be expressed as: RGSW sk (m) = (RLWE′ sk (sk·m),RLWE′ sk (m)), sk is the key, and the identifier RLWE' refers to the concept of gadget RLWE, for example, it is defined as RLWE′ sk (m) = (RLWE sk (v0·m),RLWE sk (v1·m),…,RLWE sk (v l-1 ·m)), where v=(v0,v1,…,v l-1 ) is the gadget vector.

[0105] TRGSW:

[0106] TRGSW is a torus version of RGSW that can convert plaintext messages Encrypted to ciphertext in is a matrix, each row of which is the TRLWE ciphertext of the plaintext message 0 under the same key. G is the gadget matrix, which is used to control noise propagation.

[0107] Assume k = 1, TRGSW ciphertext It can be further expressed as follows:

[0108] Among them (a i (x),b i (x)), 1≤i≤2l is the TRLWE ciphertext of plaintext message 0 encrypted with the same key, B g represents the basis of gadget decomposition, and l is the length of gadget decomposition.

[0109] It can be understood that these ciphertext types can be converted to each other to cope with different computing tasks.

[0110] 3. Bootstrapping:

[0111] The core operation of homomorphic encryption schemes is bootstrapping, a concept defined in Gentry's 2009 FHE solution. The purpose of bootstrapping is to refresh the ciphertext data to reduce its noise level and prevent excessive noise expansion during homomorphic computation, which can lead to decryption failures. The bootstrapping process is often the most time-consuming part of homomorphic encryption schemes. To enable homomorphic computation on circuits of arbitrary depth, TFHE introduces circuit bootstrapping.

[0112] TFHE provides a leveled homomorphic evaluation (LHE) scheme that allows computation of large-scale logic circuits before bootstrapping. This scheme primarily consists of a homomorphic evaluation circuit and circuit bootstrapping. Circuit bootstrapping can transform high-noise ciphertext in the form of TLWE into low-noise ciphertext in the form of TRGSW. For example, TFHE's circuit bootstrapping is often used in leveled homomorphic encryption (LHE) schemes. Combined with the LHE algorithm, bootstrapping is performed again after each pass through a larger circuit. A similar situation can be seen in Figure 4.

[0113] Specifically, the hierarchical homomorphic computation model provided by TFHE can efficiently compute multi-input lookup tables (LUTs), bit sequence representations (BSRs), weighted finite automata (WFAs), and other algorithms using hierarchical circuits. The inputs and outputs of hierarchical homomorphic computations have different ciphertext forms. To achieve composability, circuit bootstrapping is required to simultaneously transform the ciphertext form while refreshing the noise. In other words, this involves converting noisy TLWE samples in the binary message space into less noisy TRGSW samples in the integer message space.

[0114] As shown in Figure 5, to ensure security and operational correctness, TFHE's hierarchical homomorphic computing model spans three levels: level 0, level 1, and level 2. Each level sets different parameters, such as the homomorphic key.

[0115] The dimension n of level 0 is relatively low, such as n=635, and the ciphertext modulus q is relatively small, such as 32 bits, but the noise is relatively large, such as σ 2 ≈2 -30 , σ represents level 0 noise. Level 0 calculations are relatively fast, but generally allow relatively limited linear operations. In the embodiments of the present application, level 0 variables are represented by underscores.

[0116] Level 1 has a medium dimension n, such as n = 1024, and a relatively small ciphertext modulus q, such as 32 bits, but also relatively large noise, such as σ 2 ≈2 -50 , σ represents the noise of level 1. Level 1 calculation is also relatively fast, which can allow relatively large depth of homomorphic evaluation circuits. For example, the above-mentioned LUT, BSR, WFA, etc. can all be executed at level 1.

[0117] The dimension n of level 2 is medium, such as n = 2048, the ciphertext modulus q is relatively large, such as 64 bits, but the noise is relatively small, such as Indicates level 2 noise. Level 2 calculations are slower. Level 2 variables are overlined.

[0118] Circuit bootstrap spans three levels, such as level 0 to level 2 and level 2 to level 1 operations (dashed arrows in Figure 5). Circuit bootstrap keys include: 1 function bootstrap key, such as is the i-th item of the LWE key sk at level 0, i∈[1,n], n is the polynomial dimension; and the circuit bootstrapping key also includes: 2 privacy key switching keys, such as and RLWE′ sk (f 0,1 (1)). Here, function f0 is the identity function, function f1(x) = sk·x, sk is the RLWE key of level 1, Is a level 2 LWE key The jth term of , j∈[1,n], n is the polynomial dimension. Thus, circuit bootstrapping (CB or CBS): This can include the following two steps:

[0119] Step 1: Function bootstrapping (level 0 to level 2).

[0120] Function bootstrapping can be expressed as shown in the following formula 1:

[0121] Among them, the ciphertext of level 0 is bootstrapped by the function to obtain the ciphertext of level 2 sk is the key of level 0, is the level 2 key. l is equivalent to breaking a large number into smaller numbers, i.e., l LWE ciphertexts. testP is the test polynomial encoded by the LUT function f. Function bootstrapping can compute a function while simultaneously denoising and refreshing the ciphertext. Furthermore, in function bootstrapping, if a gate is computed, it is also called gate bootstrapping.

[0122] Step 2: Privacy key switching (e.g., level 2 to level 1).

[0123] Privacy key switching can be expressed as shown in the following equations 2-4: RGSW sk (m) = RLWE′ sk (sk·m),RLWE′ sk(m); (4)

[0124] Among them, the level 2 ciphertext is converted into the level 1 ciphertext after the privacy key is switched. The input of privacy key switching is LWE ciphertext, and the output is RGSW ciphertext. Specifically, privacy key switching involves: 1) changing the ciphertext form and computing the function f0 (identity function) and the function f1 (message m multiplied by the key sk); 2) concatenating one RLWE ciphertext into one RLWE' ciphertext, and then concatenating two RLWE's into one RGSW ciphertext.

[0125] 4. Advanced Encryption Standard (AES):

[0126] The AES algorithm is a variant of the Rijndael block cipher invented by two Belgian cryptographers, Vincent Rijmen and Joan Daeman. It is also known as the Rijndael encryption method. It is a symmetric cryptographic algorithm used for air interface confidentiality and integrity protection in the communication networks of fourth-generation (4G) and fifth-generation (5G) mobile communication systems.

[0127] The AES algorithm is essentially a symmetric block cipher employing a substitution / permutation network. Each round consists of three layers. A linear mixing layer ensures high diffusion across multiple rounds, a nonlinear layer consisting of 16 juxtaposed S-boxes obfuscates the data, and a key encryption layer XORs the subkeys into an intermediate state. The AES algorithm is an iterative block cipher with variable block and key lengths. However, to meet the requirements of the AES algorithm, the block size is limited to 128 bits, and the key lengths are 128, 192, or 256 bits. Different key lengths require different numbers of iterative encryption rounds, such as 10, 12, or 14 rounds. During the iterative encryption process, the AES algorithm performs operations such as subbyte substitution, row shifting, column mixing, and round key addition. The encryption and decryption processes of the AES algorithm involve multiple data transformations, each of which produces an intermediate result, called a state.

[0128] For example, as shown in Figure 6, the AES encryption algorithm execution process is as follows:

[0129] S1: Define the plaintext as M, initialize the state to M, perform the round key addition operation, and XOR the round key with the state.

[0130] S2: For each of the first N-1 rounds, e.g., N=10, a byte substitution transformation is first performed through the S-box, followed by a row shift operation on the state, a column obfuscation operation on the state, and finally a round key addition operation on the state.

[0131] S3: For the last N rounds, first perform a byte substitution transformation through the S-box, then perform a row shift operation on the state, and finally perform a round key addition operation on the state (that is, unlike the first Nr-1 rounds, it does not perform a column confusion operation).

[0132] S4: Define the content in the state output by round N as ciphertext C.

[0133] It can be understood that the AES decryption algorithm is different from the encryption algorithm. Among the basic operations, except for the round key addition, the other operations such as byte replacement, row shift and column confusion must be inverse transformed. For details, please refer to Figure 6 and will not be repeated here.

[0134] In 2012, Gentry et al. first proposed homomorphic evaluation of the AES algorithm, which involves homomorphically computing AES encryption or decryption on ciphertext. They used the BGV (Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan) homomorphic encryption algorithm and combined it with numerous optimization techniques to develop two evaluation modes: one without bootstrapping and the other with bootstrapping. These are described below.

[0135] 1) Round key addition:

[0136] Plaintext calculation: XOR the round key with the state bit by bit;

[0137] Ciphertext calculation: Set the plaintext modulus t = 2, and the ciphertext addition operation is the homomorphic XOR operation.

[0138] 2) Byte replacement:

[0139] Plaintext calculation: Byte substitution transformation is a nonlinear byte substitution (using a substitution-box (Sbox), also called an S-box), which operates on each state byte independently, and can also be called an S-box mapping. In cryptography, an S-box is the basic structure for symmetric encryption algorithms to perform substitution calculations. In block ciphers, S-boxes are often used to obfuscate the relationship between the key and the ciphertext. For example, the S-box receives a specific number of input bits (bits) m and converts them into a specific number of output bits n, where n is not necessarily equal to m. An m×n S-box can contain 2 m Entries / row, each entry is n bits of lookup table implementation, that is, input m bits (2 mentries / rows), the table lookup outputs n bits.

[0140] The essential structure of byte substitution is a finite field (Galois field) The inverse of X -1 =X 254 and Then, the S-box mapping, that is, S(X) is first in the finite field Calculate the inverse element Y = X -1 , and then apply a bitwise affine transformation, such as Z = T(Y). After finding the inverse of a finite field, we can use Frobenius automorphisms to calculate Affine transformation on For example, according to the above finite field properties, we know that X 255 =1, divide both sides by X, and you get X -1 =X 254 .

[0141] Ciphertext calculation: Figure 7 shows the process of homomorphic calculation of S-box based on BGV, specifically showing the pseudo-code description of the S-box table lookup. The column corresponding to "level" indicates the approximate "level" consumed by these homomorphic operations. The entire S-box process can be expressed as c" = δ + Mc -1 , where δ and γ j is a constant term, M is shown in Figure 8, and steps 1-9 shown in Figure 7 are expressed as follows:

[0142] Steps 1 to 7: Calculate the finite field GF(2 8 ) in the multiplication inverse. That is, the input is the ciphertext c, and the calculation c -1 =c 254 This process requires three Frobenius automorphisms and four multiplications.

[0143] Steps 8-9: Calculate the finite field (can also be written as GF(2)) affine transformation, the formula of the entire affine transformation can be expressed as

[0144] 3) Row shift:

[0145] Plaintext calculation: A row shift is a byte transposition that circularly shifts the rows in the state by different offsets. For example, as shown in Figure 9, the row shift can be: the first row remains unchanged, the second row is circularly shifted left by 8 bits, the third row is circularly shifted left by 16 bits, and the fourth row is circularly shifted left by 24 bits. Assuming the matrix is ​​a, it can be expressed as: S[i][j] = S[i][(i+j)%4], where i represents the row index and j represents the column index.

[0146] Ciphertext calculation: Automorphism on finite fields realizes element rotation of each slot.

[0147] 4) Column confusion:

[0148] Plaintext calculation: As shown in Figure 10, in column confusion, each column in the state (intermediate result) is regarded as The result s′(x) of multiplying the polynomial s(x) on the fixed polynomial a(x) is the output of column confusion.

[0149] Ciphertext calculation: Column obfuscation calculation is efficiently implemented through Frobenius automorphism, as shown in steps 8-9 (Frobenius automorphism for even-power calculation) in Figure 7 above, which can be expressed as:

[0150] Based on the above, the current technical disadvantages of the homomorphic evaluation AES algorithm are high latency and high memory consumption. Figure 11 shows the comparative results of several existing homomorphic AES encryption / decryption schemes, showing that all suffer from high latency and high memory consumption. In addition, the data volume of homomorphic ciphertext is relatively large, and transmitting homomorphic ciphertext will incur a relatively large communication overhead.

[0151] In response to the above problems, the embodiments of the present application propose the following technical solutions, which will be described below in conjunction with the accompanying drawings.

[0152] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as wireless network (Wi-Fi) systems, vehicle to everything (V2X) communication systems, device to device (D2D) communication systems, Internet of Vehicles communication systems, 4G, such as long-term evolution (LTE) systems, world-wide interoperability for microwave access (WiMAX) communication systems, 5G, such as new radio (NR) systems, and future communication systems. The technical solutions of the embodiments of the present application can also be applied to other potential industries, such as genetics, health care, national security, education, social security, commercial financial analysis and other industries, for scenarios where privacy protection is required during computing, such as cloud computing, outsourced computing, machine learning, and privacy data processing.

[0153] In the embodiment of the present application, "indication" may include direct indication and indirect indication, and may also include explicit indication and implicit indication. The information indicated by a certain information (such as the first information, the second information, or the third information below) is called information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein the other information and the information to be indicated have an association relationship. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, the indication of specific information can be achieved by means of the arrangement order of each piece of information agreed in advance (such as specified in the protocol), thereby reducing the indication overhead to a certain extent. At the same time, the common parts of each piece of information can be identified and indicated uniformly to reduce the indication overhead caused by indicating the same information separately.

[0154] In addition, the specific indication method can also be various existing indication methods, such as but not limited to the above-mentioned indication methods and various combinations thereof. The specific details of the various indication methods can be referred to the prior art and will not be repeated herein. As can be seen from the above, for example, when it is necessary to indicate multiple information of the same type, there may be a situation where the indication methods for different information are different. In the specific implementation process, the required indication method can be selected according to specific needs. The embodiment of the present application does not limit the selected indication method. In this way, the indication method involved in the embodiment of the present application should be understood to cover various methods that can enable the party to be indicated to obtain the information to be indicated.

[0155] It should be understood that the information to be indicated can be sent as a whole or divided into multiple sub-information and sent separately, and the sending period and / or sending time of these sub-information can be the same or different. The specific sending method is not limited in the embodiments of this application. The sending period and / or sending time of these sub-information can be predefined, for example, predefined according to a protocol, or can be configured by the transmitting device by sending configuration information to the receiving device.

[0156] "Pre-definition" or "pre-configuration" can be implemented by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in the device, and the embodiments of the present application do not limit the specific implementation method. Among them, "saving" can mean saving in one or more memories. The one or more memories can be set separately or integrated in an encoder or decoder, a processor, or a communication device. The one or more memories can also be partially set separately and partially integrated in a decoder, a processor, or a communication device. The type of memory can be any form of storage medium, and the embodiments of the present application do not limit this.

[0157] The "protocol" involved in the embodiments of the present application may refer to a protocol family in the communication field, a standard protocol with a similar protocol family frame structure, or a related protocol used in future communication systems. The embodiments of the present application do not make specific limitations on this.

[0158] In the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device will perform corresponding processing under certain objective circumstances. It does not limit the time, nor does it require the device to perform judgment actions when implemented, nor does it mean that there are other limitations.

[0159] In the description of the embodiments of the present application, unless otherwise specified, " / " indicates that the objects associated with each other are in an "or" relationship. For example, A / B can represent A or B. "And / or" in the embodiments of the present application is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, in the description of the embodiments of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with basically the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0160] The network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field will know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0161] To facilitate understanding of the embodiments of the present application, a security system applicable to the embodiments of the present application will be described in detail using the security system shown in Figure 12 as an example. For example, Figure 12 is a schematic diagram of the architecture of a security system applicable to the homomorphic encryption-based security method provided in the embodiments of the present application.

[0162] As shown in FIG12 , the security system may include at least one of the following: a homomorphic computing entity, a key management entity, a homomorphic task management entity, or a ciphertext data storage entity.

[0163] At least one of the above items may be provided in the same security device, or may be provided in different security devices, without specific limitation. The security device may be a terminal, a network device, or another device with homomorphic capabilities, or a chip within a terminal, a network device, or another device with homomorphic capabilities, or a device that includes a terminal, a network device, or another device with homomorphic capabilities.

[0164] The terminal may be a terminal with transceiver functions, or a chip or chip system that can be set in the terminal. The terminal may also be called user equipment (UE), access terminal, subscriber unit, user station, mobile station (MS), mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device. The terminal in the embodiments of the present application can be a mobile phone, a cellular phone, a smart phone, a tablet computer, a wireless data card, a personal digital assistant (PDA), a wireless modem, a handset, a laptop computer, a machine type communication (MTC) terminal, a computer with wireless transceiver function, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, a vehicle-mounted terminal, a road side unit (RSU) with terminal function, etc. The terminal of the present application may also be an on-board module, on-board module, on-board component, on-board chip or on-board unit built into the vehicle as one or more components or units.

[0165] The network device may be a device in an access network (AN), such as an access network device, or may be referred to as a radio access network device (RAN), which is used to provide network access services to a terminal. For example, the RAN device may include: a next-generation mobile communication system, such as a 6G access network device, such as a 6G base station, or in a next-generation mobile communication system, the network device may also have other naming methods, all of which are included in the protection scope of the embodiments of the present application, and the present application does not impose any restrictions on this. Alternatively, the RAN device may also include 5G, such as a gNB in ​​a new radio (NR) system, or one or a group of antenna panels (including multiple antenna panels) of a base station in 5G, or a network node constituting a gNB, a transmission and reception point (TRP or transmission point, TP) or a transmission measurement function (TMF), such as a baseband unit (BBU), a centralized unit (CU) or a distributed unit (DU), an RSU with base station functions, or a wired access gateway, or a 5G core network element. Alternatively, RAN devices may also include access points (APs) in wireless fidelity (WiFi) systems, wireless relay nodes, wireless backhaul nodes, various forms of macro base stations, micro base stations (also known as small stations), relay stations, access points, wearable devices, vehicle-mounted devices, and the like.

[0166] Alternatively, the network device may also be a device in the core network (CN), such as a user plane function (UPF) network element, an authentication server function (AUSF) network element, an access and mobility management function (AMF) network element, a session management function (SMF) network element, a policy control function (PCF) network element, a unified data management (UDM) network element, an application function (AF), etc., without specific limitation.

[0167] The following will describe in detail the security method based on homomorphic encryption provided in the embodiment of the present application with reference to Figures 13 to 20.

[0168] For example, Figure 13 is a flowchart diagram of a security method based on homomorphic encryption provided in an embodiment of the present application. The security method based on homomorphic encryption can be executed by the device in the security system shown in Figure 12.

[0169] As shown in Figure 13, the security method based on homomorphic encryption includes the following steps:

[0170] S1301, a homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data.

[0171] Symmetrically or asymmetrically encrypted ciphertext data can be ciphertext data sent by a terminal to a network, meaning it can be used in communication scenarios between the terminal and the network, or it can be used in other communication scenarios, without specific limitations. Symmetrically or asymmetrically encrypted ciphertext data generally refers to ciphertext encrypted using a symmetric or asymmetric cryptographic algorithm that does not have homomorphic properties, i.e., symmetrically encrypted ciphertext data or asymmetrically encrypted ciphertext data.

[0172] For example, symmetrically encrypted ciphertext data may be AES ciphertext data, i.e., ciphertext encrypted using the AES algorithm, or DES ciphertext data, i.e., ciphertext encrypted using the Data Encryption Standard (DES) algorithm, or any other possible symmetrical ciphertext data, without limitation. For another example, asymmetrically encrypted ciphertext data may be RSA ciphertext data, i.e., ciphertext encrypted using the RSA algorithm, or DSA ciphertext data, i.e., ciphertext encrypted using the DSA algorithm, or any other possible asymmetric ciphertext data, without limitation.

[0173] For convenience, the plaintext data is recorded as m, and the symmetric or asymmetric encryption key is recorded as K tx , then the symmetric or asymmetric encrypted ciphertext data can be recorded as

[0174] The homomorphic computing entity can receive symmetrically or asymmetrically encrypted ciphertext data from the data entity or the ciphertext data storage entity. That is, after the data entity generates the symmetrically or asymmetrically encrypted ciphertext data, it can send it directly to the homomorphic computing entity. Alternatively, the data entity can also send the symmetrically or asymmetrically encrypted ciphertext data to the ciphertext data storage entity cache, so that the symmetrically or asymmetrically encrypted ciphertext data can be sent to the homomorphic computing entity only when necessary, avoiding wasting communication overhead due to the mistaken sending of symmetrically or asymmetrically encrypted ciphertext data. For example, the ciphertext data storage entity can also send the symmetrically or asymmetrically encrypted ciphertext data to the homomorphic computing entity after storing it for a certain period of time by default. For another example, the ciphertext data storage entity can also send the symmetrically or asymmetrically encrypted ciphertext data to the homomorphic computing entity based on the triggering of the homomorphic task management entity. For details, please refer to the relevant introduction below, which will not be repeated here.

[0175] S1302, the homomorphic computing entity performs homomorphic encryption on the ciphertext data to obtain mixed ciphertext data.

[0176] Homomorphic computing entities can use homomorphic encryption keys to homomorphically encrypt symmetric or asymmetric encrypted ciphertext data to obtain mixed ciphertext data for homomorphic computing. For example, symmetric or asymmetric encrypted ciphertext data is recorded as Then the mixed ciphertext data can be recorded

[0177] Homomorphic encryption keys can be preconfigured or predefined locally on the homomorphic computing entity, allowing them to be directly obtained locally. Alternatively, the homomorphic computing entity can obtain homomorphic encryption keys from the key management entity on demand. The specific implementation is described below and will not be further elaborated here.

[0178] S1303, the homomorphic computing entity performs homomorphic computing symmetric or asymmetric decryption on the mixed ciphertext data to obtain first homomorphic ciphertext data.

[0179] The homomorphic computing entity can use the homomorphic ciphertext of the symmetric or asymmetric decryption key to perform homomorphic computing symmetric or asymmetric decryption on the mixed ciphertext data to obtain the first homomorphic ciphertext data, so that the first homomorphic ciphertext data can be subsequently homomorphically computed.

[0180] The homomorphic ciphertext of the symmetric or asymmetric decryption key can be the ciphertext obtained by homomorphically encrypting the asymmetric decryption key. For example, the symmetric or asymmetric decryption key is denoted as K tx , the homomorphic ciphertext of the symmetric or asymmetric decryption key can be recorded as HE(K tx). The homomorphic ciphertext of the symmetric or asymmetric decryption key can be pre-configured or pre-defined by protocol locally in the homomorphic computing entity, that is, the homomorphic ciphertext of the symmetric or asymmetric decryption key can be directly obtained locally. Alternatively, the homomorphic computing entity can also obtain the homomorphic ciphertext of the symmetric or asymmetric decryption key from the key management entity to achieve on-demand acquisition. The specific implementation can be referred to the relevant introduction below and will not be repeated here.

[0181] It can be understood that since the homomorphic computation performed in the homomorphic ciphertext state is consistent with the computation performed on the plaintext, that is, the symmetric or asymmetric decryption of the homomorphic computation can be regarded as the symmetric or asymmetric decryption of the symmetric or asymmetric encrypted ciphertext data using the symmetric or asymmetric decryption key in the homomorphic encryption state to obtain the corresponding homomorphic ciphertext, that is, the first homomorphic ciphertext data, which can be recorded as HE(m).

[0182] S1304: The homomorphic computing entity performs a homomorphic computing function f on the first homomorphic ciphertext data to obtain second homomorphic ciphertext data.

[0183] The homomorphic computing entity can use the homomorphic computing key to homomorphically compute function f on the first homomorphic ciphertext data to obtain second homomorphic ciphertext data. This means that the result obtained in the ciphertext state is consistent with the result obtained by directly computing the plaintext. The second homomorphic ciphertext data can be denoted as HE(f(m)). Function f can be an artificial intelligence algorithm or a compressed sensing algorithm, which is not limited here.

[0184] Homomorphic computing keys can be preconfigured or predefined locally on the homomorphic computing entity, meaning they can be directly obtained locally. Alternatively, the homomorphic computing entity can obtain the homomorphic computing key from the key management entity on demand. The specific implementation is described below and will not be elaborated here.

[0185] S1305, the homomorphic computing entity sends the second homomorphic ciphertext data.

[0186] The homomorphic computing entity can send the second homomorphic ciphertext data to the using entity or the decrypting entity. That is to say, if the using entity has the homomorphic decryption capability, such as the using entity and the decrypting entity are the same entity (jointly set up), then the homomorphic computing entity can send the second homomorphic ciphertext data directly to the using entity. Otherwise, if the using entity and the decrypting entity are different entities (separately set up), the homomorphic computing entity needs to send the second homomorphic ciphertext data to the decrypting entity, and the decryption entity performs homomorphic decryption. The decryption entity is another entity different from the homomorphic computing entity, and homomorphic computing and homomorphic decryption can be performed by different entities respectively to achieve privacy protection. The details are introduced below.

[0187] Case 1:

[0188] In the case where the using entity and the decryption entity are co-located, the using entity can use the homomorphic decryption key to homomorphically decrypt the second homomorphic ciphertext data to obtain the plaintext data after the function calculation. For example, the plaintext data after the function calculation can be recorded as f(m). In this case, the homomorphic decryption key can be pre-configured or pre-defined by the protocol locally in the using entity, that is, the homomorphic decryption key can be obtained directly from the local. Alternatively, the using entity can also obtain the homomorphic decryption key from the key management entity to achieve on-demand acquisition. For the specific implementation, please refer to the relevant introduction below, which will not be repeated here.

[0189] Case 2:

[0190] When the using entity and the decrypting entity are separate, the decrypting entity can use the homomorphic decryption key to homomorphically decrypt the second homomorphic ciphertext data to obtain the plaintext data after the function calculation. The decrypting entity can use the symmetric or asymmetric encryption key to symmetrically or asymmetrically encrypt the plaintext data after the function calculation to obtain the symmetric or asymmetric encrypted ciphertext data. The decrypting entity can send the symmetric or asymmetric encrypted ciphertext data to the using entity. The using entity can use the symmetric or asymmetric decryption key to symmetric or asymmetric decrypt the symmetric or asymmetric encrypted ciphertext data to obtain the plaintext data after the function calculation.

[0191] It can be understood that in this case, the homomorphic decryption key and / or the symmetric or asymmetric encryption key can be pre-configured or pre-defined by protocol locally in the decryption entity, that is, the homomorphic decryption key and / or the symmetric or asymmetric encryption key can be directly obtained locally. Alternatively, the decryption entity can also obtain the homomorphic decryption key and / or the symmetric or asymmetric encryption key from the key management entity to achieve on-demand acquisition. For specific implementation, please refer to the relevant introduction below, which will not be repeated here. Similarly, the symmetric or asymmetric decryption key can be pre-configured or pre-defined by protocol locally in the using entity, that is, the symmetric or asymmetric decryption key can be directly obtained locally. Alternatively, the using entity can also obtain the symmetric or asymmetric decryption key from the key management entity to achieve on-demand acquisition. For specific implementation, please refer to the relevant introduction below, which will not be repeated here.

[0192] In summary, a homomorphic computing entity is typically a device with relatively high performance. The homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data sent by a data entity (i.e., the data sender), rather than homomorphic ciphertext, and obtains mixed ciphertext data through homomorphic encryption. By executing the efficient homomorphic computing method designed in this application based on Boolean homomorphic encryption and AES decryption, the homomorphic computing entity obtains homomorphic ciphertext for subsequent homomorphic computing, thereby reducing the performance requirements and communication overhead of homomorphic encryption on the data sender.

[0193] Optionally, in a first possible design solution, in combination with S1301 to S1305 above, the method further includes:

[0194] Step 11: The homomorphic task management entity receives a homomorphic task request message from the user entity.

[0195] Among them, the homomorphic task request message indicates the homomorphic task requested by the using entity, and the homomorphic task request message may include the identifier of the using entity and the identifier of the homomorphic task, which are used to jointly indicate that the using entity requests to perform the homomorphic task. The homomorphic task management entity can assign a homomorphic computing entity to perform the homomorphic task for the homomorphic task, that is, the homomorphic computing entity in S1301-S1305 above. For example, the homomorphic task management entity can select a homomorphic computing entity with a relatively low current load or idle as the homomorphic computing entity to perform the homomorphic task.

[0196] In step 12, the homomorphic task management entity sends a homomorphic task key request message to the key management entity according to the homomorphic task request. The key management entity receives the homomorphic task key request message from the homomorphic task management entity.

[0197] The homomorphic task key request message is used to request the key management entity to derive and allocate relevant keys for the homomorphic task, such as including the above-mentioned homomorphic computing entity identifier and homomorphic task identifier, to request the key management entity to allocate the relevant keys for the homomorphic task to the homomorphic computing entity.

[0198] In step 13, the key management entity sends the homomorphic task-related key to the homomorphic computing entity that executes the homomorphic task based on the homomorphic task key request message.

[0199] The keys related to the homomorphic task include at least one of the following: the homomorphic ciphertext of the above-mentioned symmetric or asymmetric key, the above-mentioned homomorphic encryption key, or the above-mentioned homomorphic computing key. The key management entity can determine the keys related to the homomorphic task based on the cryptographic capability information of the homomorphic computing entity reported in advance by the homomorphic computing entity. Among them, the cryptographic capability information of the homomorphic computing entity can be used to indicate whether the homomorphic computing entity supports homomorphic encryption capability and whether it supports homomorphic computing capability. For example, the cryptographic capability information of the homomorphic computing entity is a 2-bit bitmap, in which the two values ​​of 0 / 1 of one bit are respectively used to indicate whether the homomorphic computing entity supports homomorphic encryption capability, and the two values ​​of 0 / 1 of the other bit are respectively used to indicate whether the homomorphic computing entity supports homomorphic computing capability. If the cryptographic capability information of the homomorphic computing entity indicates that the homomorphic computing entity supports homomorphic encryption capability and homomorphic computing capability, the key management entity can generate a homomorphic ciphertext of a symmetric or asymmetric key, a homomorphic encryption key, or a homomorphic computing key. Of course, the key management entity may also assume that the homomorphic computing entity supports homomorphic encryption capabilities and homomorphic computing capabilities, thereby generating keys related to homomorphic tasks.

[0200] According to the above steps 11 to 13, the homomorphic task management entity only requests the key management entity to allocate the relevant keys when the user entity has a demand to avoid communication redundancy. Of course, the key management entity can also allocate the relevant keys by default.

[0201] Optionally, in a second possible design solution, in combination with the above S1301 to S1305, the method further includes:

[0202] In step 21, the key management entity receives cryptographic capability information from the data entity.

[0203] The cryptographic capability information of a data entity can be used to indicate whether the data entity supports symmetric or asymmetric encryption capabilities. For example, the cryptographic capability information of a data entity is a 1-bit information element, and its two values ​​of 0 / 1 are used to indicate whether the data entity supports symmetric or asymmetric encryption capabilities, respectively. In addition, the cryptographic capability information of a data entity can be carried in any possible signaling, without limitation.

[0204] In step 22, the key management entity sends a symmetric or asymmetric encryption key to the data entity according to the cryptographic capability information of the data entity.

[0205] Symmetric or asymmetric encryption keys can be used by data entities to generate symmetrically or asymmetrically encrypted ciphertext data (for details, see S1301 above). The key management entity can generate a symmetric or asymmetric encryption key and issue the key to the data entity if the data entity's cryptographic capability information indicates that the data entity supports symmetric or asymmetric encryption. This avoids wasting communication overhead by sending the key even if the data entity does not support symmetric or asymmetric encryption. Furthermore, the symmetric or asymmetric encryption key can be carried in any possible signaling, without limitation.

[0206] It can be understood that steps 21 and 22 are optional steps. If the key management entity assumes that the data entity supports symmetric or asymmetric encryption capabilities, the data entity does not need to report the data entity's cryptographic capability information.

[0207] Optionally, in a third possible design solution, in combination with S1301 to S1305 above, for the above situation 1, that is, the use entity and the decryption entity are provided together, the method further includes:

[0208] In step 31, the key management entity receives cryptographic capability information from the user entity.

[0209] The cryptographic capability information of a user entity can be used to indicate whether the user entity supports homomorphic decryption capabilities. For example, the cryptographic capability information of the user entity is a 1-bit information element, and its two values ​​of 0 / 1 are used to indicate whether the user entity supports homomorphic decryption capabilities. In addition, the cryptographic capability information of the user entity can be carried in any possible signaling, without limitation.

[0210] In step 32, the key management entity sends the homomorphic decryption key to the user entity according to the cryptographic capability information of the user entity.

[0211] The homomorphic decryption key can be used by the user entity to homomorphically decrypt homomorphic ciphertext data (such as the second homomorphic ciphertext data described above). The key management entity can generate a homomorphic decryption key and issue the same to the user entity if the user entity's cryptographic capability information indicates that the user entity supports homomorphic decryption capabilities, thereby avoiding wasting communication overhead by still sending the same decryption key when the user entity does not support homomorphic decryption capabilities. Furthermore, the homomorphic decryption key can be carried in any possible signaling, without limitation.

[0212] It can be understood that steps 31 and 32 are optional steps. If the key management entity defaults to the user entity supporting homomorphic decryption capabilities, the user entity does not need to report the cryptographic capability information of the user entity.

[0213] Alternatively, for the above situation 2, that is, the using entity and the decrypting entity are separately provided, the method further includes:

[0214] In step 41, the key management entity receives cryptographic capability information from the decryption entity.

[0215] The cryptographic capability information of the decryption entity can be used to indicate whether the decryption entity supports homomorphic decryption capability and whether it supports symmetric or asymmetric encryption capability. For example, the cryptographic capability information of the decryption entity is a 2-bit bitmap, where the two values ​​of 0 / 1 of one bit are used to indicate whether the decryption entity supports homomorphic decryption capability, and the two values ​​of 0 / 1 of the other bit are used to indicate whether the decryption entity supports symmetric or asymmetric encryption capability. In addition, the cryptographic capability information of the decryption entity can be carried in any possible signaling, without limitation.

[0216] In step 42, the key management entity sends the symmetric or asymmetric encryption key and the homomorphic decryption key to the decryption entity according to the cryptographic capability information of the decryption entity.

[0217] The homomorphic decryption key can be used by the decryption entity to perform homomorphic decryption on homomorphic ciphertext data (such as the second homomorphic ciphertext data mentioned above). Symmetric or asymmetric encryption keys can be used by the decryption entity to perform symmetric or asymmetric encryption on plaintext data (such as the plaintext data after the above function calculation). Among them, the key management entity can generate a homomorphic decryption key when the cryptographic capability information of the decryption entity indicates that the decryption entity supports homomorphic decryption capability, and send the homomorphic decryption key to the decryption entity, so as to avoid wasting communication overhead by sending the homomorphic decryption key when the decryption entity does not support homomorphic decryption capability. In addition, the homomorphic decryption key can be carried in any possible signaling, and there is no limitation on this. Similarly, the key management entity can also generate a symmetric or asymmetric encryption key when the cryptographic capability information of the decryption entity indicates that the decryption entity supports symmetric or asymmetric encryption capability, and send the symmetric or asymmetric encryption key to the decryption entity, so as to avoid wasting communication overhead by sending the symmetric or asymmetric encryption key when the decryption entity does not support symmetric or asymmetric encryption capability. In addition, the symmetric or asymmetric encryption key can be carried in any possible signaling, and there is no limitation on this.

[0218] It can be understood that steps 41 and 42 are optional steps. If the key management entity assumes that the decryption entity supports symmetric or asymmetric encryption capabilities and homomorphic decryption capabilities, the decryption entity does not need to report the cryptographic capability information of the decryption entity.

[0219] In step 43, the key management entity receives the cryptographic capability information from the user entity.

[0220] The cryptographic capability information of a user entity can be used to indicate whether the user entity supports symmetric or asymmetric decryption capabilities. For example, the cryptographic capability information of the user entity is a 1-bit information element, and its two values ​​of 0 / 1 are used to indicate whether the user entity supports symmetric or asymmetric decryption capabilities, respectively. In addition, the cryptographic capability information of the user entity can be carried in any possible signaling, without limitation.

[0221] In step 44, the key management entity sends a symmetric or asymmetric decryption key to the user entity according to the cryptographic capability information of the user entity.

[0222] The symmetric or asymmetric decryption key can be used by the user entity to decrypt symmetrically or asymmetrically encrypted ciphertext data (for details, see S1305 above). The key management entity can generate a symmetric or asymmetric decryption key and issue the key to the user entity if the user entity's cryptographic capability information indicates that the user entity supports symmetric or asymmetric decryption capabilities. This avoids wasting communication overhead by sending the symmetric or asymmetric decryption key when the user entity does not support symmetric or asymmetric decryption capabilities. Furthermore, the symmetric or asymmetric decryption key can be carried in any possible signaling, without limitation.

[0223] It is understood that steps 43 and 44 are also optional. For example, if the key management entity defaults to the user entity supporting symmetric or asymmetric decryption capabilities, the user entity does not need to report its cryptographic capability information. Furthermore, the order in which steps 41 and 42 and steps 43 and 44 are performed is not limited.

[0224] Optionally, a fourth possible design scheme, in combination with the above S1301-S1305, when the symmetrically or asymmetrically encrypted ciphertext data is cached by the ciphertext data storage entity, the homomorphic task management entity may also send a ciphertext sending task configuration message to the ciphertext data storage entity. For example, after receiving the above-mentioned homomorphic task request, or at any possible opportunity, the homomorphic task management entity may send a ciphertext sending task configuration message to the ciphertext data storage entity, such as carrying the identifier of the homomorphic task, to trigger the ciphertext data storage entity to send ciphertext data to the homomorphic computing entity, or the ciphertext data of the homomorphic task indicated by the identifier of the homomorphic task. In this way, the ciphertext data storage entity can send corresponding ciphertext data, such as the above-mentioned symmetrically or asymmetrically encrypted ciphertext data, to the homomorphic computing entity according to the task configuration message.

[0225] It can be understood that since the ciphertext data can be cached by the ciphertext data storage entity, the ciphertext data can be reused to maximize the utilization value of the ciphertext data.

[0226] The overall process of the communication method is introduced above in conjunction with Figure 13. The application of the communication method in specific scenarios is introduced below in conjunction with Figures 14 to 16.

[0227] Scenario 1:

[0228] The above method can be applied to cloud computing, outsourced computing and other scenarios to perform homomorphic AES encryption and decryption. The details are described below.

[0229] As shown in Figure 14, this scenario involves the interaction between the key management center (KMC), data party A, and computing party B. KMC can be the key management entity mentioned above. Data party A can be the data entity mentioned above, specifically a terminal such as UE, or other entities / network elements of the communication network. Computing party B can be the homomorphic computing entity mentioned above, specifically an access network (AN) device, such as a base station (BS), a core network (CN) network element, such as an AMF network element, an SMF network element, etc., or other third-party devices, such as an edge node computing (MEC) entity, or other communication network entities / network elements.

[0230] In this scenario, data provider A encrypts a large amount of collected sensitive data using AES and sends it to computing provider B. Computing provider B then performs complex homomorphic computations on the data to generate low-rate data streams such as corresponding control instructions, and then sends the computation results in the form of homomorphic ciphertext to data provider A. The specific process is as follows:

[0231] 1) KMC can derive homomorphic encryption keys, homomorphic decryption keys, and homomorphic computation keys. KMC can distribute homomorphic encryption keys and homomorphic decryption keys to data party A. KMC can also distribute homomorphic encryption keys and homomorphic computation keys to computation party B. In addition, AES keys (such as K AES ) can be derived by KMC and distributed to data party A, or generated locally by data party A, without limitation.

[0232] 2) Data party A can perform homomorphic encryption on the AES key based on the homomorphic encryption key to obtain the homomorphic ciphertext of the AES key, such as HE(K AES ). The data party can send the homomorphic ciphertext of the AES key to the computing party B.

[0233] 3) Data party A can perform AES symmetric encryption on the plaintext data (such as m) based on the AES key to obtain the AES ciphertext, such as Data party A can send AES ciphertext to computing party B. After receiving it, computing party B can perform homomorphic encryption on the AES ciphertext based on the homomorphic encryption key to obtain a mixed ciphertext, such as

[0234] 4) The computing party B can perform homomorphic calculation on the mixed ciphertext based on the homomorphic ciphertext of the AES key and obtain the first homomorphic ciphertext, such as HE(m).

[0235] 5) Computing party B can use the first homomorphic ciphertext HE(m) as input to perform homomorphic computation (e.g., computing function f) to obtain a second homomorphic ciphertext after homomorphic computation, such as HE(f(m)). The second homomorphic ciphertext can be a low-rate data stream. Computing party B can send the second homomorphic ciphertext to data party A.

[0236] 6) Data party A can perform homomorphic decryption on the second homomorphic ciphertext based on the homomorphic decryption key to obtain plaintext data, such as f(m).

[0237] The specific implementation of the above scenario 1 can also refer to the relevant introduction of Figure 13 above, which will not be repeated here.

[0238] Scenario 2:

[0239] The above method can be applied to cloud collaboration and other scenarios to perform homomorphic computing symmetric / asymmetric encryption and decryption. The details are described below.

[0240] As shown in Figures 15 and 16, this scenario involves the KMC, data party A, ciphertext data storage management (CDSM), homomorphic encryption task management (HETM), computing party, decryption party, and user party B. The KMC can be the key management entity mentioned above. Data party A can be the data entity mentioned above, specifically a terminal such as a UE, or other communication network entity / network element. The CDSM can be the ciphertext data storage management entity mentioned above. The HETM can be the homomorphic task management entity mentioned above. The computing party can be the homomorphic computing entity mentioned above, specifically an access network (AN) device such as a base station (BS), a core network (CN) network element such as an AMF network element or SMF network element, or other third-party devices such as an edge node computing (MEC) entity, or other communication network entity / network element. The KMC, CDSM, HETM, etc. can be entities / network elements belonging to the communication network. The decryption party can be the decryption entity mentioned above, specifically the cloud or other computing party, or other communication network entity / network element. The user B may be the aforementioned user entity, specifically a cloud, or an entity / network element of other communication networks.

[0241] In this scenario, data party A sends a large amount of collected sensitive data to the communication network after symmetric or asymmetric encryption. The communication network performs complex homomorphic computations and sends the data to the decryption party or user. The decryption party performs homomorphic decryption and then sends the data to user B. Alternatively, user B directly performs homomorphic decryption to obtain the plaintext data. The specific process includes the following:

[0242] S1601: Establish a secure channel and negotiate cryptographic capabilities.

[0243] A secure channel, or a secure connection, can be established in advance between the data party A, the computing party, the decrypting party, and the user B and the KMC. The secure connection can be any possible secure connection, and the embodiments of the present application do not limit its specific implementation. Based on the secure connection, the data party A, the computing party, the decrypting party, and the user B can report their respective cryptographic capability information to the KMC. Among them, the cryptographic capability information of the data party A can be used to indicate whether the data party A supports symmetric or asymmetric encryption capabilities, and the cryptographic capability information of the computing party can be used to indicate whether the computing party supports homomorphic encryption capabilities and homomorphic computing capabilities. In the case where the decrypting party and the user B are jointly established, the cryptographic capability information of the decrypting party can be used to indicate whether the decrypting party supports homomorphic decryption capabilities. In the case where the decrypting party and the user B are separately established, the cryptographic capability information of the decrypting party can be used to indicate whether the decrypting party supports homomorphic decryption capabilities and symmetric or asymmetric encryption capabilities, and the cryptographic capability information of the user B can be used to indicate whether the user B supports symmetric or asymmetric decryption capabilities.

[0244] In addition, the specific implementation of S1601 can also refer to the relevant introduction of the above steps 13, 21, 31, 41, and 43, which will not be repeated here.

[0245] S1602, KMC sends the encryption key to data party A.

[0246] The encryption key can be a symmetric or asymmetric encryption key. For example, if data party A supports symmetric or asymmetric encryption capabilities, the KMC generates a symmetric or asymmetric encryption key and sends the symmetric or asymmetric encryption key to data party A.

[0247] In addition, the specific implementation of S1602 can also refer to the relevant introduction of the above step 21, which will not be repeated here.

[0248] S1603, KMC sends the decryption key to the decryption party and / or user B.

[0249] The decryption key may include a homomorphic decryption key, or may also include a homomorphic decryption key, a symmetric or asymmetric encryption key, and a symmetric or asymmetric decryption key. For example, when the decryption party and user B are jointly established, the decryption party supports homomorphic decryption capability, KMC generates a homomorphic decryption key, and sends the homomorphic decryption key to the decryption party. For another example, when the decryption party and user B are separately established, the decryption party supports homomorphic decryption capability and symmetric or asymmetric encryption capability, KMC generates a homomorphic decryption key and a symmetric or asymmetric encryption key, and sends the homomorphic decryption key and symmetric or asymmetric encryption key to the decryption party. And, user B supports symmetric or asymmetric decryption capability, KMC generates a symmetric or asymmetric decryption key, and sends the symmetric or asymmetric decryption key to user B.

[0250] In addition, the specific implementation of S1603 can also refer to the relevant introduction of step 31, step 41, and step 43, which will not be repeated here.

[0251] It is understandable that the execution order between S1602 and S1603 is not limited.

[0252] S1604, data party A performs symmetric or asymmetric encryption.

[0253] Data party A can perform symmetric or asymmetric encryption on plaintext data based on symmetric or asymmetric encryption keys to obtain symmetric or asymmetric ciphertext data.

[0254] S1605: Data party A sends symmetric or asymmetric ciphertext data to CDSM.

[0255] S1606, CDSM stores symmetric or asymmetric ciphertext data.

[0256] Among them, the specific implementation of S1604-S1606 can refer to the above-mentioned S1301 and the related introduction of the fourth possible design solution, which will not be repeated here.

[0257] S1607, HETM obtains homomorphic tasks and arranges the homomorphic tasks.

[0258] The HETM may receive a homomorphic task request message from a user B, where the homomorphic task request message may indicate a homomorphic task requested by the user B. The HETM may orchestrate the homomorphic task according to the homomorphic task request message, such as assigning a corresponding computing party to the homomorphic task.

[0259] S1608, HETM sends a homomorphic task key request message to KMC.

[0260] The homomorphic task key request message can be used by the KMC to derive and distribute related keys for the homomorphic task.

[0261] S1609, KMC generates keys related to homomorphic tasks.

[0262] The KMC can generate keys related to homomorphic tasks based on the homomorphic task key request message and the cryptographic capability information previously reported by the computing party. For example, if the computing party supports homomorphic encryption and homomorphic computation, the KMC can derive homomorphic ciphertexts, homomorphic encryption keys, and homomorphic computation keys for symmetric or asymmetric keys.

[0263] S1610, KMC sends the key related to homomorphic task allocation to the computing party.

[0264] The specific implementation of S1607-S1610 can also refer to the relevant introduction of the above steps 11-13, which will not be repeated here.

[0265] S1611, HETM sends a ciphertext sending task configuration message to CDSM.

[0266] The ciphertext sending task configuration message may be used to instruct the CDSM to send pre-stored ciphertext data, such as symmetric or asymmetric ciphertext data, to the computing party.

[0267] S1612, CDSM sends symmetric or asymmetric ciphertext data to the computing party.

[0268] The specific implementation of S16011-S1612 can also refer to the relevant introduction of the fourth possible design solution mentioned above, which will not be repeated here.

[0269] S1613, the computing party performs homomorphic encryption.

[0270] The computing party can perform homomorphic encryption on symmetric or asymmetric ciphertext data based on the homomorphic encryption key to obtain mixed ciphertext data. The specific implementation can also refer to the relevant introduction of S1302 above, which will not be repeated here.

[0271] S1614, the computing party performs homomorphic computing symmetric or asymmetric decryption.

[0272] The computing party can perform homomorphic symmetric or asymmetric decryption on the mixed ciphertext data based on the homomorphic ciphertext of the symmetric or asymmetric key to obtain the first homomorphic ciphertext data. The specific implementation can also refer to the relevant introduction of S1303 above, which will not be repeated here.

[0273] S1615, the computing party executes the homomorphic computing function f.

[0274] The computing party can perform a homomorphic computing function f on the first homomorphic ciphertext data based on the homomorphic computing key to obtain the second homomorphic ciphertext data. The specific implementation can also refer to the relevant introduction of S1304 above, which will not be repeated here.

[0275] S1616, the computing direction sends the second homomorphic ciphertext data to the decryption party.

[0276] S1617, the decryption party performs decryption.

[0277] When the decryption party and user B are jointly established, the decryption party can use the homomorphic decryption key to homomorphically decrypt the second homomorphic ciphertext data to obtain the plaintext data after function calculation. The specific implementation can also refer to the relevant introduction of the above situation 1, which will not be repeated here.

[0278] In the case where the decryption party and user B are separated, the decryption party can use the homomorphic decryption key to homomorphically decrypt the second homomorphic ciphertext data to obtain the plaintext data after the function calculation. The decryption party can also use a symmetric or asymmetric encryption key to encrypt the plaintext data after the function calculation to obtain symmetric or asymmetric encrypted ciphertext data. The decryption direction sends the symmetric or asymmetric encrypted ciphertext data to user B, and user B uses the symmetric or asymmetric decryption key to symmetric or asymmetric decrypt the symmetric or asymmetric encrypted ciphertext data to obtain the plaintext data after the function calculation. For specific implementation, please refer to the relevant introduction of Case 2 above, which will not be repeated here.

[0279] For example, Figure 17 is a flowchart diagram of a third embodiment of a security method based on homomorphic encryption provided by an embodiment of the present application. The security method based on homomorphic encryption can be executed by the device in the security system shown in Figure 12.

[0280] As shown in Figures 17 and 18, the security method based on homomorphic encryption includes the following steps:

[0281] S1701, obtaining the first state of the ciphertext data.

[0282] S1702: Based on the first state, perform homomorphic calculations of round key addition, row shift, and column obfuscation of AES encryption / decryption in level 0 of the hierarchical homomorphic computing mode to obtain a second state.

[0283] Round key addition: perform an XOR operation and set the plaintext modulus to 2. For details, please refer to the above "1) Round key addition" and will not be repeated here.

[0284] Row shift: Select the corresponding ciphertext position in the input and assign it to the output result. For details, please refer to the relevant introduction of "3) Row shift" above, which will not be repeated here.

[0285] Column confusion: In column confusion, each column in the state (intermediate result) can be regarded as The result s′(x) of multiplying the polynomial s(x) on the fixed polynomial a(x) is the output of column confusion. It represents GF(2 8 ), also known as the Galois field, or modular multiplication of polynomials over a finite field. For example, as shown in Figure 19, define b0, b1, b2, b3, b4, b5, b6, and b7 to represent the order from the low-order bit to the high-order bit in a byte. Their multiplication with the polynomial (x+1) can be represented as the third row of Figure 19, which can be completed with two XOR operations. It can be deduced that all column obfuscation operations can be converted to XOR operations.

[0286] S1703 : Based on the second state, calculate the multi-valued function bootstrapping from level 0 to level 2 and the privacy key switching from level 2 to level 1 to obtain the third state of level 1.

[0287] The present invention replaces the first step of bootstrapping the first function in conventional circuit bootstrapping with a multi-value bootstrapping operation, also known as PBSmanyLUT. PBSmanyLUT first uses modulo switching to set the corresponding lowest bits to zero, so that all function values ​​can be encoded in the test polynomial. Then, a blind rotation is performed to obtain all desired function values, as follows:

[0288] The test polynomial P(x) sets a new test polynomial for PBSmanyLUT, as shown in Equation 5 below.

[0289] in, l refers to the l independent function bootstraps required in the original circuit bootstrap. A level 0 TLWE ciphertext, such as ct in , and a bootstrapping key from level 0 to level 2, such as BSK. In addition, due to the way messages are encoded on Torus It is necessary to set a test polynomial P(x) that satisfies the negative cycle property. The test polynomial is used in the PBSmanyLUT module. is the basis of gadget, as shown in Equation 6 below.

[0290] S1704: Based on the third state, perform byte-replacement homomorphic computation of AES encryption / decryption in level 1 of the hierarchical homomorphic computation mode to obtain a fourth state.

[0291] The byte substitution in AES encryption / decryption is performed based on a hybrid packed lookup. For example, the hybrid packed lookup includes: the input of the S-box is the third state, the output of the S-box is packed into two TRLWE ciphertexts using a pre-packing technique, a target TRLWE ciphertext is selected from the two TRLWE ciphertexts using a CMUX gate, and the target TRLWE ciphertext is blindly rotated using seven CMUX gates to obtain the fourth state.

[0292] For example, as shown in FIG20, the input bits are x0…x d-1 , d=8, that is, the third state, the output value of the S box is f0…f s-1 , s = 8, and the ring polynomial dimension N = 1024. If the hybrid packed lookup table technique is used to implement the byte substitution step in homomorphic computation of AES encryption and decryption, 8 CMUX gates are usually required to implement the homomorphic computation of the S-box, as follows:

[0293] 1) Pre-packaging: As shown in Figure 20, there are 256 lines of S-box output values, each line of output values ​​is f0…f s-1 ,s=8. Use mixed packing (i.e., horizontal and vertical packing) to pack all 2048 (2 d s = 2 8 *8 = 2048 = 2·N) S-box output values ​​are packaged into two noise-free TRLWE ciphertexts, where the ring polynomial dimension of each ciphertext is N = 1024. The two packaged TRLWE ciphertexts are then labeled p0 and p1 respectively.

[0294] 2) Input bits are x0…x d-1 ,d=8, the ciphertext form is TRGSW, and the 8 TRGSW ciphertexts are marked as C0, C1, C2, C3, C4, C5, C6, C7.

[0295] 3) First based on the most significant bit x d-1 Select (implemented with a CMUX gate) and output the desired target TRLWE ciphertext, that is, select the output target TRLWE ciphertext p0 or p1 based on the TRGSW ciphertext C7.

[0296] 4) Based on the remaining 7 bits x0,…,x d-2 The corresponding TRGSW ciphertexts C0, C1, C2, C3, C4, C5, and C6 are blindly rotated on the target TRLWE ciphertext p0 or p1 (implemented through 7 CMUX gates), and the desired result is rotated to the first eight coefficients of the plaintext polynomial corresponding to the TRLWE ciphertext to obtain the output, which is the fourth state.

[0297] Afterwards, sample extraction and key switching from level 1 to level 0 may be performed on the fourth state to obtain a new first state of level 0.

[0298] In summary, the hierarchical homomorphic computing mode currently has the lowest bootstrap delay among fully homomorphic encryption schemes. Therefore, AES encryption / decryption can be applied to the hierarchical homomorphic computing mode, such as performing homomorphic calculations of round key addition, row shift, and column confusion for AES encryption / decryption in level 0 of the hierarchical homomorphic computing mode, and performing byte replacement for AES encryption / decryption in level 1 of the hierarchical homomorphic computing mode. Compared with the homomorphic calculation scheme of AES encryption / decryption in the prior art, it can reduce latency and memory consumption and improve computing efficiency.

[0299] The above describes in detail the security method based on homomorphic encryption provided by the embodiment of the present application in conjunction with Figures 13 to 20. The following describes in detail the security device for executing the security method based on homomorphic encryption provided by the embodiment of the present application in conjunction with Figures 21 and 22.

[0300] Figure 21 is a structural diagram of a security device according to an embodiment of the present application. As shown in Figure 21 , the security device 2100 includes a transceiver module 2101 and a processing module 2102. For ease of illustration, Figure 21 only shows the main components of the security device 2100.

[0301] In some embodiments, the security device 2100 can perform the functions of the homomorphic computing entity in the above method.

[0302] For example, the transceiver module 2101 is used to receive symmetrically or asymmetrically encrypted ciphertext data; the processing module 2102 is used to perform homomorphic encryption on the ciphertext data to obtain mixed ciphertext data; the processing module 2102 is used to perform homomorphic calculation symmetrically or asymmetrical decryption on the mixed ciphertext data to obtain first homomorphic ciphertext data; the processing module 2102 is used to perform homomorphic calculation function f on the first homomorphic ciphertext data to obtain second homomorphic ciphertext data; the transceiver module 2101 is used to send the second homomorphic ciphertext data.

[0303] In one possible design, processing module 2102 is further configured to perform homomorphic encryption on symmetrically or asymmetrically encrypted ciphertext data using a homomorphic encryption key to obtain mixed ciphertext data. Symmetrically or asymmetrically encrypted ciphertext data refers to ciphertext encrypted using a symmetric or asymmetric cryptographic algorithm that does not have homomorphic properties.

[0304] Optionally, the transceiver module 2101 is further used to obtain a homomorphic encryption key from a key management entity.

[0305] In one possible design, the processing module 2102 is further configured to perform homomorphic symmetric or asymmetric decryption on the mixed ciphertext data using a homomorphic ciphertext with a symmetric or asymmetric decryption key to obtain first homomorphic ciphertext data.

[0306] Optionally, the transceiver module 2101 is further configured to obtain a homomorphic ciphertext of a symmetric or asymmetric decryption key from a key management entity.

[0307] In one possible design, the processing module 2102 is further configured to use the homomorphic computing key to perform a homomorphic computing function f on the first homomorphic ciphertext data to obtain second homomorphic ciphertext data.

[0308] Optionally, the transceiver module 2101 is also used to obtain a homomorphic computing key from a key management entity.

[0309] In one possible design, the transceiver module 2101 is further configured to receive a homomorphic task configuration message from the homomorphic task management entity, wherein the homomorphic task configuration message is used to instruct the homomorphic computing entity to execute a corresponding homomorphic computing task.

[0310] In a possible design solution, the transceiver module 2101 is further configured to receive symmetrically or asymmetrically encrypted ciphertext data from a data entity or a ciphertext data storage entity.

[0311] In one possible design, the transceiver module 2101 is further configured to send the second homomorphic ciphertext data to the user entity or the decryption entity.

[0312] In one possible design, the symmetrically or asymmetrically encrypted ciphertext data is the ciphertext data sent by the terminal to the network.

[0313] In one possible design scheme, the homomorphic computing entity is any one of the following: base station BS, core network CN network element, edge node computing MEC entity, which can be selected according to actual conditions and is not specifically limited.

[0314] Optionally, the transceiver module 2101 may include a sending module (not shown in FIG21 ) and a receiving module (not shown in FIG21 ). The sending module is used to implement the sending function of the security device 2100 , and the receiving module is used to implement the receiving function of the security device 2100 .

[0315] Optionally, the security device 2100 may further include a storage module (not shown in FIG. 21 ) storing a program or instruction. When the processing module 2102 executes the program or instruction, the security device 2100 may perform the functions of the above method.

[0316] It can be understood that the security device 2100 can be a terminal, a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in a terminal, a network device, or other device that can perform homomorphic tasks, or a device that includes a terminal, a network device, or other device that can perform homomorphic tasks. This application does not limit this.

[0317] In addition, the technical effects of the safety device 2100 can be the same as the technical effects of the above-mentioned method, which will not be repeated here.

[0318] In other embodiments, the security device 2100 can perform the functions of the key management entity in the above method.

[0319] The transceiver module 2101 is configured to receive a homomorphic task key request message from the homomorphic task management entity, and the processing module 2102 is configured to control the transceiver module 2101 to send the homomorphic task-related key to the homomorphic computing entity executing the homomorphic task based on the homomorphic task key request message. The homomorphic task key request message is used to request the key management entity to derive and allocate the relevant key for the homomorphic task.

[0320] The keys associated with homomorphic tasks include at least one of the following: homomorphic ciphertext of a symmetric or asymmetric key, a homomorphic encryption key, or a homomorphic computation key.

[0321] In one possible design, transceiver module 2101 is further configured to receive cryptographic capability information from a data entity, and processing module 2102 is further configured to control transceiver module 2101 to send a symmetric or asymmetric encryption key to the data entity based on the cryptographic capability information of the data entity. The cryptographic capability information of the data entity indicates whether the data entity supports symmetric or asymmetric encryption capabilities.

[0322] In one possible design, transceiver module 2101 is further configured to receive cryptographic capability information from a decryption entity, and processing module 2102 is further configured to control transceiver module 2101 to send a symmetric or asymmetric encryption key and a homomorphic decryption key to the decryption entity based on the cryptographic capability information of the decryption entity. The cryptographic capability information of the decryption entity indicates that the decryption entity supports homomorphic decryption capabilities and symmetric or asymmetric encryption capabilities.

[0323] Optionally, the decryption entity is another entity different from the homomorphic computation entity.

[0324] Optionally, the transceiver module 2101 is further configured to receive cryptographic capability information from a user entity, and the processing module 2102 is further configured to control the transceiver module 2101 to send a symmetric or asymmetric decryption key to the user entity based on the cryptographic capability information of the user entity. The cryptographic capability information of the user entity is used to indicate whether the user entity supports symmetric or asymmetric decryption capabilities.

[0325] In one possible design, transceiver module 2101 is further configured to receive cryptographic capability information from a user entity, and processing module 2102 is further configured to control transceiver module 2101 to send a homomorphic decryption key to the user entity based on the cryptographic capability information of the user entity. The cryptographic capability information of the user entity is used to indicate that the user entity supports homomorphic decryption capabilities.

[0326] Optionally, the transceiver module 2101 may include a sending module (not shown in FIG21 ) and a receiving module (not shown in FIG21 ). The sending module is used to implement the sending function of the security device 2100 , and the receiving module is used to implement the receiving function of the security device 2100 .

[0327] Optionally, the security device 2100 may further include a storage module (not shown in FIG. 21 ) storing a program or instruction. When the processing module 2102 executes the program or instruction, the security device 2100 may perform the functions of the above method.

[0328] It can be understood that the security device 2100 can be a terminal, a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in a terminal, a network device, or other device that can perform homomorphic tasks, or a device that includes a terminal, a network device, or other device that can perform homomorphic tasks. This application does not limit this.

[0329] In addition, the technical effects of the safety device 2100 can be the same as the technical effects of the above-mentioned method, which will not be repeated here.

[0330] In some further embodiments, the security device 2100 may perform the functions of the homomorphic task management entity in the above method.

[0331] For example, the transceiver module 2101 is configured to receive a homomorphic task request message from a user entity, and the processing module 2102 is configured to control the transceiver module 2101 to send a homomorphic task key request message to the key management entity based on the homomorphic task request. The homomorphic task request message indicates the homomorphic task requested by the user entity; the homomorphic task key request message is used to request the key management entity to derive and allocate the relevant key for the homomorphic task.

[0332] In one possible design, the transceiver module 2101 is further configured to send a ciphertext sending task configuration message to the ciphertext data storage entity, wherein the ciphertext sending task configuration message is used to trigger the ciphertext data storage entity to send ciphertext data to the homomorphic computing entity.

[0333] Optionally, the transceiver module 2101 may include a sending module (not shown in FIG21 ) and a receiving module (not shown in FIG21 ). The sending module is used to implement the sending function of the security device 2100 , and the receiving module is used to implement the receiving function of the security device 2100 .

[0334] Optionally, the security device 2100 may further include a storage module (not shown in FIG. 21 ) storing a program or instruction. When the processing module 2102 executes the program or instruction, the security device 2100 may perform the functions of the above method.

[0335] It can be understood that the security device 2100 can be a terminal, a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in a terminal, a network device, or other device that can perform homomorphic tasks, or a device that includes a terminal, a network device, or other device that can perform homomorphic tasks. This application does not limit this.

[0336] In addition, the technical effects of the safety device 2100 can be the same as the technical effects of the above-mentioned method, which will not be repeated here.

[0337] In some further embodiments, the security device 2100 may perform the functions of the homomorphic computing entity in the above method.

[0338] The transceiver module 2101 is configured to obtain a first state of the ciphertext data. The processing module 2102 is configured to perform homomorphic computations of round key addition, row shifting, and column obfuscation for AES encryption / decryption at level 0 of the hierarchical homomorphic computation mode based on the first state to obtain a second state. The processing module 2102 is configured to calculate, based on the second state, multi-valued function bootstrapping from level 0 to level 2 and privacy key switching from level 2 to level 1 to obtain a third state at level 1. The processing module 2102 is configured to perform homomorphic computations of byte substitution for AES encryption / decryption at level 1 of the hierarchical homomorphic computation mode based on the third state to obtain a fourth state.

[0339] In one possible design, byte substitution for AES encryption / decryption is performed based on a hybrid packed lookup. For example, the hybrid packed lookup includes: the input of the S-box is the third state, the output of the S-box is packed into two TRLWE ciphertexts using a pre-packing technique, a target TRLWE ciphertext is selected from the two TRLWE ciphertexts using a CMUX gate, and seven CMUX gates are used to perform blind rotations on the target TRLWE ciphertext to obtain the fourth state.

[0340] In a possible design, the processing module 2102 is further configured to extract samples from the fourth state and switch the key from level 1 to level 0 to obtain a new first state of level 0.

[0341] Optionally, the transceiver module 2101 may include a sending module (not shown in FIG21 ) and a receiving module (not shown in FIG21 ). The sending module is used to implement the sending function of the security device 2100 , and the receiving module is used to implement the receiving function of the security device 2100 .

[0342] Optionally, the security device 2100 may further include a storage module (not shown in FIG. 21 ) storing a program or instruction. When the processing module 2102 executes the program or instruction, the security device 2100 may perform the functions of the above method.

[0343] It can be understood that the security device 2100 can be a terminal, a network device, or other device that can perform homomorphic tasks, or a chip (system) or other parts or components that can be set in a terminal, a network device, or other device that can perform homomorphic tasks, or a device that includes a terminal, a network device, or other device that can perform homomorphic tasks. This application does not limit this.

[0344] In addition, the technical effects of the safety device 2100 can be the same as the technical effects of the above-mentioned method, which will not be repeated here.

[0345] FIG22 is a second structural diagram of a security device provided in an embodiment of the present application. For example, the security device may be a network device, or a chip (system) or other component or assembly that can be provided in a network device. As shown in FIG22 , the security device 2200 may include a processor 2201. Optionally, the security device 2200 may further include a memory 2202 and / or a transceiver 2203. The processor 2201 is coupled to the memory 2202 and the transceiver 2203, for example, by a communication bus.

[0346] The following is a detailed introduction to the various components of the safety device 2200 with reference to FIG. 22 :

[0347] The processor 2201 is the control center of the security device 2200 and can be a single processor or a collective term for multiple processing elements. For example, the processor 2201 can be one or more central processing units (CPUs), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as one or more digital signal processors (DSPs) or one or more field programmable gate arrays (FPGAs).

[0348] Optionally, the processor 2201 can execute various functions of the security device 2200 by running or executing software programs stored in the memory 2202 and calling data stored in the memory 2202, such as executing the homomorphic encryption-based security method shown in Figures 13-21 above.

[0349] In a specific implementation, as an embodiment, the processor 2201 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 22 .

[0350] In a specific implementation, as an embodiment, the security device 2200 may also include multiple processors, such as the processor 2201 and the processor 2204 shown in FIG22 . Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0351] Among them, the memory 2202 is used to store the software program for executing the solution of this application, and the execution is controlled by the processor 2201. The specific implementation method can refer to the above method embodiment and will not be repeated here.

[0352] Alternatively, the memory 2202 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, a laser disc, an optical disc, a digital versatile disc, a Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 2202 may be integrated with the processor 2201 or exist independently and be coupled to the processor 2201 via an interface circuit (not shown in FIG. 22 ) of the security device 2200, which is not specifically limited in the embodiments of the present application.

[0353] Transceiver 2203 is used for communication with other security devices. For example, if security device 2200 is a terminal, transceiver 2203 can be used to communicate with a network device or another terminal device. For another example, if security device 2200 is a network device, transceiver 2203 can be used to communicate with a terminal or another network device.

[0354] Optionally, the transceiver 2203 may include a receiver and a transmitter (not shown separately in FIG22 ), wherein the receiver is used to implement a receiving function, and the transmitter is used to implement a sending function.

[0355] Optionally, the transceiver 2203 can be integrated with the processor 2201, or can exist independently and be coupled to the processor 2201 through the interface circuit of the security device 2200 (not shown in Figure 22). This embodiment of the present application does not specifically limit this.

[0356] It is understandable that the structure of the safety device 2200 shown in FIG. 22 does not constitute a limitation on the safety device, and an actual safety device may include more or fewer components than shown, or a combination of certain components, or a different arrangement of components.

[0357] In addition, the technical effects of the safety device 2200 can refer to the technical effects of the methods described in the above method embodiments, and will not be repeated here.

[0358] It should be understood that the processor in the embodiments of the present application may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0359] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0360] The above embodiments can be implemented in whole or in part by software, hardware (such as circuits), firmware or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (such as infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0361] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0362] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0363] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0364] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0365] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0366] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0367] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0368] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A security method based on homomorphic encryption, characterized in that: The method comprises: Obtain the first state of the ciphertext data; Based on the first state, performing homomorphic computations of round key addition, row shift, and column obfuscation of AES encryption / decryption in level 0 of the hierarchical homomorphic computation mode to obtain a second state; Based on the second state, calculate the multi-valued function bootstrapping from level 0 to level 2 and the privacy key switching from level 2 to level 1 to obtain the third state of level 1; Based on the third state, byte-substituted homomorphic computation of AES encryption / decryption is performed in level 1 of the hierarchical homomorphic computation mode to obtain a fourth state.

2. The method according to claim 1, characterized in that The byte-replacement homomorphic computation of the AES encryption / decryption is performed based on a hybrid packed table lookup.

3. The method according to claim 2, characterized in that The hybrid packing lookup table includes: the input of the S box is the third state, and the output of the S box is packed into two TRLWE ciphertexts using a pre-packing technology; based on the TRGSW ciphertext of the most significant bit of the S box input, a target TRLWE ciphertext is selected from the two TRLWE ciphertexts using a CMUX gate; based on the TRGSW ciphertext of the remaining bits of the S box input, the target TRLWE ciphertext is blindly rotated using 7 CMUX gates to obtain the fourth state.

4. The method according to any one of claims 1 to 3, characterized in that The homomorphic calculation of column obfuscation of the AES encryption / decryption is performed based on homomorphic calculation of XOR and shift.

5. The method according to any one of claims 1 to 4, characterized in that The multi-valued function bootstrap is a programmable bootstrap PBSmanyLUT that evaluates multiple lookup tables simultaneously. The test polynomial used in the PBSmanyLUT has a negative cyclic property.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Sample extraction and key switching from level 1 to level 0 are performed on the fourth state to obtain a new first state of level 0.

7. A security method based on homomorphic encryption, characterized in that: Applied to a homomorphic computing entity, the method comprises: The homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data; The homomorphic computing entity performs homomorphic encryption on the ciphertext data to obtain mixed ciphertext data; The homomorphic computing entity performs homomorphic computing symmetric or asymmetric decryption on the mixed ciphertext data to obtain first homomorphic ciphertext data; The homomorphic computing entity performs a homomorphic computing function f on the first homomorphic ciphertext data to obtain second homomorphic ciphertext data; The homomorphic computing entity sends the second homomorphic ciphertext data.

8. The method according to claim 7, characterized in that The homomorphic computing entity performs homomorphic encryption on the symmetrically or asymmetrically encrypted ciphertext data to obtain mixed ciphertext data, including: The homomorphic computing entity uses a homomorphic encryption key to homomorphically encrypt the symmetrically or asymmetrically encrypted ciphertext data to obtain the mixed ciphertext data, wherein the symmetrically or asymmetrically encrypted ciphertext data refers to the ciphertext encrypted using a symmetrical or asymmetrical cryptographic algorithm that does not contain homomorphic characteristics.

9. The method according to claim 8, characterized in that The method further comprises: The homomorphic computing entity obtains the homomorphic encryption key from a key management entity.

10. The method according to claim 7, characterized in that The homomorphic computing entity performs homomorphic computing symmetric or asymmetric decryption on the mixed ciphertext data to obtain first homomorphic ciphertext data, including: The homomorphic computing entity uses the homomorphic ciphertext of the symmetric or asymmetric decryption key to perform homomorphic computing symmetric or asymmetric decryption on the mixed ciphertext data to obtain the first homomorphic ciphertext data.

11. The method according to claim 10, characterized in that The method further comprises: The homomorphic computing entity obtains the homomorphic ciphertext of the symmetric or asymmetric decryption key from a key management entity.

12. The method according to claim 7, characterized in that The homomorphic computing entity performs a homomorphic computing function f on the first homomorphic ciphertext data to obtain second homomorphic ciphertext data, including: The homomorphic computing entity uses a homomorphic computing key to perform a homomorphic computing function f on the first homomorphic ciphertext data to obtain the second homomorphic ciphertext data.

13. The method according to claim 12, characterized in that The method further comprises: The homomorphic computing entity obtains the homomorphic computing key from a key management entity.

14. The method according to any one of claims 7 to 13, characterized in that: The method further comprises: The homomorphic computing entity receives a homomorphic task configuration message from a homomorphic task management entity, wherein the homomorphic task configuration message is used to instruct the homomorphic computing entity to execute a corresponding homomorphic computing task.

15. The method according to any one of claims 7 to 14, characterized in that: The homomorphic computing entity receives symmetrically or asymmetrically encrypted ciphertext data, including: The homomorphic computing entity receives the symmetrically or asymmetrically encrypted ciphertext data from a data entity or a ciphertext data storage entity.

16. The method according to any one of claims 7 to 15, characterized in that: The homomorphic computing entity sends the second homomorphic ciphertext data, including: The homomorphic computing entity sends the second homomorphic ciphertext data to a using entity or a decrypting entity.

17. The method according to claim 16, characterized in that The using entity and the decrypting entity are the same entity.

18. The method according to any one of claims 7 to 17, characterized in that: The homomorphic computing entity is any one of the following: a base station BS, a core network CN network element, an edge node computing MEC entity, or a terminal.

19. A security method based on homomorphic encryption, characterized in that: Applied to a key management entity, the method comprises: The key management entity receives a homomorphic task key request message from the homomorphic task management entity, wherein the homomorphic task key request message is used to request the key management entity to derive and allocate relevant keys for the homomorphic task; The key management entity sends the key related to the homomorphic task to the homomorphic computing entity that executes the homomorphic task according to the homomorphic task key request message.

20. The method according to claim 19, characterized in that The keys related to the homomorphic tasks include at least one of the following: homomorphic ciphertext of a symmetric or asymmetric key, a homomorphic encryption key, or a homomorphic computing key.

21. The method according to claim 19 or 20, characterized in that The method comprises: The key management entity receives cryptographic capability information from a data entity, wherein the cryptographic capability information of the data entity is used to indicate whether the data entity supports symmetric or asymmetric encryption capability; The key management entity sends a symmetric or asymmetric encryption key to the data entity according to the cryptographic capability information of the data entity.

22. The method according to any one of claims 19 to 21, characterized in that The method comprises: The key management entity receives cryptographic capability information from a decryption entity, wherein the cryptographic capability information of the decryption entity is used to indicate that the decryption entity supports homomorphic decryption capability and symmetric or asymmetric encryption capability; The key management entity sends a symmetric or asymmetric encryption key and a homomorphic decryption key to the decryption entity according to the cryptographic capability information of the decryption entity.

23. The method according to claim 22, characterized in that The decryption entity is another entity different from the homomorphic computing entity.

24. The method according to claim 22, characterized in that The method comprises: The key management entity receives cryptographic capability information from a user entity, wherein the cryptographic capability information of the user entity is used to indicate that the user entity supports symmetric or asymmetric decryption capability; The key management entity sends a symmetric or asymmetric decryption key to the user entity according to the cryptographic capability information of the user entity.

25. The method according to any one of claims 19 to 21, characterized in that The method comprises: The key management entity receives cryptographic capability information from a user entity, wherein the cryptographic capability information of the user entity is used to indicate that the user entity supports homomorphic decryption capability; The key management entity sends a homomorphic decryption key to the user entity according to the cryptographic capability information of the user entity.

26. A security method based on homomorphic encryption, characterized in that: Applied to a homomorphic task management entity, the method comprises: The homomorphic task management entity receives a homomorphic task request message from a user entity, wherein the homomorphic task request message indicates a homomorphic task requested by the user entity; The homomorphic task management entity sends a homomorphic task key request message to the key management entity according to the homomorphic task request, wherein the homomorphic task key request message is used to request the key management entity to derive and allocate relevant keys for the homomorphic task.

27. The method according to claim 26, characterized in that The method further comprises: The homomorphic task management entity sends a ciphertext sending task configuration message to the ciphertext data storage entity, wherein the ciphertext sending task configuration message is used to trigger the ciphertext data storage entity to send ciphertext data to the homomorphic computing entity.

28. A safety device, characterized in that: The apparatus comprises: a module for executing the method as claimed in any one of claims 1-27.

29. A safety device, characterized in that: The security device comprises: a processor and a memory; the memory is used to store computer instructions, and when the processor executes the instructions, the security device executes the method as described in any one of claims 1-27.

30. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises a computer program or instructions, and when the computer program or instructions are executed on a computer, the computer is caused to perform the method according to any one of claims 1 to 27.

31. A computer program product, characterized in that The computer program product comprises: a computer program or instructions, and when the computer program or instructions are run on a computer, the computer is caused to perform the method according to any one of claims 1 to 27.

Images