A digital signature authorization confirmation method by means of FIDO

Abstract

The digital signature authorization confirmation method with FIDO: the user has a data / message signature key pair and a FIDO key pair; when a digital signature is needed using the data / message signature private key, the program on the user side or the server side uses the data / message to be signed and the data / message signature public key data to generate a hash value / challenge code and submit it to the FIDO authenticator; after completing the user verification, the FIDO authenticator uses the user's FIDO private key to digitally sign the hash value / challenge code, the data / message signature public key data or its identification data, and the FIDO signature to form authorization data confirming that the user allows the use of the data / message signature private key; after the authorization data is verified, the digital signature program uses the user's data / message signature private key to digitally sign the data / message to be signed; the authorization data is stored in a special storage service system, or / and is transmitted / transferred and saved together with the signed data / message.

Description

Technical Field

[0001] This invention belongs to the field of cryptography, specifically a digital signature authorization and verification method using FIDO. Background Technology

[0002] Electronic signatures / digital signatures based on public-key cryptography are now widely used, and the "Electronic Signature Law of the People's Republic of China" provides strong legal protection for valid electronic signatures / digital signatures. For valid electronic signatures, the "Electronic Signature Law of the People's Republic of China" requires that the data generating the electronic signature be controlled by the signer. For electronic signatures / digital signatures based on public-key cryptography, the user's private key is the signature creation data. This key must not only be securely stored, but also be under the user's control when used for electronic signatures / digital signatures. Its use must reflect the user's true intentions, meaning its use must be fully authorized by the user. If the data generating the electronic signature is not controlled by the signer, the electronic signature / digital signature may not reflect the signer's true intentions, and the electronic signature / digital signature will not receive effective protection under the Electronic Signature Law. This could lead to serious legal and economic disputes, a problem particularly prominent for digital signature services using key escrow. Several real-world cases have fully illustrated the severity of this issue.

[0003] FIDO (Fast IDentity Online) is an online authentication technology based on public-key cryptography. The key (private key) used for user authentication (identity verification) is stored in the user's FIDO Authenticator. FIDO Authenticators come in two types: external devices (such as FIDO USB keys) and embedded devices (also called on-device FIDO Authenticators or built-in FIDO Authenticators). Embedded FIDO Authenticators are built into the user's computing device, such as a laptop or mobile phone. Embedded FIDO Authenticators can be purely software-based or a combination of hardware and software (if the user's computing device has a Secure Element, SE). External FIDO Authenticators are dedicated cryptographic devices where the user key is stored in hardware and cryptographic operations are performed in hardware, thus offering high security. Embedded FIDO detectors, whether purely software-based (without a dedicated secure unit for storing the private key and performing cryptographic operations) or a combination of software and hardware (with a dedicated secure unit for storing the private key and performing cryptographic operations), offer high security because the storage and use of user keys are strictly protected by the operating system and hardware (e.g., using the private key for cryptographic operations within the CPU's TrustZone). FIDO has evolved from its initial version 1 to the current version 2, FIDO2. FIDO uses a FIDO detector to digitally sign a random challenge code to prove that the user possesses the FIDO private key, thereby authenticating the user's identity. A key technical feature of FIDO detectors is that when using the private key, the FIDO detector must authenticate the user through certain methods (such as PIN codes, fingerprints, facial recognition, etc.) to ensure that the use of the private key is authorized by the user. Because FIDO is specifically designed for online user authentication, FIDO digital signatures differ from typical application-level data / message digital signatures (such as electronic transaction contract signatures and email signatures) in terms of generation, application, and cryptographic data format. For example, typical digital signature applications use Cryptographic Message Syntax (CMS) cryptographic data format, while FIDO does not. Furthermore, current electronic signature / digital signature applications are usually based on digital certificates, while FIDO does not use digital certificates (although FIDO public keys can be bound to digital certificates, the application of FIDO key pairs differs from that of typical certificate-based key pairs). Therefore, apart from online user authentication, FIDO digital signatures are generally not used for digital signatures in various applications. Summary of the Invention

[0004] The purpose of this invention is to address the potential problem of unauthorized use of users' data / message signing private keys and to propose a solution to ensure that the use of users' data / message signing private keys is fully authorized and permitted by the users (in this invention, digital signature authorization and signing private key authorization are equivalent; authorization to use the signing private key is equivalent to digital signature authorization, but digital signature authorization is simpler).

