MXPA97009760A - Method of digital signature multi-stages and system - Google Patents

Abstract

The present invention relates to a digital signature method, characterized in that it comprises the steps of: generating portions of a private signature key, storing the portions in separate electronic signature devices, certifying multiple authorization agents for the signature devices, and for each of a plurality of signature devices, set a partial signature to an electronic message in response to authorization from a minimum number of authorization agents, wherein a plurality of partial signatures constitute a digital signature.

Description

METHOD OF DIGITAL SIGNATURE MULTI-STAGES AND SYSTEM BACKGROUND Certificates with a public key are electronic documents signed by a trusted issuer and used to certify the union of a user name with a public key and other related data. Certificates provide security to the public that the public key identified in the certificate is owned by the user whose name appears on the certificate. The main standards that describe public key certificate systems include the ITU-T X.509 of The Directory-fluthentication Framework, The American Bankers Associations ANSI X9.30- Part 3: Certify Management for DSA (draft). Many embodiments have a hierarchical structure in which each trusted issuer, referred to as certification authority (CA), certifies keys for entities that are subordinate to it. The CA fixes a digital signature to an electronic document in a verifiable way (one can prove that the CA signed the document) and that it can not be falsified (one can be sure at a high level of confidence that no one other than the CA signed a document ). For example, at the top of the CA hierarchy there may be relatively few root CAs, perhaps one per country which certifies subordinate CAs. Below the root CA in the hierarchy, high level CAs (perhaps banks) certify low level CAs below them (eg companies), which in turn sign individual user certificates. A CA signature becomes more valuable insofar as it creates a large hierarchy of users below it and uses its signature key to sign the certificates of both high-value users and subordinate CAs. The CA signing key then also becomes likely target of terrorists, criminals inclined for economic gain, and foreign military and espionage services inclined by economic espionage or the destabilization of the economy via war information. All these issues also apply with equal force to the keys used to sign electronic representations of currency. With this scope, the security need for a private CA signing key has been directed to provide a "certified signature unit" (CSU), which is a secure tamper-proof module that meets the standards set by the standard. Federal Information Processing System (FIPS) PUB 140-1, Level 3 or 4 as published by the United States Department of Commerce, the National Institute of Standards and Technology (NIST). Such a CSU generates its pair of public / private signature keys internally, "confines" the private signature key securely and permanently within an area of the device that can not be read externally, and given only the corresponding public key, the which will be used to verify your signatures. A CSU available from Bolt, Baranek and Newrnan of Boston, MA (BBN) is configured to allow a compilation version of its private signature keys to be created using a "K-of-N threshold" scheme, in which the key Private is divided into N parts and located in small plastic data keys, each of which contains a memory chip. The data keys are a product patented by Datakey, Inc. of Burnsville, MN. Then, if the CSU device is destroyed, a quorum of at least K data keys can reconstruct the private key. At least one larger standard security body, the Committee of the Association of American Bankers ANSI X9.F1 for cryptographic security in banking applications of all types of sales has recommended that the CSU should be designed to prohibit any export of private keys from the device in any way in order to avoid any possible theft and use of the unauthorized 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 in a single site, the loss of a CSU or a site would force the CA to use another pair of keys in order to continue the business. This would require that the CA publish and / or distribute in a secure manner several (at least 2 or 3) public keys, each identified by a different code number (example BT01, BT02, BT03), so that the users could continue with the verification of the signatures that the CA will publish after the CSU (possibly containing the private key for BT01) has been destroyed. See part X9.30 3 concerning procedures for disaster recovery.

BRIEF DESCRIPTION OF THE INVENTION An object of the present invention is to provide a digital signature system ("signature system") for certificates and other high value documents (including contracts, electronic currency representations, negotiable documents, etc.) with improved security and flexibility. A further object of the present invention is to provide a signature system in which a digital signature is verifiably related to a signature key and in which no signature device containing the signature key is required during the operation of signature of the document. A further object of the present invention is to provide a signature system which allows for losses or commitments of one or more signature devices while remaining available, signature services not committed. A further object of the present invention is to provide a signature system in which multiple signature devices each create, modify or combine one or more partial signatures, and the result of operations by means of multiple signature devices produces a digital signature only. A further object of the present invention is to provide a signature system in which multiple agents authorized directly or indirectly authorize each individual signature device to sign or modify a partial signature. A further object of the present invention is to provide a robust and user-friendly mechanism in which the authorizing agents can temporarily delegate their authorization capacity. The multi-stage signature system described here uses a public key cryptosystem to sign a document in such a way that a recipient of the document can verify the signature using a public verification key of the signer. The private signature key that corresponds to the public verification key is not allowed to exist in full form, available in one place at any time during normal signature operations. In contrast, a private signature key consists of "operational parts" which can be used to set or modify a partial signature, and a sequential multi-part operation produces a signature that can be verified using the public verification key. The complete signature is not completed until all, or some quorum, signature devices have signed. Each of the signature devices requires authorization from all, or a quorum of its associated authorization agents before participating in the signature process. If, during the initial generation of the operational parts, a complete signature key is generated, the composite signature key is destroyed after the parts are distributed. Because the risk of loss due to theft or compromise of any device is now greatly reduced, the information content of each of the signature devices can now be duplicated, (for example by remote collection or by a connection replacement). or wait "hot") if any device fails, it can be replaced, (or reconstituted), and the service can resume quickly. The consequence of the subversion of any individual signature device is diminished, because the signature operation can not be completed with a single device. A system of authorization management ult -laps is established, in such a way that each of the signature devices has registered within it an individual number (or external smart cards used by designated individuals), and the signature device participates in the signature operation only until the authorization of a quorum of registered individuals. A quorum of these individuals (called authorization agents) is also required to use the changes in the system, such as the registration of additional authorization agents, deletion of authorization agents, alteration of the quorum requirements for any of the various actions that the signature devices may develop, or the generation and additional distribution or replacement of key groups. In this way, a signature can be applied in such a way that it can be verified using a public verification key, but without a private signature key in a single site where it can be subject to compromise or catastrophe. Multiple sites must fail or be compromised before the interruption of signature services or before an adversary acquires sufficient information to forge signatures. Individual signature devices do not need to be so highly secure for a CSU that uses a single complete key. A relatively inexpensive device that complies with FIPS 140-1 level 3 standards can be used (for example, a device that is resistant to violation), thus avoiding the need to use a relatively expensive level 4 device (the which takes active measures to destroy or safeguard internal information when a violation is detected). An authorization delegation mechanism allows an authorization agent to allow a delegate or quorum of delegates to authorize their smart card to fix their signature for temporary periods of time.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will be described below with reference to the accompanying drawings in which: Figure 1 illustrates a view of the basic architecture for the operational signature system according to the present invention; Figure 2 shows a preferred architecture for the data center that has a signature device; Figure 3 illustrates a preferred architecture for a trusted device used by an authorization agent; Figure 4 illustrates a process for temporary certification of uninitiated signature devices, during system boot and imcialization; Figure 5 illustrates a process for the generation and distribution of operational parts of a key of broad system authority; Figure 6 illustrates a multi-stage signature procedure for recertification of a signature device; Figure 7 shows a total architecture of the system for the certification and registration of authorization agents; Figure 8 illustrates a multi-stage signing procedure using authorization agents; Figure 9 illustrates the flow of a document through various authorization agents and signature diepoeitives during the routine of multi-stage signature operations; Figure 10 illustrates the evolution of the signature in a document during the routine of the signature operations ulti-stages. Figure 11 illustrates the flow of a document during a parallel mode of the multi-stage signature system. Figure 12 illustrates the processing of one of the coplas, and the combination of the three partial signatures in the signature of broad authority of the system. Figure 13 illustrates a command to delete an authorization agent. Figure 14 illustrates a command to add an authorization agent. Figure 15 illustrates a sample request with a command to add a manufacturer. Figure 16 illustrates a sample request with a command to suppress a manufacturer. Figure 17 illustrates a sample request with a command to add a model number. Figure 18 illustrates a sample request with a command to delete a model. Figure 19 illustrates a sample instruction that includes a command to add a signature device. Figure 20 illustrates a message for removing a signature device.

Figure 21A illustrates a sample request for a sending device to copy the public key (s). Figure 21B illustrates a sample message of a sending device for a receiving device. Figure 22 illustrates a process for encrypting stored key parts. Figure 23 illustrates a process for the generation and distribution of encrypted key rings and decrypted key parts. Figure 24 illustrates an architecture of unlocking rings. Figure 25 illustrates a process for issuing a substitution certificate to delegate signature authority.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES The most direct explanation of the multi-stage signature method begins with the discussion of several relevant mathematical processes.

A. Multiplicative Scheme with Partial Sequential Signature First, a secret signature key "KSWA" of a public / private key pair belonging to a "system-wide authority" is represented as number ("nO") of parts ("ai" ) so that the signature key KSWA can be calculated as a product of any threshold number ("tO") of parts, where tO is less than or equal to nO. The representation is made in such a way that it is difficult or impossible to recover the KSWA signature key when they have it in other parts. This can be fulfilled by means of, for example: 1) using a secret parts scheme of the Sharnir type (A. Sharnir, "How to share a secret," ACM Communications, Nov. 1979, V.22, n.ll) , 2) using a secret parts scheme of the Blakley type (GR Blakley, "Cryptographic Keys of Safeguarding," Procedures of the National Computing Conference, 1979, American Federation of Information Processing Societies, v. 48, 1979, p. 242-258); 3) Factoring the key; or 4) generating the key co or a product of known factors. All that is necessary is for the private key to be represented as: K- SWA = ai * a2 *. . . ato (mod 2N) where K-SWA is a signature key and ai is any combination of parts tO. Second, a signature is formed using multiple devices as each device has to exponentiate a partial signature left by the previous device, using a part a of a private key. When an arithmetic "N-module" is used (where the arithmetic operation concludes by dividing the result by a module N and taking the rest as the result of the N module), the following relationship between the multiplication of exponents and the sequential exponentiation is true : (? «?» 2) (mod N) = ((? * 2) a2) (mod N) = ((X «2)« i) (rnod N) set in another way, if a base value x is exponentiated by the product of two factors a and a2, the result is the same as if the base were exponentiated by a first factor a, and that result exponentiated by the second factor a2. In addition, the order of exponentiation can be reversed, so that the result will be the same if the base is first exponentiated by the second factor a2, and that result exponentiated by the first factor a. This relationship can be generalized to exponentiation by three or more factors. Unless otherwise stated, all arithmetic operations should be considered as modulo N. In the multiply signature method, the parts of a signature key a, a2, ... ano are distributed to separate the devices. A first device fixes a partial signature on a document when redoing the document (the symbol "H" will be used to designate the result of the reworked operation) and exponentiate what was redone as: first partial signature = (H) »? (rnod N) A second device advances the signature by exponentiating the first partial signature using a second part a2 as: partial second partial = ((H) *?) * (mod N) The process is repeated until "tO" devices have I exponentiated it by using each of the "tO" separate parts, to produce a final signature that can be verified using the public K- -SUA.

