A method, system, electronic device, and readable storage medium for transaction non-repudiation

Abstract

This invention relates to a method, system, electronic device, and readable storage medium for transaction non-repudiation. The method includes: a client encrypting plaintext information using a mutually agreed-upon symmetric encryption algorithm to generate ciphertext information, which is placed in the request message body; the client signing the plaintext information using an asymmetric algorithm and its private key certificate to generate a signature, which is placed in the request message header; the server receiving the client's request and decrypting the ciphertext information using the client's key to generate plaintext information, while simultaneously verifying the signature using the client's public key certificate and the request message header; the server encrypting the plaintext information using a mutually agreed-upon symmetric encryption algorithm to generate ciphertext information, which is placed in the request message body; and the server signing the plaintext information using an asymmetric algorithm and its private key certificate to generate a signature, which is placed in the request message header. This method ensures the confidentiality and integrity of transmitted messages, achieving transaction non-repudiation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a transaction anti-repudiation method, system, electronic device and readable storage medium. BACKGROUND

[0002] In the process of popularization of Internet application, more and more sites open their resources to developers for calling. The API calling provided to the outside makes the content correlation between sites stronger, and these open platforms also bring greater value to users, developers and small and medium-sized websites.

[0003] Openness is a development trend, and more and more products are moving towards openness. Commercial banks also expose their mature products to cooperative institutions or users in the form of API interface, increase user stickiness, provide better financial services, and bring convenience and value to a larger customer group.

[0004] At present, the information interaction between traditional commercial banks and external cooperative parties usually adopts a set of external connection platform for access, and verifies the access by setting a network whitelist mechanism. In order to ensure the data interaction anti-tampering and transaction anti-repudiation, in addition to establishing an SSL channel at the transmission channel layer to ensure the confidentiality of the transmission channel, bank-enterprise direct connection identity authentication, transmission integrity, transmission message confidentiality and the like also need to be realized, so as to realize the secure transmission of a transaction request. In summary, the traditional API service urgently needs stronger security protection reinforcement capability in terms of security, stability and the like, reduces transaction risks and unnecessary property losses. SUMMARY

[0005] In order to solve the problems of the prior art, the present application provides a transaction anti-repudiation method, system, electronic device and readable storage medium, which can effectively realize the integrity and confidentiality of message transmission, ensure data interaction anti-tampering and transaction anti-repudiation.

[0006] To achieve the above object, the technical scheme adopted by the present application comprises:

[0007] The present application discloses a transaction anti-repudiation method in the first aspect, comprising:

[0008] The client uses a symmetric encryption algorithm agreed by both parties to encrypt the plaintext information, generates ciphertext information, and places it in the request message body;

[0009] The client uses an asymmetric algorithm and a client private key certificate to sign the plaintext information, generates signature information, and places it in the request message header;

[0010] The server receives the request of the client, uses the client key to decrypt the ciphertext information, generates plaintext information, and uses the client public key certificate and the request message header to verify the signature.

[0011] The server uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generates ciphertext information, and places it in the request message body.

[0012] The server uses an asymmetric algorithm and a server private key certificate to sign the plaintext information, generates signature information, and places it in the request message header.

[0013] The client receives the response information from the server, decrypts the ciphertext information using the client key to generate plaintext information, and uses the server public key certificate to verify the signature of the request message header.

[0014] Further, before the client uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information and generate ciphertext information and place it in the request message body, the method further includes the client applying for an account on the server, uploading username and password information, the server generating a client symmetric key and sending it to the client.

[0015] Further, before the client uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information and generate ciphertext information and place it in the request message body, the method further includes the client and the server exchanging public key information.

[0016] Further, the method further includes the client encrypting the password information.

[0017] Further, the method further includes the client using a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information of the username and the encrypted password information, generate ciphertext information, and place it in the request message body.

[0018] Further, the client encrypting the password information includes the client generating a dynamic password to encrypt the password information.

[0019] Further, before the server uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information and generate ciphertext information and place it in the request message body, the method further includes the server verifying the correctness of the password information.

[0020] Further, before the client uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information and generate ciphertext information and place it in the request message body, the method further includes the client establishing an SSL channel with the server to ensure the confidentiality of the transmission channel.

[0021] Further, the method further includes:

[0022] Step N1: The client sends the client's SSL protocol version number, encryption algorithm type, and generated random number to the server;

