Digital signature system using a trusted server

Abstract

A method and system for a scalable, trusted server-based digital signature system is disclosed. The system includes multiple front-end servers that each communicate with multiple back-end servers. A remote application server sends a signature request to one of the front-end servers. The signature request includes at least two public keys, each with a different server identifier embedded therein. The back-end server extracts one of the server identifiers and attempts a signature generation process with the corresponding back-end server. If that back-end server does not respond, the front-end server extracts the server identifier from another public key and initiates a signature generation process with that back-end server. In some systems, the remote application server has a predetermined relationship with multiple front-end servers so that if one front-end server is down, the application server can communicate with a backup front-end server.

Description

[Technical field]

[0001] The present disclosure relates generally to secure electronic communications and electronic commerce, and more specifically to a digital signature system using a trusted server. [Background technology]

[0002] Increasingly, documents are being digitally signed. Digital signatures use a system that (a) authenticates that the person signing the document is who they say they are when signing, and (b) legally validates that the signed document is authentic. In this way, people who rely on the document can be sure that the document is authentic and that the person who signed the document cannot deny having signed it. These digital signature systems often use asymmetric cryptography, relying on a private key and a public key associated with an individual. To forge a signature, a malicious party must incur the computational cost of obtaining the private key or (possibly) subverting the signature scheme (i.e., signing a message without the private key). The resistance to attacks of digital signature systems can be classified as mathematical resistance (e.g., the ability to forge a digital signature by mathematically subverting the signature) or physical resistance (e.g., tampering with a physical device to forge a signature). The growth of digital signatures comes with a concomitant growth in the number of public keys that need to be tracked and the number of signature requests that need to be processed. As mathematical and physical robustness improves, the need for a reliable and scalable digital signature infrastructure increases.

[0003] overview The appended claims define this application. This disclosure summarizes aspects of the embodiments and should not be used to limit the scope of the claims. As will be apparent to one of ordinary skill in the art upon review of the following figures and detailed description, other implementations are contemplated in accordance with the technology described herein, and these implementations are intended to be within the scope of this application.

[0004] An exemplary system for generating a digital signature includes a first backend server, a second backend server, and a frontend server. The frontend server receives a signature request from a remote application server. The signature request includes a first overall public key with a cryptographically embedded first server identifier and a second overall public key with a cryptographically embedded second server identifier. The frontend server extracts the cryptographically embedded first server identifier from the first overall public key. The frontend server then forwards the signature request to a first backend server corresponding to the first server identifier. In response to determining that the first backend server is unavailable, the frontend server extracts the cryptographically embedded second server identifier from the second overall public key and forwards the signature request to a second backend server corresponding to the second server identifier. The responding backend server forwards the signature request to a plurality of remote security devices associated with the overall public keys. The back-end server then receives a first signature from each of the multiple remote security devices and generates a combined signature based on the first signature. The back-end server then generates a second signature based on the combined signature and a final decision key. The final decision key is cryptographically generated based on a server identifier of the back-end server. The back-end server forwards the second signature to the front-end server. The front-end server then forwards the second signature to the remote application server.

[0005] For a better understanding of the present invention, reference may be made to the embodiments illustrated in the following drawings. The components in the drawings are not necessarily to scale, and relevant elements may be omitted, or in some cases, some may be exaggerated to highlight and clearly show the novel features described herein. Furthermore, the components of the system may be configured in various ways, as known in the art. Moreover, in the drawings, like reference numerals indicate corresponding parts throughout the several views. [Brief description of the drawings]

[0006] [Figure 1] 1 illustrates a system for implementing a digital signature system using a trusted server in accordance with the techniques of this disclosure.

[0007] [Diagram 2] 1 shows a system that utilizes conventional asymmetric cryptography with a single private key.

[0008] [Diagram 3] A system is presented that utilizes split-key asymmetric cryptography using multiple private key shares that rely on a single private key.

[0009] [Figure 4] A system is shown that utilizes multi-key asymmetric cryptography using multiple unrelated private keys.

[0010] [Diagram 5] A system is presented that uses specific server information to generate a global public key and a finalized signature (called a finalized signature).

[0011] [Figure 6A] FIG. 2 is a block diagram of a certificate authority that cooperates with a signing authority to generate a certificate to be associated with a user. [Figure 6B] FIG. 2 is a block diagram of a certificate authority that cooperates with a signing authority to generate a certificate to be associated with a user.

[0012] [Figure 7] FIG. 1 is a block diagram of a system for generating multiple certificates associated with a user.

[0013] [Figure 8] FIG. 1 is a block diagram of a system that uses redundant certificates associated with users to generate documents signed with digital signatures.

[0014] [Figure 9] 9 shows a security device embodying the device-side portion of the asymmetric cryptography of FIGS.

[0015] [Figure 10] FIG. 10 is a block diagram of the electronic components of the security device of FIG.

[0016] [Figure 11] 11 is a flow diagram of a method for using redundant certificates associated with a user to generate a document signed with a digital signature that may be implemented by the application server of FIGS. 1 and 8.

[0017] [Figure 12] 9 is a flow diagram of a method for using redundant certificates associated with a user to generate a document signed with a digital signature that may be implemented by the front-end server(s) of FIG. 8.

[0018] [Figure 13] 9 is a flow diagram of a method for generating a signature for a digital document that may be implemented by the systems of FIGS. 1 and 8. [Figure 14] 9 is a flow diagram of a method for generating a signature for a digital document that may be implemented by the systems of FIGS. 1 and 8.

[0019] [Figure 15] 1 is a flow diagram of a method for reissuing a certificate.

[0020] DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS While the invention may be embodied in various forms, certain illustrative, non-limiting embodiments are shown in the drawings and described below, with the understanding that the present disclosure should be considered as exemplary of the invention and is not intended to limit the invention to the specific embodiments illustrated.