B. Additive Schema with Partial Asynchronous Signature An alternative way to accomplish a similar result involves the division of a private key from the authority that signs in parts that can be added (module N) to produce the private key. K = ai + a2 + ... at (rnod N) This in turn allows the multi-stage signature to be developed in an asynchronous way by separately generating intermediate values (H) *? by exponentiating it remade by each of the parts, and then multiplying the result of the intermediate values, + the horn follows: S = H «i * H * 2 ... H» 3 (mod N) This may have considerable operational advantages over the sequential method described above, because it is not necessary to route the message sequentially from one site to the other. Instead, a central administrator can, in a very direct way, simply send the same message (or redone it) directly to each site for partial signature, and then combine the resulting partial signatures to produce the desired final official signature. This final combination operation does not require any special security, because this does not add any information not already contained in the partial signatures, thus allowing the administrator to work on s? desk. In this way, partial signatures can conceivably be left for later combinations by the receiver who verifies the transaction. This loads the receiver with an additional processing workload, but does not break the security of the official signature. The schemes of signatures based on exponentiation that can be modified to allow multi-stage signatures include: R. Rivest, A. Sharnir and L. Adle an ("RSA"), "A method for obtaining digital signatures and crypto-signatures. public key ", ACM Communications, v.21, n.2, pp. 120-126, February 1978); D. Kravitz, Digital Signature Algorithm ("SA"), U.S. Patent No. 5,231,668; Desrnet, Y. Frankel, "Threshold cryptosystems", CRYPTO "89, pp. 307-15, 1989, Taher El-Garnal," Criptosistemae of public key and Signature schemes based on discrete logarithms "(" Algorithm of signature of El -Gamal "), IEEE Transactions on Information Theory, Vol. IT-31, No. 4, July 1985, S. Micali," A Secure and Efficient Digital Signature System, "MIT / LCS / TM-501, Massachusetts Institut ? te of Technology, Laboratory for computer science, March 1994, A. Menezes et al., "Elliptic curve public cryptoclave systems", 1993.

REVIEW OF THE SYSTEM Figure 1 illustrates a general idea of an architecture for a signature system in accordance with the present invention. The architecture includes multiple signature devices, 11, 13, 15, 17, 19 interconnected by means of a wide area network (UAN) or a local area network .5 (LAN) 21. The individual signature devices 11, 13, 15, 17, 19 are geographically distributed as widely as UAN / LAN allows, such as on separate continents, separate cities or on separate parts of an area. Unique technology. In Figure 1, the signature device 2 has been illustrated in great detail as an example. Each permanent device is assigned a permanent identification code (example, unique serial number) and a logical name (example, "Signature X device"), together with a pair of public / private device keys 12a, 12b, to encrypt / decrypt communications and a pair of keys of public / private device 14a, 14b, to verify, make signatures. In addition, each of the devices receives the public encryption keys 16 and the public verification keys 18 for all other signature devices. In the following, the keys of encpptamiento, desencpptamento are designated as "KE", while "KS" designates the keys firrna / verification. A super-written ("+") indicates a public key, and a minus ("-") super-written indicates a private key. The super-writes indicate the owners of the private keys of the respective key pairs. The groups of authorization agents 23, 25, 27, 29, 31 are also interconnected through network 1 to each other and to signature devices 11, 13, 15, 17, 19. Each authorization agent is a person acting through a reliable computer (such co or a tamper-resistant smart card, or other reliable device) as it will be discussed further cornplet menté forward. The authorization agents may be provided in the full extent of the LAN / UAN 21, but the authorization agent groups will be located in close proximity to the corresponding signature devices most of the time for the convenience of managing the authorization. the organization of the signature system. In Figure 1, the authorization agent 2a (item 25) has been illustrated by means of an example and using the same annotation for the keys eegun ee discussed above in relation to the keys maintained by the signature device 2. Each of the trusted devices of the authorization agents has assigned them a unique name, along with a pair of public / private device keys 20a, 20b for encryption / disapplication communications and a separate public / private device key pair. private 22a 22b for verification / realization of signatures. If a RSA public key cryptosystem is used, then one such pair could be used for both signatures and encrypted at the same time. Authorization agents also receive public access keys 24 and public verification keys 26 from all other authorization agents. The signature devices also receive public encryption keys 24 and public verification keys 26 for all authorization agents.

Similarly, reliable dietary information of authorization agents receive public encryption keys 28 and public verification codes for all IRNA devices. For an easy explanation of the multi-stage signing process that follows, all communications over the network are encrypted using a standard public key crypto system ("PKC"), such as the RSA-key-traneport. It will also be assumed that the commands sent from one entity in the network to another are signed by the sender using a standard scheme (PKC), such as the RCA signature with acceptance of the MD5 message. In future designs, the encryption / decryption keys of the device, and the signature / verification keys of the device may be omitted, but should be understood as present in all devices as discussed above. Figure 2 shows a preferred architecture for a secure data counting center configuration 48, where each of the signature devices of Figure 1 will preferably be found. In addition to a signature device 39, each of the data center configurations 48 additionally contains a separate message server 47. The signature device 39 is dedicated to the signature operations and is located at a physically secure site, such as a vault. There is no direct connection between the signature device and the external computer network. As will be fully discussed below, the signing device 39 will be provided with a key part for the multi-stage signature 36, eu's own signature key for the device 37, the table 38 that identifies the authorization agents, and a certificate for its public verification key 40, a public key chosen to match its key part 36, where the certificate is signed by the complete KSSWA via a multi-stage method). During the multi-stage signature processes, a signing device 39 will receive the requests through a message server 47. The message server develops the routine communication processes, such as private stripping envelopes which have been fixed by the intermediaries (server 47 does not have the private decryption key of the signature device), and queuing the entries in case they are presented faster than they can be processed. The message server presents messages to the signature device to be signed, receives the signed (or partially signed) result, and (returns the partially signed result to the requester, or (b) enroutes the result to the next device in the protocol. In order to receive and participate in ordinary communication protocols, the message server also has a public / private key pair 32, 33 to sign its own messages, and another 34, 35 for encryption, in order to enable it to receive and open encrypted messages thus releasing the signature device from its routine load without significantly affecting the security of the secure signature process.The message server 47 may be a comparatively less secure computer in a lower security environment such as a secure data center. Secure ordinary data The message server 47 connects to the LAN / UAN 21 and provides a queue of documents and communication services to the device. Signatory time 39. The message server 47 includes a system record 49 that maintains an audible track of messages and documents sent to and from the signature device. As shown, a signature device and its associated message server are preferably divided into two physically separate computers. Although less preferable, the signing device 39 and the message server 47 could be structured as separate tasks or a single computer in a highly secure environment. The message server can also provide a protection layer, known as a "wall of fire", which separately validates all transaction entries before they are passed on to signature devices. On the other hand, an "online" signature device accessible to the public network would be open to unlimited attempts, as well as network saturation attacks the purpose when delegating the service. Attacks from denial can disorganize the certified issue on a daily basis, but it will not paralyze users who trust the documents previously signed (who is the vast majority of the population of prospective users). However, attempts to cheat will always have a threat, especially if those who cheat identify some hidden flow. The messaging server can verify all the messages against a list of authorized devices (signature devices and authorization agents), as well as complex strategies to identify possible attacks, deny access after a number of unsuccessful attempts, and take sophisticated actions. to trace the source of any false data entry. This will allow the signature structure of the signature device to remain simpler and easier to validate, while also allowing system operators to modify s? Detection and evasion strategies according to the current state of network security. Figure 3 illustrates a workstation for authorization agent. Human operators who act as authorization agents can work in relatively insecure areas on desktops or terminals 51 typically found in a business office. Each such computer or terminal will have a card reader 53, and each operator will have a "secure" smart card 55. Each smart card 55 securely contains a private decryption key and a private signature key which is unique to the smart card The human operator can use the card to issue signing instructions. Such a reliable device can be implemented using a FIPS level -3 device, such as a Power Card from National Semiconductor Corp. of Santa Clara, CA, which can be easily reprogrammed at the signature structure level to allow for the progressive return of new methods and procedures in order to ensure signature and authorization without the need to replace physical devices. Each of the trusted devices of the authorization agents must have at least one private signature key. Preferably, the private signature key is installed in the device at the manufacturer's time, and the corresponding public verification key is "certified" by the manufacturer. The certification here means that the manufacturer has ided, with the reliable device, an electronic message containing the serial number of the device and the public key, along with the number of its model and other evidence of its reliable characteristics, and that message , certificate, has been signed by the manufacturer. Human operators use their desktop computers to read and generate messages. When the human operator wishes to sign a message, the desktop computer sends the message to the trusted device, which adds a digital signature using the private signature key of the device. In the preferred mode, this signature is the signature of a second for signature keys that have been specifically generated and '? ? certificates as belonging to the specified user. In this way, the system can continue to sign the device to verify the level of reliability of the device on a given tranection, while using the user's signature to certify the user's identity and consent to the transaction. This allows the user's password to be remotely generated and revoked, possibly depending on several administrative facts about the identity of the user or authority, while also allowing the device to be reused, or accepting several other user password codes. which the user may wish to use for other unrelated purposes. Figure 3 also illustrates a preferred architecture for a possible reliable device to be used by an authorization agent. This comprises a single micro chip inserted into a card in a configuration known as a "smart card". The micro chip device has an input / output circuit 42 for power and communications, and a microcontroller 44 for executing the programs of the signature structure. The memory 52 contains systems of the signature structure 43 for operating the micro chip equipment (similar to a single operation system). The memory 52 also includes areas for storing device keys installed by the manufacturer 45, user keys 47 received as part of the protocol described here, and application structure 49 for executing the network protocols described herein. An unused memory is provided as a work area 54 for temporary storage as required. The micro chip may also include an "optional unit" 46, which is a special arithmetic accelerator unit that has equipment to develop an accelerated exponentiation and other arithmetic operations of encryption / deenciphering and signature procedures. The micro chip also includes a reliable optional watch 48 (assuming the presence of a battery of adequate energy) initial hoisted by the manufacturer and useful for the firms stamped in time. It also includes an optional random number generator 50 to be used with the encryption / de-enrollment processes. The smart card may also include an optional noise source (not shown) such as a diode, which may be internal or external to the micro chip, for use in the generation of random numbers. The signature device previously shown in Figure 2 can also be a smart card which has the same general design as the trusted devices of the authorization agent. The devices in the network will be initialized in a series of stages as follows: 1) Distribution of the encryption key; 2) Temporary certification of the signature device; 3) Temporary certification of the authorization agent; 4) Distribution of the public key; 5) Recertification of the signature key; and 6) Certification of the authorization agent. Each one will be discussed in turns. Following the die-off of system initialization, the preferred methods of use for highly secure signature certificates and other documents will be explained, as well as variations and improvements.

