Cryptographic system and method with key escrow function

The present invention relates to a cryptographic communication system. More specifically, the present invention relates to the secure creation, authentication, storage, and distribution of encryption keys used in cryptographic communication systems. More specifically, the present invention relates to a system of encryption key deposit and public key authentication management performed by a self-authentication chip device.

With the development and widespread use of precision computer technology and distributed data processing systems, the transfer of information in digital format has shown rapid growth. This information is used in financial and financial matters, e-mail, electronic data interchange and other data processing systems. Transmission of this information over unsecured or unprotected channels carries the risk of exposing the transmitted information to eavesdropping or alteration. Cryptographic communication systems protect the privacy of these transmissions by preventing unauthorized parties from monitoring messages transmitted over secure channels. Cryptographic communication systems also ensure the integrity of these transmissions by preventing unauthorized parties from modifying the information in messages transmitted over secure communication paths. Cryptographic communication systems also transmit by providing a verifiable, non-forgery and digitized, document-dependent signature that can prevent the sender from rejecting their message. The integrity and certainty of the product can be guaranteed.

Cryptographic systems require encoding or encryption of digital data transmissions to make digital data transmissions incomprehensible to all but the intended recipient, including digitized voice or image transmissions. .. A digitized plaintext message consisting of sounds, letters or numbers is numerically encoded and then the encoded message is a specified set of numbers or numbers, also known as an encryption key. Encrypted using a complex mathematical algorithm that transforms based on. An encryption key is a sequence of data bits that are randomly selected or have special mathematical properties, depending on the algorithm or cryptosystem used. Computer-implemented precision cryptographic algorithms are hundreds of thousands of bits long and can translate and manipulate numbers that can compete with any known method of unauthorized decryption. There are two basic types of cryptographic algorithms: symmetric key algorithms and asymmetric key algorithms.

The symmetric key algorithm uses the same encryption key for both encryption by the sender of the communication and decryption by the receiver of the communication. A symmetric key cryptosystem is built on the mutual trust of two parties sharing an encryption key for the purpose of using the cryptosystem to protect it from untrusted third parties. The most famous symmetric key algorithms are the National Institute of Standards and It is the National Data Encryption Standard (DES) algorithm first announced by Technology). This may be referred to in Federal Registration, March 17, 1975, Vol. 40, No. 52, and August 1, 1975, Vol. 40, No. 149. The sender's cryptographic device uses the DES algorithm to encrypt the message when it is loaded with the cryptographic key for its communication session (session key) (the length of the DES cryptographic key is 56 bits). To do. The recipient's cryptographic device uses the opposite algorithm of the DES algorithm to decrypt the encrypted message when it is loaded with the same encryption key used for encryption. However, before the desired communication between the sender and the recipient is made, the sender and the recipient must exchange the encryption key on a secure communication path that is not accessed by an unauthorized third party. Therefore, the validity of symmetric key cryptosystems has generally been questioned. This process of first ensuring that the encryption key is exchanged and then encrypting the communication only requires communication that is not spontaneous or solicited, as it is often slow and cumbersome. It doesn't work in situations that require communication between parties who are strangers to each other. In addition, an unauthorized third party interrupting the encryption key allows the third party to eavesdrop on both sides of the encrypted conversation.

The second type of cryptographic algorithm, the asymmetric key algorithm, uses different cryptographic keys for encryption and decryption. In a cryptosystem that uses an asymmetric key algorithm, the user makes the encryption key public and the decryption key is secret (secret), so it is not feasible to extract the secret decryption key from the public encryption key. Is. Therefore, anyone who knows the public key of a particular user can encrypt the message to that user, while only the user who owns the private key corresponding to that public key can decrypt the message. .. This public / private key system is incorporated herein by reference in the November 1976 IEEE Bulletin on Information Theory, Diffie and Hellman, "A New Direction of Cryptography. And was first proposed in US Pat. No. 4,200,700 (Hellman et al.).

Early types of asymmetric key algorithms allow secure communication over insecure channels by interactive creation of encryption keys during that session of communication. When using the asymmetric key algorithm, the two interacting users are simultaneously and independently uninferrable by the eavesdropper and are used symmetrically to encode that session of communication between the users. You can create a secure encryption key that you need to use. This interactive method of creating secure encryption keys was described by Diffie and Hermann in their 1976 treatise. Under this conventional method, known as the interactive Diffie-Hermann method illustrated in Figure 2, two users A and B each randomly select secret numbers 21 and 22, and then 2 Calculate intermediate numbers 23, 24 using two publicly known numbers and secret numbers 21, 22 selected by the user. Each user then sends intermediate numbers 23, 24 to the other user, and then uses their own secret numbers 21, 22 and the intermediate numbers 24, 23 just received from the other user to keep secret (symmetrical). ) Calculate the encryption key 25. The interactively created encryption key 25 is then used to encrypt and decrypt the communication session in a symmetric key algorithm communication manner on a otherwise insecure communication path. Used by both users as a DES or other symmetric encryption key. This interactive process requires only a few seconds of real time, and all digital communications, including digitized voice or image transmission during a particular session, simply press a button at the start of the session to initiate the interactive key exchange process. It can be encrypted just by doing. Because all the numbers selected in the interactive Diffie Hermann key creation method are so large that it is impossible to reverse the calculation and the eavesdropper cannot calculate the private encryption key. Communication privacy is maintained. To calculate in reverse Is not possible, so each user knows that any communication received using this algorithm has not been modified and was sent only by the other user, thus maintaining the integrity and certainty of the communication. Dripping. However, this interactive key exchange method requires stakeholders to interact in real time to create an encryption key, which is not effective for unsolicited communications or unfamiliar parties. There is. In particular, the interactive Diffie-Hermann key exchange method is suitable for stored communication email-style message communication and long-term storage of documents in electronic data storage systems because the recipient is not online to negotiate a session key. Does not work.

A modified non-interactive Diffie-Hermann method known as Authenticated Diffie-Hermann can be used when neither party is online. The authentication steps for the authenticated Diffie-Hermann session key creation method are shown in Figure 3. A future recipient, a user, randomly selects a secret number 31 (his private key), then uses two public numbers 32 and the secret number 31 chosen by that user. , Calculate intermediate number 33. The user then sends proof of identification, along with the intermediate number and the two public numbers whose numbers together form his private key 34, to the authenticating authority, which then issues the authenticating authority. Issuees a public key authentication 35 with a digital signature 36 by linking the user's authorization to the user's Diffie Hermann public key information 34. The public key 34 exposed by that user does not change until the user re-enters and selects another private key 31. Message communication using the authenticated Diffie-Hermann method is shown in Figure 4. To transmit a message to that user, the sending user first obtains the receiving user's authentication 35 and verifies the signature 36 of the authoritative authority to authenticate. The sender then uses the recipient's intermediate number 33 (from recipient authentication) and the sender's own private number 41 (his private key), which he randomly selects, to use the session key 42 for that communication session. To calculate. The sender then uses the session key 42 to encrypt message 43 and puts its own unencrypted intermediate number 40 at the beginning of the communication. As soon as the recipient receives the communication, it calculates the session key 42 using the sender's unencrypted intermediate number 40 and its own private number 31 (that is, the private key), and then the session key 42. To decrypt message 43. Session keys created by the authenticated Diffie-Herman method, as in the case of using the interactive Diffie-Herman method, use traditional symmetric algorithms such as DES. Used by both parties to encrypt and decrypt communications during that session on an otherwise insecure channel. However, under the authenticated Diffie-Herman method, a trusted entity, the authority to authenticate, can sign the public key authentication of the receiving user so that the sending user can trust that the information contained therein is correct. You will need it. In addition, a private key that is randomly selected by the sender and used by the sender to calculate the session key and intermediate number for that communication is permanent to others (corresponding to the authenticated public key number). To avoid learning unique private key numbers, they must not be identical to the private keys associated with the sender's own public key authentication, and the sender creates them only for specific messages. It must be different from the short-lived private key or intermediate number that is used.

Another asymmetric key algorithm, called the RSA algorithm, named after Rivest, shamir, and Adleman, is described in US Pat. No. 4,405,829 (Rivest et al.), Which is incorporated herein by reference. And with the difficulty of factoring a number, which is the product of two large prime numbers. As with the interactive Diffie-Hermann method, the RSA algorithm is relatively simple to calculate, but in practice it is infeasible to back-calculate. Therefore, it is not feasible to extract the private key from the public key, and thus the privacy of the communication is protected. Once the message is encrypted with a public key that uses the RSA algorithm, only the private key can decrypt it and vice versa. As with the authenticated Diffie-Hermann method, the RSA algorithm requires a trusted entity to authenticate and expose the user's public key. However, in contrast to both Diffie-Hermann methods, the RSA algorithm does not itself create a "session key" that is commonly used by both parties. Instead, a public encryption key for a particular user directly encrypts communications to that user, and that user's private decryption key decrypts those communications encrypted using the user's public key. .. Thus, the RSA algorithm is a purely asymmetric key algorithm.

However, because the RSA algorithm is complex and requires the indexing of messages by a very large number, it takes a considerable amount of time to encrypt or decrypt a message of reasonable length using the RSA algorithm. Therefore, it is much simpler, faster, and more efficient to use the RSA asymmetric algorithm to transfer the DES encryption key used in the symmetric algorithm. This traditional mode of operation is known as RSA key transfer and is shown in FIGS. 5 and 6. For example, referring to FIG. 5, a user can create a random DES key 51 and use that DES key to encrypt message 52. The user then encrypts the DES key 51 with the intended receiving user's public RSA encryption key 53 and transmits the DES-encrypted message 54 with the RSA-encrypted DES key 55 to the receiving user. .. After receiving the transmission, the recipient decrypts the DES key 51 using his private RSA decryption key 56 and decrypts the message 52 using that DES key 51, as shown in FIG. To do. Symmetric DES keys are used to encrypt and decrypt actual messages because DES algorithms require much less time and cost to calculate than RSA algorithms, while asymmetric RSA keys are symmetric DES keys. Used for encryption and decryption of.

The RSA public / private key cryptosystem also provides digital "signatures" that are both message-dependent and signer-dependent, that the received message was actually sent by the sender, and that the message was received unaltered. Can be used to authenticate that it has been done. RSA digital signatures allow a user's private key to decrypt only communications encrypted using that user's public key, in addition to allowing the user's private key to be decrypted only by that user's public key. It is based on another characteristic of RSA that allows you to encrypt messages that can be encrypted. Since only the user has the private key, using the private key for encryption allows for authentication of the source, which can be verified by anyone accessing the user's public key. In practice, the sender first encodes the message text using his private key into a signed message that anyone can decrypt, but whose source is only that sender. If desired, the sender can then optionally use the recipient's public encryption key to encrypt the signed message to be transmitted. Upon receiving the encrypted text, the recipient decrypts the encrypted text with his private decryption key, if necessary, and decrypts the signed message with the sender's public encryption key. Only the sender will send a particular "signed" message because only the sender knows his own private key. Therefore, the signature confirms the sender's identity. Also, since only the recipient has the sender's public key, the sender cannot claim that the recipient or an unauthorized third party has altered or forged his message. Therefore, the signature prevents the sender from denying the message. In addition, neither the recipient nor an unauthorized third party can modify the message, as only the sender's private key translates the original message and only the sender knows his or her own private key. Would have been. Therefore, the signature authenticates the integrity of the message.

The RSA algorithm also uses the hashinq feature to provide another type of digital signature that creates a short message description that is unique to each document. Figures 7 and 8 show creating an RSA signature and verifying an RSA signature using the hashing feature, respectively. The hashing feature is "one way", that is, making it infeasible to reconstruct a document from hashed results, and "no conflict", that is, creating another document that hashes to the same description. Another complex mathematical algorithm that makes it infeasible. As shown in Figure 7, the sender first passes message 72 using hashing algorithm 73 to create message description 74, then encrypts the description with his RSA private key 75. Form a concise digital signature 74 attached to message 72. As shown in FIG. 8, after receiving the transmission of message 72 and the message description 76, the recipient uses the sender's RSA public key 77 to use the sender's RSA encrypted message description 76 ( Decrypt (digital signature). The recipient also uses the same hashing algorithm 73 to create a message description 74 from the received message. The two message descriptions resulting from the two transformations performed by the recipient must be the same, thus ensuring that the message was signed by the sender.

Another system of digital signature, called DSA, which stands for Digital Signature Algorithm, can also be used to verify the sender. The DSA algorithm is disclosed in US Patent Application No. 07 / 738,431, which is incorporated herein by reference in its entirety. The DSA algorithm uses its private key to encrypt or sign the message description after the sender passes the message through the hashing algorithm to create the message description, and the recipient publishes the sender. It has properties similar to those of the RSA signature algorithm in that it uses a key to verify the encrypted description. However, unlike the RSA signature algorithm, which returns the original message description when the recipient decrypts the cipher block, the DSA verification algorithm results in only a clear verification of the validity of the signature. Communication encrypted using the intended recipient's public key cannot be recovered later by decryption using the recipient's corresponding private key. For this reason, the DSA algorithm works very well for digital signatures, but not for key transfers or direct message encryption.

For the public / private key system to work efficiently, users must trust the centralized key authentication authority to take responsibility for publishing and updating the public encryption key directory. The key authentication authority must distribute the correct public key for all users so that it is trusted by all users, both the sender and the recipient, and the message is not transmitted to the unintended recipient. To this end, the authenticating authority distributes each user's name and public encryption key information, as detailed above and below, and distributes its own digital signature for the purpose of authenticating the correctness of the information. Will be attached to the information. However, when the authentication process involves multiple entities, a hierarchy of entities, there are several different methodologies or "credit models" for determining how a user handles authentication. The three main models are (1) a pure hierarchical model, (2) a model that uses mutual authentication between multiple hierarchies, and (3) a "local credit" model. These models are reference documents, American National Standards (American), which are incorporated herein by reference in their entirety. National Standard) X9.30, "Public Key Cryptography Using Irreversible Algorithms for the Investment Information Services Industry: Part 3: DSA Authentication Management" (American Bankers Association, 1992, Washington, DC) To. Although there is still no general consensus on which of the above credit models is the best, through this disclosure, a suitable, generally accepted authentication credit model requires authentication issued by multiple entities. It is assumed that it will always be established and adhered to when it becomes.

The public / private key system considers the privacy interests of users who wish to send and receive communications as individuals. However, there are also government law enforcement and national security interests that must be considered. The ability of the government to monitor or eavesdrop on otherwise secret electronic transmissions for law enforcement and national security purposes is beyond the reach of suspected criminals, terrorists, and foreign intelligence personnel. It must be protected so that it cannot be conspired. Telephone communications can be monitored by eavesdropping on the phone, but encryption algorithms prevent the encrypted data from being decrypted even by a strong cryptographic computer. Therefore, the increase in the amount and percentage of digital transmissions encrypted using advanced algorithms and digitized transmissions, especially for cryptographic devices, is widely implemented in telephones, computers, facsimile machines and all other data processing equipment. If so, it will play a role in frustrating or interfering with the government's electronic surveillance permitted by these communications laws.

One way for a government or other authorized investigator to monitor the communication of a suspected criminal is to give all users of cryptographic communication their secret decryption key to either private authority or the government. That is, it needs to be possible for either a private party or the government to be a trusted reminder of the user's decryption key. The government will then be able to access or access the private key to monitor all encrypted communications, if necessary for oversight. However, this method is not permitted to third parties, either due to government abuse of the secret decryption key, theft from a government or private party, or the illegal activity of a person in charge of the government or private party. On the other hand, it does not work because the protection measures taken against the possibility of leaking the secret decryption key are insufficient.

Another way to deposit a secret decryption key to protect both the interests of privacy and the security interests of law enforcement, both of which are incorporated herein by reference, March 1993. Silvio of CRYPTO92 By using a system such as the method described in No. 737. A user who wishes to authenticate his / her public key for the purpose of encryption by this method shown in FIGS. 9 to 11 must deposit his / her private key in the manner shown below. As shown in FIG. 9, the user first puts his private key 91 into multiple "parts" 92, each of which can be individually verified to be a valid part of the complete private key 91. Disassemble. The private key cannot be reconstructed without knowing all the parts or some specified number within them. The user then uses a special algorithm to identify that part as the correct part of the private key (95) and communicate this confirmation 96 to the master deposit center, as shown in Figure 10. Send each part to the depositary agent or agency 94 (93). See Figure 11, after receiving confirmations 96, 97 that each part of the private key is correct, the master deposit center issues authentication 98 for the user's public key 99, if it is a secret system and needs to be done. And only if the warrant or court order is followed, the law enforcement agency obtains the secret part of the private key from the depositary agent of your choice, recombines them, and monitors the user's communications. Make it usable with the guarantee that it can be used. This system guarantees the privacy of their encrypted transmissions and the government's ability to gain access to the encrypted transmissions when required. The probability of illegal or fraudulent activity is greatly reduced because none of the entities usually have access to the complete private key, and because the user chooses an entity that he or she trusts. It also increases the range of entities that qualify as deposit agents, thus endangering all deposit agents at the same time, thereby further reducing the disruption of all trusted transactions.

As a trusted authority to authenticate the authenticity of a user's public key, the Master Depositary Center regularly authenticates or notarizes the connection between the public encryption key and its owner's identity. Issue. Authentication of certainty ensures to the sender that the transmission to the designated public key user is actually received and read only by the intended recipient. Certification typically takes an internationally recognized electronic form, as specified in CCITT Recommendation X.509 and issued as an international standard by the International Organization for Standardization (ISO). An example of a public encryption key deposit authentication format is shown in Figure 12. Among the certifications are, among other things, the name of the organization or key management center (issuer) 121 that created the certification, the owner's public key 122, the owner's identity 126, the certification serial number 123, and the effective start and end dates. 124 is included. The issuer's digital signature 125 "seals" the certificate and prevents its alteration.

However, the US government has proposed, as a government (and perhaps industry) standard, another way to allow the government to deposit secret decryption keys and monitor communications. The US government has developed a microcircuit called a "clipper chip" that can be built into government and commercially produced telephone and computer devices. Clipper chips are low-cost chips that can be used for large amounts of cryptography and key management. The Capstone Chip is a more sophisticated version of the Clipper Chip with the addition of digital signature and message description features. Like other cryptosystems, Clipper Chips is a DES-like way of communicating telephone and digital computer data, called Skipjack, but a sensitive algorithm that uses 80-bit keys to scramble, but is symmetric. Use cryptographic algorithms. Each clipper chip has a unique serial number, a clipper family key common to all clipper chips, and a unique required by an authorized government agency to decrypt messages encoded by the device containing the chip. Symmetrical secret device key is set. When manufacturing a device with a built-in chip, the unique secret device key is split into two components (called "key dividers") and deposited separately in two key deposit databases or institutions established within the government. To. Police, prosecutors, and law enforcement agencies (collectively referred to as police) set up wiretapping devices on communications, obtained warrants to monitor or other legal authority, and issued warrants to two depository agencies. By presenting, access to these private device keys can be gained.

When a user of a clipper chip device wishes to communicate, he first agrees on a symmetric session key that uses it to encrypt the communication. You can use any method that derives the symmetric session key, such as the interactive Diffie-Hermann key derivation process, and any method that transfers the DES session key between users, such as RSA transfer. At the start of each communication, each user sends a police access field (LEAF) that contains enough information for the other to allow the police to eavesdrop on or monitor the communication. The considered form of Clipper LEAF is shown in Figure 13 (this description and Figure 13 are shown because the exact details, creation, and verification of the LEAF format are currently classified and "secret" by the U.S. Government. Note that both are reasoning to some extent). To form LEAF, the session key is encrypted first with the private device key. Then the device key encrypted session key, the sender device serial number and the original unencrypted session key checksum are both encrypted with the clipper family key to complete LEAF. Be transformed. The message is then encrypted using the selected session key. Both the session key encrypted message and the family key encrypted LEAF are transmitted to the recipient. As soon as the receiving user receives the communication, it first checks to see if LEAF is enabled and if the session key encrypted within LEAF matches the previously received session key. Load the received LEAF into your clipper chip. If LEAF is enabled, the clipper chip will decrypt the message using the previously received selected session key.

However, police who legally eavesdrop or monitor communications do not know the session key and must first decrypt the LEAF to obtain the session key. The agency interrupts the desired LEAF, decrypts the LEAF using the Clipper Family Key, and then transfers the chip sequence number from the LEAF and a court-ordered warrant or other legitimate authority to the Government Depositary. Present and instead receive two key dividers for the eavesdropping user's private device key. The institution combines the two deposited device key components and uses the resulting device key to decrypt the session key encrypted with the device key from LEAF. The session key can then be used to decrypt the actual message from the communication. Since each LEAF is considered to be passed between multiple users on the same communication medium, the requirement that the sender and receiver create LEAFs and validate the LEAFs of others causes police to create LEAFs. It is guaranteed to have a reasonable probability at the time of LEAF interrupt. In addition, this allows police to select and monitor only one suspected user by decrypting the LEAF created by that user, regardless of which user initiated the communication.

Unfortunately, the US government's clipper chip proposal has many technical problems, largely due to the fact that the deposited private key is permanently embedded in the clipper chip during manufacturing. The private encryption key for a particular device is burned onto the chip and cannot be modified, so in the event of a risk, the chip and possibly the entire device containing the chip must be discarded. Users of a particular device may optionally re-enter, re-deposit, or authenticate their device from the keyboard if they are suspected of being at risk or at regular intervals to avoid potential hazards. It is desirable to be able to fix it. Not only when users cannot re-enter or re-deposit from the keyboard, users of clipper devices have a choice of number of key deposit agents and identity choices used by the government to protect their private keys. Does not have. Instead, the private key split is deposited in two government-established deposit databases or institutions. Users cannot trust clipper chip devices because of the risk that the government may have full, abused or altered access to any transmission or transaction through the device. Users may also want their private keys to be deposited with more trustees than government-provided, in order to make their private keys more secure. If the concept of key deposit needs to be important, each user must be able to choose his or her own trustee to deposit his private key based on his desired credit level.

Government clipper systems are also believed to allow users to communicate symmetrically in real time and do not provide direct support for storage-forward email-type message communications. Before encrypting a communication, the sender and recipient must first agree on a symmetric session key that uses it to encrypt the communication. This key exchange is typically performed using the interactive Diffie-Hermann method, which is the only key exchange method believed to be supported by clipper chips. Therefore, users are limited to simultaneous interactive communications such as real-time voice communications and facsimile communications unless they wish to have their own key management system in place. However, in order to use storage transfer email message communication, the user can use the authenticated Diffie-Hermann method or the authenticated RSA key transfer method even if the intended recipient is unable to respond to the interactive online communication. Must be able to access the intended recipient's public key, such as by using. Stored email-type message communication is difficult because the government's clipper system is not believed to make this easy. In this way, government-sponsored standard systems tend to limit user communication capabilities to online dialogue.

Moreover, under government systems, a user's employer does not have access to the employee's encrypted data or transmission. An employer for whom an employee develops, communicates, or transmits confidential or exclusive data on its behalf must have the right to access the employee's data or transmission. Encrypted information is only available to specific employees who are directly involved in the use of the cryptosystem, and is not available to management or the board of directors who are responsible for the employees and who own the corporate data resources. Many situations occur. By encrypting data and communications, employees may develop new programs, products or technologies, use them for themselves, or engage in illegal activities and transactions without the employer's knowledge. Also, staff movements, reconfigurations, and storage facility changes can result in the loss of large amounts of information that was important enough to be encrypted at the time of encryption. Donn B. Parker, incorporated herein by reference. B. Parker) "Cryptographic and Business Information Disorders" (November 3-5, 1993, Invited Speaker Presentation at the First Annual AC Conference on Computer and Communication Confidentiality in Reston, Virginia) refer. Aside from the creator of the data or the sender of the transmission, the clipper chip allows only the government to access the transmission. An employer may seek a court-issued warrant to monitor employee communications, but inside in a more cautious manner by initiating a federal investigation whenever the employer is suspected. You may want to monitor officers.