[0021] With the rise of digital signatures, computer infrastructures need to reliably handle the task of generating a large number of signatures daily. Signatures are often required by third-party application servers. For example, a signature may be required to acknowledge that a customer has read a website's privacy policy and personal data policy, or a signature may be required when a customer signs a government document such as a tax document or a commercial contract (e.g., a mortgage application). However, the third-party application servers are agnostic to the digital signature scheme and are not deployed to handle the actual signature process. The signature generation process becomes more complicated when one or more physical security devices are used in the signature generation process. It is not practical for the third-party application servers to know how to contact the physical security devices. Furthermore, as the role of digital signatures becomes ubiquitous, infrastructure mechanisms are needed to add security devices and handle signature generation in a trusted manner. Furthermore, a trusted system should be configured such that (a) private keys are never transferred from the device on which they are created, and (b) when one server in the system is offline, digital signatures can still be created uninterrupted.

[0022] As described below, a Signature Authority (SA) includes back-end servers and front-end servers. The back-end servers perform signing functions and communicate with a particular security device and / or security token. Each back-end server has a unique identifier ("BESID"). The front-end servers communicate with a third-party application server to process signing requests. Customers register with the Signature Authority. During the registration process, customers associate themselves with one or more physical security devices and / or physical security tokens. The security device(s) and / or security token(s) are assigned to two or more back-end servers such that these particular back-end servers have the necessary information to communicate with the particular security device and / or security token. Furthermore, each of these back-end servers uses the unique information of the security device and / or security token to generate a certificate with a Certificate Authority (CA) that identifies (authenticates) the particular back-end server.

[0023] (a) When a multi-key method is used , Se(b) the security device generates a private key and a public key and provides the public key to the designated backend server, and / or (b) if a security token is used, the assigned backend server generates a private key and a public key associated with the customer. Using the two or more independent public keys, each backend server creates a composite public key. Each backend server then creates an overall public key based on the composite public key and the BESID. Each backend server separately sends the overall public key, its BESID, and a unique client identifier ("CID") to a certificate authority (CA). The certificate authority generates a separate certificate associated with the CID. In some instances, the certificate authority (CA) designates one of the certificates as a "primary certificate" and the other as a "secondary certificate." The certificate authority (CA) is a public repository of these certificates that provides certificates in response to receiving a request with a CID attached.

[0024] When a split key scheme is used, each backend server generates two or more key shares and a public key. Each backend server shares one of the key shares with the security device and retains one of the key shares. The security device stores each of the key shares in association with the BESID of the backend server that generated it. Each backend server then creates an overall public key based on the public key and their BESID. Each backend server separately sends the overall public key, its BESID and a unique client identifier ("CID") to a certificate authority (CA).

[0025] A security device can be any portable electronic device capable of (a) securely storing an independently generated private key, (b) receiving input from a signer, (c) reliably authenticating the identity of the signer based on the input, (d) receiving a message for generating a signature, (e) generating a signature with the independently generated private key and the message, and (f) transmitting the signature to a computing device (e.g., a server, etc.) that requests the signature. In some examples, a security device can be a smartphone, a smart watch, a tablet computer, jewelry with embedded electronics (e.g., a bracelet, a ring, a brooch, etc.), a smart card (e.g., a credit card, an ID card, etc.), and / or an electronic seal, etc. In some examples, each security device is configured to physically receive input (e.g., a biometric identifier such as a fingerprint, a password, etc.) from a signer separately from any other security device. In some examples, each security device communicates with a computing device (e.g., via a wireless connection to the Internet, etc.). Alternatively, in some examples, one of the security devices acts as a primary device that communicates with the computing device (e.g., via a wireless connection to the Internet), while the other security device communicates with the primary device via a local area network (e.g., a wireless local area network, a Bluetooth® low energy connection, etc.) to communicate with the computing device.

[0026] The security token communicates directly or indirectly (e.g., via a mobile device) with the backend server to authenticate the customer's identity when the backend server is generating the digital signature. The security token can be any mobile device that communicates with the backend server and can securely provide a credential to the user when the user provides authentication to the mobile device. For example, the device can have a biometric sensor and / or input (e.g., iris scanner, fingerprint scanner, etc.). As another example, the device may have a GPS and rely on geofencing or its proximity to another device (e.g., a security device) to authenticate the user. In some examples, the security token can be another security device that is not involved in the current signature generation. In some examples, the security token is jewelry (e.g., a bracelet, a ring, a brooch, etc.) or a smart card (e.g., a credit card, an ID card, etc.) with embedded electronics.

[0027] When a digital signature is to be created, the customer provides credentials and / or the customer's CID to the application server (e.g., credentials managed by the application server to verify the customer). The application server uses the customer's identity to retrieve multiple certificates from a certificate authority (CA). The application server has an established relationship (e.g., established when the application server registers with the signature authority) with at least two front-end servers of the signature authority. In some examples, one of the front-end servers can be designated as a "primary server" and the other of the front-end servers can be designated as a "secondary server." If more than two front-end servers are associated with the application server, the signature authority (SA) can specify an order or priority of the back-end servers. The application server sends a signing request to the primary (or first) front-end server. The signing request includes the multiple certificates retrieved from the certificate authority (CA) and a message. The message can be the original message (e.g., the digital document to be signed) or a message digest calculated from the original message by applying a cryptographic hash function (e.g., SHA-256, etc.) to the original message. If the application server does not receive an acknowledgment of its request from the primary front-end server within a threshold period of time (e.g., 500 milliseconds, 1 second, etc.), the application server resends the signature request to the secondary front-end server. If there are more than two specified front-end servers, this process is repeated until the application server receives an acknowledgment of its request. If an acknowledgment is not received, the application server generates an error message to the user.

[0028] The front-end server extracts (stripping) the BESID from the primary (or first) certificate and forwards the signing request to the back-end server associated with that BESID. If the front-end server does not receive an acknowledgment of its request from the primary back-end server within a threshold period of time (e.g., 500 milliseconds, 1 second, etc.), the front-end server extracts the BESID from the secondary certificate and forwards the signing request to the back-end server. If there are more than two certificates to attach the signing request to, this process is repeated until the front-end server receives an acknowledgment of its request. If no acknowledgment is received, the front-end server generates an error message and sends it to the application server that sent the signing request.

[0029] The backend server, in conjunction with a security device and / or security token, generates a signature on the message. The backend server then uses the final key to generate a final signature. The backend server sends the final signature to the frontend server that sent the signature request. The frontend server then forwards the final signature to the application server that requested the signature. The application server then appends the final signature to the digital document. If necessary, the digital signature can then be verified using the certificate.