DISTRIBUTION OF THE ENCRYPTION KEY Each signature device, and each smart card of the authorization agent is assumed to be a "trusted device" because this is a tamper-resistant device that operates only according to the established characteristics, and whose manufacturer has provided it with a pair of device signing keys and a pair of device encryption keys stored in a protected memory. At a minimum, the manufacturer of such a device will certify that the device does not disclose its private keys or those of the user without an expensive violation effort. Each device also has an electronic certificate, signed by the manufacturer, containing: 1) the serial number of the device; 2) the verification code of the public signature before the device; 3) the public encryption key of the device. The manufacturer can install certified certificates, one for the signature verification key and one for the enrollment key. The signature devices encipher their communications using a public / private cryptographic eeque. In the alternative, the method can take place in the manufacturer's certificates by providing physical protection to all devices, such as when conducting the tasks of micialization in a secure vault where a small computer (notebook) is used in conjunction with a device. reliable signature. It is assumed that each of the trusted devices start with some basic functionality, such as software that gives you the ability to initiate and receive messages through the network or an email, this allows you to communicate with other trusted devices . It is assumed that at least one signature device, designated as a "main" device, is capable of receiving information about the initial state of the system of human operators responsible for the micialization of the system. The next step in the preparation of the system for the case of the devices is to exchange device keys. The distribution of keys is done as follows. 1) A signature device, designated as the "main" device, receives from human operators the identities of other signature devices in the system. The primary device sends its public enrollment key and the signature verification key publishes to the other signing device. Optionally, the main device can also send messages to validate the signature structure under which it is operating, for example, by redoing its signature structure, signing the redone value using its device signature key and sending the signed redone value to other devices. 2) After other signature devices receive the public encryption key of the main device, each of the other devices sends its respective verification key of the respective public signature and the public encryption key certificates return to the main device . If the main device sends a recomposition of its signature structure, each of the other signature devices redo their own signature structure and compare the two. The two remakes must fit, otherwise, the respective signature device stops participation in the protocol and notifies its operators. This comparison of the remade values ensures that all signature devices use an identical signature structure, which acts as a check that the primary device is not an "impostor" each signature device optionally returns a recomposed its respective signature structure to the main device. 3) The main device compares the recompuestos of the other respective signature structures of the devices against s? own recomposed, which checks that none of the other devices is an impostor.

All signature devices have now received public enclosure and signature verification keys for the other devices. It will be understood that future messages will be signed by means of the private signature key of the sender and veri fled by the recipient using the public verification key of the sender. It will be understood that all communications will be encrypted using a public encryption key of the recipient and decrypted using the private decryption key of the recipient. These additional signature keys were not used for the multi-stage signature (which will be discussed below), but are instead used to encrypt and sign routine communications between the entities in the network or test the individual identity of the device. Such proofs of identity and membership in the group are of critical importance when the master key fragments are generated and distributed for use in the current multi-stage protocol.

TEMPORARY CERTIFICATION OF THE SIGNATURE DEVICE Figure 4 illustrates the temporary certification of non-initiated signature devices. During this process, the public-key certificates of the signing devices (which were not signed or signed by the device manufacturer) will be replaced by certificates signed by a temporary administrator ("the administrator") 61. The administrator preferably is a human operator responsible for the initialization of the system and acts through the administrator's personal smart card.This temporary certification establishes a level of security increase between the signature devices (as belonging to the target group) to be used while they They generate the signature keys for the multi-stage signatures During the current use, it is anticipated that the temporary administrator will be operating with multiple human witnesses to ensure the correct procedures, and that the temporary certification is effectively only for the minimum time ( few minutes or hours, at most), necessary to develop the complete master key generation protocol. The temporary certification is made as follows: 1) The administrator 61 generates a private signature key 63 and a corresponding public verification key 65. 2) The temporary administrator 61 communicates his public signature verification key 65 to each of the devices signature 11, 13, 15, 17, 19. 3) Each of the signature devices 11, 13, 15, 17, 19 generates a private signature key 67, 69, 71, 73, 75 and a verification key public (not shown), and sends a signature key certification request to administrator 61. The signature key certification request is an electronic message that contains the name of the signature device (example a serial number of the device and / or a logical name, such as ("SDL"), the verification key of the public signature generated again by the device, and other administrative information as desired 4) The administrator signs each of the certification applications used Do the administrator's private signature key. 5) The administrator returns signed signature key certificates 68, 70, 72, 74, 76, to the respective signing devices 11, 13, 15, 17, 19. The signed certificates 68, 70, 72, 74, 76 Co symbols for symbols of signature (KS +) with their appropriate indexes are illustrated and, annexed to the bottom part, the signature of the administrator ("- ADMIN"). Such certificates will include, of course, information about the identity of the device and the type (not shown). 6) The signing devices exchange their new certificates of temporary public signature verification key with each other. Each of the signature devices now has: a) the administrator's public verification key; b) your own temporary private signature key; 3) your own temporary certificate, signed by the administrator and which bears the verification code of the temporary public signature of the signature device; and 4) the verification key certificates of the temporary signature of the other signature devices. Each of the signature devices can use the administrator verification key to verify the administrator's signature on temporary certificates received from other signing devices. Each of the signature devices can now move to a heavily controlled phase of the signing protocol that has been certified by temporary administrator. For ease of explanation, it will be assumed that communications in the network involve inuJt signature operations from this point until the end of the recertification of the device is signed using a signature key that has been certified verify the 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 message of compliance is provided. 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 operations of the initialization, multi-stage, and signature.

TEMPORARY CERTIFICATION OF THE AUTHORIZATION AGENT Figure 4 illustrates the temporary certification of the authorization agents. As discussed more fully below, a signature device sets a partial signature only in response to the authorization of a quorum of authorization agents. Signature devices that operate under the permission of the temporary administrator also require a quorum of authorization agents. Temporary certification and authorization agents ensure that only a designated human agent can secure signing devices during the initiation of the process. The procedure for temporary authorization agents is similar to the previous procedure for temporary certification signature devices, and is done as follows: 1) Administrator 61 communicates s? public signature verification key 65 to each of the authorization agents 23, 25, 27, 29, 31. 2) Each of the authorization agents generates a private signature key certification request to the administrator 61. The request The signature key certification contains at least the following information: a) name of the authorization agent (distinguishable name of the human); b) identification code for the agent's reliable device (example, smart card serial number and model number); c) signature verification key for the human agent; and d) signature verification key for the agent's reliable device (which serves to ensure that the reliable device is of known type). 3) The administrator signs each of the certification requests using the administrator's private signature key. 4) The administrator returns the signed signature key certificates to the respective authorization agents.