[0005] To achieve the objectives of this invention, the proposed technical solution is a digital signature authorization and confirmation method using FIDO, as detailed below.

[0006] Users have two key pairs (using public-key cryptography algorithms). One key pair is used for digital signing and signature verification of data / messages, called the data / message signing key pair. The private key in this pair is called the data / message signing private key, and the public key is called the data / message signing public key. The other key pair is used for FIDO digital signatures, called the FIDO key pair (i.e., passkey, belonging to the user's credential). The private key in this pair 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 key pairs can be the same or different.) The FIDO public key (public information belonging to the user's credential) is registered (this is the usual practice) before use (on the FIDO server).

[0007] When a user's data / message signing private key is needed to digitally sign data / messages, the program (either on the user's end or the server's end) participating in the digital signing process (i.e., the program related to digital signing or the digital signing program) uses the data / message to be signed and the data / message signing public key data to calculate and generate a hash value / challenge code for FIDO digital signatures using a hash algorithm (e.g., FIDO2's clientDataHash, FIDO1's Challenge; the hash value is also called a hash value or hash code). This is called the FIDO hash value / challenge code. The generated FIDO hash value / challenge code is then (directly or indirectly) passed through the FIDO Authenticator. The API is 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, generating a FIDO digital signature. The data / message signing public key data is the data / message signing public key itself or data containing the data / message signing public key (such as a public key digital certificate) or data / message signing public key identification data. The data / message signing public key identification data is data that can uniquely identify the data / message signing public key (such as a public key hash value or a digital certificate serial number). The data including the data / message signing public key data and the FIDO digital signature data constitute the authorization data. The authorization data is used to confirm that the user allows the use of their data / message signing private key to digitally sign the data / message to be signed (the FIDO signature and the bound data / message signing public key reflect this confirmation and confirmation).

[0008] After the authorized data is verified (verifying the validity of the FIDO signature; typically, whoever generates the FIDO hash value / challenge code verifies it), the digital signature program (the user-side or server-side digital signature program, or the user-side and server-side digital signature co-computation / generation program) uses the user's data / message signing private key or private key secret or private key secret share to digitally sign the data / message to be signed (this digital signature process also involves the generation and calculation of a corresponding hash value), and finally generates the signed data / message; the authorized data and the signed data / message are transmitted / transmitted and stored 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 a private key but is related to or associated with the private key (such as (1+d) in SM2). A ) -1 The private key secret can be used to realize / complete digital signature operations / computations that are directly realized / completed using the private key; the secret share is the share of the private key or the private key secret after being secretly shared (through a secret sharing / sharing scheme) (a secret).

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

[0011] For the FIDO-based digital signature authorization and verification method described above, the FIDO hash value / challenge code generation data (i.e., the data used to calculate the FIDO hash value / challenge code) may include other data besides the data / message to be signed and the data / message signing public key data. This other data includes a random string, time, and context information (referring to the context information of the FIDO discriminator caller, not the context information of the FIDO discriminator). If the data generating the FIDO hash value / challenge code also includes data other than the data / message to be signed and the data / message signing public key data, then the authorization data includes the data used to generate the FIDO hash value / challenge code, excluding the data / message to be signed and the data / message signing public key data (the authorization data does not include the data / message to be signed).

[0012] For the digital signature authorization confirmation method using FIDO described above, 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 (at least two hash value calculations are performed during the FIDO hash value / challenge code calculation process, i.e., the data / message to be signed is not directly used for FIDO hash value / challenge code hash calculation).

[0013] For the digital signature authorization and confirmation method using FIDO described above, if the data / message signing private key or its secret is stored on the user end, the user end program uses the data / message to be signed and the data / message signing public key data to calculate and generate the FIDO hash value / challenge code through a hash algorithm (at this time, FIDO is not used for user identity authentication).

