A trusted login method based on signature verification between mobile smart device and notary server

Abstract

The present invention discloses a trusted login method based on signature verification between a mobile smart device and a notary server, comprising: a user terminal receives a first comparison result, enters a personal password Ct, and uses the personal password Ct and a symmetric key algorithm to symmetrically encrypt a private key Kprt to obtain a ciphertext Sprt; the private key Kprt is used to sign the ciphertext Sprt to obtain a signature value Siprt; the ciphertext Sprt is encrypted by a public key Kproas of the notary server to obtain an encrypted value Ssptt; the signature value Siprt and the encrypted value Ssptt are sent to the notary server; and, when logging in and signing, the user terminal requests the ciphertext Sprt from the notary server, enters the personal password Ct, and performs AES decryption on the ciphertext Sprt to obtain the private key Kprt; the present invention adds a user password to protect the user key, and uses the user password to encrypt the user key, so that only the user can use it and keep it confidential. At the same time, if the user has doubts about the data, he can go to the notary system to extract the notarized data, compare it, and leave evidence for verification.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet identity authentication, and in particular to a trusted login method based on signature verification between a mobile smart device and a notary server. Background Art

[0002] At present, large enterprises and groups sign tens of thousands of contracts each year, with a wide variety of contracts. During the signing and circulation process, paper contracts are prone to risks such as tampering and leakage, and are difficult to identify and prevent. Problems are not discovered until later, or problems occur during the execution process. In addition to causing losses to the company, it also brings occupational risks to related personnel. At present, there are also identity verification and security issues when signing agreements on the Internet. Personal keys are difficult to ensure security and are easily leaked in multiple signing links. Summary of the invention

[0003] The purpose of this section is to summarize some aspects of embodiments of the present invention and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section and the specification abstract and the invention title of this application to avoid blurring the purpose of this section, the specification abstract and the invention title, and such simplifications or omissions cannot be used to limit the scope of the present invention.

[0004] In view of the above existing problems, the present invention is proposed.

[0005] Therefore, the present invention provides a trusted login method based on signature verification between a mobile smart device and a notary server, which solves the problems of identity authentication, credit, and security in previous Internet signing agreements, the difficulty in ensuring the security of personal keys, and the easy leakage in multiple signing links.

[0006] In order to solve the above technical problems, the present invention provides the following technical solutions: including:

[0007] The user receives the first comparison result, enters the personal password Ct, and uses the personal password Ct and the symmetric key algorithm to symmetrically encrypt the private key Kprt to obtain the ciphertext Sprt;

[0008] Use the private key Kprt to sign the ciphertext Sprt to obtain the signature value Siprt;

[0009] The ciphertext Sprt is encrypted by the public key Kproas of the notary server to obtain the encrypted value Ssptt;

[0010] Send the signed value Siprt and the encrypted value Ssptt to the notary server;

[0011] Also, when logging in and signing, the client requests the ciphertext Sprt from the notary server, enters the personal password Ct, and performs AES decryption on the ciphertext Sprt to obtain the private key Kprt.

[0012] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server of the present invention, wherein: the first comparison result is the result of consistency between the user identity information idt and the user facial recognition feature ft compared by the notary server.

[0013] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, it also includes: before receiving the first comparison result, the user-side key algorithm library generates an asymmetric key pair Kpin and a corresponding public key Kput and private key Kprt.

[0014] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, it also includes: the notary server uses the public key Kput to asymmetrically decrypt the received signed value Siprt, and uses its own public key Kproas to decrypt the encrypted value Ssptt to obtain the ciphertext Sprt.

[0015] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, it also includes: after the private key Kprt is obtained through login decryption, the private key Kprt is used to sign the user identity information idt and the login password Pint to obtain the signed data Sig, the public key Kputds of the signing server TDS is used to encrypt the user identity information idt and the login password Pint to obtain the ciphertext data Sry, and finally the signed data Sig and the ciphertext data Sry are sent to the signing server TDS.

[0016] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, wherein: after receiving the login request, the signing server TDS uses its own private key Kprtds to decrypt the ciphertext data Sry, requests the public key Kput corresponding to the user identity information idt from the notary server, and after obtaining the return result, verifies the signature of the signed data Sig, and terminates the login if the verification fails; after the verification passes, performs login password verification, compares the password of idt in the database with the Pint obtained after decryption to see if they are consistent, terminates the login if they are inconsistent, and returns a successful login if they are consistent.