In addition, forcing a sensitive algorithm that is embedded in the chip and is only available in hardware and available only from government-approved chip manufacturers causes the government to undergo rapid change, communications and computers. It will enter a market where hardware competition has intensified. Government agencies or government-licensed manufacturers cannot design, sell, or voluntarily design and sell advanced devices and products specifically made for specific companies, as private manufacturers do. It may not be. If the government allows only certain vendors to manufacture chips with confidentiality algorithms, competition will be lessened and technology will be prevented from being incorporated into other products. In addition, the details of the skipjack algorithm have not been made public, raising doubts about whether the algorithm is unsafe, either due to its designer's oversight or the careful introduction of bypass intrusion measures by the government. .. An important value of cryptosystem design is that the privacy and confidentiality of encrypted messages should rely on the secrecy of the associated key values, not the secrecy of system details.

Therefore, it is desirable to use published algorithms to provide a commercial key deposit system that inspires the trust and trust of users and solves the problems posed by national security and police demands. It is also desirable to provide a commercial key deposit system that utilizes a private key that the user can change at will or at regular intervals.

In addition, it is desirable to provide a commercial key deposit system that allows users to select a key deposit agent to protect their private key or a separate part of the private key. While including safeguards against unlimited government access, it is also desirable to provide a commercial key deposit system that allows the employer of the user or a foreign user to access it by the country in which it is a citizen.

It is also desirable to provide a commercial key deposit system that provides an alternative to the clipper chip system proposed by the US government.

<p> A primary object of the present invention is commercial use of published algorithms to operate in a manner that inspires the trust and trust of users and to solve problems posed by national security and police demands. To provide a key deposit system. A second object of the present invention is to provide a commercial key deposit system that utilizes a private key that the user can change at will or at regular intervals.</p><p> A third object of the present invention is to provide a commercial key deposit system that allows a user to select a key deposit agent to protect his or her private key or a separate portion of the private key. A fourth object of the present invention provides a commercial key deposit system that provides protection against unlimited government access, but allows access by the country in which the employer or foreign user of the user is a citizen. That is.</p><p> A fifth object of the present invention is to provide a commercial key deposit system that provides an alternative to the clipper chip system proposed by the US Government.</p>

<p> The above object and the other object of the present invention are for verifying and dividing a user's private encryption key into components and transmitting those components to a trusted agent selected by a specific user. By providing cryptographic key deposit systems such as the Micali "fair" deposit scheme, and by providing systems that utilize modern public key authentication management enforced by chip devices that also perform self-authentication. Is achieved in accordance with the principles of the present invention. In the embodiment of the present invention, the new chip is used only when certain conditions are met, that is, (1) valid "sender authentication" and valid "recipient authentication" are entered. If "valid" means that the secret decryption key of a particular user has been deposited so that it can be authenticated by a specified number of deposit agents, and that the master deposit center is registered and authenticated by the chip manufacturer. Sufficiently for an authorized investigator to request and obtain the key deposited with it, as well as (2) a valid message control header created by the sender and verified by the recipient. Authenticate or decrypt only when you get the information. Because the invention relies on a system of authentication management, unlike a pure online system, the invention can be very flexible regardless of location and time. The method for depositing a private encryption key and receiving a deposit certificate is described herein in which a trusted device is registered with a trusted third party so that the device can communicate with other trusted devices. It also applies to the more generalized case of obtaining permission from the person concerned.</p><p> More desirable embodiments of the present invention include a step of depositing an asymmetric encryption key used by a plurality of users at a trusted depository center, a step of confirming each of the plurality of keys at the depository center, and the plurality of steps. Among a plurality of users, a step of authenticating each permission of the key at the time of confirmation and a step of initiating communication from each of the plurality of users using each of the plurality of keys on condition of the authentication are configured. Realize a way to create an authenticateable and trusted communication. Further, embodiments of the present invention include decoding of communications based on the use of message control headers entered in each communication by authorized police agencies, use of special police decoder boxes, abuse by police and other officials. In order to prevent this, the police will also audit the eavesdropping device. A more preferred embodiment provides keyboard re-entry and upgrade of the device using an authentication system, and encryption of stream-oriented data.</p><p> The above-mentioned objects and other purposes and advantages of the present invention are related to the accompanying drawings in which the reference characters refer to similar parts throughout, and will become apparent in consideration of the detailed description below.</p>

Hereinafter, examples of the present invention will be described with reference to the drawings. Public key cryptosystems, including the use of digital signatures, may be the basis for the creation of paperless electronic document systems that do not use national or global documents. The use of these systems will have enormous commercial implications in terms of cost savings. A key element in the development and dissemination of these systems is the trust placed in the underlying cryptographic systems and digital signatures by other users, including government, banking, corporate and individual users. Trust in these systems should not arise from trust in each user's own internal system or other users, but from trust in each user's public key cryptosystem and the authentication mechanism it provides. The commercial cryptosystems according to the invention calm these concerns by performing self-authentication and thus using trusted cryptographic devices as a fair and fair arbitrator of credit.

In a preferred embodiment of the invention, a chip that performs encryption, decryption and digital signature, is tamper-proof, or has a chip built into a trusted device that prevents tampering. Embedded with a unique uncorrectable public / private signature key pair and "Manufacturer Certification". Embedded manufacturer certification is that the device containing the chip (a) digitally "signs" documents and communications using a dedicated secret device signing key, which is uniquely created from that device. By allowing it to be certified and (b) attaching the manufacturer's certification to documents and communications, the device being created is one of the known and trusted types and was created by that trusted manufacturer. Therefore, it is possible to authenticate that those data structures are credible. In fact, the manufacturer's certification states: "The device whose private key matches the public key authenticated in this document is XXX. Signed, manufacturer." Documents and communications issued by the device and signed using the private signing key are also trusted because the private signing key is embedded to prevent fraudulent activity and because the manufacturer is trusted. It will be.

Preferred embodiments of the present invention have eight important stages of use, as described below. (1) Creation or manufacture of chips built into the device, (2) Registration of the device's encryption key with a depositary agent, (3) Successful encryption and decryption of user messages, (4) Allowed Decryption of communications by police agencies, (5) device rekeying and upgrades by owners or employers, (6) police wiretapping device audits, (7) stream-oriented data encryption, and (8) national security Security protection measures.

Manufacture of trusted devices The manufacture of trusted devices of the present invention is based on the presence of the following general features: (1) An embedded microprocessor (or microcontroller), a microcomputer that relays all external access and performs various computational and programming operations.

(2) Standard mathematical encryption and decryption operations can be performed much faster than general-purpose microprocessors, helping to create the authenticateable random numbers required to create encryption keys. An optional cryptographic coprocessor that is desirable to have a hardware noise source, such as a diode noise source.

(3) An input / output interface or subsystem that may be equipped with a status display or monitor to assist in the processing of data and command flows to and from the microprocessor. And (4) each can (a) read-only memory (ROM) that can store permanent and immutable programs and data, and (b) can store semi-permanent programs and data, that is, it can be modified. Can be used for electrically erasable ROM (EEPROM), or flash memory, which is not lost in the event of a power outage or power outage, and (c) temporary calculations and temporary data storage. Possibility to take advantage of multiple types of memory storage technology with various durability and accessibility features, such as random access memory (RAM), which is lost if electricity is cut off. There is a memory subsystem.

The entire device is designed to be protected from fraudulent activity in which all its elements, including permanent and semi-permanent memory areas, may reveal their contents or change their mode of operation. And manufactured. One way to protect device elements from tampering is to use a special dressing that is difficult to remove without destroying the information underneath the dressing. In addition, if an attempt is made to modify the physical enclosure in the memory area, or if the device's internal defenses stop working and attempt to destroy it, causing suspicious activity such as cooling the device to an abnormally low temperature. Besides, there is another function to erase the memory. Some of these protections may require constant battery power so that the device can take electrical action to remove sensitive data in the event of suspected fraudulent activity. There is. The present invention does not specify any particular desirable way to prevent the device from behaving erratically, but generally provides an acceptable degree of protection from unauthorized disclosure or modification of the data stored within the device. Relies on existing or future technologies that are or may be considered. Devices with these characteristics are sometimes referred to as secure modules (TRSMs) that prevent unauthorized movement, the current example of which is commercially available from Mykotronx, Inc. Clipper / Capstone device.

Chip manufacturing can be the manufacturing of many major computer microprocessor chip manufacturers. The manufacturer should be one known to the crypto industry and trusted for chip quality and the confidentiality and integrity of its manufacturing process.

Chips manufactured for use in the embodiments of the present invention will have the features shown below. First of all, the chip has an embedded device public / private key pair with a device signature issued by the device, in which case the private signature key is unreadable and does not behave illegally. Cryptographic signing keys can be of acceptable cryptographic types, such as RSA. However, since RSA has both cryptographic and signing functions, and it is desirable to isolate the signing process and the cryptographic process, it is desirable that the cryptographic signing key be DSA. In addition, the chip is embedded and equipped with the manufacturer's certification of the device signature key to prevent unauthorized movement, and an example of the format is shown in FIG. A device with a built-in chip may attach this signature to the signature for the purpose of certifying that the signature was created from a known trusted type of device with the quality described below.

In addition, the chip manufactured for use in the embodiments of the present invention comprises a manufacturer's public signature authentication key embedded in the chip to prevent unauthorized movement. The manufacturer's public signature key is for the purpose of determining whether the instructions received by the user were created by the manufacturer or by someone trusted by the manufacturer. It can be used to verify if those instructions have a valid digital signature created by the manufacturer's private signature key. The chip also includes an embedded tamper-proof public instruction key that can be used by the user to confirm instructions received from others. A public instruction key is a Bankers Trust company selected by the manufacturer. An entity trusted by an extra manufacturer, which may be the public key of someone else's trusted entity, such as Co.), or the authority of a trusted national or global system. It is optionally embedded in the chip by the manufacturer to be used as a "quick way" to avoid the need to verify certification against. The manufacturer installs multiple instruction keys for various qualified key deposit houses that the manufacturer considers to be competent and trusted.

In addition, the chips used in the embodiments of the present invention will have the ability to create public / private key pairs for encryption and decryption of data and communications by individual users. Cryptographic encryption keys can be of acceptable asymmetric cryptography, such as RSA. However, the encryption key is preferably Diffy Hermann. That is, the user's private number is the private key and the user's public intermediate number is the public key, both of which are authenticated to create the session key used to encrypt and decrypt the communication. Used in the Diffie-Hermann method. The private key created in this way is then stored inside the chip in a way that is unreadable and prevents tampering. In addition, the chip will also have the ability to re-enter and create a new public / private encryption key pair from the keyboard instead of the old key pair once the device's public / private encryption key pair has been created. Let's go. In another embodiment, interactive Diffie Hermann key creation can also be used to ensure that all senders and recipients contribute new random numbers to message session key creation, as described below. ..

In a preferred embodiment of the invention, the trusted device will have the ability to decrypt encrypted communications under only two conditions. The first condition is that valid master deposit center authentication for both the sending and receiving devices is provided into the device before the device receives the encrypted transmission. Each authentication is a master that authenticates that the device's secret decryption key is deposited with one or more qualified deposit agents, preferably two or more Mikari-style agents using an authenticateable key-splitting protocol. Valid if signed by the Depositary Center. This master deposit center certification is attached with another certification issued by the manufacturer demonstrating the designated master deposit center as a valid deposit agent, or is a public instruction key embedded inside the chip by the manufacturer. Must be signed by a third party designated as the holder (trusted national or global authority). The second condition of decryption is that the police or employer's security officer obtains the recipient's deposited private key from it and has enough data to monitor the communication. The point is that a valid Message Control Header (MCH) data field (whose format will be described later) must precede the target message.

In another embodiment of the invention, the chip has the ability to create a public / private key pair used for user signatures, separate from the embedded key pair used for device signatures. As with the device signing key pair, the cryptographic user signing key will be an acceptable cryptographic type, such as RSA, but again, to avoid possible confusion with the key used for message encryption, the DSA Is desirable. The user-signed private key must be unreadable and protected from fraudulent activity. The user uses the signing private key to sign his communication for the purpose of eliminating sender verification and denial. In another embodiment of the invention, the chip has the property that the user-signed key pair prevents known fraudulent activity by signing a request to authenticate the user public signature key that it was created for the user. It also has the ability to use the device signature key to authenticate that the private key was created by the device and protected by a device with known tamper-proof properties.

In another embodiment of the invention, the chip is a hardware noise source, such as a diode noise source for creating random numbers during key creation, and the device or its operation accounting system, network management system, and inventory. It also has a unique physical device serial number that allows the system to track it. In this embodiment, the device signature not only has the property of preventing the user's device from known fraudulent activity, but any key or random number created by the device is of high quality for which a diode noise source is desired. Authenticate a new random creation each time you use the random number generator.

In manufacturing a trusted device containing the chip of the present invention, the memory of the chip is divided into at least three general areas shown below. (1) Permanent and uncorrectable memory space to store data and firmware embedded in the chip during manufacturing, (2) Data and keys used for digital signing and decryption on behalf of the user Semi-permanent to store data such as secret encryption and signing keys that may be created for the user and delegated to the user by the chip, which may never be announced outside the device. And a modifiable memory space, and (3) a temporary, non-permanent memory space that contains the work area used to temporarily store the inputs, intermediate results, and final results of various data processing operations. .. Depending on the design, these three common areas are ROM for permanent data, EEPROM or FLASH memory for delegated user data, and RAM for volatile temporary storage. Residents in different types of memory storage systems. Another approach is to utilize FLASH memory for both permanent and non-permanent data. However, another approach is to take advantage of a chip operating system that manages microprocessor memory using a directory of objects. With this approach, some of the memory can be dedicated to a table or a directory of other items in memory, and each object can contain standardized information such as:

-Logical name (for example, "Manufacturer's public key")-Type (for example, key, authentication, code routine, etc.)-Start address and data length (in bytes)-Last modification date (optional)-Protection level (for example) Permanent, user, or volatile) -announcement level (externally readable or externally unreadable) In this way, if the entire memory equally prevents tampering, the microprocessor associates the data object. You do not need to specify a special area for protected or unprotected data because you can easily enforce the desired level of protection based on the code stored in your directory entry. This technique applies to firmware code routines as easily as it does to data, updating or replacing trusted firmware code routines without the need to physically replace any of the devices or their memory units. If you do, you can apply it to your advantage.

The protected memory area of the device of the preferred embodiment of the present invention stores the following types of information, including both data and firmware program code. A. Permanently embedded information by the manufacturer 1. Can be published externally a. Public key for all system authorities (optional) b. Manufacturer public key c. Manufacturer certification from authority for all systems d. Device Public key e. Device authentication from manufacturer f. Device-only serial number g. Firmware version number h. Trusted bank public order key 2. Cannot be announced externally a. Device private signing key 3. Firmware a. Operating system and File system b. Basic crypto library routine c. Deposit system route d. Other trusted application code B. Created by the user's actions and delegated for the user 1. Can be published externally a. User's public crypto Key b. User's public encryption key Deposit authentication c. User's public signature key d. User's public signature key authentication 2. Cannot be announced externally a. User's private encryption key b. User's private signature key C. Other Non-volatile read / write storage area (optional) a. Communication person's signature authentication b. Communication person's deposit authentication c. Communication person's device authentication (for MCH confirmation) D. Work area (may be volatile) Public key (All types), Authentication (All types), Hash value, Signature block, and other data structures in process.

Key Deposit Process Before the chip of the invention is manufactured and the chip is used to encrypt or decrypt communications, the user's public encryption key is registered with the master deposit center or a deposit agent authorized by the chip manufacturer. Must have been. The user either performs this action himself, or the manufacturer is freed from the requirement to initialize the chip being manufactured and register it with a deposit agent, thus freeing the user from depositing his or her own key. However, the manufacturer still leaves the user with the option of retyping themselves from the keyboard at a later point. For many individual users, it may be sufficient to allow the manufacturer to register the chip, with or without the rekeying option. In addition, consumers will inevitably rely on the depositary agent chosen by the chip manufacturer. Businesses and other employers program their tips and employee tips and register the tips with a deposit agent of their own choosing. However, as mentioned earlier, companies typically do not allow their employees to rekey on their own, as this results in loss of control of company information and assets.

To create and register the decryption key, the user (or any entity that performs the action) is embedded in the chip and the chip undergoes specific steps of the Mikari key deposit method or the special key deposit method used. Call a firmware program that commands it to run. See FIGS. 9 to 11, 15, and 16. Using the method chosen to deposit the private key with one or more deposit agents, the tip is first required (if those numbers have not already been set by another previous random creation). Randomly create or select a secret number that will be the user's secret decryption key (not just any other public number). The chip stores the private key in a way that is unreadable and prevents fraudulent activity. As shown in FIG. 15, the secret decryption key can be deposited with a single deposit agent. The trusted device 150 first creates a public / private encryption key pair 151 for the user and then configures the deposit center 153 with an encrypted and signed encryption key pair 151 and a device serial number 154. Message 152 is sent with the manufacturer's certification 155 for signature verification. The deposit center 153 verifies the signature, decrypts the message packet, and stores the user's secret decryption key. The deposit center 153 gives the user a signed authentication 156 consisting of the user's device serial number 154, the user's public encryption key 151, and the device's public signature authentication key 157 for signature verification. Send with certification 158. Once the user's device confirms the deposit center's signature, registration is complete.

When the private key is deposited with two or more depositing agents, the chip divides the private key into multiple locations called key dividers according to a special formula. Using the Mikari deposit scheme and algorithm shown above and illustrated in Figure 9, the chip then uses a special Mikari algorithm such that each value is based on a mathematical transformation within one of the secret key locations 92. Use to calculate a constant value of 90. The chip then forms one shared packet for each user-specified trustee or depositary agent 94, with each shared packet 93 being a unique serial number for the user's device, one private key divider, and a consignment. Includes a set of values that allow a particular trustee to see the received private key as a valid part of the complete private key without giving the person knowledge of the complete private key. .. As described below, if the user is not the owner of the device, but is, for example, an employee of the employer-owner, the employer-owner does not need to obtain a warrant first, and the employee-user's private key. The trustee's shared packet will also include the unique identification number of the device owner and the authentication of the device owner so that it can be obtained. The chip then signs each trustee shared packet with a unique device secret signing key, attaches the manufacturer's certificate to transmit the chip, and the information transmitted thereby is known credit. Authenticate that it was created from a device of the type that was created. Finally, the chip will output each signed trustee shared packet for service by the user to a trusted depositary agent.

There is another desirable method in which the master deposit center confirms a separate key split by relying solely on trusted devices, without using the Mikari method. Using this method of identifying the key dividers shown in FIG. 16, the chip creates one random number for each key divider of the secret encryption key. The chip then forms one shared packet 161 for each user-specified trustee or depositary agent 163, and each packet contains a unique number for the user's device, one private key split, and Includes one of the random numbers. The chip signs each trustee shared packet with a unique device secret signing key, attaches the manufacturer's certificate 162 to the transmitting chip, and the information transmitted thereby is a known and trusted type of device. Authenticate that it was created from. As in the Mikari method, the chip outputs each signed trustee shared packet 161 for service by the user to the trusted depositary agent 163. In addition, the chip is addressed to the master deposit center, containing each deposit agent a random number specified in the key divider, as well as the user's public encryption key and the name of the deposit agent specified by the user. You must also compose a (encrypted) message.

However, since each trustee shared packet contains a private key divider, a third party accessing the communication from the user to the depositary agent can read the contents of all the shared packets of the user and obtain the complete private key. In order to reassemble, it is conceivable to rejoin the private key dividers without those packets. In that case, the private key would be used by the third party to decrypt and encrypt the communication in the name of the user. The best way to avoid this situation is to use an encrypted communication system when sending shared packets from the user to the depositary agent. The user chooses to deposit the user's private key, which authenticates that each authentication is signed by the Master Deposit Center and that a particular depositary agent is trusted by the Master Deposit Center to receive and store key split packets. Obtain public encryption key authentication 166 for each deposit agent, and then use authentication from the device manufacturer (or from the authority of the entire system), or with a pre-embedded instruction key. And confirm the signature of the master deposit center. The device then encrypts transmission 161 containing the user's key-shared packet for each deposit agent based on the agent's authenticated public encryption key. Instead, the manufacturer, as described above, for each of the users to send their use key dividers to a deposit agent trusted by the holder of the instruction key, which is usually the master deposit center. The public encryption keys of multiple trusted deposit agents, matched against the instruction key, can be embedded in the chip. In this way, all deposit agents in the Master Deposit Center or the manufacturer's "family" request the user for deposit without burdening the user with the burden of obtaining public encryption key authentication for all deposit agents. To decrypt.

Once the deposit agent, or trustee 163, receives the appropriate shared packet 161 from the user or the user's device, the trustee inspects the used key divider received in the trustee shared packet 161 from the user's device. , With the Master Depositary Center 165, make sure it is a valid and correct part of the complete private key. The deposit agent and master deposit center must have a reliable means of authenticating or verifying that the user's secret decryption key fragment was actually deposited. Key splitting verification is accomplished by the deposit agent and master deposit center without ever inspecting or owning those fragments, or even bringing them together in one location. Is desirable. The Mikari "fair" deposit system provides one highly trusted way for deposit centers to identify separate deposit pieces of key fragments. In the Mikari method shown in FIGS. 10 and 11, this confirmation is calculated by the user's chip during the creation of the shared packet by using a special Mikari algorithm, and the key divider in each shared packet for the deposit agent. It is performed with some set of values included with. Confirmation of the Mikari algorithm and key dividers is known in the art and does not need to be repeated herein. Each trustee 94 then remembers the device manufacturer's authentication for later use during decryption and sends the appropriate signed message 96 along with the user's name and device authentication to the master deposit center. Then, the key division unit 93 is approved by signing and storing the key division unit 90. Only if presented with either (a) a warrant or court order, or (b) a signed request from the legitimate owner of the device, the trustee will have the specified secret decryption in possession. Will reveal one part (or multiple parts) of the key.

Using the preferred deposit verification method, which relies solely on trusted devices, as shown in Figure 16, each trustee 163 identifies the user's name, public encryption key, device number, and the random number it receives. Message 167 is transmitted to the master deposit center 165. In addition, the user device sends a packet containing a random number used to verify the private key divider to the master deposit center 165, and the packet is encrypted using the master deposit center's public encryption key. Need to be. The master deposit center 165 receives messages 164, 167 from the user device and trustee 163, and the individual random numbers received from each trustee are the random numbers that the user device described is designated as the trustee. Check if it matches. Note that in this method, the deposit agent 163 and the master deposit center 165 only trust the signature of the trusted device on shared packet 161 to ensure that the deposit is appropriate. This deposit verification method performs a secondary mathematical operation to verify that the deposit is appropriate or that the public key presented for authentication matches the deposited key fragment. No need. From the point of view of publicity, user or whole system credit, it is still desirable to utilize an authenticateable key deposit algorithm such as the Mikari process, but the increased cost of using such a process cannot be justified. This is clearly not necessary and can be exempted. Moreover, this method, which relies only on trusted devices, does not require devising complex secondary algorithms to verify the correct performance of the specified law, thus addressing the complexity of the key splitting methods that can be devised. There is no limit. You just need to trust the integrity of the manufacturer of the device that embeds the firmware code and that the device does not behave erratically.

After reviewing the private key splits for all users, the Master Depositary Center itself further approves the public encryption key that corresponds to the private decryption key approved by the trustees of all users. The master deposit center 165 authenticates that the private key corresponding to the public key to be authenticated has already been deposited in an appropriate manner (called master deposit center authentication, public encryption key authentication, or simply deposit authentication). ) Approve the public key by issuing a signed certificate 168. The user's device public signing key, obtained from the device manufacturer's certificate, is also included in the master deposit center certificate, thereby eliminating the need to send or reconfirm the device manufacturer's certificate at a later time in the process. Exclude. The master deposit center certification may be formatted as shown below.

Version Number Deposit Authentication Serial Number Master Deposit Center Country Code Master Deposit Center Name Master Deposit Center Public Encryption Key (for use when creating LEAF) User Distinguished Name (Authenticated by This) User Public Encryption Key (Device) User device public signature authentication key (for verifying signature) Valid date (start / end) Master Deposit Center Signature [Master Deposit Center All System Authentication]