DISTRIBUTION OF THE PARTS OF THE KEY Figure 5 illustrates the generation and distribution of "the operational parts" of the "official" signature key of broad system authority (SUR). A signature device, here called Firrn Device 1 (item 11), is designated as a "main" device. The human operators provide this main signing device with the following information: a) the threshold parameters for splitting a key into parts, for example the total number of parts to be generated and the minimum number needed to set the SUR signature. b) The identification number of the key and / or the logical name to be assigned to the public / private key pair, example serial number of the key "KS-01234," or logical name "BT01." c) The identification numbers of the parts of the key and / or the logical names to be assigned to the respective parts, example; "SIA-SHR-56789," or "BTOla." d) The device certificates of the authorization agents who will initially be allowed to authorize that particular signature for each of the devices. The human operators may additionally provide a number that limits the total number of fragments that may reside in a unique signature device, which may be used when the signature device has multiple master keys as discussed below in full. The next step is to generate the parts for signing key, called the "broad authorization system" key (SUA), which will be used to administer the system. The signature key publishes SUA publishes eon generated and distributed as follows. 1) Each signature device 11, 13, 15, 17, 19 transmits in a scrambled manner a string of random "seed" information to the main signature device 11. 2) The main device 11 combines the seed information and uses it to generate verification keys of the broad authority of the public system (KSSWA +) 91, which will finally be used to verify the official signatures. 3) The main device 11 generates operational parts 93, 95, 97, 99, 101 of the signature key Private SWA. This can be accomplished by first generating a pair of private / public cornpletae keys using key generation methods known in the prior art and then splitting the private signature keys 92 into parts using one of the vain methods of private signature key partitioning. well known The generation of parts carries with it a requirement of a minimum number of separate parts, which are not sufficient to complete a signature of broad authority of the system. 4) The main device 11 does not transmit a public verification key SUA 91 and a private signature key part 95, 97, 99, 101 to each of the other signature devices, while retaining a copy of the public verification key SUA 91 and a part of the private signature key SWA 93 for self-monitoring. Each of the SUA private signature key parts is transmitted with the following additional information: a) code type that identifies the key as a signature key part (also indicating the length of the part); b) a unique identification code for the public verification key SWA; c) a unique identification code for each of the respective private signature key parts SUA; d) the total number of SWA private signature key parts distributed; e) the minimum number of SWA private signature key parts needed to complete the SWA signature; f) the identities of the signature devices that receive the other parts of the private signature key SWA; and g) certificates of authorization of the agents who will be allowed to authorize the use of each of the parts of the key of the private signature SWA on the target fi xing device. The main device 11 encp ptara each one of the parts of the SUA private signature key using a certified public encryption key of the respective signature device for which it is done. 5) The main device Ll takes out the verification code published SUR for the human operators and deletes the following training: a) the complete private signature key SWA (if at any time during the process of generating the complete private signature key) SWA was stored); and b) all parts of the SWA private signature key (except for the part that it retains for its own use). 6) Each of the receiving signature devices installs its SUA private signature key part in a tamper-proof memory area, along with the human certificates initially authorized for that device. It is preferred that the private signature key? WA exists at most only in the main signature device 11, and then only for the minimum time necessary to generate and distribute the parts. In this way, the complete SWA private signature key simply does not exist for operational use, and is susceptible to being attacked only for a short period of time during the generation process. At this stage, each of the devices has received additionally in a secure manner: a) a copy of the signature verification key p SWA; and b) a part of the key of the private firm SWA. For the purpose of illustrating the following discussion with an example, it will be assumed (for the sake of simplicity) that the minimum number of parts needed to fix the SWA signature is two out of five parts. It will be understood that a greater number may be chosen, probably more at least 3, which will increase safety, but also increase the number of steps in the signing process.

RECERTIFICATION OF THE SIGNATURE DEVICE During the previous steps of the initialization protocol, signature verification keys of the temporary device administrator's certificate 61 under the authorization of the temporary administrator 61, and the certificates of the signature device were signed by the administrator's temporary signature key. During recertification, each of the signature devices will circulate a new certificate request for its own public key among the other signature devices to be certified under the broad authority key of the system using the multi-stage signature. Figure 6 illustrates the steps for recertification of the signature device 1. The other signature devices will recertify themselves by repeating the process for each of the devices. The process for the signature device 1 is carried out as follows: 1) The signature device 1 generates an unsigned certificate 103 and transmits that certificate to the signature device 2. The certificate includes the following: a) the identity of the signature device (example serial number and / or logical name of the device, and b) a public signature verification key for the signature key of the device. The key that is recertified is the public key number that was originally generated by the device at the beginning of the protocol, and temporarily first certified by the administrator. This key will now be certified by the administrator. The key will become the permanent sign of the device of the news in the family of the signature devices that handle the parts of this particular key SUA. (The device signature key and s? associated manufacturer's certificate remain unchanged during this process, and are permanently retained as proof of the origin of the device and the underlying characteristics.) 2) signature device 2 sets a partial signature SWA using s? part of signature key SWA 93. The partial signature is formed in two steps. First, the signature device 2 applies a "redo" function (such as MD5 or SHA) that generates a stream of reduced length that is verifiably related to the non-redone certificate. This string is expressed as binary digits that can be manipulated as a numerical value (large integer). Second, signature device 2 forms a partial signature upon exponentiating the redo cord with its signature key part SWA. That is, the signature device 2 calculates the numerical value, which becomes a partial signature, according to the formula: --SD2 = (HASH (CERT)) KEY CODE 2. module N (Note that in both texts and drawings, the bit string that constitutes the signature block is typically indicated by locating a long dash in front of the tag that identifies the signer.The resulting block is typically added to the bottom of the data block that was signed, or the context is otherwise obvious.) 3) The signature device 2 sends the partially signed certificate 105 to the signature device 3. 4) The signature device 3 completes the broad authority signature of the system by exponentiating the partial signature already applied --SD2. That is, the signature device 3 calculates a numerical value according to the formula: - SD3 = C - SD23 KEYPART 3_ module N = ((HASH (CERT) exp KEY PART 2) exp PART KEY 3 ) = - SWA The partial signature set by the signature device 2 may be allowed to remain attached to the document as an audible track. Note that only partial signatures 2 are required in this simplified example. 5) The signature device 3 returns the signed certificate 107 to the signature device 1, which then distributes copies of the certificate to other signature devices, thus allowing them to verify their future signatures. In this example, signature devices 2 and 3 set signatures in that order. Any combination of the signature devices can be signed in any order (as long as a number exceeds the minimum number to), producing the same signature. The recertification is important, because the future operations developed by the complete system of the signature devices will preferably be developed only in response to the request of the devices (example of the authorized, as described above) that have been certified as SWA signature. The signature devices themselves can make requests to other signature devices. By means of this procedure, the minimum signature devices become the first certified devices by means of the broad system authority (SUA) as a whole, using the multi-stage signature process defined here. In an alternative mode of the previous recertification process, the group of objective devices could provide their recertification (certificates not signed) before the generation of the initial key through the main device. The main device would sign this certificate at the same time it creates a private signature key SWA before splitting it into fragments and deleting the total key. It seems to be no greater advantage to do this, insofar as the main function of the reelator system is to sign certificates in a still efficient and highly controlled manner.

RECERTIFICATION OF THE AUTHORIZING AGENT Figures 7 and 8 illustrate the steps for recertification and registration authorization agents, Figure 7 shows the architecture of the entire system, while Figure 8 illustrates the processing sequence for the certification request. The signature devices will set the official signature of broad authority of the system to authorize the certificates of the agents, thus certifying a public signature verification key for each of the authorization agents. In the registration process, each of the signature devices will update a table stored internally of the particular authorization agents who will be responsible for instructing the signature devices to apply s? partial signature. During the routine operation, a signature device will set s? partial signature only if the application is signed by a minimum number of temporarily certified authorizing agents or SWA certificates (or if a minimum number of individually signed messages are received) as discussed below. An example of the process for certifying an authorization agent 3a (AA3a) and registration AA3a with signature device 3 is carried out as follows. For purpoof illustration, it will be assumed that each signature device 3 and 1 (Figure 7, items 15 and 11) are 2 of the five signature devices selected to set the SUR signature. 1) The authorization agent 3a 109 provides a recertification request for the same (Figure 8, item 121) for the Signature Device 3 through the LAN / URN 21. (Alternatively, the authorization and / or registration may be restricted to direct access to the signature device through a limited access communication channel, for example direct connection to a personal computer remains alone). The certification request includes at least the following information: a) the name of the authorization agent (distinguishable name of the human); b) identification code for the agent's reliable device (example smart card serial number and model number); c) a verification code for the signature for the human agent (as initially stated by the temporary administrator); and d) a signature fingering key for the agent's reliable device, which serves as security for your device is of the known type. Such securities are particularly critical when all or substantially all operations are carried out in widely separated sites, in such a way that system operators can not verify anything by visual inspection. 2) The signature device 3 15 sets a partial signature SWR (-SD3) to the certificate 121, and transmits the partially signed certificate 123 to other signed devices. 3) The Authorization Agent authorizes it that the partial certificate 123 can now be sent to the signature device 1 11. 4) The Signature Device 1 completes the signature process using its part 93 of the signature key SWR. 5) Signature Device 1 returns the fully signed certificate 127 to Authorization Agent 3a. 6) The Signature Device 1 retains a copy of the signed certificate 127, enters AA3a into a record of authorization agents (not shown), and returns the signed certificate 127 to the authorization agent 3a. The process is repeated for all the authorization agents which must be registered with the Signature Device 3, leaving each of the authorization agents with the signed certificate and leaving the Signature Device 3 with a record of all the certificates. The procesare repeated for all the authorization agents of the other signature devices 11, 13, 17, 19. MULTI-STAGES SIGNATURE In this stage, the signature devices have been initialized with parts of the private signature keys SWA. The signature devices have been recertified by them, and the authorization agents have been recertified and registered with their respective signature devices. The system is now ready to enter routine service for both the administration system and the official certification functions. In the following discussion, the multi-step signature will be described for the broad system authority key, which will typically be authorized by the management systems. As will be discussed further, the additional "master keys" will also be generated and used by the multi-stage signatures within the same device families, in the same way as the key of broad authority of the system, except that the content of the messages to be signed by such master keys can not be of an administrative nature. Figures 9 and 10 illustrate a multi-stage signature using the broad authority key of the system. Figure 9 illustrates the flow of a document ("DOC") through various authorization agents and signing devices, while Figures 10 illustrate the evolution of the signatures in the document.

