Digital signature system based on cloud of dedicated local device
A digital signature system using multiple security devices with independently generated private keys enhances physical attack resistance by requiring simultaneous compromise of all devices to forge a signature, addressing the limitations of traditional RSA-based systems.
Patent Information
- Application Number
- JP2025113255
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2019-06-14
- Filing Date
- 2025-07-03
- Publication Date
- 2025-10-14
AI Technical Summary
Existing digital signature systems face challenges in improving physical attack resistance while maintaining computational efficiency, particularly in RSA-based schemes where the private key must remain secure and the signer's identity must be authenticated.
A system utilizing multiple security devices, each with independently generated private keys, generates composite signatures that require collaboration to forge, enhancing physical attack resistance without relying on a trusted dealer or multi-party protocols, and uses a composite public key for verification.
The system provides improved physical attack resistance by requiring simultaneous compromise of all security devices to forge a signature, while maintaining computational efficiency by distributing the private key generation and authentication processes across multiple devices.
Smart Images

Figure 2025156351000013 
Figure 2025156351000014 
Figure 2025156351000015
Abstract
Description
[Technical Field]
[0001] The present disclosure relates generally to secure electronic communications and commerce, and more particularly to an attack-resistant implementation of public key digital signatures based on a cloud of dedicated local devices. [Background technology]
[0002] Documents are increasingly being digitally signed. Digital signatures utilize a system that (a) authenticates the person signing the document and (b) validates the authenticity of the signed document. In this way, those relying on the document can be confident that it is authentic, and the person who signed the document cannot deny having signed it. These digital signature systems often use asymmetric cryptography, relying on a secret private key associated with an individual and a non-secret public key. To forge a signature, a malicious actor must either obtain the private key or incur the computational expense (if possible) of breaking the signature scheme (i.e., signing a message without possessing the private key). The attack resistance of a digital signature system can be categorized as mathematical resistance (e.g., the ability to forge a digital signature by mathematically breaking the signature) or physical resistance (e.g., tampering with a physical device to forge a signature). In general, physical resistance is more difficult to improve. Summary of the Invention
[0003] The appended claims define the present application. This disclosure summarizes aspects of embodiments and should not be used to limit the scope of the claims. As will be apparent to one skilled in the art upon review of the following figures and detailed description, other implementations are contemplated in accordance with the techniques described herein, and these implementations are within the scope of the present application.
[0004] An exemplary system for generating a digital signature includes a first security device, a second security device, and a computing device remote from the first and second security devices. The first security device stores a first private key and, in response to receiving a message, generates a first signature based on the message received from the computing device and the first private key. The second security device stores a second private key generated independently from the first private key and, in response to receiving the message, generates a second signature based on the message and the second private key. In response to receiving a request for a digital signature, the computing device sends the message to the first and second security devices. In response to receiving the first and second signatures, the computing device further generates a composite cryptographic signature based on the first and second signatures. Additionally, the computing device appends the composite cryptographic signature to the digital document.
[0005] In some example embodiments, the first security device authenticates the signer based on a first input to the first security device before generating the first signature, and additionally, the second security device authenticates the signer based on a second input to the second security device before generating the second signature.
[0006] In some example embodiments, the first input is a different type of input than the second input.
[0007] In some example embodiments, a first security device generates a first private key and a first public key that includes a first public modulus, and a second security device generates a second private key and a second public key that includes a second public modulus.
[0008] In some example embodiments, the computing device generates a compound cryptographic signature further based on the first public module and the second public modulus.
[0009] In some example embodiments, the computing device does not store the private key used to generate the compound cryptographic signature.
[0010] In some example embodiments, the first security device and the second security device are each communicatively coupled to a computing device.
[0011] In some example embodiments, a first security device is communicatively coupled to a computing device and a second security device is communicatively coupled to the first security device.
[0012] 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 related elements may be omitted, or in some cases, proportions may be exaggerated to highlight and clearly show the novel features described herein. In addition, system components may be variously configured as known in the art. Furthermore, in the drawings, like reference numerals indicate corresponding parts throughout the several views. [Brief explanation of the drawings]
[0013] [Figure 1A] FIG. 1 illustrates a system that utilizes conventional asymmetric cryptography using a single private key. [Figure 1B] FIG. 1 illustrates a system that utilizes split-key asymmetric cryptography using multiple private key shares that rely on a single private key. [Figure 2] FIG. 1 illustrates a system that utilizes composite-key asymmetric cryptography, using multiple private keys that are independent of each other. [Figure 3] FIG. 3 illustrates a secure device that implements the device-side portion of the multi-key asymmetric cryptography of FIG. 2. [Figure 4] FIG. 4 is a block diagram of the electronic components of the secure device of FIG. 3. [Figure 5] FIG. 5 illustrates a system that implements the multi-key asymmetric cryptography of FIG. 2 using multiple secure devices and computing devices of FIGS. 3 and 4. [Figure 6] FIG. 5 illustrates a system that implements the multi-key asymmetric cryptography of FIG. 2 using multiple secure devices and computing devices of FIGS. 3 and 4. [Figure 7] 6. FIG. 7 is a flow diagram of a method for signing a document using the multi-key asymmetric cryptography of FIG. 2 that can be implemented by the secure devices of FIGS. 3, 4, 5, and 6 and the computing devices of FIGS. 5 and 6. DETAILED DESCRIPTION OF THE INVENTION
[0014] 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 is to be considered as an exemplification of the invention and is not intended to limit the invention to the particular embodiments described.
[0015] A common asymmetric cryptosystem (sometimes called a "public key cryptosystem") used in digital signatures is Rivest-Shamir-Adleman (RSA). As shown in Figure 1A, the RSA cryptosystem uses four functions. The first function is a private key generation function (f1) that generates a private key 102 based on two distinct prime numbers p and q. The integers p and q are chosen randomly and kept secret. The second function is a public key generation function (f2) that generates a public key 104 based on the two prime numbers p and q. The public key 104 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 chosen so that Equation 2 below is true.
number
number
number
number
number
number
[0016] A secure implementation of an RSA-based signature scheme requires that a signer (e.g., a person or group of people) has sole control over functions f1, f2, and f3 within a security perimeter. In general, a device implementing an RSA signature scheme (a) executes f1 and f2 only once during the device's lifetime and (b) ensures that only authorized signers can execute function f3. The private key (e.g., private key 102) must never leave the device. The device must always be able to reliably authenticate the signer before executing f3. Therefore, a security device requires, within the security perimeter, (a) computing power to perform the functions, (b) memory for storing the keys, (c) input / output (I / O) devices, and (d) an authentication solution. The security perimeter may consist of separate electronic devices, each implementing a partial function. For example, key generation functions f1 and f2 may be implemented by one set of electronic devices, and signing function f3 may be implemented by a separate set of electronic devices.
[0017] The cryptographic attack tolerance 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. Mathematical measures of attack tolerance take 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, which is usually expressed in "bits." "N-bit security" means that a malicious actor would need 2 N For example, a signature scheme may have 128-bit or 256-bit security. The monetary cost of breaking the scheme is considered to be proportional to the computational cost. The physical attack resistance of a security device refers to the cost of forging a signature (e.g., by tampering with the security device) without mathematically breaking the signature scheme.
[0018] The required mathematical and physical attack resistance of a signature scheme is derived from a risk analysis and takes into account the application in which the signature solution is being used. The physical design of security devices is often a weak point in RSA-based signature schemes. One approach to improving physical attack resistance is to require cooperation among multiple devices. In such an approach, a signing key (e.g., a master private key) is shared among several security devices. Therefore, a signature can only be created if the security devices cooperate. Attacking a single device (e.g., physically tampering with one device, revealing a portion of one device's master private key, etc.) is insufficient to forge a signature.
[0019] One such approach is shown in Figure 1B, where a master private key 110 is split into two private key shares 112 and 114 (sometimes called a Split-Key signing scheme). The master private key 110 is generated by a trusted dealer 116, who then uses the function f 10 to create a first private key share (d') 112 and a second private key share (d") 114. The trusted dealer 116 can split the master private key 110 for additive sharing or multiplicative sharing. FIG. 1B shows the trusted dealer 116 splitting the master private key 110 for additional shares. When splitting for additional shares, the trusted dealer 116 splits the master private key 110 using f 10 to derive a first private key share (d') 112 and a second private key share (d") 114 based on the private exponent (d) of the master private key 110 according to Equation 6 below:
number
number
number
number
[0020] In some examples, one of the private key shares is held by a mobile device (e.g., a smartphone), and the other private key share is held by a server collaborating in the signature scheme. Split-key signature schemes often require a trusted dealer to split a master private key 110 into signature shares 112 and 114 and then securely transmit the signature shares 112 and 114 to a security device. This introduces a third party. However, the party acting as the trusted dealer may, in some circumstances, be an untrustworthy dealer that abuses its capabilities to forge user signatures. Furthermore, the trusted dealer becomes a single point of failure in the signature scheme. If the trusted dealer is compromised, all master private keys held or generated by the trusted dealer are also compromised. To overcome this drawback, distributed generation of shares is used, where the first signature share (σ') 122, the second signature share (σ") 124, and the common public key 104 are generated as a result of a multi-party cryptographic protocol (e.g., multi-party cryptographic protocol Π) in which the master private key 110 never exists in its entirety. However, split-key implementations are very costly and inefficient compared to traditional RSA implementations.
[0021] As described in more detail below, signature generation using cooperation among multiple devices can be implemented with greater physical attack resistance than traditional RSA signer schemes, without the computational inefficiencies of split-key signature schemes (e.g., with multi-party cryptographic protocols) or the issues surrounding the use of trusted dealers. In the systems described below, instead of relying on either a master private key or a multi-party cryptographic protocol to generate a set of signature shares, a composite signature may be composed of individually generated signatures that are based on independently generated private keys. This is sometimes referred to as a Comp Key scheme. As used herein, an independently generated private key is a private key that was not generated using a master private key or a multi-party cryptographic protocol (e.g., as opposed to the private key shares of a split-key signature scheme).
[0022] The system includes two or more security devices, each storing an independently generated private key associated with its own public key. The security devices may be portable electronic devices capable of (a) securely storing the independently generated private key, (b) receiving input from a signer, (c) securely authenticating the signer's identity based on the input, (d) receiving a message for generating a signature, (e) generating a signature using the independently generated private key and the message, and (f) transmitting the signature to a computing device (e.g., a server, etc.) requesting the signature. In some examples, the security devices may be smartphones, smartwatches, tablet computers, jewelry (e.g., bracelets, rings, brooches, etc.) with embedded electronics, smart cards (e.g., credit cards, ID cards, etc.), and / or electronic seals. In some examples, each security device is configured to physically receive input from a signer (e.g., a biometric identifier such as a fingerprint, a password, etc.) independently of the other security devices. In some examples, each security device communicates with the 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, etc.), 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.
[0023] A computing device receives a signature from a security device. The computing device generates a composite signature and then uses the composite signature to sign a digital document (e.g., a contract, a website agreement, a legal document, etc.). To verify a previously signed document, the computing device obtains a public key associated with the security device and generates a composite public key. Using the composite public key, the computing device verifies whether the signature on the digital document is authentic.
[0024] Improving physical attack resistance is more difficult than improving mathematical attack resistance. A signature scheme with improved physical attack resistance is needed. Current approaches do not improve physical attack resistance. Although the Comp Key signing scheme is less mathematically robust than the corresponding conventional RSA signature scheme (e.g., if an RSA implementation has a k-bit public modulus (n) and l-bit security, the composite signature will have less than l-bit security despite having a 2k-bit public modulus), the composite signature can only be compromised by a physical attack if all of the security devices used to generate the composite signature are compromised. The mathematical attack resistance of the Comp Key signing scheme can be improved by increasing the bit length of the public modulus (n) (e.g., 256-bit public modulus (n), 2048-bit public modulus (n), etc.). The physical attack resistance of this signature scheme is improved by using the system described below, which utilizes at least two security devices with independently generated private keys.
[0025] Figure 2 illustrates a system utilizing multi-key asymmetric cryptography using multiple private keys that are independent of one another. Figure 2 illustrates a comp-key signature scheme using a first security device 202 and a second security device 204 (e.g., security device 300 as shown in Figures 3 and 4 below). Security devices 202 and 204 each independently generate private keys 206 and 208 using function f1 (as described above). Additionally, security devices 202 and 204 each generate public keys 210 and 212 having 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). Public keys 210 and 212 are transmitted to a remote computing device where they are stored in a public key database associated with the corresponding security device. When security devices 202 and 204 receive message 214, which they use to generate signatures, they each independently authenticate the signer, and then security devices 202 and 204 each independently generate signatures 216 and 218 using function f3 (as described above).
[0026] To sign a digital document, a composite signature 220 is generated from the first signature (σ1) 216 and the second signature (σ2) 218. In the illustrated example, the composite signature (σ C ) 220 is generated by function f6 according to equation 10 below:
number
[0027] To verify the signed document, the composite public modulus (n C) is calculated using function f5 according to the following equation 11: C ) is based on the public modulus (n1) of the first public key 210 and the second public modulus (n2) of the second public key 212.
number
[0028] Figure 3 shows a secure device 300 that implements the device-side portion of the CompKey signature scheme of Figure 2. Security device 300 implements functions f1, f2, and f3. Security device 300 includes a control interface 302 and an input / output (I / O) interface 304. Control interface 302 receives input from a signer 306 to authenticate the identity of signer 306, after which security device 300 generates a signature 308. I / O interface 304 communicates directly or indirectly with a computing device (e.g., computing device 502 in Figures 5 and 6 below) to send signature 308 and public key 310 and to receive message 312 used to generate signature 308.
[0029] Figure 4 is a block diagram of electronic components 400 of the secure device of Figure 3. In the illustrated example, electronic components 400 include control interface 302, I / O interface 304, processor or controller 402, and memory 404, as well as a data bus 406 connecting other electronic components.
[0030] The control interface 302 comprises a physical interface between the security device 300 and the signer 306. The control interface 302 may include a digital camera (e.g., for image capture, visual command recognition, facial recognition, iris recognition, etc.), a touchscreen and / or keyboard (e.g., for entering credentials), an audio 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 pulse oximeter, pulse sensor, etc.). For example, the control interface 302 may include a touchscreen and fingerprint identity sensor on a smartphone. Input from the signer 306 to the control interface 302 is used to authenticate the signer 306's identity. In some examples, more than one method of identifying and authenticating the signer 306 is included. For example, the signer may be required to provide both a fingerprint and a password. In some examples, the control interface 302 may differ between two cooperating security devices 300. For example, one security device 300 may have a camera that performs facial recognition, while another security device 300 may have a fingerprint scanner.
[0031] The I / O interface 304 provides an interface for communicating with other devices to send public keys 310 and signatures 308 and receive messages 312. The I / O interface 304 includes communications controllers and antennas 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); local area wireless networks (including IEEE 802.11 a / b / g / n / ac, etc.), Bluetooth® and Bluetooth® Low Energy, and Wireless Gigabit (IEEE 802.11ad), etc.). I / O interface 304 communicates directly or indirectly (e.g., via another security device 300) with an external network. 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.
[0032] The processor or controller 402 may 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 404 may be volatile memory, nonvolatile memory, unalterable memory, read-only memory, and / or a mass storage device (e.g., a hard drive, a solid-state drive, etc.). In some examples, the memory 404 includes multiple types of memory, particularly volatile and nonvolatile memory. Additionally, the memory 404 may include secure memory (sometimes referred to as "cryptomemory") that includes an embedded hardware encryption engine with its own authentication key for securely storing information.
[0033] 5 and 6 illustrate a system implementing the comp-key signature scheme of FIG. 2 using multiple security devices 300 of FIGS. 3 and 4 and a computing device 502. In FIG. 5, security device 300 communicates directly with computing device 502. In FIG. 6, one of the security devices 300 communicates directly with computing device 502, while the other security devices communicate indirectly with computing device 502 via a directly connected security device 300. In the illustrated examples of FIGS. 5 and 6, (a) security device 300 is co-located and has access to signer 306, and (b) computing device 502 is remote (e.g., geographically removed from the security device and communicatively coupled to it via an external network such as the Internet). As described in FIG. 3 above, security device 300 implements functions f1, f2, and f3. As shown in FIGS. 5 and 6, computing device 502 implements functions f4, f5, and f6.
[0034] By default, security device 300 uses function f1 to independently generate each private key (e.g., private keys 206 and 208 of FIG. 2 above) and function f2 to generate each public key 210 and 212. Public keys 210 and 212 are sent to computing device 502 via I / O interface 304. Combiner 504 within computing device 502 implements function f5 to combine public keys 210 and 212 into composite public key 222 and store composite public key 222 in public key database (PKDB) 506 in association with an identifier associated with security device 300. Alternatively, in some examples, the computing device stores public keys 210 and 212 with an identifier associated with security device 300 and performs function f5 when composite public key 222 is needed.
[0035] When a digital document is to be signed, computing device 502 sends a message (e.g., message 214 in FIG. 2 above) to security device 300. 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. Using the message and respective private keys 206 and 208, security device 300 each generates a signature (e.g., signatures 216 and 218 in FIG. 2 above) using function f3. Security device 300 transmits signatures 216 and 218 to computing device 502. Combiner 508 implements function f6 to combine signatures 216 and 218 into composite signature 220. The message and composite signature 220 are appended to the document to be signed.
[0036] 5 and 6, the combiner 504 and the validator 508 represent different security perimeters within the computing device 502 that execute on different controllers or processors. Alternatively, in some examples, the combiner 504 and the validator 508 may execute within the same security perimeter within the computing device 502.
[0037] When the signed digital document is to be verified, a verifier 506 in computing device 502 performs function f4 using the composite public key 510, the message, and the composite signature 220 attached to the digital document.
[0038] 7 is a flow diagram of a method for signing a digital document using the multi-key asymmetric cryptography of FIG. 2, which can be implemented by the secure device 300 of FIGS. 3, 4, 5, and 6 and the computing device 502 of FIGS. 5 and 6. This method can be executed, for example, when the computing device 502 receives a request to sign a digital document. Initially, at block 702, a first security device (e.g., the security device 300 of FIGS. 3 and 4 described above) receives input (e.g., via the control interface 302) and a message (e.g., via the I / O interface 304) from the signer 306. The input is used to authenticate the identity of the signer 306. For example, the input can be a fingerprint or a password. At block 704, a second security device (e.g., the security device 300 of FIGS. 3 and 4 described above) receives input (e.g., via the control interface 302) and a message (e.g., via the I / O interface 304) from the signer 306. In block 706, the first security device uses the input to authenticate the signer 306. In block 708, the second security device uses the input to authenticate the signer 306. In block 710, if the authentication is not successful, the method ends. Otherwise, the method continues at block 714. In block 712, if the authentication is not successful, the method ends. Otherwise, the method continues at block 716.
[0039] At block 714, the first security device calculates a first signature based on its independent private key. At block 716, the first security device calculates a second signature based on its independent private key. At block 718, the first security device sends the first signature to computing device 502. At block 720, the second security device sends the second signature to computing device 502. At block 722, the computing device generates a composite signature using the first signature and the second signature. At block 724, computing device 502 appends the composite signature to the digital document.
[0040] In this application, the use of disjunctive conjunctions is inclusive. The use of definite or indefinite articles does not indicate cardinality. In particular, reference to "the" object or "a" and "an" objects further denotes one of a possible plurality of such objects. Furthermore, the conjunction "or" can be used to convey simultaneous features 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 having circuitry for providing communication, control, and / or monitoring functions, often in conjunction with sensors. "Module" and "unit" can further include firmware executing on the circuitry. The terms "includes," "including," and "include" are inclusive and have the same scope as "comprises," "comprising," and "comprise," respectively.
[0041] The above-described embodiments, particularly the "preferred" embodiments, are possible examples of implementations and are set forth merely for a clear understanding of the principles of the present invention. Many variations and modifications can be made to the above-described embodiments without substantially departing from the spirit and principles of the techniques described herein. All modifications are intended to be included herein within the scope of this disclosure and protected by the following claims. [Explanation of symbols]
[0042] 102 Private key 104 Public Key 106 Messages 108 signatures 110 Master Private Key 112 First secret key sharing 114 Second secret key sharing 116 Dealer 118 First Security Device 120 Secondary Security Device 122 First Signature Share 124 Second Signature Share 202 First Security Device 204 Secondary Security Device 206 Private key 208 Private key 210 First Public Key 212 Second Public Key 214 Messages 216 First Signature 218 Second Signature 220 Composite signature 222 Composite Public Key 300 Secure Device, Security Device 302 Control Interface 304 I / O interface 306 Signatory 308 Signatures 310 Public Key 312 Messages 400 Electronic Components 402 Processor or Controller 404 Memory 406 Data Bus 502 Computing Devices 504 Combiner 506 Public Key Database 508 Verifier
Claims
1. 1. A system for generating a digital signature, comprising: a first security device storing a first private key, the first security device being configured to, in response to receiving a message, generate a first signature based on the message and the first private key; a second security device that stores a second private key generated independently from the first private key, the second security device being configured to, in response to receiving the message, generate a second signature based on the message and the second private key; a computing device remote from the first security device and the second security device; in response to receiving the request for the digital signature, sending the message to the first security device and the second security device; generating a compound cryptographic signature based on the first signature and the second signature in response to receiving the first signature and the second signature; a computing device configured to apply the compound cryptographic signature to a digital document; A system including:
2. the first security device is additionally configured to authenticate a signer based on a first input to the first security device before generating the first signature; 10. The system of claim 1, wherein the second security device is additionally configured to authenticate the signer based on a second input to the second security device before generating the second signature.
3. The system of claim 2 , wherein the first input is a different type of input than the second input.
4. the first security device is additionally configured to generate the first private key and a first public key comprising a first public modulus; 10. The system of claim 1, wherein the second security device is additionally configured to generate the second private key and a second public key that includes a second public modulus.
5. The system of claim 4 , wherein the computing device is configured to generate the compound cryptographic signature further based on the first public modulus and the second public modulus.
6. The system of claim 1 , wherein the computing device does not store a private key used to generate the compound cryptographic signature.
7. The system of claim 1 , wherein the first security device and the second security device are communicatively coupled to the computing device.
8. 10. The system of claim 1, wherein the first security device is communicatively coupled to the computing device and the second security device is communicatively coupled to the first security device.
9. 1. A method for generating a digital signature, comprising: The first security device generating and storing a first private key; In response to receiving a message, generating a first signature based on the message and the first private key; The second security device generating and storing a second private key that is independent of the first private key; responsive to receiving the message, generating a second signature based on the message and the second private key; by a computing device remote from the first security device and the second security device; in response to receiving the request for the digital signature, sending the message to the first security device and the second security device; generating a compound cryptographic signature based on the first signature and the second signature in response to receiving the first signature and the second signature; adding said compound cryptographic signature to a digital document; A method comprising:
10. prior to generating the first signature, authenticating, by the first security device, a signer based on a first input to the first security device; 10. The method of claim 9, further comprising, prior to generating the second signature, authenticating the signer by the second security device based on a second input to the second security device.
11. The method of claim 10 , wherein the first input is a different type of input than the second input.
12. generating, by the first security device, a first public key comprising a first public modulus; generating, by the second security device, a second public key including a second public modulus; 10. The method of claim 9, further comprising:
13. generating, by the computing device, the compound cryptographic signature further based on the first public modulus and a second public modulus; The method of claim 12 further comprising:
14. The method of claim 9 , wherein the computing device does not store the private key used to generate the compound cryptographic signature.
15. 10. The method of claim 9, wherein the first security device and the second security device are each communicatively coupled to the computing device.