A method, apparatus, device and medium for verifying email ownership.

Abstract

This application discloses a method, apparatus, device, and medium for email ownership verification, relating to the field of information security. The method includes an ideal authentication phase, in which the client and the verifier negotiate and formulate an ideal authentication template based on the email transmission protocol and the SASL identity authentication mechanism; an interactive execution phase, in which a TLS connection is established between the three parties based on the TLS Oracle framework, and the client and the verifier collaborate to execute the identity authentication process in the email transmission protocol according to the ideal authentication template, in conjunction with the service provider, enabling the verifier to obtain encrypted text of the request and response; and an authentication disclosure and verification phase, in which the client discloses the identifier in the authentication interaction process according to the ideal authentication template, allowing the verifier to perform verification, and obtaining the identity authentication result based on the encrypted text. This allows the user to disclose the identity authentication result contained in the protocol to the verifier without the service provider's knowledge, and to achieve ownership proof without disclosing the specific email address to the verifier.

Description

Technical Field

[0001] This application relates to the field of information security, and in particular to a method, apparatus, device, and medium for verifying email ownership. Background Technology

[0002] Email, as one of the most widely used identity identifiers, is extensively applied in account registration and recovery, multi-factor authentication, organizational identification, and protection against Sybil attacks. At the heart of these applications is the user proving ownership of their email address to the verifier. A typical email ownership verification process is as follows: (a) the user submits their email address to the verifier; (b) the verifier sends a verification email containing a random challenge (e.g., a CAPTCHA) in response; (c) the user must solve the challenge and return the result to the verifier. If the user successfully solves the challenge, the verifier can then believe that the user owns the email address and provide the corresponding services.

[0003] While this ownership verification method is widely used, users are increasingly concerned about its security and privacy risks. The verification emails relied upon by traditional ownership verification methods are a major source of security risks. Malicious attackers send phishing emails disguised as verification emails to users, exposing them to phishing attacks. For example, verification emails have become a vehicle for many phishing scams targeting digital wallets, seriously threatening the security of assets within digital wallets. Furthermore, the random challenges included in verification emails can be illegally obtained by malicious adversaries, leading to false email ownership verification. Simultaneously, due to spam settings by email service providers, verification emails may be mistakenly marked as spam, risking being included in spam folders or failing to deliver, thus causing verification failure.

[0004] Existing verification schemes also have privacy protection issues. Users are usually required to provide their complete email address to the verifier, leading to the leakage of email contact information, exacerbating the proliferation of spam and phishing emails, and causing problems such as account identity association and online behavior tracking. At the same time, emails between different email service providers are usually transmitted in plaintext to allow service providers to filter emails, but this also means that the specific content of users' emails can be reviewed by service providers, compromising privacy.

[0005] Most functions that use email addresses as identification 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 provided during registration. However, due to limitations in traditional email ownership verification methods, users can only disclose their full email address, which compromises user privacy and violates the principle of minimizing information use.

[0006] To address these issues, the privacy-preserving email ownership authentication method implemented in this invention needs to overcome the following two challenges: (a) how to verify email ownership while preventing the verifier from obtaining the specific email address, and (b) how to complete ownership verification without sending a verification email.

[0007] Several studies have proposed solutions to the privacy-preserving problem of email ownership authentication. For example, Wang et al. proposed a method called Secure Channel Injection (SCI), which allows a verifier to inject a random challenge value into an email sent from one of the prover's email accounts to another email account accessible to the prover. The prover then proves ownership of the receiving 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 of TLS v1.2, and the scheme itself cannot equally adapt to support TLS v1.3. Tan et al. constructed a scheme to authenticate email ownership by using a committee to jointly send verification emails through multi-party secure computation. However, this scheme only hides the specific email information from the committee and still relies on the verification email 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 achieve email ownership authentication. They 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, none of the aforementioned email ownership authentication methods can disclose the identity authentication results contained in the agreement to the verifier without the user's knowledge, nor can they prove ownership without disclosing the specific email address to the verifier, thus convincing the verifier that the user owns the email address. This leads to privacy leaks and user dependence on verification emails during the verification process, resulting in significant security vulnerabilities. Summary of the Invention

[0009] The purpose of this application is to provide a method, apparatus, device, and medium for email ownership verification, in order to solve the problems of serious privacy leakage and large security vulnerabilities in email ownership verification methods based on verification emails.

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

[0011] Firstly, this application provides a method for verifying email ownership, including:

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

[0013] In the ideal authentication phase, the client and the authenticator negotiate to develop an ideal authentication template based on the email transmission protocol and the SASL identity authentication mechanism. The client then fills in the ideal authentication template with personal identity information to determine the ideal authentication process. The personal identity information includes an email address and a password.