This example assumes that the authorization agents la and lb authorize device 1 to set a partial signature, and authorization agents 2a and 2b authorize signature device 2 to complete the SWA signature. For simplicity, we assure you that any of the authorization agents need to activate each of the signature devices. The sequence occurs as follows: 1) The Authorization Agent receives an application for a signature through the URN / LRN. The request is an electronic message 131 that has a header 133 and the document to be signed 135. The header will contain the command code that defines the message co or the signature request. 2) The Authorization Agent (Figure 9, item 132) strips the header and develops a check procedure number to determine if the document should be signed. The specific check procedure, which may include the judgment of the human operator RRla and which may vary depending on the underlying purpose of the document, is not related to the multi-stage signing process itself. When the fact is satisfied that the document must be signed, the Authorization Agent signs the document using the secret signature key of the people (which was recertified under the signature SUA). As shown in Figure 10, the Agent Authorization Signature (--AAla) is determined by shredding the document and exponentiating the shredding of the document and exponentiating the shred using the secret signature key AAla. The RAA then sets a new heading and sends the signed certificate 137 to the Authorization Agent Ib (another agent for the signature device is the Authorization Agent). 3) The Authorization Agent Ib (Figure 9, item 138) cuts the heading and performs a number of procedure checks (not related to the multi-stage signature) to determine whether the document should be signed. When is satisfied that the. certificate must be signed, the Authorization Agent lb also signs the document. As shown in Figure 10, the signature of the AAlb (--AAlb) is determined by: 1) shredding the concatenated combination of the document and the AAlb signature; b) exponentiation of the comminution using the AAlb signature key. The AAlb signature is left on the document as an audit trail. The AAlb then sets a new header and sends the double signed document 139 to the signature device 1 (Figure 9, item 11). 4) The signing device 1 receives the double signed document 139, cuts the heading and verifies that the document bears the necessary number of signatures of its registered authorization agents (in this example, 2). If so, the signature device 1 removes the signatures of the authorized agents and sets a partial SWA signature. As shown in Fig. 10, the partial SWA signature (-SDl) is determined by the shredding of the base document (without the signatures of the authorization agents) and the exponentiation of the shred using the signature key portion SWA of the device. signature 1, 93. The signature device 1 then sets a new header, and sends the partially signed document 141 to an Authorization Agent for another signature device, here the Authorization Agent 2a of the signature device 2. 5) The agent of Authorization 2a (Figure 9, item 143) trims the heading and performs a number of procedural checks (unrelated to the multistage signature) to determine whether the document should be signed. When it is satisfied that the certificate must be signed, the Authorization Agent 2a signs the document. As shown in Figure 10, the signature of the AA2a (-AA2a) is determined by: 1) shredding the concatenated combination of the certificate and the partial SWA signature (-SDl); and b) exponentiation of the comminution using the signature key of the AA2a recertified. The partial SWA signature of the SSD1 is left on the document. The AA2a then sets a new heading and sends the signed certificate 145 to Authorization Agent 2b (Figure 9, item 147). 6) Authorization Agent 2b (Figure 9, item 147) trims the heading and performs number of procedure checks (not related to the multi-stage signature) to determine whether the document should be signed. When satisfied that the document must be signed, Authorization Agent 2b signs the document. As shown in Figure 10, the signature of AA2b (--AA2b) is determined by: L) shredding the concatenated combination of the certificate, the partial SWA signature and the signature of the RR2a; and b) exponentiation of the shredding using the signature key of the RR2b recertified. The signature SUA partial and the signature of AA2a ee leave on the document. The RA2b then sets a new header and sends the signed certificate 149 to the signature device 2 (Figure 9, item 13). 7) Signature Device 2 receives the signed document 149, removes the heading and verifies that the certificate bears the necessary number of signatures of registered authorization agents (in this example, two). If so, the Signature Device 2 withdraws the signatures of the authorized agents and modifies the partial SWA signature to complete the signature? WA. As shown in Figure 10, the completed SUA signature (-SSWA) is determined by the exponentiation of the partial signature set by the signature device 1 (-SDl) using the signature key portion SUA 95 of the device. Signature 2. Signature Device 2 then sets a new heading, and sends the partially signed certificate 151 to the AAla (the original Authorization Agent). In the example described above, two signature devices were needed to set the broad authority signature of the system, and each signature device required authorization from two Authorization Agents. The total number of signature die required to complete a signature in the system can be adjusted at the time when the key portions are generated, and the number of authorization agents for each signature device may also vary. For example, three signature devices may be required for 5 to complete the broad authority signature of the system, and the number of authorization people needed to authorize a signature device may vary - for each signature device, depending on the level of revision desired for security purposes. After having established a multi-stage signing process as discussed above, certain central administrative actions may be conditioned upon the "settlement" of a quorum of other signature devices as authorized by the presence of the system's broad authority key. . Some of these administrative actions are discussed below. To effect actions and decisions, the company within each tamper-resistant signature device will be programmed to respond only to signed commands: 1. In the case of partial signature requirements, by an appropriate quorum of authorization agents; and 2. In the case of a system of administrative changes, by the broad authority of the system itself. That is, in the preferred embodiment, no change can be made to the authorized list or related requirements on any signature devices by another than the consent of a quorum of authorizers over the quorum of signature devices. In some cases, there may be something unduly complicated to obtain the consent of the complete system for certain innate changes, such as authority to carry out enforced backups. However, it is anticipated that such administrative changes will generally be relatively few and infrequent, in contrast to the official turnover, and that the security of the system requires that such consent should normally be obtained in all cases. Note that in the example, only 4 human signatures were required to recertify and register a user.

PARALLEL SIGNATURES Figure 11 illustrates the flow of a document during a parallel mode of the multi-stage signature system. In this illustration, it will be assumed that there are a total of three signature devices 169a, 169b, 169c in the system, and that all three signature devices are required to complete the system wide authority signature (SUA). It will also be understood that the parallel signature can be adapted to different numbers of signature devices. In the method p > Aralelo, a coordinator of documents 161 ("the coordinator") receives a document that is going to be signed 163. The coordinator can but does not need to be an authorization agent for one of the signature devices, but the coordinator is illustrated as an entity separate in general. The coordination of documents 161 generates three copies (or alternatively, three copies of a shredding of the document) 165a, 165b, 165c of the document to be signed 163. Each copy is sent to a first authorization agent 1.67a, 167b, 167c, then to a second authorization agent 171a, 171b, 171c, and then to one of the three signature devices 169a, 169b, 169c, and finally it is returned to the coordinator 161. In a more fully discussed manner, the document coordinator coordinates the separate signature of the three signature devices and produces a broad system authority signature (--SUA) that fixes to the original document 163 to produce a signed document 173. Figure 12 illustrates the processing of some of the copies, and the combination of three partial signatures on the system's broad authority signature. It should be understood that each of the copies involves a process that is essentially the same, except that different authorization agents and signature devices will fix the signatures, or partial signatures, according to their individual signature keys. In this example, two authorization agents are required to authorize their respective signature devices 169a to set s? firm. The coordinator 161 sends a first copy 165a of the document to be signed, along with a routing and information header (not shown) to a first authorization agent 167a, who sets his signature (-AAla) and sends the signed copy 175a to a second authorization agent 171a. The second authorization agent 171a adds a second authorization signature in via (double-signed) document 179a to the signing devices. The signature device 1.69a verifies the two authorization signatures, fixes its partial signature (-SDl) to the copy, and returns the signed copy 181a to the coordinator 161. Two other signature devices (not shown) fix partial signatures to the copies of the document to be signed and return the signed copies 181b, 181c to the coordinator. All three copies can be processed in parallel. After the coordinator has received all three copies 181a, 181b, 181c of the document to be signed, the coordinator multiplies together the three partial signatures (--SDl, --SD2, --SD3). The product of the three partial signatures is the system wide authorization signature (--SUA). The signing device and the smart cards of the authorization agents will be reliable devices. The security of this parallel signature method of rn? Lti-stage does not depend on the physical security of the coordinator's workstation. The coordinator does not need to have any explicit code to authorize the signature devices (although he will also have to route with encryption and signature keys to give privacy and for identification purposes). The functions of the coordinator may be dispersed among the authorization agents. A first authorization agent can receive the original document to be signed and designate another authorization agent (or even another entity that is not an authorization agent, such as a server for one of the signature devices) to receive and combine the partial signatures. It is expected that the normal operation of the organization will preferably make the coordinator receive both documents to be signed, and then be responsible for supplying the signed document to the last recipient.

ADDING / REMOVING AUTHORIZATION AGENTS Each signing device has an associated group of authorization agents. Because people come and go in an organization, the system includes provisions to add or remove -authorizers dynamically by adding and removing public keys from the trust agents' authorization devices. Adding or removing an authorization agent is carried out by submitting, to a signature device, a command to add or remove a public key from people. The command takes the form of an electronic message that has a code for the add / remove command, additional information (discussed below) and authorization sign. Authorization signatures may be from other authorization agents of the same signing device, and the add / remove process may be completed locally by a single signing device. In an alternate version, the add / remove procedure may require the signature of the broad authority key to the system, thus requiring quorum of authorization agents on a quorum of related signature devices to approve and authorize the change. In yet another alternative, different authorization agents may have different capabilities, and some more powerful authorizers may be added or removed under the broad authority key of the system, while less capable authorizers may be added or removed locally under the authority of a local quorum. Preferably, the addition or removal of authorization agents requires the signature of the broad authority key of the system. Figure 13 illustrates a command 201 for removing an authorization agent. Additional information with command 203 includes: a) the name of agent 205; b) the title of agent 207; c) the ID number 209 of the signature device from which the agent is to be removed; and d) the identification code 211 of the trusted device associated with the authorization agent to be removed. After receiving a properly signed command, the signing device removes the public verification key from the authorization agent from its internal list of authorization agents. Figure 14 flushes a command 213 by adding an authorization agent. Additional information includes: a) the name of the agent 217; b) the title of agent 219; c) the ID number 221 of the signature device for which the agent is authorized 221; d) an administrative class 225 that indicates the powers for which the agent is authorized; e) an expiration date 223 for the new authority of the people; f) identification codes 227 for the master key or master keys that the authorization agent can instruct the signing device to apply; g) code of II) 229 of the trusted agent device; and h) a certificate 231 with the public signature verification key of the entrusted device. Preferably the public key of the new agent is certified 233 under the authorization of the signature key SSUA and the certificate is included with the command. The device certificate 231, signed by the manufacturer of the trusted device associated with the authorization agent, also includes an assurance that the private signing key of the authorization agent is permanently confined to a smart card or other trusted device. have approved minimum safety properties. (Preferably, the minimum security properties of the device will include the fact that biometric information is used to link the smart card with a physical characteristic of the human user.) For example, the manufacturer can establish that the card does not create user signatures at a lesser rate than the user. the user activates an attached fingerprint reader, where the matching fingerprint data is stored within the card and ee uean to activate it). After receiving an appropriately signed request (for example, after a signed multi-stage SUA has been completed), the signing device will add the new agent information to the internal list of authorization agents.

