Mailbox ownership verification method and device, equipment and medium

Abstract

The invention discloses a mailbox ownership verification method, device and equipment and a medium, and relates to the field of information security, and the method comprises the following steps: an ideal authentication stage: enabling a client to negotiate with a verification party, and formulating an ideal authentication template according to a mailbox transmission protocol and an SASL identity authentication mechanism; in the interactive execution stage, TLS connection among three parties is established based on a TLS Oracle framework, the client and the verification party cooperate to execute an identity authentication process in a mailbox transmission protocol according to an ideal authentication template in combination with the service party, and the verification party obtains a requested and responded encrypted text; in the authentication disclosure and verification stage, the client is made to disclosure an identifier in the authentication interaction process according to an ideal authentication template, a verification party is allowed to perform verification, and an identity authentication result is obtained according to an encrypted text, so that a user can disclosure the identity authentication result contained in a protocol to the verification party under the condition that a service party does not perceive the identity authentication result; and the ownership certification is realized under the condition that a specific email address is not disclosed to a verification party.

Description

Technical Field

[0001] The present application relates to the field of information security, and in particular to a mailbox ownership verification method, device, equipment and medium. Background Art

[0002] As one of the most widely used identity identifiers, email is widely used in account registration and recovery, multi-factor authentication, organizational identity, and anti-sybil attacks. The core of implementing these applications is that users prove their ownership of email addresses to the verifier. The current typical email ownership verification process is as follows: (a) The user submits his email address to the verifier; (b) The verifier sends a verification email containing a random challenge (such as a verification code) in response; (c) The user must solve the challenge and return the result to the verifier. If the user can successfully solve the challenge, the verifier can believe that the user owns the email address and then provide the corresponding service.

[0003] Although this ownership authentication method has been widely used, users are increasingly concerned about some of its security and privacy risks. The verification emails that traditional ownership verification methods rely on are the main cause of security risks. Some malicious attackers send phishing emails to users by forging them as verification emails, exposing users to the risk of phishing attacks. For example, verification emails have become the carrier of many phishing scams targeting digital wallets, seriously threatening the security of assets in digital wallets. In addition, the random challenges contained in the verification emails may be illegally obtained by malicious adversaries, resulting in false email ownership authentication. At the same time, due to the spam settings of email service providers, verification emails may be mistakenly marked as spam, and there is a risk of being included in the spam mailbox or failing to be delivered, resulting in verification failure.

[0004] Existing verification schemes also have privacy protection issues. Users usually need to provide the verification party with a complete email address, which leads to the leakage of email contact information, exacerbating the proliferation of spam and phishing emails, and also causing problems such as account identity association and network behavior tracking. At the same time, email transmission between different email service providers is usually transmitted in plain text to allow service providers to implement email screening and filtering, but this also causes the user's specific email content to be reviewed by the service provider, destroying privacy.

[0005] Most functions that use email as an identity do not require the verifier to know the user's full email address. For example, account recovery only requires the user to prove ownership of the account filled in during registration. However, due to the limitations of traditional email ownership verification methods, users can only disclose their full email address, which destroys the user's identity privacy and violates the principle of minimizing the use of information.

[0006] To solve these problems, the privacy-preserving email ownership authentication method implemented by the present invention needs to overcome the following two challenges: (a) how to prevent the verifier from obtaining the specific email address while verifying the email ownership, and (b) how to complete the ownership proof without sending a verification email.

[0007] At present, some studies have proposed solutions to the problem of privacy-preserving mailbox ownership authentication. For example, Wang et al. proposed a method called Secure Channel Injection (SCI), which allows the verifier to inject a random challenge value into an email sent from one email account of the prover to another email account accessible to the prover. The prover then proves ownership of the recipient email account by revealing the random value. This scheme uses two-party secure computation to calculate the random value between the prover and the verifier, but currently only supports AES implementation in CBC mode in TLS v1.2, and the scheme itself cannot be adapted to support TLS v1.3 in the same way. Tan et al. constructed a scheme to authenticate mailbox ownership by using multi-party secure computation to use the committee to jointly send verification emails. However, this scheme only hides the specific information of the mailbox from the committee, and still relies on verification emails for verification. Baldimtsi et al. used identity tokens issued by applications that support the single sign-on protocol (OpenID Connect, OIDC) (such as Google, Facebook, etc.) to implement email ownership authentication, and verified the authenticity of the token through ZKP to prove the user's ownership of the email address contained in the token, but its application scope is limited.

[0008] In summary, the above-mentioned mailbox ownership authentication methods are unable to enable the user to disclose the identity authentication results contained in the agreement to the verification party without the service party's knowledge, and to realize ownership proof without disclosing the specific mailbox address to the verification party, so that the verification party can believe the user's ownership of the mailbox, resulting in privacy leakage and the user's reliance on verification emails during the verification process, and a large security loophole. Summary of the invention

[0009] The purpose of this application is to provide a mailbox ownership verification method, device, equipment and medium to solve the problem of serious privacy leakage and large security loopholes in the mailbox ownership verification method based on verification emails.

[0010] To achieve the above objectives, this application provides the following solutions:

[0011] In a first aspect, the present application provides a mailbox ownership verification method, comprising:

[0012] the ideal authentication phase, the interactive execution phase, and the authentication disclosure and verification phase;

[0013] In the ideal authentication stage, the client and the verifier negotiate to formulate an ideal authentication template according to the email transmission protocol and the SASL identity authentication mechanism, and the client is required to fill in the ideal authentication template according to personal identity information to determine the ideal authentication process; the personal identity information includes an email address and a password;