[0014] During the interaction execution phase, a TLS connection is established between the client, the authenticator, and the service provider based on the TLS Oracle framework. The client and the authenticator cooperate to perform the identity authentication process in the Mail Transfer Protocol in accordance with the ideal authentication process and in conjunction with the service provider, so that the authenticator can obtain 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 discloses key identifiers in the authentication interaction process according to the ideal authentication template, so as to allow the verifier to verify the correctness and integrity, and obtain the identity authentication result through the encrypted text of the request and response in the disclosed authentication interaction process.

[0016] Secondly, this application provides an email account ownership verification device, comprising:

[0017] The Ideal Authentication Module is used during the Ideal Authentication phase to enable the client and the authenticator to negotiate, formulate an Ideal Authentication Template based on the email transmission protocol and the SASL identity authentication mechanism, and enable the client to fill in the Ideal Authentication Template with personal identity information to determine the Ideal Authentication process; the personal identity information includes email address and password;

[0018] The interaction execution module is used to establish a TLS connection between the client, the authenticator, and the service provider based on the TLS Oracle framework during the interaction execution phase. It also enables the client and the authenticator to cooperate in performing the identity authentication process in the Mail Transfer Protocol according to the ideal authentication process and in conjunction with the service provider, so that the authenticator can obtain 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, during the authentication disclosure and verification phase, instruct the client to disclose key identifiers in the authentication interaction process according to the ideal authentication template, so as to allow the verifier to verify the correctness and integrity, and obtain the identity authentication result through the encrypted text of the request and response in the disclosed authentication interaction process.

[0020] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored on 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 the above.

[0021] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the mailbox ownership verification method described in any one of the above descriptions.

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

[0023] This application establishes a connection between the user, the authenticator, and the service provider based on the TLS Oracle framework. The user, authenticator, and service provider execute mailbox transport protocols such as SMTP, IMAP, and POP3 within the TLS Oracle framework. Through the TLS Oracle framework, the user and the authenticator jointly execute the Transport Layer Security (TLS) protocol, share the session key for the TLS connection, and collaboratively encrypt the protocol exchange data. The user then sends the encrypted data packet containing the encrypted text to the service provider. This application only extends the encryption of the exchange data from being performed independently by the user to being collaboratively encrypted by the user and the authenticator, without changing the output encrypted data packet. Therefore, the service provider cannot distinguish between the encrypted data sent by the user based on the TLS Oracle framework and the encrypted data sent under normal interaction. Thus, the user can disclose the authentication result contained in the protocol to the authenticator without the service provider's knowledge. If the user's authentication is successful, the authenticator can trust the user's ownership of the mailbox. Furthermore, this application utilizes the authentication information contained in the mailbox transport protocol as proof of the user's mailbox ownership, avoiding the need for verification emails, preventing privacy leaks, and fixing security vulnerabilities. Attached Figure Description

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

[0025] Figure 1 A schematic diagram of the SASL identity authentication interaction process provided in this application;

[0026] Figure 2 Flowchart of the email ownership verification method provided in this application;

[0027] Figure 3 This is a diagram illustrating the information exchange between the verifier, client, and service provider provided in this application.

[0028] Figure 4 This is a schematic diagram of the ideal authentication interaction template provided for this application;

[0029] Figure 5 This is a schematic diagram of the ideal authentication interaction process provided for this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0031] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] In today's information society, protecting email address privacy is crucial, impacting both personal privacy and cybersecurity. First, an email address is a vital identifier of an individual; misuse can lead to users receiving excessive spam, advertising, and even targeted scams. Second, email addresses serve as markers of a user's online behavior; malicious actors can combine this with other publicly available information to create user profiles, thereby infringing on personal privacy. Third, email addresses are a core credential for many online accounts; stealing them allows malicious actors to launch phishing attacks, steal passwords and other sensitive information, resulting in financial losses or data breaches. However, current traditional email ownership authentication methods require users to disclose their complete email address, compromising both privacy and security.

[0033] This application proposes a general email ownership authentication method based on Simple Authentication and Security Layer (SASL) in email transport protocols. By utilizing email transport protocols such as Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol (IMAP), and Post Office Protocol-Version 3 (POP3), a privacy-enhanced security authentication process using SASL is employed to verify the user's identity. The authentication result is then disclosed to the verifier via a TLS oracle framework as proof of email ownership. This achieves an ownership authentication scheme that requires no email verification and is transparent to the service provider.

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