ADD / REMOVE CARD AND MODEL MANUFACTURERS As discussed above, authorization agents act through trusted devices, which can be smart cards manufactured with certain security properties. As a condition for adding an authorization agent, the agent's trusted device must be a model. approved. During the initiation of the system, model numbers of trusted devices that would be acceptable p > for use in the system were entered. Over time, new models will be available, and security procedures may be adjusted so that older models are no longer acceptable. All signature devices maintain an internal table of accepted models. New manufacturers can be aggregates by circulating an electronic requirement between all the signature devices to add a new manufacturer. Figure 15 illustrates a sample requirement. The requirement includes a command 243 together with the name of the manufacturer 245, the name or code of the model 247, and a public signature verification key 249, joined together in a message 241 signed by the broad authority key of the system. Older manufacturers can be removed by circulating an electronic requirement, signed by the SUA key, to remove the manufacturer's public verification key from the tables of the signature devices. Figure 16 illustrates a sample requirement 251 that includes a command 253 and the name of the manufacturer 255. These add / remove requirements, once signed by a quorum of devices, are then sent to all devices, which then verify them using K + iW1 and act on them. New models for an already approved manufacturer can be added by submitting an electronic requirement, signed by the SUA key, to add a new model. Figure 17 illustrates a sample requirement 261. The requirement will include command 263; the name of the manufacturer 265; the model number 267 and? 269 certificate, signed by the manufacturer, that the particular model complies with certain safety standards (for example, a model certificate meets the requirements of level 3 FIPS). The old models can be removed by submitting an electronic request, signed by the SUA key, to remove the model from the device tables (Je firma.

Figure 18 illustrates a sample requirement 271, which includes: a command 273; the name of the manufacturer 275; and the model number 277.

ADD / REMOVE SIGNATURE DEVICES Over time, it will be desirable to add or remove signature devices from the system. Each signature device contains a table of other signature devices in the system that hold portions of the SUA key (or portions of another master key for multi-stage signing or is discussed fully below). The identity of each signature device is defined by: 1) the identification number of the devices (for example serial number, 2) the public verification key of the devices (installed by a manufacturer and certified under the manufacturer's signature, or a similar key recertified by the firm SUA); 3) the public encryption key of the device (used to send encrypted messages to the device); and 4) any subsequent certified public key only in its position. The new signature devices are added to the system by circulating an unsigned certificate among other devices to receive the SUA signature and then circulate the signed certificate. The certificate contains the information and information as discussed above. After the certificate has been signed by the SUR key, the certificate is sent to all other signing devices with an instruction to add the new devices to the internal tables of the other signing devices. Figure 19 illustrates a sample instruction 281, which includes a command 283 and a certificate 282. The certificate includes: the new identification code of the signature device 285; a signature verification key certificate 287 of the signature devices (signed by the manufacturer); and an encryption key certificate 289 of the signature device (also signed by the device manufacturer). The signature verification key and the encryption key could also be in a single certificate. Other information may be circulated among the other signature devices, such as the identities of key portions 291 used for the new signature device and the portions of decryption keys 292 included with the new devices. Once the signature device is added to the group, it can: 1) participate in the protocols to generate a new master key and receive a portion of it; 2) serve as a backup unit to receive the contents of an SD signature; or 3) serve as a replacement unit to receive the restored contents of a backup signature device for review that has been destroyed or removed from service. Figure 20 illustrates a message 293 for removing a signature device. The message 293 includes a command 295 and the ID code of the device 297.

PORTIONS OF COPY KEY The risk (coneecuenciae) of theft or destruction of the signature devices has been reduced by virtue of the process of signing ulti-stage and the fact that no single signature devices is able to form a signature or disclose enough information to form a signature . The information content of a signing device, including the SUA key portion, can therefore; or be transferred to another device, for example, when the physical support of the signature device is improved or for backup purposes. The copying of the key portions and other information is carried out by submitting or issuing a request, signed by the SUA key, to copy all or some of the information in a particular signature device to a second device. Figure 21a illustrates a sample requirement for a sending device to copy its key portion (s). The requirement 301 preferably includes: a command 303, signed by the SWA key, identifying the second device by the manufacturer 305 (which should already be included in the list of approved manufacturers' signature devices), the model number 307 (which already must be in an approved list of models), a serial number 309; a certificate 311 with a public encryption key to receive device; ID codes 313 of the key portions (or other information designation) to be copied; and the sending device ID 315. When the signed request is received by the appropriate sending device, the appropriate sending device, the sending device encrypts the identified key (s) and related information using the encryption key. The public of the sending device sends the encrypted information as an "aggregate key (s)" message to the receiving device. Figure 21 (b) illustrates a sample message from a sending device to a receiving device. The requirement 314 preferably includes: a command 316, signed by the sending device (-SD;); the receiving device ID 317; the sending device ID 318; the th-ID codes of the encrypted key portions 319; and the key portion owner's ID code 320. The receiving command may also specify a quorum (or other authorization details) for use on the receiving device-, but preferably, the reception key will be used in accordance with the quorum. original of the receiving device. As a typical operating procedure, all operators and system authorities must be informed that a copy has been made, along with the identity of the device or the storage medium that holds the copy.

Alternatively, the information can be copied to a storage device that is physically held (for example, stored in a vault) and off-line (not subject to remote attacks) in an encrypted form to serve as a security copy.

QUORUM CHANGE REQUIREMENTS The quorum of signature devices needed to set the SUA key is a design parameter of the system established by the leading diepoeitive when the key portions are generated. This rum can be changed by recharging the key portions to recover the complete signature key, and then dividing the key into an increased number of portions that are then redistributed as with the original key portions, but with a new requirement of quorum. The quorum of authorization agents needed to authorize a particular signing device to set a partial signature can be changed without re-initializing the system. Such a change is preferably carried out by issuing a requirement to the respective signing device signed by the key SWA. Alternatively, the authorization agents of a particular signature device can change the local quorum by issuing a requirement signed only by the local authorization agents. The number of signatures required to change the quorum may be equal to or different from the number required to authorize the signature device to sign the signature SUA. Note that the SUA key portions are stored inside the encrypted devices in encrypted form and if the auto attendant maintains the key portion of the activation key as discussed below., the quorum that is needed to authorize a signature should not be reduced to the number of the number of parts needed to de-code the SUA key portion. In a normal banking practice, the N of authorities should not be less than 2 per signature device, although some auto- mokers may be entitled to multiple fi xing devices.

ENCRYPT KEY PORTIONS STORED In this variation, shown in Figure 22, each portion of SUA key stored within a signature device 321 is stored in an encrypted form 323. The decryption key ("KEY") is divided into portions, and each trusted device is of authorization agent 325, 327, 229 stores a portion of the decryption key. As discussed above, each requirement for the signature device to fix a partial signature must be accompanied by signatures from a quorum of authorization agents. According to this variation, the authorization agents additionally send a portion of the decryption key 331, 333, 335 to the signature device 321. The signature device then: 1) combines the decryption key portions 337 to retrieve the key from decryption 347; 2) decrypts 339 eu key portion SWA; 3) uses the complete SWA portion 341 to set a partial signature 343 to a document 345; 4) delete the decryption key 347; 5) delete the portions 331, 333, 335 of the decryption key; and 6) delete 342 the entire SWA key portion of 341. When a document is sent to a signature device for s? signature, an authorization agent includes that agent portion of the decryption key and signs the message. In normal operation, the decryption key portions are protected due to the fact that all communications over the network are encrypted using the recipient's public encryption key (for example, from another authorization agent when a document is being circulated for agent signatures, or for a signature device when submitted for signature). Alternatively, each authorization agent can develop a session key for each message in order to protect the decryption key portions. (That is, every time a message contains a key passes from an authorization agent to another authorization agent or towards a signature device, a new encryption key is used). The entire message is then encrypted under the session key. In this way, the entire text of the SUA key portion is temporarily suspended temporarily during the time it is being used to set a partial signature. Additionally, the decryption key, and a complete set of portions of the decryption key, exist only transiently. If a signature device is stolen, the thieves could at most be able to recover the encrypted form of the SWA key portion. The process for generating and distributing encrypted key portions and portions of decryption keys would proceed as follows and is illustrated in Figure 23. 1) The main device generates a public SWA verification key 351 and portions 353, 355, 357 of a key Private SUA signature as discussed above for the basic variation. 2) The main device generates a separate public / private encryption key pair 359, 361 for each private portion of the SWA signature key (a private portion of the SWA signature key is illustrated, and it should be understood that other portions are processed similarly). 3) For each private encryption key, the primary device divides the private decryption key into portions 363a, - 363m using a division L of M where M is the total number of portions and L is the minimum number of portions needed to rebuild the key of private desencnpcion. M can be chosen to equal the total number of approvers on a signing device, while it equals the quorum of authorization agents necessary to authorize a signature on the respective SUR key portion. 4) The main device implements each portion of the signature key SWR 357 under the associated public encryption key 359, and sends a portion enc iptada 365 of 1¿ \ signature key SWR to a respective signing device together with the M portions of the respective private decryption key. 5) The privately owned key portions for the SWR key portions can also be distributed (distpbu dae for secure maintenance) among other signature devices such that any private decryption key can be retrieved from the signature diets, but no signature device contains enough information to recover any decryption key for another device. Such general portions for any given signature device would be released and under the consent of a quorum of authorities on various other SDs. 6) The main device deletes the private decryption keys, the private decryption key portions, and the complete private SWR signature key (if it still exists) from its memory.