[0014] In the interactive execution phase, a TLS connection is established between the client, the verifier and the service provider based on the TLS Oracle framework, and the client and the verifier cooperate to perform the identity authentication process in the mailbox transmission protocol in accordance with the ideal authentication process in combination with the service provider, so that the verifier obtains the encrypted text of the request and response during the authentication interaction between the client and the service provider;

[0015] During the authentication disclosure and verification phase, the client is instructed to disclose key identifiers in the authentication interaction process according to the ideal authentication template to allow the correctness and integrity of the verifier to be verified, and the identity authentication result is obtained through the disclosed encrypted text of the request and response in the authentication interaction process.

[0016] In a second aspect, the present application provides a mailbox ownership verification device, comprising:

[0017] The ideal authentication module is used to make the client and the verifier negotiate in the ideal authentication stage, formulate an ideal authentication template according to the email transmission protocol and the SASL identity authentication mechanism, and make the client fill in the ideal authentication template according to personal identity information to determine the ideal authentication process; the personal identity information includes an email address and a password;

[0018] An interactive execution module, used to establish a TLS connection between the client, the verifier and the service provider based on the TLS Oracle framework during the interactive execution phase, and enable the client and the verifier to cooperate with each other to perform the identity authentication process in the mailbox transmission protocol in accordance with the ideal authentication process in combination with the service provider, so that the verifier obtains the encrypted text of the request and response during the authentication interaction between the client and the service provider;

[0019] The authentication disclosure and verification module is used to enable the client to disclose the key identifiers in the authentication interaction process according to the ideal authentication template during the authentication disclosure and verification stage, so as to allow the correctness and integrity of the verifier to be verified, and to obtain the identity authentication result through the encrypted text of the request and response in the disclosed authentication interaction process.

[0020] In a third aspect, the present application provides a computer device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the mailbox ownership verification methods described above.

[0021] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-described mailbox ownership verification methods.

[0022] According to the specific embodiments provided in this application, this application discloses the following technical effects:

[0023] This application is based on the TLS Oracle framework to build a connection between the user, the verifier and the service party. The user, the verifier and the service party execute the mailbox transmission protocol, such as SMTP, IMAP and POP3, under the TLS Oracle framework. Through the TLS Oracle framework, the user and the verifier jointly execute the Transport Layer Security (TLS) protocol, share the session key of the TLS link, and jointly complete the encryption of the protocol interaction data, and then the user sends the encrypted data packet containing the encrypted text to the service party. This application only expands the encryption of the interaction data from the user independently completing the encryption to the user and the verifier jointly completing the encryption, without changing the output encrypted data packet. Therefore, the service party cannot distinguish between the encrypted data sent by the user based on the TLS Oracle framework and the encrypted data sent under normal interaction. As a result, the user can disclose the identity authentication result contained in the protocol to the verifier without the service party's perception. If the user's identity authentication is successful, the verifier can believe the user's ownership of the mailbox. And this application uses the identity authentication information contained in the mailbox transmission protocol as proof of the user's mailbox ownership, avoiding the need for verification emails, avoiding privacy leakage problems, and repairing security vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0025] Figure 1 Schematic diagram of the SASL authentication interaction process provided for this application;

[0026] Figure 2 Flowchart of the mailbox ownership verification method provided for this application;

[0027] Figure 3 The information interaction diagram between the verifier, client and service provider provided by this application;

[0028] Figure 4 Schematic diagram of the ideal authentication interaction template provided for this application;

[0029] Figure 5 Schematic diagram of the ideal authentication interaction process provided by this application. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0031] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0032] The privacy protection of email addresses is of great significance in today's information society, and it is related to personal privacy and network security. First of all, email addresses are an important identifier of personal identity. The abuse of email addresses may cause users to receive a large number of spam, advertising promotions, and even targeted fraud information. In addition, email addresses can be used as identifiers associated with user network behavior. Malicious adversaries can analyze user profiles in combination with other public information, thereby infringing personal privacy. At the same time, email addresses are one of the core credentials of many online accounts. Malicious adversaries can launch phishing attacks by stealing email addresses, defrauding sensitive information such as passwords, and causing property losses or information leaks. However, the current traditional email ownership authentication method requires users to disclose their complete email addresses, which undermines the privacy and security of email addresses.

[0033] This application proposes a general mailbox ownership authentication method based on the Simple Authentication and Security Layer (SASL) in the mailbox transfer protocol. By utilizing mailbox transfer protocols such as Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol (IMAP) and Post Office Protocol (POP3), the user's identity is verified using the secure authentication process after SASL privacy enhancement. The authentication result is then disclosed to the verifier through the TLS Oracle framework as proof of email ownership. This achieves an ownership authentication scheme that does not require email verification and is unaware of the service provider.

[0034] The main participants in this application include the client (Client, C), the verifier (Verifier, V) and the server (Server, S).

[0035] (1) Client (C): The client agent performs the authentication process on behalf of the user, indicating that the entity wishes to prove to the verifier (third party) that it owns a specific email address, represented by the symbol C. In this application, it is assumed that C has legal access rights to the email address to be proven and can send, receive and access emails. However, a malicious C may attempt to prove ownership of an email address that he does not own.

[0036] (2) Verifier (V): The verifier is an application or service that needs to confirm the ownership of C's email address, represented by the symbol V. V's goal is to verify the association between C and the email address it provides to support the application or service it provides (such as account recovery), but without disclosing the full email address. However, a malicious V may try to obtain sensitive identity information that C has not disclosed in the process.

[0037] (3) Service provider (S): The service provider is a service provider that provides email transmission services (such as Gmail, Outlook, etc.), represented by the symbol S. This application requires that the email transmission protocol service provided by S needs to support the TLS protocol to protect the transmitted data. S is generally considered to be trustworthy and reliable because malicious behavior will damage its reputation. However, S may analyze the traffic data it forwards out of curiosity and monitor the user's online behavior.