The public encryption key authentication issued by the Master Depositary Center is distributed and used by the device owner to boot the device and initiate an encrypted message, or by someone else to publish the user. / Private encryption Can be used to encrypt messages to device owners that contain key pairs.

It should be noted that in the present invention, two or more deposit agents need not be the recipients of the user's private encryption key divider. In some cases, it may be sufficient to deposit the user's secret decryption key with a single deposit agent (or deposit center). However, in order to increase the trust of users and social systems, all key dividers or a specified number of key dividers are required for the purpose of reassembling the user's keys and decrypting the communication. , It is desirable to split the user's secret decryption key among multiple depositing agents. In addition, if each depositary agent is an independent and trusted business operation, thereby attempting illegal activity, bribery, extortion or abuse, the user may be more than if the private key is stored in a single entity. It is desirable to achieve "split knowledge" so that it is much more difficult to obtain the secret decryption key of. It is also desirable that the entities be geographically separated for the purpose of further curbing attempts at destruction or illegal activity.

Communication encryption A user who wishes to send an encrypted communication to another user must have a deposit authentication of his device and a deposit authentication of the intended recipient's public encryption key. This is because the device of the present invention does not encrypt or decrypt if either of them is missing. First, the sender must load its valid authentication into the device, generally the first time it is received from the master deposit center. After that, the intended recipient's public key authentication can be done directly from the intended recipient, from a directory service that lists the key authentication, or by the user with whom the sender has previously exchanged encrypted communications. Available either from the sender's local file, such as the file in. In one embodiment of the invention, the sender's device does not encrypt unless the recipient's public encryption key authentication is enabled in order for the recipient's device to decrypt the encrypted message. The recipient's public encryption key authentication is (a) the manufacturer of the recipient's device (the device manufacturer is probably not the private key of the user entrusted as a deposit, because the recipient's device does not decrypt. Therefore, this is an unlikely case), (b) the master deposit center, and the manufacturer's certification that authorizes the master deposit center as a valid trustee are attached, or (c) the instruction key is manufactured. Must be signed by either the trustee embedded in the device or the master deposit center. Recipient's Public Encryption Key Using the intended recipient's authenticated public encryption key specified in Authentication, the sender user can use the sender to encrypt and decrypt the communication. Create a session key for use by both recipients. This session key can rather be created using the authenticated Diffie-Hermann method, or an alternative equivalent system. In the authenticated Diffie-Hermann method, the user first randomly creates a temporary private key for the message and then owns it. Calculate the session key based on the private key and the recipient's public key (that is, the recipient's intermediate number and the two public numbers, all entered with the recipient's public encryption key authentication). Then, using the session key, the sender encrypts the message sent to the recipient user.

However, in deciding whether to send an encrypted message to the intended recipient, the sender is made by a different manufacturer than the manufacturer on which the sender's device used the recipient's device. If so, it may not be possible to verify the characteristics of the recipient's public encryption key authentication or the characteristics of the digital title on it. Due to the fact that the recipient's device was made by another manufacturer, the sender's device states that the manufacturer's signature or the recipient's master deposit center is valid and approved by that manufacturer. It will not be easy to verify either of the manufacturer's certifications (certifying the master deposit center that signed the recipient's key deposit certification). Similarly, the recipient's chip will not be able to confirm these conditions regarding sender authentication prior to decryption. Police legally interrupt and decrypt messages sent and received by designated suspicious users without necessarily obtaining the secret decryption key of other unmonitored parties, thereby not being monitored. Deposit restrictions on both parties will need to be enforced to allow access to irrelevant messages of the parties.

One way to deal with this issue, while still allowing more than one manufacturer to produce cryptographic devices, is for certification issued either within the device or by the user's master deposit center or chip manufacturer. During the disclosure of credible national entities such as the Fed, which the Federal Reserve Bank (FRB) uses to verify different certifications issued to each of various other master deposit centers and manufacturers. Embed the key. Such certification confirms the authenticity of a particular master deposit center or manufacturer and is signed by the Fed. Therefore, the master deposit center has been officially authorized by the Fed, not by the chip manufacturer, to be authenticated by the Fed's public key or authentication, so that the sending user can authenticate the intended recipient's public encryption key. Trust the Master Depositary Center that you obtained and issued the certification. Also, the signature of a particular device would be credible as it was officially licensed by the Fed by the other manufacturer who authenticated the device so that it would be authenticated by the Fed or public key. To handle this issue at a less local US-based level and further promote an international and global system, the public keys of credible global entities such as the International Approval Bank in Switzerland , Embedded in trusted devices (depending on the credit model used), FRB certification or master deposit center, or manufacturer certification, to officially authorize the master deposit center and manufacturer worldwide, the Fed It works the same as described for keys. Another way for one device to trust a deposit center that is certified by another manufacturer, although not involving US or world authority, is for the device manufacturer or master deposit center to mutually certify each other. Is. This is done by allowing the sender's device to see the authentication path of the recipient's deposit authentication from the recipient's device manufacturer or master deposit center to itself. Allows one's device to help enforce recipient deposit restrictions. In a preferred embodiment, the public key of a trusted system entity is embedded in a trusted device to officially authorize all master deposit centers and manufacturers on a system-wide basis, and the Fed or worldwide. Works in the same way as described above for keys of various entities.

Whenever any user, entity or device "verifies" a digitally signed "certification", most, whether it is a manufacturer's certification or deposit certification issued by the authenticating authority or manufacturer. Or in all actual and proposed public key authentication management systems, a list of revoked authentications that the user, entity or device is updated according to the appropriate security policy by the authority or other issuer to authenticate. Applicable "authentication invalidation" for the purpose of determining whether authentication has been invalidated based on the issuer name and authentication number, and whether to make it available for distribution, propagation, or otherwise. It is a common practice to also check the "list" ("CRL"), which is assumed in this disclosure. Authentication issued to a user may be invalid due to death, change of name or occupation, or loss, theft, or destruction of a device (personal smart card) with a private key. Authentication issued to an entity may be invalidated due to business termination, renaming, or loss, theft or destruction of a device with a private key. Authentication issued to a device may be revoked due to device loss, theft, outage or destruction. Checking CRLs during certification verification is well documented in published literature (such as ANSI X9.30-Part 3) and requires no further explanation. All users, entities, and devices can typically access the appropriate telecommunications facility and, if desired, search for CRLs and perform queries. Similarly, under the present invention, it is assumed that all entities issuing CRLs are available to all involved parties.

Message Control Header Format When sending encrypted communication, the sending user must also form an appropriate Message Control Header (MCH) field with the following information: (1) Calculated by the sender using the sender's randomly created temporary private key, which was also used by the sender to calculate the session key in which the message was encrypted using it. The intermediate number of the sender of the encrypted message to be. The recipient user must provide this intermediate number for the purpose of calculating the session key for decrypting the message.

(2) Sender's master deposit center name and country code. (3) The name and country code of the recipient's master deposit center, obtained from the recipient's public key authentication. (4) A transmission encrypted using the sender's master deposit center's public encryption key (obtained from the sender's deposit authentication) so that only the sender's master deposit center can decrypt it. Deposit authentication number of the person.

(5) Used by the sender to calculate a temporary session key to the sender's master deposit center where the sender's authentication number is encrypted (sender's previous intermediate number). (Different from) Sender's intermediate number. The sender's master deposit center must have this number in order to calculate the temporary key for decrypting the sender's authorization number.

(6) In fact, encrypted using the sender's own public key (the sender's own public authentication intermediate number), just as the sender sends the message session key to himself. The session key for the message. Police gain access to this message session key once the sender's private key fairness element is obtained from the sender's depositary agent.

(7) The sender's (unlike the sender's two previous intermediate numbers) used by the sender to calculate a temporary key in which the message session key is encrypted to itself. Intermediate number. Police must also have this number to calculate the temporary key for decrypting the message session key, also using the sender's private key obtained from the sender's master deposit center. (8) Receipt encrypted using the recipient's master deposit center's public encryption key (obtained from the recipient's deposit authentication) so that only the recipient's master deposit center can decrypt it. The person's authorization number.

(9) The recipient's deposit authorization number was used by the sender to calculate a temporary key encrypted according to the recipient's master deposit center (sender's past three intermediate numbers). (Different from) Sender's intermediate number. The recipient's master deposit center must provide this number to calculate a temporary session key for decrypting the recipient's authorization number.

(10) Timestamps (optional) to assist with follow-up purposes and warrant enforcement dates and time restrictions. (11) The signature of the sender's device. (12) Sender's public key deposit authentication issued by the sender's master deposit center. The sender's deposit authentication includes the sender's device public signature key, which is copied from the sender's device manufacturer's authentication after being confirmed by the master deposit center in advance.

(13) Certification of the Fed, manufacturer, or master deposit center of any trusted system authority that is added to the sender's deposit certification if the recipient's chip is made by another manufacturer. Certification of the manufacturer, Fed or all system authority is required only for the first communication between the two parties. The certification may be a mutual certification of the recipient's manufacturer or master deposit center.

The MCH described in this way is summarized as follows. (Allows the recipient to decrypt the message) Sender Intermediate Number Sender Master Deposit Center Country Code Sender Master Deposit Center Name Recipient Master Deposit Center Country Code Recipient Master Deposit Center Name For Sender Master Deposit Center Encrypted Sender Deposit Authentication Number (for encrypting the sender authentication number) Sender Intermediate Number Encrypted message session key for the sender (for encrypting the message session key for the sender) Sender Intermediate Number The recipient deposit authorization number encrypted for the recipient master deposit center.

Sender Intermediate Number Timestamp (for encrypting Recipient Authentication Number) Sender Device MCH Signature [Sender Deposit Authentication]

[Deposit Center Certification]. Figure 17 shows the process for sending MCH-encrypted message 176. The entire MCH172 (the additional credentials 173, 174, 175 are not technically part of the MCH) was signed by the sender's device 171 using the device secret DSA signing key and embedded by the manufacturer. Authentication is attached there (within the sender's deposit authentication) for the purpose of authenticating the device's public signing key. This ensures that the entire MCH is delivered to the recipient intact and that the recipient's tip can easily verify that the MCH has not been modified. The manufacturer's certification is accompanied by national (FRB) certification or global authority certification, and if the recipient's device is manufactured by another manufacturer, the sender's chip manufacturer's trust. May authenticate sex.

In another embodiment of the invention, a second shorter MCH format can be used in cases where complete privacy is not critical. In this MCH, neither the sender authentication number nor the recipient authentication number is encrypted for each master deposit center. Not encrypting the authorization number saves a considerable amount of time and space in creating the MCH. In another embodiment of the invention, a third shorter MCH format makes EC1 identical to EC2 so that both the sender and the recipient utilize the same master deposit center for the key deposit process in common. Can be used in the case of. By eliminating the need to identify information in the Second Master Depositary Center within the MCH and the special intermediate number used to encrypt the recipient authorization number in the Second Master Depositary Center. MCH can be significantly shortened. In addition, the size of the MCH can be further reduced by using RSA key transfer and encrypting the DES key on each of the message and the three encrypted internal LEAF components. According to this method, each sender intermediate number is replaced by a smaller RSA packaged DES key. Therefore, the sender RSA-encrypts the recipient's message session key, eliminating the need for the first intermediate number in the MCH. The sender also RSA-encrypts the message session key to itself (in fact, for police to decrypt later), thus eliminating the need for a third intermediate number within the MCH. The sender further RSA-encrypts its own authentication number and the recipient's authentication number, thus eliminating the need for a second and fourth intermediate number within the MCH. Eliminating the four intermediate numbers and their associated ciphers and replacing each intermediate number with the smaller RSA transfer cipher 181 saves a significant amount of space in the MCH size, as shown in FIG.

Contribution to random materials Message session keys exchanged using only the RSA key transfer method or the authenticated Diffie-Hermann method, when either of these two methods is used, both the sender and the recipient provide information, Some people are concerned that it is not secure enough because only the sender creates the message session key. However, under the military standards of secure communications, there is clearly a probability that the sender will use a weak key or use the same key repeatedly, thereby exposing the recipient to undesired unintentional security risks. To reduce, both the sender and the recipient must contribute random material in creating the session key prior to each communication session. The system of trusted devices considered in the present invention can mitigate this fear in two ways. First, the system ensures that the transmitting device creates each key separately using a random number derived from the noise of the built-in hardware noise source, such as an inverting bias diode, as described above. can do. The recipient is then guaranteed that each message session key and the random number used to create it are strong and unique, as long as the device signs the MCH, the message control header. Type-1 for Confidential Information As defined for military systems, those who claim higher security may still demand the contribution of random material from both sides of the communications.

During this disclosure So far, the sender is not based on the random material received from the recipient during the setup phase of the communication, but on the recipient's public encryption key as described in his deposit certificate. Has been described as creating a message session key. However, adjusting the sender to receive contributions from the recipient creates new problems. Recipients must not simply create their own Diffy-Hermann intermediate number and send it to the sender for use in creating the message session key. This is because, in that case, the recipient no longer uses the private key deposited within his trusted device to decrypt the message, and the communication is never monitored by police. For continued success in deposit law enforcement, neither the sender nor the recipient must be able to read the message without using a registered and trusted device.

In order to allow a situation where both the sender and the recipient contribute random material to the message session key prior to communication, the initial key exchange protocol is that the apparent recipient's device is separate. A new temporary that is used to calculate a new intermediate number that is sent to the sender for use in calculating the message session key for encryption of the message, away from the recipient's deposited private key. Modified to allow the creation of a Diffy Hermann secret number. The recipient's deposited private key will still be used to create intermediate numbers and temporary session keys used to encrypt various parts of the MCH. However, the fix is that the creation of a new secret number occurs within the fake recipient's device, that the new secret number remains within the trusted device, and that the new intermediate number is a new temporary secret. The number must be signed by the fake recipient's device before being sent to the sender's device in order to authenticate that the number is actually kept within the recipient's device. .. As before, the sender's device creates a new secret number that is separate from the sender's deposited private key and uses that new secret number and the recipient's new intermediate number to decrypt the message. Create a message session key for. The sender's device also uses the sender's new secret number to create a new sender's intermediate number that is sent to the recipient's device as an element of the MCH for the purpose of setting up an eavesdropping device. Therefore, in this scheme, the message session key contains random material contributed by both the sender and the receiver, if desired.

However, under this modified key exchange protocol, the recipient and sender will actually use the new Diffie Hermann private key for each message, so police and business management will use their temporary deposit agent. The deposit function still "disappears" so that the message session key can never be obtained. Therefore, deposit system needs and interested communities require message session keys to be forwarded within the MCH as before. In fact, all fields previously announced as part of the MCH remain intact to ensure equality of interception. The field of transferring the message session key to the sender (which is the only police way to eavesdrop on the sender to read the message) is still included in the MCH in order to uphold the principle of equality of interception. There must be. The message session key is still encrypted using the sender's public encryption key into the MCH, which police still have access to. The sender's new intermediate number is still sent to the recipient as the first element of the MCH to allow police to eavesdrop on the recipient and calculate the message session key. Therefore, in order to incorporate the interactive Diffie Hermann key exchange technique, this protocol pretends to be the only way that interested communities (police, employers and others) can read the message. The new intermediate number of the recipient needs to be created internally and signed by the recipient's device, and the new intermediate number of the sender may be used instead of the previously mentioned key transfer method. Needs to be added to the MCH. However, this method may not be economical for transactions other than online telephone, network, or dialing transactions because the device must remember, that is, the other party has too many special intermediate numbers. This method is purely real-time interactive

Interesting Header Community The MCH is usually placed as a message header before the encrypted message. In many current email and document systems, multiple recipients use the RSA transfer embodiment of the MCH design described above by RSA encryption of the message session key, which uses each recipient's public encryption key. You can read one encoded message. That is, if multiple recipients are intended to receive the same encrypted message, the MCH header will contain, for each intended recipient, the intended receipt using that recipient's public encryption key. Each person can contain the name of the intended recipient, followed by an RSA-encrypted message session key. In this way, each intended recipient can find his entry in the MCH header, decrypt a copy of the message session key, and read the message. The correctness of the MCH is enforced on both sides of the communication, even if there are multiple intended recipients. That is, on the sending side, the MCH output is enforced by the internal logic of the sender's device, that is, the requirement that it create a valid MCH before encrypting the message, and on the receiving side, the correctness of the MCH is. Enforced by verification of the digital signature of the sender's device by the recipient's device. As noted earlier, the recipient's copy of the message key is integrated into the MCH, so unless the MCH is transmitted and received intact, unlike a clipper system where the MCH itself is not linked to a key transfer mechanism. No recipient can decrypt the message.

Under this MCH format concept, MCH can be summarized as shown in Figure 25. As with the previous MCH format, the authenticity of the MCH is guaranteed by the digital signature of the sender's device 258. In addition, as before, the sender and recipient deposit authentication ciphers are encrypted under their respective master deposit centers 251, 252 public encryption keys. However, in this format, the MCH signed by the sender's device becomes a modified "list of recipients" that is more flexible and easier to understand with respect to the behavior of modern encrypted email systems. For example, the sender's name and recipient's name (or system ID or address) are now shown unencrypted in MCH253,254. This violates the anonymity of the sender and recipient, but in reality it is difficult for email systems to send a message untagged with the sender and recipient's name and address. .. Therefore, the loss of privacy is negligible. In addition, the sender's employer and recipient's employers 255, 256 names (or unique IDs such as tax numbers and DUNS numbers) are also shown unencrypted, which makes the employer confidential. The burden of finding messages sent and received by each employee of the protection staff is significantly reduced. Instead, instead of leaving the sender name, recipient name, and employer name blocks unencrypted, these entries state that the actual identifier is still in the encrypted area. It should be read as "sender," "destination," "sender's employer," and "recipient's employer" (or equivalent). Therefore, the intended recipient of the communication looks into the MCH in search of his unencrypted identification omission, thus addressing himself and only the portion of the MCH encrypted for whites. Decrypt and try to read.

In addition, the MCH format shown in Figure 25 allows subunits within the employer's organization to access by defining secondary employer lines (a, b, etc.). For confidential employers, the MCH is read as the unencrypted "sender employer subunit b" as described above, and the encrypted area contains the actual company unit. Each MCH entry is labeled, so there is no limit to how many layers of employer access can exist. That is, in a sense, all of them are authorized "recipients" of the message. In addition, in contrast to the previous MCH format, this MCH format eliminates the need for employers to go to the master deposit center and agents to obtain a message session key for message decryption. Can include a message session key encrypted directly for employer 257. Although it can violate employee expectations regarding privacy at work, this form allows employers to check or recover employee files with minimal effort.

In order to create an MCH in this format before sending a communication, the sender must first obtain all the required names / codes and public keys of the intended recipient and his employer. This information can be obtained from the recipient's deposit certificate and his own deposit certificate. However, in order to generalize this approach and make this information available to users who wish to send communications, the master deposit center employs, as mentioned above, in each user's standard form deposit authentication. Must include a unique identification or code number and public encryption key for both the person and the employer's subunits. Deposit authentication layouts can be created by using iterative subgroups to efficiently handle a variable number of "interested community" stakeholders. Each interested community stakeholder entry has a unique identification number, public encryption key, and an instruction code (or as described below) that tells the sender's device how to encode that stakeholder's MCH entry. Policy code) is set. The instruction code includes (1) the unique identification number of the party that is unencrypted or uses an alias such as "empl-a" on the sending device, and (2) the message session key of the coded area. Gives the option to include, or none, (3) a unique identification number of the party involved in the coded area, or none, and (4) a time stamp or random number at the beginning of the coded area, or none. Contains elements of choice. These (and perhaps other) opcodes could be defined as bitmask flags. A list of stakeholders (or their code, or both), their public encryption key, and instruction flags is part of the sender's device, the community portion of MCH's interests, according to each party's wishes. Orders how to format for anonymity or complete anonymity. In fact, many interested community members have revealed their names and identification numbers.

Decryption by recipient When the intended recipient receives the encrypted message 191 and MCH field 192, multiple things must be done for the recipient to read the message, as shown in Figure 19. In a preferred embodiment of the invention, the chip does not decrypt without deposit authentication, so first of all, the recipient must load his or her valid deposit authentication 193 into chip 190. Usually, the recipient's deposit authentication is already stored in the device's memory in a pre-confirmed state. The recipient then includes the sender on chip 190, MCH192, and (if necessary, with the appropriate full system, national, or global authority certification 195) the public signature authentication key of the sender's device. Deposit certification 194 must be loaded. The recipient's chip 190 checks the sender's deposit authentication 194 to see if the sender's private encryption key has been deposited. It uses the manufacturer's signature on device authentication, or, if necessary, the manufacturer's public key to verify the signature of the authority of the entire system on deposit center authentication, and the sender's deposit authentication. This is done by checking if the above deposit center signature is valid. In a preferred embodiment, the public signature key 196 of all system authorities is used to verify the direct deposit authentication 195. The recipient's tip is then (1) whether the sending device is trusted, (2) whether the sender's key is deposited as a deposit so that it can also be verified by the sender, and ( 3) Check the MCH signature before proceeding to ensure that MCH192 is valid, that is, whether MCH is properly formatted and contains all necessary information. This is done by verifying the sender's device signature, the sender's device manufacturer's certification signature, and, if necessary, the manufacturer's full system authoritative certification. The manufacturer's and all system authority's public key is a tip of the recipient to facilitate this verification process. Embedded in 190. In the simplest case, the recipient needs to verify the sender's deposit authentication 194 only once by comparing it with the public key of its embedded manufacturer or the instruction key of an entity trusted by the entire system. is there. Once these are shown to be valid for a particular sender, the recipient only needs to verify the MCH signature using the sender's pre-verified device public key, resulting in a message. One signature verification is done for each. If either sender's authentication 194 or MCH192 is invalid, the recipient's chip does not decrypt the message. Finally, after confirming these authentications and signatures, the recipient will be exposed to the message session key contained within the MCH, and the recipient's public encryption key authentication 193, based on the sender's intermediate number. Calculate the recipient's own private key (recipient's private number) corresponding to the key. The recipient uses the session key to decrypt the message sent by the sending user.

Decryption by police For the purpose of interrupting and decrypting communications to and from a particular user, police must obtain court permission or warrant to monitor that particular user's communications. The court's permission is ninety-nine out of ten, (1) the date and time when the police may start monitoring the user's communication, and (2) the police must not monitor the user's communication thereafter. "End" date and time, and perhaps (3) during that grace period, for police to further interrupt or monitor the user's additional communications, but only to decrypt previously interrupted communications. Includes a grace period following the "end of monitor" date on which the user's private key may be retained. When monitoring the sending user's communication, police interrupt the communication and identify the sender's master deposit center name and country from the MCH to determine who should request the sender's secret decryption key. To do. The police then use the MCH from the court's permission and interrupted communications to decrypt the sender's authorization number encrypted in the MCH, the sender's master deposit center. Present to. The sender's master deposit center uses the sender's authorization number to look up the sender's user's name and the sender's deposit agent's name, and the sender's later required by police during decryption. All of this will be revealed to the police, along with device manufacturer certification. The police then contacted each of the sender's deposit agents, presented the agent with the sender's name and warrant, and each deposit agent gave the key entrusted to that agent by the sender. Get the split. The preferred method of interrupting and decrypting encrypted communication by the police in the present invention is to use the decoder box specified below, so that the key divider is not for the police agency itself, but for the police. The request to the police deposit agent also includes the police decoder box's public encryption key so that it can be sent directly to the decoder box. Each depositary agent allows the decoder box to implement the terms of the warrant So, send your own sender's key divider to the police decoder box as an encrypted message with a "monitor start" date and a "monitor stop" date, as well as an optional "grace period". To do. The decoder box then decrypts the encrypted key divider message, combines the key dividers, and uses the sender's reassembled private key to send the message to itself by the sender. Obtain the session key for encrypted communication in the MCH as. Therefore, the decoder box can monitor and interrupt communications to and from the sender only during the monitoring period specified in the warrant, and only until the end of the grace period specified in the warrant. You can continue to decrypt the interrupted communication.

Similar procedures are used to monitor communications to and from recipients. From the interrupted communication MCH, police identify the name and country of the recipient's master deposit center, then decrypt the warrant and interrupted communication MCH, and the recipient's authorization number encrypted into the MCH. Present to the recipient's master deposit center that uses the private key to do so. The recipient's master deposit center uses the recipient's authorization number to search for the recipient's name and the recipient's deposit agent's name, all of which is revealed to the police. The police then contact each of the recipient's deposit agents and present the recipient's name and warrant to that agent. Each depositary agent sets a "monitor start" date, a "monitor stop" date and a grace period for the key dividers delegated to the agent by the beneficiary user for the execution of the warrant provisions by the decoder box. It is sent to the police decoder box as an encrypted message for the decrypted decoder box. The decoder box then decrypts the encrypted key dividers, combines them, reassembles the private key that results from the recipient, and calculates each MCH for the session key of the communication. Used with the sender's intermediate number at the beginning of. Therefore, the decoder box can monitor and interrupt communications to and from recipients only during the monitoring period specified in the warrant, and only to the end of the grace period specified in the warrant for those interrupted communications. Decryption can continue.

In another embodiment of the invention, the format of the encrypted key divider message for each deposit agent's police decoder box is as follows: User Authentication Number Private Key Fragment: X (i) Monitor Start Date and Time Monitor Stop Date and Time Court-approved grace period (days / hours) Date and time (in this key divider message) Deposit Agent Signature [ Deposit agent certification].

In this format, all information except the authorization number is encrypted with the encryption key in the decoder box. Key divider messages from the deposit agent are encrypted for that particular decoder box so that no other user or decoder box can read them.

In addition, the "monitor start" and "monitor stop" dates and times tell the decoder box when to start monitoring and decoding the communication and when to stop the monitor. The grace period allows the decoder box to have an additional specified time period to decrypt the backlog of previously interrupted communications, after which the decoder box stops decoding and erases the subject's private key. There must be. In this way, the decoder box is then capable of decoding the user's communication monitored until the date specified in the warrant, which prevents further decoding by the decoder box and its embedded time clock. Can be used. The decoder box refuses to process key divider messages that are set to have a message date and time that is more than 12 hours (or some other specified time period), or that has an expiration date and time that has already passed. Sometimes.

Realization of decoder box In a preferred embodiment of the invention, police utilize a decoder box that prevents special tampering to interrupt and decrypt the monitored user's communication under certain defined and controlled conditions. To do. An example of the decoder box and its processing flow is shown in FIG. The decoder box 200 is designed to be a trusted device with a similar design within the system of trusted devices of the present invention, and therefore enforces various conditions to prevent improper conduct by police. it can. The decoder box 200 comprises a secret device signature key embedded by the manufacturer and a manufacturer's public signature key authentication of the public signature key that matches the device secret signature key. In addition to manufacturer certification 202, the decoder box certifies or notarizes the connection between the decoder box and police or security authorities, certifying that the decoder box is under its exclusive ownership and control. Has certification 203 issued (or instead) by the police or corporate security department that owns the decoder box. The decoder box 200 also has the ability to create public / private key pairs for the encryption and decryption of management and control messages to the decoder box, similar to the conventional user chips of the present invention. The decoder box also securely stores its private key and issues the corresponding public encryption key within authentication 201 signed by itself, with its device authentication 202 signed by the manufacturer attached. Also has the ability to do. By providing the ability to create this public / private key pair, the wiretapping agent's deposit agent 206 is at the time the police issue a warrant to monitor the user's communication to the master deposit center. Then, the key division part 204 of the user who set up the wiretapping device can be sent to the decoder box encrypted using the public encryption key of the decoder box, and the decoder box sends the secret decryption key. Use those key splits You will be able to decode the part. However, unlike the normal user chip of the invention that decrypts the message and returns the unencrypted result to the user, the decoder box never outputs the private key of the user with the wiretapping device to the police agency. Instead, the decoder box securely stores this information until the end of the grace period specified in the warrant and key divider message, at which point the decoder box permanently erases the information.

Therefore, in order to perform its duties as a trusted device and to implement the date and time limits imposed by the authorities that set up the wiretapping device, the decoder box 200 is a trusted, calibrated and guaranteed date /. A time clock 205 must also be provided. To do. The decoder box manufacturer certifies and demonstrates clock effectiveness and calibration when the manufacturer issues device certification 202 with a list of its known device characteristics. When the decoder box 200 receives from the depositary agent 207 a key divider 204 containing a time limit for which the warrant is not valid before or after it (based on the warrant), the decoder box 200 uses its internal time clock 205 to use its internal time clock 205. Make sure the police warrant is still valid. If the warrant is not valid, the decoder box will not monitor or decrypt the communication of the user with the wiretapping device. When the warrant (and the applicable grace period) expires, the user's private key with the wiretapping device is erased and recreated by the decoder box with that warrant (unless a new warrant with a new time period is issued). It will not be fixed. The trusted time clock 205 is optional for the conventional user chip of the present invention, but is essential for the decoder box 200 to allow the decoder box to perform the date and time limits of the wiretapping warrant. It must be noted that. However, users of the user chip can usually assist in executing the time limit by maintaining the calibration of the chip's time clock. If the user's clock is not calibrated, the MCH created by the user's device during communication will have a null value specified in the timestamp field. In that case, the decoder box that interrupts the communication can execute only the monitor stop date of the warrant by refusing to perform the decryption after the expiration of the warrant and the grace period. Therefore, as long as the warrant is still valid, the warrant specified a null timestamp value. The decoder box cannot enforce the monitor start date because decryption of all MCHs is allowed, even if they were interrupted before the monitor start date and time of the warrant period. However, if the user's clock is calibrated, the police decoder box refuses to decrypt any MCH that has a valid and trusted time stamp on the date and time before the warrant's monitor start date and time. It is possible and will refuse. It is most desirable for the decoder box of the present invention to decode only communications that are reliable to be time stamped during the warrant time period. Thus, further exemption from possible abuse of the warrant's time period by police is expected to motivate users of the chips of the invention to keep their chips calibrated. In fact, if the data storage system uses the system to encrypt a large number of messages, it is highly desirable to enforce a time period for a later warrant or disclosure order. This is because many messages that are otherwise outside the scope of the legitimate order may be subject to inspection. If the system is used to do so, it is highly desirable to enforce a time period for a later warrant or disclosure order. This is because many messages that are otherwise outside the scope of the legitimate order may be subject to inspection. If the system is used to do so, it is highly desirable to enforce a time period for a later warrant or disclosure order. This is because many messages that are otherwise outside the scope of the legitimate order may be subject to inspection.

Police Audit Capabilities When using deposited cryptosystems, there are concerns that police could easily be acquired to obtain cryptographic keys that protect high-value data. For example, a well-funded member of a criminal entity first illegally intercepted the company's communications to obtain some message headers and deposit agent names, and then acquired low-paying police officers. A valuable industrial plan from a particular company by requesting a drug investigation warrant to obtain the company's secret decryption key from a depositary agent and finally stealing the plan using the secret decryption key. You may be able to steal the set. Cryptography is now used for secure communication between many computers, making it unacceptable for police to install eavesdropping devices in telecommunications systems that have minimal safeguards. A much stronger set of safeguards is needed to raise police procedures and control to the level of modern corporate computer security practices and prevent the occurrence of this type of situation.

One such safeguard for trusted devices is an internal counter for numbering each message control header, which is incremented with each access. The message sequence number (MSN) can be set in each encrypted message header so that it is not visible to outsiders. It is the source of the sender's public encryption key, along with the number (1) a copy of the sender of the message session key, and (2) the source of the public encryption key of the depositary agent, either the sender or the recipient. Or (3) preferably at least under the sender, the recipient, and the sender and recipient's depositary agent, and preferably under all parties within the interested community. It can be executed by encrypting the number with. However, the sender's depositary agent may choose to allow the sequence number to be disclosed in plain text on the grounds of saving space and the low risk of exposing it, as a matter of policy. .. Avoiding duplicate numbers in message control headers is important, and numbering gaps should be avoided as much as possible.

Another safeguard feature is to allow the user to include an optional secret "title line" in the message control header. If the user fears illegal interception with an inappropriate warrant, the user can encode a short title such as "Plan # 123" to alert himself and others to the content of the message. .. Alternatively, the user can simply store his own log of the message sequence number assigned by the device (using the mail software system) and the title assigned by the user. To save space, as is often the case, if no title is entered, the title line will be zero in length.

A third protection is to prevent the user or the police from later claiming that the content of the decrypted message is something other than what was actually sent, in the signature part of the message control header. To add a description or hash of. That is, for example, a user cannot replace a previously sent drug trade message with a harmless message, or a corrupt police officer can replace a valuable industrial plan stolen by an official with a drug trade or harmless message. right.

These safeguards can be used as additional security measures. First, the message sequence number created by the sender's device is used to track the message by both the sender and the recipient, as well as by both police and court mechanisms. Effective control of police access is difficult, especially in the enthusiastic pursuit of criminals, and court mechanisms may not necessarily carefully analyze police demands before issuing a wiretapping permit. Not possible, but as a result of the wiretapping device, use constant efforts to seek facts for the purpose of auditing the results of all wiretapping devices, random samples of the wiretapping device, or any suspected anomaly. Can be done. Therefore, the police trusted device, the Decoder Box, has a secure internal log of the message sequence number and the message description (and title line, if any) of the message it has monitored and allowed to be read by the police. Is modified to include. The electronic permission sent by the eavesdropping device-equipped user's depositary agent to the decoder box along with the user's key divider may also include the public encryption key and public signature key of the court that issued the warrant. Therefore, the decoder box can possibly meet the request to print a log of message sequence numbers and title lines encrypted under the key of a properly authorized recipient, such as the court that issued the warrant.

In another embodiment, the decoder box does not initiate decryption of the monitored communication until it receives a particular court order that matches the key split received from the depositary agent. For example, a key split message received from a deposit agent and encrypted using the decoder box's public encryption key, the public encryption key and public signature key of the court that issued the warrant (each deposit agent). Can be enhanced to include). Alternatively, the depositary agent will refer to the date and number (if any) of the warrant in their key split message and the decoder box will be attached by the court to the original wiretapping device installation permit. You will receive the court's public encryption key and public signing key as well as the court's public key authentication. For example, the court's permission for the depositary agent can be strengthened to convey the following data required for key split messages.

Master Deposit Center Name or ID Number Monitored User Authentication Number Court Name or ID Number Warrant Number (if any) Warrant Date and Time Monitor Start Date and Time Monitor Stop Date and Time Maximum number of messages (optional) [Judge's signature]

Judge's Authentication Judge's Witness Authentication (for example, court) Then the deposit agent puts each key split from each deposit agent into an encrypted key split message from the deposit agent to the decoder box. It may "reauthenticate" the court's public encryption and signing keys to the decoder box by including the following additional information that must be present in the department.

Master Deposit Center Name or ID Number Monitored User Authentication Number (Send This Key Split Message) Deposit Agent Name or ID Number Court Name or ID Number Court Public Encryption Key Court Public Signature Key Warrant Number (If Yes) Maximum Number of Warrant Date and Time Messages (Optional) Deposit Agent Stigma [Deposit Agent Authentication]

In this way, the decoder box receives a guarantee that all key divider messages came from the same judge and the same warrant.

Due to the fact that the decoder box also has the judge's public encryption key and public signature key, the judge can act as a post-eavesdropping device audit to protect the police from unjustified, illegal, or illegal activity. , The log of all message sequence numbers and message title lines interrupted by the decoder box during the eavesdropping device period can be requested and received (secretly). In addition, the decoder box states that the decoder box may do so, a monitored message until it receives a separate order from the judge or court, which is confirmed in comparison to the previously received public signature. Do not delete, erase, or reuse the memory allocated for logs. Such an order is issued either because the court has already received the monitored message log requested in the past from the decoder box, or because the court has determined that an audit is not required in this example. Monitored Message Logs When the memory storage area is full, logs are sent to the judge or court until a court-signed order is received that allows the decoder box to clear the monitored message logs. , The decoder box no longer decodes the message. New messages are not decrypted until the full message log is cleared for auditing, but police can continue to interrupt new messages until the monitored message log is cleared. The decoder box also has the ability to warn the police that the monitored message log is approaching capacity so that the decoder box can request uploading of the message audit log so that it does not stop decoding. These transactions and communications are fully automated and almost instantaneous.

Each entry in the audit log has a second description that is the result of (a) the message description plus (b) the full text of the previous log entry that was concatenated and re-edited together. included. This prevents dishonest court officials from adding, deleting, or rearranging entries in the log. This concept is explained in US Pat. No. 5,316,646 and US Pat. No. 5,136,647, which are incorporated herein by reference.

As a follow-up action, the court will later require police to submit the complete content of the message headers and message abstracts in the audit logs received by the court. Also, in its eavesdropping device installation permit, the court maximizes the number of monitored messages decrypted by the decoder box before the monitored message log and message headers have to be audited. Artificially limit to less than capacity. This type of restriction does not affect the police's overall investigative capacity, as downloading logs for auditing to the court is almost instantaneous, but may warn the court of an unusual situation. There is. In special cases that require stronger control than simply sending monitored message logs to the court, the court maximizes police before they have to seek a new warrant to monitor additional communications. It may be limited to the message log capacity or less.

Therefore, (1) both the sender and the receiver track the sequence number of the message they send and receive, associate the title line in the message control header, or log the message in its local software system. If (2) both the police and the court keep a complete log of each message decrypted by the police, and (3) each message header later for the parties to hide their actions. If the message description is included to prevent alteration of the message, a credible post-interception audit can determine if the police have abused or misconducted it. Although this system cannot deductively prevent the planned theft scenario described above, it is inappropriate police to know that the criminal entity is fully auditable by both the court and the target user. It will be a considerable check for the act of. It also records all messages interrupted by the police under a warrant and submits them to the court, especially if the subject is tied to a business entity and no criminal liability can be claimed based on the wiretapping device. It is a matter of the rule that the person who set up the wiretapping device can request an audit of the wiretapping device.

Stream-oriented data In communications involving stream-oriented data, such as telephones, where each communication consists of streams of multiple message packets from two or more users, the sender device hashes the entire message as part of the MCH. It is impossible to sign. It may be possible to send each packet of communication and MCH, but doing so is very costly in terms of processing time and network bandwidth. Therefore, the MCH should be sent only once during call setup. The preferred way to handle a continuous stream of encrypted data is to specify the calling user as the "sender" and, as before, be signed by the message sequence number (MSN) and device (if present). Is to negotiate the MCH at the start of communication, including the hash of the first packet. In that case, the sender's device creates a series of unique packet sequence numbers (PSNs) whose sequence starts from zero at the beginning of each communication. For all subsequent packets, the device simply hashes and signs that particular packet, including (signing) the hash of that packet, the MSH (as for the entire message), and the PSN. The caller refers to the caller's MSH of the communication, numbers its own packets consecutively starting from zero, and attaches the caller device to the packet hash, the caller's MSN, and the caller's. By having the PSN sign and thereby form a "packet control header" (PCH), it performs similar actions for each packet it sends. The device optionally includes the current time as an offset from the beginning of the communication (in milliseconds) that already exists in the previously disclosed version of the MCH. This allows the call to be played more realistically.

To further distinguish between caller packets and caller packets after communication, assign numbers to the parties involved in the communication, such as caller = 0, caller = 1, and the same encrypted session. It is desirable to have a call party code (CPC) with a simple coding method that allows additional parties to receive even larger numbers. Alternatively, instead of CPC, a device serial number plus the device manufacturer ID number, or a unique identification number such as the hash above, can be used.

These methods can also be generalized as methods for creating multiple joint session keys. For example, a caller can create a session key and use the same key to initiate calls with multiple callers using RSA key transfer at the same time. In that case, there would be a separate MCH for each party added after the first two parties (caller and caller). The caller's device can treat multiple joint calls as multiple separate calls or as a single call with the same session key but multiple CPCs. Therefore, each caller will be responsible for using the caller's MSN and maintaining its own CPC and PSN. Instead, assuming the use of traditional bi-joint session key creation methods (such as the Diffie-Hermann method), the core parties (such as the system operator) make all calls and of each party. There are conference phones that perform real-time decryption and re-encryption of packets on behalf of everyone else. The central party may also be an individual who temporarily connects to the next caller, in which case the caller's packet is decrypted by that individual's device before the caller. Is re-encrypted using the session key (s) used to communicate with other parties (s). See also Schneier's Applied Decoding Method, J. Willy, 1994, p. 276, for the use of Diffie Hermann in three or more parties.

The packet control header (PCH) can be formulated as follows. Original Caller's MSH User Call Participant Code (CPC) (Caller = 0, etc.) User Packet Sequence Number (PSN) Time Offset from Call Setup (msec) Hash [Device Signature]

In some systems that use short packets, it is desirable to send PCH only on a regular basis, rather than sending PCH for each packet of communication, as this results in considerable overhead. This is similar to a technique known as a "sliding window" in network communication, where packet arrays and retries are performed only on a large number of packets rather than on a packet-by-packet basis. Usually, such systems are based on line noise and dynamically "window", that is, adjust the number of packets sent during error checking, that is, make the window larger for clear lines, but many Make the window smaller for noisy lines that cause error retries. If errors occur frequently, the small window only requires the user to resend a small amount of data. If the error is rare, the check is performed occasionally, even if it is expensive to resend the lost data in the event of an error. Packet control headers can be integrated directly into the sliding window method of communication systems, thereby providing the desired ability to audit police actions down to the packet level, allowing maximum system throughput in modern communication networks. it can.

To further increase the auditability of the wiretapping process, it is useful to clearly mark the end of the communication session with some special packet. This packet goes unnoticed by the user to prevent either the user or the police from later claiming that the conversation was over or not when the opposite happened. , Automatically sent by each device to other devices before disconnection. This is done by instructing each device to accept the input "I want to hang up now" from that human user, so that the device sends a "ready to disconnect" packet, which is the other device. Have (there may be more than one) do the same. The device (s) terminates its data stream with a "final" packet that does not contain additional data but includes the sum of all packets sent and received, call hold time, and so on.

Timestamp Device Another feature of the invention in its preferred embodiment described above with respect to the decoder box is a timestamp device that prevents trusted fraudulent movement, which is digitally considered reliable by a third party. Self-authenticate that you can issue (or attach) a signed timestamp (or a data structure with such a timestamp). Such a time stamp device is Addison M Fisher (Addison) Explained in US Pat. No. 5,001,752 and US Pat. No. 5,136,643 by M. Fischer). In its preferred embodiment shown in FIG. 21, the time stamp device 210 (or subsystem) has a postage meter installed only by the local US Postal Service Office and thereafter only up to the amount paid in advance. Just as a postage meter stamp is not given and is calibrated and operated only by a trusted authority such as the manufacturer or the authority trusted by the manufacturer, much like it is trusted by the general public and the postal system. You can get started. Once calibrated, the timestamp device 210 (or subsystem) sends a "time setting" instruction 211 (ie, recalibration) to the manufacturer itself, or the manufacturer or manufacturer trusts the entity. Host Device Timestamp Responds only if a device (or subsystem) is installed and signed by either entity with an authentication 212 stating that it is trusted to calibrate. Perhaps the time-setting instruction operation temporarily owns the device physically, allowing the device owner to capture the instruction and play the instruction later to "set the device's clock to an earlier date". For the purpose of preventing sex, it will need to be executed by a person who has the time setting authority to immediately delete the time setting instruction 211.

Once calibrated and undisturbed, the time stamp device 210, based on its internal clock mechanism, attaches the time stamp 213 or the complete time stamp data in the structured data field as a result of its secret device key being set. Sign 214 the resulting data structure and provide its manufacturer certification 215. When the host device is turned off, interfered with by an instruction to stop itself, or receives an instruction to stop itself, the time stamp device stops issuing time stamps. In that case, to avoid compromising other valid features that do not require a trusted timestamp as an absolute matter, the timestamp device should have a structured data field if the structured data field requires a timestamp. Take advantage of conventions (or equivalent conventions), such as filling timestamp fields with pre-agreed "null" values such as all binary zeros and binary 1. However, if a structured data field or host device requests the actual time stamp to be issued, as in the case of the police decoder box, if the time stamp device stops issuing the time stamp, then the time stamp is required. The host device function does not work. In the case of a decoder box, the box refuses to decrypt the interrupted communication. To avoid or minimize the occurrence of power outages on the host device, each trusted time stamp device has its own separate long-lived clock dedicated battery 216, to prevent power outages before battery replacement of the time stamp device. It is desirable to have some "low battery" warning indicator and means to retain the proper charge during the battery replacement operation (such as a storage capacitor, a second battery compartment or an optional external power supply).

Each timestamp issued by the timestamp device is issued by the manufacturer (or another timestamp authority) and is not only the quality and reliability of the timestamp clock, the predicted timestamp clock drift, but also the timestamp clock. There will be a timestamp device authentication that describes the date that was last set. When the recipient user receives a data structure digitally signed by the host device, the recipient will sign and authenticate the device if the timestamp field is completed with a valid value, and the data structure will create and sign, And understand that it authenticates that the issued time is correct. This certification subsidy is (1) the authoritative reliability of the most recently calibrated timestamp clock, (2) the clock drift tolerance described by the manufacturer in the device certification, and (3) itself in the event of clock interference or power outage. Is based on the ability to stop. In addition, the recipient acknowledges that the timestamp clock was not in a trusted calibration state when the device created, signed, and published the data structure if a "null" value was specified for the timestamp field. to understand. It is desirable that this information about the credit characteristics of the timestamp device and its internal clock mechanism can be encoded directly during device authentication using appropriate attribute value coding methods. However, this information may also be suggested by the manufacturer name and device type that the manufacturer publishes in the specifications and performance certification as part of the "policy" that is publicly stated when the device certification is issued.

Such time stamps may also be issued by the device as part of other message processing operations other than MCH creation and decryption. These time stamps are attached to the user's personal signature on the device when the user signs another document or transaction using his or her personal signature key, which is securely confined inside the device. Will be done. The device either signs or co-signs the timestamp element of the user's signature, or instead, on top of the entire user's signature block (also signed by the user, along with the document hash result message description). Will sign. Therefore, the device provides its certification so that a third party who knows the manufacturer's public key can believe and trust the time stamp.

Trusted upgrades, replacements and rekeys Another feature of the invention is any firmware routine embedded by the manufacturer, including an embedded manufacturer's public key, a protected non-volatile memory area, and a secure central processing unit (CPU). A trusted device that prevents fraudulent activity that can be upgraded or supplemented in a trusted manner. A trusted device is suitable for that type of device and performs an upgrade or supplement by accepting as input the body of data containing a new or additional firmware code that is digitally signed with the manufacturer's signature, and that signature A new firmware code has been created, tested, approved by the manufacturer, and therefore the device either (a) overlays one or more currently embedded firmware routines with the new firmware code, or (b) a new firmware code. Guarantee the device that it should be added as one or more new routines within the currently unused area of protected memory. In a preferred embodiment, the protected memory can hold its information indefinitely while it is off, but it can also be erased by the device (albeit at a relatively slow speed), if desired. It will be a reusable FLASH type. Protected memory is encrypted, with the code being upgraded or captured, whose decryption key is known only by trusted devices, regardless of whether fraudulent activity is prevented. It also includes data storage areas (such as disk drives) that are stored in a format. When the device receives such a signed body of the new firmware (or software) code, the user enters the code with the manufacturer's signature and issues a "firmware upgrade process" instruction to the device. The device then verifies the manufacturer's signature using the manufacturer's public signature key embedded within the device during manufacturing. Manufacturer's office

The trusted upgrade process for the firmware of the trusted devices mentioned above functions like the current key deposit system, designed and managed by the Bank Master Depositary Center, primarily independent of the trusted device manufacturer. It can be further extended to include authorized third parties who wish to upgrade their firmware routines for device features related to those third parties, including. In the case of a third party upgrade, the manufacturer signs a firmware upgrade certificate containing the public key of the third party firmware provider and issues it to that third party. The third party will then create, test and approve the replacement firmware routine or additional firmware routine, sign them with the third party's private signing key, and attach the upgrade certification from the manufacturer there. Upon receiving such an upgrade, the user loads both the signed code routine and the manufacturer's upgrade certificate into the device and then issues a "third-party firmware upgrade process" instruction. Therefore, the device verifies the third party's signature on the new code routine against the manufacturer's upgrade certificate and then upgrades against the manufacturer's public signature key embedded in the device during manufacture. Confirm authentication. If both signatures are confirmed, the upgrade is accepted and the device performs the desired upgrade.

In addition to accepting instructions to upgrade or supplement device firmware routines, trusted devices that prevent tampering also accept instructions to replace or supplement "instruction" public keys embedded during manufacturing. be able to. As mentioned above, a trusted device may have a public key other than the key embedded by the manufacturer during the manufacture of the device. As described in the present invention, such an "instruction" public key may include the public key of one or more master deposit centers. These embedded keys, including those of the manufacturer or other trusted third party, are presented to the device for deposit authentication device authentication, upgrade authentication, timed instruction authentication, and the device to operate accordingly. It can be used to verify various authentications like others. In addition to trusting only the public key that is embedded during manufacturing, the device can also accept external instructions to embed a new public key or replace an existing public key. In order for the device to accept and store in the secret area of the trusted third party's public signature key, the manufacturer orders the device to discard the authentication provided and store the specified public command key inside. Put the new public key in a signed instruction data packet (or authentication) signed by the manufacturer. The special packet also commands the device regarding the type of transaction in which the new key is trusted (eg, for use with key deposit applications, car rental applications, medical data applications, and other uses). Upon receiving such a public key data packet from the manufacturer, the device first verifies the manufacturer's signature, then accepts the new public key and stores it with restrictions on the use of the public key.

At the time of embedding a third party public instruction key as part of an instruction data packet, either during or after the manufacturer, one of the transactions for which the third party key was approved is manufactured. It can be specified as an alternative to the manufacturer's own basic public signature authentication key. Such an alternative to the manufacturer's own public signature key is almost never required, but the manufacturer's corresponding private signature key (for issuing device authentication and other instructions to the device) is compromised due to theft. There is a possibility of becoming. Theft of the manufacturer's private signature key could allow the thief to issue seemingly valid orders to approve the new depository center (of suspicious reliability) and approve the new time-setting authority. Alternatively, and more likely, the manufacturer's private signature key is simply lost or destroyed, thereby preventing the issuance of more valid instructions. Either of these events is categorized as a "disaster" in computer system terminology, resulting in the need to retrieve all of the manufacturer's devices. However, according to the present invention, the cost of such recovery could be prevented or mitigated by allowing a trusted third party to replace the manufacturer's compromised signature key. The manufacturer has already embedded one or more trusted third party instruction keys in the device, either during production or when using the instruction data packet thereafter, and the third party's public instruction key is approved. Assuming that you have a substitute for your own public key between possible transactions, the manufacturer relies on its trusted third party, who in turn provides a substitute for the manufacturer's public signature key. Allows, thereby requiring itself and all of its users to issue instruction data packets to all of the manufacturer's devices, which saves a huge amount of money to actually replace all physical devices. All device certifications issued by the manufacturer must also be replaced Therefore, this is achieved by having each device issue an authentication request for the public device signing key of the device itself. If the manufacturer's private key is lost or destroyed and not compromised, all previous signatures are still valid and the user can authenticate a new device for the same information signed by the manufacturer's new signature key. You'll just show your old device authentication to get it issued. The manufacturer will then revert the new device authentication (perhaps online or via an email transaction). This is still expensive, but cheaper and less detrimental to the manufacturer's reputation than physically replacing all of the manufacturer's trusted devices in the field on a large scale.

Incorporating the manufacturer's public key or any other trusted public instruction key into the trusted device of the present invention poses some system security risk by using the root public key of the entire system. It will be relieved. This further increases trust in a purely hierarchical credit model, generally allowing for shorter, simpler authentications that require fewer authentications and to determine which authentication to use. Will reduce the effort and the calculation time to verify the signature.

Owner control re-entry As mentioned above, the user also has the option to re-enter the device with respect to the user encryption key pair at any time after manufacturing. The user performs a specific step of the key deposit method on the trusted device, that is, creates a new pair of private key and public encryption key, sends the key divider to the deposit agent, and finally Do this by issuing a firmware instruction from the master deposit center to receive a new deposit certificate. However, the purpose of ensuring that the employer or backer of the user (or the owner if the user is another device or process) (a) selects a depositary agent that the user deems acceptable. And (b) the employer remains known to the selected depositary agent as the true owner of the device, and thus the user's key split without first obtaining a warrant or court order. It is also desirable to have control over the keying and rekeying process to ensure that the department can be requested by the depositary agent. A key for a particular device for any number of reasons, such as for employers to perform internal oversight or to recover encrypted proprietary data after the associated device is lost, stolen or destroyed. May request access to. The employer regularly has its previous encryption or signature key compromised or erased, for a device given to another employee, or as a matter of policy by its owner organization. You may need to rekey your device for any number of reasons, such as for a device that rekeys all cryptographic devices at regular intervals.

In a preferred embodiment, the trusted device is a device such as that shown in FIG. 22, where the device first describes a permanent serial number 221 for a particular device and is signed by the manufacturer (225). Preconfigured by the manufacturer not to initiate the key creation and deposit process unless certified by the owner for 220. The owner certification 220 issued by the manufacturer to the device purchaser at the time of purchase is the company name 222, (Internal Revenue Service Employer Identification Number (EIN) or Dan &amp; Blood Street Number (DUNS)). The company's disclosure, which corresponds to the company's unique identification number 223, and the private signing key held by the company, and is used to verify rekeying and other instructions issued by the company to the device. The signature authentication key 224 is also described. After receiving this information, the device is rekeyed, or any other instruction that is signed using the enterprise owner's private signing key that corresponds to the public key found within the device owner's authentication. Only respond.

Now referring to Figure 23, if the employer (device owner) wishes to rekey the device, the employer will: (1) the device serial number 232, the unique owner identification number 233, (2). ) Names of deposit agent 235 and master deposit center 234, (3) date and time of rekey entry instruction, (4) date and time of rekey entry instruction deadline 236, and (5) unique sequence number of rekey entry instruction Issue a signed instruction 231 to device 230, including 237, and sign the instruction using the employer's private signature key 238. Upon receiving a valid owner authentication 239 and a valid rekey entry instruction 231, the chip 230 in the trusted device first receives the manufacturer's signature on the owner authentication 239 and the rekey entry instruction 231. Check the employer's signature. The trusted device then completes the key creation and deposit process, including the owner's unique identification number 233 in each deposit shared packet, as before, and is designated by the employer in the rekey entry instruction 231. Send shared packets only to the deposited agent 235. Subsequent playback of these instructions (which can be issued electronically) ensures that the device retains the sequence number of the previous multiple rekey input instructions received in the non-volatile storage area and executes the instructions. It can be limited by designing the device to reject again. Assuming that the device's time clock is well maintained, simply instructing the device's time clock to respect the due date and time in the instruction will limit further playback of the rekey input. You can also. In a preferred embodiment, the device whose clock is uncalibrated refuses to process a rekey input instruction with a non-null deadline date / time, but the deadline date / time remains null. Go ahead.

Upon receiving a key (or rekey) split shared packet containing a unique owner identification number from the user device, the deposit agent and master deposit center will record that unique identification number in each database and thereafter. Will respect the request from its owner to access the private encryption key. In a preferred embodiment, the deposit agent and the deposit center will each have to attach each device owner certificate signed by the manufacturer to the key split shared packet that specifies a unique owner identification number. Request. This device owner authentication allows the deposit agent and master deposit center to operate according to a key request message signed with the owner's private signing key that corresponds to the owner's public key being authenticated by the device owner. ..

In another embodiment, the trusted device accepts rekeying, redepositing, owner transfer or other orders from the device owner without using separate device owner authentication. Is allowed. The requirement that instructions to a device must use a separate owner's authentication is that the owner maintains a database of authentications for all the devices it owns, rekeys the device, or commands the device. It's an administrative burden because you have to find the right certificate every time you want to send. A better approach, as shown in Figure 26, is to have the manufacturer issue a single certificate to the owner for the owner's public instruction key for the specified family of devices and let the seller sell the device 260. Occasionally, the public instruction authentication key 261 is installed inside the device 260 and then the system is configured based on the internal storage of those keys. When the device is first sold to the owner by its manufacturer, the device 260 first authenticates the owner's manufacturer using the manufacturer's public instruction key 263 embedded within the device by the manufacturer. Confirm the validity of 262. If the owner's public instruction key area 264 in the device is blank, the device copies the owner's public instruction key 261 from the owner's manufacturer authentication 262 into the device's owner public instruction key area 264. .. If the owner public instruction key already exists in the device and is different from the owner public instruction key that attempts to initialize the device, the device assumes that the manufacturer has sold the device to another entity. To do. Since each device has at most one primary owner, ownership of that device is an owner disclosure order within device 260 instead of (or in addition to) the concept of owner's certifier. Determined by the presence or absence of key 261.

If the owner public instruction key is not installed, the device is considered to be a single user consumer device with no restrictions on device rekeying or transfer of ownership. As such, the device would consider the absence of an installed owner key as a signal to follow the user's instructions without invoking the rekeying, redepositing, and transfer of ownership rules described above. .. As shown in Figure 27, if the owner disclosure instruction key 271 is installed inside a trusted device 270, the user rekey entry, redeposit, and transfer of ownership instructions 272 are these instructions. Not processed unless signed by the corresponding owner private signing key 274. Once the owner's signature 273 is verified, the trusted device 270 performs the steps of the re-deposit procedure described above. Therefore, the owner does not need to attach the owner's authorization to authenticate his ownership of the specified number of devices when instructing the device. However, the owner's signed instruction, needless to say, specifies a numbered device, or perhaps its device number, to prevent the instruction from being delivered to any device owned by that owner. Must be limited to certain classes of devices that follow certain rules or templates.

In addition, as shown in Figure 28, the owner owns the device by replacing the originally installed owner public order authorization key with another one (from the purchaser, that is, the new owner of the device). You can send orders to transfer rights. The device owner sends an ownership transfer order 282 to device 280 containing the name of the new owner and the public order authentication key signed using the current owner's private command signing key 283. The device uses the current owner's public instruction key 281 to verify ownership transfer instruction 282, replaces that key with the new owner's public instruction key 284, and thereafter only commands from the new owner. respond. In addition, the owner can add another "secondary owner" by installing a second public instruction key. This second public order authentication key has a "rights" field that indicates for which action it is allowed to accept the order. These rights may include rekeying, adding another owner, deleting an owner (same as conditional sale), deleting all owners, and having the listed owner. There is no return to consumer devices. However, these defined rights may include more or less rights than the first, or primary instruction authentication key, including the right to replace or delete the primary owner instruction key, and in the same amount. You may have the right.

Generalized device registration The above-mentioned common method for depositing a secret decryption key and receiving a deposit certificate is not necessarily limited to the key deposit situation for the scope or purpose, but the trusted device is registered with a trusted third party. However, note that it can also be applied to the more general case of receiving permission from the third party to allow the device to communicate with other trusted devices. This common process, depicted in Figure 24, is a programmable trusted device 240 that communicates with a trusted third party (TTP) 241 to authenticate the manufacturer of the private signing key and the corresponding public signing key. Equipped with 242. This process may also be the same and secure system-level firmware that can support remote installation of additional application-level firmware and associated public keys as described elsewhere in this disclosure. It also includes the public key of the manufacturer and the public key of the entire system (or global) authority (SWA). The device 240 can be registered with any one of the unlimited number of TTP241 that can be placed within this general registration system by being issued an authority 243 certificate signed by SWA (SWA). , An additional layer of witnesses can be appointed to allow TTP to enter the system according to the well-known principle of the public key authentication hierarchy). Once the device is registered with the designated TTP, the user can engage in specialized transactions with other trading partners.