[0030] 1 illustrates a system 100 for implementing a digital signature system using a trusted server in accordance with the teachings of the present disclosure. The system 100 generates secure and reliable digital signatures. In the illustrated example, the system 100 includes a signing authority 102, a certificate authority 104, and one or more application servers 106.

[0031] The signing authority 102 acts as an intermediary between an application server 106 and one or more security devices 108 managed by a user 110 of the application server 106. When a security device 108 is registered with the signing authority 102, the signing authority 102 collects and / or generates information for the certificate authority 104 to generate multiple certificates associated with the security device(s) 108. The signing authority 102 works in conjunction with the security device(s) 108 to generate digital signatures in response to a signing request that includes a certificate sent by one of the application servers 106.

[0032] The certificate authority 104 generates and stores certificates. The certificate authority 104 generates certificates based on input from the signing authority 102, including a public key and a client identifier (CID). The certificate authority 104 stores the generated certificates in a database (sometimes called a "certificate repository" or "public key repository"). In response to receiving a certificate and its associated CID, the certificate authority 104 provides the stored certificates to the application server 106 (e.g., the certificates are freely available to entities that request them using the CID).

[0033] A customer 110 may interact with the application server 106 such that the application server 106 generates a signature request. For example, the customer 110 may be signing a document or accepting a privacy policy and data usage policy on a website. When the application server 106 requests a digital signature, the application server 106 obtains a certificate from the certificate authority 104 that is associated with a CID that is directly or indirectly provided by the customer 110. 102manages the signing process so that the application server 106 does not need a direct relationship with the security device(s) 108 of the customer 110. The application server 106 is communicatively coupled to the signing authority 102 through a pre-established relationship. For example, if the owner of the application server 106 wants to accept digital signatures from the signing authority 102, the signing authority 102 can provide settings regarding how the signing request should be sent.

[0034] FIG. 2 illustrates a system that utilizes conventional asymmetric cryptography with a single private key, and generally for verifying signatures. A common asymmetric cryptosystem (sometimes called a "public key cryptosystem") used for digital signatures is Rivest-Shamir-Adelman (RSA). As shown in FIG. 2, the RSA cryptosystem uses four functions. The first function is a private key generation function (f1) that generates a private key 202 based on two distinct prime numbers p and q. The integers p and q are randomly selected and kept secret. The second function is a public key generation function (f2) that generates a public key 204 based on the two prime numbers p and q. The public key 204 consists of a public modulus (n) and a public exponent (e). The public modulus (n) is calculated according to Equation 1 below. The public exponent (e) is selected such that Equation 2 below is true. That is, n=pq (Equation 1) gcd(p-1,e)=gcd(q-1,e)=1 (Equation 2) In Equation 2 above, gcd is the greatest common denominator function that returns the largest positive integer by which each of its inputs are divided. The RSA cryptosystem uses a signature function (f3) to sign a message (m) 206 with a private key 202, where: JPEG0007617117000001.jpg6165 The RSA cryptosystem uses a private exponent (d) to compute a signature 208 of a message (m) 206. The private exponent (d) is computed according to Equation 3 below:

number

[0035] A secure implementation of an RSA-based signature scheme requires that a signer (e.g., a person or group of people) has sole control of the functions, namely, the private key generation function (f1), the public key generation function (f2), and the signature function (f3) within the security boundary. In general, a device implementing an RSA signature scheme (a) performs the private key generation function (f1) and the public key generation function (f2) only once during the device's lifetime, and (b) ensures that only authorized signers can perform the signature function (f3). The private key (e.g., private key 202) should never leave the device. The device must always be able to reliably authenticate a signer before performing the signature function (f3). Thus, a security device requires within the security boundary (a) computing power to compute the functions, (b) memory to store the keys, (c) input / output (I / O) devices, and (d) authentication solutions. The security boundary can consist of separate electronic devices, each of which implements partial functionality. For example, the key generation function, the private key generation function (f1) and the public key generation function (f2) may be implemented by one set of electronic devices, and the signature function (f3) may be implemented as a separate set of electronic devices.

[0036] The cryptographic resistance of a signature scheme (such as the RSA cryptosystem mentioned above) is defined in terms of computational complexity theory and has mathematical and physical components. A measure of mathematical resistance to attack takes into account the computational resources (number of steps, memory in bits, program size, etc.) required to break the scheme (i.e., to sign a message without access to the private key). The computational cost of breaking the scheme is expressed as a security level. Security levels are usually expressed in "bits." "N-bit security" means that a malicious party needs 2 N The physical attack resistance of a security device refers to the cost of forging a signature without mathematically breaking the signature scheme (e.g., tampering with the security device).

[0037] The mathematical and physical attack resistance required for a signature scheme is derived from a risk analysis and takes into account the application in which the signature solution is being used. In many cases, the physical design of the security device is a weak point in RSA-based signature schemes. One approach to improve physical attack resistance would require cooperation between multiple devices. In such an approach, a signature key (e.g., a master private key) is shared between several security devices. Thus, a signature can only be created when the security devices cooperate. Attacking one device (e.g., physically tampering with one device to reveal part of the master private key on one device) is insufficient to forge a signature. A cryptographic scheme to address these issues is described below in connection with Figures 3 and 4.