[0035] (1) Client (C): The client acts as an agent for the user in performing the authentication process, representing an entity that wishes to prove to the authenticator (third party) that it owns a specific email address, denoted by the symbol C. This application assumes that C has legitimate access rights to the email address to be verified, and is able to send, receive, and access emails. However, a malicious C might attempt to prove ownership of an email address that it does not own.

[0036] (2) Verifier (V): The verifier is an application or service that needs to verify ownership of C's email address, denoted 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 offers (such as account recovery), without disclosing the complete email address. However, a malicious V may attempt to obtain sensitive identity information that C has not disclosed in this process.

[0037] (3) Service Provider (S): The service provider is the provider of email transmission services (such as Gmail, Outlook, etc.), denoted by the symbol S. This application requires that the email transmission protocol service provided by S supports the TLS protocol to protect transmitted data. S is generally considered trustworthy and reliable because malicious behavior would damage its reputation. However, S may analyze its forwarded traffic data out of curiosity, thereby monitoring users' online behavior.

[0038] The safety 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 a wrong password) to interact with S and complete successful authentication.

[0040] (2) Privacy: Malicious V cannot obtain any information that honest C has not proactively disclosed.

[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 provider is unaware: When C is honest, S cannot distinguish between the connection interaction established by C through the execution of the scheme of this application and the regular connection interaction established by C.

[0043] The background information 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 abstraction layer built between specific protocols and authentication mechanisms, enabling any protocol to achieve secure authentication through any authentication mechanism without redesign. Protocols can choose the most suitable mechanism based on their specific security requirements and operating environment. Common authentication mechanisms include PLAIN, LOGIN, and XOAUTH2.

[0045] SASL's identity authentication interaction process is as follows: Figure 1 As shown:

[0046] Line 1: Client C sends a SASL authentication request, which includes a field indicating the name of the authentication mechanism selected by C.

[0047] Lines 2-4: The service provider S and the client C use a challenge-response authentication process. S first issues a verification challenge, and C resolves the challenge and returns a response. This process can contain one or more pairs of challenge-response pairs.

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

[0049] in, Figure 1 The authentication result contained in line 5 is the evidence that this application wishes to credibly disclose to the verifier for email ownership authentication. If the user receives a successful authentication output from the service provider during the SASL authentication interaction phase of the email transfer protocol, then the user can be considered to own the email account.

[0050] (2) Email Transmission Protocols: Email transmission relies on three key protocols: SMTP, IMAP, and POP3. SMTP is responsible for sending emails, while IMAP and POP3 are responsible for receiving them. However, the original framework of these protocols lacks necessary security protections. During execution, they cannot verify the identities of the communicating parties, nor can they guarantee the confidentiality and integrity of data during transmission. Email transmission protocols enhance the security of the original protocols and solve these problems by integrating SASL authentication and TLS / SSL protocols.

[0051] By integrating the SASL framework, email service providers can 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, authentication, and data integrity protection, preventing data from being eavesdropped on or tampered with during network transmission. Currently, the main methods for establishing TLS connections using email transmission protocols are implicit TLS and STARTTLS.

[0052] (3) TLS Oracle Framework: The TLS Oracle framework enables the trusted export of encrypted data in the TLS protocol and proves the source of the data to the verifier while protecting privacy. It allows users who establish a connection with the service provider through the TLS protocol to trustedally disclose specific data of the interaction to the verifier (third party), or selectively disclose assertions related to the data through zero-knowledge proofs.

[0053] The process of the TLS Oracle framework used in this application is represented as follows, with the main participants including the client (C), the verifier (V), and the service provider (S). The meanings of the symbols used are as follows:

[0054] pp: Common parameters that C and V need to negotiate when implementing the TLS Oracle protocol.

[0055] tk: The session key for encrypting session data in the 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 uses... express.

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

[0059] cm: C is a cryptographic commitment to session data.

[0060] r: A random number chosen by C when making a commitment to session data.

[0061] The TLS Oracle framework process consists of 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. The two parties negotiate the common parameter pp, including parameters such as the TLS version number to be established later.

[0063] Handshake established: O.Handshake(pp, C<>, V<>) → (C(tk) c ), V(tk v >): C and V jointly negotiate the various parameters of the TLS handshake phase with S. After the negotiation, S obtains the stacked cryptographic key parameter tk for the TLS session phase, while 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 jointly encrypt request Q, and both parties receive the encrypted ciphertext request. C will then Send to S, and then receive the request response from S. The message is then forwarded to V. C and V jointly verify the integrity of the message. In general, at this stage, C and V jointly encrypt the sent request and verify the integrity and authentication of the received response.

[0065] Session commitment: Decrypting TLS session data in C Previously, C needed to... Make a commitment and output cm to avoid C incorrectly disclosing session data content to V.

[0066] Open commitment: O.Open(pp, C<M,r> V(cm>)→(C<>,V<0 / 1>): C opens a session data to V. Let M be the variable, and prove that M is the same as the content promised by cm. If V successfully verifies, then C has successfully disclosed to V the data content of its interaction with 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 email transmission protocols: SMTP, IMAP, and POP3, as well as multiple SASL 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 uses... express.

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

[0071] k: Indicates the number of rounds in which the "challenge-response" authentication protocol is implemented in SASL.

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

[0073] U: Represents the ideal authentication interaction message flow designed according to SASL and mailbox transport protocols.

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

[0075] φ: Indicates the type of SASL authentication mechanism used in the email ownership authentication process, such as PLAIN, LOGIN, etc.

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

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

[0078] cm: C is a cryptographic commitment to session data.

[0079] r: A random number chosen by C when making a commitment to session data.

[0080] This application provides a method for verifying email ownership. This method is executed by a computer device, specifically a terminal or server, or both. In this application embodiment, for example... Figures 2-3As shown, the method includes the following steps.

[0081] An email 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 phase, the client and the authenticator negotiate to develop an ideal authentication template based on the email transmission protocol and the SASL authentication mechanism. The client fills in the ideal authentication template with its identity information (including email address and password) to obtain the ideal authentication process.

[0083] S2: During the interaction execution phase, a TLS connection is established between the client, the authenticator, and the service provider based on the TLS Oracle framework. The client and the authenticator cooperate to perform the identity authentication process in the Mail Transfer Protocol in accordance with the ideal authentication process and in conjunction with the service provider, so that the authenticator can obtain the encrypted text of the request and response during the authentication interaction between the client and the service provider.

[0084] S3: In the authentication disclosure and verification phase, the client discloses key identifiers in the authentication interaction process according to the ideal authentication template, so as to allow the verifier to verify the correctness and integrity, and obtain the identity authentication result through the encrypted text of the request and response in the disclosed authentication interaction process.

[0085] In one exemplary embodiment, the ideal authentication phase specifically includes the following steps.

[0086] S11: The client and the authenticator negotiate to determine the ideal authentication template that the client needs to follow when executing the SASL authentication mechanism in the email transmission protocol, based on the email transmission protocol and the SASL authentication mechanism. The ideal authentication template includes fixed fields in all requests and commands, as well as the service provider's response content. Among these fixed fields, the fields involving client identity information and service provider identity information are empty fields. The service provider's response content is the service provider's successful response 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; during the sending of the capability request command, the missing field is a field representing the client's IP or domain name information.

[0088] S13: In the ideal authentication template, the client sends an authentication request command to the service provider to execute the "challenge-response" interaction step; in the "challenge-response" interaction step, the missing fields are the client's email address and authentication password in the "challenge-response" interaction step.

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

[0090] S15: After the client completes the ideal authentication template based on its personal identity information, determine the complete content of all messages sent by the client in the ideal authentication process, and assume that the service provider responds successfully and correctly to all requests, and complete the message content sent by the service provider in the ideal authentication process.

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

[0092] Γ={U mark ,l}

[0093] Among them, U mark The key identifier is the one that identifies the ideal authentication process; l is the regular expression that needs to be followed to construct a message containing credentials, which is determined by the name of the SASL 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 as follows:

[0095]

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

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

[0098] S111: Instruct the client and the verifier to negotiate and confirm the email transmission protocol to be executed, and confirm that the client needs to send a capability request command to the service provider.

[0099] S112: If the capability request command is successfully responded to, instruct the service provider to return the list of extended services.

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

[0101] S114: The service provider authenticates with the client according to the SASL authentication mechanism name in a "challenge-response" mode. In each round of "challenge-response" interaction, the service provider sends a challenge, and the client replies with a response to resolve the challenge, until the service provider replies with a response 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 be left blank.

[0102] In practical applications, based on a series of numbered RequestForComments (RFC) standards for email transmission protocols and SASL authentication mechanisms, the client and the authenticator, in conjunction with the specific email transmission protocol L and SASL authentication mechanism φ, can construct an ideal authentication interaction template Γ={U mark ,l}。where U mark It is a key identifier that can identify an ideal certification process; it is Q. pre ,R pre , and R a The `cred` field contains fixed values ​​defined by the RFC standard, including specific commands and response codes. `l` is the regular expression that must be followed to construct a message containing `cred = {addr, passwd}`, determined by the SASL authentication mechanism `φ` used. The ideal authentication template contains the fixed fields specified in the RFC standard for the corresponding message; sections involving client and service information should be left blank.

[0103] This application specifies the ideal authentication process for users performing email ownership verification.

[0104]

[0105] The ideal authentication process U is completed by client C supplementing the identity information of the ideal authentication template. Client C first sends a capability request command, represented as Q. pre R requests a list of extended services from service provider S. S sends its own list of supported extended services to C, denoted as R. preA successful response from S also indicates that the service configuration lists for both C and S have been successfully initialized, any ongoing tasks have been cleared, and the state list has been reset.

[0106] Then, C needs to immediately execute the SASL authentication mechanism. C first issues an authentication request, including the name of the selected SASL authentication mechanism φ (e.g., AUTH PLAIN), denoted as Q. a Then S performs authentication based on φ and C according to a "challenge-response" model, executing a total of k rounds, denoted as... In each round of the "challenge-response" interaction, S sends a challenge to R. i C responded to Q's challenge. i Finally, S replies with the response R after successful authentication. a .

[0107] Taking the PLAIN authentication mechanism in SMTP as an example, the ideal authentication interaction template generated is as follows: Figure 4 As shown, a capability request command is given where the first line is sent by C, for example, Q. pre ="EHLO*******", if S supports the extended list of email services, it will reply with a response containing response code 250 and a list of supported services, i.e., R pre ="250******". Then C sends Q according to the authentication request content specified in the authentication interaction template. a ="AUTH PLAIN", S recognizes the authentication mechanism φ=PLAIN requested by C and initiates 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. Subsequently, C constructs a response request to the challenge according to the regular expression l that must be followed to construct a message containing "cred", which includes the email address and authentication password, and encodes it using Base64 encoding, which can be represented as Q1="Base64(****** <nul> ****** <nul>******)″. S then verifies C's email address and authentication password, i.e., verifies C's identity. If the verification is successful, S replies with a successful authentication response, which includes response code 235, which can be represented as R. a ="235******".

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

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

[0110] S21: Instruct the client and the verifier to execute the initialization instructions in the TLS Oracle framework used in the interaction execution phase, and generate the TLS Oracle framework public parameter pp required for subsequent connection 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.

[0111] S22: Based on the public parameter pp, instruct the client and the authenticator to execute the handshake establishment instructions in the TLS Oracle framework used in the interaction execution phase to establish a TLS connection with the service provider; wherein, the client and the authenticator do not need to input anything, and the client receives the shared session key share tk of the session key after executing the handshake instructions. c ,tk c The shared session key share (tk) in the TLS protocol owned by the client; the shared session key share (tk) received by the authenticator after executing the handshake instructions. v ,tk v This refers to the share of the shared session key in the TLS protocol owned by the verifier.

[0112] S23: Based on the TLS connection, instruct the client to complete the authentication request content according to the ideal authentication template based on the credentials.

[0113] S24: The client and the verifier work together to send the authentication request content to the service provider in sequence, and receive a list of encrypted response messages sent by the service provider.

[0114] S25: Based on the authentication request content and the encrypted response message list, instruct the client and the verifier to execute the data exchange instructions of the interaction execution phase to perform the identity authentication process; during execution, the client needs to input its shared session key share tk. c and the j-th response Q sent by the client j The verifier needs to enter the share (tk) of the shared session key they possess. v The encryption request and corresponding encryption response received by the client and the authenticator after completing the data exchange instruction. and The request is for the ciphertext after the j-th encryption. The ciphertext response returned by the service provider after the j-th encryption.

[0115] S26: Instruct the client to execute the commitment instruction in the authentication disclosure and verification phase to determine the ideal encrypted authentication process; wherein, the client needs to input an encrypted message. The random number r and the shared session key share tk c , This includes encrypted authentication request content and encrypted response messages. For the list of authentication request content, This is a list of encrypted response messages; the verifier needs to enter the share of the shared session key tk they possess. v After executing the commitment instruction, the client and the verifier obtain the corresponding information. The promise cm j cm j This represents the cryptographic commitment to the session data in the j-th session.

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

[0117] First, C and V are executed:

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

[0119] Generate the public parameters pp for establishing a TLS Oracle connection.

[0120] Then, C determines the domain name and port of the service provider S, and checks whether the email transfer protocol provided by the target service provider S supports the TLS protocol, and what connection method is used 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] This enables C and S to establish a TLS connection. Then, C, based on the credentials cred = (addr, passwd), completes the authentication request according to the ideal authentication template Γ.

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

[0125] Then, together with V, they are sent sequentially to S, and then the encrypted response message list R = (R_V ... pre R a R1, ..., R k )

[0126] C executes:

[0127]

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

[0129] Then C receives the encryption request. and response The message makes a commitment:

[0130]

[0131] in, get V will then transfer the session key share tk v Send it to C so that C can decrypt the encrypted message.

[0132] In this stage, the verifier V can determine the validity of the received data. and Organize the ideal authentication process for encryption.

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

[0134] S31: Instruct the client to execute the commitment instruction during the authentication disclosure and verification phase, disclosing key identifiers in the authentication interaction process; wherein, the client needs to input plaintext message M. j And the corresponding random number r, the verifier needs to input the commitment cm to be opened. j If the verifier accepts the commitment cm j If the result of opening is true, output 1; otherwise, output 0. Let the verifier verify whether the identifier is the same as the identifier in the ideal authentication template. If yes, the verification is successful; if no, the verification is unsuccessful.

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

[0136] Verify whether the identifiers disclosed in V are the same as those in the template Γ. Verification includes the number of identifiers, the content of the identifiers, and whether the combination of the email address and verification password conforms to the regular expression l.

[0137] If the verification passes, V outputs 1, indicating that C and S have conducted a legitimate 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 in performing the correct identity authentication operation. This application formulates an ideal authentication template Γ based on the rules of the email transmission protocol and the SASL identity authentication mechanism. The ideal authentication template Γ includes the request content, execution order, and identification content that needs to be subsequently disclosed and verified for the authentication interaction between C and S. V can verify the completeness 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 phase is the interactive execution phase. C, V, and S establish a connection based on the TLS Oracle framework. C and V collaborate to execute the authentication process in the mailbox transmission protocol with S according to the ideal authentication template Γ. From S's perspective, C's operations are no different from normal authentication operations. After execution, V obtains the encrypted text of the requests and responses throughout the entire interactive process.

[0141] The third part is the authentication disclosure and verification stage. C discloses the identifiers in the authentication interaction process according to the provisions of the ideal authentication template Γ, so that V can verify the correctness and completeness of the authentication process, and at the same time obtain the identity authentication result.

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

[0143] (1) No email verification required.

[0144] This application utilizes the SASL authentication method within the Email Transfer Protocol (STP) to identify email ownership, thereby eliminating the need for verification emails. It extracts an ideal authentication interaction paradigm from the SASL specification, ensuring its reliability through formal definition and proof. The SASL-based authentication result is then reliably exported to the verifier for verification, serving as proof of email ownership provided by the user. This approach only requires the user to execute the authentication process within the STP, without disclosing their complete email address to the service provider or receiving a verification email. This avoids the service provider's collection of sensitive user information and the security and privacy vulnerabilities caused by verification emails.

[0145] (2) Compatible with all general needs.

[0146] Email transmission protocols, as the fundamental support for email services, are widely used globally. Commonly used protocols include SMTP, IMAP, and POP3. These protocols, through standardized communication methods, enable interconnection between different devices and mail servers, ensuring efficient delivery and reliable storage of emails between different email providers. Furthermore, these protocols use the SASL authentication mechanism to authenticate user identities, thereby enhancing email transmission security. This application is compatible with the three commonly used email transmission protocols and various SASL authentication mechanisms, seamlessly integrating with existing email providers and providing compatibility and universality. This universality ensures that this application is applicable to a wide range of email providers, such as Gmail and Outlook, thereby expanding its usability and influence.

[0147] (3) The server is unaware of this.

[0148] The email ownership authentication method implemented in this application does not require email verification, so honest but curious email service providers cannot monitor or track users' authorization authentication behavior. Furthermore, since this application utilizes the authentication portion of the normal email transmission protocol for ownership authentication, email providers cannot distinguish between user requests using this application and those executing the normal email transmission protocol, achieving server-side non-disclosure. Moreover, this application's implementation requires no modification or cooperation from email service providers, improving the solution's practicality.

[0149] (4) Privacy protection.

[0150] This application utilizes the TLS Oracles scheme to protect the privacy and security of data exchanged between users and service providers, ensuring that sensitive user information (such as email addresses or passwords) is not obtained by the authenticator. Simultaneously, the authenticator participates in the email transmission protocol interaction between users and service providers through the TLS Oracles scheme, verifying the source and integrity of the exchanged data.

[0151] Based on the same inventive concept, this application also provides an email ownership verification device for implementing the email ownership verification method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations of the one or more email ownership verification device embodiments provided below can be found in the limitations of the email ownership verification method described above, and will not be repeated here.

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

[0153] The Ideal Authentication Module is used during the Ideal Authentication phase to enable the client and the authenticator to negotiate and formulate an Ideal Authentication Template based on the email transmission protocol and the SASL identity authentication mechanism.

[0154] The interaction establishment module is used to establish a TLS connection between the client, the authenticator, and the service provider based on the TLS Oracle framework during the interaction execution phase. It also enables the client and the authenticator to cooperate in performing the identity authentication process in the Mail Transfer Protocol according to the ideal authentication template and in conjunction with the service provider, so that the authenticator can obtain the encrypted text of the request and response during the authentication interaction between the client and the service provider.

[0155] The authentication disclosure and verification module is used to, during the authentication disclosure and verification phase, instruct the client to disclose key identifiers in the authentication interaction process according to the ideal authentication template, so as to allow the verifier to verify the correctness and integrity, and 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, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores mailbox ownership verification data. The I / O interfaces of the computer device are used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a mailbox ownership verification method.

[0157] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0158] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the methods described above.