In the first step of this process, the user initiates request 244 to register with his device 240 designated authenticated TTP241. This request 244 contains information 245 to confirm the qualifications of the user and registration request, and is accompanied by the manufacturer's device certification 242 to support the signature and known type of device. The user's identity, affiliation, where the selected TTP241 is outside the scope of this protocol but may influence the TTP's decision to grant or deny the desired permission to execute the transaction. Other information and warranties may be requested from either the user or other parties to confirm reliability, etc. The TTP241 uses the appropriate public key to verify the manufacturer's signature on device authentication 242 and the device signature for the information in the user's registration request 245.

Satisfied with being able to allow a user to engage in transactions of the requested class, TTP241 issues a response 246 containing authentication 247, which specifically allows the device to perform those transactions on behalf of the user. To do. TTP's device authorization authentication 247 is usually for convenience (and as described below) so that the user does not have to submit his device authentication 242 for each subsequent transaction with a trading partner. It contains not only a re-authenticated copy of the public signing key, but also information that identifies the TTP, the user, the user's device, and the authorized transaction. The TTP response 246 also includes the public key 248, or both, that is loaded into the downloadable firmware and / or the user's trusted device, allowing that device to perform authorized transactions. It may be done. If TTP Response 246 requires the user to securely load the new firmware or public key into their device, Response 246 authenticates the TTP's public signing key and conveys the firmware and public key upgrade authority. Also includes the certification of the authority 243 TTP issued by SWA. Upon receiving the TTP response 246, the user's trusted device 240 uses its embedded SWA public signing key to verify the TTP authentication of authority 243 and uses the TTP public signing key contained therein. Then check the firmware and public key upgrade 248 and TTP device authorization authentication 247.