[0023] Step N2: The server transmits the client's SSL protocol version number, the type of encryption algorithm, the generated random number, and other relevant information to the client. At the same time, the server transmits the server's public key certificate to the client.

[0024] Step N3: The client verifies the legitimacy of the server; if the legitimacy verification fails, the communication is disconnected; if the legitimacy verification passes, the next step is executed.

[0025] Step N4: The client randomly generates a client symmetric key for subsequent communication, encrypts the client symmetric key using the server's public key certificate, and transmits it to the server; wherein, the symmetric key is used for encryption and decryption of secure data communication using the SSL protocol;

[0026] Step N5: The client and the server communicate with each other, and the handshake process ends;

[0027] Step N6: Data communication through the SSL channel begins. The client and the server start communicating with each other using the same symmetric key, while simultaneously verifying the integrity of the communication.

[0028] A second aspect of the present invention discloses a transaction non-repudiation system, comprising:

[0029] The first encryption module involves the client encrypting the plaintext information using a symmetric encryption algorithm agreed upon by both parties, generating ciphertext information, which is placed in the request message body; and the client signing the plaintext information using an asymmetric algorithm and the client's private key certificate, generating signature information, which is placed in the request message header.

[0030] The first verification module involves the server receiving the client's request, decrypting the encrypted information using the client's key to generate plaintext information, and verifying the signature using the client's public key certificate and the request header.

[0031] The second encryption module involves the server using a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is placed in the request message body; and the server using an asymmetric algorithm and its private key certificate to sign the plaintext information, generating signature information, which is placed in the request message header.

[0032] The second verification module involves the client receiving the response information from the server, decrypting the ciphertext information using the client's key to generate plaintext information, and verifying the signature using the server's public key certificate and the request header.

[0033] A third aspect of the present invention discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0034] A fourth aspect of the present invention discloses an electronic device, including a processor and a memory;

[0035] The memory is used to store operation instructions;

[0036] The processor is configured to execute the above-described method by invoking the operation instructions.

[0037] A fourth aspect of the present invention discloses a computer program product comprising a computer program and / or instructions which, when executed by a processor, implement the steps of the method described above.

[0038] The beneficial effects of this invention are as follows:

[0039] The present invention employs a transaction non-repudiation method, system, electronic device, and readable storage medium. Based on this method, by setting request message parameter information, the system performs data parsing during message transmission and completes user identification and authentication, transaction data decryption, and signature verification operations according to different transaction types. While meeting the basic requirements of low loss and high performance in traditional message transmission requests, it achieves user identification, ensures the confidentiality and integrity of transmitted messages, and achieves true transaction non-repudiation and tamper-proofing. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the transaction non-repudiation method provided in an embodiment of the present invention.

[0041] Figure 2 This is a schematic diagram of the transmission channel encryption method provided in an embodiment of the present invention.

[0042] Figure 3 This is a schematic diagram of the transaction non-repudiation system provided in an embodiment of the present invention. Detailed Implementation

[0043] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0044] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0045] Example 1

[0046] This invention relates to a process flow as follows Figure 1 The transaction non-repudiation methods shown include:

[0047] Step S1: The client uses the symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is placed in the request message body (body.msg_content); the client uses an asymmetric algorithm and the client's private key certificate to sign the plaintext information, generating signature information, which is placed in the request message header (head.Sign).

[0048] Step S2: The server receives the client's request and uses the client's key to decrypt the encrypted information to generate plaintext information. At the same time, it uses the client's public key certificate and the request header (head.Sign) for verification to ensure that the data has not been tampered with.

[0049] Step S3: The server uses the symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is placed in the request message body (body.msg_content); the server uses an asymmetric algorithm and its private key certificate to sign the plaintext information, generating signature information, which is placed in the request message header (head.Sign).

[0050] Step S4: The client receives the response information from the server and uses the client key to decrypt the ciphertext information to generate plaintext information. At the same time, the client uses the server's public key certificate and the request header (head.Sign) to verify the signature and ensure that the data has not been tampered with.

[0051] Repeat steps S1-S4 in a loop until the business ends.

[0052] Optionally, before step S1, the method further includes the client applying to the server to open an account, uploading username and password information, and the server generating a symmetric key for the client and sending it to the client.

[0053] Optionally, in this embodiment, before step S1, the method further includes the client and the server exchanging public key information.