[0038] The security features that this solution should meet include:

[0039] (1) Authentication correctness: A malicious C cannot use invalid authentication information (such as an incorrect email address or an incorrect password) to interact with S and complete a successful authentication.

[0040] (2) Privacy: A malicious V cannot obtain any information that is not proactively disclosed by an honest C.

[0041] (3) Unforgeability: A malicious C cannot forge the interaction process with S, nor can it forge the ownership verification statement that can be verified by V.

[0042] (4) Service-side unawareness: When C is honest, S cannot distinguish between the connection interaction established by C through the execution of the solution of the present application and the regular connection interaction established by C.

[0043] The background knowledge involved in this application is as follows:

[0044] (1) Simple Authentication and Security Layer: Simple Authentication and Security Layer (SASL) is a basic framework that integrates authentication capabilities and data security services into various connection-oriented protocols through replaceable mechanisms. SASL is an abstract layer built between specific protocols and identity authentication mechanisms, enabling any protocol to achieve security authentication through any identity authentication mechanism without redesign. Protocols can choose the most suitable mechanism based on their specific security requirements and operating environment. Common identity authentication mechanisms include: PLAIN, LOGIN, and XOAUTH2.

[0045] The SASL authentication interaction process is as follows Figure 1 As shown:

[0046] Line 1: Client C sends a SASL authentication request that contains a field for the name of the authentication mechanism selected by C.

[0047] Line 2-4: The service provider S and the client C perform the identity authentication process in the "challenge-response" mode. S first issues a verification challenge, and C solves the challenge and returns a response. This process can include one or more pairs of "challenge-response";

[0048] Line 5: S outputs the authentication result of C.

[0049] in, Figure 1 The authentication result contained in line 5 is the evidence that this application hopes to disclose to the verification party for mailbox ownership authentication. When the user executes the SASL identity authentication interaction phase in the mailbox transmission protocol, the service party can successfully authenticate the user's identity, and the user can be considered to own the mailbox.

[0050] (2) Mail transfer protocol: Email transmission relies on three key protocols: SMTP, IMAP, and POP3. Among them, the SMTP protocol is responsible for sending emails, while the IMAP and POP3 protocols are responsible for receiving emails. However, the original frameworks of these protocols lack the necessary security protection protocols. During the execution process, they cannot verify the identities of the communicating parties, nor can they guarantee the confidentiality and integrity of the data during transmission. The mailbox transfer protocol increases the security of the original protocol by integrating the SASL authentication protocol and the TLS / SSL protocol, and solves these problems.

[0051] By integrating the SASL framework, email service providers are allowed to verify the identity of email clients, ensuring that only clients that pass the authorization check can send and receive emails. The TLS / SSL protocol provides security for email transmission through encryption, identity authentication, and data integrity protection, preventing data from being eavesdropped or tampered with during network transmission. The main methods for establishing TLS connections in current email transmission protocols are implicit TLS and STARTTLS.

[0052] (3) TLS Oracle Framework: The TLS Oracle Framework can realize the trusted export of encrypted data in the TLS protocol and prove the source of the data to the verifier under privacy protection. It allows users who establish a connection with the service provider through the TLS protocol to trustfully disclose specific interaction data to the verifier (third party) or selectively disclose assertions related to the data through zero-knowledge proof.

[0053] The process of the TLS Oracle framework used in this application is shown as follows. The main participants include the client (C), the verifier (V) and the server (S). The meanings of the symbols used include:

[0054] pp: Public parameters that need to be negotiated between C and V when executing the TLS Oracle protocol.

[0055] tk: Session key for encrypting session data in TLS protocol.

[0056] tk c(v) : The shared session key in the TLS protocol owned by C or V.

[0057] The request data sent by client C is represented by Q, and the encrypted ciphertext request is express.

[0058] The response data sent by the service provider S is represented by R, and the encrypted ciphertext response is represented by express.

[0059] cm: C's cryptographic commitment to the session data.

[0060] r: A random number chosen by C when committing to the session data.

[0061] The process of the TLS Oracle framework includes five parts: initialization, handshake establishment, data exchange, session commitment, and open commitment. The specific process is as follows:

[0062] Initialization: O.Setup(C<>, V<>)→(pp): A secure connection is established between C and V, and both parties negotiate the public parameters pp, including parameters such as the TLS version number that will be established later.