[0017] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, it also includes: when signing a document, using a private key Kprt to sign all document signing information to obtain signed data Snt and sending it to the notary server, using the notary server public key Kproas to encrypt all document signing information to obtain encrypted data Set and sending it to the notary server.

[0018] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, wherein: the document signing information includes selecting a seal Sealt and a signature Signt at any position in the signed document ft0, and signing to obtain a seal PSealt and a signature PSignt after signing; using a private key Kprt to sign the document ft, seal Sealt, signature Sign, seal PSealt and signature PSignt after signing.

[0019] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, it also includes: the notary server uses the public key Kproas to decrypt the encrypted data Set, and terminates the signing if the decryption fails; the serial number Serialt is obtained after the decryption is successful, and the corresponding public key Kput is searched in the database according to the user identity information idt sent in the request, and the public key Kput is used to verify the signature of the signed data Snt.

[0020] As a preferred solution of the trusted login method based on signature verification between a mobile smart device and a notary server described in the present invention, wherein: if the signature verification fails, the signing task is terminated; if the signature verification succeeds, the corresponding seal Sealt is synthesized onto the corresponding post-signature seal PSealt according to the trusted signature algorithm, and the signature Signt is synthesized onto the corresponding post-signature signature PSignt, thereby obtaining the authentic document ft1 and associating it with the serial number Serialt.

[0021] The beneficial effects of the present invention are as follows: the present invention adds a user password to protect the user key, and uses the user password to encrypt the user key. When the user signs or logs in and needs to use the user key, the password is needed to decrypt the key, so that only the user can use it and the need for confidentiality is met. At the same time, if the user has doubts about the data, he can go to the notarization system to extract the notarized data, compare it, and keep evidence for verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative labor. Among them:

[0023] Figure 1 A system diagram of a trusted login method based on signature verification between a mobile smart device and a notary server according to an embodiment of the present invention;

[0024] Figure 2 A schematic diagram of the interaction process of a trusted login method based on signature verification between a mobile smart device and a notary server according to an embodiment of the present invention; DETAILED DESCRIPTION

[0025] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the drawings of the specification. Obviously, the described embodiments are part of the embodiments of the present invention, but not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary persons in the art without creative work should fall within the scope of protection of the present invention.

[0026] In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention may also be implemented in other ways different from those described herein, and those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0027] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The term "in one embodiment" that appears in different places in this specification does not necessarily refer to the same embodiment, nor does it refer to a separate or selective embodiment that is mutually exclusive with other embodiments.

[0028] The present invention is described in detail with reference to schematic diagrams. When describing the embodiments of the present invention, for the sake of convenience, the cross-sectional diagrams showing the device structure will not be partially enlarged according to the general scale, and the schematic diagrams are only examples, which should not limit the scope of protection of the present invention. In addition, in actual production, the three-dimensional dimensions of length, width and depth should be included.

[0029] At the same time, in the description of the present invention, it should be noted that the directions or positional relationships indicated by the terms "upper, lower, inner and outer" are based on the directions or positional relationships shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as limiting the present invention. In addition, the terms "first, second or third" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0030] In the present invention, unless otherwise clearly specified and limited, the terms "install, connect, connect" should be understood in a broad sense, for example: it can be a fixed connection, a detachable connection or an integral connection; it can also be a mechanical connection, an electrical connection or a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0031] Example 1

[0032] Reference Figure 1-2 , is an embodiment of the present invention, and provides a trusted login method based on signature verification between a mobile smart device and a notary server, comprising:

[0033] During registration, user T uses a mobile smart device to download, install and run the user-side App, enter user identity information idt, set a user login password Pint, and use the mobile smart device in conjunction with a camera device (including but not limited to the camera built into the smart device) to obtain user T's facial recognition feature ft. On the user side, the key algorithm library JST is used to generate an asymmetric key pair Kpin that complies with the asymmetric key algorithm standard (including but not limited to SM2 and RSA), as well as the corresponding public key Kput and private key Kprt. Idt, Pint, ft, and Kput are arranged and combined, Rt = (idt&ft&Pint&ft&Kput), Rt is signed with the mobile phone APP private key Kprapp to obtain the signed value Siappt = Kprapp(Rt), Rt is encrypted with the public key of the notary server OAS to obtain the encrypted value Ssappt = Kpuoas(Rt), and finally Siappt and Ssappt are sent to the notary server OAS.

[0034] S1: The user receives the first comparison result, enters the personal password Ct, and uses the personal password Ct and the symmetric key algorithm to symmetrically encrypt the private key Kprt to obtain the ciphertext Sprt;

