A public key encryption method supporting bidirectional access control and traceability

Abstract

The application relates to a public key encryption method supporting bidirectional access control and traceability, and has the characteristics that: the method does not depend on a third-party authority to host a key, solves the problems of key hosting and single-point failure, supports a system user to calculate auxiliary information in advance through preprocessing, reduces the calculation burden during encryption and decryption, and has a very low requirement on the computing power of the user terminal; the method supports bidirectional access control, allows a sender and a receiver to specify respective access control strategies, and only when bilateral matching is achieved, can the decryption be successfully performed, so that ciphertext filtering and data source authentication are achieved; the method supports a ciphertext receiver to report to a supervisor according to plaintext information corresponding to the ciphertext, after verification of the report information, the supervisor can trace the ciphertext sender; and a certain supervisor is specified to supervise the information before the message is sent, so that the division of the supervision function in the system is achieved.

Description

Technical Field

[0001] This invention relates to the fields of privacy protection and content regulation. Specifically, it relates to a public-key encryption method that supports two-way access control and accountability. Background Technology

[0002] The rapid development of the internet has led to the widespread use of social media in people's lives. Currently, the user base of social media has reached billions, with mobile users (such as those using smartphones) making up the vast majority. However, while social media facilitates information exchange, it also brings potential privacy risks. When people send messages on social networks, they are actually sharing this private data with software service providers. Although in the era of big data, user data can be collected by companies and used appropriately to provide better services to users, malicious incidents such as malicious companies or third parties infringing on user privacy still exist. Several years ago, an analytics company illegally collected the personal data of millions of users on a social media platform and used it for other purposes. Just six months later, the social media platform was again embroiled in a data privacy scandal. These incidents undoubtedly increase users' concerns about privacy breaches on social media and pose new challenges to existing privacy protection measures for social media.

[0003] To address these challenges, end-to-end encryption was proposed. End-to-end encryption is a method of protecting communication privacy where data is encrypted on the sender's device and then decrypted on the receiver's device. Only the sender and receiver can access and decrypt the data. Throughout the communication process, no third party, including service providers and potential adversaries, can access or decrypt the data. This greatly improves the security and privacy of user communications, but it also leads to difficulties for service providers in regulating platform content. Therefore, an increasing number of social media platforms employing end-to-end encryption are being used to spread large-scale spam, harassment, violence, misinformation, and terrorist information. This presents new challenges for social media platforms that aim to ensure user privacy in terms of content regulation.

[0004] Matching encryption, as an emerging public-key cryptosystem, has opened up new methods for secure communication. Both the sender and receiver of a message can specify fine-grained access control policies for encrypted data. Specifically, in matching encryption, both the sender and receiver have their own attributes. The sender can specify that only receivers meeting certain attributes can decrypt the message, and the receiver can specify that only senders meeting certain attributes can send them messages; messages from those who do not meet the conditions will be discarded. Therefore, the receiver can only recover the plaintext from the ciphertext when both parties' access control policies are satisfied. This bilateral matching characteristic is helpful in establishing blacklist and whitelist mechanisms in end-to-end encrypted online social platforms, enabling receivers to filter out messages sent by unauthorized senders from their blacklists.

[0005] Message stamping was first introduced by a company in its end-to-end encrypted messaging service. It allows for the generation of verifiable malicious reporting reports by including cryptographic proofs, thus addressing regulatory oversight issues in end-to-end encrypted scenarios. Summary of the Invention

[0006] This invention presents a novel public-key encryption method for end-to-end encrypted content monitoring on online social platforms. This protocol eliminates the need for a central authority like a Key Generation Center (KGC) to initialize users' public and private key pairs, effectively solving problems related to key escrow and single points of failure. Furthermore, the protocol avoids complex and time-consuming pairing operations, enabling effective deployment even on resource-constrained terminal devices. This invention also supports data source authentication and implements a reporting and monitoring function.

[0007] This invention is achieved through the following technical solution:

[0008] A public-key encryption method supporting two-way access control and accountability includes the following steps:

[0009] A. During the system initialization phase, system users generate their own public and private key pairs by calling a key generation algorithm based on the system public parameter pp generated by the network social platform operator; specifically including:

[0010] S is randomly selected As his private key, and based on the system public parameters pp = (G, g, p, h = g) a Hash Enc Calculate the corresponding public key Where G is a prime group of order p, with generator g, and hash... Enc It is a G→{0,1} v hash function, It is a random value; the receiver R and the supervisor M use the same key generation algorithm to generate their respective public and private key pairs, i.e.

[0011]

[0012]