Revisiting FIG. 24, when a user wishes to perform a transaction with a trading partner 250, that device is implemented within a firmware program installed on the device, as extensively described throughout this disclosure. Formalize transaction data 249 (either at the time of manufacture or at the time of subsequent download), sign transaction 249, and attach the authentication of its corresponding public key. This certificate may be the manufacturer's device authorization certificate 242, but is probably TTP's device authorization authorization 247, which includes a copy of the device public key that has been reauthenticated for convenience. The counterparty 250 typically leverages the TTP public key, verifies the TTP signature on its device authorization signature 247, and then uses the device public signature key contained therein to device in transaction 249. Verify the device's signature and thereby verify the device's compliance with the transaction protocol requirements imposed by the associated firmware. If the trading partner 250 does not already have a specific TTP public signature authentication key, the user can verify that the trading partner uses the SWA public key and already owns it to become a participant in this system. The SWA authentication of the authority 243 TTP, which must be done, can be put in transaction 249.

The generalized process described so far is as follows: (a) The information provided or suggested during user device authentication causes the device to perform the specialized functions of the key deposit cryptosystem already described herein. Depositing a private encryption key in return for a deposit certificate signed by the Deposit Center (TTP), or (b) such a device, informing the Deposit Center that it has the firmware that can be used. Allows the device to download a secure software upgrade that allows the device to meet the transaction requirements of the deposit system at the time of installation if it does not have such features, but has features that do. So common. The transaction data 249 sent to the counterparty 250 is prefixed with a message control header and attached with authorization 247 (user deposit authentication) issued by TTP241 (master deposit center).

Therefore, the generalized system of FIG. 24 has many highly desirable properties that can facilitate complex forms of enterprise and government transactions in an open communication network environment. In particular, as many different device manufacturers as long as each participating device can perform a secure multi-step transaction, download firmware to perform an additional type of secure multi-step transaction, and sign the transaction so created. Can exist. Also, each issues a different type of transaction permit, and each authenticates a different class of firmware application, such as key deposit, digital cash management, car rental, or user medical record management, any number of credits. There can also be a third party. Therefore, a trading partner may be required to utilize a trusted device that is provided for comparison (depending on the firmware and protocol of the user device), which device is associated with the original user's party. Created, published, and provided by different parties, and if the original user's transaction is so authenticated by SWA and its TTP, the other party recognizes all versions of the device and its program to each other. As long as you have a copy of the SWA Public Signature Authentication Key 247 that allows you to work with it, it will be accepted and processed according to system rules. Some examples of business objectives achieved by this protocol are (a) encryption using an authenticateable deposit key, (b) management of digital representations of cash or other high-value documents, and ( c) Includes a system that enforces transactional requirements for access to and use of a user's medical or other personal information.

Unique owner identification number Depending on the need to balance ease of use with privacy rights, the unique owner identification number can optionally be (a) the user's deposit authentication or (b) usually, not only in the key split message to the deposit agent. It is displayed on either of the MCH issued during the communication of. An investigator attempting to decrypt a communication determines whether one or both of the devices involved in the communication from which the MCH was taken belong to the specified owner, including the owner identification number. It is desirable to be able to judge by looking at. However, other privacy interests, including certain owners, suggest that the owner identification number is omitted from the MCH for the purpose of enhancing the privacy of communications. In cases where the owner identification number is included only in the device deposit authorization and not in the MCH of the communication, it is matched against many MCHs that are employed by a particular employer and do not have the listed device owners. An investigator seeking to determine if a particular communication originates from an employee of the employer is owned by the employer at the Master Depositary Center listed in the designated MCH. Will ask if it originated from the device being used. The Master Depositary Center decrypts the authorization number of the MCH communication party whose key is deposited with the Master Depositary Center and checks if user authorization has been issued to the investigator's employer. If issued, and if the investigator's request is signed using the employer-owner's signature key (that is, the investigator has permission to investigate from the employer-owner), the master The deposit center will reveal this information. If the investigator does not have permission, the investigator will need to seek a warrant or court order to investigate any suspicious activity reflected in the MCH of a known device owner. It is expected that most device owners will not object to being publicly named in their deposit authentication and MCH. This is usually the sending and receiving of designated messages in most electronic communication systems. This is because it is not practical to suppress the information of physical network addresses and logical network addresses that strongly identify the system. Therefore, there is little loss by exposing the unique owner identification number, and much is gained by providing the ability to quickly sort and classify messages by sender device owner name and recipient device owner name. ..

However, the unique owner identification number may not be disclosed and may still be included in the employee deposit certificate or in the MCH of the communication. Employee deposit authentication and MCH will include an employer public encryption key along with the other keys mentioned above. These keys are usually present in both the sender's deposit and the recipient's deposit (assuming both the sender and the recipient are employers). When the sender's device forms an MCH, the sender's device actually uses the MCH to consist of each employer-owner to each employer-owner's own unique ID. Incorporate one or both employer unique identification numbers into the MCH, each using the employer's public encryption key, to send a decryptable message. This method is for the purpose of allowing the sender to send an authentication number encrypted under the public encryption key of each deposit center for both the sender and the recipient, and to allow interception of both parties. Similar to the method described above with respect to using MCH, to send the message session key not only to the sender but also to the recipient (a normal function of MCH). Using this technique, the employer can easily identify all messages belonging to the employer-employer's employee within the message traffic flow, and the owner ID number is unencrypted and easily retrieved. It is easy to determine which MCH belongs to the employee while avoiding possible situations.