[0035] It should be noted that the user's private key is a complex, illogical and very long text string. Therefore, a user password is added to protect the user's secret key. The user password is used to encrypt the user's secret key. When the user signs or logs in and needs to use the user's secret key, the password is needed to decrypt the secret key. In this way, it is achieved that only the user can use it and it is kept confidential.

[0036] Furthermore, the first comparison result is a result of the notary server comparing the user identity information idt and the user facial recognition feature ft and finding them to be consistent.

[0037] It should be noted that if the comparison results are inconsistent, the verification is terminated.

[0038] Furthermore, it also includes that before receiving the first comparison result, the user-side key algorithm library generates an asymmetric key pair Kpin and a corresponding public key Kput and private key Kprt.

[0039] S2: Use the private key Kprt to sign the ciphertext Sprt to obtain the signature value Siprt;

[0040] S3: Encrypt the ciphertext Sprt using the public key Kproas of the notary server to obtain the encrypted value Ssptt;

[0041] S4: Send the signed value Siprt and the encrypted value Ssptt to the notarization server;

[0042] Furthermore, the notary server uses the public key Kput to asymmetrically decrypt the received signed value Siprt, and uses its own public key Kproas to decrypt the encrypted value Ssptt to obtain the ciphertext Sprt.

[0043] It should be noted that after this, the identity information of user T is entered into the database, including idt, ft, Sprt, Kput, Pint generated in the above steps, and the user end is notified that the user registration and authentication is completed.

[0044] S5: When logging in and signing, the client requests the ciphertext Sprt from the notary server, enters the personal password Ct, and performs AES decryption on the ciphertext Sprt to obtain the private key Kprt.

[0045] It should be noted that the private key Kprt=AES|DEC(Sprt|Ct).

[0046] Furthermore, after logging in and decrypting to obtain the private key Kprt, the private key Kprt is used to sign the user identity information idt and login password Pint to obtain the signed data Sig, and the public key Kputds of the signing server TDS is used to encrypt the user identity information idt and login password Pint to obtain the ciphertext data Sry, and finally the signed data Sig and the ciphertext data Sry are sent to the signing server TDS.

[0047] It should be noted that the signature data Sig = Kprt (idt, Pint); the ciphertext data Sry = Kputds (idt, Pint);

[0048] Furthermore, after receiving the login request, the signing server TDS uses its own private key Kprtds to decrypt the ciphertext data Sry, requests the public key Kput corresponding to the user identity information idt from the notary server, and verifies the signature of the signed data Sig after obtaining the return result. If the verification fails, the login is terminated. After the verification passes, the login password is verified, and the password of idt in the database is compared with the Pint obtained after decryption to see if they are consistent. If they are inconsistent, the login is terminated, and if they are consistent, the login success is returned.

[0049] It should be noted that after logging in, the user enters the document signing server TDS, uploads the electronic document ft0 to be signed to TDS, and selects the signatory position St; the document signing server TDS receives the signing request, records the selected signatory position St and the signature position Pt, uses the SHA-256 hash algorithm to calculate the hash value SHA-256(ft0) of the file ft0, generates the signing serial number Serialt, and records it in the database, notifies the signatory to log in for signing by SMS, email, etc.; the signatory receives the signing task and logs in, retrieves the unsigned tasks in the database according to idt, and selects one to sign.

[0050] Then execute step S5. If the decryption fails, the signing is terminated. Furthermore, when signing the document, use the private key Kprt to sign all the document signing information to obtain the signed data Snt and send it to the notary server. Use the notary server public key Kproas to encrypt all the document signing information to obtain the encrypted data Set and send it to the notary server.

[0051] Furthermore, the document signing information includes selecting a seal Sealt and a signature Signt at any position in the signed document ft0, signing to obtain a signed seal PSealt and a signed signature PSignt; using a private key Kprt to sign the document ft, seal Sealt, signature Sign, signed seal PSealt, and signed signature PSignt.

[0052] Furthermore, it also includes that the notary server uses the public key Kproas to decrypt the encrypted data Set, and terminates the signing if the decryption fails; the serial number Serialt is obtained if the decryption is successful, and the corresponding public key Kput is searched in the database according to the user identity information idt sent in the request, and the public key Kput is used to verify the signature of the signed data Snt, that is: Very(Kput, Snt).

[0053] Furthermore, if the signature verification fails, the signing task is terminated; if the signature verification succeeds, the corresponding seal Sealt is synthesized onto the corresponding post-signature seal PSealt according to the trusted signature algorithm, and the signature Signt is synthesized onto the corresponding post-signature signature PSignt, thereby obtaining the authentic document ft1 and associating it with the serial number Serialt.