[0013] The system does not rely on a third-party authoritative institution to manage keys; all users generate and manage their own public and private key pairs locally.

[0014] B. In the preprocessing stage, the sender, receiver, and supervisor pre-calculate auxiliary information based on their respective private key information and the public key information of the target communication object for subsequent encryption and decryption; specifically including:

[0015] If communication occurs between sender S and receiver R, the same applies to communication between other users. Sender S can use its private key information in advance... and the public key information of the designated recipient R Calculate auxiliary information The receiver R can also use its private key information in advance. and the public key information of the designated sender S Calculate auxiliary information The auxiliary information can be calculated in advance, reducing the computational burden of subsequent encryption and decryption operations;

[0016] C. During the message flow stage:

[0017] 1) Before sending the encrypted information, the sender S will first select a random value t and calculate the intermediate quantity T = (T1, T2) = (g t h t )and Then the sender S confirms the proof. and statement Then call the non-interactive zero-knowledge proof algorithm NIZK R .prove(m, x, y) generates a proof π that identifies itself and the designated supervisor. This proof π is embedded in ciphertext for accountability purposes.

[0018] 2) The sender S selects a random value u and concatenates the message m to be sent and the proof π to obtain the message msg = m||π; then the following ciphertext component is calculated: U = g u , The ciphertext C = (U, T, M, V) is sent to the receiver R; here K is introduced. r And auxiliary information H S This is equivalent to setting an access control policy for the sender, at which point only the receiver R can decrypt the ciphertext;

[0019] 3) After receiving the ciphertext C, receiver R will use its whitelist WL to... R Perform initial screening; if the sender S's public key information... The message is stored in the receiver R's whitelist, indicating that the sender S is allowed to send messages to the receiver R. Then, the receiver R uses its private key to send the message. Restore Then, based on the ciphertext component V, the obtained K is restored. r And the auxiliary information H calculated in the preprocessing stage R Through the following calculations The plaintext message msg is restored through the above construction to achieve two-way access control. The ciphertext can only be successfully decrypted when both the sender and receiver's identities satisfy each other's access control policies.

[0020] 4) After receiver R reconstructs the message msg, it first performs the following steps according to the statement: The verification algorithm SPoK for proving satisfaction knowledge. R The `verify(m, π, y)` function verifies the integrity of the message data, ensuring that the received data has not been maliciously tampered with. After verifying the validity of the data, if the data contains illegal information, the receiver R acts as the message sender and sends a report to the supervisor M, similar to executing step C.2) again. That is, the receiver R selects a random value u′ and then calculates the following ciphertext component U′=g. u′ , in It is the public key information of the designated supervisor M. It is pre-calculated auxiliary information, and the ciphertext C′=(U′,T,M,V′) is sent to the supervisor M;

[0021] D. During the reporting and monitoring phase, the monitor M decrypts the encrypted report information sent by the receiver R to obtain the message msg, according to the statement. The verification algorithm SPoK for proving satisfaction knowledge. R The `verify(m, π, y)` function verifies whether the violation message was indeed sent by sender S to receiver R. If the verification is correct, the report is considered valid, and supervisor M will hold sender S accountable and, depending on the severity of the violation, decide whether to add sender S to the system blacklist BL. Otherwise, the report is invalid.

[0022] The beneficial effects of this invention are:

[0023] 1) It does not rely on a central authority such as a key generation center to initialize the user's public and private key pairs, thus achieving decentralization and effectively solving problems such as key escrow and single point of failure.

[0024] 2) Users can pre-calculate the auxiliary information required for encryption and decryption, reducing the computational overhead during peak communication periods. Furthermore, the encryption and decryption operations do not involve complex pairing operations, thus requiring very low computing power from the user's terminal device.

[0025] 3) Supports two-way access control for communication information. Only when the identities of the sender and receiver both meet the other party's access control policy can the receiver restore the ciphertext to plaintext, thus realizing ciphertext filtering and message source authentication.

[0026] 4) Supports the reporting and supervision of encrypted communications and enables the division of supervisory functions within the system. Attached Figure Description

[0027] Figure 1 This is an explanatory diagram of the system initialization phase of the present invention;

[0028] Figure 2 This is an explanatory diagram of the message flow stage of the present invention;

[0029] Figure 3 This is an illustrative diagram of the reporting and supervision stage of this invention. Detailed Implementation

[0030] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0031] A public-key encryption method supporting two-way access control and accountability is presented. Its system model includes three roles: supervisor (social platform operator), message sender (user), and message receiver (user). The following is a detailed description of the characteristics and functions of each role:

