20050102498 | Data storage and/or retrieval | May, 2005 | Bojinov et al. |
20100049994 | Universal Ethernet Power Adapter | February, 2010 | Ghoshal |
20100088500 | MULTIPLE GUEST O.S. BOOT FOR SERVER COMPONENT SETUP | April, 2010 | Ball et al. |
20060242398 | Booting from non-volatile memory | October, 2006 | Fontijn et al. |
20050149767 | Video and audio control power interface card | July, 2005 | Fei |
20080229123 | Power transmission line for power supply clusters | September, 2008 | Chen et al. |
20090249061 | CERTIFYING A VIRTUAL ENTITY IN A VIRTUAL UNIVERSE | October, 2009 | Hamilton II et al. |
20100070793 | Clock supply device | March, 2010 | Tokue |
20050144444 | Data card and authentication process therefor | June, 2005 | Hall et al. |
20070094150 | Transaction authorization service | April, 2007 | Yuen et al. |
20060005036 | Enterprise security management system using hierarchical organization and multiple ownership structure | January, 2006 | Hu et al. |
[0001] This application is a continuation in part of U.S. patent application Nos. 08/181,859, CRYPTOGRAPHIC SYSTEM WITH KEY ESCROW FEATURE, and U.S. Patent application Nos. 08/272,203, ENHANCED CRYPTOGRAPHIC SYSTEM AND METHOD WITH KEY ESCROW FEATURE, both of which are incorporated here by reference.
[0002] Public key certificates are electronic documents signed by a trusted issuer and used to attest to the binding of a user's name to a public key and other related data. Certificates provide assurance to the public that the public key identified in the certificate is owned by the user whose name is in the certificate. Major standards which describe public key certificate systems include ITU-T X.509 The Directory-Authentication Framework, and American Bankers Association ANSI X9.30-Part 3: Certificate Management for DSA (draft). Many implementations impose a hierarchical structure in which each trusted issuer, referred to as a Certification Authority (CA) certifies keys for entities that are subordinate to it. The CA affixes a digital signature to the electronic document in a way that is verifiable (one can prove that the CA signed the document) and cannot be forged (one can be assured to a high level of confidence that no one other than the CA signed the document). For example, at the top of the CA hierarchy there may be relatively few “root” CAs, perhaps one per country which certify subordinate CAs. Below the root CAs in the hierarchy, high level CAs perhaps banks) certify lower level CAs beneath them (e.g., companies), which in turn sign individual user certificates.
[0003] A CA's signature becomes more valuable as it creates a large hierarchy of users beneath it and uses its signature key to sign the certificates of both high-value users and subordinate CAs. The CA's signature key then also becomes a more likely target for terrorists, criminals bent on economic gain, and foreign military and espionage services bent on economic spying or de-stabilizing the economy via information warfare. All these issues also apply with equal force to keys used to sign electronic representations of money.
[0004] Thus far, the need for security of a CA's private signature key has been addressed by providing a “certificate signing unit” (CSU), which is a tamper-proof secure module satisfying standards set forth in Federal Information Processing Standard (FIPS) PUB
[0005] At least one major security standards body, the American Bankers Association ANSI X9.F1 committee on cryptographic security in wholesale banking applications has recommended that CSU's should be designed to forbid any export of the private key from the device in any form in order to prevent any possible unauthorized theft and use of the key. This approach would require an elaborate procedure for disaster recovery, involving the use of several key pairs simultaneously. Because a single key would exist only in a single CSU at a single site, the loss of a CSU or of a site would force the CA to use another key pair in order to continue business. This would require the CA to publicize and/or securely distribute several (at least two or three) public keys, each identified by a distinct code number (e.g., BT01, BT02, BT03), so that users could continue to verify the signatures that the CA would issue after one CSU (possibly containing the private key for BT01) had been destroyed. See X9.30-Part 3 concerning procedures for disaster recovery.
[0006] An object of the present invention is to provide a digital signing system (“signing system”) for certificates and other high value documents (including contracts, electronic representations of currency, negotiable documents, etc.) with improved security and flexibility.
[0007] A further object of the present invention is to provide a signing system in which a digital signature verifiably relates to a signature key, and in which no single signing device needs to contain the signature key during the document signing operation.
[0008] A further object of the present invention is to provide a signing system which permits loss or compromise of one or more signing devices while maintaining available, uncompromised signing services.
[0009] A further object of the present invention is to provide a signing system in which multiple signing devices each create, modify, or combine one or more partial signatures, and the result of operations by multiple signing devices produces a single digital signature.
[0010] A further object of the present invention is to provide a signing system in which multiple authorizing agents directly or indirectly authorize each individual signing device to affix or modify a partial signature.
[0011] A further object of the present invention is to provide a robust and easy-to-use mechanism in which authorizing agents can temporarily delegate their authorizing capability.
[0012] The multi-step signing system described here uses a public key cryptosystem approach to sign an electronic document such that a recipient of the document can verify the signature using a public verification key of the signer. The private signature key which corresponds to the public verification key is not permitted to exist in whole, available form in one place at any time during normal signing operations. Instead, a private signature key consists of “operational shares” which can be used to affix or modify a partial signature, and sequential operation of multiple shares produces a signature that can be verified using the public verification key. The full signature is not completed until all, or some quorum, of the signing devices have signed. Each signing device in turn requires authorization from all, or some quorum, of its associated authorizing agents before participating in the signature process.
[0013] If, during the initial generation of operational shares, a whole signature key is generated, the whole signature key is destroyed after shares are distributed. Because the risk of loss from the theft or compromise of any one device is now greatly reduced, the information content of each signing device can be now duplicated (e.g., for remote backup or for a plug-in replacement or “hot” standby) so that if any device fails, it can be replaced (or reconstituted) and service can resume quickly. The consequence of subversion of any individual signing device is lowered, because the signing operation cannot be completed with a single device.
[0014] A multi-layered authorization management system is established, such that each signing device has registered within it a number of individuals (or external smart cards used by designated individuals), and the signing device participates in the signing operation only upon authorization from a quorum of registered individuals. A quorum of these individuals (called authorizing agents) are also required to authorize changes to the system, such as registering additional authorizing agents, deleting authorizing agents, altering the quorum requirements for any of the various actions that the signing devices can perform, or generating and distributing additional or substitute key sets.
[0015] In this way, a signature can be applied that can be verified using a public verification key, but no private signature key exists at a single location where it may be subject to compromise or catastrophe. Multiple sites must fail or be compromised before interrupting signing services or before an adversary acquires sufficient information to forge signatures. Individual signing devices need not be as be as highly secure for a CSU using a single whole key. A relatively inexpensive device meeting the standards of FIPS 140-1 level
[0016] An authorization delegation mechanism allows an authorizing agent to let a delegate, or quorum of delegates, authorize his smart card to affix his/her signature during temporary periods of time.
[0017] The invention will be described below with reference to attached drawings in which:
[0018]
[0019]
[0020]
[0021]
[0022]
[0023]
[0024]
[0025]
[0026]
[0027]
[0028] The most direct explanation of the multi-step signature method begins with a discussion of several relevant mathematical processes.
[0029] A. Multiplicative Scheme with Sequential Partial Signing
[0030] First, a secret signature key “K
[0031] where K
[0032] Second, a signature is formed using multiple devices by having each device exponentiate a partial signature left by a prior device, using one share ai of the private key. When using “modulo N” arithmetic (wherein an arithmetic operation concludes by dividing the result by a modulus N and taking the remainder as the modulo N result), the following relationship between multiplication of exponents and sequential exponentiation is true:
[0033] Stated another way, if a base value x is exponentiated by the product of two factors a1 and a
[0034] In the multi-step signature method, shares of a signature key a
[0035] A second device advances the signature by exponentiating the first partial signature using a second share a
[0036] The process repeats until “t0” devices have exponentiated the hash using each of “to” separate shares, to produce a final signature that can be verified using the public K
[0037] B. Additive Scheme with Asynchronous Partial Signing
[0038] An alternative way to accomplish a similar result involves dividing the private key of the signing authority into shares which can be added (modulo N) to yield the private key.
[0039] This in turn permits the multi-step signing to be performed an in an asynchronous manner by separately generating intermediate values (H)
[0040] This can have considerable operational advantages over the sequential method described above, because it is not necessary to route the message sequentially from one location to another. Instead, a central administrator can, in a straightforward manner, simply send the same message (or hash) directly to each location for partial signing, and then combine the resulting partial signatures to produce the final desired official signature. This final combining operation does not require any special security, because it does not add any information not already contained in the partial signatures, thus allowing the administrator to work from a desktop. Indeed, the partial signatures could conceivably be even be left for later combining by the recipient who verifies the transaction! This burdens the recipient with additional processing workload, but does not weaken the security of the official signature.
[0041] Signature schemes based on exponentiation which can be modified to permit multi-step signing include: R. Rivest, A. Shamir and L. Adleman (“RSA”), “A method for Obtaining Digital Signatures an Public Key Cryptosystems,” Communications of the ACM, v.21, n.2, pp.120-126, February 1978); D. Kravitz, Digital Signature Algorithm (“DSA”), U.S. Pat. No. 5,231,668; Desmet, Y. Frankel, “Threshold Cryptosystems,” CRYPTO '
[0042] System Overview
[0043]
[0044] In
[0045] Hereafter, encryption/decryption keys are designated as “KE,” while “KS” designates signature/verification keys. A plus (“+”) superscript indicates a public key, and a minus (“−”) superscript indicates a private key. Subscripts indicate the owners of the private keys of respective key pairs.
[0046] Groups of authorizing agents
[0047] In
[0048] Signing devices also receive the public encryption keys
[0049] For ease of explanation of the multi-step signature process which follows, it will be assumed that all communications on the network are encrypted using a standard Public Key Cryptosystem (“PKC”) scheme, such as RSA-key-transport. It will also be assumed that commands sent from one network entity to another are signed by the sender using a standard (PKC) scheme, such as RSA-signature with MD
[0050]
[0051] During the multi-step signing processes, a signing device
[0052] The message server
[0053] The message server can also provide a layer of protection, known as a “firewall,” that separately validates all transactional inputs prior to passing them on to the signing devices. Otherwise an “on-line” signing device accessible to a public network would be open to unlimited hacking attempts, as well as to network saturation attacks aimed at denial of service. Denial attacks may disrupt daily certificate issuance, but would not cripple users who rely on previously signed documents (which is the vast majority of the anticipated user population). However, hack attempts will always pose a threat, especially if hackers identify some hidden flaw. The message server can verify all messages against a list of authorized devices (signing devices and authorizing agents), as well as more complex strategies to identify possible attacks, deny access after a number of failed attempts, and undertake sophisticated actions to track down the source of any false data inputs. This will allow the signing device's firmware to remain simpler and easier to validate, while also allowing the system operators to modify their detection and evasion strategies in accord with the current state of network security.
[0054]
[0055] The human operators use their desk-top computers to read and generate messages. When a human operator wishes to sign a message, the desk-top computer sends the message to the trusted device, which appends a digital signature using the device private signature key. In the preferred embodiment, this signature is the signature of a second signature key pair which has been specifically generated for and certified as belonging to the specified user. In this manner, the system can continue to use the device's signature to verify the trust level of the device on any given transaction, while using the user's signature to attest to the user's identity and consent to the transaction. This allows the user key to be generated and revoked remotely, depending possibly on various administrative facts about the user's identity or authority, while also allowing the device to be reused, or to host several other user key pairs which the user may wish to use for other unrelated purposes.
[0056]
[0057] The signing device previously shown in
[0058] Devices in the network will be initialized in a series of stages as follows:
[0059] 1) encryption key distribution;
[0060] 2) signing device temporary certification;
[0061] 3) key share distribution;
[0062] 4) signing device recertification; and
[0063] 5) authorizing agent certification.
[0064] Each will be discussed in turn. Following the discussion of system initialization, the preferred methods of use for signing highly secure certificates and other documents will be explained, as well as further variations and enhancements.
[0065] Encryption Key Distribution
[0066] Each signing device, and each authorizing agents' smart card is assumed to be a “trusted device” in that it is a tamper-resistant device that functions only in accord with stated characteristics, and whose manufacturer has endowed it with a device signature key pair and a device encryption key pair stored in a protected memory. At a minimum, the manufacturer of such a device will attest that the device will not divulge either its own or its user's private key(s) without an expensive tampering effort. Each device also has an electronic certificate, signed by the manufacturer, containing: 1) the device serial number; 2) the device's public signature verification key; and 3) the device's public encryption key. The manufacture may install two separate certificates, one for the signature verification key and one for the encryption key. Signing devices encrypt their communications using a public/private cryptographic scheme. In the alternative, the method can proceed without manufacturer certificates by providing physical protection for all devices, such as conducting the initialization tasks in a secure vault where a small (notebook) computer is used in lieu of a trusted signing device.
[0067] It is assumed that each trusted device begins with certain basic functionality, such as software conferring the ability to initiate and receive messages through a network or an electronic mail system, that lets it communicate with other trusted devices. It is also assumed that at least one signing device, designated as the “lead” device, is capable of receiving information about the initial state of the system from human operators responsible for initializing the system.
[0068] The next step in preparing the system is for devices to exchange device keys. Key distribution proceeds as follows.
[0069] 1) One signing device, designated as the “lead,” receives from human operators the identities of other signing devices in the system. The lead device-sends its public encryption key and public signature verification key to the other signing devices. Optionally, the lead device may also send a message for validating the firmware under which it is operating, for example, by hashing its firmware, signing the hash value using its device signature key and sending the signed hash value to the other devices.
[0070] 2) After other signing devices receive the lead device's public encryption key, each other signing device sends its respective public signature verification key and public encryption key certificate(s) back to the lead device. If the lead device sent a hash of its firmware, each other signing device hashes its own firmware and compares the two. Both hashes must match, otherwise, the respective signing device stops participating in the protocol and notifies its operators. This comparison of hash values ensures that all signing devices use identical firmware, which acts as a check that the lead device is not an “impostor.” Each signing device optionally returns a hash of its respective firmware to the lead device.
[0071] 3) The lead device compares the hashes of the respective other devices' firmware against its own hash, which acts as a check that none of the other devices is an impostor.
[0072] All signing devices now have received public encryption and signature verification keys for the other devices. It will be understood that all future messages will be signed by the sender's private signature key and verified by the recipient using the sender's public verification key. It will also be understood that all communications will be encrypted using the recipient's public encryption key and decrypted using the recipient's private decryption key.
[0073] These additional signature keys are not used for multi-step signing (which will be discussed below), but are used instead for encrypting and signing routine communications among network entities as proof of a device's individual identity. Such proofs of identity and membership in the group are of critical importance when generating and distributing the master key fragments for use in the actual multi-step protocol.
[0074] Signing Device Temporary Certification
[0075]
[0076] 1) The administrator
[0077] 2) The administrator
[0078] 3) Each signing device
[0079] 4) The administrator signs each certification request using the administrator's private signature key.
[0080] 5) The administrator returns the signed signature key certificates
[0081] 6) The signing devices exchange their new temporary public signature verification key certificates among one another.
[0082] Each signing device now possesses: a) the administrator's public verification key; b) its own temporary private signature key; 3) its own temporary certificate, signed by the administrator and bearing the signing device's temporary public signature verification key; and 4) the temporary signature verification key certificates of the other signing devices. Each signing device can use the administrator's verification key to verify the administrator's signature on the temporary certificates received from the other signing devices.
[0083] Each signing device may now advance to a more tightly controlled phase of the protocol by exchanging messages using the signature keys that have been certified by the temporary administrator. For ease of explanation, it will be assumed that communications on the network involved in the multi-signature operations from this point until the end of device recertification are signed using a signature key that has been certified by the temporary administrator, and that each recipient verifies the sender's signature of the sender. If a message is not properly signed, the message will be rejected and the protocol will fail to continue unless a conforming message is supplied. It is further contemplated that some form of threat analysis or threat response may be undertaken when an improperly signed or unsigned message is received during the multi-step initialization and signature operations.
[0084] Authorizing Agent Temporary Certification
[0085]
[0086] The procedure for temporarily certifying authorizing agents is similar to the procedure above for temporarily certifying signing devices, and proceeds as follows:
[0087] 1) The administrator
[0088] 2) Each authorizing agent generates a private signature key certification request to the administrator
[0089] 3) The administrator signs each certification request using the administrator's private signature key.
[0090] 4) The administrator returns the signed signature key certificates to the respective authorizing agents.
[0091] Key Share Distribution
[0092]
[0093] a) The threshold parameters for splitting a key into shares, i.e., the total number of shares to be generated and the minimum number needed to affix the SWA signature.
[0094] b) A key identification number and/or logical name to be assigned to the public/private key pair, e.g., key serial number “KS-01234,” or logical name BT01.
[0095] c) Key share identification numbers and/or logical names to be assigned to the respective shares, e.g., “SWA-SHR-56789,” or “BT01.”
[0096] d) The device certificates of authorizing agents who will initially be permitted to authorize that particular signature for each device.
[0097] The human operators may additionally provide a number that limits the total number of fragments that can reside in a single signing device, which can be used when a signing device has multiple master keys as discussed more fully below.
[0098] The next step is to generate shares for a signature key, called the “system wide authority” (SWA) key, which will be used to administer the system. The public SWA public signature key and corresponding private SWA key shares are generated and distributed as follows.
[0099] 1) Each signing device
[0100] 2) The lead device
[0101] 3) The lead device
[0102] 4) The lead device
[0103] a) a type code identifying the key as a signature key share (also indicating the length of the share);
[0104] b) a unique identification code for the SWA public verification key;
[0105] c) a unique identification code for each respective SWA private signature key share;
[0106] d) the total number of SWA private signature key shares distributed;
[0107] e) the minimum number of SWA private signature key shares needed to complete a SWA signature;
[0108] f) the identities of signing devices receiving other SWA private signature key shares; and
[0109] g) certificates of authorizing agents who will be permitted initially to authorize use of each SWA private signature key share on the target signing device.
[0110] The lead device
[0111]
[0112] a) the whole private SWA signature key (if at any time during the generation process the whole private SWA signature key was stored); and
[0113] b) all shares of the SWA private signature key (except for one share which it retains for its own use).
[0114]
[0115] It is preferred that the private SWA signature key exist at most only in the lead signing device
[0116] At this stage, each signing device now additionally has securely received: a) a copy of the public SWA signature verification key; and b) a private SWA signature key share.
[0117] For the purpose of illustrating an example in the following discussion, it will be assumed (for the sake of simplicity) that the minimum number of shares n0 needed to affix the SWA signature is two out of five shares. It should be understood that a higher number may be chosen, most probably at least three, which will increase security, but which will also increase the number of steps in the signing process.
[0118] Signing Device Recertification
[0119] During previous steps of the initialization protocol, a temporary administrator
[0120]
[0121] 1) Signing Device
[0122] 2) Signing Device
[0123] (Note that in both text and drawings, a string of bits that constitutes a signature block is typically indicated by placimg a long dash in front of the signer's identifying label. The resulting block is typically appended to the bottom of the block of data that was signed, or is otherwise obvious from the context.)
[0124] 3) Signing Device
[0125] 4) Signing Device
[0126] The partial signature affixed by Signing Device
[0127] 5) Signing Device
[0128] In this example, signing devices
[0129] Recertification is important, because future operations performed by the full system of signing devices will preferably be performed only in response to requests from devices (e.g., of the authorizers, as discussed below) that have been certified by the SWA signature. Signing devices themselves may make requests to other signing devices. By this procedure, the signing devices themselves become the first devices certified by the system wide authority (SWA) as a whole, using the herein defined multi-step signature process.
[0130] In an alternative embodiment of the foregoing recertification process, the group of target devices might submit their recertification requests (unsigned certificates) prior to the initial key generation by the lead device. The lead device would sign these certificates at the time it creates the SWA private signing key prior to splitting it into fragments and erasing the whole key. There does not seem to be any major advantage in doing this, as the main function of the resulting system is to sign such certificates in a highly controlled yet efficient manner.
[0131] Authorizing Agent Recertification
[0132]
[0133] For purpose of illustration, it will be assumed that Signing Devices
[0134] 1) Authorizing Agent
[0135] 2) Signing Device
[0136] 3) Signing Device
[0137] 4) Signing Device
[0138] 5) Signing device
[0139] 6) Signing Device
[0140] The process is repeated for all authorizing agents
[0141] Multi-Step Signing
[0142] At this stage, signing devices have been initialized with shares of the SWA private signature key. Signing devices have recertified themselves, and authorizing agents have been both recertified and registered with their respective signing devices. The system is now ready to enter routine service for both system administration and official certification functions. In the following discussion, multi-step signing will be described for the system wide authority key, which typically will be used for system administration. As will be discussed below, additional “master keys” will also be generated and used for multi-step signing within the same family of devices, in the same way as for the system wide authority key, except that the content of messages to be signed by such master keys may not be administrative in nature.
[0143]
[0144] 1) Authorizing Agent la receives a request for a signature through the WAN/LAN. The request is an electronic message
[0145] 2) Authorizing Agent la (
[0146] 3) Authorizing Agent
[0147] 4) Signing Device
[0148] 5) Authorizing Agent
[0149] 6) Authorizing Agent
[0150]
[0151] In the example described above, two signing devices were necessary to affix the system wide authority signature, and each signing device required authorization from two authorizing agents. The total number of signing devices needed to complete a signature in the system may be adjusted at the time the key shares are generated, and threshold numbers of authorizing agents for each signing device may also vary. For example, it may require
[0152] After having established a multi-step signing process as discussed above, certain core administrative actions can be taken conditioned on the “assent” of a quorum of other signing devices as authorized by the presence of the system wide authority key. Some of these administrative actions are discussed below. To effectuate such actions and decisions, the firmware inside each tamper resistant signing device will be programmed to respond only to commands signed:
[0153] 1. in the case of partial signing requests, by a proper quorum of authorizing agents; and
[0154] 2. in the case of system administrative changes, by the systemwide authority itself.
[0155] That is, in the preferred embodiment, no changes can be made in the list of authorizers or related requirements on any signing device by other than the consent of a quorum of authorizers on a quorum of all signing devices. In some cases, it may be deemed unduly burdensome to obtain the consent of the entire system for certain minor changes, such as authority to perform encrypted backups. However, it is anticipated that such administrative changes will generally be relatively few and infrequent, in contrast to the volume of official business, and that the security of the system demands that such consent should be normally obtained in all cases. Note that in the example, only 4 human signatures were required to (re)certify and (re)register a user.
[0156] Parallel Signing
[0157]
[0158] In the parallel method, a document coordinator
[0159] The document coordinator
[0160]
[0161] In this example, two authorizing agents are required to authorize their respective signing device
[0162] Two other signing devices (not shown) affix partial signatures to copies of the document to be signed and return the signed copies
[0163] After the coordinator has received all three copies
[0164] The signing device and the smart cards of the authorizing agents will be trusted devices. The security of this parallel multi-step signing method does not depend on the physical security of the coordinator's workstation. The coordinator need not possess any secret keys for authorizing the signing devices (although it will likely have routing encryption and signature keys for privacy and identification purposes).
[0165] The functions of the coordinator may spread among authorizing agents. A first authorizing agent may receive the original document to be signed and designate another authorizing agent (or even another entity which is not an authorizing agent, such as a server for one of the signing devices) to receive and combine the partial signatures. It is expected that the normal operation of the organization will make it preferable to have the coordinator both receive the document to be signed, and then be responsible for delivering the signed document to its ultimate recipient.
[0166] Adding/Deleting Authorizing Agents
[0167] Each signing device has an associated group of authorizing agents. Because people come and go in organization, the system includes provisions to add and delete authorizers dynamically by adding and deleting the public keys of the authorizing agents' trusted devices. Adding, or deleting an authorizing agent is accomplished by submitting, to a signing device, a command to add or delete a public key of the agent. The command takes the form of an electronic message having a code for the add/delete command, additional information (discussed below) and authorizing signatures.
[0168] The authorizing signatures may be from other authorizing agents of the same signing device, and the add/delete process can be completed locally by a single signing device. In an alternate version, the add/delete procedure may require the signature of the system wide authority key, thus requiring quorums of authorizing agents on a quorum of related signing devices to approve and authorize the change. In yet another alternative, different authorizing agents may have differing capabilities, and some more powerful authorizers may be added or deleted under the system wide authority key, while less capable authorizers may be added or deleted locally under the authority of a local quorum. Preferably, the addition or deletion of authorizing agents requires the signature of the system wide authority key.
[0169]
[0170]
[0171] Add/Delete Card Manufacturers And Models
[0172] As discussed above, authorizing agents act through trusted devices, which may be smart cards manufactured with predetermined security properties. As a condition for adding an authorizing agent, the agent's trusted device must be of an approved model. During the initiation of the system, model numbers of trusted devices that would be acceptable for use in the system were input. Over time, new models will become available, and security procedures may be tightened such that older models may no longer be acceptable. All signing devices maintain an internal table of accepted models.
[0173] New manufacturers may be added by circulating an electronic request among all the signing devices to add a new manufacturer.
[0174] Old manufacturers may be deleted by circulating an electronic request, signed by the SWA key, to remove the manufacturer's public verification key from the tables of the signing devices.
[0175] New models for an already-approved manufacturer may be added by submitting an electronic request, signed by the SWA key, to add a new model.
[0176] Old models may be deleted by submitting an electronic request, signed by the SWA key, to remove the model from the tables of the signing devices.
[0177] Adding /Deleteting Signing Devices
[0178] Over time, it will be desirable to add or delete signing devices from the system. Each signing device contains a table of other signing devices in the system that hold shares of the SWA key (or shares of another master key for multi-step signing as discussed more fully below). The identity of each signing device is defined by: 1) the device identification number (e.g., serial number); 2) the device public verification key (installed by a manufacturer and certified under the manufacturer's signature, or a similar key recertified by the SWA signature); 3) the device public encryption key (used to send encrypted messages to the device); and 4) any subsequent certified public keys uniquely in its possession.
[0179] New signing devices are added to the system by circulating an unsigned certificate among other devices to receive the SWA signature and then circulating the signed certificate. The certificate contains the identifying information as discussed above. After the certificate has been signed by the SWA key, the certificate is sent to all other signing devices with an instruction to add the new device to the other signing device's internal tables.
[0180]
[0181] Copy Key Shares
[0182] The risk (consequences) of theft or destruction of signing devices has been reduced by virtue of the multi-step signing process and the fact that no single signing device is capable of forging a signature or divulging information sufficient to forge a signature. The information content of a signing device, including the SWA key share, can therefore be transferred to another device, e.g., when upgrading signing device hardware or for back-up purposes.
[0183] Copying of key shares and other information is accomplished by submitting a request, signed by the SWA key, to copy all or some of the information in a particular signing device to a second device.
[0184] Alternately, the information may be copied to a. storage device which is kept physically secure (e.g., stored in vault) and off line (not subject to remote attack) in encrypted form for use as backup.
[0185] Change Quorum Requirements
[0186] The quorum of signing devices needed to affix the SWA key is a system design parameter used by the lead device when generating key shares. This quorum can be changed by re-combining the key shares to recover the whole signature key, and then splitting the key into an increased number of shares which are then re-distributed as with the original key shares, but with a new quorum requirement.
[0187] The quorum of authorizing agents needed to authorize a particular signing device to affix a partial signature can be changed without reinitializing the system. Such a change preferably is accomplished by submitting a request to the respective signing device signed by the SWA key. Alternately, authorizing agents of a particular signing device may change the local quorum by submitting a request signed only by local authorizing agents. The number of signatures needed to change the quorum may be the same as or different from the number needed to authorizing the signing device to affix the SWA signature. Note that if SWA key shares are stored within signing devices in encrypted form and if authorizers hold decryption key shares as discussed below, the quorum needed for authorizing a signature should not be reduced to less than the number of shares needed to decrypt the SWA key share. In normal banking practice, the N of authorities must not be less than
[0188] Encrypting Stored Key Shares
[0189] In this variation, shown in
[0190] 1) combines the decryption key shares
[0191] 2) decrypts
[0192] 3) uses the plaintext SWA share
[0193] 4) erases the decryption key
[0194] 5) erases the shares
[0195] 6) erases
[0196] When sending a document to a signing device for signature, an authorizing agent includes that agent's share of the decryption key and signs the message. In normal operation, the decryption key shares are protected due to the fact that all communications on the network are encrypted using the public encryption key of the recipient (i.e., of another authorizing agent when a document is being circulated for agents signatures, or of a signing device when submitted for signing). Alternately, each authorizing agent may develop a session key for each message in order to protect the decryption key shares. (That is, each time a key-containing message passes from an authorizing agent to another authorizing agent or to a singing device, a new session encryption key is used.) The entire message is then encrypted under the session key.
[0197] In this way, the plaintext SWA key share exists only transiently during the time that it is being used to affix a partial signature. Furthermore, the decryption key, and a complete assembly of shares of the decryption key exist only transiently. If a signing device is stolen, thieves would at best be able to recover the encrypted form of the SWA key share.
[0198] The process for generating and distributing encrypted key shares and shares of decryption keys would proceed as follows and illustrated in
[0199] 1) The lead device generates a public SWA verification key
[0200] 2) The lead device generates a separate public/private encryption key pair
[0201] 3) For each private encryption key, the lead device splits the private decryption key into shares
[0202] 4) The lead device encrypts each share of the SWA signature key
[0203] 5) The private decryption key shares for the SWA key shares may also be escrowed (distributed for safe keeping) among the other signing devices such that any private decryption key can be recovered from the signing devices, but no one signing device contains enough information to recover any decryption key for another device. Such general shares for any given signing device would be released and upon consent of a quorum of authorities on several other SDs.
[0204] 6) The lead device erases the private decryption keys, the private decryption key shares, and the whole private SWA signature key (if it still exists) from memory.
[0205] When each signing device registers its respective authorizing agents, the signing device additionally sends each authorizing agent a decryption key share, identified by: 1) an identification number for the decryption key share; and 2) the identification number for the associated SWA key share.
[0206] For example, if there were five SWA signature key shares, (with three needed for a signature) and each SWA key share were encrypted under a separate public encryption key, and each SWA key share required three of five authorizing agents, then each decryption key could be divided into five shares with any three capable of recovering the decryption key. There would be twenty five decryption key shares, with each signing device having distributed five to its authorizing agents (for its own key) and holding one share of each of the decryption keys for the other four devices.
[0207] In this way, the quorum of authorizing agents needed to authorize a signing device to affix a partial signature will also have a sufficient number of decryption key shares to allow the signing device to decrypt the SWA key share transiently for each signing operation.
[0208] If one or more of the authorizing agents lose their keys (e.g., loose their trusted device smart cards), then new smart cards would be registered on the same signing device. The decryption key shares could be recovered from other signing devices and could be reinstated to the newly-registered smart cards by submitting an electronic message, signed by the SWA signature key, for the signature devices to transfer shares of the decryption key to the newly registered devices. As an alternate method, subject to the consent of the SWA, a given device could receive all description shares, decrypt its signing share, generate a new encryption key pair, reencrypt the signing share under the public key, divide the new private decryption key into new shares and redistribute these shares to the trusted devices of the relevant authorities, taking care to encrypt them under the public encryption keys of those receiving authorities'trusted devices.
[0209] As an alternate back-up method, up the decryption key shares can be escrowed off-line with an independent trust institution as described in copending U.S. patent application Nos. 08/181,859 and 08/277,438.
[0210] Cryptographic Heartbeat
[0211] As a further protective measure, each signing device receives a periodic data input (“heartbeat”) which, if interrupted, causes the signing device to become deactivated. The heartbeat would be generated from a location separate from signing device so that, if thieves attempt to steal a signing device, they must also penetrate a separate room or vault to get the heartbeat source. If they fail to acquire the heartbeat source, the signing device becomes inactive and is useless.
[0212] In one implementation, each signing device provides an encryption key to a heartbeat source. The heartbeat source periodically sends encrypted messages to the signing device. If the signing device fails to receive a minimum number of messages over a period of time from the heartbeat source, then the signing device erases its internal memory or takes other evasive action. The messages may be empty messages or simple messages, which must be encrypted by the heartbeat source using the public even key given to it by the SD. Alternately, the messages could be a pseudo random string generated in the heartbeat source by a pseudo random number generator (RNG) and verified by a synchronized (RNG) in the signing device.
[0213] Multiple heartbeat sources could be established so that a signing device must receive messages from at least one (or a minimum number) over a period of time. If one heartbeat source goes off line due to equipment failure or power outage, it will not trigger premature erasure of signing device memories Keys used in heartbeat communications may be backed up in shares to multiple locations.
[0214] In a second implementation, each signing device may send a query to a group of associated (“satellite”) devices on the network, and continue operation only if at least a quorum of associated devices responds. Requiring a quorum allows operations to continue during inevitable outages and repairs to communications.
[0215] Use of satellite devices, while more complex, adds physical security and can be used at locations having less secure environments, rather then upgrading these facilities with vaults, guards, cameras, etc.
[0216] The communication link between a signing device and its heartbeat source or satellite device may be a public network. If a signing device is reported stolen, its associated satellite units can be deactivated by the system operators to prevent thieves from tapping communication lines and re-routing the heartbeats to the stolen device.
[0217] For example, the signing device may be in the United States and its associated satellite device in Europe. When the signing device is stolen, the European satellite device is taken off line by its operators. Liability of the European agent for any erroneous action would be minimal, because the removal of the satellite only interferes with new signing operations for a short time. Previously signed signatures remain in force Alternately secure physical wiring can be provided between a signing device and its satellite or heart-beat source in lieu of a public network.
[0218] Generating Additional Master Keys
[0219] Having established a secure, multi-step signing system with a SWA key, it is a simple matter to generate a number of additional “master” keys to be used for other purposes. While the SWA signature key controls system administration, master keys can be used to sign other certified messages or documents by use on behalf of other legal entities. The generation and administration of other master keys is similar to the SWA key but without intermediate temporary certification steps. The method proceeds as follows:
[0220] 1) Designate one signing device as “lead” (it need not be the same “lead” that generated the SWA signature key.
[0221] 2) Input a list public key certificates of signing devices to receive shares of the master key.
[0222] 3) Input an identification code for the master key and a logical name.
[0223] 4) Establish secure communication channels among signing devices (preferably using the encryption key certificates of each related signing device).
[0224] 5) Optionally obtain random material from each signing device.
[0225] 6) Generate a new “master” public private key pair.
[0226] 7) Distribute private keys shares (optionally encrypting each share and distributing shares of decryption key).
[0227] 8) Erase the whole master private key (if it was stored), and erase all shares not retained by the lead signing device.
[0228] This process may also be used to replace the SWA signature, by additionally sending each signing device a command, signed by the (old) SWA signature key to install the new master key as the SWA signature key. Generally, the master key will have separate uses from the SWA key and the shares of many master keys may coexist in the signing devices. A previously generated master key (other than a SWA signature key) can be deleted from the system by submitting a message, signed by the SWA signature key, to delete the master key fragments.
[0229] Document And Signature Tracking
[0230] It is desirable to assign a unique identification code to each document to be signed in order to assist in managing the flow of documents through the system. The following information may be included in the headers of each document for use by message servers and authorizers:
[0231] 1) The signature key identification code of the key to be used to sign the document.
[0232] 2) The total number of partial signatures needed to complete the signature and/or the number of partial signatures already applied.
[0233] 3) The key fragment identification codes that have already been used to sign.
[0234] 4) The identities of the signing devices that have already signed (e.g., the logical device names).
[0235] Interlocking Rings of Signing Services
[0236] A root CA, using a multi-step signing system as described above, will generally certify subordinate CAs located in other business and government organizations. Hypothetically, a large money center bank might certify a major agency of a state government. The state agency, in turn, might certify a corporation. This distributes the certification process flexibly in a way which can conform to existing political, economic and social organizations.
[0237] However, each mid-tier CA must maintain strong security over its signature key. Few such organizations, other than banks, some large corporations, and some government agencies, have traditionally maintained multiple highly secure data processing facilities and storage vaults. For example, a mid-tier CA may possess at least one nominally secure physical location, such as a data center or vault operation, but lack the funds to serve multiple sites for the multi-device schemes described above. In the alternative, the mid-tier CA may have no truly secure location.
[0238] Less secure mid-tier CA's (such as a corporate CA) may nevertheless set up their own signature-rings (as described above) and interlock these mid-tier rings with the more highly secure ring of a parental CA (such as a bank or secure government agency). This can be done while separating the issues of: (1) key ownership and official control, (2) administrative and backup responsibility, and (3) physical possession of the devices.
[0239] An interlocking ring architecture can be created as shown in
[0240] The mid-tier CA initiates the key generation and share distribution protocol outlined above using one of its own signing devices as a “lead” device, and authorizes its own officers as authorizing agents
[0241] Thereafter, the mid-tier CA would initiate multi-step signing of the CA's signatures based on signatures generated by smart cards possessed by their officers, and route those requests to their own signing devices and/or to devices in the possession of the parent CA. Indeed, signing devices need not be located with the parent CA, but could be sited at any other CA also having a secure location and communication access.
[0242] Fully Leased Services
[0243] An organization that does not possess even one secure facility might still wish to generate certificates and can still become a CA. The organization can lease use of signing devices located in secure locations already established by various banks or other CAs. The organization takes possession of smart cards for its authorizing agents, and routes signing requests to signing devices through a communication network. The processes of generating keys, issuing signatures, and performing other administrative tasks can therefore occur within devices under local bank physical control in accord with contractual trust arrangements with the owner.
[0244] The organization's officers would go to the local secure (banking) facility to witness the key generation protocol by which their new signature key is created, divided, and distributed to each of a number of host facilities (possibly other banks or other locations of the same bank) that they have selected. At that time they could also assign the appropriate administrative backup powers as needed.
[0245] The organization could then issue official signatures and certifications, without the need of establishing their own secure data center or vault facilities, while still achieving substantially all the security benefits of the system as described.
[0246] Signature Delegation
[0247] When an authorizing agent becomes temporarily unavailable (due to being on vacation, incapacitated, etc.), some form of delegation of signatory authority is desirable. It is undesirable for a human operator to loan his/her smart card-and an associated pin number or key-to another, because that creates an un-managed security risk.
[0248] One alternate delegation mechanism is for an original authorizing agent (“primary user”) to issue a specialized “delegation” certificate to a substitute authorizing agent (“delegate”). The certificate, signed by the primary user, would identify the delegate and the delegate's public signature verification key. The delegation certificate would also contain a time limit during which the delegation certificate (and hence the delegate's authority) would be valid. (See Sudia & Ankney, “Commercialization of Digital Signatures,” 1993.) A delegate, using his/her personal smart card, would sign a document using the delegate's personal signature key and would attach the delegation certificate. Resulting documents would be signed by the delegate, not the primary user, and a document recipient must undertake additional steps to verify the delegate's signature and the delegate certificate. This relies, in part, on an ability for all public users of a system to have such verification capability and, to have good access to a source of revocation information (or “hot list”), in case the authority must be cancelled before it expires A preferred approach is to allow a delegate to use the primary user's smart card in a secure way that, in effect, substitutes the human delegate for the human primary user vis-à-vis the primary user's smart card. Then, the delegate would use the primary user's smart card to affix the primary user's signature, and the universe of document recipients is spared the additional burden of verifying and evaluating another complex certificate.
[0249] When the primary user wishes to delegate signatory authority, the primary user issues a “substitution” certificate
[0250] As shown in
[0251] The primary user's smart card
[0252] For example, a primary user might be a vice-president in charge of purchasing, who wishes to delegate his specific signature authority to his secretary while he travels to negotiate a pending deal. The substitution certificate might specify that his smart card is to issue the vice president's signature only upon receipt of a signature request signed by: (a) the secretary, as designated by-his substitution certificate; and (b) co-signed by any other person with primary signing authority in the purchasing department. The vice-president places his card in a card reader in a locked vault and leaves.
[0253] To obtain the vice-president's signature, the secretary would prepare the document to be signed and compute its associated hash using her desk-top computer terminal. She would then sign the hash, attach the vice-president's public key certificate, the final recipient will need it and then send them in a message to another purchasing agent. The other purchasing agent co-signs the same hash and attaches his public key certificate, along with his authorization certificate which grants him his purchasing authority. The other purchasing agent sends them in a message to the vice-president's smart card through a local area network. Given that the vice-president's card also contains trusted copies of the public keys of the certifying authorities which created these certificates, such as the SWA, the vice-president's card determines that the signatures and certificates are all valid and affixes the vice-president's signature to the document. The card might also request that all these certificates be accompanied by recently signed CRL's or certificates of good standing from a locally recognized CRL handler.
[0254] This delegation mechanism takes advantage of an ability to re-program the primary user's smart card. The primary user's smart card is trusted device having known security characteristics, one of which must be a capability to engage in a secure download of new instructions (e.g., substitution certificates), as described for example in co-pending U.S. patent applications Nos.08/181,859 and 08/272,203 (Sudia key escrow parent and Sudia key escrow CIP).
[0255] The foregoing delegation mechanism may be generalized such-that many high-value end-user digital signature keys are in fact generated and used within tamper resistant secure modules (TRSMs) that are stored inside secure vaults or data centers, while the authorization for such signatures comes from signature request messages signed by approved users who are given unofficial (time locked) smart cards to carry around with them. These TRSMs would remain secure against tampering, to prevent any data center personnel from ever having access to user private keys, but could be designed to contain the keys of many different users, each of which might be authorized to act based on some single non-official signature, or some prearranged combination of signatures and authorizations.
[0256] Another use for the delegation mechanism, apart from simple delegation from users on temporary leaves of absence, would be a system or method whereby such a programmatic signature request would be made to a card (or to a key contained with a common TRSM) to perform the signature of a major “desk” or other role within a financial or corporate environment.
[0257] After learning of the embodiments described above, people practicing in this art will be able to make variations that fall within the spirit and scope of the invention. The embodiments described above are exemplary but not intended to limit unduly the scope of the invention as defined by the following claims.