Multi-step digital signature method and system
Abstract
This record has no abstract on file.
Term
Term ended
Expired 19 April 2016, 10.4 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
17 claims: 15 independent, 2 dependent
- 1電子メッセージに関する ディジタル署名 を作成する 方法であって、秘密署名鍵の部分を作成するステップと、 前記部分は秘密署名鍵を決定するために十分な情報を搬送する複数の部分のような数学的に関係する値であり、 複数の 別個の電子署名装置 の各々 へ 秘密署名鍵の 部分を保存するステップと、 認証機関の身元を確認情報と結合する信用発行者から各認証機関に対し証明書を発行することにより、 署名装置 に関する 複数の認証機関を 証明 するステップと、複数の署名装置の 各々に関し 、 部分署名値を作成するため秘密署名鍵の保存された部分を使用するため 最低数の認証機関から 許可を提供し、前記許可は認証機関の認証情報に基づき、そして 部分署名 値を使用する電子メッセージに関する ディジタル署名を 作成するステップと を含む 方法。
- 2ディジタル署名を電子文書に添付するシステムであって、複数の相互通信署名装置と、なお各署名装置は、電子文書を受け取り、 そして 予め決められた数の認証 機関からの許可信号 に応じて、 部分署名値 を 作成するために秘密署名鍵の保存された部分を使用する ようにプログラミングされている電子装置を含み、複数の認証機関と、各機関は関連する署名装置と通信でき、各機関は関連する署名装置に 許可信号 を提供するようにプログラミングされている電子装置を含 み、そして、 部分署名値から得られる電子文書に関するディジタル署名を作成する装置とを 含むシステム。
- 3電子文書にディジタル署名を添付するための署名装置のインターロックリングシステムであって、署名装置の第1集合と、なお前記第1の集合は、 (a) 複数の電子装置と、各装置は、電子文書を受け取り、 そして 第1の 秘密 署名鍵 に関連する 部分署名 値を作成するために第1の秘密署名鍵の保存された部分を使用 するようにプログラミングされ、 そして(b)第1の秘密署名鍵に関連する部分署名値から得られる第1の電子文書に関する第1のディジタル署名を作成する装置と を含み、署名装置の第2集合とを含み、なお前記第2の集合は (a) 複数の電子装置と、各装置は、電子文書を受け取り、 そして 第2 の秘密 署名鍵に 関連する 部分署名 値を作成するために第2の秘密署名鍵の保存された部分を使用 するようにプログラミングされ、 そして(b)第2の秘密署名鍵に関連する部分署名値から得られる第2の電子文書に関する第2のディジタル署名を作成する装置と を含み、前記署名装置の第1集合は、前記第2集合にはいない少なくとも1つ のメンバーを 含み、そして前記第1集合と第2集合は少なくとも1つの共通メンバーを含 み、前記共通メンバーは第1集合の署名装置としておよび第2集合の署名装置としての双方の機能をする システム。
- 4前記複数の署名装置は、前記メッセージを前記複数の署名装置の中の第1の署名装置に送信 するステップと 、 なお 前記第1の署名装置がその後で前記メッセージ に関する 第1の部分署名 値 を 作成 し、 そして 前記メッセージ および前記第1の部分署名値 を前記複数の署名装置の中の第2の署名装置に送信 するステップと 、 なお 第2の署名装置がその後で前記メッセージに関する第2の部分署名を 作成 し、 を 含む方法に従って メッセージに関する 複数の部分署名 値を作成する 請求の範囲第1項記載の方法。
- 5直列に署名装置を残すために前記メッセージおよび部分署名値を 送信するステップ をさらに含み、各残りの後に続く署名装置はその後前記メッセージに関する後に続く部分署名値を作成する 請求の範囲第4項記載の方法。
- 6前記複数の署名装置は秘密署名鍵の部分を格納している署名装置の定足数である請求の範囲第5項記載の方法。
- 7秘密署名鍵を形成するために 前記 署名装置の 各々 からの部分を再結合するステップと、ディジタル署名を形成するために必要な部分の定足数が必要に応じて変更 され るように 、 秘密署名鍵の新部分を 形成 するステップと、 そして 別個の電子署名装置に新部分を 保存 するステップと を含む 方法に従って、秘密署名鍵の部分を再分配することにより 同一の秘密署名鍵を維持し、前記ディジタル署名を形成するために必要な署名装置の定足数を変更することができる 請求の範囲第6項記載の方法。
- 8前記定足数はディジタル署名を形成するために必要な部分署名の数を増加することにより変更 される 請求の範囲第7項記載の方法。
- 9前記定足数は署名装置の数を増加することにより変更 される 請求の範囲第8項記載の方法。
- 10複 数の認証機関 が 前 記電 子署名装置の少なくとも1つに割り当てられ、 そして 前記電子署名装置に 関し 前記部分署名を添付するために 、 前記複数の認証機関の定足数からの許可 が要求される 請求の範囲第1項記載の方法。
- 11前記複数の署名装置は、 前記 メッセージを コーディネーターから前記 複数の署名装置の各々に 別々に 送信し、 そして 、 複数の部分署名値を形成するために 前記複数の署名装置の各々において 部分署名値を作成 するステップと、 前記メッセージに関する前記 ディジタル署名 を 形成するために、 前記複数の部分署名値を 結合するステップと 、 を含む 方法に従って 部分署名値を作成する 請求の範囲第1項記載の方法。
- 12前記複数の署名装置は秘密署名鍵の部分を 保存 している 前記 署名装置の 定足 数である請求の範囲第11項記載の方法。
- 13前記複数の 相互通信を可能な 署名装置は、 前記 メッセージを 前記 複数の署名装置 における 第1の署名装置に送信し、 そして、 前記メッセージに 関する 第1の部分署名 値 を 作成 するステップと、 そして、 前記第1の部分署名 値を前記 複数の署名装置 における 第2の署名装置に送信し、 そして、 前記メッセージ に関する 第2の部分署名 値 を 作成 するステップと を含む 方法に従って部分署名値 を作成する 請求の範囲第2項記載の システム 。
- 14残りの署名装置に対し直列に部分署名値を送信するステップをさらに含み、各残りの署名装置はその後前記メッセージに関しそれに続く部分署名値を作成する 請求の範囲第13項記載の システム 。
- 15前記複数の署名装置は秘密署名鍵の部分を 保存している前記 署名装置の定足数である請求の範囲第 14 項記載の方法。
- 16前記複数の署名装置は、 前記 メッセージを 別々に前記 複数の署名装置の各々に 送信 し、 そして、前記メッセージに関する複数の部分署名値を 形成するために前記複数の署名装置の各々において部分署名 値 を 作成 するステップと、 そして 前記メッセージに関し 前記 ディジタル署名を形成するために前記 複数の 部分署名 値 を結合する ステップと を含む 方法に従って部分署名 値 を 作成 する請求の範囲第2項記載の システム 。
- 17前記複数の署名装置は秘密署名鍵の部分を 保存している 前記署名装置の定足数である請求の範囲第16項記載の システム 。
Independent claims17
2 paragraphs, as filed
This application is a partial continuation of US Patent Application No. 08 / 181,859 "Encryption System with Key Deposit Function" and US Patent Application No. 08 / 272,203 "Advanced Encryption System and Method with Key Deposit Function". Applications, which are incorporated herein by reference. Background Technology A public key certificate is an electronic document that is signed by a credit issuer and used to prove the binding of a username to a public key or other relevant data. The certificate publicly guarantees that the public key identified in the certificate is owned by the user named on the certificate. The main standards describing public key certification systems are ITU-T X.509 The Directory-Authentication Framework, American Bankers Association ANSI X9.30-Part 3, Certificate Management for There are DSA (draft) and so on. Many examples have a hierarchical structure in which each credit issuer referred to as a guarantee certification body (CA) certifies the key of a subordinate legal entity. A CA can provide an electronic document in a provable (prove that the CA has signed the document) and non-counterfeitable (guaranteeing a high degree of reliability that no one other than the CA has signed the document). Attach a digital signature. For example, at the top of the CA hierarchy, there may be a relatively small number of root CAs, perhaps one for each country that proves a lower level CA. Below a CA in the hierarchy, a higher level CA (probably a bank) certifies a lower level CA (eg, a company) below it, and this CA signs an individual user certificate. CA signing becomes more valuable as it creates a large hierarchy of users below it and uses the signing key to sign certificates for both high-value users and subordinate CAs. Therefore, the CA's signature key is targeted by terrorists, criminals seeking fraudulent economic interests, as well as foreign troops and espionage organizations seeking economic instability through economic espionage and information warfare. These issues apply equally to the keys used to sign electronic money. To date, the security needs of CA's private signing keys have been addressed by providing a certificate signing unit (CSU). This CSU is the Federal Information Processing Standard (FIPS) PUB 140-1, published by the National Institute of Standards and Technology (NIST) of the US Department of Commerce. It is a non-alterable and reliable module that meets the criteria specified in Level 3 or Level 4. This CSU internally creates a public / private signing key mechanism that ensures and permanently makes the private signing key unreadable from the outside and only the corresponding public key used to verify its signature. Contain inside the area of the device that outputs. One CSU available from Boston, MA's Bolt, Barenek, and Newton (BBN) is configured to allow creation using the "K-of-N threshold" method by backing up its private signing key. In this "K-of-N threshold" scheme, the private key is divided into N parts, each placed in a small plastic data key containing a memory chip. The data key is a patented product of Detakey, Inc. of Burnsville, MN. In the unlikely event that the CSU is destroyed, at least K data keys<u style="single">quorum</u>Can recover the private key. At least one major security standards body, the American Bankers Association ANSI, which deals with cryptographic security in large banks. The X9.F1 Commission recommends that CPUs should be designed to prohibit the removal of private keys from devices in any way to prevent key theft and unauthorized use. This approach requires good procedures for disaster recovery, including the simultaneous use of multiple pairs of keys. One key exists in only one CSU at one site, so if a CSU or site is lost, another key pair must be used to continue the business. This requires the CA to issue and / or distribute multiple (at least 2 or 3) public keys identified by different code numbers (eg, BT01, BT02, BT03). In this way, the user can see the signature issued by the CA after the destruction of one CSU containing the BT01 private key. For disaster recovery procedures, see X9. See 30-Part 3. Disclosure of Invention The purpose of the present invention is to provide a highly secure and flexible digital signature system (hereinafter abbreviated as signature system) for certificates and other valuable documents such as contracts, electronic currencies, and contract documents. To provide. A further object of the present invention is to provide a signing system in which the relationship between the signing system and the signing key can be proved and no signing device needs to include the signing key when performing document signing. Another object of the present invention is to provide a signature system that allows the loss or loss of security of one or more signature devices during maintenance of available secure signature services. Another object of the present invention is a signature system in which a plurality of signature devices can create, modify, and combine one or more partial signatures, respectively, and one digital signature is created as a result of processing by the plurality of signature devices. To provide. Another object of the present invention is to provide a signature system in which a plurality of certification bodies directly and indirectly allow each signing device to attach or change a partial signature. Yet another object of the present invention is to provide a strong and easy-to-use mechanism by which a certification body can temporarily delegate its authorization authority. The multi-step signature system described here uses a public key cryptosystem method to sign an electronic document so that the recipient of the document can verify the signature using the signer's public verification key. The private collation key corresponding to the public collation key is never allowed to exist in any form in one place during normal signing work. Instead, the private signature key consists of an operational share (functional part) that can be used to attach or modify a partial signature. By sequential processing of multiple parts, a signature that can be confirmed using the public key is created. Full signing is not complete until all or some of the signing devices have signed. Also, each signing device requires the permission of all or some of the relevant certification bodies before participating in the signing process. If the entire signing key is created during the initial creation of the functional part, the entire signing key is destroyed after the functional part is distributed. A device The risk of loss due to theft or failure of the device is greatly reduced, so if any device fails, it can be easily replaced (or rebuilt) and service resumed (eg remote backup or plug-in replacement). The information content of each signing device can be duplicated (or for hot standby, etc.). Since the signature process is not completed by one device, the effect of destruction of the individual signature device is reduced. A multi-layered authentication management system has been established, in which each signing device registers a large number of individuals (or external smart cards used by designated individuals), and the signing device is a signing device.<u style="single">quorum</u>Participate in signing activities only with the permission of the registered individual. Called a certification body<u style="single">quorum</u>Registered individuals can also register additional certification bodies, delete certification bodies, and for various actions that signatories can perform.<u style="single">quorum</u>You are required to allow changes to your system, such as changing requirements, or creating or distributing additional or alternative key pairs. In this way, signatures that are verified using public verification keys are valid, but no private signature key is present in one place where there is a risk of danger or disaster. Multiple sites must go down before interrupting the signature service or before an adversary gets enough information to forge a signature. Individual signing devices are not as secure as CSUs that use a single global key. Relatively inexpensive equipment that meets FIPS 140-1 Level 3 criteria, that is, interference-resistant equipment, can be used, requiring proactive measures to destroy or protect internal information when alterations are detected. You don't have to use relatively expensive Level 4 equipment. By the delegation mechanism, the certification body may be an agent or<u style="single">quorum</u>You can temporarily allow your smart card to attach your signature to your agent.
BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be described with reference to the following accompanying drawings. FIG. 1 shows an outline of the basic structure of a signature system according to the present invention. Figure 2 shows the preferred structure of a data center with a signing device. Figure 3 shows the preferred structure of a credit device used by a certification body. Figure 4 shows the process of temporarily authenticating a new signing device at system startup and initialization. Figure 5 shows the process of creating and distributing a system-wide valid key operational share. Figure 6 shows a multi-step signing procedure for re-authenticating the signing device. Figure 7 shows the entire system structure for accrediting and registering certification bodies. Figure 8 shows a multi-step signing procedure using a certification body. Figure 9 shows the flow of documents through various certification bodies and signing devices during routine multi-step signature processing. Figure 10 shows the progress of signatures on documents during routine multi-step signature processing. FIG. 11 shows the document flow of a parallel embodiment of a multi-step signature system. Figure 12 shows the three partial signature copies, the process of incorporating them into the system-wide authority signature. Figure 13 shows the delete command for the certification authority. Figure 14 shows the additional commands for the certification body. Figure 15 shows a sample request with a command to add a manufacturer. Figure 16 shows a sample request with a command to remove the manufacturer. Figure 17 shows a sample request with a command to add a model number. Figure 18 shows a sample request with a command to remove the model number. Figure 19 shows a sample instruction, including a command to add a signing device. Figure 20 shows a message to delete the signing device. Figure 21A shows a sample request for the transmitter to copy the key portion. Figure 21B shows a sample message from the transmitter to the receiver. FIG. 22 shows a process of encrypting the stored key portion. FIG. 23 shows a process of generating and distributing an encrypted key portion and a key portion of a decryption key. FIG. 24 shows an interlock ring mechanism. Figure 25 shows the process of issuing a proxy certificate to a proxy signing certification body. Best for carrying out the invention Form First, the multi-step signing method will be explained most directly, starting with some calculation processes. A. Multiplication method in sequential partial signature First, the private signature key K of the public / private key pair that belongs to the authority valid for the entire system.<sub>SAW</sub>Is the signing key K<sub>SWA</sub>Part a so that can be calculated as the product of the part thresholds t0<sub>i</sub>Expressed as the number n0 of. Where t0 is equal to or less than n0. Since it is expressed like this, even if the part less than t0 is processed, the signature key K<sub>SWA</sub>Is extremely difficult to recover. For example, this uses the following 1) Shamir-style secret sharing method (A. Shamir, How to Share a Secret , Communications of the ACM, Nov. 1979, V. 22, n.11). , 2) Use the Blakey secret sharing method (GR Blakley, Safeguarding Cryptographic keys, Proceedings of the National Computer Conference, 1979, American Federation of Information Processing Societies, V.48, 1979, pp, 242-268), It can be done by 3) factoring the key, and 4) creating the key as the product of known factors. All that is required is that the private key be represented as: K<sup>-</sup><sub>SWA</sub>= a<sub>1</sub>* a<sub>2</sub>* ... * a<sub>t0</sub>(mod 2N) Where K<sub>SWA</sub>Is the signing key, a<sub>i</sub>Is a combination of t0 parts. Second, signatures are created using multiple devices by raising the partial signature left by the previous device to each device, and using one part of the private key. When using method N (here, the operation ends by dividing the result by method N and taking the remainder as the result of method N), the following relationship between exponent multiplication and sequential powers is true. (X<sup>a1 * a2</sup>) (Mod N) = ((X)<sup>a1</sup>)<sup>a2</sup>) (Mod N) = ((X)<sup>a2</sup>)<sup>a1</sup>) (Mod N) In other words, if the base value x is raised by the product of two factors a1 and a2, the base is raised by the first factor a1 and the result is raised by the second factor a2. , The result will be the same. In addition, the power order can be reversed. This results in the same result that the base is first raised by the second factor a2 and the result is raised by the first factor a1. This relationship can be generalized to a power of three or more factors. Unless otherwise stated, all operations must be considered law N. In the multi-step signature method, the signature key a<sub>1</sub>, a<sub>2</sub>..., a<sub>n0</sub>Part is distributed to a separate device. The first device hashes the document, powers the Hash function as follows, and attaches a partial signature to the document (the symbol H is used to indicate the result of the hash operation). First partial signature = (H)<sup>a1</sup>(mod N) The second device is the second part a as follows<sub>2</sub>Is used to power the first partial signature to make an additional signature. Second partial signature = ((H<sup>a1</sup>))<sup>a2</sup>(mod N) The t0 device powers the hash using each t0 part, and the public key K<sup>-</sup><sub>SWA</sub>This process is repeated until a final signature that can be authenticated using is created. B. Addition method with asynchronous partial signature In the alternative method to obtain the same result, the private key of the signing authority is added by law N and divided into parts where the private key can be created. K = a<sub>1</sub>+ a<sub>2</sub>+ ... a<sub>t</sub>(mod N) This causes the hash to be raised to the power of each part, multiplied by the result, and separately median (H), as shown below.<sup>ai</sup>Will allow you to perform multi-step signatures asynchronously. S = H<sup>a1</sup>* H<sup>a2</sup>* ... H<sup>a3</sup>(mod N) This is a significant processing advantage over the sequential method described above, as it does not require sequential routing of messages from one location to another. Instead, the central administrator can request a partial signature, send the same message (or hash) directly to each location, and combine the partial signatures to create the final formal signature. This final join process does not require any special security, as it does not add any information that is not yet included in the partial signature. Therefore, the administrator can work from the desktop. Indeed, the recipient verifying the transaction must do the work of joining the partial signatures later, but this does not compromise the security of the formal signature. Power-based signature methods that can be modified to allow multi-step signing include: R. Rivest, A, Shamir and L. Adleman (RSA), "How to Obtain a Digital Signature and Public Key Cryptography System", Communications of the ACM, v.21, n.2, pp.120-126, February 1978); D. Kravitz, Digital Signature algorithm (DSA), US Patent No. 5,231,668; Desmet, Y. Frankel, "Threshold Cryptography System", CRYPTO, '89, pp.307-15, 1989: Taher El-Gamal, "Publication Based on Discrimination Algorithm" Key Cryptography System and Signature Algorithm , (El-Gamal Signature Algorithm ), IEEE Transaction on Information Theory, Vol. IT-31, No.4, Jul. 1985; S. Micali "Secure and Efficient Digital Signature System", MIT / LCS / TM-501, Massachusetts Institute of Technology, laborator for Computer Science, March 1994; A. Menezes et al., "Elliptic Curve Public Key Cryptography", 1993. System Overview Figure 1 shows an overview of the structure of the signature system according to the present invention. This structure includes multiple signing devices 11,13,15,17,19 interconnected by a wide area network (WAN) or local area network (LAN) 21. The individual signing devices 11,13,15,17,19 can be geographically distributed over any area as WAN / LAN allows (multiple continents, multiple cities, multiple regions of one city). ). FIG. 1 shows the signature device 2 in detail as an example. Each signing device, along with public / private key pairs 12a, 12b, has a permanent identification code (eg, a unique serial number) and a logical name (eg, a signature) for encryption / decryption of communications. Device X) is also assigned a separate public / private key pair 14a, 14b for signature authentication and execution. In addition, each signing device receives a public encryption key 16 and a public authentication key 18 for other signing devices. After that, the signature / authentication key is designated as KS, and the encryption / decryption key is designated as KE. The plus (+) superscript indicates the public key, and the minus (-) superscript indicates the private key. The subscript indicates the owner of the private key for each pair of keys. Groups of certification bodies 23,25,27,29,31 are also interconnected over the network and signing devices 11,13,15,17, Also connected to 19. Each certification body is a person who works with a credit computer device, such as an interference-resistant smart card or other credit device, as will be described in detail below. Certification bodies can be distributed as far as LAN / WAN21 allows, but groups of certification bodies are most often located near the corresponding signing device for convenience of the organization that manages the signing system. In FIG. 1, the certification body 2a (reference number 25) is illustrated using the same notation as described above in relation to the key held by the signing device 2 as an example. The credit device of each certification body is given a unique name. Also, public / private device keys vs. 20a, 20b for communication encryption / decryption, and public / private device keys vs. 22a, for signature authentication and execution. The same applies to 22b. If the RSA public key cryptosystem is used, this pair is used for both signing and encryption at the same time. The certification body also receives the public encryption key 24 and public certification key 26 of all other certification bodies. The signing device also receives the public encryption key 24 and the public authentication key 26 of all certification bodies. Similarly, the credit device of the certification authority receives the public encryption key 28 and the public authentication key 30 of all signing devices. To simplify the description of the multi-step signing process, we assume that all communications on the network are encrypted using a standard public key cryptosystem (PRC) method such as RSA key transfer. It is also assumed that commands sent from one network corporation to another are signed by the sender using a standard (PRC) method, such as an RSA signature with an MD5 message digest. In the drawings below, the device encryption / decryption key and the device signature / authentication key may be omitted, but it should be understood that this applies to all devices as described above. FIG. 2 shows the preferred structure of a secure data center computer configuration 48. Each signing device of FIG. 1 exists here. In addition to the signing device 39, each data center configuration 48 further includes a separate message server 47. The signature device 39 is dedicated to signature processing and is located in a solid place such as a safe. There is no direct connection between the signing device and the external computer network. As described in detail below, the signing device 39 was chosen to match the key portion for the multi-step signature 36, its own signature key 37, the table 38 identifying the certificate authority, and the key portion 36. Authentication is provided for the public authentication key 40, which is the public key (here, the certificate is full KS using the multistep method).<sub>SWA</sub>Signed by). In the multi-step signing process, the signing device 39 receives the request through the message server 47. The message server strips the normal privacy envelope attached by the intermediary (server 47 does not process the private decryption key of the signing device), or the input that is made when presented beyond the processing speed. Performs normal communication processes such as queuing. The message server provides a message to the signing device for signing, receives the signature (or partial signature) result, and either (a) returns the partial signature result to the requester, or (b) sends the result to the next device in the protocol. hand over. To receive and participate in a normal communication protocol, the message server receives an encrypted message and has a public / private key pair 32, to sign its own message so that it can be opened. Owns 33 and owns other vs. 34, 35 for encryption. This frees the signing device from this routine load without significantly compromising the security of the secure signing process. The message server 47 may be a computer with a relatively low security level in a low security environment such as a normal secure data center. Message server 47 is LAN / WAN Connect to 21 and provide document queuing and communication services to signing device 39. The message server 47 includes a system log 49 that maintains an audit trail of messages and documents sent and received to and from the signing device. As mentioned earlier, the signing device and its associated message server are usually divided into two physically separate computers. Although less preferred, the signing device 39 and the message server 47 can also be implemented as two tasks on the same computer in a secure environment. Message servers can also provide a layer of protection, the so-called firewall, that checks the validity of all transaction inputs before passing them to the signing device. Without this layer of protection, online signatories with access to public networks could be exposed to unlimited hacking attacks as well as network saturation attacks aimed at outages. Stop attacks can interrupt daily certificate issuance, but they cannot compromise users who are already relying on signed documents (which make up the majority of participating users). However, hack attacks can be a threat, especially if the hacker is identifying a hidden defect. Message servers have a complex strategy of identifying possible attacks and taking advanced actions to track the source of incorrect data entry, as well as all of the list of authorized devices (signing devices and certification bodies). You can inspect the message. Not only does this simplify and inspect the signature device firmware, but it also allows system operators to modify their inspection / evasion strategies based on the current state of network security. Figure 3 shows a working station for a certification body. Operators acting as certification bodies may work in relatively insecure areas such as desktop computers and terminals commonly found in business offices. Such computers and terminals have a card reader 53, and each operator is secure. I have a mart card 55. Each smart card 55 contains a secret decryption key and a secret signature key that are unique to that smart card. The operator can use the card to issue a signature instruction. Such credit devices are from Santa Clara, CA's National Semiconductor Corp. It can be achieved using FIPS Level-3 devices, such as the company's iPower card. This iPower is a device that can be easily reprogrammed at the firmware level according to the emergence of secure signature and authorization methods and procedures without having to replace the physical device. The credit device of each certification authority must have at least one private signing key. Typically, the private signing key is installed on the device by the manufacturer and the corresponding public authentication key is inspected by the manufacturer. Here, inspection means that the credit device includes an electronic message (certificate) in which the manufacturer contains the serial number and public key of the device in addition to evidence of its model number and other credit features. ) Means that the manufacturer signs it. Operators use their desktop computers to read and compose messages. When the operator wants to sign a message, the desktop computer sends the message to a credit device, which uses the device secret signing key to add a digital signature. In a preferred embodiment, this signature is the signature of a second signature key pair created and inspected specifically for a particular user. In this way, the system uses the user's signature to prove the user's identity and consent to the transaction, and continues to use the device signature to verify the reliability level of the device in a transaction. Can be done. As a result, the user key can be remotely created or revoked according to the management facts regarding the user's identity and authority. It also allows the device to be reused and services for other multiple user key pairs that the user wants to use for other unrelated purposes. Figure 3 shows the structure in which credit devices are used by certification bodies. It consists of a smart card, which consists of a single microchip contained in the card. The microchip device includes an input / output circuit 42 for power supply and communication, and a microcontroller 4 for executing a firmware program. Have two The memory 52 contains system firmware 43 (a simple operating system, so to speak) that drives the hardware of the microchip. The memory 52 contains an area for storing the device key 45 incorporated by the manufacturer, the user key 47 received as part of the protocol described here, and the application firmware 49 for executing the network protocol described here. Includes. Unused memory is provided as a work area 54 as a temporary storage device when needed. The macro chip may also optionally include an encryption unit 46 as a dedicated numerical operation accelerator unit with hardware for performing encryption / decryption and accelerated numerical operations of the signature process. In addition, the microchip is initialized by the manufacturer and includes an optional credit time clock 48 that is useful for time stamping signatures. Therefore, an appropriate battery power supply is required. In addition, the microchip contains an optional random number generator 50 used in the encryption / decryption process. Smart cards may also have optional noise sources (not shown), such as internal or external diodes in the microchip, used in random number generation. The signing device shown in Figure 2 may be a smart card with the same design as the credit device of the certification authority. The device on the network is initialized through a series of steps as follows. 1) Distribution of encryption key 2) Temporary signing device 4) Recertification of signing device 5) Certification of certification body 6) Certification of certification body Each is explained in order. After system initialization, describe the usual methods used to sign advanced certificates and other documents, and address their sophistication and variations. Encryption Key Distribution Each signing device and each smart card of the certification authority operates only according to the features described above, and the device signature key pair and device encryption key pair stored in the protected memory by the manufacturer. It is a credit device in the sense that it is a device that is resistant to tampering. I assume. Manufacturers of such devices must, at a minimum, prove that they will not divulge their own or the user's private key without expensive tampering. In addition, each device has an electronic certificate signed by the manufacturer, and the certificate includes the following 1) device serial number, 2) device public signature authentication key, and 3) device public encryption key. Includes. The manufacturer can install two certificates, one for the signing authentication key and one for the encryption key. The signing device uses public / secret cryptography to encrypt its communications. Alternatively, the manufacturer's proof by giving physical protection to all devices, such as performing an initialization task in a secure vault where a small computer (notebook) is used instead of a credit signing device. It may be installed without writing. It is assumed that each credit device first initiates certain basic functions that allow intercommunication with other credit devices, such as software that provides the ability to send and receive messages through a network or email system. It is also assumed that one signing device designated as the lead device can receive information about the initial state of the system from the operator responsible for initializing the system. In the next step of system preparation, the device exchanges device keys. The key distribution process proceeds as follows. 1) The signing device designated as the lead receives the identity of the other signing devices in the system from the operator. The leading device sends the public encryption key and the public signature authentication key to another signing device. Optionally, the leading device sends a message confirming its operating firmware by hashing the firmware, signing the hash value with its device signing key, and sending the signed hash value to another device. You can also. 2) When another signing device receives the public encryption key of the leading device, each of the other signing devices sends back the certificate of the public signing authentication key and the public encryption key to the leading device. If the leading device sends a hash of the firmware, each other signing device Hash your own firmware and compare both hashes. The two hashes must match. If they do not match, each signing device stops participating in the protocol and notifies the operator to that effect. Such a comparison of hash values ensures that all signing devices use the same firmware and can check that the leading device is not an impostor. Each title device optionally returns a hash of its firmware back to the lead device. 3) The leading device compares the hash of the firmware of each other device with its own hash and checks that the other device is not an impostor. Here, all signing devices have received the public encryption key and signature authentication key of the other device. All subsequent messages are understood to be signed by the sender's private signing key and verified by the recipient using the sender's public authentication key. It is also understood that all communications are encrypted using the recipient's public encryption key and decrypted using the recipient's private decryption key. These additional signing keys are not used in the multi-step signing described below, but are used as proof of device identity for the encryption and signing of regular communications between network corporations. Proof of identity and affiliation with a group is very important when creating and distributing master keys used in actual multi-step protocols. Temporary certification of signing device Figure 4 shows a temporary certification of a new signing device. In this process, the signing device's public key certificate, signed or unsigned by the device manufacturer, is replaced by a certificate signed by the temporary administrator (administrator) 61. Usually, this administrator is the operator responsible for initializing the system and operating the administrator's personal smart card. This temporary certificate is used when creating a signing key for multi-step signing, increasing the level of security among signing devices belonging to the target group. In practice, the temporary administrator works in the presence of multiple people to ensure that the correct procedure is performed, and the temporary certificate Ming is expected to be valid only for the minimum amount of time (at most minutes or hours) required to run the complete master key creation protocol. Temporary proof is performed by the following procedure. 1) The temporary administrator 61 creates a public authentication key 65 corresponding to the private signature key 63. 2) The temporary administrator 61 sends the public signature authentication key 65 to each signature device 11,13,15,17,19. 3) Each signing device 11,13,15,17,19 creates a private signing key 67,69,71,73,75 and a public authentication key (not shown), and sends a signing key certification request to the administrator 61. The signing key certification request includes the name of the signing device (eg, device serial number and / or logical name such as SD1), the newly created public signing authentication key of the device, and other management information as needed. It is an electronic message. 4) The administrator signs each certification request using the administrator's private signature key. 5) The administrator returns the signed signature key certificate 68,70,72,74,76 to each signing device 11,13,15,17,19. The signed certificate 68,70,72,74,76 is a public signing key (KS) with the appropriate subscript. 76 is returned to each signing device 11,13,15,17,19. The signed certificate 68,70,72,74,76 is a public signing key (KS) with the appropriate subscript. 76 is returned to each signing device 11,13,15,17,19. The signed certificate 68,70,72,74,76 is a public signing key (KS) with the appropriate subscript.<sup>+</sup>) And the administrator's signature (--- ADMIN) symbol attached below it. Naturally, this certificate contains information about the identity and type of device (not shown). 6) Signing devices exchange their new temporary public signature authentication key certificates with each other. At this point, each signing device has the following: a) administrator's public authentication key, b) own temporary private signing key, 3) administrator signing and signing device's temporary public signing authentication. Temporary certificate that holds the key, 4) Temporary signature authentication key certificate of another signing device. Each signing device can use the administrator's authentication key to verify the administrator's signature on temporary certificates received from other signing devices. Each signing device advances to a higher stage of the protocol by exchanging messages with a signing key authenticated by the temporary administrator. In the following description, communication on the network related to the multi-signature process from here to device recertification is signed using the signature key certified by the temporary administrator, and each recipient authenticates the sender's signature. Suppose. If the message is not properly signed, the message is rejected and protocol continuation fails unless the correct message is provided. It is assumed that some threat analysis and threat protection will be performed if an unsigned or unsigned message is received during the multi-step initialization and signing process. Temporary certification of certification body Figure 4 shows the temporary certification of a certification body. As described in detail below, the signing device<u style="single">quorum</u>Attach a partial signature only with permission from the certification body of. Signing devices operating under the permission of the temporary administrator<u style="single">quorum</u>Request a certification body. Temporary certification of the certification body ensures that only designated human agents can authorize the signing device at the time of enrollment. The procedure for temporary certification of the certification body is similar to the procedure for temporary certification of the signing device, and proceeds as follows. 1) Administrator 61 uses public signature authentication key 65 for each certification body 23,25,27,29, Send to 31. 2) Each certification body creates a private signature key certification request for Administrator 61. The signing key certificate request contains at least the following information: a) the name of the certification authority (human identification name), b) the identification code of the certification authority's credit device (eg, the serial number and model number of the smart card). , C) Certificate authority (human) signature authentication key, d) Certification authority credit device signature authentication key (this ensures that the credit device is of a known type). 3) The administrator signs each certification request 30 using the administrator's private signature key. 4) The administrator returns the signed signing key certificate to each certification authority. Key Part Distribution Figure 5 shows the creation and distribution of a system-wide authority (the functional part (operational share) of the formal signing key of SWA9. One signing device, here signing device 1 (reference number 11)) The operator provides this leading signing device with at least the following information: a) Threshold parameters for dividing the key into parts, i.e. the total number of parts created and the SWA signature attached. The minimum number required to do. b) The key identification number and / or logical name assigned to the public / private key pair, such as the key serial number KS-01234, or the logical name BT01. c) The key part identification number and / or logical name assigned to each part, such as SWA-SHR-56789 or BT01a. d) A device certificate from a certification authority that is first allowed to allow a particular signature on each device. The operator can further limit the total number of fragments that can exist in one signing device and provide the number used when the signing device has multiple master keys. This will be described in detail below. The next step is to create a portion of the signing key called the System Wide Authority (SWA) key that is used to manage the system. The published SWA public signature key and the corresponding private SWA key part are created and distributed as follows. 1) Each signature device 11,13,15,17, 19 sends an encrypted character string of random number seed information to the leading signature device 11. 2) Leading device 11 combines seed information and uses it to public system wide authority signature authentication key (KS).<sub>SWA</sub><sup>+</sup>) 91 is created. This signature authentication key is finally used to authenticate the official signature. 3) Leading device 11 creates functional parts 93,95,97,99,101 of the secret SWA signature key. To do this, the process of first creating a private / public key pair using a known key creation method and then splitting the private signature key 22 into parts using one of the known private signature key splitting methods is performed. There is also. Creating parts entails the requirement that a minimum of n0 for each part must be sufficient to complete the signature of the system-wide authority. 4) The leading device 11 stores the SWA public authentication key 91 and one part 93 of the SWA private signature key for itself, and also stores the SWA public authentication key 91 and one part of the private signature key 95,97,99, Send 101 to each other signing device. The portion of each SWA private signing key is sent with the following additional information. a) A type code that identifies the key as the signing key part (also indicates the length of the part). b) Unique identification code of the SWA public authentication key c) Unique identification code of each SWA private signature key part d) Total number of SWA private signature key parts distributed e) SWA required to complete the SWA signature Private signing key part g) The certificate leading device 11 of the certification authority that is first allowed to allow the use of each SWA secret signing key part in the target signing device is the authenticated public encryption of each originally specified signing device. Encrypt each SWA secret signature key part using the authentication key. 5) Leading device 11 outputs a public SWA authentication key for the operator and erases the following information. a) If the entire private SWA signing key is stored at some point during creation, then the entire private SWA signing key b) All of the SWA secreting key except one part that is stored for your own use Part 6) Each receipt signing device installs its SWA private signing key portion in a non-tamperable memory area, along with the certificate of the first human authoritator for the device. It is desirable that the secret SWA signing key exist only in the leading signing device 11 and for the minimum amount of time required to create and distribute parts. In this way, the private SWA signing key no longer exists for practical use and can only be attacked for a short period of time at the time of creation. At this stage, each signing device has securely received the following: a) a copy of the public SWA signing authentication key, b) part of the private SWA signing key. For the example below, we assume that the minimum number n0 of parts required to attach a SWA signature is two of the five parts. Larger numbers (often at least three) can be chosen for added security, but it must be understood that this increases the number of steps in the signing process. In the previous step of the signing device recertification initialization protocol, the temporary administrator 61 certifies the device signing authentication key under the authority of the temporary administrator 61 and signs it. The name device certificate was signed by the administrator's temporary signing key. Upon recertification, each signing device circulates a new certification request requiring its public key between other signing devices to be certified under a system-wide authority key using multi-step signing. FIG. 6 shows the steps to recertify signing device 1. Other signing devices recertify themselves by repeating this process for each device. The process of signing device 1 proceeds as follows. 1) The signing device 1 creates an unsigned certificate 103 and sends the certificate to the signing device 2. The certificate includes at least the following: a) the identity of the signing device (eg, serial number and / or device logical name), b) the public signing authentication key of the signing key of the device. The key that must be recertified is the same public key that was originally created by the device at the beginning of the protocol and initially temporarily proved by the administrator. This key is a permanent proof that it belongs to the family of signing devices that handle this particular SWA key portion. The device signature key and associated manufacturer's certificate remain unchanged during this process and are permanently preserved as evidence of the device's origin and its characteristics. 2) The signature device 2 attaches a partial SWA signature using the SWA signature key portion 93. The partial signature is created in the following two steps. First, signing device 2 applies a hash function (eg, MD5, SHA) that creates a truncated string associated with the authentication aspect of the unhashed certificate. This string is represented as a binary number that can be manipulated as a number (large integer). Next, the signature device 2 raises the hash character string by the SWA signature key portion to create a partial signature. That is, the signature device 2 creates a numerical value to be a partial signature according to the following equation. --SD2 = (HASH (CERT)) Circulate the new certification request you seek. FIG. 6 shows the steps to recertify signing device 1. Other signing devices recertify themselves by repeating this process for each device. The process of signing device 1 proceeds as follows. 1) The signing device 1 creates an unsigned certificate 103 and sends the certificate to the signing device 2. The certificate includes at least the following: a) the identity of the signing device (eg, serial number and / or device logical name), b) the public signing authentication key of the signing key of the device. The key that must be recertified is the same public key that was originally created by the device at the beginning of the protocol and initially temporarily proved by the administrator. This key is a permanent proof that it belongs to the family of signing devices that handle this particular SWA key portion. The device signature key and associated manufacturer's certificate remain unchanged during this process and are permanently preserved as evidence of the device's origin and its characteristics. 2) The signature device 2 attaches a partial SWA signature using the SWA signature key portion 93. The partial signature is created in the following two steps. First, signing device 2 applies a hash function (eg, MD5, SHA) that creates a truncated string associated with the authentication aspect of the unhashed certificate. This string is represented as a binary number that can be manipulated as a number (large integer). Next, the signature device 2 raises the hash character string by the SWA signature key portion to create a partial signature. That is, the signature device 2 creates a numerical value to be a partial signature according to the following equation. --SD2 = (HASH (CERT)) Circulate the new certification request you seek. FIG. 6 shows the steps to recertify signing device 1. Other signing devices recertify themselves by repeating this process for each device. The process of signing device 1 proceeds as follows. 1) The signing device 1 creates an unsigned certificate 103 and sends the certificate to the signing device 2. The certificate includes at least the following: a) the identity of the signing device (eg, serial number and / or device logical name), b) the public signing authentication key of the signing key of the device. The key that must be recertified is the same public key that was originally created by the device at the beginning of the protocol and initially temporarily proved by the administrator. This key is a permanent proof that it belongs to the family of signing devices that handle this particular SWA key portion. The device signature key and associated manufacturer's certificate remain unchanged during this process and are permanently preserved as evidence of the device's origin and its characteristics. 2) The signature device 2 attaches a partial SWA signature using the SWA signature key portion 93. The partial signature is created in the following two steps. First, signing device 2 applies a hash function (eg, MD5, SHA) that creates a truncated string associated with the authentication aspect of the unhashed certificate. This string is represented as a binary number that can be manipulated as a number (large integer). Next, the signature device 2 raises the hash character string by the SWA signature key portion to create a partial signature. That is, the signature device 2 creates a numerical value to be a partial signature according to the following equation. --SD2 = (HASH (CERT)) Device logical name), b) Public signature authentication key of the device signature key. The key that must be recertified is the same public key that was originally created by the device at the beginning of the protocol and initially temporarily proved by the administrator. This key is a permanent proof that it belongs to the family of signing devices that handle this particular SWA key portion. The device signature key and associated manufacturer's certificate remain unchanged during this process and are permanently preserved as evidence of the device's origin and its characteristics. 2) The signature device 2 attaches a partial SWA signature using the SWA signature key portion 93. The partial signature is created in the following two steps. First, signing device 2 applies a hash function (eg, MD5, SHA) that creates a truncated string associated with the authentication aspect of the unhashed certificate. This string is represented as a binary number that can be manipulated as a number (large integer). Next, the signature device 2 raises the hash character string by the SWA signature key portion to create a partial signature. That is, the signature device 2 creates a numerical value to be a partial signature according to the following equation. --SD2 = (HASH (CERT)) Device logical name), b) Public signature authentication key of the device signature key. The key that must be recertified is the same public key that was originally created by the device at the beginning of the protocol and initially temporarily proved by the administrator. This key is a permanent proof that it belongs to the family of signing devices that handle this particular SWA key portion. The device signature key and associated manufacturer's certificate remain unchanged during this process and are permanently preserved as evidence of the device's origin and its characteristics. 2) The signature device 2 attaches a partial SWA signature using the SWA signature key portion 93. The partial signature is created in the following two steps. First, signing device 2 applies a hash function (eg, MD5, SHA) that creates a truncated string associated with the authentication aspect of the unhashed certificate. This string is represented as a binary number that can be manipulated as a number (large integer). Next, the signature device 2 raises the hash character string by the SWA signature key portion to create a partial signature. That is, the signature device 2 creates a numerical value to be a partial signature according to the following equation. --SD2 = (HASH (CERT)) Create a partial signature by raising the character string to the power of the SWA signature key part. That is, the signature device 2 creates a numerical value to be a partial signature according to the following equation. --SD2 = (HASH (CERT)) Create a partial signature by raising the character string to the power of the SWA signature key part. That is, the signature device 2 creates a numerical value to be a partial signature according to the following equation. --SD2 = (HASH (CERT))<sup>[KEY SHARE 2]</sup>It should be noted that in both the modulo N text and the drawings, the sequence of bits that make up the signature block is usually indicated by a long dash in front of the signer's identification label. The created block is usually pushed to the bottom of the block of data to be signed. Otherwise, it is clear from the context. 3) The signing device 2 sends the partially signed certificate 105 to the signing device 3. 4) Signature device 3 completes the system-wide authority signature by powering the already applied partial signature--SD2. That is, the signature device 3 calculates the numerical value according to the following formula. --SD3 = [--SD2]<sup>[KEY SHARE 3]</sup>modulo N = ((HASH) (CERT) exp KEY SHARE 2) exp KEY SHARE 3) =-It is also permissible to leave the partial signature attached by the SWA signature device attached to the document as an audit trail. It should be noted that in this simple example, only two partial signatures were required. 5) The signing device 3 returns the signed certificate 107 to the signing device 1. The returned signature device 1 distributes a copy of the certificate to the other signing device so that the other signing device can authenticate the signature. In this example, signature devices 2 and 3 attached signatures in this order. The same signature can be created by signing in any combination of signing devices and in any order as long as the number exceeds the minimum number of t0s. Subsequent processing performed by the full system of signing devices should only be performed in response to requests from devices that are certified by SWA signatures (eg, license provider devices, as described below). So re-proofing is important. The signing device itself can make requests to other signing devices. This procedure makes the signing device itself the first device to be proven by the entire System Wide Authority (SWA) using the multi-step signing process defined here. In an alternative embodiment of the previous recertification process, the group of target devices sends their recertification request (unsigned certificate) prior to the initial key creation by the leading device. The lead device signs this certificate at the time of creating the SWA private signing key before breaking it into pieces and erasing the entire key. There seems to be no particular advantage to this approach, as the key functions of the system must be highly controlled and the certificate must be signed in an efficient and internal manner. Certification Body Recertification Figures 7 and 8 show the steps to certify and register a certification body. FIG. 7 shows the overall system structure, and FIG. 8 shows the procedure for processing the certification request. The signing device attaches the official signature of the system wide authority to the certificate of the certification authority and certifies the public signature authentication key of each certification authority. During the registration process, each signing device is instructed to apply its partial signature to the signing device. Update the internal storage table of a particular certification body that has the power to do so. During routine processing, the signing device received the minimum number of temporary or SWA-certified certification bodies, or received the minimum number of individually signed messages, as described in detail below. Only if so, attach the partial signature. The process of certifying the certification body 31a (AA3a) and registering AA3a with the signing device 3 proceeds as follows. For illustration purposes, signature devices 3 and 1 (reference numbers 15 and 11 in Figure 7) are assumed to be two of the five signing devices chosen to attach the SWA signature. 1) Certification body 3a (109) sends a recertification request to signing device 3 via LAN / WAN21 (see number 121 in Figure 8). Alternatively, authorization and / or registration can be restricted to a direct connection to the signing device through a communication channel with access restrictions, eg, a direct connection to a stand-alone computer. The certification request contains at least the following information; a) the name of the certification authority (human identification name), b) the identification code of the certification authority's credit device (eg, smart card serial number or model number): , C) Signature authentication key of the certification body (human). This guarantees that the device belongs to a known type. Such assurance is especially important because all or virtually all processing is performed from widely distributed locations and the system operator cannot authenticate anything by visual inspection. 2) The signature device 3 (15) attaches the partial SWA signature (-SD3) to the certificate 121 and sends the partial signature certificate 123 to another certification authority. 3) The signing device 1a SDIs the partial certificate 123 (10, Be able to send to 11). 4) The signing device 1 completes the signing process using part 93 of the SWA signing key. 5) The signing device 1 returns the signed certificate 127 to the signing device 3a. 6) Signing device 1 saves a copy of the signed certificate 127, enters AA3a in the certification authority (not shown) log, and returns the signed certificate 127 to the certification authority 3a. This process is repeated for all certification bodies that must be registered with signing device 3, leaving a signed certificate for each certification body and logging all certificates for signing device 3. Other signing devices 11,13,17, This process is repeated for all 19 certification bodies. Multi-step signing At this stage, the signing device is initialized by the SWA private signing key portion. The signing device has recertified itself, and the certification body has recertified and registered with each signing device. Here, the system is ready to enter routine services for both system administration and formal certification functions. The following description describes multi-step signing for system-wide authority keys that are normally used for system management. As described below, additional master keys are also created and used for multi-step signing within the same device family, as is the case with system wide authority keys. However, the exception is when the content of the message signed by this master key is not related to management. Figures 9 and 10 show multi-step signatures using a system-wide authority key. Figure 9 shows the flow of documents (DOC) through various certification bodies and signing devices, and Figure 10 shows the progress of signatures in documents. This example assumes that certification bodies 1a and 1b allow signing device 1 to attach a partial signature, and certification bodies 2a and 2b allow signing device 2 to complete a SWA signature. For simplicity, any is fine, but we assume that two certification bodies are needed to activate each signing device. It is done in the following order. 1) Certificate authority 1a receives a signature request via WAN / LAN. The request is message 131 containing header 133 and document 135 to be signed. The header has a command code that specifies the message as a signing request. 2) Certification body 1a (reference number 132 in Figure 9) extracts the header and performs some checks to determine if the document should be signed. Certain procedural checks, which can include operator judgment and may vary depending on the basic purpose of the document, are not closely related to the multi-step signing process itself. Determine that the document should be signed The certification body 1a then signs the document with the certification body's private signing key, which has been recertified under the SWA signature. As shown in Figure 10, the signature of certification authority 1a (--AA1a) is determined by document hashing and hash powers using AA1a's private signing key. AA1a attaches a new header and sends the signed document 137 to certification body 1b (another certification body for the same signing device as certification body 1a). 3) Certification body 1b (reference number 138 in Figure 9) extracts the header and performs some procedural checks (not closely related to multi-step signing) to determine if the document should be signed. When it decides to sign the certificate, the certification authority 1b also signs the document. As shown in Figure 10, the AA1b signature (--AA1b) is determined by: 1) hashing of the concatenated join of the document and AA1b signature, and 2) the power of the hash using the AA1b signature key. The AA1a signature is documented as an audit trail. AA1b then attaches a new header and sends the twice-signed document 139 to signing device 1 (see number 111 in FIG. 9). 4) The signing device 1 receives the twice-signed document 139, extracts the header, and checks if the document has the required number of signatures of its registered certification authority, 2 in this example. If so, signing device 1 extracts the signature of the certification authority and attaches a partial SWA signature. As shown in FIG. 10, the partial SWA signature (--SD1) hashes the basic document without the signature of the certification authority and powers the hash using the SWA signature key portion 93 of the signing device 1. The signing device 1 then attaches a new header and sends the partial signature document 141 to another signing device's certification body, here the signing device 2's certification body 2a. 5) Certification body 2a (reference number 143 in Figure 9) extracts the header and performs some procedural checks (not closely related to multi-step signing) to determine if the document should be signed. If it decides that the certificate should be signed, the certification authority 2a signs the document. AA2a signature as shown in Figure 10. (--AA2a) is determined by: 1) Hashing of concatenated combinations of certificate and partial SWA signature (--SD1), b) Power of hash using AA2a recertified signature key. The SD1 partial SWA signature is left in the document. AA2a then attaches a new header and sends the signed document 145 to certification body 2b (see number 147 in Figure 9). 6) Certification body 2b (reference number 147 in Figure 9) extracts the header and performs some procedural checks (not closely related to multi-step signing) to determine if the document should be signed. If it determines that the document should be signed, Certification Authority 2b signs the document. As shown in Figure 10, the AA2b signature (--AA2b) is determined by: 1) certificate, partial SWA signature, hashing of concatenated combinations of AA2a signatures, b) AA2b recertified signature. Power of hash with key. The partial SWA signature and the AA2a signature are left in the document. AA2b then attaches a new header and sends the signed document 149 to signing device 2 (see number 13 in Figure 9). 7) Signing device 2 receives the signed document 149, extracts the header, and checks whether the certificate has the required number of signatures of the registered certification authority (2 in this example). If so, signing device 2 extracts the signature of the certification authority, modifies the partial SWA signature, and completes the SWA signature. As shown in FIG. 10, the completed SWA signature (--SWA) is determined by powering the partial signature (--SD1) attached by the signature device 1 using the SWA signature key portion 95 of the signature device 2. Be done. The signing device 2 then attaches a new header and sends the partially signed document 151 to AA1a (original certification body). In the example described above, two signing devices were required to attach a system-wide authority signature, and each signing device required permission from two certification bodies. The total number of signing devices required to complete a signature in the system can be adjusted when the key portion is created, and the threshold number of certification bodies for each signing device is security. It can vary with each signing device, depending on the level of human review for the purpose. As mentioned earlier, after setting up the multi-step signing process, as allowed by the presence of the system wide authority key,<u style="single">quorum</u>Can perform key administrative tasks conditioned by the consent of other signing devices. Some of these management tasks will be described below. To streamline this task and decision, the firmware in each non-tamperable signing device is programmed to respond only to signed commands in the following cases: 1. Appropriate<u style="single">quorum</u>In the case of a partial signing request by the certification authority of 2. In the case of a system management change by the system wide authority itself, that is, in a preferred embodiment, the list of license providers of signing devices or related requests<u style="single">quorum</u>Permit provider or<u style="single">quorum</u>It cannot be changed without the consent of the signing device of. Obtaining system-wide consent for small changes, such as permission to perform encrypted backups, may seem unnecessarily cumbersome. However, when compared to the scale of normal business activity, such administrative changes generally do not have to be made frequently, and for the security of the system, such consent must be obtained in any case. I don't think it will. Note that in the example, only four human signatures are required to (re) certify (re) register the user. Parallel signature Figure 11 shows the flow of documents during parallel implementation of a multi-step signature system. In this figure, it is assumed that the system has a total of 3 signing devices 169a, 169b, 169c, and these 3 signing devices are required to complete the System Wide Authority (SWA) signature. It must be understood that parallel signatures can be adapted to a different number of signing devices. In the parallel method, the document integrator 161 (coordinator) receives the document 163 to be signed. However, the integrator does not have to be the certification body of either signing device, but the integrator is usually illustrated as a separate legal entity. Document consolidator 161 makes three copies of document 163 to be signed 165a, 165b, 165c (or three copies of the hash of the document). Each copy is sent to the first certification body 167a, 167b, 167c, then to the second certification body 171a, 171b, 171c, then to the three signing devices 169a, 169b, After being sent to one of the 169c, it is finally returned to the integrater 161. As described in detail below, the document consolidator combines the signatures of the three signing devices and attaches a system-wide authority signature (--SWA) to the original document 163 to create the signed document 173. To create. Figure 12 shows the processing of one of the copies and the incorporation of the three partial signatures into the system-wide authority signature. It must be understood that each copy is basically the same. However, there is an exception that each certification body and signing device attaches a signature or partial signature depending on its individual signature key. In this example, two certification bodies are required to allow each signing device 169a to attach its signature. The integrater 161 attaches its signature (--AA1a) and sends a double-signed signed copy 175a to the second certification authority 171a, along with a routing information header (not shown) for the first certification authority 167a. Send the first copy 165a of the document to be signed. The second certification body 171a attaches the second authorization signature and sends the twice-signed document 179a to the signing device. The signing device 169a authenticates the two authorization signatures, attaches a partial signature (--SD1) to the copy, and returns the signed copy 181a to the integrater 161. The other two signing devices (not shown) attach a partial signature to the copy of the signed document and return the signed copies 181b, 181c to the integrater. These three copies can be processed in parallel. After receiving all three copies of the document that the integrater should sign, 181a, 181b, 181c, the integrater receives three partial signatures (--SD1, --SD2,, --Multiply SD3). The product of the three partial signatures is the system-wide authority signature (--SWA). The signing device and smart card of the certification body are credit devices. The security of this parallel multi-step signature method does not depend on the physical security of the integrated workstation. The integrater does not need to process any private key to grant authorization to the certification authority. However, they usually have routing encryption and signing keys for privacy and identification. The functions of the integrater can also be distributed among the certification bodies. The first certification body may also specify another certification body that receives the first document to be signed and receives and combines partial signatures. Alternatively, it can be specified by another legal entity that is not a certification authority, such as the server of any signing device. In the normal operation of an organization, it may be desirable for the integrator to receive the document to be signed and to be responsible for delivering the signed document to the last recipient. Add / Remove Certification Authorities Each signing device has an associated group of certification authorities. As people enter and exit the organization, the system has rules for dynamically adding or removing authorization providers by adding and removing public keys for the certification authority's credit device. The addition or deletion of the certification authority is performed by sending a command for adding or deleting the public key of the certification authority to the signing device. The command takes the form of an electronic message that has the code for the add / remove command, additional information (discussed below), and an authorization signature. Authorization signatures may come from other certification bodies on the same signing device, and the add / remove process can be completed locally by one signing device. The add / remove procedure may also require the signature of a system-wide authority key. In that case, it was involved to approve and approve the changes You can also specify another certification body that receives the first document, receives the partial signature, and combines it. Alternatively, it can be specified by another legal entity that is not a certification authority, such as the server of any signing device. In the normal operation of an organization, it may be desirable for the integrator to receive the document to be signed and to be responsible for delivering the signed document to the last recipient. Add / Remove Certification Authorities Each signing device has an associated group of certification authorities. As people enter and exit the organization, the system has rules for dynamically adding or removing authorization providers by adding and removing public keys for the certification authority's credit device. The addition or deletion of the certification authority is performed by sending a command for adding or deleting the public key of the certification authority to the signing device. The command takes the form of an electronic message that has the code for the add / remove command, additional information (discussed below), and an authorization signature. Authorization signatures may come from other certification bodies on the same signing device, and the add / remove process can be completed locally by one signing device. The add / remove procedure may also require the signature of a system-wide authority key. In that case, it was involved to approve and approve the changes You can also specify another certification body that receives the first document, receives the partial signature, and combines it. Alternatively, it can be specified by another legal entity that is not a certification authority, such as the server of any signing device. In the normal operation of an organization, it may be desirable for the integrator to receive the document to be signed and to be responsible for delivering the signed document to the last recipient. Add / Remove Certification Authorities Each signing device has an associated group of certification authorities. As people enter and exit the organization, the system has rules for dynamically adding or removing authorization providers by adding and removing public keys for the certification authority's credit device. The addition or deletion of the certification authority is performed by sending a command for adding or deleting the public key of the certification authority to the signing device. The command takes the form of an electronic message that has the code for the add / remove command, additional information (discussed below), and an authorization signature. Authorization signatures may come from other certification bodies on the same signing device, and the add / remove process can be completed locally by one signing device. The add / remove procedure may also require the signature of a system-wide authority key. In that case, it was involved to approve and approve the changes ), And take the form of an electronic message that has a permit signature. Authorization signatures may come from other certification bodies on the same signing device, and the add / remove process can be completed locally by one signing device. The add / remove procedure may also require the signature of a system-wide authority key. In that case, it was involved to approve and approve the changes ), And take the form of an electronic message that has a permit signature. Authorization signatures may come from other certification bodies on the same signing device, and the add / remove process can be completed locally by one signing device. The add / remove procedure may also require the signature of a system-wide authority key. In that case, it was involved to approve and approve the changes<u style="single">quorum</u>In the signature device of<u style="single">quorum</u>Certification body is required. Alternatively, different certifiers can add or remove strong certifiers under a system-wide authority key, but less capable license providers are local.<u style="single">quorum</u>Can be added or removed locally under the authority of. It is desirable that the addition or removal of certification bodies requires the signature of a system-wide authority key. FIG. 13 shows command 201 for deleting a certification authority. Additional information in command 203 includes: a) certification authority name 205, b) certification authority title 207, c) signature device ID number 209, d) deletion. Credit device identification code 211 associated with the certification body. After receiving the properly signed command, the signing device removes the certification authority's public authentication key from the certification authority's internal list. Figure 14 shows command 213 to add a certification authority. Additional information includes the following: a) certification body name 217, b) certification body title 219, c) signature device ID number 221, which is authorized by the certification body, d) recognized by the certification body. Management class 225, e) End date of authority of new certification body 223, f) Master key identification code 227, h) Public signature authentication key of credit device instructing the certification body to apply to the signing device Certificate 231 that has. The public key of the new certification authority is certified under the authority of the SWA signing key233, and it is generally desirable that the command include the certificate. The device certificate 231 signed by the manufacturer of the credit device associated with the certification authority also guarantees that the certification authority's private signing key will be contained in a smart card or other credit device with approved minimum security properties. Includes. It is desirable that the device's minimum security properties include the fact that biometric information is used to associate a smart card with the physical characteristics of a human user. For example, if the user does not activate the attached fingerprint reader, the card may not create a user signature. In this case, the matching fingerprint data is stored inside the card and is used to use the card. After receiving a properly signed request, ie SWA multi-step signing is complete The signing device then adds the new certification authority information to the certification authority's internal list. Card Manufacturers and Model Name Additions / Deletions As mentioned earlier, certification bodies operate through credit devices such as smart cards that are manufactured to have predefined security properties. As a condition for adding a certification authority, the certification authority's credit device must have an approved model name. At system startup, the model number of the credit device allowed to be used by the system was entered. New model numbers will be available, security measures will be strengthened, and old model numbers will gradually be rejected. All signing devices maintain an internal table of eligible model numbers. To add a new manufacturer, electronic requests can be circulated between all signing devices and a new manufacturer can be added. Figure 15 shows a sample request. The request contains command 243 along with manufacturer name 245, model name or model number code 247, public signature authentication key 249, summarized in message 241 signed by the system wide authority key. The old manufacturer can be deleted by circulating the electronic message signed by the SWA key in order to remove the manufacturer's public authentication key from the signing device table. Figure 16 shows sample 251 request containing command 253 and manufacturer name 255. To add, electronic requests can be circulated between all signing devices and new manufacturers can be added. Figure 15 shows a sample request. The request contains command 243 along with manufacturer name 245, model name or model number code 247, public signature authentication key 249, summarized in message 241 signed by the system wide authority key. The old manufacturer can be deleted by circulating the electronic message signed by the SWA key in order to remove the manufacturer's public authentication key from the signing device table. Figure 16 shows sample 251 request containing command 253 and manufacturer name 255. To add, electronic requests can be circulated between all signing devices and new manufacturers can be added. Figure 15 shows a sample request. The request contains command 243 along with manufacturer name 245, model name or model number code 247, public signature authentication key 249, summarized in message 241 signed by the system wide authority key. The old manufacturer can be deleted by circulating the electronic message signed by the SWA key in order to remove the manufacturer's public authentication key from the signing device table. Figure 16 shows sample 251 request containing command 253 and manufacturer name 255.<u style="single">quorum</u>These add / remove requests, signed by the device, are sent to all devices, and each device Ks the request.<sup>+</sup><sub>SWA</sub>Authenticate using and act on it. The new model name of the approved manufacturer can be added by sending an electronic request signed by the SWA key. Figure 17 shows sample 261 of the request. The request is command 263, manufacturer name 265, model number 267, and manufacturer-signed certificate 269 indicating that a particular model number meets security standards (for example, this model number is FIPS level 3). Includes a certificate that the request is met). The old model number can be deleted by sending an electronic request with a SWA key signature to remove the model number from the signing device table. Figure 18 shows sample request 271 with command 273, manufacturer name 275, and model number 277. As the signing device is added / removed, the signing device must be added to the system or removed from the system. Each signing device contains a SWA key portion, or another master key portion for multi-step signing, described in detail below, and a table of other signing devices on the system. The identity of each signing device is defined by 1) a device identification number (eg, serial number), 2) a key installed by the manufacturer and certified under the manufacturer's signature, or a SWA signature re-signed. A device public authentication key that is a similar key to certify, 3) a device public encryption key used to send an encrypted message to the device, and 4) a unique certified public key that you own. The new signing device is added to the system by circulating the unsigned certificate between other devices to receive the SWA signature and then circulating the signed certificate. The certificate contains identification information, as mentioned above. After the certificate is signed with the SWA key, the certificate is sent to all other signing devices with instructions to add the new device to the internal table of the other signing device. Figure 19 shows sample instructions 281 containing command 283 and certificate 282. The certificate is a new signing device ID code 285, manufacturer-signed signature device signing authorization. It includes a certificate key certificate 287 and an encryption key certificate 289 for the signing device, also signed by the device manufacturer. The signature authentication key and the encryption key may be included in one certificate. Other information, such as the key portion 291 used by the new signing device and the encryption key 292 portion deposited in the new device, must be circulated among other signing devices. Adding a signing device to a group allows you to: 1) create a new master key and join the protocol to receive that part, 2) act as a backup unit to receive the contents of the signed SD, Or 3) Act as an alternative unit to receive the recovery contents of the revision backup signing device that has been corrupted or removed from service. FIG. 20 shows message 293 for removing the signing device. Message 293 contains command 295 and device ID code 297. The risk (result) of theft or destruction of the key part storage signature device is the ability of the multi-step signature process and the information sufficient to forge a signature, as no signature device alone can forge a signature. Is reduced by the fact that it cannot be leaked. Therefore, the information content of the signing device such as the SWA key part can be transferred to another device when upgrading or backing up the signing device hardware. A copy of the key portion or other information is performed by sending a request signed by the SWA key to copy all or part of the information of a particular signing device to a second device. FIG. 21a shows a sample that requires the sending device to make a copy of its key portion. The request 301 should include the following, which is identifying the second device by the manufacturer 305, command 303 signed by the SWA key (this manufacturer is the signature of the authorized manufacturer). Must be on the device list), model number 307 (must be on the approved list of model numbers), serial number 309, certificate 311 with the receiving device's public encryption key, copied Key part ID code 313 (or other specified information), transmitter ID 315. When the signed request is received by the appropriate transmitter, the transmitter uses the receiver's public encryption key to encrypt that key portion and related information, and then receives encrypted information such as an add key message. Output to the device. FIG. 21b shows a sample message from the transmitter to the receiver. Request 314 preferably includes: Transmitter signed (--SD) command 316, receiver ID 317, transmitter ID 318, encryption key part ID code 319, key part owner ID code 320. The receive share command is used on the receiving device<u style="single">quorum</u>(Or other permission-providing details) can be specified, but the received key is the receiver's default<u style="single">quorum</u>It is desirable to be used according to. As a general operating procedure, all system operators and license providers are informed that a copy has been made with the identity of the device or storage medium that stores the copy. Alternatively, the information can be copied in encrypted form to a physically secure storage device used as a backup, eg, stored in a vault and vulnerable to offline remote attacks.<u style="single">quorum</u>Change requirements of the signing device used to attach the SWA key<u style="single">quorum</u>Is a system design parameter used by the leading device when creating the key part. this<u style="single">quorum</u>Rejoins the key part to recover the entire signing key and is later redistributed like the original key part, new<u style="single">quorum</u>It can be changed by splitting the key into more parts with requirements. Of the certification body required to allow a particular signing device to attach a partial signature<u style="single">quorum</u>Can be changed without reinitializing the system. This change should be made by sending a request signed with a SWA key to each signing device. Alternatively, the certification body of a particular signing device is local by sending a request signed only by the local certification body.<u style="single">quorum</u>Can be changed.<u style="single">quorum</u>The number of signatures required to change is the same as or different from the number required to allow a signing device to attach a SWA signature. If the SWA key part is stored encrypted in the signing device and the permit provider has the decryption key part as described below, it is necessary to authorize the signature.<u style="single">quorum</u>Must not be less than the number of parts required to decrypt the SWA key part. In normal banking, some license providers may have authority over multiple signing devices, but license provider N must be less than 2 per signing device. Encryption of stored key portion As shown in FIG. 22, each SWA key portion stored in one signature device 321 is stored in the encrypted form 323. The decryption key (KEY) is divided into parts, and the credit devices 325,327,329 of each certification body store the decryption key part. As explained earlier, each request that the signing device attach a partial signature is<u style="single">quorum</u>Must be carried out with the signature of the certification body of. In this case, the certification authority further sends the part of the decryption key 331,333,335 to the signing device 321. The signing device then does the following: 1) Combine the decryption key part 337 to recover the decryption key 347. 2) Decrypt the SWA key part 3393) Attach the partial signature 343 to the document 345 using the plaintext SWA part 341. 4) Erase the decryption key 347 5) Erase the decryption key part 331,333,335 6) Erase the plain text SWA key part 341 342 When sending the document to the signing device for signature, the certification authority Contains the decryption key portion of the certification authority and signs the message. In normal processing, the decryption key portion is when all communications on the network are sent to the recipient, that is, another certification authority when the document is circulated for the signature of the certification authority, or for signature. It is encrypted using the public encryption key of the signing device of. Alternatively, each certification authority can develop a session key for each message to protect the decryption key portion. That is, each time a message containing a key is passed from one certification authority to another certification authority or signing device, a new session encryption key is used. The entire message is then encrypted under the session key. In this way, the plaintext SWA key portion is only temporarily present while it is being used to attach a partial signature. Moreover, the decryption key and the complete assembly of the decryption key part exists only temporarily. If the signing device is stolen, the thief can at best recover the encrypted form of the SWA key portion. The process of creating and distributing the encryption key part and the decryption key part proceeds as follows, and the process is shown in FIG. 1) The leading device is the public SWA authentication key 351 and the private SWA signature key part 353,355, as explained earlier in the basic example. Create 357. 2) The leading device creates a pair of public / private encryption keys of 359,361 for each private part of the SWA signing key. Only one SWA part 357 is shown in the figure, but it should be understood that the other parts are processed as well. 3) For each secret encryption key, the leading device divides the secret encryption key into parts 363a, ..., 363m using L of M division. Here, M is the total number of parts, and L is the minimum number of parts required to reconstruct the secret decryption key. M can choose a number equal to the total number of authorized providers of the signing device, and L is the certification authority required to authorize the signature on each SWA key portion.<u style="single">quorum</u>be equivalent to. 4) The leading device encrypts each part of the SWA signing key under the associated public encryption key 359 and sends the encryption part 365 of the SWA signing key to each signing device along with the M part of each secret decryption key. .. 5) The secret decryption key part of the SWA key part can also be distributed for security and stored among other signing devices. This allows any secret decryption key to be recovered from the signing device, but none of the signing devices has enough information to recover the decryption keys of other devices. A common part of one signing device is in multiple other SDs<u style="single">quorum</u>Released with the agreement of the license provider. 6) The leading device erases the secret decryption key, the secret decryption key portion, and the entire secret SWA signature key (if it still exists) from memory. When each signing device registers its own certification body, the signing device also sends a decryption key portion to each certification body. This key part is identified by: 1) Identification number of the decryption key part, 2) Identification number of the related SWA part. For example, there are 5 SWA signing key parts (including 3 required for signing), each SWA key part is encrypted under a separate public encryption key, and each SWA key part is 5 If you are requesting three of the certification authorities, each decryption key is split into five parts, including three that can recover the decryption key. There will be 25 decryption key parts, each signing device will distribute 5 to the certification authority for its own key, and one part of each decryption key for the other 4 devices. have. In this way, it is necessary for the signing device to be able to attach partial signatures.<u style="single">quorum</u>The certification body will have a sufficient number of decryption key parts to allow the signing device to temporarily decrypt the SWA key parts in each signing activity. If one or more certification bodies lose their keys, for example, a credit device smart card, a new smart card is registered with the same signing device. The decryption key portion can be recovered from other signing devices by sending an electronic message signed by the SWA signing key that the signing device should transfer the decryption key portion to the newly registered device. You can reinstall it on the newly registered Sumart Card. Alternatively, with the consent of SWA, a device receives all the decryption keys and decrypts the signature part by encrypting under the public encryption key of the credit device of the person who has the receiving authority. To create a new encryption key pair, re-encrypt the signature part under the public key, split the new private decryption key into new parts, and redistribute this part to the credit device of the relevant certification authority. can do. Also, using the backup method, the decryption key portion is U.S. Patent Application Nos. 08 / 181,859 and 08/277, It can be stored offline in an independent trust institution as described in No. 438. Encrypted Heartbeat As a further defense, each signing device may receive a periodic data entry (heartbeat) that deactivates the signing device if interrupted. Heartbeats are created away from the signing device, so if someone tries to steal the signing device, they must enter an isolated room or basement to get the source of the hardbeat. It doesn't become. If the source of the heartbeat is not available, the signing device is inactive and is of no use. In some embodiments, each signing device provides an encryption key to the heartbeat source. The heartbeat source periodically sends an encrypted message to the signing device. If the signing device fails to receive the minimum number of messages from the heartbeat source in a given amount of time, the signing device either clears its internal memory or takes other evasive action. The message can be an empty message or a simple message, but it must be encrypted by the heartbeat source using the public key given by the SD. Alternatively, the message may be a pseudo-random number string created by the pseudo-random number generator (RNG) at the heartbeat source and authenticated by the synchronous random number generator (RNG) of the signing device. Multiple heartbeat sources can be installed so that the signing device can receive messages from at least one (or minimum number) sources over a period of time. If a single heartbeat source goes offline due to equipment or power failure, the signing device's memory will not be prematurely triggered. Keys used in hard beat communication can be backed up to multiple locations. Alternatively, the following embodiment can be considered. Each signing device sends a query to a group of network related (satellite) devices, at least The heartbeat source must be encrypted with the given public key. Alternatively, the message may be a pseudo-random number string created by the pseudo-random number generator (RNG) at the heartbeat source and authenticated by the synchronous random number generator (RNG) of the signing device. Multiple heartbeat sources can be installed so that the signing device can receive messages from at least one (or minimum number) sources over a period of time. If a single heartbeat source goes offline due to equipment or power failure, the signing device's memory will not be prematurely triggered. Keys used in hard beat communication can be backed up to multiple locations. Alternatively, the following embodiment can be considered. Each signing device sends a query to a group of network related (satellite) devices, at least The heartbeat source must be encrypted with the given public key. Alternatively, the message may be a pseudo-random number string created by the pseudo-random number generator (RNG) at the heartbeat source and authenticated by the synchronous random number generator (RNG) of the signing device. Multiple heartbeat sources can be installed so that the signing device can receive messages from at least one (or minimum number) sources over a period of time. If a single heartbeat source goes offline due to equipment or power failure, the signing device's memory will not be prematurely triggered. Keys used in hard beat communication can be backed up to multiple locations. Alternatively, the following embodiment can be considered. Each signing device sends a query to a group of network related (satellite) devices, at least<u style="single">quorum</u>Continues processing only when the related device of is responded.<u style="single">quorum</u>By requesting, the process can be continued even in the event of an unavoidable communication failure or communication repair. It's complicated, but satellite devices add physical security, and you don't have to upgrade your equipment where it's sealed, guarded, and monitored by a camera, and you can use it in less secure environments. The communication line between the signing device and its hardbeat source or satellite device may be a public line. If the signing device is reported stolen, the system operator can deactivate the associated satellite unit to prevent eavesdropping on the communication line or rerouting the heartbeat to the stolen device. For example, suppose a signing device is in the United States and its associated satellite device is in Europe. If the signing device is stolen, the European satellite device will be taken offline by the operator. Even if European certification bodies do the wrong thing, the impact is very small. This is because removing the satellite only interferes with the new signing device for a short period of time. Already signed signatures are still valid. Alternatively, instead of a public line, a secure physical line can be installed between the signing device and its satellite or heartbeat source. Creating additional master keys Once you have established a secure multi-step signing system with SWA keys, it is easy to create multiple master keys for other purposes. Since the SWA signing key controls system administration, the master key can be used to sign other certified messages or documents that are used on behalf of other legitimate legal entities. Creating and managing other master keys is similar to SWA keys, but there is no intermediate temporary proof step. This is done as follows. 1) Designate one signing device as the leading device (it must not be the same leading device that created the SWA signing key). 2) Enter the public key certificate list of the signing device that receives the master key part. 3) Enter the master key identification code and local name. 4) Establish a secure communication channel between signing devices. each It is desirable to use the encryption key certificate of the associated signing device. 5) Optionally, get a random number from each signing device. 6) Create a new master public / private key pair. 7) Distribute the private key part. Optionally, encrypt each part and distribute the decryption key part. 8) If saved, erase the entire master private key and erase all parts not held by the leading signing device. This process can also be used to exchange SWA signatures by sending a command signed by the old SWA signature key to each signing device to install the master key as the SWA signature key. In general, the master key has a different purpose than the SWA key, and many parts of the master key coexist in the signing device.To. Already created master keys other than the SWA signing key can be erased from the system by sending a message signed by the SWA signing key to remove the master key fragment. It is desirable to assign a unique identification code to each signed document to facilitate document flow management in the document and signature tracking system. The following information can be included in the header of each document for use by message servers and authorization providers. 1) Signing key identification code of the key used to sign the document 2) Total number of partial signatures required to complete the signature and / or number of partial signatures already in use 3) Already used to sign Identification code for the broken key fragment 4) Identity of the signing device that has already signed (for example, the name of the logical device) Interlocking of the signing device As explained above, the root certification authority using the multi-step signing system usually informs other companies and government organizations. Accredit a subordinate certification body. Suppose a large money center certifies the main certification body of the state government. And the state government has certified the municipality. This flexibly distributes the certification process in a way that suits existing political, economic and social organizations. However, each middle-tier certification authority must maintain strong security for its signing key. With the exception of banks, some large companies, and some governmental organizations, few organizations have multiple highly secure data processing and storage facilities. For example, a middle-tier certification body may have physical facilities that are at least nominally secure, such as processing in a data center or vault, but for the multi-device scheme described above. Lacking funds to run multiple sites. Alternatively, middle-tier certification bodies may not have truly secure facilities. However, less secure middle-tier certification bodies, such as corporate certification bodies, set up their own signature ring as described above, and this middle-tier ring is like a bank or a secure government certification body. Can be interlocked with the highly secure ring of the master certification body. This can be done by separating the following problems: (1) Key owner and formal control, (2) Management and backup responsibility, (3) Physical ownership of the device. By having the middle layer certification body 371, which maintains one or more middle layer signing devices 375,377,289, in its own secure position, an interlock ring structure as shown in FIG. 24 can be created. An additional middle layer signing device 379,381 can be maintained in a secure location on the master certification body and is the same device 379, which constitutes the master (root) certification body ring (here the interlock ring) 383. It can even contain some or all of the 381. The master certification body can maintain multiple signing devices 83,385,387 that are independent of the signing device of the middle layer certification body 383. The signing device described above does not require any additional modifications to hold the additional master key. The additional master key is owned and managed separately by each certification body 319a and 319b, respectively, and the added master key is classified in a different way. The middle layer certification body initiates the key creation and partial distribution protocol described above using its own signing device, which is the lead device, and appoints its own agent as certification body 391b. Some parts of the new certification authority master key are on its own signing device 373,375,377, the rest are master certification authority 379, It is on the 381 signing device. In case of emergency, some of the authority may be delegated to an agent of the master certification body organization, but the authority to issue signatures remains with the agent of the key owner. Therefore, the middle-tier certification authority initiates a multi-step signature of the certification authority's signature based on the signature created by the smart card owned by the agent, and this request is made by its signature device and / or the master certification authority. Send to the device you own. Indeed, the signing device does not have to be in the same location as the master certification authority, but it can be in a secure location and at another certification authority that has communication access. Full Rental Service Even organizations that do not have any secure facilities may want to create a certificate and can be a certification body. Organizations can rent the use of signature devices in secure locations already set up by various banks or other certification bodies. The organization owns a smart card for the certification authority and sends a signing request to the signing device over the communication network. Therefore, the process of creating keys, issuing signatures, and performing other administrative tasks takes place within the device under the physical control of the local bank under a contract with the owner. The organization's agent will be locally witnessing a protocol in which his new signing key is created, split, and distributed to the host facility of his choice, or to another bank or other facility of the same bank. Go to a safe banking facility. At that time, if necessary, appropriate management backup capability can be provided. Organizations can then issue formal signatures and certificates without having to set up their own secure local center or underground vault. And, at that time, it is possible to substantially enjoy all the security benefits already described. Signing Delegation When a certification body is temporarily unavailable due to vacation, busyness, etc., it is desirable to delegate signing authority in some way. It is under control for operators to lend their smart cards-related pin numbers or keys-to others. It is not desirable because it creates an unspecified security risk. A delegation mechanism is conceivable in which the original certification body (primary user) issues a special delegation certificate to the alternative certification body (agent). The certificate signed by the primary user identifies the agent and the agent's public signature authentication key. The delegation certificate describes the validity period of the delegation certificate and the authority of the agent (Sudia & Ankney, Commercialization of Digital Signature , 1993. See). An agent using his or her personal smart card signs the document with the agent's personal signature key and attaches a proof of delegation. As a result, the document is signed by the agent, not the primary user, and the recipient of the document must take steps to verify the agent's signature and delegation certificate. It has access to the source of revocation information, or hotlists, if all public users of the system have such verification ability, and if the authority must be revoked before maturity. It depends in part on whether or not it is present. In effect, it is desirable to allow the agent to use the primary user's smart card in a secure manner by replacing the agent with the primary user vs. the primary user's smart card. In that case, the agent uses the primary user's smart card to attach the primary user's signature, and the recipient of the document is freed from the hassle of authenticating and evaluating other complex certificates. .. If the primary user wishes to delegate signing authority, the primary user issues a proxy certificate to the proxy, as shown in Figure 25. The proxy certificate is the primary user's ID 411, the proxy's ID 413, the means by which the primary smart card recognizes the proxy (probably the proxy's public authentication key 417), the proxy certificate 409 (and the proxy's authority). Identify the validity period 415. The primary user can appoint multiple people, empower one to use a smart card, and empower a group of others to use a smart card jointly. Such methods have already been described by Addison Fischer in US Pat. Nos. 4,868,877, 5,005,200, 5,214, It is stated in No. 702. As shown in FIG. 25, if the agent wants to sign document 403 on behalf of the primary user, agent 401 prepares and signs request 405 in a special format sent to the primary user's card 407. Proxy certificate 409 is also attached to or included in the message. If more than one agent needs to verify the validity of the primary user's card, the multiple agents will sign the request sent to the signing device by more than one certificate authority as described above. Sign the requests sequentially in the same way as. Upon receiving the signing request, the primary user's card checks to see if the requesting user's signature matches the public key specified in the proxy certificate, applies the primary user's signature 419, and signs. Send the completed document to signing device 421 (or another destination) in the usual way. The primary user's smart card 407 can also be physically passed to the agent. Since there is a time limit on the authority of the agent, a time lock is applied. As a result, the agent can use the primary user's smart card for that period of time. As mentioned earlier, the privileges of the primary user are also limited to a certain period of time. This limitation reduces the risk of theft and allows the primary user and agents to keep the primary user's card in an insecure office environment. When the deadline expires, smart cards will not be decrypted under any key-breaking attack. In fact, the attack is completely invalid, even if the primary user or agent is writing his pin directly on the card. Protecting against loss or physical attack can be taken by placing the smart card in a safe or locked area and inserting the card into the card reader electronically rather than physically. In this way, all the actions described above can be performed and no one physically owns the card. For example, a primary user goes on a business trip to negotiate a deal. Suppose you're the Vice President of Purchasing who wants to delegate his specific signature authority to his secretary while he's calling. In the proxy certificate, specify that your smart card will issue the vice president's signature only when it receives a signature request signed by the following person. (a) The secretary specified in your proxy certificate, (b) Co-signing with another person who has the primary signing authority in the purchasing department. The vice president inserts the card into the card reader in the locked safe and goes on a business trip. To get the vice president's signature, the secretary prepares the document to sign and uses the desktop computer terminal to calculate the relevant hash. Then sign the hash and attach the vice president's public key certificate required by the final recipient. Then send it as a message to other purchasers. The purchaser who receives it co-signs the same hash and attaches his public key certificate along with the proof of authority granting the purchase authority. Other purchasers send it in the form of a message to the Vice President's smart card through the local area network. Since the Vice President's card has a credit copy of the public key of the authentication authority that created the certificate like SWA, the Vice President's card determines that all signatures and certificates are valid and the Vice President Attach your signature to the document. The card can also require all certificates to be accompanied by a recently signed CRL or a certificate of eligibility from a locally certified CRL handler. This delegation mechanism has the advantage of being able to reprogram the smart card of the primary user. A primary user's smart card is a credit device with known security features. U.S. Patent Application No. 08 / 181,859 for ongoing Sudia key deposits, No. 08/272, One of the known security features, as described in issue 203, is the need for secure download of new instructions. The previous depository mechanism also allows a large number of valuable end-user digital signature keys to be created and used within an inaccessible secure module (TRSM) stored in a secure vault or data center. The entitlement to such signatures can be generalized to come from a signature request message signed by an authorized user who is given an informal time-locked smart card to be carried. This TRSM is tamper-proof and does not allow data center personnel to access the user's private key, but each is based on an informal signature or a pre-determined combination of signatures and privileges. Is designed to contain the keys of a number of each user who is authorized to act. Apart from simple delegation from users taking temporary leave, the following delegation mechanisms exist. In this system or method, a programmatic signature request is made on the card (or the key contained in the common TRSM) to perform the signature as a desk that plays a major role in the financial or corporate environment. Is issued to. After learning the above embodiments, those skilled in the art can make various changes within the gist and scope of the present invention. The above embodiment is merely an example and does not attempt to impose an unreasonable limitation on the scope of the present invention as defined in the claims below. Designed to contain the keys of a large number of each user given. Apart from simple delegation from users taking temporary leave, the following delegation mechanisms exist. In this system or method, a programmatic signature request is made on the card (or the key contained in the common TRSM) to perform the signature as a desk that plays a major role in the financial or corporate environment. Is issued to. After learning the above embodiments, those skilled in the art can make various changes within the gist and scope of the present invention. The above embodiment is merely an example and does not attempt to impose an unreasonable limitation on the scope of the present invention as defined in the claims below. Designed to contain the keys of a large number of each user given. Apart from simple delegation from users taking temporary leave, the following delegation mechanisms exist. In this system or method, a programmatic signature request is made on the card (or the key contained in the common TRSM) to perform the signature as a desk that plays a major role in the financial or corporate environment. Is issued to. After learning the above embodiments, those skilled in the art can make various changes within the gist and scope of the present invention. The above embodiment is merely an example and does not attempt to impose an unreasonable limitation on the scope of the present invention as defined in the claims below.
Every citation, both waysCites: the store holds 1 of 2
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2023299978A1 | Cited by | United States of America | Search report |
| JP06103426A | Cites | Japan | – |
| 加藤隆充, 廣瀬勝一, 美濃導彦, 池田克夫, “ElGamalの公開鍵暗号系に基づくグループによる著名プロトコル”,1992年電子情報通信学会-創立75周年記念-秋季大会講演論文集, 日本, 社団法人電子情報通信学会, 1992年 9月15日, 分冊1, 基礎・境界, p. 1-187 | Non-patent | – | – |
81 members in 29 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 08462430 | United States of America | – | |
| 46243095 | United States of America | A | |
| 46243095 | United States of America | A | |
| 9605317 | United States of America | W | |
| 9605317 | United States of America | W | |
| 1995462430 | – | – | – |
| 1996005317 | – | – | – |
| US19950462430 | – | – | – |
| WO1996US05317 | – | – | – |
Members81
| Document | Office | Kind | |
|---|---|---|---|
| CA2176032A1 | Canada | A1 | |
| WO9519672A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU1680395A | Australia | A | |
| WO9519672A3 | World Intellectual Property Organization (WIPO) | A3 | |
| GB9610291D0 | United Kingdom | D0 | |
| HU9601870D0 | Hungary | D0 | |
| IL118363D0 | Israel | D0 | |
| AU6084296A | Australia | A | |
| EP0739560A1 | European Patent Office (EPO) | A1 | |
| PL315574A1 | Poland | A1 | |
| ZA963635B | South Africa | B | |
| CA2223305A1 | Canada | A1 | |
| WO9639765A1 | World Intellectual Property Organization (WIPO) | A1 | |
| GB2301919A | United Kingdom | A | |
| AU5552196A | Australia | A | |
| CN1138927A | China | A | |
| CZ197896A3 | Czechia | A3 | |
| HUT75800A | Hungary | A | |
| MX9602773A | Mexico | A | |
| TW307075B | Taiwan Province of China | B | |
| CO4480074A1 | Colombia | A1 | |
| JPH09507729A | Japan | A | |
| BR9506414A | Brazil | A | |
| AR002213A1 | Argentina | A1 | |
| AP626A | African Regional Intellectual Property Organization (ARIPO) | A | |
| NZ279622A | New Zealand | A | |
| US5799086A | United States of America | A | |
| MX9709760A | Mexico | A | |
| CN1192834A | China | A | |
| US5825880A | United States of America | A | |
| EP0872080A1 | European Patent Office (EPO) | A1 | |
| US5841865A | United States of America | A | |
| US5850451A | United States of America | A | |
| BR9608416A | Brazil | A | |
| US5857022A | United States of America | A | |
| US5867578A | United States of America | A | |
| US5872849A | United States of America | A | |
| KR19990022451A | Republic of Korea | A | |
| AU705473B2 | Australia | B2 | |
| HU216231B | Hungary | B | |
| PL176458B1 | Poland | B1 | |
| JPH11506222A | Japan | A | |
| GB9918950D0 | United Kingdom | D0 | |
| AU4461999A | Australia | A | |
| GB2337145A | United Kingdom | A | |
| US6009177A | United States of America | A | |
| NZ306846A | New Zealand | A | |
| NZ329891A | New Zealand | A | |
| IL118363A | Israel | A | |
| GB2301919B | United Kingdom | B | |
| GB2337145B | United Kingdom | B | |
| AU718265B2 | Australia | B2 | |
| US6209091B1 | United States of America | B1 | |
| NZ500372A | New Zealand | A | |
| EP0739560B1 | European Patent Office (EPO) | B1 | |
| AT202439T | Austria | T | |
| ATE202439T1 | Austria | T1 | |
| DE69521413D1 | Germany | D1 | |
| ES2158081T3 | Spain | T3 | |
| UA41387C2 | Ukraine | C2 | |
| DK0739560T3 | Denmark | T3 | |
| US2001050990A1 | United States of America | A1 | |
| PT739560E | Portugal | E | |
| GR3036650T3 | Greece | T3 | |
| US2002013898A1 | United States of America | A1 | |
| OA10456A | African Intellectual Property Organization (OAPI) | A | |
| DE69521413T2 | Germany | T2 | |
| US6411716B1 | United States of America | B1 | |
| EP0872080A4 | European Patent Office (EPO) | A4 | |
| US2005204129A1 | United States of America | A1 | |
| JP2005328574A | Japan | A | |
| JP2006246543A | Japan | A | |
| JP2006333520A | Japan | A | |
| JP2007282295A | Japan | A | |
| JP4083218B2This record | Japan | B2 | |
| US2009217034A1 | United States of America | A1 | |
| EP0872080B1 | European Patent Office (EPO) | B1 | |
| AT492088T | Austria | T | |
| ATE492088T1 | Austria | T1 | |
| DE69638307D1 | Germany | D1 | |
| US8364967B2 | United States of America | B2 |
18 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written submission of copy of amendment under section 19 (pct)JAPANESE INTERMEDIATE CODE: A524A524 | A524 | |
| Written submission of copy of amendment under section 19 (pct)JAPANESE INTERMEDIATE CODE: A524A524 | A524 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 4083218
- Publication, DOCDB
- 4083218
- Publication, EPODOC
- JP4083218B
- Application
- 50047397
- Application, DOCDB
- 50047397
- Application, EPODOC
- JP19970500473
Titles2
- Japanese
- マルチステップディジタル署名方法およびそのシステム
- English
- Multi-step digital signature method and its system
Classification
- CPC, 10
- G06F21/64
- H04L9/30
- G06F7/725
- G06F21/40
- G06Q20/02
- G06Q20/3829
- H04L9/085
- H04L9/3255
- H04L9/3265
- H04L2209/56
- IPC, 5
- G09C1 00
- H04L9 32
- G06F7 72
- G06Q20 00
- H04L9 08