[0014] If the data / message signing 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 signing public key data to calculate and generate a FIDO hash value / challenge code through a hash algorithm (in this case, FIDO may or may not be used for user authentication; in this case, the server's FIDO server may or may not be a FIDO-based authentication server, but simply a signature authorization server using the FIDO protocol; regardless of whether it is used for user authentication, the FIDO-signed data of this invention has a signature authorization confirmation function) (this situation includes the full custody of the user's data / message signing private key, or the user and server adopting a secret sharing method to separately store and use the secret share of the user's data / message signing private key, and generate a digital signature through collaborative calculation).

[0015] For the FIDO-based digital signature authorization and verification method described above, the methods for transmitting and storing authorized data along with data / messages signed (using the user's data / message signing private key) include:

[0016] The digital signature program adds or appends authorized 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. Then, it 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 (this method works only if the original, initial data / message to be signed can be separated and restored from the signed data / message, which is usually possible).

[0017] Alternatively, the cryptographic data structure of the signed data / message (such as CSM SignedData) may include signature attributes (such as custom or extended CMS SignerInfo SignedAttributes). 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 signing private key.

[0018] Alternatively, the data / message signing private key corresponds to a digital certificate, and the cryptographic data structure used for signing the data / message includes a field for storing the digital certificate (such as the "certificates" field in CMS's SignedData; these fields can contain the signer's certificate, a certificate used to construct a certificate trust chain, or other certificates). When digitally signing data / messages, the digital signing program (temporarily) generates a pseudo-digital certificate, includes the authorization data in the pseudo-digital certificate (e.g., stored in a custom or extended field of the pseudo-digital certificate), and then includes the pseudo-digital certificate in the field storing the digital certificate within 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 signing private key and is not used to construct a certificate trust chain (i.e., it cannot form a certificate trust chain with other certificates; therefore, the signature verification program ignores it).

[0019] For the above-mentioned digital signature authorization and confirmation method using FIDO, if the authorization data is included in the fake digital certificate, then the signature value of the issuer of the fake digital certificate can be the signature value generated using the user's data / message signing private key or an arbitrarily selected or set value (e.g., a fixed value or a random value, or a value calculated or selected in an agreed manner, or even the FIDO signature value in the authorization data, i.e., the implementer can select or set it however they want).

[0020] For the above-mentioned FIDO-based digital signature authorization and verification method, 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, and for two reasons—first, to ensure the security of the private key or its secret or its secret share, and second, to facilitate the protection of the user's stored private key or its secret or its secret share by avoiding the use of methods such as user input of PIN codes—then 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 signing 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 a user's computing device needs to digitally sign a data / message using its private key, secret, or secret share, the server system uses the data / message to be signed and the public key data for signing to calculate a FIDO hash value / challenge code using a hash algorithm and returns it to the user. The user's (digital signature related) program calls the FIDO Authenticator to digitally sign the FIDO hash value / challenge code, generating authorization data and returning it. After verifying the validity of the authorization data, the server system returns the decryption key to the user's computing device. The program on the user's computing device uses the decryption key to decrypt the encrypted private key, secret, or secret share of the data / message signing in the user's computing device, and then uses the decrypted private key, secret, or secret share to complete the digital signature of the data / message. Afterward, the plaintext of the user's decryption key and the private key, secret, or secret share of the data / message signing is discarded. If the authorization data also has the function of authenticating the user's identity, the data used to generate the FIDO hash value / challenge code includes a random string generated by the server system.

[0023] For the above-mentioned digital signature authorization and confirmation method using FIDO, in order to ensure that the user is aware of the operation in progress, before calling / using the FIDO authenticator to sign the FIDO hash value / challenge code, the digital signature program or digital signature application displays information prompting the user to confirm the operation of digitally signing data / messages using the secret generated by the electronic signature.

[0024] For the above-mentioned FIDO-based digital signature authorization and verification method, when a dispute arises regarding 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 the FIDO hash value / challenge code in the same way as when generating the authorization data, verifies the validity of the authorization data (verifies the validity of the FIDO digital signature), and thus determines whether the use of the data / message signing private key was authorized or permitted by the user when generating the digital signature of the data / message.

[0025] As described above, in this invention, before digitally signing data / messages using the data / message signing private key, the user's FIDO signing private key must first be used to digitally sign the FIDO hash value / challenge code generated from the data / message to be signed and the data / message signing public key data. The FIDO signing private key is protected by security measures such as PIN codes, fingerprints, and facial recognition. Therefore, using the user's FIDO signing private key requires user participation, such as entering a PIN code, fingerprint, or facial recognition. The FIDO authenticater verifies the user's identity. Only after successful verification does the FIDO authenticater use the FIDO signing private key to digitally sign the FIDO hash value / challenge code generated from the data / message to be signed and the data / message signing public key data, generating authorized data. The digital signing process only proceeds after the authorized data is verified. Only when a user's data / message signing private key is used can the data / message to be signed be digitally signed. Therefore, it can be seen that when using a user's data / message signing private key to digitally sign data / messages, it must be done with the user's knowledge, participation, and permission. This can prevent users from claiming in the future that they were unaware of the use of the signing private key to sign data / messages, or that the use of the private key was not authorized by them, thus avoiding disputes, or making it easier to determine the authenticity in the event of a dispute: if the digital signature of the data / message corresponds to valid authorization data, then the digital signature was done with the user's participation and authorization, and is genuine and valid; conversely, if the digital signature of the data / message does not have corresponding authorization data, or the authorization data is invalid, then the digital signature of the data / message was not authorized by the user and is invalid.

[0026] As can be seen, in this invention, the user's data / message signing 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 signing public key (key pair), while the data / message signing binds the data / message to be signed with the authorized data signed by the FIDO private key (mutual binding).

[0027] As can be seen, this invention actually uses the user's data / message signing private key and FIDO signing private key to digitally sign the data / message twice, forming a dual signature with two signature values. The data / message signing private key ensures that the digital signature conforms to the usual generation method, application method, and data format, and supports digital certificates. Conventional applications process the signature of the data / message using the data / message signing private key (the main signature of the data / message). Conventional applications do not process the FIDO digital signature (the auxiliary signature of the data / message). Only in the event of a dispute is the FIDO digital signature processed by a dedicated authentication program.

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

[0029] Many portable computers and mobile terminals (such as mobile phones) currently support or have embedded FIDO discriminators, which makes the implementation and application of this invention convenient. Attached Figure Description

[0030] Figure 1 The client program calls the embedded or external FIDO discriminator;

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

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

[0033] Figure 4 The server program calls the embedded FIDO discriminator in the mobile terminal via the Internet. Detailed Implementation

[0034] The specific embodiments of the present invention will be described below. The following content is only a description of possible embodiments of the present invention and does not represent all possible embodiments, nor is it intended to limit the scope of protection of the present invention.

[0035] In a broad sense, the FIDO hash value / challenge code submitted to the FIDO discriminator also belongs to the data / message to be signed, but in this invention, the FIDO hash value / challenge code does not belong to the data / message signed with the data / message signing private key.

[0036] FIDO has been developed into two versions to date, version 1 and version 2 (referred to as FIDO1 and FIDO2). There may be new versions in the future. The implementation of this invention is not limited to a specific FIDO version, nor is it restricted by a specific version. It is also limited by the existing version, as long as the invention can be implemented.

[0037] This invention does not limit the specific implementation of the FIDO discriminator. The FIDO discriminator can be external or embedded (also known as on-device). Whether embedded or external, it can be purely hardware, purely software, or a combination of hardware and software. It can be a dedicated FIDO device or implemented using general user devices such as laptops or mobile terminals.

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

[0039] Since the FIDO signature in this invention is used for authorization, in specific implementations, it is usually only necessary to implement the FIDO authenticator and its API (such as Client to Authenticator Protocol, FIDO U2F) on the user side. It is not necessary to implement the complete FIDO server-side functions (FIDO Credential registration function needs to be implemented), nor is it necessary to implement FIDO-based user authentication on 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 exclude the implementation of identity authentication functions at the same time as authorization). In practical implementation, if the FIDO authenticator API is the FIDO2 API (Client to Authenticator Protocol), the FIDO hash value / challenge code submitted to the FIDO authenticator for signing is the hash value (clientDataHash). In this case, if the FIDO authenticator is the FIDO2 authenticator (CTAP2), the hash value is used directly. If the FIDO authenticator is the FIDO1 authenticator (CTAP1, i.e., FIDO U2F), the FIDO2 API converts the hash value into a FIDO1 challenge code. If the FIDO authenticator API is the FIDO1 (FIDO U2F), the FIDO hash value / challenge code submitted to the FIDO authenticator for signing is the FIDO1 challenge code. In this case, the challenge code is still calculated by the caller using the data / message to be signed or its hash value and the data / message signing public key data through a hash algorithm; that is, the challenge code is still the hash value.

[0040] In practical implementation, if the FIDO hash value / challenge code submitted to the FIDO discriminator for signing is generated on the user's end (e.g., by the user's application, client program, or digital signature program participating in the digital signature process), or if the digital signature for the FIDO hash value / challenge code is not used for online user authentication on the server side, then generating the FIDO hash value / challenge code only requires the data / message to be signed or the hash value of the data / message to be signed, and the public key data for signing the data / message; the generated data does not need to include a random string (although including it is optional). If the data submitted to the FIDO discriminator... The FIDO hash value / challenge code for signing needs to take into account the user's online identity authentication. For example, when it is necessary to use a escrowed private key, private key secret, or secret share of the private key stored on the server to digitally sign data / messages, the FIDO hash value / challenge code is generated on the server (e.g., by the application service program or 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 for signing the data / message, the data / message also includes a random string generated by the server to prevent replay attacks.