[0032] I. Regulators

[0033] The regulator of this system is the service provider of the end-to-end encrypted online social platform. They are responsible for initializing system parameters, publishing and updating the system's blacklist, receiving and verifying user-initiated reports of malicious information, and ultimately tracking down malicious users within the system, thus fulfilling their content monitoring function.

[0034] II. Message sender:

[0035] The message sender is responsible for signing the message, which means mixing the sender's own information and the identity information of the designated supervisor into the sent data. Then, the target recipients need to be specified, which means setting the sender's access control policy. Finally, the data is encrypted and the ciphertext is distributed to all target recipients.

[0036] III. Message Recipient:

[0037] The message receiver is responsible for decrypting the ciphertext and collecting the data, but can only decrypt ciphertext that satisfies a two-sided match. If the message receiver recovers the plaintext and finds that it contains malicious information, they can submit a malicious information report to the regulator, requesting the regulator to conduct content supervision and accountability investigation, and add the malicious user to the system blacklist.

[0038] The specific technical solution of the present invention includes the following steps:

[0039] This public-key encryption method consists of four main stages: system initialization, preprocessing, message flow, and reporting / monitoring. The protocol includes a sender (S) (malicious), a receiver (R) (malicious), and a monitor (M) (semi-honest).

[0040] Step 1: System Initialization

[0041] 1.1 System Common Parameter Initialization: This step is performed by the network social platform operator. A security parameter λ is selected as input to generate a prime group G of order p, with generator g. Then, a hash function Hash is selected. Enc : G→{0,1} v Then randomly select And calculate h = g a Finally, the system's common parameters are output as pp = (G, g, p, h = g). a Hash Enc The message sender (S), receiver (R), and monitor (M) can each generate their own whitelist (WL) based on this blacklist. S WL R WL M .

[0042] 1.2 User Key Initialization: Sender S is randomly selected As his private key sk S And calculate the corresponding public key. Receiver R and supervisor M use the same key generation algorithm to generate their respective public-private key pairs, i.e.

[0043]

[0044]

[0045] Step 2: Preprocessing

[0046] 2.1 The sender S, receiver R, and supervisor M can calculate auxiliary information based on their respective private keys and the public key of the target communication object, i.e.

[0047]

[0048] The auxiliary information obtained from preprocessing can effectively reduce the computational burden on terminal devices and accelerate the encryption and decryption efficiency of subsequent steps.

[0049] Step 3: Message Flow

[0050] 3.1 Sender Signature: Sender S designates recipient R to send a message with plaintext m. First, a random value t needs to be selected and calculated:

[0051]

[0052] Then let And generate proof

[0053] π = NIZK R .prove(m, x, y).

[0054] The section on zero-knowledge proofs will be discussed in detail later.

[0055] 3.2 Sender Encryption: Sender S selects a random value u and concatenates the plaintext information m and the proof π to obtain msg = m||π. Then, through calculation...

[0056]

[0057]

[0058] Finally, the sender S sends the ciphertext C = (U, T, M, V) to the receiver R.

[0059] 3.3 Receiver filtering and decryption of ciphertext: After receiving the ciphertext C = (U, T, M, V), receiver R first filters and decrypts the ciphertext according to its whitelist WL. R Perform encrypted filtering if And if the sender of the ciphertext is indeed sender S, then it can be detected using its private key. Restore Then, based on V and the reconstructed K, r and the H obtained from preprocessing calculations R Calculate

[0060]

[0061] The correctness of the decryption algorithm is explained here. And restored Therefore, the following calculation can be performed: because Therefore H S =H R Therefore, there is Hash Enc (H S) = Hash Enc (H R ), then naturally we can obtain

[0062] 3.4 Receiver Verification: Receiver R obtains the plaintext m and the proof π from msg, and then uses zero-knowledge proof to verify... Perform verification if SPoK R If .verify(m, π, y) = 1, then the verification is successful, which proves the integrity of the received data and indicates that the received data has not been maliciously tampered with and is valid.

[0063] Step 4: Report to the regulator

[0064] After receiver R reconstructs the plaintext message m, if he / she finds that the plaintext message m contains illegal information, such as spam containing fraud or violence, then receiver R can report it to regulator M according to the following procedure.

[0065] 4.1 Receiver Encryption: This stage is similar to sender encryption. The receiver R selects a random value u′, and then calculates...

[0066]

[0067]

[0068] The final recipient R sends the ciphertext C′=(U′,T,M,V′) to the supervisor M.