When each signing device registers its respective authorization agents, the signing device additionally sends each authorization agent a decryption portion, identified by: 1) an identification number for the decryption key portion; and 2) the identification number for the associated SWR key portion. For example, if there are five portions of the SWR signature key, (with the need for three for a signature) and each SWR key portion was enclosed under a separate public disclosure key, and each SWR key portion requires three of the logs. five authorization agents, then each decryption key can be divided into 5 portions with any of three of them capable of recovering the decryption key. There would then be 25 portions of the decryption key, with each signature device having five distributed to the authorization agent (for its own key) and maintaining a portion of each of the decryption keys for 4 other devices. Thus, the authorization agents necessary to authorize a signature device for which to set a partial signature will also have a sufficient number of decryption key portions to enable the signature device to decrypt the SWA signature key portion transiently to each signing operation. If one or more of the authorization agents loses their keys (for example, loses their smart card from trusted device), then new smart cards would be registered on the same signature devices. The decryption key portions could be retrieved from another signature body and could be restored to the newly registered smart cards by submitting or issuing an electronic message, signed by the SWR signature key, for the signature devices to transfer portions of the signature. decentecppcion key to recently registered devices. As an alternative method, subject to SWR consent, a given device could receive all the decryption portions, decrypt its signature portion, generate a new encryption key pair, reencrypt the signature portion under the public key, divide the new one private release key in new portions and redistribute these portions to the trusted devices of the relevant authorities, taking care to enforce them under the public encryption key of those trusted devices of the receiving authorities. As an alternate security copy method, even the decryption key portions may be distributed offline with an independent trusted institution as described in US Patent Application Pending Nos. 08 / 181,859 and 08 / 277,438.

CRIPTOGR FICO LATIDO As an additional protective measure, each signature device receives a periodic data entry ("heartbeat") which, if interrupted, causes the signature device to be disabled. The heartbeat must be generated from a separate ligation of the signature device so that, if thieves attempt to steal a signature device, they must also enter a separate room or vault to obtain the source of the heartbeat. If they fail to acquire the source of the heartbeat, the signature device will be inactive and will not be useful. In an implementation, each signature device supplies an encryption key to a heartbeat source. The heartbeat source periodically sends encrypted messages to the signature device. If the signature device fails to receive a minimum number of messages for a period of time from the heartbeat source, then the signature device erases its internal memory or takes other evasive action. Messages can be empty messages or simple messages, which must be encrypted by the heartbeat source using the public key given to it by the SD. Alternatively, the messages may be a random string generated at the source of the beat by a random-number generator (RNG) and verified by a (RNG) synchronized on the firrna device.

Multiple heartbeat sources can be established such that the signing device must receive messages from at least 1 (or a regular number) for a period of time. If a heartbeat source goes out of line due to equipment failure or power loss, it will not trigger premature erasure of the signature device memories. The keys used in heartbeat communications can be recovered in portions at multiple locations. In a second implementation, each signature device can send a request to a group of associated ("satellite") devices over the network, and continue the operation only if at least a quorum of associated devices responds. The requirement of a quorum allows operations to continue during unavoidable drops and repairs to communications. The use of a satellite device, while more complex, adds physical security and can be used in locations that have less secure environments, instead of improving these facilities with vaults, guards, cameras, etc. The communication is linked between a signature device and its heartbeat source or a satellite device can be a public network. If a signature device has been stolen, its associated satellite units can be deactivated by system operators to prevent thieves from entering the communication lines and re-routing the beats to the stolen device. For example, the signing device may be in the United States and its associated satellite device in Europe. When the signature device is stolen, the European satellite device goes offline by its operators. The reliability of the European agent for any erroneous action would be minimal, because the removal of the satellite only interferes with new signature operations for a short time. Previously signed signatures remain active. Alternatively a physical security wiring can be supplied between a signature device and s? satellite or heartbeat source instead of a public network.

GENERATION OF ADDITIONAL MASTER KEYS Having established a secure multi-stage signature system with an SUA key, it is quite simple to generate an additional number of "master" keys to be used for other purposes. While the SUA signature key controls the administration of the system, master keys can be used to sign other certified messages or documents for use in favor of other legal entities. The generation and administration of other master keys is similar to the key SUA but without stages of intermediate temporary certification. The method proceeds as follows: 1) Designate a signature device as "leader" (this is not necessarily the "leader" ism that generated the signature key SWA). 2) Enter a public key certificates in the list of signature devices to receive portions of the master key. 3) Enter an identification code for the master key and a logical name. 4) Secure communication channel between signature devices (preferably using encryption key certificates for each related signature device). 5) Optionally obtain random material from each signature device. 6) Generate a new one for "master" public private keys 7) Distribute portions of private keys (optionally encrypted each portion and distributed portions of decryption keys). 8) Delete the complete master private key (if it was stored) and erase all portions not retained by the leading signature device. This process can also be used to replace the signature SUA, sent additionally to each device signing a command, signed by the signature key SUA (old) to install the new master key as the signature key SWA. Generally, the master key will have separate uses from the SWA key and portions of the various master keys can coexist on the signature devices. A previously generated master key (other than the SUA signature key) can be removed from the system by sending a message, signed by the SUA signature key, to remove fragments of the master key.

TRACKING OF DOCUMENTS AND SIGNATURES It is desirable to assign a unique identification code to each document to be signed in order to assist in the management of the flow of documents through the system. The following information may be included in the headings of each document for use by the message servers and authorizers: 1) The code identifying the signature key of the key to be used to sign the document. 2) The total number of partial signatures required to complete the signature and / or the number of partial signatures already applied. 3) Identification codes of key fragments that have already been used to sign. 4) The identities of the signature devices that they have already signed (for example, the logical device names).

INTERLOCKING RINGS OF SIGNATURE DEVICES A CA root, using a multi-stage signature system as described above, will generally certify subordinate CAs located in other businesses and government organizations. Hypothetically, a large central currency bank can certify a larger agency of a state of government. The state agency, in turn, can certify-a corporation. This distributes the certification process flexibly in a way that can shape existing political, economic and social organizations. However, each CA half must maintain strong security over its signing key. Few such organizations, other than banks, some large corporations, and some government agencies, maintain multiple high-security data processing facilities and storage vaults. For example, one half of a CA may have at least one nominally secure physical location, such as a data center or a vault operation, but it lacks the funds to serve multiple sites for the multi-device schemes described above, in one. alternative, the middle part of the CA may not have a truly secure location. Less secure CA moieties (such as CA corporations) may nevertheless establish their own signature rings (as described above) and interlace these middle rings with a high security ring from a CA relative (such as a bank or an agency). of secure government). This can be done while separating the following problems: (1) ownership of key and official control, (2) administrative responsibility and copies of security and (3) possession of the device. An interlock locking ring architecture may be created as shown in Figure 24 but having an average CA 371 maintaining one or more means of signature devices 373, 375, 377 in its own secure locations. The additional means of signing means 379, 381 may be maintained in the secure locations of a relative 383 and may even include some or all of the three dietary elements 379, 381 which form the relative CA ring (root) 383 ( therefore, "interbibber rings"). The parent CA may maintain vain signature devices 385, 387, 389 that are independent of those of any given average CAs 383. The signature devices described above do not require additional modifications to maintain additional master keys, each under different owners and control by respective authority agents 391a, 391b, with supplemental master keys grouped in different manners. The average CA initiates key generation and distributes previously designed portions of protocol using one of its own signature devices as a "leader" device, and authorizes its own officers as a self-holding agent 391b. Some of the new key code Cfl receive their own signature deed (e) 373, 375, 377, while others will reside on signature devices of their relative 379, 381. The authority to issue signatures can remain distributed only in the office of key owners, although they can also delegate some of this authority to some officers of the relative institution, in case of emergency. Thereafter, the average Cfl would initiate a multi-stage signature of the Cfl firms based on signatures generated by smart cards owned by officials, and route those requirements to their own signature devices and / or devices in possession of the parent CA. In fact, the signature devices do not need to be located with the relative CA, but they can be located in any other CA that has a secure location and communication access.

COMPLETE LEASING SERVICES An organization that does not have adequate and safe facilities can still generate certificates and can become a CA. The organization can rent the use of signature devices located in secure locations already established by various banks and other CAs. The organization takes possession of smart cards for its authorization agents, and completes signature requirements for signature devices through the communication network. The proceeds of generating keys, issuing signatures, and carrying out other administrative tasks can therefore occur within diepoeitivoe under physical control of the local bank in accordance with the contractual trust arrangement with the owner. The officials of the organization would go to the local secure facilities (bank) to witness the key generation protocol by means of which new signature keys are created, divided, and distributed to each of a number of guest facilities (possibly others). bank, other locations in the same bank) that they have selected. By that time they can also assign poderee for appropriate administrative backups as needed. The organization can then issue official signatures and official certifications, in the need to establish its own data center or vault facilitation, while still achieving all the security benefits of the system as described.