[0041] If the FIDO hash value / challenge code submitted to the FIDO discriminator for signing is generated on the server side, in order to protect user privacy, the FIDO hash value / challenge code is usually not generated directly from the data / message to be signed. Instead, it is generated from the hash value of the data / message to be signed (and the hash value is then calculated).

[0042] In practice, the data used to generate 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 for signing the data / message, and a random string, other information such as time and context information (here, context refers to the context information of the FIDO caller, not the context information of the FIDO discriminator) can be included as needed. Apart from the data / message to be signed or its hash value (which can be obtained from the signed data / message), the other data used to generate the FIDO hash value / challenge code is transmitted / transmitted and stored together with the authorization data as part of the authorization data.

[0043] In practice, the specific data included in the authorization data is entirely determined by the implementer, but some basic requirements must be met: the FIDO hash value / challenge code that generated the authorization data can be recovered, and the authenticity and validity of the authorization data can be verified (through FIDO signature), thereby confirming that the user's authorization has been obtained by using the user data / message signing private key.

[0044] Since the FIDO signature of this invention is used for authorization of private key use in data / message signing, and not for user authentication in system login, the generation of FIDO hash value / challenge code and the use of FIDO signature in specific implementation do not completely comply with the FIDO specification, but must meet the security requirements and needs of the implementer.

