Digital signature authorization confirmation method by means of FIDO

Abstract

According to the digital signature authorization confirmation method by means of the FIDO, a user has a data / message signature key pair and an FIDO key pair; when the data / message signature private key needs to be used for digital signature, the program of the user side or the server side generates a hash value / challenge code by using the data / message to be signed and the data / message signature public key data, and submits the hash value / challenge code to the FIDO discriminator; after the FIDO discriminator completes user verification, the FIDO private key of the user is used for digitally signing the hash value / challenge code, and the data / message signature public key data or the identification data of the data / message signature public key data and the FIDO signature form authorization data which confirms that the user is allowed to use the data / message signature private key of the data / message signature public key data; after the authorization data passes the verification, the digital signature program uses the data / message signature private key of the user to digitally sign the to-be-signed data / message; the authorization data is stored in a specialized storage service system, or / and communicated / transmitted and saved with signed data / messages.

Description

Technical Field

[0001] The present invention belongs to the field of cryptography technology, and particularly relates to a method for authorizing and confirming digital signatures with the aid of FIDO. Background Art

[0002] Electronic signatures / digital signatures based on public key cryptography technology have currently been widely applied, and the Electronic Signature Law of the People's Republic of China provides strong legal protection for valid electronic signatures / digital signatures. For a valid electronic signature, the Electronic Signature Law of the People's Republic of China requires that when an electronic signature / digital signature is made, the electronic signature generation data is controlled by the signer. For electronic signatures / digital signatures based on public key cryptography technology, the signature private key of a user is the signature production data, which not only needs to be securely stored, but also, when used for electronic signatures / digital signatures, it should be under the control of the user, and its use reflects the true will of the user, that is, its use should be fully authorized by the user. If the electronic signature generation data is not controlled by the signer when an electronic signature / digital signature is made, the electronic signature / digital signature may not reflect the true will of the signer, and the electronic signature / digital signature will not be effectively protected by the Electronic Signature Law, and serious legal disputes and economic disputes may occur. This problem is particularly prominent for digital signature services that adopt the key escrow method, and some cases that have occurred in reality fully illustrate the severity of this problem.

[0003] FIDO (Fast IDentity Online) is an online identity authentication technology based on public key cryptography. The key (private key) used for user identity authentication (identity proof) is stored in the user's FIDO authenticator. There are two types of FIDO authenticators: external devices (such as FIDO USB Keys, etc.) and embedded devices (embedded devices are also called on-device FIDO authenticators, built-in FIDO authenticators). Among them, the embedded FIDO authenticator is built into user computing devices such as laptops and mobile phones; the embedded FIDO authenticator can be pure software or a combination of software and hardware (if the user computing device has a secure element, SE). The external FIDO authenticator is a dedicated cryptographic device. The user key is stored in the hardware and the cryptographic operations are also performed in the hardware, so it has high security. For the embedded FIDO authenticator, whether it is pure software (without a dedicated secure element to store the private key and perform cryptographic operations) or a combination of software and hardware (with a dedicated secure element to store the private key and perform cryptographic operations), due to the strict security protection of the storage and use of the user key by the operating system and hardware (such as using the private key for cryptographic operations in the CPU's TrustZone), it also has high security. FIDO has evolved from the initial version 1 to the current version 2, FIDO2. FIDO uses the FIDO authenticator to digitally sign a random challenge code to prove that the user owns the FIDO private key, thereby achieving user identity authentication. An important technical feature of the FIDO authenticator is that when using the private key, the FIDO authenticator needs to authenticate the user in a certain way (such as PIN code, fingerprint, face, etc.) to ensure that the use of the private key is authorized by the user. Since FIDO is specifically designed for user online identity authentication, the digital signature of FIDO is different from the digital signature for application-level data / messages (such as electronic transaction contract signature, email signature) in terms of generation method, application method, and the cryptographic data format of the signature data. For example, the data used for the signature in the usual digital signature application follows the Cryptographic Message Syntax (CMS) cryptographic data format, while FIDO does not; also, the current electronic signature / digital signature applications are usually based on digital certificates, while FIDO does not use digital certificates (although the FIDO public key can also be bound to a digital certificate, the application method of the FIDO key pair is different from the application method of the key pair usually based on digital certificates). Therefore, in addition to user online identity authentication, the FIDO digital signature is usually not used for digital signatures in various applications. Summary of the Invention

[0004] The object of the present invention is to propose a solution to the problem of unauthorized use that may exist in the user's data / message signature private key, so as to ensure that the use of the user's data / message signature private key obtains the full authorization and permission of the user. (In the present invention, digital signature authorization and signature private key authorization are equivalent. The use authorization of the signature private key is digital signature authorization, but digital signature authorization is more concise.)

[0005] For the object of the present invention, the technical solution proposed by the present invention is a method for confirming digital signature authorization with the help of FIDO, which is specifically as follows.