[0159] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods described above.

[0160] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0161] In this application, all actions to acquire signals, information, or data are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with the authorization granted by the owner of the relevant device.

[0162] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0163] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.< / nul> < / nul>

Claims

1. A method for verifying email ownership, characterized in that, The email ownership verification method includes: the ideal authentication phase, the interactive execution phase, and the authentication disclosure and verification phase; In the ideal authentication phase, the client and the verifier negotiate to develop an ideal authentication template based on the email transmission protocol and the SASL identity authentication mechanism. The client then fills in the ideal authentication template with personal identity information to determine the ideal authentication process. The personal identity information includes an email address and a password. The ideal authentication template includes the request content, execution order, and identification content that needs to be disclosed and verified subsequently between the client and the service provider for authentication interaction. During the interaction execution phase, a TLS connection is established between the client, the authenticator, and the service provider based on the TLS Oracle framework. The client and the authenticator cooperate to perform the identity authentication process in the Mail Transfer Protocol in accordance with the ideal authentication process and in conjunction with the service provider, so that the authenticator can obtain 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 discloses key identifiers in the authentication interaction process according to the ideal authentication template, so that the verifier can verify the correctness and completeness of the authentication process and obtain the identity authentication result through the encrypted text of the request and response in the disclosed authentication interaction process.