[0038] In FIG. 3 , a master private key 302 is split into two private key shares 304 and 306 (sometimes referred to as a split key signature scheme). The master private key 302 is subjected to a key splitting function (f 10 The master private key 302 is generated by a trusted dealer 308 who splits it by a key splitting function (f ) to derive a first private key share (d') 304 and a second private key share (d") 306 based on the private exponent (d) of the master private key 302 according to Equation 6 below. The trusted dealer 308 can split the master private key 302 for additive sharing or multiplicative sharing. FIG. 3 shows a trusted dealer 308 splitting the master private key 302 for additive sharing. When splitting for additive sharing, the trusted dealer 308 uses a key splitting function (f ) to derive a first private key share (d') 304 and a second private key share (d") 306 based on the private exponent (d) of the master private key 302 according to Equation 6 below: 10 ) is used. That is, d≡d'+d”(modψ(n)) (Equation 6) When splitting for multiplicative sharing, a trusted dealer 308 uses a key splitting function (f) to derive a first private key share (d') 304 and a second private key share (d") 306 according to Equation 7 below: 10 ) is used. That is, d≡d'd”(modψ(n)) (Equation 7) The trusted dealer 308 sends the first private key share (d') 304 to the first security device 310 and the second private key share (d") to the second security device 312. In generating the signature, the security devices 310 and 312 perform a signature function (f3) with their respective private key shares to generate a first signature share (σ') 314 and a second signature share (σ") 316. The signature (σ) 308 is generated by combining the first signature share (σ') 314 and the second signature share (σ") 316 in a split key combination function (f 11 ) is used to generate the split key combination function (f 11 ) is calculated according to the following Equation 8:

number

number

[0039] In some examples, one of the private key shares is held by the security device and the other private key share is held by a backend server (e.g., backend server 702 in FIG. 7 below). Split-key signature schemes often require a trusted dealer 308 to split the master private key 302 into private key shares 304 and 306 and then securely send the signature shares 314 and 316 to the security device. In some examples, the trusted dealer 308 uses distributed generation of the shares used, where the first signature share (σ') 314 and the second signature share (σ") 316 and the common public key 204 are generated as a result of a multi-party cryptographic protocol (e.g., Multi-Party Cryptographic Protocol II) in which the master private key 302 never exists in its entirety.

[0040] FIG. 4 illustrates a system that utilizes multi-key key asymmetric cryptography using multiple private keys that are unrelated to each other. FIG. 4 illustrates a multi-key signature scheme that uses a first security device 402 and a second security device 404. In some examples, one of the first or second security devices 402 and 404 is a back-end server (e.g., back-end server 702 in FIG. 7 below). Each of the security devices 402 and 404 separately generates a private key 406 and 408 using a private key generation function (f1) (as described above). Furthermore, each of the security devices 402 and 404 generates a public key 410 and 412 using a public modulus (n) (e.g., calculated according to Equation 1 above) and a public exponent (e) (e.g., determined according to Equation 2 above). The public keys 410 and 412 are sent to the back-end server. When security devices 402 and 404 receive message 414 for use in generating a signature, after the security devices have each independently authenticated the signer, security devices 402 and 404 each independently generate signatures 416 and 418 using signature function (f3) (as described above).

[0041] To sign a digital document, a composite signature 420 is generated from the first signature (σ1) 416 and the second signature (σ2) 418. In the illustrated example, the composite signature (σ c ) 420 is generated using a compound signature function (f6) according to Equation 10 below: σ c =(bn1σ1+an2σ2)mod(n1n2) (Equation 10) In the above formula 10, n1 is the public modulus of the first public key 410, and n2 is the public modulus of the second public key 412. Furthermore, the coefficients a and b satisfy an1+bn2=1. c ) 420 is further modified by the backend server and then used to attach the digital document.

[0042] To verify the signed document, the composite public modulus (n c ) is calculated using a composite public key function (f5) according to Equation 11 below: n c =n1n2 (Equation 11) The composite public modulus (n c ) is based on the public modulus (n1) of the first public key 410 and the second public modulus (n2) of the second public key 412.

[0043] Composite public key 422( <n c , e>) and message 414 to obtain the signature (σ s ) is verified using function f4 (as described above).

[0044] 5 shows a system that uses a unique backend server identifier (BESID) 506 to generate an overall public key 502 and a final determined key 504. The system embeds the BESID 506 into the overall public key 502 and the final determined key 504. The following description uses a composite key scheme, although a split key scheme could also be used.

[0045] The system is based on the identity embedding function (f 20 ) to generate the overall public key 502 and the final signature 508. 20 ) uses the composite public key 422 (or any other applicable public key) and the BESID 506 to generate the overall public key 502 and the final signature 508. In the illustrated example, the identity embedding function (f 20 ) is calculated according to the following Equations 12 to 17. First, the system calculates the L bound according to Equation 12 below. That is,

number

number

[0046] The system calculates the modulus (n TP ) is calculated. That is, n TP =n'·p (Equation 15) As a result, the identity embedding function (f 20 ) is the overall public key 502 <n TP ,e> will be output.

[0047] The system calculates the final decision index (d f ) is calculated. That is,

number

[0048] After the backend server generates the composite signature 420, the system generates a final signature (σ F) 508. F ) 508 is the final decision function (f 30 ) and the backend server's BESID 506 is embedded in it using the final decision function (f 30 ) is an RSA signature (σ') (a compound signature (σ c ) 420), the padded message P, and the final signature (σ F ) to generate a final decision key 504 (e.g., (n, a', b', p, d f In the illustrated example, the final decision function (f 30 ) is calculated according to the following Equations 18 to 20. First, the system truncates the padded message P according to the following Equation 18. That is, P f =Pmodp (Equation 18) In the above formula 18, P f is the truncated message. The system then generates a partial final signature (σ f ) is calculated. That is,

number

number

[0049] 6A and 6B are block diagrams of a certificate authority 104 that cooperates with the signing authority 102 to generate a certificate 602 to be associated with a user. FIG. 6A illustrates an example when the certificate authority 104 has access to the signature authority 102's internal information (such as the BESID 506, etc.). For example, the certificate authority 104 may be closely associated with the signing authority 102 (e.g., operated by the same entity) or may be incorporated into the signing authority 102. FIG. 6B illustrates an example when the certificate authority 104 does not have access to the signature authority 102's internal information. For example, the certificate authority 104 may be operated by a separate entity as the signing authority 102. In the illustrated example of FIG. 6A and 6B, the certificate authority 104 includes a certificate authority (CA) private key 604 and a certificate generator 606. The CA private key 604 may be generated by the certificate authority 104 by any suitable means (e.g., the private key generation function (f1) as described above). The certificate generator 606 receives input from the signing authority 102 and generates the certificate 602.

[0050] In FIG. 6A, a certificate generator 606 uses a public key (e.g., composite public key 422 in FIG. 4 above), a BESID 506, and a client identifier (CID) 610 to generate a certification statement 608 using a combination function (f 50 ) The public key, the BESID 506 and the CID 610 are received from the signing authority 102. 50 ) generates a certification statement 608, which is a list or concatenation of public keys, BESIDs 506, and CIDs 610.

[0051] In FIG. 6B, a certificate generator 606 uses a combined function (f) to generate a certification statement 608 using a comprehensive public key (e.g., comprehensive public key 502 of FIG. 5 above) and a CID 610. 70 ) The overall public key and CID 610 are received from the signing authority 102. 70) generates a certification statement 608 which is a list or concatenation of the overall public key and CIDs 610.