[0006] The user has two pairs of key pairs (of public key cryptography algorithms). One pair of key pairs is used for digital signature and signature verification of data / messages, and is called the data / message signature key pair. The private key therein is called the data / message signature private key, and the public key is called the data / message signature public key. The other pair of key pairs is used for FIDO digital signature and is called the FIDO key pair (i.e., passkey, belonging to the user's Credential). The private key therein is called the FIDO private key, and the public key is called the FIDO public key. (Here, the public key cryptography algorithms corresponding to the two pairs of key pairs can be the same or different); The FIDO public key (public information belonging to the user's Credential) is registered (registration, which is the usual practice) before use (at the FIDO server, FIDO Server).

[0007] When it is necessary to digitally sign data / messages using the user's data / message signature private key, the program participating in the digital signature process (i.e., the program related to digital signature or the digital signature program, either on the user side or the server side) utilizes the data / message to be signed and the data / message signature public key data, and calculates and generates a hash value / challenge code for FIDO digital signature through a hashing algorithm (such as the clientDataHash of FIDO2, the Challenge of FIDO1, and the hash value is also called the hash value or digest value), which is called the FIDO hash value / challenge code. Then, the generated FIDO hash value / challenge code is submitted (directly or indirectly) to the FIDO authenticator through the FIDO Authenticator API. After the FIDO authenticator completes user verification, it uses the user's FIDO private key to digitally sign the FIDO hash value / challenge code, generating a FIDO digital signature; the data / message signature public key data is the data / message signature public key itself, or the data containing the data / message signature public key (such as a public key digital certificate), or the data / message signature public key identification data; the data / message signature public key identification data is the data that can uniquely identify the data / message signature public key (such as the public key hash value, digital certificate serial number); the data including the data / message signature public key data and the FIDO digital signature constitutes the authorization data; the authorization data is used to confirm that the user allows the use of their data / message signature private key to digitally sign the data / message to be signed (the FIDO signature and the bound data / message signature public key reflect this confirmation and determination).

[0008] After the authorization data passes the verification (verifying the validity of the FIDO signature; usually, the one who generates the FIDO hash value / challenge code is the one who verifies), the digital signature program (the digital signature program on the user side or the server side, or the collaborative calculation / generation program of the digital signature on the user side and the server side) uses the user's data / message signature private key, or the private key secret, or the private key secret share to digitally sign the data / message to be signed (there will also be corresponding hash value generation and calculation during this digital signature process), and finally generates the signed data / message; the authorization data and the signed data / message are transmitted and saved together, or / and stored in a dedicated storage service system (such as a blockchain platform).

[0009] The private key secret is data that is not the private key but is related or associated with the private key (such as (1 + d in SM2 A ) -1 ), and using the private key secret can achieve / complete the digital signature operation / calculation that can be achieved / completed directly using the private key; the secret share is the share (a piece of secret) obtained after the private key or the private key secret is secretly shared / shared through a secret sharing / scheme.

[0010] The usual FIDO is used for identity authentication. During identity authentication, the authenticating party (relying party) generates a random string (number) to form a FIDO hash value / challenge code. However, in the present invention, FIDO is used for signature authorization rather than identity authentication. Therefore, the FIDO hash value / challenge code in the present invention is generated using the data / message to be signed and the public key data of the data / message signature (this is the biggest difference from the usual FIDO usage method), and usually, a random string does not have to be used (although it is not excluded).

[0011] For the above-mentioned method for confirming digital signature authorization with the aid of FIDO, the data for generating the FIDO hash value / challenge code (i.e., the data used to calculate the FIDO hash value / challenge code) may include other data in addition to the data / message to be signed and the public key data of the data / message signature. The other data includes a random string, time, and context information (referring to the context information of the FIDO authenticator invoker, not the context information of the FIDO authenticator); if the data for generating the FIDO hash value / challenge code further includes data other than the data / message to be signed and the public key data of the data / message signature, the authorization data includes the data for generating the FIDO hash value / challenge code other than the data / message to be signed and the public key data of the data / message signature (the authorization data does not include the data / message to be signed).

[0012] For the above-mentioned method for confirming digital signature authorization with the aid of FIDO, when calculating the FIDO hash value / challenge code, the data / message to be signed is directly used, or the hash value of the data / message to be signed is used (in this case, there are at least two hash value calculations during the calculation process of the FIDO hash value / challenge code, that is, the data / message to be signed is not directly used for the hash calculation of the FIDO hash value / challenge code).

[0013] For the above-mentioned method for confirming digital signature authorization with the aid of FIDO, if the private key of the data / message signature or its secret is stored on the user side, the program on the user side calculates and generates the FIDO hash value / challenge code using the data / message to be signed and the public key data of the data / message signature through a hash algorithm (at this time, FIDO is not used for user identity authentication);

[0014] If the private key for data / message signature, or its secret, or its secret share is stored on the server side, the program on the server side uses the data / message to be signed and the public key data for data / message signature to calculate and generate a FIDO hash value / challenge code through a hashing algorithm (at this time, the FIDO can be used for user authentication or not. At this time, the FIDO server on the server side can be a FIDO-based authentication server or not, but just a signature authorization server relying on the FIDO protocol; whether or not it is used for user authentication, the data signed by FIDO of the present invention has a signature authorization confirmation function) (this situation includes full custody of the user data / message signature private key, or the user side and the server side separately store and use the secret share of the user data / message signature private key in a secret sharing manner, and generate a digital signature through collaborative calculation).