[0054] It should be noted that by introducing identity verification by authoritative parties, notarization by the notary office, and encryption technology, the identity verification problems, credit problems, security problems, and the soundness of laws and regulations when signing Internet protocols are currently solved. The encrypted data has not been modified. When extracting the data later, if the user has doubts about the data, he can go to the notary system to extract the notarized data and compare it, thereby ensuring data security and retaining evidence.

[0055] At the same time, the meaning of the characters is explained in detail:

[0056] 1. idt: user identity information, mainly ID card information, name information, etc.;

[0057] 2. pint: login password set by the user;

[0058] 3. User T: generally refers to the user who uses the system;

[0059] 4. ft: facial data obtained by users using face recognition technology;

[0060] 5. JST: abbreviation of secret key algorithm;

[0061] 6. Kpin: An asymmetric key pair in an asymmetric key algorithm in computer software technology. An asymmetric key pair consists of a private key and a public key.

[0062] 7. Kput: the public key in the asymmetric key pair;

[0063] 8. Kprt: private key in an asymmetric key pair;

[0064] 9. Rt=(idt&ft&Pint&ft&Kput): Use part of the information in interpretation 1-8 to mix, confuse and reorganize to generate a data without direct meaning. Rt is this meaningless data.

[0065] 10. Kprapp: an asymmetric key pair that identifies the user's mobile phone;

[0066] 11. Siappt = Kprapp (Rt): indicates that the meaningless data generated by 9 is subjected to a digest algorithm using the asymmetric key pair of the mobile phone to obtain a digest data;

[0067] 12. OAS stands for Notary Server;

[0068] 13. Ssappt = Kpuoas (Rt): indicates that the notary server OAS public key encrypts Rt to obtain an encrypted value, where Ssappt represents the encrypted value, and the meaningless data Kpuoas generated by Rt interpretation 9 represents the private key in the asymmetric key pair of the notary server;

[0069] 14. Ct represents the user's personal password, which is different from pint;

[0070] 15. AES means symmetric key algorithm;

[0071] 16. Sprt = AES (Ct || Kprt) means using a symmetric key algorithm to encrypt the user's personal password and the private key in the asymmetric key pair to generate an encrypted data, where AES represents the symmetric key algorithm, Ct represents the user's personal password, Kprt represents the private key in the asymmetric key pair, and Sprt represents the generated encrypted data;

[0072] 17. Siprt=Kprt(Sprt) means using the private key in the asymmetric key pair to sign the encrypted data in Interpretation 16 to generate a signed data, wherein Kprt represents the private key in the asymmetric key pair, and Sprt represents the generated signed data;

[0073] 18. Ssptt=Kpuoas(Sprt) indicates that the encrypted data generated by interpretation 16 is encrypted using the public key of the notary server to obtain encrypted data, Kpuoas indicates the public key of the notary server, Sprt indicates the encrypted data generated by interpretation 16, and Ssptt indicates the encrypted data obtained by the Kpuoas(Sprt) algorithm;

[0074] 19. Kproas represents the private key of the notary server;

[0075] 20. Kprt = AES|DEC (Sprt|Ct) represents the decryption algorithm. The user enters a personal password, decrypts the ciphertext information Sprt, and obtains the private key in the asymmetric key pair. For the meaning of the abbreviation object, please refer to the previous explanation;

[0076] 21. Sig = Kprt (idt, Pint) means using the private key in the asymmetric key pair to sign the user information and user password, and Sig represents the signed data;

[0077] 22. TDS means signing server;

[0078] 23. Kputds means signing the server public key;

[0079] 24. Sry = Kputds (idt, Pint) means using the signing server public key to encrypt the user information and password, and Sry represents the encrypted ciphertext data;

[0080] 25. Kprtds represents the signing server private key;

[0081] 26. Tmt0 indicates the timestamp when the signing server receives the QR code request. For example, the browser sends a QR code login request to the signing server at 15:59:59, and the signing server receives the request at 16:00:00. Then Tmt0 is 16:00:00.

[0082] 27. Qrt represents the unique identifier of the QR code generated by the signing server;

[0083] 28. Sig = Kprt (idt, Qrt) indicates that the user uses the private key in the asymmetric key pair to sign the user information and the unique identifier of the QR code to obtain the signed data, and Sig identifies the signed data;