[0063] Handshake establishment: O.Handshake(pp, C<>, V<>)→(C(tk c ), V(tk v >): C and V jointly negotiate with S on various parameters in the handshake phase of the TLS protocol. After the negotiation, S obtains the heap encryption key parameter tk of the TLS protocol session phase, and C and V obtain the shared value tk of tk c and tk v ,satisfy

[0064] Data Exchange: In a single interaction between C and V, C and V encrypt the request Q together, and both parties will receive the encrypted ciphertext request C will then Send it to S, and then get the request response returned by S And forward it to V. C and V jointly check the integrity of the message. In general, at this stage, C and V encrypt the request sent together and check the integrity and authentication of the received response.

[0065] Session Commitment: Decrypting TLS session data in C Before, C needs to Make a commitment and output cm to prevent C from mistakenly disclosing the session data content to V.

[0066] Open a promise: O.Open(pp, C<M,r> , V(cm>)→(C<>, V<0 / 1>): C opens a session data to V For M, and prove that M is the same as cm's commitment. If V succeeds in verification, C successfully discloses to V the data content of the interaction between it and S. V outputs 1, otherwise it outputs 0.

[0067] The technical solution of this application implements an ownership authentication framework that does not require sending verification emails, supports three mailbox transmission protocols: SMTP, IMAP and POP3, and multiple SASL identity authentication mechanisms.

[0068] The meanings of the symbols used in this application are as follows:

[0069] The request data sent by client C is represented by Q, and the encrypted ciphertext request is express.

[0070] The response data sent by the service provider S is represented by R, and the encrypted ciphertext response is represented by express.

[0071] k: indicates the number of rounds in the SASL challenge-response authentication protocol.

[0072] Represents an ordered sequence of messages exchanged between C and S.

[0073] U: represents the ideal authentication interaction message flow designed based on SASL and mailbox transport protocol.

[0074] L: Indicates the type of email transport protocol used in the email ownership authentication process, such as SMTP, IMAP, etc.

[0075] φ: indicates the type of SASL authentication mechanism used in the mailbox ownership authentication process, such as PLAIN and LOGIN.

[0076] cred={addr,passwd}: indicates the email address addr and authentication password passwd used by the client during the authentication process.

[0077] Γ:Γ={U mark , l} represents the interactive process template that the verifier needs to verify during the authentication process, including the identification of the message in the ideal authentication interactive message flow U mark , and the message containing the email address and the authentication password satisfies the regular expression l.

[0078] cm: C's cryptographic commitment to the session data.

[0079] r: A random number chosen by C when committing to the session data.

[0080] The embodiment of the present application provides a mailbox ownership verification method, which is executed by a computer device, and can be executed by a computer device such as a terminal or a server alone, or can be executed by a terminal and a server together. In the embodiment of the present application, Figure 2-Figure 3As shown, the method includes the following steps.

[0081] A mailbox ownership verification method includes an ideal authentication phase, an interactive execution phase, and an authentication disclosure and verification phase.

[0082] S1: In the ideal authentication stage, the client negotiates with the verifier to formulate an ideal authentication template based on the email transmission protocol and the SASL identity authentication mechanism. The client fills in the ideal authentication template based on the identity information it has (including email address and password) to obtain the ideal authentication process.

[0083] S2: In the interactive execution phase, a TLS connection is established between the client, the verifier and the service provider based on the TLS Oracle framework, and the client and the verifier cooperate to perform the identity authentication process in the mailbox transmission protocol in accordance with the ideal authentication process in conjunction with the service provider, so that the verifier obtains the encrypted text of the request and response during the authentication interaction between the client and the service provider.

[0084] S3: During the authentication disclosure and verification phase, the client is instructed to disclose the key identifiers in the authentication interaction process according to the ideal authentication template to allow the correctness and integrity of the verifier to be verified, and the identity authentication result is obtained through the disclosed encrypted text of the request and response in the authentication interaction process.

[0085] In an exemplary embodiment, the ideal authentication stage specifically includes the following steps.

[0086] S11: Instruct the client and the verifier to negotiate, and determine, based on the email transfer protocol and the SASL identity authentication mechanism, an ideal authentication template that the client needs to follow when executing the SASL authentication mechanism in the email transfer protocol; the ideal authentication template includes fixed fields in all requests and commands, and the service party response content; wherein the fields involving the client identity information and the service party identity information in the fixed fields are blank fields; the service party response content is the successful response content of the service party to the capability request command sent by the client.

[0087] S12: In the ideal authentication template, the client sends a capability request command to the service provider to request the service provider's extended service list; in the process of sending the capability request command, the blank field is a field of IP or domain name information representing the client identity.

[0088] S13: In the ideal authentication template, the client sends an identity authentication request command to the service provider to execute a "challenge-response" interaction link; in the "challenge-response" interaction link, the blank field is the client's email address and authentication password in the "challenge-response" interaction link.

[0089] S14: Based on the ideal authentication template, the client is instructed to fill in the blank fields in the ideal authentication template during the process of sending the capability request command according to personal identity information.

[0090] S15: After the client completes the ideal authentication template according to the personal identity information, the complete content of all messages sent by the client in the ideal authentication process is determined, and assuming that the service provider responds successfully and correctly to all requests, the message content sent by the service provider in the ideal authentication process is completed.

[0091] In an exemplary embodiment, the ideal authentication interaction template Γ is:

[0092] Γ={U mark ,l}

[0093] Among them, U mark is a key identifier that can identify the ideal authentication process; l is a regular expression that needs to be followed when constructing a message containing credentials, which is determined by the name of the SASL identity authentication mechanism used. The credentials include the email address and authentication password used by the client during the authentication process.

[0094] In an exemplary embodiment, the ideal authentication process U is:

[0095]

[0096] Among them, Q pre Request command for capability; R pre The response to the capability request command; Q a is a request for authentication; R i Q is the challenge sent by the service provider in the i-th round of “challenge-response” interaction; i is the response of the client to solve the challenge in the i-th round of "challenge-response" interaction; k is the total number of "challenge-response" interaction rounds; R a The service side responds with a successful authentication response.

[0097] In an exemplary embodiment, S11 may be replaced by the following steps.

[0098] S111: The client and the verification party negotiate and confirm the mailbox transmission protocol to be executed, and confirm that the client needs to send a capability request command to the service party.

[0099] S112: If the capability request command response is successful, the service provider is instructed to return an extended service list.

[0100] S113: Confirm that the client sends an authentication request to the service provider; the authentication request includes the name of the SASL authentication mechanism selected for execution; the ideal authentication template contains a fixed field for the name of the SASL authentication mechanism selected for execution, and the part involving client information and service provider information should remain blank; the ideal authentication template also includes the service provider response content that is the service provider's successful response content to the client authentication request.

[0101] S114: Instruct the service provider to perform authentication with the client in a "challenge-response" mode according to the SASL authentication mechanism name, and in each round of "challenge-response" interaction, instruct the service provider to send a challenge, and instruct the client to reply with a response that solves the challenge, until the service provider replies with a response output indicating successful authentication; the ideal authentication template also includes fixed fields in the "challenge-response" interaction, and the parts involving client information and service provider information should remain empty.

[0102] In practical applications, according to a series of numbered Request For Comments (RFC) standards for the mailbox transmission protocol and the SASL authentication mechanism, the client and the verifier can construct an ideal authentication interaction template Γ = {U mark ,l}. Among them, U mark It is a key symbol that can identify the ideal certification process and is Q pre ,R pre , and R a The fixed values ​​determined by the RFC standard include specific commands, response codes, etc. l is a regular expression that must be followed to construct a message containing cred={addr,passwd}, which is determined by the SASL authentication mechanism φ used. The content contained in the ideal authentication template is the fixed fields of the corresponding message specified in the RFC standard, and the part involving client information and service party information should remain empty.

[0103] This application specifies the ideal authentication flow for users to perform the mailbox ownership verification process

[0104]

[0105] The ideal authentication process U is completed by the client C supplementing the identity content of the ideal authentication template. The client C first sends a capability request command, represented by Q pre , to request the extended service list of the service provider S. S sends the extended service list it supports to C, denoted as R preA successful response from S also indicates that the service configuration lists of C and S were successfully initialized, clearing any ongoing tasks and resetting the status lists.

[0106] Then, C needs to execute the SASL authentication mechanism immediately. C first sends an authentication request, including the name of the SASL authentication mechanism selected for execution (such as AUTH PLAIN), represented by Q a Then S performs authentication according to φ and C in the "challenge-response" mode, performing k rounds in total, expressed as In each round of challenge-response interaction, S sends a challenge R i , C replies with a response Q that solves the challenge i Finally, S replies with the response output R after successful authentication a .

[0107] Taking the implementation of PLAIN authentication mechanism in SMTP as an example, the ideal authentication interaction template generated is as follows Figure 4 As shown, given a command where the first line is a capability request command sent by C, such as Q pre = "EHLO*******", if S supports the mailbox extended service list, it will reply with a response code 250 and a list of supported services, that is, R pre = "250******". Then C sends Q according to the authentication request content specified in the authentication interaction template. a = "AUTH PLAIN", S identifies the authentication mechanism φ = PLAIN requested by C, and starts the "challenge-response" interaction. S sends a challenge R1 = "334", which is the first challenge content that S needs to send when executing the PLAIN mechanism as specified in SMTP. Then C constructs a response request to the challenge according to the regular expression l that needs to be followed when constructing a message containing cred, which includes the email address and authentication password, and is encoded in Base64 encoding, which can be expressed as Q1 = "Base64 (****** <nul> ****** <nul>******)″. S then verifies C’s email address and authentication password, that is, verifies the correctness of C’s identity. If the verification is correct, it replies with a successful authentication response, which includes a response code 235, which can be represented as R a ="235******".

[0108] The ideal authentication interaction process after the client completes the identity information filling is as follows Figure 5 As shown, it is assumed that the client's IP address is "198.01.23.1", the email address is "sample@xxx.com", and the corresponding authentication password is "123456".

[0109] In an exemplary embodiment, the interactive execution phase may be replaced by the following steps.

[0110] S21: Instruct the client and the verifier to execute the initialization instructions in the TLS Oracle framework applied in the interactive execution phase, and generate the TLS Oracle framework public parameters pp required for subsequent link establishment; at this time, the client and the verifier do not need to input, and both parties obtain the public parameters pp after the execution is completed.

[0111] S22: Based on the public parameter pp, the client and the authenticator execute the handshake establishment instruction in the TLS Oracle framework applied in the interactive execution phase to establish a TLS connection with the service provider; wherein the client and the authenticator do not need to input, and the client receives the shared session key share tk of the session key after executing the handshake instruction c ,tk c It is the shared session key share in the TLS protocol owned by the client; the verifier receives the shared session key share tk of the session key after executing the handshake instruction v ,tk v The share of the shared session key in the TLS protocol that the authenticator possesses.

[0112] S23: Based on the TLS connection, the client is instructed to improve the authentication request content based on the certificate and the ideal authentication template.

[0113] S24: Instruct the client to cooperate with the verification party to send the authentication request content to the service party in sequence, and receive the encrypted response message list sent by the service party.

[0114] S25: Based on the authentication request content and the encrypted response message list, the client and the verifier are instructed to execute the data exchange instructions of the interactive execution phase to perform the identity authentication process; during the execution, the client needs to input the shared session key share tk c and the jth response Q from the client j ; The authenticator needs to enter the shared session key share tk v The encrypted request and corresponding encrypted response received by the client and the verifier after completing the data exchange instruction and is the ciphertext request after the jth encryption; The ciphertext response returned by the service provider after the jth encryption.

[0115] S26: Instruct the client to execute the commitment instructions in the authentication disclosure and verification phase to determine the encrypted ideal authentication process; wherein the client needs to input the encrypted message The random number r and the shared session key share tk c , Including encrypted authentication request content and encrypted response message, Request content list for authentication. To encrypt the response message list; the authenticator needs to enter the shared session key share tk v After the client and the verification party execute the commitment instruction, Commitment cm j , cm j is the cryptographic commitment for the session data in the jth session.

[0116] In practical applications, C and V negotiate to generate an ideal authentication interaction template Γ = {U mark , l}, establish a TLSOracles link with S to execute the authentication interaction process that complies with the interaction template Γ.

[0117] First, C and V are executed:

[0118] O.Setup(C<>,V<>)→(pp)

[0119] Generates the public parameters pp for establishing a TLS Oracle link.

[0120] Then C determines the domain name and port of the service provider S to be accessed, and determines whether the email transmission protocol provided by the target service provider S supports the TLS protocol, and the link mode to establish the TLS protocol. For a TLS connection established in STARTTLS mode, C needs to use the STARTTLS command to upgrade the connection with S to establish the TLS protocol. For implicit TLS mode, C can directly establish a TLS connection with S.

[0121] C and V execution:

[0122] O.Handshake(pp,C<>,V<>)→(C(tk c >, V <tk v >)

[0123] C and S establish a TLS connection. Then C supplements the specific content of the authentication request based on the credential cred = (addr, passwd) according to the ideal authentication template Γ:

[0124] Q=(Q pre , Q a , Q1,…,Q k )

[0125] Then it is sent to S in conjunction with V, and then receives the encrypted response message list R sent by S = (R pre , R a , R1,…,R k )

[0126] C by executing:

[0127]

[0128] Among them, Q j ∈Q,R j ∈R, completing the above interaction.

[0129] Then C receives the encrypted request and response Message commitment:

[0130]

[0131] in, get V then uses the session key share tk v Sent to C to allow C to decrypt the encrypted message.

[0132] In this stage, the verifier V can and Ideal authentication process for encryption

[0133] In an exemplary embodiment, the authentication disclosure and verification phase may be replaced by the following steps.

[0134] S31: Instruct the client to execute the commitment instruction of the authentication disclosure and verification phase, and disclose the key identifier in the authentication interaction process; wherein the client needs to input the plain text message M j And the corresponding random number r, the verifier needs to enter the commitment cm to be opened j ; If the verifier accepts the commitment cm j If the result of opening is the same as the result of opening the authentication template, output 1, otherwise output 0; let the verification party verify whether the identifier is the same as the identifier in the ideal authentication template; if so, determine that the verification is passed; if not, determine that the verification is not passed.

[0135] In practical applications, M j ∈U mark .

[0136] V verifies whether the disclosed identifier is the same as the identifier in the template Γ. The verification content includes the number of identifiers, the content of the identifiers, and whether the combination of the email address and the verification password conforms to the regular expression l.

[0137] If the verification is successful, V outputs 1, and V can assume that C and S have conducted a legal authentication interaction and received a successful authentication response. V believes that C owns the corresponding email address. Otherwise, V outputs 0, indicating that the email ownership authentication failed.

[0138] The technical solution of this application includes the following three stages:

[0139] The first stage is the ideal authentication stage. V needs to design an ideal authentication process based on the adopted email transmission protocol to guide C to perform the correct authentication operation. This application formulates an ideal authentication template Γ according to the rules of the email transmission protocol and the SASL authentication mechanism, wherein the ideal authentication template Γ includes the request content, execution order, and identification content that needs to be disclosed and verified later for the authentication interaction between C and S. V can verify the integrity and correctness of C's authentication interaction process based on the ideal authentication template Γ to ensure the validity of the email ownership authentication result.

[0140] The second stage is the interactive execution stage. C, V and S establish a connection based on the TLS Oracle framework. C and V collaborate with S to perform the identity authentication process in the mailbox transmission protocol according to the ideal authentication template Γ. From S's perspective, C's operation is no different from the normal identity authentication operation. After the execution is completed, V can obtain the encrypted text of the request and response in the entire interactive process.

[0141] The third part is the authentication disclosure and verification phase, where C discloses the identity during the authentication interaction process according to the provisions of the ideal authentication template Γ to allow V to verify the correctness and completeness of the authentication process, and also obtain the identity authentication result.

[0142] The advantages of this solution are described in detail below:

[0143] (1) No verification email is required.

[0144] This application uses the authentication result of the SASL authentication performed in the mailbox transfer protocol to identify the mailbox ownership, thereby avoiding the need for verification emails. This application extracts the ideal identity authentication interaction paradigm from the SASL authentication specification, based on formal definitions and proofs to ensure its reliability. The authentication result based on the SASL implementation is then exported to the verifier for verification as the mailbox ownership authentication proof provided by the user. This method only requires the user to execute the authentication process in the mailbox transfer protocol, without disclosing the complete email address to the service provider and receiving the verification email, thereby avoiding the service provider's collection of sensitive user information and the security and privacy vulnerabilities caused by the verification email.

[0145] (2) Universal compatibility.

[0146] Mailbox transfer protocols, as the basic support for mail services, are widely used around the world. Common protocols include SMTP, IMAP, and POP3 protocols. These protocols achieve interconnection between different devices and mail servers through standardized communication methods, ensuring efficient delivery and reliable storage of mails between different email providers. These protocols use the SASL authentication mechanism to authenticate user identities to improve the security of email transmission. This application is compatible with the three commonly used mail transfer protocols and multiple SASL authentication mechanisms, and integrates seamlessly with existing email providers, providing compatibility and versatility. This versatility ensures that this application is applicable to a wide range of email providers, such as Gmail, Outlook, etc., thereby expanding its practicality and influence.

[0147] (3) The server is not aware.

[0148] The mailbox ownership authentication method implemented by this application does not require verification of emails, so honest but curious email service providers cannot monitor and track the user's authorization authentication behavior. At the same time, since this application uses the authentication part of the normal mailbox transmission protocol to implement ownership authentication, the email provider cannot distinguish between user requests using this application and user requests executing the normal mailbox transmission protocol, achieving server non-perception. In addition, the implementation scheme of this application does not require modification and cooperation from the email service provider, which improves the practicality of the scheme.

[0149] (4) Privacy protection.

[0150] This application uses the TLS Oracles solution to protect the privacy and security of the data exchanged between the user and the service provider, ensuring that the user's sensitive information (such as email address or password) is not obtained by the verification party. At the same time, the verification party participates in the email transmission protocol interaction between the user and the service provider through the TLS Oracles solution to verify the source and integrity of the interaction data.

[0151] Based on the same inventive concept, the embodiment of the present application also provides a mailbox ownership verification device for implementing the mailbox ownership verification method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more mailbox ownership verification device embodiments provided below can refer to the limitations of the mailbox ownership verification method above, and will not be repeated here.

[0152] In an exemplary embodiment, a mailbox ownership verification device is provided, comprising:

[0153] The ideal authentication module is used to enable the client and the verifier to negotiate during the ideal authentication phase and formulate an ideal authentication template based on the mailbox transmission protocol and the SASL identity authentication mechanism.

[0154] The interactive establishment module is used to establish a TLS connection between the client, the verifier and the service party based on the TLS Oracle framework during the interactive execution phase, and enable the client and the verifier to collaborate in accordance with the ideal authentication template and in conjunction with the service party to execute the identity authentication process in the mailbox transmission protocol, so that the verifier obtains the encrypted text of the request and response during the authentication interaction between the client and the service party.

[0155] The authentication disclosure and verification module is used to enable the client to disclose the key identifiers in the authentication interaction process according to the ideal authentication template during the authentication disclosure and verification stage, so as to allow the correctness and integrity of the verifier to be verified, and to obtain the identity authentication result through the encrypted text of the request and response in the disclosed authentication interaction process.

[0156] In an exemplary embodiment, a computer device is provided, which may be a server or a terminal. The computer device includes a processor, a memory, an input / output interface (I / O for short) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store mailbox ownership verification data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a mailbox ownership verification method is implemented.

[0157] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the above method is implemented when the processor executes the computer program.

[0158] In an exemplary embodiment, a computer-readable storage medium is provided, storing a computer program, which implements the above method when executed by a processor.

[0159] In an exemplary embodiment, a computer program product is provided, including a computer program, which implements the above method when executed by a processor.

[0160] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ReadOnlyMemory, ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (Magnetoresistive RandomAccess Memory, MRAM), ferroelectric random access memory (Ferroelectric RandomAccess Memory, FRAM), phase change memory (Phase Change Memory, PCM), graphene memory, etc. Volatile memory can include random access memory (RandomAccess Memory, RAM) or external cache memory, etc. By way of illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0161] In this application, all actions to obtain signals, information or data are carried out in compliance with the relevant data protection laws and policies of the country where they are located and with the authorization given by the owner of the corresponding device.

[0162] The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. The non-relational database may include a distributed database based on blockchain, etc., but is not limited thereto. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but is not limited thereto.

[0163] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0164] This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. At the same time, for those skilled in the art, according to the ideas of this application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.< / nul> < / nul>

Claims

1. A mailbox ownership verification method, characterized in that: The mailbox ownership verification method comprises: an ideal authentication phase, an interactive execution phase, and an authentication disclosure and verification phase; In the ideal authentication stage, the client and the verifier negotiate to formulate an ideal authentication template according to the email transmission protocol and the SASL identity authentication mechanism, and the client is required to fill in the ideal authentication template according to personal identity information to determine the ideal authentication process; the personal identity information includes an email address and a password; In the interactive execution phase, a TLS connection is established between the client, the verifier and the service provider based on the TLS Oracle framework, and the client and the verifier cooperate to perform the identity authentication process in the mailbox transmission protocol in accordance with the ideal authentication process in combination with the service provider, so that the verifier obtains the encrypted text of the request and response during the authentication interaction between the client and the service provider; During the authentication disclosure and verification phase, the client is instructed to disclose key identifiers in the authentication interaction process according to the ideal authentication template to allow the correctness and integrity of the verifier to be verified, and the identity authentication result is obtained through the disclosed encrypted text of the request and response in the authentication interaction process.

2. The mailbox ownership verification method according to claim 1, characterized in that: The ideal authentication stage specifically includes: The client and the verifier negotiate to determine, based on the mailbox transmission protocol and the SASL identity authentication mechanism, an ideal authentication template that the client needs to follow when executing the SASL authentication mechanism in the mailbox transmission protocol; the ideal authentication template includes fixed fields in all requests and commands, and service party response content; wherein the fields involving the client identity information and the service party identity information in the fixed fields are vacant fields; the service party response content is the successful response content of the service party to the capability request command sent by the client; In the ideal authentication template, the client sends a capability request command to the service provider to request the service provider's extended service list; in the process of sending the capability request command, the blank field is a field of IP or domain name information indicating the client's identity; In the ideal authentication template, the client sends an identity authentication request command to the service provider to perform a "challenge-response" interaction; in the "challenge-response" interaction, the blank field is the client's email address and authentication password in the "challenge-response" interaction; Based on the ideal authentication template, instruct the client to fill in the vacant fields in the ideal authentication template during the process of sending the capability request command according to personal identity information; After the client completes the ideal authentication template according to the personal identity information, the complete content of all messages sent by the client in the ideal authentication process is determined, and assuming that the service provider responds successfully and correctly to all requests, the message content sent by the service provider in the ideal authentication process is completed.

3. The mailbox ownership verification method according to claim 2, characterized in that: According to the mailbox transport protocol and the SASL identity authentication mechanism, determine the ideal authentication template that the client needs to follow when executing the SASL authentication mechanism in the mailbox transport protocol, specifically including: Instruct the client and the verification party to negotiate and confirm the mailbox transmission protocol to be executed, and confirm that the client needs to send a capability request command to the service party; If the capability request command response is successful, the service provider returns the extended service list; Confirm that the client sends an authentication request to the service provider; the authentication request includes the name of the SASL authentication mechanism selected for execution; the ideal authentication template contains a fixed field for the name of the SASL authentication mechanism selected for execution, and the part involving the client information and the service provider information should remain blank; the service provider response content also included in the ideal authentication template is the service provider's successful response content to the client authentication request; The service provider is instructed to perform authentication with the client in a "challenge-response" mode according to the SASL authentication mechanism name, and in each round of "challenge-response" interaction, the service provider is instructed to send a challenge, and the client is instructed to reply with a response that solves the challenge, until the service provider replies with a response output indicating successful authentication; the ideal authentication template also includes fixed fields in the "challenge-response" interaction, and the parts involving client information and service provider information should remain empty.

4. The mailbox ownership verification method according to claim 2, characterized in that: The ideal authentication template Γ is: C={U mark ,l} Among them, U mark is a key identifier that can identify the ideal authentication process; l is a regular expression that needs to be followed when constructing a message containing credentials, which is determined by the name of the SASL identity authentication mechanism used; the credentials include the email address and authentication password used by the client during the authentication process.

5. The mailbox ownership verification method according to claim 2, characterized in that: The ideal authentication process U is: Among them, Q pre Request command for capability; R pre The reply to the capability request command; Q a is a request for authentication; R i Q is the challenge sent by the service provider in the i-th round of "challenge-response" interaction; i is the response that the client replies to solve the challenge in the i-th round of "challenge-response" interaction; k is the total number of "challenge-response" interaction rounds; R a The service side responds with a successful authentication response.

6. The mailbox ownership verification method according to claim 1, characterized in that: The interactive execution phase specifically includes: Instruct the client and the verifier to execute the initialization instructions in the TLS Oracle framework applied in the interactive execution phase, and generate the TLS Oracle framework public parameter pp required for subsequent link establishment; at this time, the client and the verifier do not need to input, and both parties obtain the public parameter pp after the execution is completed; Based on the public parameter pp, the client and the verifier execute the handshake establishment instruction in the TLS Oracle framework applied in the interactive execution phase to establish a TLS connection with the service provider; wherein the client and the verifier do not need to input, and the client receives the shared session key share tk of the session key after executing the handshake instruction c , tk c It is the shared session key share in the TLS protocol owned by the client; the verifier receives the shared session key share tk of the session key after executing the handshake instruction v , tk v The share of the shared session key in the TLS protocol owned by the authenticator; Based on the TLS connection, the client is instructed to complete the authentication request content according to the ideal authentication template based on the credential; Instruct the client to cooperate with the verification party to send the authentication request content to the service party in sequence, and receive the encrypted response message list sent by the service party; Based on the authentication request content and the encrypted response message list, the client and the verifier are instructed to execute the data exchange instructions of the interactive execution phase to perform the identity authentication process; wherein, during the execution, the client needs to input the shared session key share tk c and the jth response Q from the client j ; The authenticator needs to enter the shared session key share tk v The encrypted request and corresponding encrypted response received by the client and the verifier after completing the data exchange instruction and is the ciphertext request after the jth encryption; The ciphertext response returned by the service provider after the jth encryption; The client is instructed to execute the commitment instructions in the authentication disclosure and verification phase to determine the encrypted ideal authentication process; wherein the client needs to input the encrypted message The random number r and the shared session key share tk c , Including encrypted authentication request content and encrypted response message, Request content list for authentication. To encrypt the response message list; the authenticator needs to enter the shared session key share tk v After the client and the verifier have executed the commitment instruction, Commitment cm j , cm j is the cryptographic commitment for the session data in the jth session.

7. The mailbox ownership verification method according to claim 6, characterized in that: The certification disclosure and verification phase specifically includes: The client is required to execute the commitment instruction of the authentication disclosure and verification phase and disclose the key identifier in the authentication interaction process; wherein the client needs to input the plaintext message M j And the corresponding random number r, the verifier needs to enter the commitment cm to be opened j ; If the verifier accepts the commitment cm j If the result is opened, output 1, otherwise output 0; Instructing the verification party to verify whether the identifier is identical to the identifier in the ideal authentication template; If yes, confirm that the verification is successful; If not, it is determined that the verification has not passed.

8. A mailbox ownership verification device, characterized in that: The mailbox ownership verification device comprises: The ideal authentication module is used to make the client and the verifier negotiate in the ideal authentication stage, formulate an ideal authentication template according to the email transmission protocol and the SASL identity authentication mechanism, and make the client fill in the ideal authentication template according to personal identity information to determine the ideal authentication process; the personal identity information includes an email address and a password; An interactive execution module, used to establish a TLS connection between the client, the verifier and the service provider based on the TLS Oracle framework during the interactive execution phase, and enable the client and the verifier to cooperate with each other to perform the identity authentication process in the mailbox transmission protocol in accordance with the ideal authentication process in combination with the service provider, so that the verifier obtains the encrypted text of the request and response during the authentication interaction between the client and the service provider; The authentication disclosure and verification module is used to enable the client to disclose the key identifiers in the authentication interaction process according to the ideal authentication template during the authentication disclosure and verification stage, so as to allow the correctness and integrity of the verifier to be verified, and to obtain the identity authentication result through the encrypted text of the request and response in the disclosed authentication interaction process.

9. A computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the mailbox ownership verification method described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the mailbox ownership verification method described in any one of claims 1 to 7 is implemented.

Images