[0015] For the above-mentioned digital signature authorization confirmation method relying on FIDO, the ways of transmitting / transferring and saving the authorization data together with the data / message (signed using the user's private key for data / message signature) include:

[0016] The digital signature program adds or attaches the authorization data to the data / message to be signed (such as adding it as hidden data to Word or PDF documents), forming a new data / message to be signed, and then uses the user's private key for data / message signature, or its secret, or its secret share to perform a digital signature on the new data / message to be signed (this method is valid on the premise that the original data / message to be signed can be separated and restored from the signed data / message, and usually this can be achieved);

[0017] Or, the cryptographic data structure of the signed data / message (such as CSM SignedData) allows the inclusion of signature attributes (such as custom or extended-defined CMS SignerInfo SignedAttributes), and the digital signature program includes the authorization data as a signature attribute in the cryptographic data structure of the signed data / message generated after performing a digital signature on the data / message using the user's private key for data / message signature;

[0018] Alternatively, the data / message signature private key corresponds to a digital certificate, and the cryptographic data structure used for the signed data / message contains a field for storing the digital certificate (such as the certificates field in the SignedData of CMS. The digital certificates in these fields can be the signer's certificate, the certificate used to construct the certificate trust chain, or other certificates). When digitally signing the data / message, the digital signature program (temporarily) generates a pseudo-digital certificate, includes the authorization data in the pseudo-digital certificate (for example, stored in a custom or extended definition extension field of the pseudo-digital certificate), and then includes the pseudo-digital certificate in the field for storing the digital certificate in the cryptographic data structure of the signed data / message; the pseudo-digital certificate has the format and structure of a digital certificate, but it is not a real and valid digital certificate, it is not the digital certificate corresponding to the data / message signature private key, and it is not used to construct the certificate trust chain (that is, it cannot form a certificate trust chain with other certificates. Therefore, the signature verification program will ignore it).

[0019] For the above digital signature authorization confirmation method using FIDO, if the authorization data is included in the pseudo-digital certificate, the signature value of the issuer of the pseudo-digital certificate is the signature value generated using the user's data / message signature private key or is a randomly selected or set value (for example, a fixed value or a random value, or a value calculated or selected in a conventional manner, or even the FIDO signature value in the authorization data, that is, the implementer can select and set it as they like).

[0020] For the above digital signature authorization confirmation method using FIDO, if the user's computing device (computer, mobile terminal) stores the user's data / message signature private key or its secret or its secret share, on the one hand, for the security of the private key or its secret or the private key secret share, and on the other hand, for convenience, to avoid protecting the private key or its secret or its secret share stored on the user's computing device by means of the user entering a PIN code, etc., a security protection method for the user's data / message signature private key or its secret or its secret share stored in the user's computing device is as follows:

[0021] The user's data / message signature private key or its secret or its secret share is encrypted and stored in the user's computing device, while the corresponding decryption key is stored in the server system;

[0022] When it is necessary to digitally sign data / messages using the data / message signature private key or its secret or its secret share in the computing device of the client, the server system calculates and generates a FIDO hash value / challenge code through a hashing algorithm using the data / message to be signed and the data / message signature public key data, and returns it to the client. The (digitally signature-related) program on the client calls the FIDO Authenticator to digitally sign the FIDO hash value / challenge code, generates authorization data and returns it; after the server system completes the validity verification of the authorization data, it returns the decryption key to the computing device of the client; the computing device of the client (the program in it) uses the decryption key to decrypt the data / message signature private key or its secret or its secret share encrypted and stored in the computing device of the client, and then uses the decrypted data / message signature private key or its secret or its secret share to complete the digital signature for the data / message; afterwards, the decryption key of the client and the plaintext of the data / message signature private key or its secret or its secret share are discarded; if the authorization data also has the function of authenticating the user identity, the data for generating the FIDO hash value / challenge code includes a random string generated by the server system.

[0023] For the above digital signature authorization confirmation method using FIDO, in order to ensure that the user is informed and aware of the ongoing operations, before calling / using the FIDO Authenticator to sign the FIDO hash value / challenge code, the digital signature program or the digital signature application program displays information to prompt the user to confirm the operation of using the electronic signature to generate a secret to digitally sign the data / message.

[0024] For the above digital signature authorization confirmation method using FIDO, when there is a dispute over the use authorization or permission of the signature private key used for the signed data / message, the authentication program obtains the original data / message to be signed from the signed data / message, obtains the data / message signature public key data from the authorization data, generates the FIDO hash value / challenge code in the same way as when generating the authorization data, and verifies the validity of the authorization data (verifies the validity of the FIDO digital signature), so as to determine whether the use of the data / message signature private key when generating the digital signature of the data / message has obtained the user's authorization or permission.

[0025] As can be seen from the above description, in the present invention, before using the data / message signature private key to digitally sign data / message, it is necessary to first use the user's FIDO signature private key to digitally sign the FIDO hash value / challenge code generated from the data / message to be signed and the data / message signature public key data. Since the FIDO signature private key is protected by security means such as PIN code, fingerprint, face, etc., the use of the user's FIDO signature private key must involve the user, such as entering the PIN code, fingerprint, face, etc. The FIDO authenticator authenticates the user. After successful authentication, the FIDO authenticator uses the FIDO signature private key to digitally sign the FIDO hash value / challenge code generated from the data / message to be signed and the data / message signature public key data to generate authorization data. Only after the authorization data is verified can the digital signature program use the user's data / message signature private key to digitally sign the data / message to be signed. Therefore, it can be seen that when using the user's data / message signature private key to digitally sign data / message, it must be carried out with the user's knowledge, participation and permission, so as to avoid the user claiming in the future that they were unaware of the signing of the data / message using the signature private key and that the use of the private key was not authorized by them, thus avoiding disputes or facilitating the determination of authenticity in case of disputes: if the digital signature of the data / message corresponds to valid authorization data, the digital signature is carried out with the user's participation and authorization and is true and valid; on the contrary, if the digital signature of the data / message does not have corresponding authorization data or the authorization data is invalid, the digital signature of the data / message is not authorized by the user and is invalid.

[0026] It can be seen that in the present invention, the user's data / message signature key pair (public key and private key) and the user's FIDO key pair are used in a bound manner. The FIDO digital signature binds the data / message to be signed with the data / message signature public key (key pair), and the data / message signature binds the data / message to be signed and the authorization data signed by the FIDO private key (mutually bound).

[0027] It can be seen that the present invention actually performs two digital signatures on the data / message using the user's data / message signature private key and the FIDO signature private key to form a dual signature with two signature values. Among them, the digital signature of the data / message using the data / message signature private key ensures that the digital signature conforms to the usual generation method, application method and data format, and supports digital certificates. Conventional application programs process the signature of the data / message using the data / message signature private key (the main signature of the data / message), and do not process the FIDO digital signature (the auxiliary signature of the data / message). Only in case of disputes will the special authentication program process the FIDO digital signature.

[0028] As can be seen, in the present invention, the user's FIDO signature private key is not or does not have to be used for user authentication, but for authorizing the use of the data / message signature private key, which is different from the usual FIDO.

[0029] Currently, many laptops and mobile terminals (such as mobile phones) support or are equipped with embedded FIDO authenticators, which makes the implementation and application of the present invention convenient. Brief Description of the Drawings

[0030] Figure 1 The client program calls an embedded or external FIDO authenticator;

[0031] Figure 2 The client program calls the embedded FIDO authenticator in the mobile terminal through USB / local network;

[0032] Figure 3 The client program calls the embedded FIDO authenticator in the mobile terminal through the Internet;

[0033] Figure 4 The server program calls the embedded FIDO authenticator in the mobile terminal through the Internet. Detailed Embodiment

[0034] The following describes the detailed embodiment of the present invention. The following content is only an illustration of the possible embodiments of the present invention, does not represent all possible embodiments, and does not limit the protection scope of the present invention.

[0035] Broadly speaking, the FIDO hash value / challenge code submitted to the FIDO authenticator also belongs to the data / message to be signed, but in the present invention, the FIDO hash value / challenge code does not belong to the data / message signed by the data / message signature private key.

[0036] FIDO has developed two versions so far, the first version and the second version (referred to as FIDO1 and FIDO2). There may be new versions in the future. The implementation of the present invention is not limited to a specific FIDO version, nor is it restricted by a specific version, nor is it limited to the existing versions, as long as the present invention can be implemented.

[0037] The present invention has no limitation on the specific implementation of the FIDO authenticator. The FIDO authenticator can be external or embedded (also called on-device), and whether it is embedded or external, it can be purely hardware, purely software, or a combination of software and hardware. It can be a dedicated FIDO device or implemented using a general user device such as a laptop or a mobile terminal.

[0038] In a conventional FIDO, FIDO is used for user authentication. Therefore, in order to verify whether a user has a FIDO private key and prevent replay attacks, the hash value / challenge code submitted for signature by the FIDO authenticator is data randomly generated by the server or data (after hash calculation) generated using data randomly generated by the server. In contrast, the FIDO of the present invention is not used for user authentication. The hash value / challenge code submitted for signature by the FIDO authenticator is calculated through a hash algorithm using the data / message to be signed and the data / message signature public key data. Since it is not used for user authentication, it is not necessary to use randomly generated data when generating the FIDO hash value / challenge code. This is a key difference between the present invention and the conventional FIDO.

[0039] Since the FIDO signature in the present invention is used for authorization, in specific implementations, usually only the FIDO authenticator and its API on the user side (such as the Client to Authenticator Protocol, FIDO U2F) need to be implemented, and it is not necessary to implement the complete FIDO server function (the FIDO Credential registration function needs to be implemented), nor is it necessary to implement FIDO-based user authentication in the server system. For example, it is not necessary to implement WebAuthn (Web Authentication: An API for accessing Public Key Credentials Level 1, Level 2) (of course, it does not exclude or reject implementing the authentication function while authorizing). In specific implementations, if the FIDO authenticator API is the FIDO2 API (Client to Authenticator Protocol), the FIDO hash value / challenge code of the signature submitted to the FIDO authenticator is the hash value (clientDataHash). At this time, if the FIDO authenticator is a FIDO2 authenticator (CTAP2), the hash value is directly used; if the FIDO authenticator is a FIDO1 authenticator (CTAP1, i.e., FIDO U2F), the FIDO2 API converts the hash value into a FIDO1 challenge code (challenge); if the FIDO authenticator API is FIDO1 (FIDO U2F), the FIDO hash value / challenge code of the signature submitted to the FIDO authenticator is the FIDO1 challenge code (challenge). At this time, the challenge code is still calculated through a hash algorithm by the caller using the data / message to be signed or its hash value and the data / message signature public key data, that is, the challenge code is still a hash value.

[0040] In a specific implementation, if the FIDO hash value / challenge code submitted to the FIDO authenticator for signature is generated on the user side (e.g., generated by an application program, a client program, or a digital signature program on the user side participating in the digital signature process), or the digital signature for the FIDO hash value / challenge code is not used for the online user identity authentication on the server side, then only the data / message to be signed or the hash value of the data / message to be signed, as well as the public key data of the data / message signature, are used to generate the FIDO hash value / challenge code, and the generated data does not need to include a random string (of course, including it is also okay); if the FIDO hash value / challenge code submitted to the FIDO authenticator for signature needs to take into account the online user identity authentication, for example, when it is necessary to use the escrow private key, private key secret, or secret share of the private key stored on the server side to digitally sign the data / message, then the FIDO hash value / challenge code is generated on the server side (e.g., generated by an application service program or a signature service program participating in the digital signature process). In addition to the data / message to be signed or the hash value of the data / message to be signed, and the public key data of the data / message signature, the data for generating the FIDO hash value / challenge code also includes a random string generated by the server side to prevent replay attacks.

[0041] If the FIDO hash value / challenge code submitted to the FIDO authenticator for signature is generated on the server side, then to protect user privacy, generally the data / message to be signed is not directly used to generate the FIDO hash value / challenge code, but the hash value of the data / message to be signed is used for generation (calculating the hash value again using the hash value).

[0042] In a specific implementation, the data for generating the FIDO hash value / challenge code can include, in addition to the data / message to be signed or its hash value, the public key data of the data / message signature, and a random string, other information as needed, such as time, context information, etc. (here the context refers to the context information of the FIDO caller, not the context information of the FIDO authenticator). Except for the data / message to be signed or its hash value (which can be obtained from the signed data / message), other data used to generate the FIDO hash value / challenge code is part of the authorization data and is transmitted / delivered and stored together with the authorization data.

[0043] In a specific implementation, which specific data the authorization data includes is entirely determined by the implementer, but some basic requirements need to be met: the FIDO hash value / challenge code used to generate the authorization data can be recovered, and the authenticity and validity of the authorization data can be verified (through FIDO signature), so as to confirm that the use of the user data / message signature private key has obtained the authorization of the user.

[0044] Since the FIDO signature of the present invention is used for authorizing the use of the private key for data / message signature and not for user identity authentication in system login, in specific implementations, the generation of the FIDO hash value / challenge code and the usage mode of the FIDO signature do not fully comply with the FIDO specification, but should meet the security requirements and security needs of the implementer.

[0045] The FIDO key pair (i.e., Credential) corresponds to and is bound to the relying party (through the relying party identifier) and the user (usually through the user's user name on the relying party as the user identifier). If the digital signature application for data / message signature is a specific application, for example, a certain online transaction, then the relying party identifier corresponds to the specific application, and the user name (user identifier) corresponds to the user's account name (user name) in the specific application system; if the digital signature for data / message signature is provided through a public service, for example, a public signature service, then the relying party identifier corresponds to the public signature service platform, and the user name (user identifier) corresponds to the user's account name on the public signature service platform. When the user's Credential (public key) is registered, the user's Credential (public key) will be bound to the relying party identifier and the user identifier in the FIDO server and the FIDO authenticator. Therefore, in specific implementations, the application program or the digital signature program can select and use the corresponding FIDO key pair (Credential) according to the relying party identifier and the user identifier for FIDO signature and signature verification.

[0046] In specific implementations, the way to call the FIDO authenticator can be called by a program on the user side (such as Figure 1 , 2 , 3), or can be called by a program on the server side (as shown in Figure 4 ), where Figure 1 corresponds to the situation where a program on the user side calls the built-in (in the device) FIDO authenticator or an external FIDO authenticator in the user computing device. At this time, the external FIDO authenticator can be called through USB, NFC, etc.; Figure 2 corresponds to the situation where a program on the user side calls the built-in FIDO authenticator in a mobile terminal (such as a mobile phone) through USB, NFC, etc., Figure 3 corresponds to the situation where a program on the user side calls the built-in FIDO authenticator in a mobile terminal (such as a mobile phone) through the Internet. At this time, the program on the user side and the proxy program of the built-in FIDO authenticator in the mobile terminal (such as a mobile phone) establish a network communication connection through a connection intermediary system to exchange data; Figure 4It corresponds to the server program calling the embedded FIDO authenticator in a mobile terminal (such as a mobile phone) via the Internet. At this time, the server program and the proxy program of the embedded FIDO authenticator in the mobile terminal (such as a mobile phone) establish a network communication connection through the network and exchange data (the proxy program in the mobile phone actively initiates a connection to the server). It should be noted that Figure 1 the client computing device in Figure 1 itself can also be a user mobile terminal (with an embedded FIDO authenticator or an external FIDO authenticator). Since many current mobile phone terminals have provided and implemented the function of an embedded FIDO authenticator, therefore, using the FIDO authenticator of a mobile phone terminal as the FIDO authenticator is a convenient, low-cost, and secure choice (providing fingerprint security protection for the FIDO private key).

[0047] In specific implementation, whether to calculate the FIDO hash value / challenge code using a hashing algorithm at the client or the server, whether to call the FIDO authenticator by the client program or the server program to submit the FIDO hash value / challenge code, and whether it is the digital signature program of the client or the server that calculates and generates the digital signature for the data / message are related to the storage and usage methods of the data / message signature private key. The following are some possible implementation scenarios:

[0048] (1) The data / message signature private key or its secret is stored at the client, and the digital signature program of the client calculates and generates the FIDO hash value / challenge code and submits it to the FIDO authenticator ( Figure 1 、 2 、3), and then the digital signature program of the client uses the data / message signature private key or its secret to generate the digital signature for the data / message;

[0049] (2) The data / message signature private key or its secret is stored at the server, and the digital signature program of the server calculates and generates the FIDO hash value / challenge code. Then, the program of the client participating in the digital signature submits the FIDO hash value / challenge code to the FIDO authenticator ( Figure 1 、 2 、3), or the program of the server participating in the digital signature submits the FIDO hash value / challenge code to the FIDO authenticator ( Figure 4 ), and finally, the digital signature program of the server uses the data / message signature private key or its secret to generate the digital signature for the data / message;

[0050] (3) The client and the server respectively store the secret shares of the data / message signature private key. The digital signature for the data / message adopts a password collaborative calculation method. The digital signature program of the server calculates and generates the FIDO hash value / challenge code, and then the program of the client participating in the digital signature submits the FIDO hash value / challenge code to the FIDO authenticator (Figure 1 , 2 , or the program participating in digital signature on the server side submits the FIDO hash value / challenge code to the FIDO authenticator ( Figure 4 ), and finally, the digital signature programs on the client side and the server side jointly generate a digital signature for the data / message using the secret shares of the data / message signature private key.

[0051] In a specific implementation, the digital signature for the data / message adopts the usual and conventional digital signature for application data, so that the usual and conventional digital signature application programs do not need to be modified; for the digital signature of application data (including the digital signature for general applications and the digital signature for specific applications), the currently most commonly used cryptographic data structure of the signed data is SigndData of CMS (Cryptographic Message Syntax). However, for the implementation of the present invention, the signed data / message generated by using the data / message signature private key for digital signature of the data / message is not limited to a specific digital signature cryptographic data structure, as long as it is a data signature for the data / message. For example, CMS Advanced Electronic Signatures (CAdES), or other cryptographic data structures of specific signed data for specific applications. Only for the cryptographic data structures of specific signed data for specific applications, the transmission and storage methods of the authorization data may be different.

[0052] In a specific implementation, the authorization data can be transmitted / transferred and saved together with the signed data / message for easy acquisition and use when needed, or stored in a dedicated storage service system (such as a blockchain platform) and acquired and used when needed, or the authorization data is transmitted / transferred and saved together with the signed data / message and stored in a dedicated storage service system at the same time.

[0053] If the authorization data is transmitted / transferred and saved together with the signed data / message (generated by digitally signing using the user's data / message signature private key), the specific implementation methods include:

[0054] The mathematical signature program or the digital signature related program adds or attaches the authorization data to the data / message to be signed (such as adding it as hidden data to a Word or PDF document) to form a new data / message to be signed, and then uses the user's data / message signature private key to digitally sign the new data / message to be signed (this method is valid on the premise that the original data / message to be signed can be separated and restored from the signed data / message, and this is usually achievable);

[0055] Alternatively, the cryptographic data structure of the signed data / message (such as CMS SignedData) may allow the inclusion of signed attributes (such as the signedAttributes of SignerInfo in a custom or extended definition of CMS). The mathematical signature program or digital signature-related program includes the authorization data as a signed attribute in the cryptographic data structure of the signed data / message generated after digitally signing the data / message with the user's data / message signature private key.

[0056] Alternatively, the data / message signature private key corresponds to a digital certificate, and the cryptographic data structure used for the signed data / message has a field for storing the digital certificate (such as the certificates field in CMS's SignedData). The digital certificates in these fields can be the signer's certificate, a certificate used to construct a certificate trust chain, or other certificates. When digitally signing the data / message, the digital signature program (temporarily) generates a pseudo-digital certificate, includes the authorization data in the pseudo-digital certificate (for example, stored in a custom or extended definition of the extension field of the pseudo-digital certificate), and then includes the pseudo-digital certificate in the field for storing the digital certificate in the cryptographic data structure of the signed data / message. The pseudo-digital certificate has the format and structure of a digital certificate, but it is not a real and valid digital certificate, not the digital certificate corresponding to the data / message signature private key, and not used to construct a certificate trust chain (that is, it cannot form a certificate trust chain with other certificates, so the signature verification program will ignore it).

[0057] In a specific implementation, if the implementation method of including the authorization data in the pseudo-digital certificate is adopted, the signature value of the issuer of the pseudo-digital certificate is the signature value (valid signature value) generated using the user's data / message signature private key or a randomly selected or set value (for example, a fixed value or a random value, or a value calculated or selected in a conventional manner, or the FIDO signature value in the authorization data, or even an invalid signature value). In a specific implementation, it is preferable to use the user's data / message signature private key to generate the signature value of the signer of the pseudo-digital certificate, so that the use of the data / message signature key and the FIDO key can be bound to each other.

[0058] In a specific implementation, if the computing device (computer, mobile terminal) at the user end stores the user's data / message signature private key or its secret or its secret share, for the security of the private key or its secret or the private key secret share, and for convenience, to avoid protecting the private key or its secret or its secret share stored at the user end by means such as the user entering a PIN code, the following method can be adopted to securely protect the user's data / message signature private key or its secret or its secret share stored in the computing device at the user end and its use:

[0059] The user's data / message signature private key, or its secret, or its secret share is encrypted and stored in the computing device at the user end, while the corresponding decryption key is stored in the server system;

[0060] When it is necessary to use the data / message signature private key, or its secret, or its secret share in the computing device at the user end to digitally sign data / messages, the server system generates a FIDO hash value / challenge code and returns it to the user end (the computing device). The program in the computing device at the user end calls the FIDO Authenticator to digitally sign the FIDO hash value / challenge code, generates authorization data and returns it. After the server system completes the validity verification of the authorization data, it returns the decryption key to the computing device at the user end. The program in the computing device at the user end uses the decryption key to decrypt the encrypted data / message signature private key, or its secret, or its secret share stored in the computing device at the user end, and then uses the decrypted signature private key, or its secret, or its secret share to complete the digital signature for the data / message. After that, at the user end, the decryption key and the plaintext of the data / message signature private key, or its secret, or its secret share are discarded. If the authorization data also has the function of authenticating the user's identity (for example, the server system has not authenticated the user's identity before), the data for generating the FIDO hash value / challenge code includes a random string generated by the server system.

[0061] If the digital signature for data / messages in a specific implementation involves the collaborative generation of a digital signature based on secret sharing, how to implement the collaborative generation of a digital signature based on secret sharing does not belong to the content of this invention, and there are already many mature solutions.

[0062] In a specific implementation, to ensure that the user is informed and aware of the ongoing operations, before the program calls / uses the FIDO Authenticator to sign the FIDO hash value / challenge code, the digital signature program or digital signature application program displays information to the user, prompting the user to confirm the operation of using the electronic signature to generate private data (private key) to digitally sign data / messages. For example, it prompts the user to allow and / or confirm authorizing the use of their electronic signature (electronic seal) private data to generate an electronic signature (electronic seal).

[0063] In a specific application, to address possible disputes, an authentication process can be implemented. When there is a dispute regarding the authorization or permission to use the signature private key used for signed data / messages, the authentication process obtains the original data / messages to be signed from the signed data / messages, obtains the data / message signature public key data from the authorization data, generates the FIDO hash value / challenge code in the same manner as when generating the authorization data, and verifies the validity of the authorization data (verifies the validity of the FIDO digital signature), thereby determining whether the use of the data / message signature private key when generating the digital signature of the data / messages has been authorized or permitted by the user.

[0064] Other specific technical implementations not described belong to the prior art or public knowledge and are well-known and self-evident to those skilled in the relevant fields.

Claims

1. A method for confirming authorization using a digital signature using FIDO, characterized by: The user has two key pairs, one of which is used for digital signature and signature verification of data / messages, called data / message signature key pair, and the private key is called data / message signature private key, and the public key is called data / message signature public key. The other key pair is used for FIDO digital signature, called FIDO key pair, and the private key is called FIDO private key, and the public key is called FIDO public key. FIDO public key is registered before use; When it is necessary to use the user's data / message signature private key to digitally sign data / message, the program involved in the digital signature process uses the data / message to be signed and the data / message signature public key data to calculate and generate a hash value / challenge code for FIDO digital signature through a hash algorithm, which is called a FIDO hash value / challenge code. The generated FIDO hash value / challenge code is then submitted to the FIDO authenticator. After completing user verification, the FIDO authenticator uses the user's FIDO private key to digitally sign the FIDO hash value / challenge code to generate a FIDO digital signature; the data / message signature public key data is the data / message signature public key itself or data containing the data / message signature public key or data / message signature public key identification data; the data / message signature public key identification data is data that can uniquely identify the data / message signature public key; the data including the data / message signature public key data and the FIDO digital signature constitutes authorization data; the authorization data is used to confirm that the user allows the use of his / her data / message signature private key to digitally sign the data / message to be signed; After the authorization data is verified, the digital signature program uses the user's data / message signature private key or private key secret or private key secret share to digitally sign the signed data / message, and finally generates the signed data / message; the authorization data is transmitted / transmitted and stored together with the signed data / message, or / and stored in a dedicated storage service system; The private key secret is not the data / message signature private key but it is data related or associated with the data / message signature private key. Using the private key secret can implement / complete the digital signature operation / calculation that is implemented / completed directly using the data / message signature private key; the secret share is the share of the data / message signature private key or its secret after secret sharing / sharing.

2. The method for confirming authorization by means of a digital signature using FIDO according to claim 1, wherein: In addition to the data / message to be signed and the data / message signature public key data, the data used to generate the FIDO hash value / challenge code is allowed to include other data, including a random string, time, and context information; if the data used to generate the FIDO hash value / challenge code also includes data other than the data / message to be signed and the data / message signature public key data, then the authorization data includes the data used to generate the FIDO hash value / challenge code other than the data / message to be signed and the data / message signature public key data.

3. The method for confirming authorization by means of a digital signature using FIDO according to claim 1, characterized in that: When calculating the FIDO hash value / challenge code, the data / message to be signed is used directly, or the hash value of the data / message to be signed is used.

4. The method for confirming authorization by means of a digital signature using FIDO according to claim 1, wherein: If the data / message signature private key or its secret is stored on the user side, the user side program uses the data / message to be signed and the data / message signature public key data to calculate and generate the FIDO hash value / challenge code through a hash algorithm; If the data / message signature private key or its secret or its secret share is stored on the server, the server program uses the data / message to be signed and the data / message signature public key data to generate a FIDO hash value / challenge code through a hash algorithm.

5. The method for confirming authorization by means of a digital signature using FIDO according to claim 1, wherein: The authorization data may be delivered / transmitted and stored together with the signed data / message in the following ways: The digital signature program adds or appends the authorization data to the data / message to be signed to form new data / message to be signed, and then uses the user's data / message signing private key or its secret or its secret share to digitally sign the new data / message to be signed; Alternatively, the cryptographic data structure of the signed data / message allows the signature attribute to be included, and the digital signature program includes the authorization data as a signature attribute in the cryptographic data structure of the signed data / message generated after the data / message is digitally signed using the user's data / message signature private key; Alternatively, the data / message signature private key corresponds to a digital certificate, and the cryptographic data structure used for the signed data / message includes a field for storing the digital certificate. When digitally signing the data / message, the digital signature program generates a pseudo-digital certificate, includes the authorization data in the pseudo-digital certificate, and then includes the pseudo-digital certificate in the field for storing the digital certificate in the cryptographic data structure of the signed data / message; the pseudo-digital certificate has the format and structure of a digital certificate, but it is not a real and valid digital certificate, it is not the digital certificate corresponding to the data / message signature private key, and is not used to construct a certificate trust chain.

6. The method for confirming authorization by using a digital signature of FIDO according to claim 5 is characterized in that: If the authorization data is included in the pseudo digital certificate, the signature value of the issuer of the pseudo digital certificate is a signature value generated using the user's data / message signature private key or is an arbitrarily selected or set value.

7. The method for confirming authorization by using a digital signature of FIDO according to any one of claims 1 to 6, characterized in that: If the computing device at the user end stores the user's data / message signature private key or its secret or its secret share, a security protection method for the user's data / message signature private key or its secret or its secret share stored in the computing device at the user end is as follows: The user's data / message signature private key or its secret or its secret share is encrypted and stored in the user's computing device, while the corresponding decryption key is stored in the server system; When it is necessary to use the data / message signature private key or its secret or its secret share in the computing device of the user end to digitally sign the data / message, the server system uses the data / message to be signed and the data / message signature public key data to calculate the FIDO hash value / challenge code through the hash algorithm, and returns it to the user end. The program of the user end calls the FIDO authenticator to digitally sign the FIDO hash value / challenge code, generates authorization data and returns it; After completing the validity verification of the authorization data, the server system returns the decryption key to the computing device on the user side; the computing device on the user side uses the decryption key to decrypt the encrypted and stored data / message signature private key or its secret or its secret share in the computing device on the user side, and then uses the decrypted data / message signature private key or its secret or its secret share to complete the digital signature for the data / message; thereafter, the user's decryption key and the plaintext of the data / message signature private key or its secret or its secret share are discarded; if the authorization data also has the function of authenticating the user's identity, the data for generating the FIDO hash value / challenge code includes a random string generated by the server system.

8. The method for digital signature authorization confirmation by FIDO according to any one of claims 1 to 6, characterized in that: Before invoking / using the FIDO authenticator to sign the FIDO hash value / challenge code, the digital signature program or digital signature application displays a message prompting the user to confirm the operation of using the electronic signature generating secret to digitally sign the data / message.

9. The method for confirming authorization by using a digital signature of FIDO according to claim 8, characterized in that: When a dispute arises over the authorization or permission for the use of the signing private key used to sign the data / message, the authentication program obtains the original data / message to be signed from the signed data / message, obtains the data / message signing public key data from the authorization data, generates a FIDO hash value / challenge code in the same way as when generating the authorization data, verifies the validity of the authorization data, and thereby determines whether the use of the data / message signing private key when generating the digital signature of the data / message is authorized or permitted by the user.

Images