[0052] The certificate generator 606 generates the certificate 602 by applying a signature function (f3) to the attestation statement 608 using the CA private key 604. The certificate generator 606 then stores the certificate 602 associated with the CID 610 in a database.

[0053] When the certificate 602 is included in a signing request (e.g., signing request 804 in FIG. 8 below), the signing authority 102 calculates an identity extraction function (f 60 ) to extract the BESID 506 from the certificate 602. 60 ) extracts the BESID 506 from the certificate 602 by decrypting the certificate with the public key of the certificate authority 104 that corresponds to the CA private key 604 , and extracts the BESID 506 from the attestation statement 608 .

[0054] 7 is a block diagram of a system for generating multiple certificates 602 associated with a customer 110. When a security device 108 is first activated, it generates a private key (e.g., private key 202 of FIG. 2 above) and a public key 204. The security device 108 sends the public key 204 to the signing authority 102, which routes the public key 204 to at least two backend servers 702. These backend servers 702 will be servers that have the necessary information to communicate with the security device 108 (e.g., IP address, authentication information (credentials), etc.). The backend servers 702 also receive or otherwise retrieve a CID 610 associated with the security device 108 (e.g., obtained via an activation process, etc.).

[0055] In the illustrated example, backend servers 702a and 702b independently generate public keys and combine the generated public keys with public keys received from security devices 108 using the composite public key function (f5). Alternatively, customer 110 registers more than one security device 108 and backend server 702 combines the received public keys using the composite public key function (f5). In the illustrated example, primary backend server 702a generates primary composite public key 422a. Primary backend server 702a forwards composite public key 422a, its BESID 506a and CID 610 to frontend server 704. Frontend server 704 sends composite public key 422a, CID 610 and BESID 506a to certificate authority 104. The certificate authority 104 uses the certificate generator 606 to generate a primary certificate 706a using the composite public key 422a, the CID 610 and the BESID 506a.

[0056] The secondary backend server 702b generates a secondary composite public key 422b. The secondary composite public key 422b is different from the primary composite public key 422a because the public key generated by the secondary backend server 702b is different from the public key generated by the primary backend server 702a. The secondary backend server 702b forwards the composite public key 422b, its BESID 506b and CID 610 to the frontend server 704. The frontend server 704 sends the composite public key 422b, CID 610 and BESID 506b to the certificate authority 104. The certificate authority 104 uses the certificate generator 606 to generate a secondary certificate 706b using the composite public key 422b, CID 610 and BESID 506b.

[0057] FIG. 8 is a block diagram of a system that uses redundant certificates (e.g., primary certificate 706a and secondary certificate 706b) associated with a customer 110 to generate a digital signature (e.g., final signature 508) to sign a document. In the illustrated example, the customer 110 interacts with the application server 106 as the application server 106 needs to generate a signed document. The application server 106 receives and / or otherwise retrieves (e.g., via the customer 110) a CID 610. Using the CID 610, the application server requests a certificate associated with the CID 610 (e.g., primary certificate 706a and secondary certificate 706b, etc.). The application server 106 generates a signature request 804 that includes (i) the certificates 706a and 706b, and (ii) the message 414. The message can be an original message (e.g., a digital document to be signed) or a message digest computed from the original message by applying a cryptographic hash function (e.g., SHA-256, etc.) to the original message.

[0058] The application server 106 has an established relationship with at least two front-end servers (e.g., a primary front-end server 704a and a secondary front-end server 704b) of the signing authority 102 (e.g., established when the application server 106 registers with the signing authority 102). The relationship with multiple front-end servers provides redundancy in case one of the front-end servers is unavailable. The signing authority 102 can select which particular front-end server is assigned to the application server 106 based on traffic management principles. For example, application servers 106 assigned to the same primary front-end server 704a can be assigned to different secondary front-end servers 704b such that the unavailability of the primary front-end server 704a does not stress any of the secondary front-end servers 704b. A front-end server serving as a primary front-end server 704a for one application server 106 can be a secondary front-end server 704b for another application server 106.

[0059] The application server 106 sends the signing request 804 to the primary front-end server 704a. If the application server 106 does not get an acknowledgment of the signing request 804 and / or receives any other indication that the primary front-end server 704a is unavailable, the application server 106 sends the signing request 804 to the secondary front-end server 704b. In instances where the application server 106 is associated with more than two front-end servers, this can continue until the application server 106 has tried all of the associated front-end servers. If a front-end server is unavailable, the application server 106 generates an error.

[0060] A front-end server (e.g., primary front-end server 704a or secondary front-end server 704b) that receives the signature request 804 performs an identity extraction function (f 60) to extract the BESID 506a of the primary backend server 702a from the primary certificate 706a. The front-end server then forwards the signing request 804 to the primary backend server 702a. If the front-end server does not get an acknowledgement of the signing request 804 and / or receives any other indication that the primary backend server 702a is unavailable, the front-end server (i) extracts the identity extraction function (f 60 ) to extract the BESID 506b of the secondary backend server 702b from the secondary certificate 706b, and (ii) send the signing request 804 to the secondary backend server 702b. In instances where the signing request 804 includes more than two certificates, this can continue until the front-end server attempts to forward the signing request 804 using all of the certificates. If the back-end server is not available, the front-end server sends an error message to the application server 106.