[0045] FIDO key pairs (i.e., credentials) are associated and bound to a relying party (identified by a relying party identifier) ​​and a user (usually identified by the user's username on the relying party). If the digital signature application for signing data / messages is specific to a particular application, such as an online transaction, the relying party identifier corresponds to the specific application, and the username corresponds to the user's account name on that application system. If the digital signature for signing data / messages is provided through a public service, such as a public signature service, the relying party identifier corresponds to the public signature service platform, and the username corresponds to the user's account name on that platform. During user credential registration, the credential is bound to the relying party identifier and user identifier on the FIDO server and FIDO discriminator. Therefore, in practice, applications or digital signature programs can select and use the appropriate FIDO key pair for FIDO signing and signature verification based on the relying party identifier and user identifier.

[0046] In practical implementation, the FIDO discriminator can be invoked by a user-side program (e.g., ...). Figure 1 , 2 3) It can also be called by the server-side program (such as...) Figure 4 As shown), where, Figure 1 This corresponds to the situation where the user-end program calls the FIDO discriminator embedded in the user's computing device or an external FIDO discriminator. In this case, the external FIDO discriminator can be called via USB, NFC, etc. Figure 2 This corresponds to the user-side program calling the embedded FIDO discriminator in the mobile terminal (such as a mobile phone) via USB, NFC, etc. Figure 3 This corresponds to the user-side program calling the embedded FIDO discriminator in the mobile terminal (such as a mobile phone) via the Internet. At this time, the user-side program and the agent program of the embedded FIDO discriminator in the mobile terminal (such as a mobile phone) establish a network communication connection through the connection intermediary system and exchange data. Figure 4This corresponds to the server-side program calling the embedded FIDO detector in the mobile terminal (such as a mobile phone) via the internet. At this time, the server-side program and the agent program of the embedded FIDO detector in the mobile terminal (such as a mobile phone) establish a network communication connection and exchange data (the agent program in the mobile phone actively initiates the connection to the server). It should be noted that... Figure 1 The user-end computing device itself can also be a user mobile terminal (with an embedded FIDO detector or an external FIDO detector). Since many mobile terminals now provide and implement embedded FIDO detector functionality, using the mobile terminal's FIDO detector as a FIDO detector is a convenient, low-cost, and secure option (providing fingerprint security protection for the FIDO private key).