Still, this approach has the disadvantage that a unique employer identification cipher encrypted using an employer public encryption key always produces the same, and therefore recognizable value. If this approach is implemented even better, not only the employee's deposit authorization number (which the employer clearly has the right to know), but also the time stamp gives the encrypted data block a high degree of variability. Encrypt a data block with the current timestamp (or another random number) with the employer's public key. A few bytes of separate "eye-catching" text, such as "EMPL" (or the employer's unique ID if space allows), are other data (which one may not definitely understand). A field could also be placed inside an encrypted block to reveal a successful decryption to the decrypting entity (in the case the item is binary). In this case, the employer's proof of ownership consists simply that the employer can read this field. In addition, the time stamps will be different each time, and therefore another random number will be added to the data block to increase the variability that is not sufficiently trusted to make every employer MCH data block unique.

This improved approach, which is performed on both sender and recipient employers in every message sent, allows the employer and other backers to own any of their communications. Which communication was created and received by the employee without submitting an encrypted MCH for each communication to the appropriate deposit center to determine if it originated from a device You will be able to determine if this is the case, and you will save a considerable amount of money. Each employer still has to contact the Master Deposit Center and Deposit Agent to obtain the employer's private encryption key, and its owner certification issued by the device manufacturer. Matching with the public signature authentication key listed in must actually authenticate the employee's device owner by signing the request with a private signature key. At the very least, it would not force employers to spend the time, effort, and expense of making additional requests to those parties with respect to MCH for communications originating from what later turns out to be unowned devices. And, as before, if the employer becomes aware of criminal activity or other inappropriate activity that is accompanied by MCH from communications by unowned devices, the employer will always contact the appropriate police and the agency. Tell your employer why you noticed criminal activity, a criminal who is not a third-party employee, or perhaps an employee, a cryptographic device that is not owned by your employer and is registered with your employer. Send the agency to court to obtain a warrant for interrupting and / or decrypting those communications, which are believed to have originated from individuals on the employer's premises using.

Sender and receive information (each of which can decrypt the message session key) how to put the information into an encrypted MCH so that it can only be read by the parties authorized to read it. Contact someone else, the master deposit center of each party (each of which can decrypt its respective user's authorization number), and (each of which can avoid being identified by each message). Each party's employer-owner can decrypt the employee's authorization number or its own unique owner identification number so that it can be seen if it owns the communicating device without it. It's clear that it can be extended to more than just stakeholders. This can also be extended to other parties, such as very large businesses or some foreign local police that do not have warrant requirements. Needless to say, all information under these keys is described above, assuming that these parties are publicly nominated in each message and have no basis to oppose being routinely identifiable. As you can see, it can be displayed as a normal sentence, that is, without encryption. This information can also be omitted if the user is not involved, such as when the user has no employer. A simplified approach would be to use one MCH format in all situations and leave the field blank if it is not applicable. Otherwise, in a preferred embodiment, each format is identified by a unique version number in the first field so that each device processing the MCH can determine which field to predict and analyze the MCH accordingly. Will utilize a variety of different MCH formats within the same system. This method allows infinite nesting of stakeholders in MCH, the most flexible system. The computational overhead depends largely on how many of these fields actually had to be encrypted with the public encryption key of each individual party.

Employers can make it easier for employers to put information in an MCH by attaching a "policy field" to each entry, an instruction code that contains a code that tells the employer's device what information to put in the MCH. Can be controlled to. As before, the opcode may contain a selection of elements that give the employer the option to enter the following information: The employer's nomination and unique identification number, either encrypted or using an alias, (2) the employer's unique identification number is encrypted in the MCH field. , Unencrypted word "employer", (3) user authentication number in encrypted field, (4) message session key in encrypted field, (5) time stamp in encrypted field , And (6) a random entanglement number in any of the other encrypted fields. Many of these options are actually simultaneous. In addition, the options for these policies will be the same for all members of the critical community, including the communicators themselves, thereby "sender" or "receive" by their email ID or system ID, or in the relevant explicit MCH field. To be able to label stakeholders simply by using the word "person".

Multiple simultaneous deposit keys In addition to the above features for upgrading device firmware routines and replacing the manufacturer's public keys, the trusted devices of the invention also have the ability to simultaneously maintain and manage multiple sets of deposited encryption keys. There is a need. Normally, when the device initiates a cycle of rekeying, creating and depositing a new private encryption key, and as a result receives a deposit certificate for the corresponding new public encryption key, the device is newly deposited. Erase the previous private key to enforce the device's trust in the private key. Instead, the device takes a short time ago secret, such as the time required to recover the encrypted data into the data storage area using the previous secret encryption key, if necessary. Hold the key. However, in an alternative embodiment, the device re-from either the user or the device owner as described above to create a second valid deposit authentication for the same private / public encryption key pair. Deposit orders can also be accepted and processed. In this embodiment, the device will probably proceed with the deposit process using a different list of deposit agents and a different master deposit center, signed and issued by the second master deposit center, and can be used in place of the first deposit certificate. You will receive separate, equally valid deposit certificates for the same public / private encryption key pair. This second public encryption key authentication is the case where the user of the device travels internationally and communicates with stakeholders located in other countries, especially those other countries originating from or terminating in other countries. This is effective when you wish to carry out legal supervision of communications. In such cases, by re-depositing the same device key in another country, the user or employer can use the original set of deposit agents at the time and business (legal owner monitoring, recovery of lost keys). Etc.) may be allowed to help the user (or employer of the user) meet possible legal requirements in other countries. Therefore, it allows the owner to follow up on the employee's MCH. For this purpose, it may be sufficient if the sender and recipient owner IDs are displayed on each MCH, thereby telling the owner that it really has the ability to obtain the key. To save time and effort, the owner sends such an MCH to a foreign master deposit center to obtain a foreign deposit authorization number, underlying device number and underlying device certification, but already owns it. Applies to its domestic depositary agent who can verify the authenticity of the owner and release the actual private key split. This procedure frees the device owner from special legal procedures that may be required to obtain the actual key split from a foreign depositary agent.

National security export protection measures The current policy of the US government is to allow unregulated use by American citizens in the United States, but to impose heavy restrictions and fines on the export of cryptographic devices, software or know-how. It is possible to modify the system to allow relatively free personal use of cryptographic devices in the United States while imposing restrictions on their international use. Such systems have a common "policy area" that is open to all software and hardware vendors with minimal or no changes to the standard message formats used throughout the system. Will be possible. In addition, the key deposit system itself, without the explicit or implied obligation of a particular legal entity to facilitate police access to cryptographic communications using the key deposited by that legal entity. It is desirable to enable the use of secret deposit agents in a single country situation within a pure legal entity that can monitor and control the use of cryptography by employees. In particular, such companies may purchase software and hardware for their own use, but provide access to private keys in a short-term framework desired by police enthusiastically pursuing criminals and terrorists. May refuse to accept public obligations.

This is, first of all, to ensure that all devices in the system, directly or indirectly, are perceived by the devices in the system as being reliable and reliable (as described above). This can be done by assuming that it is linked to a deposit agent, a master deposit center and all system authorities (SWAs) that issue certifications to device manufacturers. National or global communication systems must support the existence of multiple relevant internal master deposit centers and and agents, each of which must be certified by SWA for practical purposes as certain. It doesn't become. In each certification issued to the Master Deposit Center or Deposit Agent, SWA designates it as either "public" or "secret". A "public" master deposit center or deposit agent is one who is ready and responsible for responding promptly to a national security or police warrant or summons. Users whose keys are deposited with such agents are allowed to engage in cross-border communications. "Secret" Master Deposit Centers or Deposit Agents include those single enterprise or single state key centers that have installed key deposit system technology for their own use but do not assume responsibility for services at the public level. .. Certification from SWA to the Master Deposit Center or Deposit Agent also includes the country code. Therefore, each user's deposit certificate issued and signed by the Master Deposit Center and attached with the Master Deposit Center SWA certificate will also include the user's country code. As a matter of convenience, the user's deposit authentication may not be possible for SWA to enforce the correctness of the information, but it originated from either a public deposit agent or a non-public deposit agent. Note that it is also necessary to state whether or not. This makes it much easier for the device to implement these rules than it always requires SWA authentication for the master deposit center.

Figures 29 and 30 show the enforcement of deposit requirements when sending and receiving international encrypted communications. As shown in Figure 29, the sender's trusted device 29 has deposit authentications 291 and 293 for both the sender and the recipient, and if the sender and recipient are not deposited at the same master deposit center. Implements this system by requiring its master deposit center SWA certifications 292,294 before sending international communications. The country codes 295 and 296 of the recipient user and its master deposit center must match so that the sending device can send the communication. In addition, if the sender and recipient are in different countries 295,297, and if one user is using a private master deposit center 298,299, the sender device will communicate to that recipient. Will refuse to start. As shown in FIG. 30, the recipient's trusted device 300 also has a public master that somehow initiates communication when the sender and recipient are in different countries, and one user is not public. If you are using a deposit center, implement this system by refusing to decrypt the communication. Because the Master Deposit Center cannot fake its official status authenticated by SWA, and even if the Master Deposit Center makes it appear that the user belongs to another country's territory) the user's country code These rules do not allow non-deposited international cryptographic communications, as the device does not allow inconsistencies between the user's country code and the master deposit center's country code, even if it can be deceived. It will be realized. These rules do not prevent users from transferring improperly trusted cryptographic devices across national borders, but they keep the keys deposited in each country and use only the appropriate keys in each policy area. Make it easier to comply with national requirements by allowing them to communicate with each other.

Multi-user device version Another feature of the invention is the ability to initiate and manage multiple different sessions of communication with different local or remote users using the same device. Many larger computers are often logged simultaneously through terminal sessions, but support multiple users who wish to initiate encrypted sessions with other entities around the world. .. However, it is extremely inefficient to request a separate trusted device for each user session on the shared computer, so the trusted device will have it along with the unique message sequence number (MSN) for that session. By storing, the message session key can be tracked for each communication. Therefore, when additional message packets with that MSH arrive, these packets are decrypted without delay and the response is encrypted. In addition, the device links each user private key with a particular user-aware number, and if each key is presented with some appropriate user authentication such as password, smart card, PIN, biometric, and challenge response. Only the secret decryption key of multiple users can be deposited while making it available. Length, deadline, retry lockout, and ease of inference by assigning a user identification number and password, or equivalent, to each public / private key pair when it is created for deposit. Control over ordinary passwords, such as, can be imposed by the device to limit the possibility of unauthorized access.

In this way, a cryptographic system and method with a key deposit function is provided. Those skilled in the art will appreciate that the invention has been presented for illustration purposes and is not presented for limitation other than the described examples, and that the invention is claimed as follows: You will understand that it is limited only by the range.

Further, the description of the examples of the present application includes the inventions described in the following sections. (1) A method for generating an authenticateable and trusted secret cryptographic digital communication among a plurality of users while allowing an external entity to monitor the communication, and at least one is trusted. A step of depositing a plurality of asymmetric encryption keys used for encrypted communication by a plurality of users to a deposit center, a step of authenticating each deposit of the plurality of keys by the at least one deposit center, and the above-mentioned The step of encrypting the communication from the first user of the plurality of users to the second user of the plurality of users using the first key of the plurality of keys, and the deposited communication, the at least one credit. The encrypted by the second user of the plurality of users using the step of including a message control header containing sufficient information to identify the deposit center to be used and the second key of the plurality of keys. The step of decrypting the encrypted communication by the second user includes the step of decrypting the communication, the authentication of the key of the first and second users, and the communication of the valid message control header. Includes methods subject to presence within.

(2) The step of encrypting the communication from the first user is conditioned on the authentication of the key of the first and second users and the presence of a valid message control header in the communication (1). The method described in. (3) The method according to (1), wherein the first user and the second user are the same so that the communication is encrypted from the first user to the user himself / herself for storage.

(4) Multiple corresponding publications that each user must use to encrypt and decrypt encrypted communications so that each user has at least one corresponding pair of public and private encryption keys. The method described in (1) with multiple randomly created asymmetric encryption keys that make up a key / private key pair. (5) The depositing step further divides the secret key consisting of the at least one corresponding key pair into parts for each user, and the secret key for each of at least one trustee. And each of the at least one trustee is provided with confirmation information to allow the trustee to confirm the correct receipt of the at least one part of the private key. A step of confirming the correct receipt of the at least one portion of the private key by each of the at least one trustee by the at least one trusted depository center (4). Method.

(6) The depositing step further comprises depositing communications to the at least one depositing center, including the user private key, so that the dividing step is performed by the depositing center (5). The method described in. (7) The method according to (6), wherein the step of depositing a communication to the at least one deposit center including the user private key further comprises a step of the user digitally signing the communication.

(8) The splitting step further comprises splitting each user's private key into N parts so that all N parts are required to reconstruct the private key. The method described in (5). (9) When the division step is M &lt;N, the private key of each user is further divided into N parts so that only M parts are required to reconstruct the private key. The method described in paragraph (5), which comprises dividing.

(10) The step of providing each of at least one trustee with at least one portion of the private key further communicates to each of the at least one trustee including said at least one portion of the user private key. The method according to (5), which comprises a step of encrypting.

(11) The step of providing confirmation information to each of at least one trustee further comprises a step of encrypting a communication containing the confirmation information to each of the at least one trustee (10). The method described. (12) The step of encrypting a communication to the at least one trustee, including the at least one portion of the user private key, is performed by the user, and the user digitally signs the communication. The method according to (11) provided.

(13) The step of encrypting a communication to each of the at least one trustee including the confirmation information is performed by the user, further comprising a step of digitally signing the communication by the user (12). The method described in. (14) The step of encrypting a communication to each of the at least one trustee, including the at least one portion of the user private key, is performed by the deposit center, and the deposit center digitally performs the communication. The method according to (13), which comprises a step of signing.

(15) The step of encrypting a communication to the at least one trustee containing the confirmation information is performed by the deposit center, further comprising a step of digitally signing the communication by the deposit center (14). The method described in. (16) The step of confirming the at least one deposit center notifies each trustee of the receipt of the at least one portion of the user's private key by the trustee to the deposit center. The step of communicating the confirmation information by the trustee to the deposit center, and the correct communication of the confirmation information by the trustee of the at least one part of the private key of the user. , The method according to (5), comprising the step of confirming the correct receipt by the trustee by the deposit center.

(17) The method according to (16), wherein the step of communicating the confirmation information to the deposit center by the trustee comprises a step of encrypting the communication to the deposit center including the confirmation information. (18) The method according to (17), wherein the step of encrypting a communication to the deposit center containing the confirmation information further comprises a step of the trustee digitally signing the communication.

(19) Each of the plurality of users has a unique digital identification code, and the method further comprises providing the at least one trustee with a unique digital identification code for the user (5). The method described in. (20) The plurality of steps for authenticating the deposit of each of the plurality of keys further notarize the connection between the encryption key and the corresponding user and authenticate that the encryption key has been deposited. The method according to (1), which comprises issuing a deposit certificate by at least one deposit center for each of the encryption keys of the above.

(21) The method according to (20), wherein the step of authenticating the deposit of each of the plurality of keys further comprises a step of transmitting a copy of the deposit authentication to the corresponding user. (22) The method according to (20), wherein the step of authenticating the deposit of each of the plurality of keys further comprises a step of making the deposit authentication available to others of the plurality of users.

(23) The method of (22), wherein the step of making the deposit authentication available comprises putting the deposit authentication into a deposit authentication directory accessible to such a user. (24) The method according to (1), further comprising a step of authenticating the credibility of at least one trusted depositary center by a superior authority.

(25) The step of certifying a trusted depositary center is a step of issuing a certification by the higher authority to each of the at least one trusted depositary center that notarizes the credibility of the depositary center for deposit. The method according to (24). (26) The method according to (25), wherein the step of authenticating the trusted depositary center further comprises sending a copy of the authorization of the higher authority to the corresponding trusted depositary center.

(27) The method according to (25), wherein the step of authenticating the trusted deposit center further comprises a step of making the other of the plurality of users available of the superior authority authentication. (28) The method according to (25), wherein the higher authority constitutes the entire system authority.

(29) The method according to (25), which constitutes at least one manufacturer of the device whose superior authority is trusted. (30) The step of authenticating the trusted depositary center notarizes the authenticity of the at least one manufacturer of the device, randomly creates an asymmetric encryption key for the manufactured device, and is unreadable. Further include a step of issuing a manufacturer's certificate by all system authorities to each of the at least one manufacturer of the device, demonstrating the ability to memorize the key in a manner that prevents tampering (29). The method described in. (31) The method of (30), wherein the step of authenticating the trusted depository further comprises sending a copy of the manufacturer certification to the corresponding manufacturer.

(32) The method of (30), wherein the step of authenticating the trusted depository further comprises sending a copy of the manufacturer's certification to a user of a device manufactured by the manufacturer. (33) The step of authenticating the deposit of each of the plurality of keys notarizes the connection between the corresponding encryption key pair and the corresponding user, and the private key of the corresponding encryption key pair The method according to (4), which comprises issuing a deposit certificate by one deposit center for each of the corresponding encryption key pairs that authenticate the deposit.

(34) The method according to (33), wherein the step of authenticating the deposit of each of the plurality of keys further comprises the step of transmitting a copy of the deposit signature to the corresponding user. (35) The method according to (33), wherein the step of authenticating the deposit of each of the plurality of keys further comprises a step of making the deposit authentication available to others of the plurality of users.

(36) before the step to allow the use of SL deposit authentication method according to the user comprises to put the deposit authentication in deposit authentication directory and easy use (35). (37) The step of authenticating each deposit of the plurality of keys confirms the deposit of each private key of the corresponding encryption key pair by the at least one deposit center before issuing the deposit certificate. The method according to (33).

(38) The deposit authentication of the corresponding encryption key pair constitutes the identification of the deposit center issuing the certification, the digital code identification of the deposit authentication, and the public key of the corresponding encryption key pair. The method described in (37). (39) The step of inserting the message control header comprises forming a cryptographic message control header packet constituting the identification of the deposit center of the first user and the digital code identification of the deposit authentication of the first user (). 38).

(40) The step of inserting the message control header comprises forming a cryptographic message control header packet constituting the identification of the deposit center of the second user and the digital code identification of the deposit authentication of the second user ( 39) The method described.

(41) The deposit center of the first user and the deposit center of the second user are the same, and the step of inserting the message control header is the identification of the deposit center of the first and second users and the deposit authentication, respectively. The method according to (40), further comprising the step of forming an encrypted message control header packet constituting the digital identification code of the above.

(42) The method according to (39), wherein the step of inserting the message control header further comprises a step of forming a cryptographic message control header packet constituting the identification of the employer or supervisor of the first user. (43) The method according to (42), wherein the step of inserting the message control header includes a step of forming an encrypted message control header constituting the identification of the employer or supervisor of the second user.

(44) The employer or supervisor of the first user and the employer or supervisor of the second user are the same, and the step of inserting the message control header further further employs the first and second users. Alternatively, the method according to (43), comprising the steps of identifying the supervisor and forming the digital identification code for each of the deposit authentications.

(45) The step of inserting the message control header further comprises forming a cryptographic message control header packet constituting a time stamp indicating the date and time of formation of the message control header by the first user (39). The method described in.

(46) The step of inserting the message control header comprises the trusted time clock for the user to create a time stamp indicating the date and time of the encrypted communication and the formation of the message control header. The method according to (45), further comprising a step of certifying the reliability of the.

(47) The step of authenticating the reliability of the time stamp comprises issuing a certificate by a higher authority notarizing the reliability of the time clock in order to create the time stamp (46). Method. (48) The method according to (47), wherein the step of authenticating the time stamp further comprises attaching the time clock authentication to each of the created time stamps.

(49) The method according to (47), wherein the higher authority constitutes the entire system authority. (50) The method according to (47), wherein the higher authority constitutes the manufacturer of the time clock. (51) The method according to (46), wherein the higher authority constitutes a deposit center, the time clock certification is issued within the deposit certification, and is based on the judgment of the device manufacturer and the device information during the deposit process.

(52) The method according to (39), further comprising the step of monitoring the encrypted communication by the external entity having permission to install the wiretapping device. (53) The monitoring step includes a step of interrupting the encrypted communication by the external entity, a step of presenting the wiretapping measure installation permission and the message control header to the deposit center of the first user, and the first step. The step of acquiring the private key of the corresponding encryption key page of the first user deposited in the deposit center of one user, and the decryption of the encrypted communication by using the private key of the first user for the decryption of the encrypted communication. The method according to (51), further comprising steps to be used.

(54) The presented step includes the step of extracting the digital identification code of the first user's deposit center and the first user's deposit authentication from the message control header, the eavesdropping device installation permission, and the said. The method according to (53), further comprising the step of presenting the digital identification code of the deposit authentication of the first user to the deposit center of the first user.

(55) The step of inserting the message control header is the step in which the first user has a trusted time clock for creating a time stamp indicating the date and time of the encrypted communication and the formation of the message control header. A step of forming an encrypted message control header packet that constitutes a time stamp indicating the date and time of the formation of the message control header by the first user, and a step of authenticating the reliability of the time clock for the purpose of creating the time stamp. The method according to (54), which further comprises.

(56) The method of (55), wherein the trusted time clock can only be set or calibrated by the manufacturer of the time clock. (57) The method of (53), wherein the wiretapping device installation permit is subject to at least one predefined constraint.

(58) The at least one predefined constraint includes a start date and time that the eavesdropping device installation permission must not occur prior to the step of acquiring the private key of the first user. The method according to (57), which comprises such a time constraint. (59) The at least one predefined constraint is such that the wiretapping permit includes an end date and time at which the step of acquiring the private key of the first user must not occur thereafter. The method according to (58), which further comprises a time constraint.

(60) The at least one predefined constraint is such that the wiretapping device installation permission includes an end date and time at which the step of acquiring the private key of the first user must not occur thereafter. The method according to (53), which has a time constraint. (61) The step of acquiring the private key of the first user is a step of collecting the at least one part of the private key of the first user from the at least one trustee, and the recovery of the private key. The method according to (53), further comprising a step of reconstructing the private key from the portion.

(62) The method of (61), wherein the acquisition step is performed by the deposit center. (63) The method of (61), wherein the acquisition step is performed by the external entity. (64) The method according to (38), comprising identifying the deposit center of the second user and forming an encrypted message control header packet constituting the digital identification code of the deposit authentication of the second user.

(65) The method according to (64), wherein the step of inserting the message control header further comprises a step of forming a cryptographic message control header packet constituting the identification of the employer or supervisor of the second user. (66) The method according to (64), further comprising a step of monitoring the encrypted communication by the external entity having permission to install the wiretapping device.

(67) The monitoring step includes a step of interrupting the encrypted communication by the external entity, a step of presenting the wiretapping device installation permission and the message control header to the deposit center of the second user, and the first step. The step of acquiring the private key of the corresponding encryption key pair of the second user deposited in the deposit center of the two users, and the second user's in order to decrypt the encrypted communication. The method according to (66), further comprising the step of using the private key.

(68) The presented step includes the step of extracting the identification of the deposit center of the second user and the digital identification of the deposit authentication of the second user from the message control header, the eavesdropping device installation permission, and the said. The method according to (67), further comprising the step of presenting the digital code identification of the deposit authentication of the second user to the deposit center of the second user.

(69) The step of inserting the message control header includes a time clock that the first user is trusted to create a time stamp indicating the date and time of the encrypted communication and the formation of the message control header. A step of forming an encrypted message control header packet that constitutes a time stamp indicating the date and time of the formation of the message control header by the first user, and a step of authenticating the reliability of the time clock for the purpose of creating the time stamp. The method according to (68).

(70) The method of (69), wherein the trusted time clock can only be set or calibrated by the manufacturer of the time clock. (71) The method of (67), wherein the wiretapping permit is subject to at least one predefined constraint. (72) The at least one predefined constraint such that the wiretapping device installation permit includes a start date and time prior to which the step of acquiring the private key of the second user must not occur. The method according to (71), which has a time constraint.

(73) The at least one predefined constraint so that the wiretapping device installation permission includes an end date and time after which the step of acquiring the private key of the second user must not occur. The method according to (72), which comprises additional time constraints.

(74) The at least one predefined constraint is such that the wiretapping device installation permission includes an end date and time after which the step of acquiring the private key of the second user must not occur. The method according to (73), which comprises a time constraint. (75) The step of acquiring the private key of the second user is a step of recovering the at least one part of the private key of the second user from the at least one trustee, and the recovery of the private key. The method according to (67), further comprising a step of reconstructing the private key from the portion.

(76) The method of (75), wherein the acquisition step is performed by the deposit center. (77) The method of (75), wherein the acquisition step is performed by the external entity. (78) For each matching pair in the plurality of corresponding pairs of the public key and the private key, only the private key can decrypt the communication encrypted using the public key (4). The method described.

(79) The first key of the plurality of keys used by the first user to encrypt the communication to the second user includes the public key of the second user (78). the method of. (80) The method according to (78), wherein the second key of the plurality of keys used by the second user to decrypt the encrypted communication includes the private key of the second user.

(81) The step of encrypting the communication includes a step of creating a unique encryption key for use in both encryption and decryption of the encrypted communication between the first user and the second user. The method according to (1), further comprising the step of encrypting the communication by the first user to the second user by using the encryption key.

(82) The step of creating the unique encryption key is the step of calculating the intermediate number of the second user by the second user using the private key of the second user and at least one public number. , The step of acquiring the intermediate number of the second user by the first user, and the encryption key by the first user using the secret key of the first user and the intermediate key of the second user. It includes a step of calculation so that the communication from the first user to the second user encrypted using the encryption key can be decrypted using only the encryption key (81). ).

(83) The method according to (82), wherein the intermediate number of the second user and the at least one public number constitute the public key of the second user. (84) The first user of the plurality of keys used by the first user to encrypt the communication to the second user is used in the step of calculating the encryption key. The method according to (82), wherein the private key is provided.

(85) The secret of the second user used in the step of calculating the intermediate number by the second key of the plurality of keys used by the second user to decrypt the encrypted communication. The method according to (82), which comprises a key. (86) The method according to (82), further comprising the step of calculating the intermediate number of the first user by the first user using the first user and at least one public number.

(87) The method according to (86), wherein the step of inserting the message control header further comprises a step of forming the message control header constituting the intermediate number of the first user and the at least one public number. (88) The step of decrypting the encrypted communication by the second user is said by the second user using the secret key of the second user and the intermediate number of the first user. The method according to (87), further comprising a step of calculating an encryption key and a step of decrypting the communication from the first user by the second user using the encryption key.

(89) The method according to (81), wherein the step of creating the unique encryption key includes a step of interactively creating the encryption key by each of the first user and the second user. (90) The step of interactively creating the encryption key by each of the first user and the second user is performed by the first user using the first user's private key and at least one public key. A step of calculating the first intermediate number, a step of calculating the second intermediate number by the second user using the second user's private key and at least one public key, and the secret of the first user. Using the key and the second intermediate number to calculate the encryption key by the first user, and using the second user's secret key and the first intermediate number, the second user The first user to the second user or the second user to the first user encrypted using the encryption key. The method according to (89), wherein the communication can be decrypted only when the encryption key is used.

(91) The first key of the plurality of keys used by the first user to encrypt the communication to the second user is used in the step of calculating the first intermediate number. The method according to (90), which comprises the user's private key. (92) The second key of the plurality of keys used by the second user to decrypt the encrypted communication is used in the step of calculating the second intermediate number. The method according to (90), which comprises the user's private key.

(93) The step of decrypting the encrypted communication by the second user further includes a step of decrypting the communication from the first user using the encryption key by the second user. The method described in (90). (94) For each credit device, the public key of the corresponding key pair is used to encrypt the encrypted communication to the device, and the corresponding private key of the corresponding key pair is used to decrypt the encrypted communication. In a cryptosystem with multiple trusted devices with at least one corresponding pair of randomly created asymmetric encryption keys, between multiple devices while allowing an external entity to monitor said communication. At least one public pair of said corresponding pairs of each encryption key of said trusted device is deposited in at least one deposit center, a method for creating authenticateable and trusted cryptographic communications. The device using the step, the step of guaranteeing the deposit of the corresponding key pair of each of the devices by the at least one deposit center, and the public key of the corresponding key pair of the second device. A message control header containing sufficient information to identify the at least one trusted depository center is encrypted with a step of encrypting the communication from the first of the devices to the second of the above. The second device comprises a step included with the communication and a step of decrypting the encrypted communication by the second device using the private key of the corresponding key pair of the second device. The step of decrypting the encrypted communication by is conditioned on the authentication of the private key of each of the first device and the second device, and the presence of a valid message control header in the communication. Method.

(95) The step of encrypting the communication from the first step is conditioned on the authentication of the private key of each of the first device and the second device and its presence in a valid message control header ( 94). 96) The method of (94), wherein for each of the corresponding pairs of at least one asymmetric encryption key, only the private key can decrypt the communication encrypted using the public key.

(97) The method of (94), wherein the first device and the second device are identical such that the communication is encrypted from the first device to itself for storage. (98) Each trusted device randomly creates the at least one corresponding encryption key pair and remembers the key pair in a secure, tamper-proof and unreadable manner. The method according to (94), which has the ability to perform.

(99) The method according to (98), wherein each of the trusted devices has a manufacturer and further comprises a step of authenticating the ability of the device to randomly create and store the key of the device by a higher authority. .. (100) The step of notarizing the manufacturer issues the certification by the superior authority to the manufacturer, notarizing the reliability of the manufacturer and the ability to randomly create and store the key of the device. The method according to (99) comprising steps.