DELEGATION OF SIGNATURE When an authorized agent is temporarily unavailable (due to vacation, disability, etc.), some form of delegation of signature authority is desirable. It is not desirable for a human operator to lend s? smart card and an associated identification number or key to another, because this creates an unmanageable security risk. An alternate delegation mechanism is for an original authorization agent ("primary") to issue a specialized "delegation" certificate for a substitute authorizing agent ("delegate"). The certificate, signed by the primary user, would identify the delegate and the public signature verification key of the delegate. The delegation certificate would also contain a time limit during which the delegation certificate, and therefore the authority of the delegate) would be valid (see Sudia &Ankney, "Digital Signature Marketing," 1993). A delegate, using s? personal smart card, sign a document using the delegate's personal signature key and could link the delegation certificate. The resulting documents would be signed by the delegate, not by the primary user, and a document recipient should carry out additional steps to verify the delegate's signature and the delegate's certificate. This is, in part, about the ability for a public user of a system to have such a verification capability and to have good access to a source of revocation information (or "hot list"), in case authority be canceled before s? expiration. A preferred approach is to allow a delegate to use the primary user's smart card in a secure manner that, in effect, substitutes the human delegate for the human primary user face-to-face or directly with the primary user's smart card. The delegate then removes the primary user's smart card to set the primary user signature, and the universe of document receivers would save the additional inconvenience of verifying and evaluating another complex certificate. When the primary user wishes to delegate signature authority, the primary user issues a "substitution" certificate 409 to the delegate as shown in Figure 25. The certificate of identification identifies the primary data ID 411, the Delegate ID 413, a means for the primary smart card to recognize the delegate (usually the public verification key of delegate 417), and a time limit 415 during which the 409 subtest certificate (and therefore the delegate's authority) is valid. The primary user can identify multiple individuals, any of whom can authorize the smart card, or a group of individuals of which several must join to authorize the smart card. Background to such methods has been discussed in US Patents Nos. 4,868,877, 5,055,200 and 5,214,702 by Addison Fischer. As shown in Figure 25, when a delegate wishes to sign a document 403 in favor of a primary user, the delegate 401 prepares and signs a 405 request in a specified format to be communicated to the primary user's card 407. Next to this , or otherwise included in the wording eeta 409 substitution certificate. If multiple delegates require authorization of the primary user's card, they can sign the requirement in a manner similar to the signature of the multiple authorization agents a requirement issued towards a signature device as discussed above. Upon receipt of the signature request, the primary user's card will verify that the signature of the user required matches the public key that was originally specified in the substitution certificate, applies the signature of the primary user, 19 and sends the signed document to a signature device 421 (or other destination) in the usual manner. The smart card of the primary user 407 can be physically given to a delegate. The presence of a time limit for delegate authority provides a "time lock" such that delegates can only use the primary user's smart card for a limited period. As discussed above, the authority of the primary user is also limited to a fixed period of time. These limits reduce the consequences of theft, and allow primary and delegated users to store primary user cards in relatively unsafe office environments. After the period of time has expired, the smart card does not become vulnerable to any key guessing attack. (In fact, it would be immune from attack even if the primary user or the delegate wrote keys directly on the card). An additional protection against loss or fierce attack can be achieved by placing the smart card in a vault or in another closed environment, and meertando the card in a card reader where eete can be entered electronically but not physically. In this way, all the actions described above can be carried out, but none can have physical possession of the card. For example, a primary user may be a vice president in charge of purchasing, who must delegate his specific signature authority to his secretary while he travels for business. The substitution certificate may specify that your smart card must issue the signature of said president only upon receipt of a signature requirement signed by: (a) the secretary, as designated by s? substitution certificate; and b) confirmed by any other person with primary signature authority in the purchasing department. The vice president places his card in a card reader in a closed vault and leaves it. To obtain the signature of the vice president, the secretary would prepare the document to be signed and compute the shredding of s? associated using your computer terminal. She would then sign the shredded, place the vice president's public key certificate, the final recipient would need it and then send them in a message to another purchasing agent. The other purchasing agent would confirm the same shredding and link your public-key certificate, along with your certificate of authorization that has been granted to you by your purchasing authority. The other purchasing agent sends them in a message to the vice president's smart card through a local area network. Since the vice president's card also contains security copies of the public keys of the certificate certificate that have created these certificates, such as the SUA, the vice president's card determines that the signing and certificates are all valid and fixes the signature of the vice president to the document. The card may also require that all certificates be accompanied by CRLs recently signed or certified in good faith from a locally recognized CRL handler. This delegation mechanism has the advantage of the ability to reprogram the smart card of the primary user. The smart card of the primary user is a trusted device having known security features, one of which may be an ability to latch onto a secured load of new instructions (e.g. substitution certificates), as described for example in the US Patent Applications still pending 08 / 181,859 and 08 / 272,203 (relative escrow of key S? Dia and CIP escrow of key Sudia).

The above delegation mechanism can be generalized such that it can have high-value digital end-user security keys that were in fact generated and used within the security-resistant security modules (TRSM) that were stored inside security vaults or data centers, while the authorization for such signatures comes from the signature request messages signed by approved users who are given unofficial smart cards (blocked in time) to carry with them. These TRSMs would remain in security against violation, to prevent any personnel from the data center from having access to private user keys, but may be designated to contain the passwords of many different users, each of whom may be authorized to act based on a single unofficial signature, or some pre-arranged combination of signatures and authorizations. Another use for the delegation mechanism, apart from the sole delegation from users on temporary absences, would be a system or method by which a programmatic signature requires a serious programmatic signature requirement made to a card (or a key concatenated with a common TRSM) to carry out the signing of a major "desk" or other role within a corporation or financial environment. After learning from the modalities described above, people who practice that technique will be able to make variations that fall within the spirit and scope of the invention. The embodiments described above are examples which do not unduly limit the scope of the invention which is defined in the following claims.

Claims (9)

NOVELTY OF THE INVENTION CLAIMS

1. - A digital signature method comprises the steps of: generating portions of a private signature key; e the portions in separate electronic signature devices; certify multiple authorization agents for signature devices; and for each of a plurality of signature devices, setting a partial signature to an electronic message in response to authorization from a minimum number of authorization agents; wherein a plurality of partial signatures constitute a digital signature.

2. A system for fixing digital signatures to electronic documents comprises: a plurality of intercommunicative signature devices, each signature device comprises an electronic device programmed to receive an electronic document and to fix a partial signature using a portion of a signature key in response to a predetermined number of authorizations; and a plurality of authorization agents, each agent is in communication with an associated signature device, each agent comprises an electronic device programmed to provide an authorization to an associated signature device.

3. A system of interlocked rings of signature devices for fixing digital signatures to electronic documents comprise: a first set of signature devices, said first set comprises a plurality of electronic devices, each device is programmed to receive a document electronic and set a partial signature for a first signature key, a plurality of said partial signatures comprises a first digital signature; a second set of signature devices, said second set comprises a plurality of electronic devices, each device is programmed to receive an electronic document and set a partial signature for a second signature key, a plurality of said partial signatures comprises a second digital signature; wherein said first set of signature devices includes at least one member that is not in said second set, and said first and second sets include at least one common member.

4. An electronic method for delegated use of an electronic key comprises the steps of: ing said key in a first electronic device; communicate a certificate of electronic delegation to a delegate; send a request and the delegation certificate from the delegate to a first electronic device; and using said first electronic device to use the electronic key in response to the requirement and the delegation certificate.

5. The method according to claim 1, further characterized in that said plurality of signature devices set the plurality of partial signatures for the message according to a method comprising the steps of: transmitting said message to a first signature device of said plurality of signature devices, subsequently said first signature device fixes a first partial signature for said message; and transmitting said message having said first partial signature to a second signature device of said plurality of signature devices, said second signature device later affixes a second partial signature to said message.

6. The method according to claim 5, further characterized in that said transmission step is repeated for each plurality of signature devices.

7. The method according to claim 6, further characterized in that said plurality of signature devices is a quorum of signature devices having ed portions of private signature key.

8. The method according to claim 7, further characterized in that the quorum of signature devices required p > To form said digital signature can be modified while maintaining the same private signature key by redistributing portions of the private signature key according to a method comprising the steps of: recombining the portions of each of the signature devices to form the private signature key; generate new portions of private signature key so that the quorum of portions necessary to form a digital signature is modified as described; and store the new portions in separate fi rm devices.

9. The method according to claim 8, further characterized in that the quorum is modified by increasing the number of partial signatures necessary to form a digital signature. 1.0.- The method according to claim 9, further characterized in that the quorum is modified by increasing the number of signature devices. 11. The method according to claim 1, further characterized in that a plurality of authorization agents are assigned for at least one of said electronic signature devices; and wherein the authorization of a quorum of said plurality of authorization agents is required for said electronic device to fix said partial signature. 12. The method according to claim 1, further characterized in that said plurality of signature devices set the plurality of partial signatures for the message according to a method comprising the steps of: transmitting said message separately to each plurality of devices of signing and fixing a partial signature to said message in each plurality of signature devices to form a plurality of messages having partial signatures; and combining said plurality of messages having partial signatures to form said message having said digital signature. 13. The method according to claim 12, further characterized in that said plurality of signature devices is a quorum of said signature devices that have stored portions of the private signature key. 14.- The system in accordance with the claim 2, further characterized in that said plurality of intercommunicating signature devices fix the plurality of partial signatures for the message according to a method q? E comprising the steps of: transmitting said message to said first plurality of signature devices and setting a first partial signature for said message; and transmitting said message having said first partial signature to a plurality of signature devices and setting a second partial signature for said message. 15.- The method according to the claim 14, further characterized in that said transmission step is repeated for each plurality of signature devices. 16. The method according to claim 14, characterized in that said plurality of signature devices is a quorum of said signature devices that have stored portions of the private signature key. 17. The system according to claim 2, further characterized in that said plurality of signature devices set the plurality of partial signatures for the message according to a method comprising the steps of: transmitting said message separately to each plurality of devices of signing and setting a partial signature for said message in each plurality of signature devices to form-a plurality of messages having signatures p > arcial and combining said plurality of messages having partial signatures to form said message having said digital signature. 18.- The method of compliance with the claim 17, further characterized in that said plurality of signature devices is a quorum of said signature devices having stored portions of the private signature key.