2. The email ownership verification method according to claim 1, characterized in that, The ideal authentication phase specifically includes: The client and the authenticator negotiate to determine the ideal authentication template that the client needs to follow when executing the SASL authentication mechanism in the email transmission protocol, based on the email transmission protocol and the SASL authentication mechanism. The ideal authentication template includes fixed fields in all requests and commands, as well as the service provider's response content. Among the fixed fields, the fields involving client identity information and service provider identity information are empty fields. The service provider's response content is the service provider's successful response 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 list of extended services; during the sending of the capability request command, the missing field is a field representing the client's IP or domain name information; In the ideal authentication template, the client sends an authentication request command to the service provider to execute the "challenge-response" interaction step; in the "challenge-response" interaction step, the missing fields are the client's email address and authentication password in the "challenge-response" interaction step; Based on the ideal authentication template, the client fills in the missing fields in the ideal authentication template during the process of sending capability request commands according to its personal identity information; After the client completes the ideal authentication template based on its personal identity information, the complete content of all messages sent by the client in the ideal authentication process is determined, and the service provider is assumed to respond successfully and correctly to all requests, and the message content sent by the service provider in the ideal authentication process is completed.

3. The email ownership verification method according to claim 2, characterized in that, Based on the Mail Transfer Protocol and the SASL authentication mechanism, the ideal authentication template that the client needs to follow when executing the SASL authentication mechanism in the Mail Transfer Protocol is determined, specifically including: The client and the authenticator negotiate and confirm the email transmission protocol to be executed, and confirm that the client needs to send a capability request command to the service provider; If the capability request command responds successfully, the service provider will return a list of extended services. Confirm that the client sends an authentication request to the service provider; the authentication request includes the name of the selected SASL authentication mechanism; the ideal authentication template contains a fixed field for the name of the selected SASL authentication mechanism, and the parts involving client information and service provider information should be left blank; the ideal authentication template also includes the service provider's response content, which is the service provider's successful response to the client's authentication request; The service provider authenticates with the client using the SASL authentication mechanism name in a "challenge-response" mode. In each round of "challenge-response" interaction, the service provider sends a challenge, and the client responds with a response to resolve the challenge, until the service provider outputs a response indicating successful authentication. The ideal authentication template also includes fixed fields in the "challenge-response" interaction, while the parts involving client information and service provider information should be left blank.