(101) The method according to (99), wherein the higher authority constitutes the entire system authority. (102) The depositing step is to divide the private key into parts for each trusted device and to provide each of at least one trustee with at least one part of the private key. And the step of providing the trustee with confirmation information that allows the trustee to confirm the correct receipt of the at least one portion of the private key, and the at least one portion of the private key. The method according to (94), further comprising a step of confirming the correct receipt by each of the at least one trustee of the above by the at least one trusted depositary center.

(103) Each of the at least one trusted depository center has at least one corresponding public and private encryption key pair that needs to be used to encrypt and decrypt cryptographic communications. The depositing step further comprises a step of encrypting communication to the at least one depositing center, including the trusted device private key, so that the decomposing step is performed by the depositing center (102). The method described in.

(104) The encryption key of the at least one trusted deposit center has been credited by the manufacturer of the device such that a group of at least one deposit center is selected by the manufacturer for deposit purposes. Pre-embedded in the device, said deposit step uses one of the pre-embedded deposit center encryption keys to make one deposit center out of the group of at least one deposit center. The method according to (103), further comprising a step of encrypting a communication comprising at least one portion of said private key to.

(105) The method of (103), wherein the encryption key of the at least one deposit center is obtained by the device from a deposit authentication directory accessible to the device. (106) The step of encrypting a communication containing the trusted device private key to the at least one depository center is further comprising a step of being performed by the device and the device digitally signing the communication (103). ).

(107) Each of the at least one trustee has at least one corresponding public / private cryptographic key pair that needs to be used to encrypt and decrypt cryptographic communications and splits said. The method of (102), wherein the step is performed by said device.

(108) Of the trusted device by the manufacturer of the device so that the encryption key of the at least one trustee is selected by the manufacturer for deposit purposes by a group of the at least one trustee. The step, which is pre-embedded in and provides each of at least one trustee with at least one portion of the private key, uses one of the pre-embedded trustee encryption keys. The method according to (107), further comprising a step of encrypting a communication with at least one part of the private key for each of the at least one trustee from the group of the at least one trustee.

(109) The method of (108), wherein the step of encrypting the communication to each of the at least one trustee is performed by the device, further comprising the step of the device digitally signing the communication. (110) The step of providing at least one portion of the private key to each of the at least one trustee with respect to the deposit center constituting the respective identification of the at least one trustee who received the portion of the private key. The method according to (108), further comprising a step of encrypting the communication.

(111) The step of providing confirmation information to each of the at least one trustee further comprises a step of encrypting the communication containing the confirmation information to each of the at least one trustee (108). The method described. (112) The step of encrypting a communication to each of the at least one trustee including the confirmation information is performed by the device, further comprising a step of the device digitally signing the communication (111). the method of.

(113) The steps of providing confirmation information to each of the at least one trustee constitute (a) the identification of each of the at least one trustee who received the confirmation information, and (b) the confirmation information. The method according to (111), further comprising a step of encrypting communication to the deposit center.

(114) The splitting step further comprises splitting the private key into N parts so that all N parts are needed to reconstruct the private key (102). ). (115) If the split step is M &lt;N, split the private key into N parts so that only M parts are needed to reconstruct the private key. The method according to (102).

(116) The step of providing each of the at least one trustee with at least one portion of the private key encrypts communication to each of the at least one trustee including said at least one portion of the private key. The method according to (102), further comprising the step of performing.

(117) The method of (116), wherein the step of encrypting a communication to each of the at least one trustee, including the at least one portion of the device private key, comprises a step of digitally signing the communication. (118) The step of providing confirmation information to each of the at least one trustee further comprises a step of encrypting the communication containing the confirmation information to each of the at least one trustee (116). The method described.

(119) The method of (118), wherein the step of encrypting a communication to each of the at least one trustee, including the confirmation information, further comprises a step of the deposit center digitally signing the communication. (120) The step of confirming by the at least one deposit center is to notify each trustee of the receipt of the at least one part of the private key of the device by the trustee to the deposit center. Based on the step of communicating the confirmation information to the deposit center by the trustee and the correct communication of the confirmation information by the trustee, by the trustee of the at least one part of the secret key of the device. The method according to (102), comprising a step of confirming the correct receipt by the depository center.

(121) The method according to (120), wherein the step of communicating the confirmation information by the trustee to the deposit center includes a step of encrypting the communication to the deposit center including the confirmation information. (122) The method of (121), wherein the step of encrypting the communication to the deposit center containing the confirmation information further comprises the step of digitally signing the communication by the trustee.

(123) A unique digital identification code is set for each of the plurality of trusted devices, and the method further comprises providing each of the at least one trustee with a unique digital identification code for the device. (102).

(124) The method according to (102), further comprising a step of authenticating the reliability of at least one trusted depository center by a higher authority. (125) The step of authenticating a trusted depositary center issues a certificate by the superior authority to each of the at least one trusted depositary center whose reliability of the depositary center is negotiated for the purpose of deposit. The method according to (124), further comprising the steps to be performed.

(126) The method according to (125), wherein the higher authority constitutes the entire system authority. (127) The method of (125), wherein the superior authority constitutes at least one manufacturer of the device. (128) The step of authenticating the trusted depository notarizes the reliability of the at least one manufacturer of the device and randomly selects the corresponding pair of each asymmetric encryption key of the device to be manufactured. It further comprises the step of issuing a notarized whole-city authority to each of the at least one manufacturer of the device to create and demonstrate the ability to memorize the key in a way that is unreadable and prevents unauthorized movement (127). The method described in.

(129) The step of authenticating the deposit of the private key notarizes the connection between the public key of the corresponding encryption key pair and the private key, and the private key of the corresponding encryption key pair. Further comprises the step of issuing a deposit certificate by one deposit agent for each of the corresponding cryptographic key pairs of the device, which makes it difficult for the depositor to be deposited as a deposit (94). the method of.

(130) Each said deposit authentication of the corresponding cryptographic key pair comprises the identification of the certificate issuing deposit center, the digital identification code of the deposit authentication, and the public key of the corresponding cryptographic key pair (129). The method described in. (131) The step of authenticating the deposit of the private key is a step of confirming the deposit of the private key of the corresponding encryption key pair by the certificate issuing deposit agent before the step of issuing the deposit certificate. Further provided (129).

(132) The confirming step by the at least one deposit center notifies each trustee of the receipt of the at least one portion of the private key of the device by the trustee to the deposit center. And, based on the trustee's communication of the confirmation information to the deposit center and the correct communication of the confirmation information by the trustee, the deposit center said that at least one portion of the secret key of the device was deposited. The method described in (131), which comprises steps to teach the correct receipt by a person.

(133) The method according to (132), wherein the step of communicating the confirmation information to the deposit center by the trustee comprises a step of encrypting the communication to the deposit center including the confirmation information. (134) The method of (133), wherein the step of encrypting a communication to the deposit center containing the confirmation information further comprises a step of the trustee digitally signing the communication.

(135) The deposit authentication for each of the corresponding cryptographic key pairs comprises the identification of the certificate issuing deposit center, the digital identification code of the deposit authentication, and the public key of the corresponding cryptographic key pair (131). The method described in. (136) The step of inserting the message control header includes the step of identifying the deposit center of the first device and forming the encrypted message control header packet constituting the digital identification code of the deposit authentication of the first device. The method described in (135).

(137) The step of inserting the message control header includes a step of forming an encrypted message control header packet constituting the digital identification code of the deposit center of the second device and the deposit authentication of the second device (). 136) The method described.

(138) The deposit center of the first device and the deposit center of the second device are the same, and the step of inserting the message control header is the identification of the deposit center of the first and second devices and the deposit authentication. The method according to (137), comprising the step of forming a cryptographic message control header packet comprising each of the digital identification codes.

(139) The step of including the message control header further comprises forming a cryptographic message control header that constitutes the identification of the owner of the first device or the employer or supervisor of the user of the first device. (136).

(140) The step of including the message control header further comprises forming a cryptographic message control header packet that constitutes the identification of the owner of the second device or the employer or supervisor of the user of the second device. The method according to (139).

(141) The step of inserting the message control header is the step in which the owner of the first device and the second device is the same as the employer or supervisor of the user of the first device and the second device. The method according to (140), further comprising the steps of forming an encrypted message control header that constitutes the identification of the owner, employer or supervisor, and the digital identification of each of the deposit authentications.

(142) The method according to (136), further comprising the step of forming a cryptographic message control header constituting the time stamp indicating the date and time of formation of the message control header by the first device. (143) The device comprises a trusted time clock for creating a time stamp indicating the date and time of the encrypted communication and the creation of the message control header, and the step of inserting the message control header is the time stamp. The method according to (142), further comprising a step of authenticating the reliability of the.

(144) The step of authenticating the reliability of the time stamp comprises issuing a certificate by a higher authority that notarizes the reliability of the time clock to create the time stamp (143). the method of. (145) The method of (144), wherein the step of authenticating the time stamp further comprises attaching the time clock authentication to each of the created time stamps.

(146) The method according to (144), wherein the higher authority time clock constitutes the entire system authority. (147) The method according to (144), wherein the higher authority time clock constitutes the manufacturer of the device. (148) The method according to (144), wherein the higher authority time clock constitutes a deposit center.

(149) The method of (143), wherein the trusted time clock can only be set or calibrated by the manufacturer of the time clock. (150) The method of (143), wherein the time clock can only be set or calibrated by an entity authorized by the manufacturer of the time clock.

(151) The method according to (136), further comprising a step of monitoring the encrypted communication by the external entity having permission to install the wiretapping device. (152) The monitoring step includes a step of interrupting the encrypted communication by the external entity, a step of presenting the wiretapping device installation permission and the message control header to the deposit center of the first device, and the first step. The step of acquiring the private key of the corresponding encryption key pair of the first device deposited at the deposit center of one device and the secret key of the first device are used for decrypting the encrypted communication. The method according to (151), further comprising:

(153) The presented step includes the step of extracting the digital identification code of the deposit center of the first device and the deposit authentication of the first device from the message control header, the eavesdropping device installation permission, and the step. The method according to (152), further comprising the step of presenting the digital identification code of the deposit authentication of the first device from the first device to the deposit center of the first device.

(154) The step of inserting the message control header is such that the first device comprises a time clock trusted to create a time stamp indicating the date and time of the encrypted communication and the creation of the message control header. A step of forming an encrypted message control header packet that constitutes a time stamp indicating the date and execution of the formation of the message control header by the first device, and a step of authenticating the reliability of the time clock to create the time stamp. The method according to (153).

(155) The method of (154), wherein the trusted time clock can only be set or calibrated by the manufacturer of the time clock. (156) The method of (151), wherein the step of using the private key of the first device to decrypt the communication is performed by the external entity.

(157) The method of (152), wherein the step of using the private key of the first device to decrypt the communication is performed by the deposit center. (158) The method according to (152), wherein the wiretapping device installation permit is subject to at least one predefined restriction.

(159) The start date and time the at least one predefined restriction must not occur before the eavesdropping device installation permit, the step of using the private key to decrypt the communication. The method according to (158), which comprises a time constraint such as.

(160) The end date and time the at least one predefined restriction must not occur in the eavesdropping device installation permission, after which the step of using the private key to decrypt the communication must not occur. The method according to (158), which comprises an additional time constraint such as.

(161) The end date and time the at least one predefined restriction must not occur in the eavesdropping device installation permission, after which the step of using the private key to decrypt the communication must not occur. The method according to (158), which comprises a time constraint such as.

(162) The step of acquiring the private key of the first device is a step of recovering the at least one part of the private key of the first device from the at least one trustee, and the recovery of the private key. The method according to (152), further comprising a step of reconstructing the private key from the portion.

(163) The method of (162), wherein the acquisition step is performed by the deposit center. (164) The method of (162), wherein the acquisition step is performed by the external entity. (165) The dividing step further comprises a step of dividing the secret key into N parts so that all N parts are required to reconstruct the secret key. The at least one part of the private key from each of the at least one trustee so that the step of retrieving the at least one part of the private key recovers all of the N parts of the private key. The step of reconstructing the secret key comprises the step of reconstructing the secret key from all of the N recovered parts of the secret key (162). The method described in.

(166) The step of retrieving all N parts of the private key is such that for each of the at least one trustee the step of reconstructing the private key is performed by the external entity. The method according to (162), further comprising the step of encrypting a communication to the external entity including the at least one device private key portion.

(167) The method of (166), wherein the step of encrypting a communication to the external entity, including the at least one device private key portion, further comprises a step of digitally signing the communication by the trustee. (168) The step of retrieving all N parts of the private key is performed by the deposit center so that the step of reconstructing the private key is performed for each of the at least one trustee. The method according to (165), further comprising the step of encrypting a communication to the at least one deposit center including the at least one private key portion.

(169) The method of (168), wherein the step of encrypting a communication to the deposit center that includes the at least one device private key portion further comprises a step of the trustee digitally signing the communication. (170) When the dividing step is M &lt;N, the secret key is divided into N parts so that only M parts are required to reconstruct the secret key. The step of retrieving the at least one portion of the private key retrieves the at least one portion of the secret key from the at least one trustee so that at least M parts of the secret key are reclaimed. The method according to (162), wherein the step of reconstructing the secret key reconstructs the secret key from at least M recovered parts of the secret key.

(171) For each of the at least one trustee so that the step of retrieving at least M parts of the private key performs the step of reconstructing the private key by the external entity. The method according to (170), further comprising a step of encrypting communication to said external entity, including said device private key portion.

(172) The method of (171), wherein the step of encrypting a communication to the external entity including the device private key portion further comprises a step of digitally signing the communication by the trustee. (173) For each of the at least one trustee, such that the step of retrieving at least M parts of the private key reconstructs the private key is performed by the depository center. The method according to (170), further comprising a step of encrypting communication to the at least one deposit center, including the device private key portion.

(174) The method of (173), wherein the step of encrypting a communication to the deposit center, including the device private key portion, further comprises a step of the trustee digitally signing the communication. (175) The step of inserting the message control header comprises forming a cryptographic message control header packet constituting the digital identification code of the deposit center of the second device and the deposit authentication of the second device ((175). 135).

(176) The step of including the message control header further comprises forming a cryptographic message control header packet that constitutes the identification of the owner of the second device or the employer or supervisor of the second device (175). ). (177) The method according to (175), further comprising the step of monitoring the encrypted communication by the external entity having permission to install the wiretapping device.

(178) The monitoring step interrupts the encrypted communication by the external entity, presents the wiretapping device permission and the message control header to the deposit center of the second device, and the second. The step of acquiring the private key deposited in the deposit center of the second device of the corresponding encryption key pair of the device and the secret key of the second device are used to decrypt the encrypted communication. The method according to (177), further comprising:

(179) The presented step is a step of extracting the identification of the deposit center of the second device and the digital code identification of the deposit authentication of the second device from the message control header, and the eavesdropping device installation permission and the step. The method according to (178), further comprising the step of presenting the digital code identification of the deposit authentication of the second device to the deposit center of the second device.

(180) The step of inserting the message control header is such that the first device includes a time clock trusted to create a time stamp indicating the date and time of the encrypted communication and the creation of the message control header. A step of forming an encrypted message control header packet that constitutes a time stamp indicating the date and time of creation of the message control header by the first device, and a step of authenticating the reliability of the time clock for the purpose of creating the time stamp. (179).

(181) The step of authenticating the reliability of the time stamp comprises issuing a certificate by a higher authority notarizing the reliability of the time clock for the purpose of creating the time stamp (180). Method. (182) The method according to (181), wherein the step of authenticating the time stamp attaches the time clock authentication to each of the created time stamps.

(183) The method according to (181), wherein the higher authority constitutes the entire system authority. 184) The method according to (181), wherein the superior authority constitutes a manufacturer of the device. (185) The method according to (181), wherein the higher authority constitutes a deposit center. (186) The method of (180), wherein the trusted time clock can only be set or calibrated by the manufacturer of the time clock.

(187) The method of (180), wherein the trusted time clock can only be reconfigured or recalibrated by an entity specified by the manufacturer. (188) The method of (178), wherein the step of using the private key of the second device to decrypt the communication is performed by the external entity.

(189) The method of (178), wherein the step of using the private key of the second device to decrypt the communication is performed by the deposit center. (190) The method of (178), wherein the wiretapping device installation permit is subject to at least one predefined constraint.

(191) The at least one predefined constraint is such that the wiretapping permit includes a start date and time before which the step of acquiring the private key of the second device does not occur. The method according to (190), which comprises a time constraint. (192) The at least one predefined constraint is such that the wiretapping permit includes an end date and time at which the step of acquiring the private key of the second device does not occur thereafter. The method according to (190), which comprises an additional time constraint.

(193) The at least one predefined constraint is such that the wiretapping permit includes an end date and time at which the step of acquiring the private key of the second device does not occur thereafter. The method according to (190), which comprises a time constraint. (194) The step of acquiring the secret key of the second device is a step of recovering the at least one part of the secret key of the second device from each of the at least one trustee, and the step of obtaining the secret key of the secret key. The method according to (178), further comprising the step of reconstructing the private key from the recovered portion.

(195) The method of (194), wherein the acquisition step is performed by the deposit center. (196) The method of (194), wherein the acquisition step is performed by the external entity. (197) The secret key is divided into N parts so that the dividing step requires all N parts to reconstruct the secret key, and at least one of the secret keys. The step of retrieving one portion reclaims each of the at least one portion of the secret key from each of the at least one trustee so that all N parts of the secret key are reclaimed. The method according to (194), wherein the step of rebuilding the secret key reconstructs the secret key from all the N recovered parts of the secret key.

(198) The step of retrieving all N parts of the private key is such that the step of reconstructing the private key is performed by the external entity for each of the at least one trustee. The method of (197), further comprising the step of encrypting communication to the external entity, including said at least one device private key portion.

(199) The method of (198), wherein the step of encrypting a communication to the external entity, including the at least one device private key portion, further comprises a step of digitally signing the communication by the trustee. (200) For each of the at least one trustee so that the step of retrieving all N parts of the private key reconstructs the private key is performed by the depository center. The method according to (197), further comprising a step of encrypting communication to the at least one deposit center, including said at least one device private key permitter.

(201) The method of (200), wherein the step of encrypting a communication to the deposit center that includes the at least one device private key portion further comprises a step of digitally signing the communication by the trustee. (202) When the division method is M &lt;N, the secret key is divided into N storage parts so that only M parts are required to reconstruct the secret key, and the secret is divided into N storage parts. The step of retrieving the at least one portion of the key retrieves the at least one portion of the secret key from the at least one trustee so that at least M parts of the secret key are reclaimed. The method according to (194), wherein the step of reconstructing the secret key reconstructs the secret key from said at least M recovered parts of the secret key.

(203) The device for at least one trustee such that the step receiving at least M parts of the private key reconstructs the private key is performed by the external entity. The method according to (202), further comprising a step of encrypting communication to said external entity including a private key portion.

(204) The method of (203), wherein the step of encrypting a communication to the external entity, including the device private key, further comprises a step of digitally signing the communication by the trustee. (205) For each of the at least one trustee, such that the step of receiving at least M parts of the private key reconstructs the private key is performed by the depository center. The method according to (202), further comprising the step of encrypting communication to one deposit center at least later, including the device private key portion.

(206) The method of (205), wherein the encryption step for the deposit center, including the device private key portion, further comprises a step of digitally signing the communication by the trustee. (207) The step of encrypting the communication includes a step of creating a unique encryption key for use in both encryption and decryption of the encrypted communication between the first device and the second device. The method according to (94), further comprising a step of encrypting the communication to the second device using the encryption key by the first device.

(208) The step of creating the unique encryption key calculates the intermediate number of the second device by the second device using the private key of the second device and at least one public key. The encryption using the step, the step of acquiring the intermediate number of the second user by the first user, the secret key of the first device by the first device, and the intermediate number of the second device. The key calculation step is further provided, and the communication from the first device to the second device encrypted using the encryption key can be decrypted simply by using the encryption key. The method described in (207).

(209) The method of (208), wherein the private key of the second device is randomly created by the second device. (210) The method according to (208), wherein the intermediate number of the second device constitutes the public key of the second device. (211) The method according to (208), wherein the intermediate number of the second device and the at least one public number include the public key of the second device.

(212) The method according to (208), further comprising the step of calculating the intermediate number of the first device using the secret key of the first device by the first device and the at least one public key. .. (213) The method according to (212), wherein the private key of the first device is randomly created by the first device.

(214) The method according to (212), wherein the step of inserting the message control header further comprises a step of forming a message control header packet constituting the intermediate number of the first device and the at least one public number. (215) The step of decrypting the encrypted communication by the second device uses the secret key of the second device by the second device and the intermediate number of the first device. The method according to (214), which comprises a step of calculating an encryption key and a step of decrypting the communication from the first device using the encryption key by the second device. 216) The method according to (207), wherein the step of creating the unique encryption key comprises the step of interactively creating the encryption key by each of the first device and the second device.

(217) The step of creating the encryption key interactively by each of the first and second devices uses the private key of the first device and at least one public number to create the first device. The step of calculating the first intermediate number by the second device, the step of calculating the intermediate number by using the secret key of the second device by the second device, and the at least one public number, and the step of calculating the intermediate number by the first device. Using the secret key of the first device and the second intermediate number to calculate the encryption key, and using the secret key of the second device and the first intermediate number of the second device by the second device. The first device to the second device or the second device to the first device encrypted using the encryption key. The method according to (216), wherein the communication can be decrypted using only the encryption key.

(218) The method of (217), wherein the private key of the first device is randomly created by the first device. (219) The method according to (217), wherein the private key of the second device is randomly created by the second device. (220) The step of decrypting the encrypted communication by the second device further comprises decrypting the communication from the first device by the second device using the encryption key. The method according to (217), which comprises a step.

(221) The public key of the first corresponding key pair is used to encrypt the encrypted communication to the device, and the corresponding private key of the first corresponding key pair decrypts the encrypted communication. The private key of the second corresponding key pair is used to digitally sign the digital data, and the corresponding private key of the second corresponding key pair is used to verify the digital signature. Allowing an external entity to monitor said communication in a cryptosystem with multiple trusted devices, each trusted device having at least two corresponding pairs of randomly created asymmetric encryption keys. It is a method for creating authenticateable and trusted cryptographic communication between multiple user devices. The step of depositing each at least one secret decryption key of the trusted device to at least one deposit center and the deposit of the at least one secret decryption key of each of the devices by said at least one deposit center. The first step of the user device relative to the second of the user device using the step of authenticating at least one private signing key of each of the devices and the public encryption key of the second device. A step of encrypting a communication from, a step of inserting a message control header containing sufficient information to identify the at least one trusted depository center in the encrypted communication, and a step of the second device. The step of decrypting the encrypted communication by the second device using the secret decryption key is provided, and the step of decrypting the encrypted communication by the second device is described as described above. A method subject to the authentication of the secret decryption key of each of the first and second devices and the presence of a valid message control header in the communication.

(222) The step of encrypting the communication from the first device identifies the secret decryption key of each of the first device and the second device and the presence of a valid message control header in the communication. The method described in (221) as a condition. (223) The method of (221), wherein the first device and the second device are identical such that the communication is encrypted from the first device to itself for storage.

(224) The ability and security of each of the trusted devices to randomly create the at least two corresponding encryption key pairs for encryption and decryption, as well as for signing and verification. The method according to (221), which has the ability to memorize each of the key pairs in an unreadable manner to prevent tampering.

(225) Each said trusted device has a manufacturer, and the step of authenticating at least one private signature key further authenticates the ability of a superior authority to randomly create and store said key of the device. The method according to (224).

(226) The step of authenticating the capabilities of the device is also randomized in such a way as to prevent unauthorized movement of the manufacturer's reliability and the key of the device manufactured by the manufacturer. The method according to (225), comprising the step of notarizing the ability to create and memorize the manufacturer's certification by the superior authority.

(227) The method according to (226), wherein the higher authority constitutes the entire system authority. (228) The method according to (226), wherein the manufacturer certification is attached to each signature issued using a private signature key created by the manufacturer. (229) The method according to (221), further comprising a step of authenticating the reliability of at least one depositary center by a superior authority.