[0047] In practice, whether the FIDO hash value / challenge code is calculated using a hash algorithm on the user end or the server end, whether the FIDO hash value / challenge code is submitted by the FIDO discriminator called by the user-side program or the server-side program, and whether the digital signature program on the user end or the server end calculates and generates the digital signature for the data / message, all depend on how the data / message signature private key is stored and used. The following are some possible implementation scenarios:

[0048] (1) The data / message signing private key or its secret is stored on the user's end. The user's digital signature program calculates and generates the FIDO hash value / challenge code, and submits it to the FIDO discriminator. Figure 1 , 2 3), and then the digital signature program on the user's end uses the data / message signing private key or its secret to generate a digital signature for the data / message;

[0049] (2) The data / message signing private key or its secret is stored on the server. The server's digital signature program calculates and generates the FIDO hash value / challenge code, and then the user-side program participating in the digital signature submits the FIDO hash value / challenge code to the FIDO discriminator. Figure 1 , 2 3), or, the server-side program participating in the digital signature submits the FIDO hash value / challenge code to the FIDO authenticator. Figure 4 Finally, the server-side digital signature program generates a digital signature for the data / message using the data / message signing private key or its secret;

[0050] (3) The user end and the server end each store a secret share of the private key for data / message signing. A cryptographic collaborative computation method is used for digital signatures of data / messages. The server-side digital signature program calculates and generates the FIDO hash value / challenge code, and then the user-side program participating in the digital signature submits the FIDO hash value / challenge code to the FIDO discriminator. Figure 1 , 2 3), or, the server-side program participating in the digital signature submits the FIDO hash value / challenge code to the FIDO authenticator. Figure 4 Finally, the digital signature program on the user's end and the digital signature program on the server end work together to generate a digital signature for the data / message using a secret share of the data / message signing private key.

[0051] In practical implementation, the digital signature for data / messages uses the usual, conventional digital signature for application data, so the application does not need to be modified. For digital signatures of application data (including digital signatures for general applications and digital signatures for special applications), the most commonly used cryptographic data structure for signed data is the CMS (Cryptographic Message Syntax) signed data (SigndData). However, in the implementation of this invention, the signed data / messages generated by using the data / message signing private key for digital signatures are not limited to a specific cryptographic data structure for digital signatures. As long as it is a data signature for data / messages, such as CMS Advanced Electronic Signatures (CAdES) or other cryptographic data structures for specific applications, it is acceptable. The only difference is that the method of transmitting and storing authorized data may differ depending on the cryptographic data structure for specific applications.

[0052] In practice, authorized data can be transmitted and stored together with signed data / messages for easy access and use when needed, or stored in a dedicated storage service system (such as a blockchain platform) for access and use when needed, or authorized data can be transmitted and stored together with signed data / messages and stored in a dedicated storage service system.