4. The email ownership verification method according to claim 2, characterized in that, The ideal authentication template for: in, Key identifiers that can identify an ideal certification process; The regular expression that must be followed to construct a message containing credentials is determined by the name of the SASL authentication mechanism used; the credentials include the email address and authentication password used by the client during the authentication process.

5. The email ownership verification method according to claim 2, characterized in that, The ideal authentication process for: in, Request a command for capability; A response to a capability request command; For authentication request; For the first i In the "challenge-response" interaction, the challenge sent by the service provider; For the first i In the "challenge-response" interaction, the client responds with a solution to the challenge; k This refers to the total number of rounds of the "Challenge-Response" interaction. The server outputs a response indicating successful identity authentication.

6. The email ownership verification method according to claim 1, characterized in that, The interactive execution phase specifically includes: The client and the authenticator execute the initialization instructions in the TLS Oracle framework used during the interaction execution phase to generate the common parameters of the TLS Oracle framework required for subsequent connection establishment. At this point, neither the client nor the verifier needs to input anything; after execution, both parties obtain the shared parameters. ; Based on the aforementioned common parameters The client and the authenticator execute the handshake establishment instructions in the TLS Oracle framework used in the interaction execution phase to establish a TLS connection with the service provider; wherein, the client and the authenticator do not need to input anything, and the client receives the shared session key share of the session key after executing the handshake instructions. , The shared session key share in the TLS protocol owned by the client; the shared session key share received by the authenticator after executing the handshake instructions. , This refers to the share of the shared session key in the TLS protocol held by the verification party. Based on the TLS connection, the client completes the authentication request content according to the ideal authentication template based on the credentials; The client and the verifier work together to send the authentication request content to the service provider in sequence, and receive a list of encrypted response messages sent by the service provider. Based on the authentication request content and the encrypted response message list, the client and the verifier execute the data exchange instructions of the interaction execution phase to perform the identity authentication process; wherein, during execution, the client needs to input its share of the shared session key. and the client number j The next response The authenticator needs to enter the share of the shared session key they possess. The encryption request and corresponding encryption response received by the client and the authenticator after completing the data exchange instruction. and ; For the first j The encrypted ciphertext request; No. j The encrypted response returned by the service provider after secondary encryption; The client executes the commitment instruction in the authentication disclosure and verification phase to determine the ideal encrypted authentication process; wherein, the client needs to input an encrypted message. random numbers and the share of the shared session key owned , , This includes encrypted authentication request content and encrypted response messages. For the list of authentication request content, This is a list of encrypted response messages; the verifier needs to enter the share of the shared session key they possess. After executing the commitment instruction, the client and the verifier obtain the corresponding information. promise , For the first j A cryptographic commitment to the session data in this session.