[0069] 4.2 Regulator Filtering: This stage is similar to receiver filtering. After receiving the ciphertext C′=(U′, T, M, V′), regulator M first checks its whitelist WL. M Perform encrypted filtering if And since the sender of the ciphertext is the receiver R, then it is sent using their own private key. Restore Then the supervisor M can use V′ and the reconstructed K′ to determine the outcome. r and the H obtained from preprocessing calculations m Calculate

[0070]

[0071] 4.3 Supervisor Verification: This stage is similar to receiver verification. The supervisor obtains the plaintext m and the proof π from msg, and then uses zero-knowledge proofs to verify the plaintext m. Perform verification if SPoK RIf .verify(m,π,y)=1, the verification is successful, which proves that the illegal message was indeed sent by the sender S to the receiver R. The report is valid, and the supervisor will hold the sender S accountable. Depending on the severity of the case, the supervisor will decide whether to add the sender S to the system blacklist BL.

[0072] The following are the detailed aspects of zero-knowledge proofs, primarily constructed based on the Okamoto and Chaum-Pedersen protocols. The specific protocols are as follows:

[0073] First, select the hash function. Where M is the plaintext space. Then, the relationship that the witness and statement in this scheme must satisfy is determined, i.e.

[0074]

[0075] The relational constraints indicate that the proof was indeed generated by sender S, ensuring that when sender S sends inappropriate information and is reported, regulators can accurately trace him back to the source. Furthermore, The relational constraints indicate that when sender S sends a message, the platform will specify which supervisor will oversee the message according to the platform's requirements. This serves as a zoned supervision mechanism. Only the designated supervisor is obligated to supervise the message. If a non-designated supervisor receives the report, they may not take any action.

[0076] The algorithm used by message sender S to generate proof of its identity is as follows:

[0077] NIZK R .prove(m,x,y)→π, where

[0078] 1) According to the Okamoto protocol: randomly select Then a commitment is generated. Then calculate the hash value c. o =Hash NIZK (m,com o Next, let's... And finally obtained

[0079] 2) According to the Chaum-Pedersen protocol: randomly select Then a commitment is generated. in

[0080]

[0081] Then generate a hash value. Then let β cp =β3+t·C cp Thus, we obtain π. cp =(com) cp ,β cp ).

[0082] 3) The final output proves π = (π o , π cp ).

[0083] The algorithm details for message receiver R and supervisor M, acting as verifiers, to verify that the prover possesses knowledge that satisfies constraint relation R are as follows:

[0084] SPoK R .verify(m, π, y) → 0 / 1

[0085] make in First, restore the hash value c. o =Hash NIzK (m,com) o )and Then verify whether the following equations are true. If they are true, output 1; otherwise, output 0.

[0086]

[0087]

[0088] Output 1 indicates that although the prover did not reveal relevant information, they did possess knowledge about the proof (witness) that satisfies the above relational constraints, namely, knowledge of (s, u, t).

[0089] Correctness explanation: For Known Then the left side of the equation equals And the right side of the equation equals If the expressions on both sides are equal, then it means This refers to one of the relational constraints that must be satisfied. Verifying whether other relational constraints are satisfied is similar; simply substitute and simplify.

[0090] See Figure 1In this invention, during the system initialization phase, the platform service provider generates a system public parameter pp based on the security parameter λ. Furthermore, as a supervisor, the service provider also publishes a blacklist containing public key information of malicious users to system users. Each user in the system can create a trusted whitelist based on the blacklist and their personal address book for encrypted filtering in subsequent processes. Moreover, system users (including message senders, message receivers, and message supervisors) will locally invoke a key generation algorithm based on the public parameter pp to generate their own public-private key pair.

[0091] See Figure 2 In this invention, during the message flow stage, the message sender is required to embed proofs of their own identity and the identity of a designated supervisor using zero-knowledge proofs before sending the message. The sender then concatenates the plaintext message and the proof and encrypts them. Before encryption, the sender is required to specify the target recipient, thus implementing access control on the sender's side. When the message recipient receives the ciphertext sent by the sender, it first checks its own trusted whitelist to verify if the message sender is on it. If not, the ciphertext is discarded. If it is, the recipient then checks if the message sender is the target recipient, verifying if the sender's identity information meets the recipient's access control policy. If both sides match successfully, the message recipient can successfully reconstruct the plaintext. The reconstructed plaintext undergoes an integrity check to verify whether the received data has been tampered with. If the verification fails, the message recipient can consider it invalid and discard it. If a message recipient repeatedly receives plaintext data that fails verification from the same message sender, the recipient can remove that sender from its trusted whitelist.