[0084] 29. Sry=Kputds(idt,Qrt) identifies that the user information and the unique identifier of the QR code are encrypted using the public key of the signing server to obtain the encrypted information Sry;

[0085] 30. Tmt1 is the timestamp of the login request received by the signing server;

[0086] 31. St indicates the signatory position;

[0087] 32. Pt indicates the signature position;

[0088] 33. SHA-256 represents a 256-bit hash algorithm;

[0089] 34. ft0 indicates the document to be signed;

[0090] 35. SHA-256 (ft0) means using a hash algorithm to hash the file to be signed to obtain a unique value;

[0091] 36. Sealt identifies the unique identifier of the seal to which the user belongs;

[0092] 37. Signt represents the unique identifier of the signature to which the user belongs;

[0093] 38. PSealt indicates the location information where the user puts the seal on the document to be signed;

[0094] 39. PSignt indicates the location information where the user stamps his signature on the document to be signed;

[0095] 40. Snt=Kprt(ft0|Sealt|Signt|PSealt|PSignt|Serialt) means using the private key to sign the file to be signed, signature information, seal information, signature position, and seal position to obtain the signed data Snt;

[0096] 41Set=(ft0,Sealt,Signt,PSealt,PSignt,Serialt) means using the private key to encrypt the file to be signed, signature information, seal information, signature position, and seal position to obtain encrypted data Set.

[0097] Example 2

[0098] Reference Figure 1-2 , which is an embodiment of the present invention, provides an application scenario of a trusted login method based on signature verification between a mobile smart device and a notary server, and specifically describes its beneficial effects.

[0099] The trusted data platform is divided into two parts to ensure data trust: user information trust and signed information trust. The core idea is to encrypt and sign the interactive data every time the platform or the user interacts with the platform. Encryption ensures that the data is converted from plain text to cipher text, and others cannot know the plain text even if they obtain the cipher text in time; signing ensures data consistency and ensures that the data sent by the sender is consistent with the data received by the receiver.

[0100] 1. User registration: User T downloads the trusted data interaction platform APP, fills in the mobile phone number, obtains the verification code, and sends the registration information to the trusted data interaction platform. The registration is successful after the verification code is verified. In this process, the invented technology is used to sign and encrypt the user's mobile phone number and verification code to ensure that the data transmission process cannot be stolen or tampered with by others. After successful registration, it is sent to the authoritative notarization platform. The notary creates a user profile after notarization and records the user's behavior.

[0101] 2. User authentication: After user registration, user authentication is required, which requires collecting user ID information, facial feature information, user password, etc. After the ID information and facial feature information are encrypted and signed, they are sent to the authoritative system for matching by the notary staff of the authoritative notary system to prevent the use of other people's information for authentication. After the match is correct, the notary staff will link it to the user's profile and generate a unique trusted digital identity based on the user's password to match the user's profile one by one.

[0102] 3. User login: Users log in using their mobile phone number + verification code. The login information is encrypted and signed, and matched with the user profile of the authoritative notarization platform. After the match is correct, the login is successful, and the ciphertext of the user's digital identity is returned in an encrypted and signed manner. The user can only decrypt it after entering the personal password.

[0103] There are two types of login: APP login and PC login. The above embodiments are for APP login. When logging in with PC, enter the login address of the signing server TDS, and the browser sends a login QR code request to the signing server TDS. After receiving the request, the signing server TDS records the current timestamp Tmt0, uses the unique ID generator to generate a unique QR code Qrt, uses the cache to bind Tmt0 and Qrt, and returns to the browser for display after the QR code is generated. The user uses the APP to scan the code, parses the unique identifier Qrt of the QR code, uses Kprt to sign Qrt and user idt to obtain Sig = Kprt (idt, Qrt), uses the public key Kputds of the signing server TDS, and the login password Qrt to encrypt to obtain Sry = Kputds (idt, Qrt), and finally sends Sig and Sry to TDS. The signing server TDS receives the login request, records the request arrival time Tmt1, uses Kprtds to decrypt Sry, obtains idt, Qrt, requests the public key Kput corresponding to idt from the notary server OAS, and verifies the signature of Sig after receiving the return result. If the verification fails, the login is terminated and failure is returned. After the verification passes, the QR code Qrt is verified and the cache is queried to see if Qrt exists. If not, the login is terminated and failure is returned. If so, check whether the interval between Tmt0 in the cache and the timestamp Tmt1 when the login request is received exceeds 1 minute. If so, the login is terminated and failure is returned. If not, the login verification ends and login success is returned.