(230) The step of authenticating the depositary center comprises issuing a certification by the superior authority for each of the at least one depositary center, notarizing the authenticity of the depositary center for the purpose of depositing (229). The method described in. (231) The method according to (230), wherein the higher authority constitutes the entire system authority.

232) The method of (230), wherein the superior authority constitutes at least one manufacturer of the device. (233) The depositing step divides the secret decryption key into parts for each user device and provides each of at least one trustee with at least one part of the secret key. And the step of providing each of the at least one trustee with confirmation information that allows the trustee to confirm the correct receipt of the at least one portion of the private key, and by the at least one deposit center. The method according to (221), further comprising a step of confirming the correct receipt of the at least one portion of the private key by each of the at least one trustee.

(234) Each of the at least one deposit center comprises the user secret decryption key, the step of configuring and encrypting a trusted device, the easy step of performing the partitioning step by the deposit center. The method according to (233), further comprising the step of encrypting the communication to the at least one depository center.

(235) The method of dividing the private key into N parts such that the dividing step requires all of the N parts to reconstruct the private key. .. (236) If the split step is M &lt;N, split the private key into N parts so that only M parts are needed to rebuild the private key (234). ).

(237) The only deposit center's public encryption key is pre-embedded in the user device by the device manufacturer so that it is selected by the manufacturer for the purpose of depositing by the deposit center. The method according to (234), wherein the deposit step further comprises a step of encrypting communication to the deposit center using the pre-embedded deposit center encryption key.

(238) In the user device by the manufacturer of the device so that the public encryption key of at least one deposit center is selected by the manufacturer for the purpose of depositing a group of at least one deposit center. The step of pre-embedding and depositing into at least one of the secret keys for one of the groups of at least one deposit center using one of the pre-embedded deposit center public encryption keys. The method according to (234), further comprising a step of encrypting a communication involving one part.

(239) The method of (234), wherein the encryption key of the at least one deposit center is obtained by the user device from the deposit authentication directory. (240) The step of encrypting a communication to the at least one deposit center, including the user device secret encryption key, further adds a step of digitally signing the communication by the device using the secret device signing key. The method according to (234).

(241) The step of providing each of the at least one trustee with at least one portion of the secret key is such that the deposit center provides the at least part of the secret key for each of the at least one trustee. The method according to (234), further comprising a step of encrypting the including communication.

(242) The step of encrypting a communication to each of the at least one trustee, including the at least one portion of the device private key, further comprises a step of the deposit center digitally signing the communication (241). ). (243) The step of providing confirmation information to each of the at least one trustee puts the confirmation information in the communication to each of the at least one trustee, including the at least one portion of the private key (241). ) (244) The method of (243), wherein the step of encrypting a communication to each of the at least one trustee further comprises a step of the deposit center digitally signing the communication.

(245) The method of (233), wherein each of at least one trustee constitutes a trusted device and the dividing step is performed by the device. (246) The method of (245) comprising dividing the private key into N parts such that all of the N parts are required to reconstruct the private key.

(247) If the splitting step is M &lt;N, the private key is split into N parts so that only M parts are needed to reconstruct the private key (247). 245). (248) The user device by the manufacturer of the device such that the public encryption key of the at least one trustee is selected by the manufacturer for the purpose of depositing a group of at least one trustee. The step, which is pre-embedded in and provides each of at least one trustee with at least one portion of the private key, further uses the pre-embedded trustee's public encryption key. (245), wherein the device encrypts communication between the groups of at least one trustee, including at least one portion of the private key to each of the at least one trustee. Method.

(249) The method of (248), wherein the step of encrypting a communication to each of the at least one trustee further comprises a step of digitally signing the communication by the user device. (250) The step of providing each of the at least one trustee with at least one portion of the private key identifies each of the at least one trustee who has received the portion of the private key from the user device. The method of (248), comprising a step of the user device encrypting communication to the deposit center for later use in the confirmation step.

(251) The user device is in said communication to each of the at least one trustee, including the at least one portion of the private key, in the step of providing confirmation information to each of the at least one trustee. The method according to (248), wherein the confirmation information is input.

(252) The method of (251), wherein the step of encrypting a communication to each of the at least one trustee further comprises a step of digitally signing the communication by the user device. (253) The confirming step by the at least one deposit center notifies the deposit center of receipt of the at least one portion of the private key of the user device for each trustee by the trustee. By the trustee of at least one part of the secret key based on the step of communicating the confirmation information by the trustee to the deposit center and the correct communication of the confirmation information by the trustee. The method according to (233), comprising a step of confirming the correct receipt by the depository center.

(254) The method according to (253), wherein the step of communicating the confirmation information by the trustee comprises a step of encrypting the communication to the deposit center including the confirmation information by the trustee. (255) The method of (254), wherein the step of encrypting a communication to the deposit center containing the confirmation information further comprises a step of the trustee digitally signing the communication.

(256) The step of authenticating the deposit of the at least one secret decryption key notarizes the connection between the public key and the private key and the corresponding device, and the secret decryption key of the corresponding key pair. The method according to (233), further comprising the step of issuing a deposit certificate by one deposit center for each corresponding key pair of each said user device, ensuring that the deposit is made.

(257) The step of authenticating the deposit of the secret decryption key further comprises a step of confirming the deposit of the secret decryption key prior to the step of issuing the deposit certificate (256). Method. (258) The step confirming the deposit of the secret decryption key notifies the deposit center of receipt by the songwriter of the at least one portion of the secret decryption key of the device for each trustee. The step of communicating the confirmation information by the trustee to the deposit center, and the at least one portion of the secret decryption key of the device based on the correct communication of the confirmation information by the trustee. The method according to (257), comprising the step of confirming the correct receipt by the trustee by the depository center.

(259) The step in which the deposit center constitutes a trusted device and the confirmation information is communicated to the deposit center by the trustee comprises a step of encrypting the communication to the deposit center including the confirmation information. The method described in (258). (260) The step of configuring the trusted device by the trustee and encrypting the communication to the deposit center further comprises the step of the trustee digitally signing the communication using the secret signing key ((260). The method described in 259).

(261) The method of (260), wherein the confirming step further comprises confirming the signature of the trustee in the communication, including the confirmation information. (262) The method according to (256), wherein the deposit authentication constitutes the identification of the certificate issuing deposit center, the digital identification code of the deposit authentication, and the public encryption key corresponding to the deposited secret decryption key. ..

(263) The encrypted message control header in which the step of inserting the message control header in the encrypted communication constitutes the digital identification code of the deposit center of the first user device and the deposit authentication of the first user device. The method according to (262), comprising the step of forming a packet.

(264) The step of inserting the message control header further comprises a step of forming a cryptographic message control header constituting the identification of the deposit center of the second user device and the digital code identification of the deposit authentication of the second user device. (263).

(265) The deposit center of the first device and the deposit center of the second user device are the same, and the step of inserting the message control header further identifies the deposit center of the first device and the second device and the above. The method according to (264), comprising each step of forming the digital code identification of the deposit authentication.

(266) The step of inserting the message control header is a step of forming a cryptographic message control header packet constituting the identification of the owner of the first user device or the identification of the employer or supervisor of the user of the one user device. Further provided, the method according to (263).

(267) The step of including the message control header forms a cryptographic message control header packet that constitutes the identification of the owner of the second user device or the employer or supervisor of the user of the second user device. The method according to (266).

(268) The owner of the first and second user devices or the employer or supervisor of the user of the first and second user devices is the same, and the step of inserting the message control header is the possession. The method according to (267), further comprising the steps of forming a cryptographic message control header packet that constitutes the identification of a person, employer or supervisor and the digital code identification of each of the deposit authentications.

(269) The step of inserting the message control header comprises forming a cryptographic message control header packet constituting a time stamp indicating the date and time of creation of the message control header by the first user device (263). The method described in.

(270) Each trusted device comprises a time clock to create a time stamp indicating the date and time of the encrypted communication and the message control header, and the step of inserting the message control header is the time stamp. The method according to (269), which further comprises a step of certifying the reliability of the.

(271) The method according to (270), wherein the step of authenticating the reliability of the time stamp issues a certificate by a higher authority notarizing the reliability of the time clock for the purpose of creating the time stamp. (272) The method according to (271), wherein the step of authenticating the time stamp attaches the time clock authentication to each of the created time stamps.

(273) The method according to (271), wherein the higher authority time clock has all system authority. (274) The method of (271), wherein the higher authority time clock comprises the manufacturer of the device. (275) The method of (270), wherein the trusted time clock can only be set or calibrated by the manufacturer of the time clock.

(276) The method according to (263), further comprising the step of monitoring the encrypted communication by the external entity having permission to install the wiretapping device. (277) The monitoring step interrupts the encrypted communication by the external entity, and presents the wiretapping device installation permission and the message control header to the deposit center of the first user device. And the step of acquiring the secret decryption key of the first user device deposited in the deposit center of the first user device, and the encrypted communication of the secret decryption key of the first user device. The method according to (276), further comprising steps used for decryption.

(278) The presented step is a step of extracting the digital identification code of the deposit center of the first user device and the deposit authentication of the first user device from the message control header, and the wiretapping device installation. The method according to (277), further comprising the step of presenting the digital identification code of the authorization and the deposit authentication of the first user device to the deposit center of the user device.

(279) The first user device comprises a time clock trusted to form and create a time stamp indicating the date and time of the encrypted communication and the formation of the message control header, and the step of inserting the message control header , The method according to (278), further comprising a step of forming an encrypted message control header packet constituting a time stamp and a step of authenticating the reliability of the time clock for the purpose of creating the time stamp.

(280) The method according to (279), wherein the step of authenticating the reliability of the time stamp issues a certificate by a higher authority that notarizes the reliability of the time clock for the purpose of creating the time stamp. (281) The method according to (280), wherein the step of authenticating the time stamp attaches the time clock to each of the created time stamps.

(282) The method according to (280), wherein the higher authority time clock has all system authority. (283) The method of (279), wherein the trusted time clock can only be set or calibrated by the manufacturer of the manufacturing time clock. (284) The method of (277), wherein the step of using the secret decryption key of the first user device to decrypt the first user device is performed by the external entity.

(285) The method of (277), wherein the step of using the secret decryption key of the first user device to decrypt the communication is performed by the deposit center. (286) The method according to (277), wherein the wiretapping device installation permit is subject to at least one predefined restriction.

(287) The at least one predefined constraint includes a start date and time in which the wiretapping device installation permit must not previously occur the step of acquiring the private key of the first device. The method according to (286), which comprises such a time constraint.

(288) The at least one predefined constraint includes an end date and time in which the wiretapping device installation permit must not otherwise occur the step of acquiring the private key of the first device. The method according to (287), which comprises such additional time constraints.

(289) The at least one predefined constraint includes an end date and time in which the eavesdropping device installation permit must not otherwise undergo the step of acquiring the private key of the first device. The method according to (286), which comprises such a time constraint.

(290) The step of acquiring the private key of the first device includes a step of collecting the at least one part of the private key of the first user device from the at least one trustee and the collection of the private key. The method according to (277), comprising the step of reconstructing the private key from the portion.

(291) The method of (290), wherein the acquisition step is performed by the deposit center. (292) The method of (290), wherein the acquisition step is performed by the external entity. (293) The secret key is divided into N parts so that the dividing step requires all of the N parts to reconstruct the secret key, and at least the secret key. Retrieving one Part Retrieving each of the at least one part from the at least one trustee of the secret key so that all of the N parts of the secret key are required. The method according to (290), wherein the step of rebuilding the secret key reconstructs the secret key from all of the N recovered parts of the secret key.

(294) For each of the at least one trustee so that the step of retrieving all N parts of the private key reconstructs the private key is performed by the external entity. The method according to (293), further comprising the step of encrypting a communication to the external entity including the at least one device private key portion.

(295) The method of (293), wherein the step of encrypting a communication to the external entity, including the at least one device private key portion, further comprises a step of digitally signing the communication by the trustee. (296) The step of retrieving all N parts of the private key includes said at least one device private key part such that the step of rebuilding the private key is performed by the deposit center. The method according to (293), further comprising the step of encrypting the communication to the at least one depository center.

(297) The method of (296), wherein the step of encrypting a communication to the deposit center that includes the at least one device private key portion further comprises a step of the trustee digitally signing the communication. (298) If the step to divide is M &lt;N, the private key is divided into N parts so that only M parts are needed to reconstruct the private key. The step of retrieving the at least one portion of the private key retrieves the at least one portion of the secret key from the at least one trustee so that at least M parts of the secret key are reclaimed. The method according to (290), wherein the step of rebuilding the secret key reconstructs the secret key from at least M recovered parts of the secret key.

(299) For each of the at least one trustee so that the step of retrieving at least M parts of the private key performs the step of reconstructing the private key by the external entity. The method according to (298), further comprising a step of encrypting communication to the external entity, including the device private key portion.

300) The method of (299), wherein the step of encrypting a communication to the external entity including the device private key portion further comprises a step of digitally signing the communication by the trustee. (301) For each of the at least one trustee so that the step of retrieving at least M parts of the secret key is performed by the deposit center so that the step of reconstructing the secret key is performed by the deposit center. The method according to (298), further comprising a step of encrypting communication to the at least one deposit center, including the device private key portion.

(302) The method of (301), wherein the step of encrypting a communication to the deposit center, including the device private key portion, further comprises a step of the trustee digitally signing the communication. (303) The encrypted message control header packet in which the step of inserting the message control header in the encrypted communication constitutes the digital identification code of the deposit center of the second user device and the deposit authentication of the second device. (262).

(304) The step of inserting the message control header forms a cryptographic message control header packet that constitutes the identification of the owner of the second user device or the employer or supervisor of the user of the second user device. The method according to (303).

(305) The method according to (303), further comprising a step of monitoring the encrypted communication by the external entity having permission to install the wiretapping device. (306) The monitoring step includes a step of interrupting the encrypted communication by the external entity, a step of presenting the wiretapping device installation permission and the message control header to the deposit center of the second user device, and the above. The step of acquiring the secret decryption key of the second user device deposited in the deposit center of the second user device, and the secret decryption key of the second user device for decrypting the encrypted communication. The method according to (305), further comprising steps to be used.

(307) The presented step is a step of extracting the digital identification code of the deposit center of the second user device and the deposit authentication of the second user device from the message control header, and the wiretapping device installation. The method according to (306), further comprising the step of presenting the digital identification code of the authorization and the deposit authentication of the second user device to the deposit center of the second device.

(308) The step of inserting the message control header, wherein the first device comprises a time clock trusted to create a time stamp indicating the date and time of the encrypted communication and the creation of the message control header. The method according to (307), further comprising a step of forming a message control header packet constituting a time stamp and a step of authenticating the credibility of the time clock for the purpose of creating the time stamp.

(309) The method according to (309), wherein the step of authenticating the reliability of the time stamp issues a certificate by a higher authority notarizing the reliability of the time clock for the purpose of creating the time stamp. (310) The method according to (309), wherein the step of authenticating the time stamp attaches the time clock authentication to each of the created time stamps.

(311) The method according to (309), wherein the higher authority time clock has all system authority. (312) The method of (309), wherein the higher authority time clock comprises the manufacturer of the device. (313) The method of (308), wherein the trusted time clock can only be set or calibrated by the manufacturer of the time clock.

(314) The method of (306), wherein the step of using the secret decryption key of the second user device to decrypt the communication is performed by the external entity. (315) The method of (306), wherein the step of using the secret decryption key of the second user device to decrypt the communication is performed by the deposit center.

(316) The method according to (306), wherein the wiretapping device installation permit is subject to at least one predefined constraint. (317) The at least one predefined constraint includes a start date and time in which the wiretapping device installation permit must not previously occur the step of acquiring the private key of the second device. The method according to (316), which comprises a time constraint so as to be.

(318) The at least one predefined constraint includes an end date and time in which the wiretapping device installation permit must not subsequently undergo the step of acquiring the private key of the second device. (317).

(319) The at least one predefined constraint includes an end date and time in which the wiretapping device installation permit must not subsequently undergo the step of acquiring the private key of the second device. The method according to (317), which has such a time constraint.

(320) The step of acquiring the secret decryption key of the second user device is a step of recovering the at least one part of the secret key of the second user device from each of the at least one trustee. The method according to (306), further comprising the step of reconstructing the secret key from the recovered portion of the secret key.

(321) The method of (320), wherein the acquisition step is performed by the deposit center. (322) The method of (320), wherein the acquisition step is performed by the external entity. (323) The splitting step splits the secret key into N parts so that all N parts are required to reconstruct the secret key, and at least one of the secret keys. The step of retrieving parts reclaims each of the at least one part of the secret key from each of the at least one trustee so that all N parts of the secret key are reclaimed. The method according to (320), wherein the step of rebuilding the private key reconstructs the private key from all the N recovered parts of the private key.

(324) For each of the at least one trustee that the step of retrieving all of the N parts of the private key is performed by the external entity so that the step of reconstructing the private key is performed by the external entity. The method according to (323), further comprising the step of encrypting a communication to the external entity including the at least one device private key portion.

(325) The method of (324), wherein the step of encrypting a communication to the external entity, including the at least one device private key portion, further comprises a step of digitally signing the communication by the trustee. (326) For each of the at least one trustee so that the step of retrieving all N parts of the private key and the step of reconstructing the private key are performed by the deposit center. The method according to (323), further comprising a step of encrypting communication to the at least one deposit center that includes the at least one device private key portion.

(327) The method of (326), wherein the step of encrypting a communication to the deposit center that includes the at least one device private key portion further comprises a step of the trustee digitally signing the communication. (328) If the splitting step is M &lt;N, the private key is split into N parts so that only M parts are needed to reconstruct the secret key. The step of retrieving the at least one portion of the private key retrieves the at least one portion of the secret key from at least one trustee so that at least M parts of the secret key are reclaimed. The method according to (320), wherein the step of reconstructing the secret key reconstructs the secret key from at least M recovered parts of the secret key.

(329) For each of the at least one trustee so that the step of retrieving at least M parts of the private key is performed by the external entity so that the step of reconstructing the private key is performed by the external entity. The method according to (328), comprising a step of encrypting communication to the external entity, including the device private key portion.

330) The method of (329), wherein the step of encrypting a communication to the external entity including the device private key portion further comprises a step of digitally signing the communication by the trustee. (331) For each of the at least one trustee, such that the step of retrieving at least M parts of the private key reconstructs the private key is performed by the depository center. The method according to (328), further comprising a step of encrypting communication to the at least one deposit center, including the device private key portion.

(332) The method according to (331), wherein the step of encrypting a communication to the deposit center including the device private key portion comprises a step of digitally signing the communication by the trustee. (333) Grant the trusted device permission to perform electronic transactions between the first user and the second party, and the trusted device is subject to pre-determined rules that cannot be modified by the user. A method of providing a guarantee to engage in an electronic transaction, the trusted device electronically transmitting a request for permission to engage in the electronic transaction to a third party, the request being said. Authority to engage in the transaction, at least in part, in accordance with the determination by the third party that the trusted device operates in accordance with the rules, including the identity of the trusted device. The third party electronically transmitted permission to engage in the electronic transaction to the trusted device, and the permission was granted by the third party. That the trusted device is authorized to engage in the electronic transaction from the trusted device to the second party and will only engage in the electronic transaction in accordance with the rules. A method of electronically transmitting transaction data as a guarantee of the above, and electronically transmitting transaction data from the trusted device to the second party in accordance with the above rules.

(334) The method of (333), wherein the authorized transmission step comprises a step of said rule transmission from the third party to the trusted device. (335) The method of (333), wherein the trusted device comprises the rules prior to the authorized transmission step.

(336) The method of (333), wherein the authorized transmission step comprises attaching the digital signature of the third party to the authentication. (337) The method of (333), wherein the request transmission step comprises transmitting the authentication of the identity of the trusted device digitally signed by the manufacturer of the trusted device.

(338) The method of (333), wherein the determination step comprises determining whether the device is a person who prevents fraudulent movement based on the identity of the trusted device. (339) The method of (333), wherein the trusted device associates the public and private keys of an asymmetric cryptographic system with it, and the transmission step comprises transmitting the device public key to the third party. ..

(340) The identity authentication comprises the public key of the trusted device's public-private key pair, and the request transmission step originated from the third party's request from the trusted device. The method according to (337), comprising attaching to the request a digital signature of the trusted device created using the device private key so that the device can be identified.

(341) The step in which the trusted device associates the first and second keys of the asymmetric cryptosystem with it and transmits transaction data to the second party is created using the first key. The method described in (333), which comprises the step of attaching a digital signature of a trusted device.

(342) The method according to (340), wherein the step of transmitting the transaction data to the second party includes a step of transmitting the second key to the second party. (343) The method according to (341) or (342), wherein the first device key and the second device key are a private key and a public key, respectively.

<figref num="1A">A list of symbols and abbreviations used in the drawings of the present invention.</figref><figref num="1B">A list of symbols and abbreviations used in the drawings of the present invention.</figref><figref num="1C">A list of symbols and abbreviations used in the drawings of the present invention.</figref><figref num="1D">A list of symbols and abbreviations used in the drawings of the present invention.</figref><figref num="1E">A list of symbols and abbreviations used in the drawings of the present invention.</figref><figref num="1F">A list of symbols and abbreviations used in the drawings of the present invention.</figref><figref num="1G">A list of symbols and abbreviations used in the drawings of the present invention.</figref><figref num="2">It is a flowchart which shows the step of the interactive Differ-Hermann key derivation method by the prior art.</figref><figref num="3">It is a flowchart which shows the step of the authentication part of the authentication type Differ-Hermann method by the conventional technique.</figref><figref num="4">It is a flowchart which shows the step of the message communication part of the authentication type Differ-Hermann method by the conventional technique.</figref><figref num="5">It is a flowchart which shows the step of the encryption using the RSA transfer method by the prior art.</figref><figref num="6">It is a flowchart which shows the step of the decoding using the RSA transfer method by the prior art.</figref><figref num="7">It is a flowchart which shows the step of the signature creation using the RSA transfer method by the prior art.</figref><figref num="8">It is a flowchart which shows the step of signature confirmation using the RSA transfer method by the prior art.</figref><figref num="9">It is a flowchart which shows the step of the Mikari key deposit process by the conventional technique together.</figref><figref num="10">It is a flowchart which shows the step of the Mikari key deposit process by the conventional technique together.</figref><figref num="11">It is a flowchart which shows the step of the Mikari key deposit process by the conventional technique together.</figref><figref num="12">This is an example of the format of public encryption key deposit authentication by the conventional technology.</figref><figref num="13">An example of a possible format for the Clipper Device Police Access Field (LEAF).</figref><figref num="14">This is an example of a device certification format issued by the device manufacturer of the present invention.</figref><figref num="15">It is a flowchart which shows the step of the method of depositing so that a key can be authenticated to only a depositary agent.</figref><figref num="16">It is a flowchart which shows the step of the method of depositing a key so that it can be authenticated based only on a trusted device.</figref><figref num="17">It is a flowchart which shows the step of the method of sending the message encrypted by the message control header (MCH).</figref><figref num="18">An example of MCH in RSA key transfer format.</figref><figref num="19">It is a flowchart which shows the step of the method of receiving the message encrypted by MCH.</figref><figref num="20">This is an example of a flowchart of the MCH decoder box and its process flow.</figref><figref num="21">This is an example of a trusted time stamp device that self-authenticates.</figref><figref num="22">This is an example of the device owner authentication format issued by the device manufacturer of the present invention.</figref><figref num="23">It is a flowchart which shows the step of the method of re-depositing (re-keying) the key by the owner of the device of this invention.</figref><figref num="24">It is a flowchart which shows the step of the method for registration of the trusted device of this invention by a trusted third party.</figref><figref num="25">The MCH format is shown.</figref><figref num="26">It is a figure which shows about the owner authentication.</figref><figref num="27">The processing of the owner public instruction key is shown.</figref><figref num="28">Indicates replacement of the owner public order approval key.</figref><figref num="29">Indicates the enforcement of deposit requirements when sending and receiving international encrypted communications.</figref><figref num="30">Indicates the enforcement of deposit requirements when sending and receiving international encrypted communications.</figref>