7. The email ownership verification method according to claim 6, characterized in that, The certification disclosure and verification phase specifically includes: The client is instructed to execute a commitment instruction during the authentication disclosure and verification phase, disclosing key identifiers in the authentication interaction process; wherein, the client needs to input plaintext messages. and the corresponding random number The verifier needs to enter the commitment to be opened. If the verification party accepts the commitment If the result of opening is found, output 1; otherwise, output 0. The verifier is instructed to verify whether the identifier is the same as the identifier in the ideal authentication template. If so, the verification is successful; If not, the verification failed.

8. A device for verifying email ownership, characterized in that, The mailbox ownership verification device includes: The ideal authentication module is used during the ideal authentication phase to enable the client and the verifier to negotiate, formulate an ideal authentication template based on the email transmission protocol and the SASL identity authentication mechanism, and enable the client to fill in the ideal authentication template with personal identity information to determine the ideal authentication process; the personal identity information includes email address and password; the ideal authentication template includes the request content, execution order and identification content that needs to be disclosed and verified subsequently between the client and the service provider for authentication interaction; The interaction execution module is used to establish a TLS connection between the client, the authenticator, and the service provider based on the TLS Oracle framework during the interaction execution phase. It also enables the client and the authenticator to cooperate in performing the identity authentication process in the Mail Transfer Protocol according to the ideal authentication process and in conjunction with the service provider, so that the authenticator can obtain 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, during the authentication disclosure and verification phase, instruct the client to disclose key identifiers in the authentication interaction process according to the ideal authentication template, so as to allow the verifier to verify the correctness and completeness of the authentication process, and 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 on the memory and executable on the processor, characterized in that the processor executes the computer program to implement the mailbox ownership verification method according to any one of claims 1-7.

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

Images