[0061] A backend server (e.g., secondary backend server 702b) verifies the identity of customer 110. In the illustrated example, the backend server includes a private key (e.g., a separate private key in a multi-key scheme or a key share in a split-key scheme) associated with customer 110. The backend server attempts to authenticate the identity of customer 110 (e.g., via security token 806). If the backend server successfully authenticates the identity of customer 110, it uses a signing function (f3) to generate a first signature (or a first signature share) using the message 414 and the private key associated with customer 110. The backend server also sends the signing request (or a portion thereof) to the security device 108 associated with customer 110. After the security device 108 authenticates the identity of customer 110, the security device 108 generates a second signature (or a second signature share) 808 and sends it to the backend server that sent the signing request 804. In a composite key embodiment, the backend server uses a composite signing function (f6) to generate the composite signature 420. In a split key embodiment, the backend server uses a split key combining function (f 11) to generate a signature. Using the final decision key 504, the backend server calculates the final decision function (f 30 ) to generate the final signature 508.

[0062] The back-end server sends the final signature 508 to the front-end server that sent the signature request 804. The front-end server sends the final signature 508 to the application server 106 that sent the signature request 804. The application server 106 attaches the final signature 508 to the digital document to be signed.

[0063] The front-end server and the back-end server may run on the same physical machine or set of physical machines using virtual computing resources, such as virtual machines or containers. In some examples, the front-end server and the back-end server are isolated from each other such that if one is destroyed, the other is not affected at all. For example, if one front-end server is destroyed, the other front-end server and the back-end server are not affected.

[0064] Figure 9 shows a security device 108 that embodies the device-side portion of the signature schemes of Figures 2, 3, 5, 7 and 8. The security device 108 embodies the functions: a private key generation function (f1), a public key generation function (f2) and a signature function (f3). The security device 108 includes a control interface 902 and an input / output (I / O) interface 904. The control interface 902 receives input from a signer (e.g., customer 110) to authenticate the identity of the signer before the security device 108 generates a signature (e.g., signatures 416 and 418). The I / O interface 904 communicates directly or indirectly with the signing authority 102 to send signatures and public keys and to receive messages used to generate signatures.

[0065] Figure 10 is a block diagram of electronic components 1000 of the security device 108 of Figure 9. In the illustrated example, the electronic components 1000 include a control interface 902, an I / O interface 904, a processor or controller 1002, and a memory 1004, as well as a data bus 1006 connecting the other electronic components.

[0066] The control interface 902 provides a physical interface between the security device 108 and the signer. The control interface 902 may include a digital camera (e.g., for image capture, recognition of visual cues, facial recognition, iris recognition, etc.), a touch screen and / or keyboard (e.g., for inputting authentication information), a voice input device (e.g., a microphone for voice recognition, etc.), a biometric input device (e.g., a fingerprint scanner, etc.), and / or a biometric sensor (e.g., a blood oximeter, a pulse sensor, etc.). For example, the control interface 902 may include a touch screen and a fingerprint identification sensor on a smartphone. The input from the signer to the control interface 902 is used to authenticate the identity of the signer. In some examples, more than one method of identifying and authenticating the signer is included. For example, the signer may be required to provide both a fingerprint and a password. In some examples, the control interface 902 may differ between two cooperating security devices 108. For example, one security device 108 may have a camera to perform facial recognition and the other security device 108 may have a fingerprint scanner.

[0067] The I / O interface 904 provides an interface for communicating with other devices to send public keys and signatures and receive messages. The I / O interface 904 includes a communications controller and antenna for one or more standards-based networks (e.g., Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Code Division Multiple Access (CDMA), WiMAX (IEEE 802.16m); Near Field Communication (NFC); ​​Wireless LAN (including IEEE 802.11 a / b / g / n / ac or others), Bluetooth® and Bluetooth® Low Energy, and Wireless Gigabit (IEEE 802.11ad), etc.). The I / O interface 904 communicates with external networks directly or indirectly (e.g., via another security device 108). The external network may be a public network, such as the Internet, a private network, such as an intranet, or a combination thereof, and may utilize a variety of currently available or later developed network protocols, including, but not limited to, TCP / IP-based network protocols.

[0068] The processor or controller 1002 can be any suitable processing device or set of processing devices, such as, but not limited to, a microprocessor, a microcontroller-based platform, a suitable integrated circuit, one or more field programmable gate arrays (FPGAs), and / or one or more application specific integrated circuits (ASICs). The memory 1004 can be a volatile memory, a non-volatile memory, an immutable memory, a read-only memory, and / or a mass storage device (e.g., a hard drive, a solid-state drive, etc.). In some examples, the memory 1004 includes multiple types of memory, particularly volatile memory and non-volatile memory. Additionally, the memory 1004 can include a secure memory (sometimes referred to as "CryptoMemory") that includes an embedded hardware encryption engine with its own authentication key for securely storing information.

[0069] FIG. 11 is a flow diagram of a method for using redundant certificates 602 associated with a customer 110 to generate a document signed with a digital signature, which may be embodied by the application server 106 of FIGS. 1 and 8. Initially, at block 1102, the application server 106 receives input from the customer 110 that results in a digital document to be signed. For example, the customer 110 may click an accept button to indicate acceptance of the privacy policy of a website associated with the application server 106. At block 1104, the application server 106 retrieves two or more certificates 602 associated with the customer 110 from the certificate authority 104. At block 1106, the application server 106 sends a signature request 804 to the primary front-end server 704a. The application server 106 is configured to be communicatively coupled to at least two front-end servers. In some examples, the order of the front-end servers (e.g., which front-end server will be the primary front-end server 704a and which front-end server will be the secondary front-end server 704b) is specified by the signing authority 102 when the application server 106 registers with the signing authority 102. Alternatively, in some examples, the application server 106 selects one of the front-end servers to send the signing request 804 to first.

[0070] At block 1108, the application server 106 determines whether it has received an indication that the front-end server is unavailable. For example, the application server 106 may (a) wait a threshold period of time to receive a signature from the front-end server, (b) receive a message that the front-end server is unavailable, and / or (c) fail to receive an acknowledgment from the front-end server in response to the signature request 804. If the front-end server is available, the method continues at block 1110. Otherwise, if the front-end server is not available, the method continues at block 1114.

[0071] At block 1110, the application server 106 receives the finalized signature 508 from the front-end server. At block 1112, the application server 106 attaches the finalized signature to the digital document.

[0072] At block 1114, the application server 106 determines whether there is another front-end server to send the signing request to. If there is another front-end server, the method proceeds to block 1116. Otherwise, if there is not another front-end server, the method proceeds to block 1118.