[0054] In this embodiment, after the symmetric key is generated for the first time, it will not be actively generated again under normal circumstances. A new symmetric key will only be generated after re-initialization or calling the interface, so as to control the life cycle of the symmetric key.

[0055] In this embodiment, the client and server encrypt the plaintext information using a symmetric algorithm (e.g., SM4 / 3DES) to generate ciphertext information, which is placed in the request message body (body.msg_content) to ensure the integrity of the transmitted message. Then, the client and server use an asymmetric algorithm (e.g., MD5WithRSA / SM3WithSM2) to generate a signature, which is placed in the request message header (head.Sign) to ensure the confidentiality of the transmitted message.

[0056] In real-world business scenarios, the methods described in the above embodiments allow users to perform basic services with low security requirements, such as browsing general information and financial news that are unrelated to security.

[0057] Example 2

[0058] Based on Implementation Example 1, an identity authentication process is added according to actual business needs, especially before the client initiates a business transaction for the first time, user authorization login is required.

[0059] This invention relates to another method for transaction non-repudiation, comprising:

[0060] Step P1: The client encrypts the password information;

[0061] Step P2: The client encrypts the username and encrypted password using a symmetric encryption algorithm agreed upon by both parties to generate ciphertext, which is placed in the request message body (body.msg_content); the client then signs the plaintext using an asymmetric algorithm and its private key certificate to generate a signature, which is placed in the request message header (head.Sign).

[0062] Step P3: The server receives the client's request and uses the client's key to decrypt the encrypted information to generate plaintext information. At the same time, it uses the client's public key certificate and the request header (head.Sign) to verify the signature and ensure that the data has not been tampered with.

[0063] Step P4: The server verifies the correctness of the password information. To prevent client applications from repeatedly obtaining the authorization token, each client generates no more than 10 keys at any time and sends them out, which are placed in the return message header (head.App_Auth_Token).

[0064] Step P5: The server uses the symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is placed in the request message body (body.msg_content); the server uses an asymmetric algorithm and its private key certificate to sign the plaintext information, generating signature information, which is placed in the request message header (head.Sign).

[0065] Step P6: The client receives the response information from the server and uses the client key to decrypt the encrypted information to generate plaintext information. At the same time, it uses the server's public key certificate and the request message header (head.Sign) to verify the signature and ensure that the data has not been tampered with.

[0066] Step P7: The client caches the request header (head.App_Auth_Token) and sets it in the request header (head.App_Auth_Token) during subsequent normal business requests for the server to perform user authorization authentication.

[0067] In real-world business scenarios, the methods described in the above embodiments allow users to perform core services with high security requirements, such as financial transactions and purchasing financial service products. User authentication enhances transaction security.

[0068] Example 3

[0069] Based on Embodiment 1, the method further includes establishing an SSL channel between the client and the server to ensure the confidentiality of the transmission channel.

[0070] This invention relates to another step process as follows: Figure 2 The schematic diagram shown illustrates the transmission channel encryption method, which includes:

[0071] Step N1: The client sends the client's SSL protocol version number, encryption algorithm type, and generated random number to the server;

[0072] Step N2: The server transmits the client's SSL protocol version number, the type of encryption algorithm, the generated random number, and other relevant information to the client. At the same time, the server transmits the server's public key certificate to the client.

[0073] Step N3: The client verifies the legitimacy of the server; if the legitimacy verification fails, the communication is disconnected; if the legitimacy verification passes, the next step is executed.

[0074] Step N4: The client randomly generates a client symmetric key for subsequent communication, encrypts the client symmetric key using the server's public key certificate, and transmits it to the server; wherein, the symmetric key is used for encryption and decryption of secure data communication using the SSL protocol;

[0075] Step N5: The client sends a message to the server, indicating that the symmetric key will be used for subsequent data communication, and at the same time notifies the server that the handshake process is over;

[0076] Step N6: The server sends a message to the client, indicating that the symmetric key will be used for subsequent data communication, and at the same time notifies the client that the handshake process is over;

[0077] Step N7: Data communication through the SSL channel begins. The client and the server begin communicating with each other using the same symmetric key, while simultaneously verifying the integrity of the communication.