[0092] See Figure 3After successfully decrypting the ciphertext and confirming the verification, if the recipient finds illegal or malicious information in the plaintext data, they can assume the sender is malicious and has violated the content supervision terms of the online social platform. In this case, the recipient can report the message to the designated supervisor. The recipient will act as the sender, first extracting proof π identifying the malicious user, then implementing access control policies before encrypting the message and sending it to the designated supervisor. Upon receiving the ciphertext, the supervisor will first filter it according to their maintained whitelist, then decrypt it using bilateral matching to extract the sender's identity proof. Next, they will verify the authenticity of the report using zero-knowledge proofs, confirming that the malicious message was indeed sent by the sender as the recipient claims. Finally, the supervisor will investigate the malicious message, hold the reported party accountable, and, depending on the severity of the offense, consider adding them to the system blacklist. In real-world scenarios, there are also situations where the recipient sends a report to other regulators. However, when these other regulators receive the report, they verify it using their public key to see if the information pertains to their oversight. If not, they do not process it. This effectively establishes a division of regulatory functions within the system.

Claims

1. A public-key encryption method supporting two-way access control and traceability, characterized in that, Includes the following steps: A. During the system initialization phase, system users generate their own public and private key pairs by calling a key generation algorithm based on the system public parameter pp generated by the network social platform operator; specifically including: S is randomly selected As his private key, and based on the system public parameters pp = (G, g, p, h = g) a Hash Enc Calculate the corresponding public key Where G is a prime group of order p, with generator g, and hash... Enc It is a G→{0,1} v hash function, It is a random value; the receiver R and the supervisor M use the same key generation algorithm to generate their respective public and private key pairs, i.e. The system does not rely on a third-party authoritative institution to manage keys; all users generate and manage their own public and private key pairs locally. B. In the preprocessing stage, the sender, receiver, and supervisor pre-calculate auxiliary information based on their respective private key information and the public key information of the target communication object for subsequent encryption and decryption; specifically including: If the sender S and the receiver R communicate, the sender S can use its private key information in advance. and the public key information of the designated recipient R Calculate auxiliary information The receiver R can also use its private key information in advance. and the public key information of the designated sender S Calculate auxiliary information The auxiliary information can be calculated in advance, reducing the computational burden of subsequent encryption and decryption operations; C. During the message flow stage: 1) Before sending the encrypted information, the sender S will first select a random value t and calculate the intermediate quantity T = (T1, T2) = (g t ,h t )and Then the sender S confirms the proof. and statement Then call the non-interactive zero-knowledge proof algorithm NIZK R .prove(m,x,y) generates a proof π that identifies itself and the designated supervisor. This proof π is embedded in ciphertext for accountability purposes. 2) The sender S selects a random value u and concatenates the message m to be sent and the proof π to obtain the message msg = m||π; then the following ciphertext component is calculated: U = g u , The ciphertext C = (U, T, M, V) is sent to the receiver R; K is introduced. r And auxiliary information H S Establish access control policies for the sender, so that only the receiver R can decrypt the ciphertext. 3) After receiving the ciphertext C, receiver R will use its whitelist WL to... R Perform initial screening; if the sender S's public key information... The message is stored in the receiver R's whitelist, indicating that the sender S is allowed to send messages to the receiver R. Then, the receiver R uses its private key to send the message. Restore Then, based on the ciphertext component V, the obtained K is restored. r And the auxiliary information H calculated in the preprocessing stage R Through the following calculations Restore the plaintext message msg; 4) After receiver R reconstructs the message msg, it first performs the following steps according to the statement: The verification algorithm SPoK for proving satisfaction knowledge. R The `verify(m,π,y)` function verifies the integrity of the message data, ensuring that the received data has not been maliciously tampered with. After verifying the validity of the data, if the data contains illegal information, the receiver R acts as the message sender and sends a report to the supervisor M. That is, the receiver R selects a random value u′ and then calculates the following ciphertext component U′=g. u′ , in It is the public key information of the designated supervisor M. It is pre-calculated auxiliary information, and the ciphertext C′=(U′,T,M,V′) is sent to the supervisor M; D. During the reporting and monitoring phase, the monitor M decrypts the encrypted report information sent by the receiver R to obtain the message msg, according to the statement. The verification algorithm SPoK for proving satisfaction knowledge. R The `verify(m,π,y)` function verifies whether the violation message was indeed sent by sender S to receiver R. If the verification is correct, the report is considered valid, and supervisor M will hold sender S accountable and, depending on the severity of the violation, decide whether to add sender S to the system blacklist BL. Otherwise, the report is invalid.

Images