[0104] 4. User Signature: Before signing, the user needs to enter a personal password to unlock the digital identity. If the password is entered incorrectly, subsequent signing will not be possible. When signing, you need to select the seal and signature to be used, as well as the corresponding seal and signature position. Before sending the signature information, the user needs to collect facial information and enter a personal password to encrypt and sign the facial recognition information, and cross-check with the authoritative notarization platform. After the verification is successful, the authoritative notarization platform notarizes the signature of the user himself, and encrypts and signs the selected seal and signature, as well as the corresponding seal, signature position, signed documents and other information and sends them to the authoritative notarization platform for signature notarization by the notary staff.

[0105] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention, which should all be included in the scope of the claims of the present invention.

Claims

1. A trusted login method based on signature verification between a mobile smart device and a notary server, characterized in that: include: The user receives the first comparison result, enters the personal password Ct, and uses the personal password Ct and the symmetric key algorithm to symmetrically encrypt the private key Kprt to obtain the ciphertext Sprt; The first comparison result is a result that the notary server compares the user identity information idt and the user facial recognition feature ft and they are consistent; Use the private key Kprt to sign the ciphertext Sprt to obtain the signature value Siprt; The ciphertext Sprt is encrypted by the public key Kproas of the notary server to obtain the encrypted value Ssptt; Send the signed value Siprt and the encrypted value Ssptt to the notary server; Also, when logging in and signing, the client requests the ciphertext Sprt from the notary server, enters the personal password Ct, and performs AES decryption on the ciphertext Sprt to obtain the private key Kprt; After logging in and decrypting to obtain the private key Kprt, use the private key Kprt to sign the user identity information idt and login password Pint to obtain the signed data Sig, use the public key Kputds of the signing server TDS to encrypt the user identity information idt and login password Pint to obtain the ciphertext data Sry, and finally send the signed data Sig and ciphertext data Sry to the signing server TDS; After receiving the login request, the signing server TDS uses its own private key Kprtds to decrypt the ciphertext data Sry, and requests the public key Kput corresponding to the user identity information idt from the notary server. After obtaining the return result, it verifies the signature of the signed data Sig. If the verification fails, the login is terminated. After the verification passes, the login password is verified, and the password of idt in the database is compared with the Pint obtained after decryption to see if they are consistent. If they are inconsistent, the login is terminated, and if they are consistent, the login success is returned.

2. The trusted login method based on signature verification between a mobile smart device and a notary server as claimed in claim 1, characterized in that: It also includes that before receiving the first comparison result, the user-side key algorithm library generates an asymmetric key pair Kpin and a corresponding public key Kput and private key Kprt.

3. The trusted login method based on signature verification between a mobile smart device and a notary server as claimed in claim 2, characterized in that: It also includes that the notary server uses the public key Kput to asymmetrically decrypt the received signed value Siprt, and uses its own public key Kproas to decrypt the encrypted value Ssptt to obtain the ciphertext Sprt.

4. The trusted login method based on signature verification between a mobile smart device and a notary server as claimed in claim 3, characterized in that: It also includes, when signing a document, using the private key Kprt to sign all document signing information to obtain the signed data Snt and sending it to the notary server, and using the notary server public key Kproas to encrypt all document signing information to obtain the encrypted data Set and sending it to the notary server.

5. The trusted login method based on signature verification between a mobile smart device and a notary server as claimed in claim 4, characterized in that: The document signing information includes selecting a seal Sealt and a signature Signt at any position in the signed document ft0, signing to obtain a seal PSealt and a signature PSignt after signing; using a private key Kprt to sign the document ft, seal Sealt, signature Sign, seal PSealt and signature PSignt after signing.

6. The trusted login method based on signature verification between a mobile smart device and a notary server as claimed in claim 5, characterized in that: It also includes that the notary server uses the public key Kproas to decrypt the encrypted data Set, and terminates the signing if the decryption fails; the serial number Serialt is obtained if the decryption is successful, and the corresponding public key Kput is searched in the database according to the user identity information idt sent in the request, and the public key Kput is used to verify the signature of the signed data Snt.

7. The trusted login method based on signature verification between a mobile smart device and a notary server as claimed in claim 6, characterized in that: If the signature verification fails, the signing task is terminated; if the signature verification succeeds, the corresponding seal Sealt is synthesized onto the corresponding post-signature seal PSealt according to the trusted signature algorithm, and the signature Signt is synthesized onto the corresponding post-signature signature PSignt, thereby obtaining the authentic document ft1 and associating it with the serial number Serialt.

Images