[0078] This application provides a method for transaction non-repudiation, comprising: a client encrypting plaintext information using a mutually agreed symmetric encryption algorithm to generate ciphertext information, which is placed in the request message body; the client signing the plaintext information using an asymmetric algorithm and the client's private key certificate to generate signature information, which is placed in the request message header; the server receiving the client's request and decrypting the ciphertext information using the client's key to generate plaintext information, while simultaneously verifying the signature using the client's public key certificate and the request message header; the server encrypting the plaintext information using a mutually agreed symmetric encryption algorithm to generate ciphertext information, which is placed in the request message body; the server signing the plaintext information using an asymmetric algorithm and the server's private key certificate to generate signature information, which is placed in the request message header; and the client receiving the server's response information and decrypting the ciphertext information using the client's key to generate plaintext information, while simultaneously verifying the signature using the server's public key certificate and the request message header. This method is applied to commercial bank financial service platforms, which serve both internal business partners and external collaborating institutions. It is a financial system software that uses technological means to package internal financial capabilities to meet external needs. While meeting the basic requirements of low loss and high performance in traditional message transmission requests, this method achieves user identification, ensures the confidentiality and integrity of transmitted messages, and achieves true transaction non-repudiation and tamper-proofing.

[0079] Another aspect of the present invention relates to a transaction non-repudiation system, the structure of which is as follows: Figure 3 As shown, it includes:

[0080] The first encryption module involves the client encrypting the plaintext information using a symmetric encryption algorithm agreed upon by both parties, generating ciphertext information, which is placed in the request message body; and the client signing the plaintext information using an asymmetric algorithm and the client's private key certificate, generating signature information, which is placed in the request message header.

[0081] The first verification module involves the server receiving the client's request, decrypting the encrypted information using the client's key to generate plaintext information, and verifying the signature using the client's public key certificate and the request header.

[0082] The second encryption module involves the server using a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is placed in the request message body; and the server using an asymmetric algorithm and its private key certificate to sign the plaintext information, generating signature information, which is placed in the request message header.

[0083] The second verification module involves the client receiving the response information from the server, decrypting the ciphertext information using the client's key to generate plaintext information, and verifying the signature using the server's public key certificate and the request header.

[0084] By using this system, the aforementioned computational processing methods can be executed and the corresponding technical effects can be achieved.

[0085] Embodiments of the present invention also provide a computer-readable storage medium capable of implementing all the steps of the methods in the above embodiments, wherein the computer-readable storage medium stores a computer program that, when executed by a processor, implements all the steps of the methods in the above embodiments.

[0086] Embodiments of the present invention also provide an electronic device for performing the above-described method. As an implementation device for the method, the electronic device includes at least a processor and a memory. In particular, the memory stores data and related computer programs required for performing the method, such as [examples omitted]. The processor calls the data and programs in the memory to execute all the steps of the method and obtain the corresponding technical effect.

[0087] Preferably, the electronic device may include a bus architecture, which may include any number of interconnected buses and bridges. The bus will include various circuits linked together by one or more processors and memories. The bus may also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface between the bus and the receiver and transmitter. The receiver and transmitter may be the same element, i.e., a transceiver, providing a unit for communicating with various other systems over a transmission medium. The processor is responsible for managing the bus and general processing, while the memory may be used to store data used by the processor during operation.

[0088] Additionally, the electronic device may further include components such as a communication module, an input unit, an audio processor, a display, and a power supply. The processor (or controller, operating control) used may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device; the memory may be one or more of a buffer, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices, which can store the aforementioned data information, and may also store programs for executing the information, and the processor can execute the program stored in the memory to achieve information storage or processing, etc.; the input unit is used to provide input to the processor, for example, it can be a button or touch input device; the power supply is used to provide power to the electronic device; the display is used to display images and text, for example, it can be an LCD display. The communication module is a transmitter / receiver that transmits and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor to provide input signals and receive output signals, which can be the same as in conventional mobile communication terminals. Based on different communication technologies, multiple communication modules can be incorporated into the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) is also coupled to a speaker and microphone via an audio processor to provide audio output through the speaker and receive audio input from the microphone, thereby enabling typical telecommunications functions. The audio processor can include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor is coupled to a central processing unit, enabling on-device recording via the microphone and on-device playback of stored sound via the speaker.

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

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

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