[0073] In block 1116, the application server 106 sends the signature request 804 to the next front-end server (eg, the secondary front-end server 704b, etc.). The method then returns to block 1108.

[0074] At block 1118, the application server 106 generates an error message.

[0075] 12 is a flow diagram of a method for using redundant certificates associated with a customer 110 to generate a document signed with a digital signature, which may be embodied by the front-end server(s) 704 of FIGS. 1 and 8. Initially, at block 1202, the front-end server 704 receives a signing request 804 from the application server 106, the signing request 804 including multiple certificates (e.g., a primary certificate 706a and a secondary certificate 706b). At block 1204, the front-end server 704 performs an identity extraction function (f 60 ) to extract the BESID 506 from the primary certificate 706a. In block 1206, the front-end server 704 sends a signing request 804 to the back-end server that corresponds to the BESID 506 extracted in block 1204.

[0076] At block 1208, the front-end server 704 determines whether it has received an indication that the back-end server 702 is unavailable. For example, the front-end server may (a) wait a threshold period of time to receive a signature from the back-end server 702, (b) receive a message that the back-end server 702 is unavailable, and / or (c) fail to receive an acknowledgment from the back-end server 702 in response to the signature request 804. If the back-end server 702 is available, the method continues at block 1210. Otherwise, if the back-end server 702 is not available, the method continues at block 1214.

[0077] At block 1210, the front-end server 704 receives the finalized signature 508 from the back-end server 702. At block 1212, the front-end server 704 sends the finalized signature 508 to the application server 106.

[0078] At block 1214, the front-end server 704 determines whether another certificate (e.g., secondary certificate 706b) is present. If another certificate is present, the method proceeds to block 1216. Otherwise, if another certificate is not present, the method proceeds to block 1220. At block 1216, the front-end server 704 performs an identity extraction function (f 60 ) to extract the BESID 506 from the secondary certificate 706b. At block 1218, the front-end server 704 sends a signing request 804 to the back-end server 702 that corresponds to the BESID 506 extracted at block 1216. The method then returns to block 1208.

[0079] In block 1220 , the front-end server 704 sends an error message to the application server 106 .

[0080] FIG. 13 is a flow diagram of a method for generating a signature for a digital document that may be embodied by the systems of FIG. 1 and FIG. 8. In FIG. 13, the backend server 702 stores a private key for the customer 110. In block 1302, the backend server 702 sends a signature request 804 to the security device 108 associated with the corresponding certificate 602 included in the signature request 804. In block 1304, the security device 108 authenticates the customer 110. For example, the security device 108 may authenticate the customer 110 in response to receiving a fingerprint and / or a set of authentication information. In block 1306, the security device 108 generates a first signature with its stored private key using a signature function (f3). In block 1308, the security device 108 sends the first signature to the backend server 702.