[0053] If authorized data is transmitted and stored together with signed data / messages (generated using the user's data / message signing private key digital signature), then the specific implementation methods include:

[0054] Mathematical signature programs or digital signature-related programs add or append authorized 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. Then, the user's data / message signing private key is used to digitally sign the new data / message to be signed (this method works if the original, initial data / message to be signed can be separated and restored from the signed data / message, which is usually possible).

[0055] Alternatively, the cryptographic data structure of the signed data / message (such as CMS SignedData) may include signature attributes (such as signedAttributes of SignerInfo of CMS, which are custom or extended definitions), and mathematical signature programs or digital signature-related programs may include authorization data as a signature attribute in the cryptographic data structure of the signed data / message after the data / message is digitally signed using the user's data / message signing private key;

[0056] Alternatively, the private key for signing data / messages corresponds to a digital certificate, and the cryptographic data structure used for signing the data / messages has fields for storing the digital certificate (such as the "certificates" field in CMS's SignedData; these fields can contain the signer's certificate, a certificate used to construct a certificate trust chain, or other certificates). When digitally signing data / messages, the digital signing program (temporarily) generates a pseudo-digital certificate, includes the authorization data in the pseudo-digital certificate (e.g., stored in a custom or extended field of the pseudo-digital certificate), and then includes the pseudo-digital certificate in the field storing the digital certificate within the cryptographic data structure of the signed data / messages. The pseudo-digital certificate has the format and structure of a digital certificate, but it is not a real and valid digital certificate, is not the digital certificate corresponding to the private key for signing data / messages, and is not used to construct a certificate trust chain (i.e., it cannot form a certificate trust chain with other certificates; therefore, the signature verification program ignores it).

[0057] In practical implementation, if the authorization data is included in the pseudo-digital certificate, the signature value of the issuer of the pseudo-digital certificate can be a valid signature value generated using the user's data / message signing private key, or an arbitrarily selected or set value (e.g., a fixed or random value, a value calculated or selected using an agreed-upon method, the FIDO signature value in the authorization data, or even an invalid signature value). In practical implementation, it is preferable to use the user's data / message signing private key to generate the signature value of the signer of the pseudo-digital certificate, thus binding the use of the data / message signing key and the FIDO key together.

[0058] In practical implementation, if the user's computing device (computer, mobile terminal) stores the user's data / message signing private key or its secret or its secret share, for two reasons—first, to ensure the security of the private key or its secret or its secret share, and second, for convenience, avoiding the use of methods such as user input of PIN codes to protect the user's stored private key or its secret or its secret share—then the following methods can be used to securely protect the user's data / message signing private key or its secret or its secret share stored in the user's computing device and its use:

[0059] The user's data / message signing 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;

[0060] When a data / message signature private key or its secret or its secret share needs to be digitally signed using the user's computing device, the server system generates a FIDO hash value / challenge code and returns it to the user's computing device. The program on the user's computing device calls the FIDO Authenticator to digitally sign the FIDO hash value / challenge code, generating authorization data and returning it. After verifying the validity of the authorization data, the server system returns the decryption key to the user's computing device. The program on the user's computing device uses the decryption key to decrypt the encrypted data / message signature private key or its secret or its secret share stored on the user's computing device, and then uses the decrypted signature private key or its secret or its secret share to complete the digital signature of the data / message. Afterwards, on the user's end, the plaintext of the decryption key and the data / message signature private key or its secret or its secret share is discarded. If the authorization data also has the function of authenticating the user's identity (for example, if the server system did not authenticate the user's identity before), the data that generates the FIDO hash value / challenge code includes a random string generated by the server system.

[0061] If the digital signature for data / message in the specific implementation involves the collaborative generation of digital signatures based on secret sharing, how to implement the collaborative generation of digital signatures based on secret sharing is not within the scope of this invention, and there are already many mature solutions.

[0062] In practice, to ensure that users are aware of the ongoing operation, before the program calls / uses the FIDO discriminator to sign the FIDO hash value / challenge code, the digital signature program or digital signature application displays information to the user, prompting the user to confirm the operation of digitally signing data / messages using the private data (private key) generated by the electronic signature. For example, the user is prompted to allow and / or confirm authorization to use their electronic signature (electronic seal) private data to generate an electronic signature (electronic seal).

[0063] In practical applications, to address potential disputes, an authentication procedure can be implemented. When a dispute arises regarding the authorization or permission for the use of the signing private key for the signed data / message, the authentication procedure 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 manner as when generating the authorization data, verifies the validity of the authorization data (verifies the validity of the FIDO digital signature), and thus determines whether the use of the data message signing private key was authorized or permitted by the user when generating the digital signature of the data / message.

[0064] Other unspecified technical implementations are existing technology or publicly available knowledge, and are well-known and self-evident to those skilled in the art.

Claims

1. A digital signature authorization and verification method using FIDO, characterized by: The user has two key pairs. One key pair is used for digital signing and signature verification of messages, called the message signing key pair, with the private key called the message signing private key and the public key called the message signing public key. The other key pair is used for FIDO digital signing, called the FIDO key pair, with the private key called the FIDO private key and the public key called the FIDO public key. The message signing private key is not the private key that implements the FIDO signing function in the FIDO discriminator. The FIDO public key is registered before use. When it is necessary to digitally sign a message using the user's message signing private key: Step 1: The program participating in the digital signature process uses the message to be signed and the message signing public key data to calculate and generate a hash value / challenge code for FIDO digital signature using a hash algorithm. This is called the 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, generating the FIDO digital signature. The message signing public key data can be the message signing public key itself, data containing the message signing public key, or message signing public key identification data. The message signing public key identification data is data that uniquely identifies the message signing public key. The data including the message signing 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 message signing private key to digitally sign the message to be signed. Step 2: After the authorized data is verified, the digital signature program uses the user's message signing private key or private key secret or private key secret share to digitally sign the same message to be signed that generated the aforementioned FIDO hash value / challenge code, and finally generates the signed message; The authorization data generated in the first step is transmitted and saved together with the signature message generated in the second step, or / and stored in a dedicated storage service system; The message is application-level data, i.e., application data; the private key secret is not the message signing private key, but it is data related to or associated with the message signing private key. The private key secret can be used to realize / complete the digital signature operation that is realized / completed directly using the message signing private key; the secret share is the share of the message signing private key or its secret after secret sharing / sharing.

2. The digital signature authorization and verification method using FIDO according to claim 1, characterized in that: In addition to the message to be signed and the message signing public key data, the data used to generate the FIDO hash value / challenge code may also include other data, such as random strings, time, and context information. If the data used to generate the FIDO hash value / challenge code also includes data other than the message to be signed and the message signing public key data, then the authorized data includes the data used to generate the FIDO hash value / challenge code, excluding the message to be signed and the message signing public key data.

3. The digital signature authorization and verification method using FIDO according to claim 1, characterized in that: When calculating the FIDO hash value / challenge code, either use the message to be signed directly, or use the hash value of the message to be signed.

4. The digital signature authorization and verification method using FIDO according to claim 1, characterized in that: If the message signing private key or its secret is stored on the user's end, the user's program will use the message to be signed and the message signing public key data to calculate and generate the FIDO hash value / challenge code through a hash algorithm. If the message signing private key or its secret or its secret share is stored on the server, the server program uses the message to be signed and the message signing public key data to calculate and generate a FIDO hash value / challenge code using a hash algorithm.

5. The digital signature authorization and verification method using FIDO according to claim 1, characterized in that: The methods for transmitting / sending and storing authorized data along with signed messages include: The digital signature program adds or appends authorized data to the message to be signed, forming a new message to be signed, and then uses the user's message signing private key or its secret or its secret share to digitally sign the new message to be signed; Alternatively, the cryptographic data structure of the signed message may include signature attributes. The digital signature program includes the authorization data as a signature attribute in the cryptographic data structure of the signed message generated after the message is digitally signed using the user's message signing private key. Alternatively, the message signing private key corresponds to a digital certificate, and the cryptographic data structure used for signing the message includes a field for storing the digital certificate. When digitally signing the message, the digital signing 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 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 message signing private key and is not used to construct a certificate trust chain.

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

7. The digital signature authorization and verification method using FIDO according to any one of claims 1-6, characterized in that: If the user's computing device stores the user's message signing private key, its secret, or its secret share, then a security protection method for the user's message signing private key, its secret, or its secret share stored in the user's computing device is as follows: The user's message signing 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 digitally sign a message using the message signing private key or its secret or its secret share in the user's computing device, the server system uses the message to be signed and the message signing public key data to calculate and generate a FIDO hash value / challenge code through a hash algorithm, and returns it to the user. The user program calls the FIDO discriminator to digitally sign the FIDO hash value / challenge code, generates authorization data and returns it. After verifying the validity of the authorized data, the server system returns the decryption key to the user's computing device. The user's computing device uses the decryption key to decrypt the encrypted message signing private key or its secret or its secret share stored in the user's computing device, and then uses the decrypted message signing private key or its secret or its secret share to complete the digital signature of the message. Afterwards, the plaintext of the user's decryption key and the message signing private key or its secret or its secret share is discarded. If the authorized data also has the function of authenticating user identity, the data for generating the FIDO hash value / challenge code includes a random string generated by the server system.

8. The digital signature authorization verification method using FIDO according to any one of claims 1-6, characterized in that: Before invoking / using the FIDO discriminator to sign the FIDO hash value / challenge code, the digital signature program or application displays a message prompting the user to confirm the operation of digitally signing the message using the secret generated by the digital signature generator.

9. The digital signature authorization and verification method using FIDO according to claim 8, characterized in that: When a dispute arises regarding the authorization or permission for the use of the signing private key used to sign a message, the authentication procedure retrieves the original message to be signed from the message being signed, obtains the 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 thus determines whether the use of the message signing private key was authorized or permitted by the user when generating the digital signature of the message.

Images