[0092] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the functions specified in one or more boxes. Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0093] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for transaction non-repudiation, characterized in that, include: The client uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is then placed in the request message body. The client uses an asymmetric algorithm and its private key certificate to sign the plaintext information, generating a signature that is placed in the request header. The server receives the client's request, decrypts the encrypted information using the client's key to generate plaintext information, and verifies the signature using the client's public key certificate and the request header. The server uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is then placed in the request message body. The server uses an asymmetric algorithm and its private key certificate to sign the plaintext information, generating a signature that is placed in the request header. The client receives the response information from the server, decrypts the ciphertext information using the client key to generate plaintext information, and verifies the signature using the server's public key certificate and the request header. The method further includes the client applying to the server to open an account, uploading username and password information, and the server generating a symmetric key for the client and sending it to the client. The client uses a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information and generate ciphertext information, which is placed in the request message body before the client uses the ciphertext information. Before the client encrypts the plaintext information using a symmetric encryption algorithm agreed upon by both parties to generate ciphertext information, which is then placed in the request message body, the method also includes the client and the server exchanging public key information. Once the symmetric key is generated for the first time, it will not be generated automatically under normal circumstances. It will only be regenerated after re-initialization or by calling the interface.

2. The method as described in claim 1, characterized in that, The method also includes the client encrypting the password information.

3. The method as described in claim 2, characterized in that, The method further includes the client encrypting the username and encrypted password information using a symmetric encryption algorithm agreed upon by both parties to generate ciphertext information, which is then placed in the request message body.

4. The method as described in claim 2, characterized in that, The client's encryption of the password information includes the client generating a dynamic password to encrypt the password information.

5. The method as described in claim 3, characterized in that, The method further includes the server encrypting the plaintext information using a symmetric encryption algorithm agreed upon by both parties to generate ciphertext information, which is placed in the request message body before the server verifies the correctness of the ciphertext information.

6. The method according to any one of claims 1 to 5, characterized in that, Before the client encrypts the plaintext information using a symmetric encryption algorithm agreed upon by both parties to generate ciphertext information, which is then placed in the request message body, the method further includes establishing an SSL channel between the client and the server to ensure the confidentiality of the transmission channel.

7. The method as described in claim 6, characterized in that, The method further includes: Step N1: The client sends the client's SSL protocol version number, encryption algorithm type, and generated random number to the server; Step N2: The server transmits the client's SSL protocol version number, the type of encryption algorithm, the generated random number, and other relevant information to the client. At the same time, the server transmits the server's public key certificate to the client. Step N3: The client verifies the legitimacy of the server; if the legitimacy verification fails, the communication is disconnected; if the legitimacy verification passes, the next step is executed. Step N4: The client randomly generates a client symmetric key for subsequent communication, encrypts the client symmetric key using the server's public key certificate, and transmits it to the server; wherein, the symmetric key is used for encryption and decryption of secure data communication using the SSL protocol; Step N5: The client and the server communicate with each other, and the handshake process ends; Step N6: Data communication through the SSL channel begins. The client and the server start using the same symmetric key to communicate data, while simultaneously verifying the integrity of the communication.

8. A transaction non-repudiation system, characterized in that, include: The first encryption module involves the client using a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is then placed in the request message body. The client uses an asymmetric algorithm and its private key certificate to sign the plaintext information, generating a signature that is placed in the request header. The first verification module involves the server receiving the client's request, decrypting the encrypted information using the client's key to generate plaintext information, and verifying the signature using the client's public key certificate and the request header. The second encryption module involves the server using a symmetric encryption algorithm agreed upon by both parties to encrypt the plaintext information, generating ciphertext information, which is placed in the request message body; and the server using an asymmetric algorithm and its private key certificate to sign the plaintext information, generating signature information, which is placed in the request message header. The second verification module involves the client receiving the response information from the server, decrypting the ciphertext information using the client's key to generate plaintext information, and verifying the signature using the server's public key certificate and the request header. Before the client encrypts the plaintext information using a symmetric encryption algorithm agreed upon by both parties to generate ciphertext information, which is placed in the request message body, the client also applies to the server to open an account, uploads username and password information, and the server generates a symmetric key for the client and sends it to the client. Before the client encrypts the plaintext information using a symmetric encryption algorithm agreed upon by both parties to generate ciphertext information, which is placed in the request message body, the client and the server also exchange public key information. Once the symmetric key is generated for the first time, it will not be generated automatically under normal circumstances. It will only be regenerated after re-initialization or by calling the interface.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method of any one of claims 1 to 7.

10. An electronic device, characterized in that, Including processor and memory; The memory is used to store operation instructions; The processor is configured to execute the method of any one of claims 1 to 7 by invoking the operation instructions.

11. A computer program product, comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images