[0081] At block 1310, the backend server 702 authenticates the customer 110. In some examples, the backend server 702 can communicate with a security token to receive authentication information or other authentication tokens. For example, the security token can have a fingerprint scanner to receive input from the customer 110 and a wireless transceiver to determine if the security token is within a threshold distance of the security device 108 (e.g., using an RSSI measurement, etc.). At block 1312, the backend server 702 generates a second signature using a signature function (f3). At block 1314, the backend server 702 generates a combined signature (e.g., a composite signature using a composite signature function (f6), or a split key combination function (f 11 In block 1216, the backend server 702 generates a final decision function (f 30 ) to generate the final signature. In block 1318, the backend server 702 sends the final signature to the frontend server 704.

[0082] Figure 14 is a flow diagram of a method for generating a signature for a digital document that may be implemented by the systems of Figures 1 and 8. In Figure 14, the backend server 702 does not store the private key for the customer 110. In block 1402, the backend server 702 sends a signature request 804 to the security device 108 associated with the corresponding certificate 602 included in the signature request 804.

[0083] In block 1404, the first security device 108 authenticates the customer 110. For example, the first security device 108 may authenticate the customer 110 in response to receiving a fingerprint and / or a set of authentication information. In block 1406, the first security device 108 generates a first signature with its stored private key using a signing function (f3). In block 1408, the first security device 108 sends the first signature to the backend server 702.

[0084] In block 1410, the second security device 108 authenticates the customer 110. In block 1412, the second security device 108 generates a second signature with its stored private key using a signing function (f3). In block 1414, the second security device 108 sends the second signature to the backend server 702.

[0085] In block 1416, the backend server 702 generates a combined signature (e.g., a combined signature using a combined signature function (f6) or a split key combining function (f 11 In block 1418, the backend server 702 generates a final decision function (f 30 ) to generate the finalized signature. In block 1420, the backend server 702 sends the finalized signature 508 to the frontend server 704.

[0086] FIG. 15 is a flow diagram of a method for reissuing a certificate 602. A certificate can be reissued, for example, when one of the backend servers 702 fails. A new backend server can be installed and a new certificate can be issued based on the existing certificate. As described below, this process is automatic and in some instances does not require sending a specific request to the certificate authority 104. If two different backend servers 702 are used and one of them is not functioning, this automatic certificate issuing procedure allows the system to recover without any downtime. First, the certificate authority 104 receives the BESID 506 and the public key of the new backend server 702.

[0087] At block 1502, the certificate authority 104 verifies the primary and secondary certificates 706a and 706b associated with the primary and secondary backend servers 702a and 702b. At block 1504, the certificate authority 104 extracts the CID 610, the public key of the primary certificate 706a, and the public key of the secondary certificate 706b. At block 1506, the certificate authority 104 uses the public key of the primary certificate 706a and the public key of the secondary certificate 706b to calculate a public key for the customer's security device 108. At block 1508, the certificate authority 104 creates a new public key using the public key for the customer's security device 108 and the public key of the new backend server 702 (e.g., using a compound public key function (f5), etc.). At block 1510, the certificate authority 104 creates a new certificate 602 for the new backend server 702 based on the BESID 506, the new public key, and the CID 610 associated with the primary and secondary certificates 706a and 706b of the new backend server 702. At block 1506, the certificate authority 104 replaces the certificate associated with the non-functioning backend server 702 with the new certificate.

[0088] In this specification, the use of disjunctions is intended to include conjunctions. The use of definite or indefinite articles is not intended to indicate number. In particular, reference to "the" object or "a" object and "an" object is intended to mean one of a plurality of possible such objects. Furthermore, the conjunction "or" may be used to convey features that exist simultaneously instead of mutually exclusive alternatives. In other words, the conjunction "or" should be understood to include "and / or". As used herein, the terms "module" and "unit" refer to hardware that includes circuitry, often in conjunction with sensors, to provide communication, control, and / or monitoring capabilities. "Module" and "unit" may also include firmware that executes on the circuitry. The term "remote" means geographically separated and communicatively coupled via an internal or external network, such as an intranet or the Internet. The terms "include" and "comprising" are inclusive and have the same scope as "comprises" and "comprising", respectively.

[0089] The above-described embodiments, and in particular any "preferred" embodiments, are possible examples of implementations and are merely set forth for a clear understanding of the principles of the present invention. Many variations and modifications may be made to the above-described embodiment(s) without substantially departing from the spirit and principles of the technology described herein. All modifications are intended to be included herein within the scope of this disclosure and are protected by the following claims.

Claims

1. 1. A system for generating a digital signature, comprising: a first backend server; a second backend server; a front-end server, the front-end server comprising: receiving a signing request from a remote application server, the signing request including a first overall public key with a cryptographically embedded first backend server identifier and a second overall public key with a cryptographically embedded second backend server identifier; extracting the cryptographically embedded first backend server identifier from the first overall public key; forwarding the signature request to the first backend server corresponding to the first backend server identifier; in response to determining that the first backend server is unavailable, extracting the cryptographically embedded second backend server identifier from the second overall public key and forwarding the signing request to the second backend server corresponding to the second backend server identifier; configured to forward the second signature to the application server; The first backend server and the second backend server each include transmitting the signature request to a plurality of remote security devices associated with a collective public key; receiving a first signature from each of the plurality of remote security devices; generating a combined signature based on the first signature; generating the second signature based on the combined signature and a final determination key, the final determination key being cryptographically generated based on a server identifier of a backend server; The system is configured to forward the second signature to the front-end server.

2. The system of claim 1 , wherein the combined signature is generated using a multi-key scheme.

3. The system of claim 1 , wherein the combined signature is generated using a split key scheme.

4. The system of any one of claims 1 to 3, wherein the front-end server determines that the first back-end server is unavailable when the front-end server is unable to receive a positive response from the first back-end server in response to forwarding the signature request.

5. The system of any one of claims 1 to 3, wherein the front-end server determines that the first back-end server is unavailable when the front-end server is unable to receive the second signature within a threshold period of time.

6. 1. A system for generating a digital signature, comprising: a first backend server; a second backend server; a first front-end server; a second front-end server; a certificate authority; the certificate authority is configured to forward, in response to receiving a certificate request from an application server including a user identifier, a first certificate having a first public key and a second certificate having a second public key to the application server, the first certificate and the second certificate being associated with the user identifier; The first front-end server and the second front-end server each include receiving a signing request from the application server, the signing request including the first public key with a cryptographically embedded first backend server identifier and the second public key with a cryptographically embedded second backend server identifier; extracting the cryptographically embedded first backend server identifier from the first public key; forwarding the signature request to the first backend server corresponding to the first backend server identifier; in response to determining that the first backend server is unavailable, extracting the cryptographically embedded second backend server identifier from the second public key and forwarding the signing request to the second backend server corresponding to the second backend server identifier; configured to forward the second signature to the application server; The first backend server and the second backend server each include transmitting the signature request to a plurality of remote security devices associated with a collective public key; receiving a first signature from each of the plurality of remote security devices; generating a combined signature based on the first signature; generating the second signature based on the combined signature and a final determination key, the final determination key being cryptographically generated based on a server identifier of a backend server; The system is configured to forward the second signature to a front-end server.

7. The system of claim 6 , wherein the combined signature is generated using a multi-key scheme.

8. The system of claim 6 , wherein the combined signature is generated using a split key scheme.

9. The system of any one of claims 6 to 8, wherein the front-end server determines that the first back-end server is unavailable when the front-end server is unable to receive a positive response from the first back-end server in response to forwarding the signature request.

10. The system of any one of claims 6 to 8, wherein the front-end server determines that the first back-end server is unavailable when the front-end server is unable to receive the second signature within a threshold period of time.

11. 7. The system of claim 6, wherein the certificate authority is further configured to generate a third certificate associated with a third backend server based on the first certificate and the second certificate in response to determining that one of the first or second backend servers is unavailable.

12. 1. A method for generating a digital signature, comprising: receiving, at the front-end server, a signing request from a remote application server, the signing request including a first overall public key with a cryptographically embedded first back-end server identifier and a second overall public key with a cryptographically embedded second back-end server identifier; extracting, by the front-end server, the cryptographically embedded first back-end server identifier from the first overall public key; forwarding, by the front-end server, the signing request to a first back-end server corresponding to the first back-end server identifier; in response to determining that the first backend server is unavailable, extracting, by the front-end server, the cryptographically embedded second backend server identifier from the second overall public key and forwarding the signing request to a second backend server corresponding to the second backend server identifier; forwarding the signature request by the first backend server or the second backend server to a plurality of remote security devices associated with an overall public key; receiving, by the first backend server or the second backend server, a first signature from each of the plurality of remote security devices; generating a combined signature based on the first signature by the first backend server or the second backend server; generating, by the first backend server or the second backend server, a second signature based on the combined signature and a final determination key, the final determination key being cryptographically generated based on a server identifier of the backend server; forwarding the second signature by the first backend server or the second backend server to the frontend server; forwarding, by the front-end server, the second signature to the application server.

13. The method of claim 12 , wherein the combined signature is generated using a multi-key scheme.

14. The method of claim 12 , wherein the combined signature is generated using a split key scheme.

15. 15. The method of claim 12, wherein determining that the first backend server is unavailable comprises determining when the frontend server is unable to receive an affirmative response from the first backend server in response to forwarding the signing request.

16. The method of any one of claims 12 to 14, wherein the front-end server determines that the first back-end server is unavailable when the front-end server fails to receive the second signature within a threshold period of time.

Images