Method of and system for encoding with deposition of encoding keys

The subject of the invention is a method of encrypting a communication system, in particular secure production, confirmation, collection and distribution of encryption keys used in encrypted communication systems. The invention also relates to a system of depositing coded keys and management of public key certificates, supported by a self-testing microchip device.

The development and spread of complex computer technologists and data processing systems have led to the rapid development of digital forms of information transmission. This information is used in financial and banking operations, electronic mail, electronic data exchange and other data processing systems. Sending information on unprotected and unsecured communication channels exposes the transmitted information to changes. Cipher communication systems protect the secrecy of these transmissions by preventing any unauthorized alteration of information sent over an unprotected channel. Cipher communication systems also enable ensuring the completeness and authenticity of the transmission by creating understandable, non-fake and document-dependent digital signatures that prevent the sender from denying his own message.

The encryption method consists in encoding or encrypting transmitted digital data, including digitized voice or image transmission '' to make them incomprehensible to everyone except the intended recipient. An unencrypted message containing digitized sounds, letters and / or numbers is digitally encoded and then encrypted using a complex mathematical algorithm based on a set of digits that transforms the encoded message, also called a cipher key. A code key is a sequence of data bits that are randomly selected or have special mathematical properties that depend on the algorithm or encryption system used. Complex encryption algorithms implemented on computers transform and transform numbers containing hundreds of thousands of bits and are resistant to any known method of unauthorized decryption. There are currently two basic classes of cipher algorithms: symmetric key algorithms and asymmetric key algorithms.

Symmetric key algorithms use an identical code key for both encryption by the sender and decryption by the recipient of the transmission. Symmetric key encryption systems are based on mutual trust between two parties that share a common key used to protect the system against access by unauthorized third parties. The best known algorithm with a symmetrical key is the DES algorithm in accordance with the American Data Encryption Standard, published for the first time by the American standardization institution National Institute of Standard and Technology, Federal Register, March 17, 1975, volume 40, No. 52 and August 1, 1975, volume 40 , No. 149. The sender's encryption device uses the DES algorithm to encrypt the transmitted information with a cipher key, the DES key being 56 bits long, during the communication session using the session key. The recipient's decryption device uses the inverse DES algorithm to decrypt the encrypted message with the same encryption key that was used for encryption. However, the overall usefulness of symmetrical encryption systems has been questioned,

176 458 because they require, prior to the desired transmission between the sender and recipient, the exchange of the encryption key between the sender and the recipient through a secured channel to which no unauthorized third party has access. This procedure, in which you must first securely replace the code key and only then encrypt messages, is often slow and inconvenient, so it is not useful in situations requiring spontaneous or unexpected transmissions or in situations requiring communication between non-knowing parties. it allows access at both ends of the encrypted conversation

The second class of cipher algorithms, asymmetric algorithms, uses different cipher keys for encryption and decryption. In an encryption system using an asymmetric key algorithm, the user makes the encryption key public and keeps the private decryption key. It is not possible to derive the private decryption key from the public encryption key. Thus, anyone who knows the public key of a specific user can encrypt the message for that user, while only the user who owns the private key corresponding to the public key can decrypt the message. This public / private key system was first proposed by Diffie and Hellman in the publication "New Directions of Cryptography" in IEEE Transaction on Information Theory, November 1976 and in US Patent No. 4,200,770.

The early type asymmetric algorithm enables secure communication through an unprotected channel due to the interactive creation of a code key by the participants for the given communication session. Using an asymmetric key algorithm, two interacting users simultaneously and independently produce a secure combination key that cannot be decrypted by the eavesdropper and can be used symmetrically to encrypt a communication session between users. This interactive method of producing a secure digital key was described by Diffie and Hellman in a paper published in 1976.

To verify the sender, another digital signature system may also be used, called DSA from the words Digital Signature Algoritm, i.e. the Digital Signature Algorithm. The DSA algorithm is disclosed in US Patent Application No. 07/738431. The DSA algorithm has similar properties to the RSA signature algorithm in the sense that the sender processes the message using a hash algorithm to create a message hash, and then encrypts or signs the message hash with its private key. The recipient verifies the encrypted hash using the sender's public key. However, unlike the RSA signature algorithm, which restores the initial message hash when the recipient decrypts the signature block, the DSA verification algorithm only results in confirmation of the signature's authenticity. Messages encrypted using the intended recipient's public key cannot later be restored by decryption using the recipient's private key. For this reason, the DSA algorithm can be quite conveniently used for a digital signature, but not for key transmission or direct message encryption

For the public / private key system to work effectively, users must entrust the centralized authority certifying keys with responsibility for publishing and updating the public encryption key directory. The authority confirming the keys must be reliable for all users, both senders and recipients · ·. To this end, the confirming authority will spread the name and public encryption key information of each user and attach its own digital signature to the information to be sent to confirm its correctness. However, when more than one entity or hierarchy of entities is involved in the deposit process, there are several methodologies or trust models to determine how the user will deposit. There are three basic models: a pure hierarchical model, a model that performs mutual confirmation between multiple hierarchies, and a local trustee model. These models are described in detail in the standardization document of the American Institute for Standardization Χ9.30 “Public key cryptography, using irreversible algorithms, for the institute6

176 458 Financial Support Services: Part 3: DSA Certificate Management, American Bankers' Association, Washington DC, 1992. Although there is no general agreement as to which of the above deposit models is the best, it is assumed in the description that it will be an appropriate, generally accepted model for reliable certificates, established in which the issuing of certificates will be carried out by more than one entity.

The public / private key system described above takes into account the need for confidentiality by users who wish to send and receive messages secretly. However, compliance with national law and security must also be considered. The ability for the government to monitor and eavesdrop on electronic transmissions for law enforcement and national security purposes must be ensured so that suspected criminals, terrorists and foreign spies cannot conspire outside the law. While telephone communications can be monitored by wiretaps, encryption algorithms make encrypted data impossible to decrypt even by powerful computers capable of breaking ciphers. The increase in the percentage of digital and digitized encrypted transmissions using advanced algorithms makes legal, government electronic surveillance of these transmissions difficult, especially if encryption devices are widely introduced into telephones, computers, copiers and other data processing equipment.

One way to enable government or other authorized investigators to monitor the connectivity of suspected criminals is to require all users of cipher communications to entrust their private decryption keys to either private institutions or the government. However, this method is not useful because it has insufficient protection against the government's misusing private decryption keys and against the possibility of private decryption keys getting into unauthorized third parties through theft or corruption.

Another method of depositing private encryption keys, which allows you to keep the secret of transmission and ensure law enforcement, is to use a system such as described in the publication "Honest Encryption Systems with Public Keys" by Sylvio Micali, presented at CRYPTO 92 in March 1993 and published by the Laboratory of Computer Sciences Massachusetts Institute of Technology, October 1993 and U.S. Patent No. 5,276,737.

The main deposit center as a trusted institution confirming the authenticity of users' public keys periodically issues publicly available certificates attesting or certifying the relationship between the public key and information identifying its owner. The certificate of authenticity assures the sender that the transmission to the specified user of the public key will actually be received and read only by the intended recipient. The certificate usually has an internationally accepted electronic format, such as that adopted in the CCITT Recommendation X.509 issued as an international standard by the International Organization for Standardization ISO. The certificate contains, among others, the name of the organization or the key of the management center, which issues the issuer, public key owner certificates, information identifying the owner, certificate series number and the beginning and end dates of the validity period. The issuer's digital signature authenticates the certificate and prevents its change.

However, the US government proposed, as a governmental and perhaps industrial standard, another method to deposit private decryption keys and monitor communications. The US government commissioned the development of a chip called a Clipper cube that can be embedded in government and industrially manufactured telephones and computer devices. The Clipper cube is a cheap cube that can be used for mass encryption and key management. The Capstone cube is a more advanced version of the Clipper cube, additionally having the option of making a digital signature and a message hash. Like other encryption systems, the Clipper cube uses a symmetrical encryption algorithm, such as a qualified algorithm called Skipjack, which encrypts by mixing telephone or computer communication data in a manner similar to DES, but using an 80-bit key. Each Chpper cube has a unique serial number, a Clipper family key shared by all, and its own symmetrical device key, which will be needed by authorized government agencies to decode messages encoded by the device containing the cube. The device's unique private key is divided into two components called key fragments, placed separately in two databases of deposited keys or agencies that will be established by the government.

In the event that Clipper cube users want to connect, they first agree on a symmetrical session key with which they encrypt the transmission. Any method of obtaining a symmetric key can be used here, such as an interactive Diffie-Hellman key, and any method of sending a DES session key between users, such as RSA transfer. At the beginning of each communication, each user sends a LEAF Law Enforcement Access Field to the other, which contains information enabling law enforcers to eavesdrop or monitor communications. To create the LEAF, the session key is first encoded using the private device key, then the session key encoded with the device key, the sender's device serial number and the checksum, i.e. the verification value of the original, unencrypted session key are encrypted together with the cutter family key, creating a complete LEAF. The message is then encrypted using the selected session key. The message encrypted with the session key and LEAF encrypted with the family key are sent together to the recipient. After receiving the message, the recipient first loads the received LEAF into his Clipper cube to check whether the LEAF is valid and whether the session key encrypted with LEAF agrees with the previously received session key. If LEAF is valid, the Clipper cube will decrypt the message using the session key previously received.

The law enforcement agent, legally eavesdropping or monitoring the transmission, however, does not know the session key, so he must first decrypt the LEAF to obtain the session key. The agent takes over the desired LEAF, decrypts it using the Clipper family key and then presents the cube's serial number from LEAF, court authorization or other legal permission to two government trustees, resulting in two pieces of the private key of the user's eavesdropping device. The agent combines the two deposited device key fragments and uses the obtained device key to decrypt the key encrypted session key with LEAF. The session key can then be used to decrypt the actual message being sent. The requirement for both the sender and recipient to form the LEAF and certify the other's LEAF ensures that law enforcement agents will have a reasonable chance of acquiring the LEAF, as each LEAF is expected to be transmitted between users through the same means of communication. In addition, it allows law enforcement agents to selectively monitor only one suspicious user by decrypting the LEAF created by that user regardless of which user has made contact.

There are many technical problems associated with the government's proposal to use Clipper cubes, mainly due to the fact that the private keys to be entrusted are permanently embedded in the Clipper cubes during their manufacture. Because the private encryption key is placed in the cube and cannot be changed, the cube and probably the entire device that contains it will have to be discarded when it is discredited. It is beneficial for the user of a specific device to be able to change the key freely, change the trustee and obtain a re-certification of the device if he suspects that it has been discredited or at regular intervals to avoid potential discrediting. The user not only cannot change the key and the trustee, but by using the Clipper device there is no choice of the number and identity of trustees employed by the government to protect his private key. Private key fragments are deposited in two deposit databases or agencies established by the government. Users may not trust devices with Clipper cubes due to the risk that the government may have full access to any operation or transaction through the device, access that may be abused or corrupt. Users can also themselves

176 458 wish that their keys be kept with more trustees than the government provides, for greater security of their private keys. If the concept of stored keys is to be relevant, each user must be able to choose their own trustee to entrust private keys, given the desired level of trust.

It can also be assumed that the government Clipper system enables symmetrical communication between users in real time and does not give any direct possibility of sending messages in a memory sending email system. Before encrypting communications, the sender and recipient must first agree on a symmetrical session key by which they encrypt the communication. Typically, this key exchange is done using the interactive Diffie-Hellman scheme, the only key exchange method implemented by the Clipper cube. So, if you do not want to organize your own key exchange system, you are limited to simultaneous interactive communication such as voice or fax communication in real time. To send messages, as in a remembered-sending e-mail system, the user must be able to access public intended recipient's key, as with the use of confirmed Diffie-Hellman or key transmission according to the confirmed RSA scheme, even if the intended recipient is not available for interactive, direct communication. Since it can be assumed that the Clipper government system does not allow this, sending messages in the memory-sending system is difficult. The system in the standard proposed by the government may aim to limit the possibilities of communication to direct interactive communication.

In addition, in the government system, the user employer does not have access to encrypted data or transmission of his employees. Employers on whose behalf employees develop, transfer or transfer confidential or proprietary data must retain the right to access their employees' data or communications. There can be many situations in which encrypted information would only be available to specific employees directly involved in the use of the encryption system,. and not for the board of directors or directors who are responsible for these employees and have the enterprise's data sources at their disposal. By encrypting data or communications, employees can develop or appropriate new programs, products or technologies, or may conduct illegal activities and operations, all without the knowledge of their employers. Also the change or reorganization of staff or change of storage devices may result in the loss of a large amount of information that at the time of encryption was so important that it was encrypted, see Donn B. Parker "Encrypting and Avoiding Enterprise Information Anarchy", presentation of the invited speaker at the first annual conference on computers and communications security, 3-5 October 1993, Reston VA. In addition to the data creator or sender of the transmission, the Clipper cube only allows the government to access the transmission. Although employers may obtain a court order to monitor their employees' communications, they may still want to screen officers more discreetly than by initiating a state investigation when suspicion arises.

In addition, mandating a qualified algorithm, which is embedded in the cube, and hence available only in the form of equipment only from government-authorized cube manufacturers, introduces the government to the rapidly changing and very competitive market of communications and computer equipment. A government agenda or government-authorized manufacturer may or may not want to design and market advanced equipment and products specifically tailored to specific companies, as a private manufacturer would do. If the government only authorizes certain sellers to produce cubes with a qualified algorithm, there will be limited competition , and the technology will not be able to be incorporated into other products. In addition, because the details of the Skipjack algorithm have not been made public, there is a suspicion that the algorithm will not be uncertain due to either the oversight of its designers or by the deliberate introduction of a trap by the government. An important value of a cipher system design is that it is secret and encrypted security

176 458 messages should depend on the secrecy of the relevant key values ​​and not on the secrecy of system details.

The method according to the invention consists in verifying each of the many keys at the deposit center, confirming each of the many keys after verification and initiating transmission from each of the many users using one of the many keys subject to confirmation.

It is preferred that each key is verified in the deposit center, each key is confirmed after verification and secure transmission is initiated from the initiating user to the receiving user, subject to confirmation of the keys of both the initial user and the receiving user.

It is preferred that at least the first selected unit, which is not a communication party, is made available for user communications, keys are verified in the deposit center, each key is confirmed after verification, and reliable transmission is initiated from the initiating to the receiving user in a manner enabling access to communication first unit not being a communications party.

It is beneficial that when each user is equipped with a computer device, the computer devices are registered in the center in accordance with the control information specified by the owner of the device, who is not the device user, the computer devices are confirmed, with each confirmation creating a certificate associated with the center, computer user and device and secure transmission is initiated from the initiating user to the recipient, using the message key in a way that allows the owner to access the transmission.

It is beneficial that the keys are verified in the escrow center, each key is confirmed after verification, and reliable transmission is initiated from the sending user to the receiving user using the verified key, with the information included in the transmission to obtain the initiating user key and the receiving user key

It is preferred that using electronic computer devices controlled by tamper-proof logic, secure transmission is initiated from the initiating device to the receiving device, with access information signed by the initiating device being included in the transmission and access to the transmission via the external party being enabled.

It is preferred that the keys are verified at the escrow center, each key is confirmed after verification, and transmission is initiated from the initiating user to the receiving user, subject to confirmation of the keys of the initiating user and the receiving user by a reliable device of the initiating user.

It is beneficial that the keys are verified in the deposit center, each key is confirmed after verification, and transmission from the initiating user to the receiving user is initiated, conditioned by confirmation of the key used in the transmission, with access information included in the transmission to allow access to the transmission through the outside.

It is beneficial that the keys are verified in the deposit center, each key is confirmed after verification and a reliable device associated with each user and transmission is initiated from the initiating user to the recipient after confirmation of the key used in the transmission and after confirming the parameters of a reliable device associated with the initiating user .

It is beneficial that one of the deposit centers is assigned to the first group, the other of the deposit centers is assigned to the second group, the keys in the deposit centers are verified, each of the keys is verified after verification, and the transmission between the first user and the second user, conditioned by groups, is carried out, to which the sender's and recipient's deposit centers are assigned.

It is beneficial that each of the keys in the depository center is verified, each key is confirmed after verification and an encrypted streaming transmission is created from the user10

176 458 initiating access to the receiving user, using the initiating user's encryption key, a preliminary access information packet is included in the transmission, enabling the external party to decrypt the stream, and the stream of subsequent packets, each subsequent packet containing information identifying the next packet as associated with the stream and at least one subsequent packages are deprived of access information.

It is beneficial that a key associated with the source of the software is placed in a reliable device, the software is transmitted to a reliable device, while the transmission is modified by the software source in a manner confirmed using the key and the software is introduced into a reliable device conditioned by confirmation of transmission using placed key.

It is beneficial that when each user is equipped with a computer device having at least one key associated with the device, the computer devices are registered in at least one center, selected from many centers, the computer devices are confirmed, and a certificate for the device is created by confirmation , secure transmission is initiated from the initiating user to the recipient using the message key, for the transmission the access part encrypted with the center key is activated to obtain the message key.

It is beneficial that it is transmitted electronically via a reliable device to a third party, requesting authorization to carry out an electronic operation, with the request including the identification of a reliable device, it is determined by a third party that the reliable device should be authorized to carry out the operation, at least in part according to stating that a reliable device will work according to the rules, transmitted electronically, by a third party to a credible device, authorization to carry out an electronic operation, the authorization being accompanied by confirmation that the third party has given this authorization, electronically transmitted by a credible device to the other party, confirmation as ensuring that the credible device is authorized to carry out electronic operation and will conduct it only in accordance with the rules and the operation data is electronically transmitted, through a reliable device to the other party, according to the rules.

The advantage of the invention is the introduction of a commercial key deposit system that uses published algorithms, works in a way that inspires the trust and confidentiality of users, and solves the problems posed by national security and law enforcement. The invention provides the desirable introduction of a commercial key deposit system that uses private keys that can be changed by the user at any time or at regular intervals. The advantage is the introduction of a commercial key deposit system that allows the user to choose key agent agents to protect his private key or separate fragments of his private key. The invention enables the introduction of a commercial key deposit system that includes safeguards against unrestricted government access, as well as access for users' employers or countries whose citizens are foreign users.

The advantage of the invention is therefore the introduction of a commercial key deposit system that offers an alternative to the Clipper cube system proposed by the US government.

The subject of the invention is illustrated in the embodiments in the drawing, in which Figures 1A-1G are lists of symbols and abbreviations used in the figures, Fig. 2 - a flowchart showing the steps for obtaining keys in the known Diffie-Hellman interactive method, Fig. 3 - a flowchart showing the steps of the certificate portion in a known manner of confirmed Diffie-Hellman, fig. 4 - a flowchart showing the steps of the part regarding broadcasting messages in the known Diffie-Hellman method, Fig. 5 - a flowchart showing the encryption steps in the known RSA key transfer method, Fig. 6 - a flowchart showing the decryption steps in the known RSA key transfer method, fig 7 - flowchart showing the steps for creating a signature in the known RSA key transfer method, fig. 8 - network

176 458 actions showing signature verification steps in the known RSA method, Fig. 9-11 - action networks showing together the steps of a known Micali key deposit process, Fig. 12 - an example of the format of a known public encryption key certificate, Fig. 13 - an example of a presumed Law Enforcement Access format LEAF of the Clipper device, Fig. 14 - an example of the format of the device certificate issued by the device manufacturer according to the invention, Fig. 15 - flowchart showing the stages of verifiable key deposit with only one deposit agent, Fig. 16 - flowchart showing stages of the method of verifiable key deposit based on a single reliable device, Fig. 17 - flowchart showing stages of how to send an encrypted message with the MCH Message Control Header, Fig. 18 example of MCH in RSA format for key transfer, fig. 19 - a flowchart showing the steps for receiving an encrypted message from MCH, Fig. 20 - an example of the MCH decoder box and a flowchart of the process, Fig. 21 - an example of a self-checking, reliable date stamp, Fig. 22 - an example of the format of the device owner certificate issued by the device manufacturer according to 23, a flowchart showing the steps for how to deposit the key when the key is replaced by the owner of the device according to the invention and FIG. 24 a flowchart showing the steps of registering reliable devices according to the invention by a reliable third party.

Figures 1A-IG show lists of symbols and abbreviations used in the figures.

Figure 2 shows an interactive Diffie-Hellman diagram in which each of the two users A, B randomly selects the secret number 21, 22, and then calculates the intermediate number 23.24 using two publicly known numbers and the secret number 23.24 selected by the user. Each user then sends the intermediate number 23, 24 to the other user, and then calculates the secret symmetric combination key 25 using its own secret number 21.22 and the intermediate number just received from the other user. The interactively created code key 25, such as a DES key or other symmetrical code key, is then used symmetrically by both users to encrypt and decrypt this communication session, sent over an unsecured channel, in the same way as for communication with a symmetric key. This interactive procedure requires only a few seconds of real time and all digital messages, including sound and image transmissions, can be encrypted simply by pressing the button at the beginning of the session to initiate the interactive key exchange process. Because all the numbers selected in the Diffie-Hellman interaction scheme are very large, the calculation cannot be inverted and the code key cannot be calculated by the eavesdropper, which protects the secrecy of communication. Because the calculation cannot be reversed, every user knows that the message received using this algorithm has not been changed and could only be sent by a second user, so the completeness and authenticity of the communication is protected. This interactive key exchange method, however, requires real-time collaborating parties to create the encryption key and cannot be useful for spontaneous communication or between non-knowing parties. In particular, the Diffie-Hellman interactive key exchange scheme cannot be used in a memory-sending email system or for long document storage in electronic data storage systems, because the recipient is not directly available to negotiate the session key.

The modernized, non-interactive form of the Diffie-Hellman scheme, known as the confirmed Diffie-Hellman, can be used when the transmission participants are not connected directly. The initial stage of confirmation during a key generation session in a Diffie-Hellman confirmed system occurs when one user, which can be the recipient, randomly selects the secret number 31, his private key, and then calculates the intermediate number 33, using two publicly known numbers 321 chosen by himself secret number 31. The user then sends the confirmation of identification together with the intermediate number and two public numbers, which together form their public key 34. The confirming authorities then issue the public key certificate 35, digitally signed 36 by the issuing authority of the binding confirmation of the public user's key identity

176 458

Diffie-Hellman 34 The public key 34 provided by the user is valid until he decides to change the key and select another private key 31. When sending messages using the Diffie-Hellman confirmed method, for sending messages to the receiving user, the first user receives receiving user certificate 35 and checks the signature of the 36 certifying authority. The sender then calculates session key 42 for this communication session, using the recipient's intermediate number 33 from the recipient's certificate and sender's own secret number 41, his private key, which is randomly selected. The sender then encrypts the message 43, using session key 42, and places at the beginning of the message an unencrypted own intermediate number 40. By receiving the message, the recipient calculates the session key using the unencrypted sender's intermediate number 40 and its own secret number 31 or private key, and then obtains the session key 42 to decrypt the information 43. As in the Diffie-Hellman interaction schema, the session key created in the confirmed Diffie-Hellman schema is then used by both parties to encrypt and decrypt the message during that session through an unprotected channel using a conventional symmetric algorithm, such as a DES key. However, the confirmed Diffie-Hellman scheme requires that a credible certifying entity or institution signs a public key certificate so that the sender can trust that the information it contains is true. In addition, the private key chosen at random by the sender by which it calculates the session key and the number of intermediate for this transmission cannot be identical to the private key attached to the public key certificate owned by the sender to avoid its other constant private key numbers corresponding to public key figures that have been confirmed. The sender should keep them different from ephemeral, private keys or intermediate numbers that are generated only for specific messages.

Another asymmetric key algorithm is the algorithm named RSA after the inventors of Rivest, Shamir and Adleman. It creates a difficulty in decomposing the number, which is the product of two large prime numbers. Like the Diffie-Hellman interaction schema, the RSA algorithm is relatively easy to calculate, but practically impossible to reverse. Therefore, it is not possible to derive the private key from the public key and thus you can keep the secret of communication. When the message is encoded with a public key using the RSA algorithm, it can only be decrypted using the private key and vice versa. Like the confirmed Diffie-Hellman scheme, the RSA algorithm requires a reliable unit to confirm and make public user keys public. Unlike both Diffie-Hellman schemes, the RSA algorithm alone does not generate a session key for symmetrical use by parties. On the contrary, the user's public encryption key directly encrypts messages for that user, and the user's private decryption key decrypts messages encrypted by that user's public key. So the RSA algorithm is a pure asymmetric key algorithm.

However, because the RSA algorithm is complex and introduces the power of a message by large numbers, encryption and decryption of the message, even of moderate length, using the RSA algorithm, requires a long time. It is therefore much simpler, faster and more efficient to use the asymmetric RSA algorithm to send the DES encryption key for use in the symmetrical algorithm. This known mode of operation is known as RSA key transmission and is shown in Figures 51.6. For example, according to Fig. 5, the user can randomly generate a DES 51 key and encrypt the message 52 with this key. Then the user can encrypt the DES 51 key using the public encryption key 53 of the user for whom the message is intended, and send the message 54 encrypted with the DES key , together with the DES 55 encrypted RSA key, to the receiving user. After receiving the transmission, as shown in Fig. 6, the recipient decrypts the DES 51 key using their private RSA 56 decryption key and uses this DES 51 key to decrypt the 52 message. Because the DES algorithm requires much less time and calculation effort than

176 458 RSA algorithm, the symmetric DES key is used to encrypt and decrypt the actual message, while the asymmetric RSA keys are used to encrypt and decrypt the symmetrical DES key.

The encryption system with the RSA public / private key also provides a digital signature that is dependent on the message and on the signatory and can be used to confirm that the received message was actually sent by the sender and was received unchanged. The RSA digital signature is based on the additional property of RSA, which, in addition to enabling the private key to decrypt only messages that were encrypted with its public key, also allows the private key to be encrypted with messages that can only be decrypted with its public key. Since only the user has his private key, the use of the private encryption key allows proving the origin, which can be confirmed by anyone who has access to the user's public key. In practice, the sender first uses the private key to encode the text into a signed message that can be decrypted by anyone but can only come from a specific sender. If desired, the sender can then optionally use the recipient's public encryption key to encrypt the signed message to be sent. After receiving the encrypted text, the recipient decrypts it using the private decryption key when necessary and decodes the signed message using the sender's public encryption key. Because only the sender knows the unique private key, only the sender can send the specified signed message. Thus, the signature confirms the sender's identity. Also, because the recipient only knows the sender's public key, the sender cannot claim that the sender or unauthorized third party changed or produced his message. The signature prevents the sender from denying the message. In addition, because only the sender's private key transforms the original message and only the sender knows the unique private key, neither the recipient nor an unauthorized third party cannot change the message. The signature therefore confirms the integrity of the message.

The RSA algorithm also provides a different type of digital signature that uses a hash function to create a short message hash, unique to each document. Figures 7 and 8 show RSA signature creation and signature verification using a hash function. The hash function is another complex, one-way mathematical algorithm, which means that you can't reproduce the document with the hash result. It is also collision-free, that is, it is impossible to create another document that will give the same abbreviation as a result of mixing. As shown in Figure 7, the sender first processes message 72 using a hash algorithm 73 to create a message hash 74, and then encrypts the hash with a private RSA key 75, creating a compact digital signature 76 that is attached to message 72. When the message transmission is received 721 of hash of message 76 as shown in Fig. 8, the recipient decrypts the encrypted RSA key of the sender's message abbreviation 76, digital signature, using the sender's RSA 77 public key. The recipient also uses the same hash algorithm 73 to create a message hash 74 from the received message. The two message abbreviations from the two transformations made by the recipient should be identical, thus confirming that the message was signed by the sender.

In Figures 9-11, a user who wants to confirm his public encryption key must deposit the private key as follows. The user first splits private key 91 into several fragments 92, each of which can be individually verified to be an important fragment of the complete private key 91. Private key 91 can be reconstructed only if all fragments or certain specific numbers thereof are known. The user then sends 93 each fragment to another trustee or deposit agency 94, which, as shown in Figure 10, verifies the fragment 95 as the actual fragment of the private key 91 using a special algorithm and informs the main deposit center about this verification. According to Fig. 11, after obtaining verification 96, 97 stating that each fragment of the private key is correct, the main depository center may then issue a certificate14

176 458 cat 98 public user key 99 enabling its use in a security system, ensuring that if necessary and in accordance with the authorization or court order, the law enforcement agent will be able to obtain secret fragments of the private key from the trustee selected by the user, submit them and monitor user connectivity. In this system, users can be confident that their encrypted broadcasts are kept secret, and the government can be sure that they can access encrypted broadcasts when the need arises. Because one entity normally never has access to the entire private key, and because the user chooses an entity that they trust, the chance of unlawful or corrupt activity is greatly reduced. Also, because a wide range of individuals wants to be re-elected as trustees, the chances of colluding all trustees at the same time and thereby destroying the entire deposit system are even more limited.

The key deposit process will now be described.

After making the microchip according to the invention, and before using the microchip to encrypt or decrypt the transmission, the public user key must be registered by the main depository center or by the deposit agents approved by the microchip manufacturer. This operation can be carried out by the user himself or the manufacturer can initiate it and register the microcircuit with one of the depository agents during manufacture, thus freeing the user from the obligation to deposit his key personally. However, the manufacturer should still leave the user the option of changing the key himself at a later date. For many individual users, allowing the manufacturer to register the chip with or without the key exchange option will be sufficient. In addition, users will most likely trust the deposit agent chosen by the manufacturer. Enterprises and other employers may program their own microcircuits and microcircuits of their employees and register the microcircuits with depository agents according to their own choice. However, companies will generally not allow their employees to change the key on their own, as this could lead to loss of information and assets, as discussed above.

To create and register the code key, the user (or other entity performing the operation) recalls the firmware that has been embedded in the microchip and instructs the microchip on how to perform the individual steps of how to deposit Micali keys or the specific method of depositing keys that is used. See figures 9-11, 116. Using any of the methods of depositing a private key with one or more deposit agents, the chip will first randomly generate or choose a secret number that will be the private decryption key for that user (as well as other public numbers that will be required if these numbers have not yet been set in other earlier generations of random numbers). The chip will remember the private key in an unreadable and resistant to forgery. As shown in Fig. 15, a private encryption key can be deposited with a single agent. The reliable device 150 first generates a public / private pair of 151 encryption keys for the user, and then sends to the escrow center 153 an encrypted and signed message 152 containing the pair of encryption keys 1511 serial device number 154 with the manufacturer's certificate 155 for signature verification. The escrow center 153 verifies signatures, decrypts the message packet, and remembers the user's private decryption key. The escrow center also sends to the user a signed certificate 156, containing the serial number of the user's device 154 and the public encryption key of the user 1511, the public signature verification key of the device 157 with the certificate of the deposit center 158 for signature verification. When the user's device verifies the signature of the deposit center, registration is made.

If the private key is to be deposited with more than one deposit agent, the chip must then split the private key into a number of fragments, i.e. split the key according to a specific formula, using the method of depositing Micali and the algorithm described earlier and shown in Fig. 9, the chip will calculate then some values ​​of 90

176 458 using the special Micali algorithm, so that each value is based on the mathematical transformation of one of the fragments of private key 92 The chip then creates one separate packet 93 for each trustee or deposit agent 94 designed by the user, each separated packet 93 contains the unique serial number of the user's device, one fragment of a private key and a set of certain values, which allow a particular trustee to verify the received private key fragment as a valid fragment of the entire private key without giving the trustee information about the entire private key. As will be discussed later, if the user is not the owner of the device but rather, for example, an employee of the owner-employer, the separated trustee package should also contain a unique identification number of the owner and the certificate of the owner of the device, so that the employer-owner can obtain the private key of the user-employee without first obtaining authorization. The chip then signs each dedicated trustee packet using the device's unique private signature key and appends the manufacturer's certificate for the transmitting chip to confirm that the information being sent is from a known and reliable type of device. Finally, the chip will issue a signed dedicated trustee package for delivery by the user to a reliable escrow agent.

There is also another way for the main depository to verify separate key fragments without using the Micali method, involving only a reliable device. Using this method of verification of key fragments shown in Fig. 16, the chip generates one random number for each private decryption key fragment. The chip then creates one trustee packet 161 for each trustee or escrow agent 163 designed by the user, each packet contains a unique number of the user's device, one private key fragment, and one random number. The chip signs each trustee packet using the device's unique private signature key and attaches the manufacturer's certificate 162 to the transmitting chip to confirm that the information being sent is from a known and reliable type of device. As in the Micali method, the microchip will issue a signed dedicated trustee packet 161 for delivery by the user to a reliable escrow agent 163. In addition, the chip must also create a (encrypted) message 164 for the master escrow center 165, including, inter alia, the user's public decryption key and the names of the deposit agents designated by the user, and together with the random number given by the key fragment to be sent to each separate deposit agent.

It is possible, however, because each trustee packet contains a private key fragment that a third party having access to transmission from the user to the escrow agent could read the contents of all trustee packages sent by the user and play the private key fragments contained in these packages to restore the entire private key . Then, using the private key, this third party could decrypt and encrypt the transmissions on behalf of the user. The best way to avoid this situation is to use an encrypted communication system when you send trustee packages from you to escrow agents. The user should obtain a public encryption key certificate 166 from each escrow agent selected for depositing the user's private key, where each certificate is signed by the master escrow center confirming that the specified escrow agent is a trusted root escrow center for receiving and depositing the key fragment packet. Subsequently, the signature of the main depository center would be verified either using confirmation from the device manufacturer (or from a system-wide institution) or using a pre-placed instruction key. The device would then encrypt for each escrow agent, based on the confirmed public encryption key of that agent, a transmission 161 that includes the trustee's private key packet. Alternatively, the manufacturer could embed in the chip public encryption keys of several reliable deposit agents matched to the instruction keys for each, as discussed earlier, so that the user sends

176 458 a fragment of your private key to the escrow agent reliable for the owner of the instruction keys, which is typically the main escrow center. In this way, all escrow agents in the main escrow center or in the 'family' of manufacturers will be able to decrypt the user's acceptance of the deposit, saving the user the trouble of obtaining public encryption key certificates from all deposit agents.

When each escrow agent or trustee 163 receives the appropriate trustee packet 161 from a user or user device, the trustee checks the private key fragment received in the trustee packet 161 from the user's device and, together with the master escrow center 165, verifies that it is a valid and valid fragment of the complete key private. It is necessary for the escrow agents and the main depository center to have reliable means of proving or verifying that the fragments of the user's private encryption key have actually been deposited. It is desirable that the verification of key fragments is carried out by the escrow agents and the main deposit center without examining or having these fragments themselves or combining them in one place. Micali's "fair" trust system gives the escrow center one highly reliable way to verify the separate deposits of key fragments. In the Micali method shown in Figures 10 and 11, this verification is done using a set of certain values ​​that were calculated by the user chip when creating the trustee package, using a special Micali algorithm that was attached along with a key fragment to each trustee package sent to escrow agent. The Micali algorithm and key fragment verification are known and need not be repeated here. Each trustee 94 then stores the device manufacturer's certificate for later use for decoding and confirms the key fragment 93 by sending the corresponding signed message 96 to the main depository center, along with the user name and device certificate and by signing and storing the key fragment 90. Only if he is presented with (a) an authorization or 'court order, or (b) a signed request from the legal owner of the device, the trustee will disclose the fragment (s) of the private key in his possession.

Using the preferred deposit and verification method based solely on the reliable device shown in Fig. 16, each trustee 163 sends a message 167 to the main depository 165, identifying the username, public encryption key, device number and random number as received. In addition, the user equipment sends a packet to the main escrow center 165 containing random numbers used to verify the private key fragments, and the packet should be encrypted using the main encryption key of the public escrow. The main escrow center 165 receives messages 164, 167 from the user equipment and from the trustees 163, and checks that each individual random number received from each trustee agrees with a random number as per the user device was given to that trustee. It should be noted that according to this method, the escrow agent 1631, the main escrow center 165 relies only on the signing of a reliable device in the trustee packet 161 to ensure that the deposit is correct. This method of depositing and verification does not require secondary mathematical operations to verify that the deposit is correct or that the public key submitted for confirmation matches the key fragments submitted. Although from the point of view of a public user or system-wide trust, it could still be desirable to use a verifiable deposit algorithm such as the Micah procedure, this is obviously not necessary and may be waived if the additional cost of using such a procedure cannot be justified. In addition, in this system, which relies only on a reliable device, there is no limit to the complexity of the key distribution scheme that can be invented, since it is not necessary to invent complex secondary algorithms to verify the correct execution of any given scheme. You only need to trust the device manufacturer who entered the firmware code and trust that the device will be resistant to spoofing

176 458

After verifying all fragments of the user's private key, the master escrow center will then itself confirm the public encryption key that corresponds to the private key that has been confirmed by all the trustees of the user, the master escrow center 165 confirms the public key by issuing a signed certificate (called the master escrow center certificate, public key certificate encryption or simply a deposit certificate) confirming that the private key corresponding to the public key that is confirmed has already been deposited in the right way. The user's public device signature key obtained from the device manufacturer's certificate can also be placed in the master escrow center certificate, which eliminates the need to send or re-verify the device manufacturer's certificate at later stages of the process. The master escrow center certificate can be formatted as follows:

Version number

Certificate Certificate Serial Number

National code for the main depository

Name of the main deposit center

Main encryption public encryption key (for use in creating LEAF)

Distinguished username

User's public key (hereby confirmed)

Public device signature verification key (for device signature verification)

Expiration dates (start / end)

Main deposit center signature [Main deposit center system certificate]

Public encryption key certificates that have been issued by the main escrow center are widespread and can be used either by the owner of the device to activate his device to produce encrypted messages or by others to encrypt messages to the owner of the device containing the user's public / private pair of encryption keys

It should be noted that the present invention does not require that more than one depository agent is the recipient of fragments of a user's private encryption key, in some cases only the submission of a user's private encryption key with one depositary agent or at (deposit center) would suffice. However, to increase user trust and public trust in the system, it is desirable to split the user's private encryption key among several depository agents so that all key fragments or a certain number thereof are required to assemble the user key and decrypt its transmissions. It is also desirable for each escrow agent to be an independent trustee in the interests, to use "knowledge of unbundling", so that in the event of attempted corruption, bribery, extortion or abuse, it would be much more difficult to illegally obtain a user's private encryption key than if that key were only stored in one unit. It is also desirable for entities to be separated geographically to further limit the possibilities of seizure or corruption.

Message encryption

A user who wants to send an encrypted message to another user must have a deposit certificate for his own device and a deposit certificate for the public encryption key of the intended recipient, because the device according to the invention will neither encrypt nor decrypt if any of these documents are missing. First, the sender must load his own valid certificate into the device, typically as soon as he receives it from the main escrow center. Then, the public key certificate can be obtained either directly from the intended recipient, from the information service printing public key certificates or from the sender's local file, e.g. users' files with which the sender previously exchanged encrypted messages. In one embodiment of the present invention, because the sender's device will not encrypt and the recipient's device

176 458 will not decrypt if the recipient's public encryption key certificate is not "valid" so that the recipient's device decrypts the encrypted message the recipient's public encryption key certificate must be signed either by (a) the recipient's device manufacturer (this probably cannot happen because device manufacturers they most likely will not accept users' private keys for deposit); (b) the main depository center, including the manufacturer's certificate confirming that the main depository center is an important trustee; or (c) a trustee or main depository center whose instruction keys were built into the device during production. Using the user's confirmed public encryption key as given in the recipient's public key certificate, the sender then generates a session key for use by the sender and recipient to encrypt and decrypt the message, this session key can be advantageously generated using the confirmed Diffie-Hellman method or alternatively another appropriate system. In the confirmed Diffie-Hellman method, the user first generates his ephemeral private key for this message, and then calculates the session key based on his own private key and the public key of the recipient (i.e. the intermediate number of the recipient and two public numbers, which are all contained in the public certificate recipient encryption key). Then, using the session key, the sender encrypts the message to be sent to the recipient /.

However, when deciding to send or unencrypted message to the intended recipient, the sender may not be able to verify the properties of the recipient's public encryption key certificate or digital signature if the sender's device was made by a manufacturer other than the manufacturer of the recipient's device. The fact that the recipient's device was made by another manufacturer may prevent the sender's device from easily verifying either the manufacturer's signature or the manufacturer's certificate (which confirms the main depository center that has signed the recipient's key depository certificate) stating that the recipient's main depository center is valid and approved by the manufacturer Similarly, the recipient's chip would be unable to verify these conditions with respect to the sender's certificate before decryption. Enforcement of the deposit requirements from both parties is needed to allow law enforcement agents to legally access and decrypt messages sent and received by a given suspicious user, without having to obtain the private decryption key of the other unmonitored site, which would give them access to unrelated non-monitored site messages /.

One way to find a solution to this problem when more than one manufacturer produces encryption devices is to put in the device or in the certificate issued by the user's main deposit center or the chip manufacturer, the public key of a reliable entity, e.g. the Federal Reserve Bank. ("FRB"), which could be used to verify one more certificate issued by the FRB to any of the other different major depository centers or producers. Such a certificate could be verified by the individual main deposit center or producer and would be signed by the FRB. The sender could then obtain the intended recipient's key certificate and could believe the main depository that issued the certificate because the main depository center was accredited by the FRB rather than by the chip manufacturer as a public key or certificate confirmed by the FRB. Also, the signature of a particular device may be credible, because the other manufacturer that confirmed the device was accredited by the FRB, as confirmed in the FRB certificate or public key. To implement this solution at a less provincial level of the United States and promote a more international system with a global reach, the public key of a reliable global institution, such as the Swiss Bank for International Settlements could be included in either a reliable device, an FRB certificate or a certificate of the main depository or manufacturer (depending on the confidential model adopted) and could work in the same way, which was discussed in relation to the FRB key to accredit major depository centers and producers on a global basis.

176 458

Another way, although not introducing US or global institutions to one device to authenticate deposit centers confirmed by another manufacturer, is for device manufacturers or major deposit centers to perform mutual confirmations. This could help the sender's device enforce the recipient's deposit restrictions by allowing the sender's device to verify the confirmation path of the recipient's deposit certificate, returning through the recipient's device manufacturer or main deposit center to his own. In a preferred embodiment of the invention, the public key of a reliable system-wide entity would be placed in a reliable device and would operate in the same way as discussed above for the FRB key or global-scope entity to accredit all major depository centers and producers on a system basis.

Whenever a user, entity or device "verifies" a digitally signed "certificate" or manufacturer's certificate, or a certificate of deposit issued by a confirming institution or manufacturer, it is normal practice in most real and proposed public key certificate management systems (and is adopted in the invention), that the user, entity or device also checks the available "certificate revocation list" ("CRL") to determine whether the confirming institution or other issuer, disseminated, propagated or otherwise made available a list of revoked certificates, which is updated in accordance with the relevant security policy and based on the name and number of the certificate, whether the certificate has been revoked. The certificate issued to the user may be revoked due to death, name change or employment or loss, theft or destruction of a device (smart card) containing a private key. The certificate issued to the institution may be revoked due to business interruption, name change, loss, theft or destruction of a device containing a private key. The certificate issued for the device may be revoked due to loss, theft, withdrawal from work or destruction of the device. CRL checking during certificate verification is well described in known literature (e.g. ANSI Χ9.30 - part 3) and requires no further discussion. All users, units and devices will have normal access to the relevant telecommunications equipment and may recover CRL or obtain the requested information. Similarly, according to the invention, all CRL issuing entities are assumed to make them available to all interested parties.

Message Control Header Format

When sending an encrypted message, the sender must also create the appropriate Message Control Header (MCH) field containing the following information:

(1) The intermediate number of the sender for an encrypted message calculated by the sender using his randomly created private ephemeral key, which was also used by the sender to calculate the session key by which the message was encrypted. The recipient must have this intermediate number to calculate the session key to decrypt the message.

(2) The name and country code of the sender's main escrow center.

(3) The name and country code of the recipient's main escrow center derived from the recipient's public key certificate.

(4) The sender's escrow certificate number, encrypted using the sender's primary encryption key (obtained from the sender's escrow certificate), so that only the sender's main escrow center can decrypt it.

(5) The sender's intermediate number (different from the previous intermediate number) that was used by the sender to calculate the ephemeral session key by which the sender confirms the encrypted number to the sender's main deposit center. The sender's main escrow center must have this number to calculate the ephemeral key to decrypt the sender's certificate number.

(6) Session key for encrypting the message, encrypted using the sender's own public key (an intermediate number from the sender's own public certificate), so that the sender actually sends the message session key to himself. Egzek Agenda 20

176 The law may access this message session key when it obtains portions of the sender's private key from the sender's escrow agents.

(7) The sender's intermediate number (different from the sender's previous two intermediate numbers) that was used by the sender to calculate the ephemeral session key by which the message session key was encrypted to itself The law enforcement agency must have that number to calculate using also the sender's private key (its secret number) obtained from the sender's main escrow center, an ephemeral key for decrypting the session's key message.

(8) The recipient's certificate number, encrypted using the public encryption key of the recipient's main depository (obtained from the recipient's depository certificate) so that only the recipient's main depository can decrypt it.

(9) The sender's intermediate number (different from the sender's previous three intermediate numbers) that was used by the sender to calculate the ephemeral session key by which the recipient's deposit certificate number was encrypted for the recipient's main depository. The recipient's master escrow center must have this number to calculate the ephemeral session key to decrypt the recipient's certificate number.

(10) Timestamp (optional), for tracking purposes and possible assistance in enforcing the authorization date and time limits.

(11) Signature of the sender's device.

(12) The sender's public key deposit certificate issued by the sender's main escrow center. The sender's certificate of deposit contains the sender's public key, which the main depository center previously verified and then copied from the sender's device manufacturer's certificate.

(13) The main depository center certificate from the FRB, the producer or any system-wide institution is credible if the recipient's chip is made by another manufacturer attached to the sender's certificate of deposit. A manufacturer, FRB or system-wide organization certificate is only needed for the first transmission between two parties. The certificate may also be mutually confirmed by the recipient manufacturer and the main deposit center.

The MCH described in this way can be summarized as follows:

Indirect Sender Number (to enable the recipient to decrypt the message)

Sender's Main Deposit Center Country Code

Name of the Sender's Main Deposit Center

Recipient's Main Deposit Center Country Code

Name of the Recipient's Main Deposit Center

The Sender's Deposit Certificate Number, encrypted for the Sender's Main Deposit Center

Sender's Intermediate Number (for encrypting the sender's certificate number)

Message Session Key, encrypted for the sender

Sender's Intermediate Number (for encrypting the sender's message key)

Recipient's Deposit Certificate Number, encrypted for the Recipient's Main Deposit Center

Recipient Intermediate Number (for encrypting the recipient's certificate number)

Time stamp

Signature of MCH Sender's Equipment [Sender's Deposit Certificate] [Deposit Center Certificate]

Figure 17 shows the process of sending an encrypted message 176 from MCH. The entire MCH 172 (attached certificates 173, 174, 175 are not technically part of the MCH) is signed by the sender's device 171 using the device's private DSA key with the device's signature DSA attached to it (inside the sender's certificate of deposit) to confirm the public key device signature.

176 458

This ensures that all MCH is delivered intact to the recipient and that the recipient's chip can easily verify that the MCH has not been modified. The manufacturer's certificate may be accompanied by a certificate (FRB) or a global institution to confirm that the sender's microcircuit manufacturer is reliable, if the recipient's device was manufactured by another manufacturer.

In another embodiment of the invention, a second, shorter MCH format may be used in cases where absolute confidentiality is not critical. In this MCH, neither the Sender's Certificate Number nor the Recipient's Certificate Number are encrypted for a particular main deposit center. Not encrypting certificate numbers saves a lot of time and space in creating MCH. In yet another embodiment of the invention, the third also shorter MCH format can be used in such a typical case when both the sender and the recipient use the same main depository center to deposit the keys, making EC1 identical to EC2. By eliminating the need to include in the MCH information identifying the second main depository center and the special intermediate number used to encrypt the recipient's certificate number for the second main depository center, the MCH may be much shorter. In addition, MCH size can be further reduced by using RSA key forwarding to encrypt the DES key for the message and for each of the three encrypted internal LEAF components. According to this method, each intermediate number of the sender should be replaced by a smaller DES key associated with RSA. Thus, the sender can encrypt the message session RSA key for the recipient and eliminate the need for the first intermediate number in the MCH. The sender can also encrypt the message session RSA key for himself (actually for later decryption by the law enforcement agency) and thereby eliminate the need for a third intermediate number in the MCH. The sender can also encrypt RSA numbers of his and the recipient's certificates, thus eliminating the need for a second and fourth intermediate number in MCH. As shown in Fig. 18, the elimination of four intermediate numbers and the associated encryption and the replacement of each intermediate number with the smaller RSA 181 transport cipher significantly reduces the MCH size.

Share of random material

You may be concerned that the exchange of the message session key using only the RSA transport method or the confirmed Diffie-Hellman scheme is not secure enough, because both methods, although both the sender and the recipient provide information, only the sender creates the message session key. However, according to military standards for secure communication, both the sender and the recipient must bring random material into the creation of a session key before each communication session apparently to reduce the sender's ability to use a weak key or reuse the same key and thus expose the recipient against his will at risk loss of security. The system of reliable devices envisaged by the invention can reduce these fears in two different ways. First, it can ensure that the transmitting device will produce each key separately using random numbers derived from noise generated by the built-in hardware noise source, such as a back-polarized diode, as discussed earlier. Then, as long as the device signs the MCH or Message Control Header, the recipient can be sure that each message session key and random numbers used to produce it are strong and unique. However, those who insist on greater security may require the sharing of random material from both sides of the communication, as specified for Type 1 military information classification systems.

So far, this invention describes how the sender creates a message session key based on the recipient's public encryption keys as contained in his certificate of deposit, and not on random material received from the recipient during the initial communication phase. Such an organization, in which the sender would receive participation from the recipient, however, creates a new problem. You cannot simply allow the recipient to create the Diffie-Hellman intermediate number yourself and send the sender to use the message in the created session key, because the recipient could no longer use the deposited private key in

176 458 their reliable message decryption device and because their messages could never be monitored by law enforcement agencies. The success of the system implementing the deposit scheme requires that neither the sender nor the recipient be able to read the message without using a registered, reliable device.

To enable the sender and recipient to co-create random material for the pre-transmission session key, the initial key exchange protocol can be modified to allow the intended recipient's device to generate a new ephemeral, secret Diffie-Hellman secret number independently and in addition to the recipient's private key being deposited is used to calculate the new intermediate number, which in turn will be sent to the sender to calculate the session message key to encrypt the message. The recipient's private key would still be used to create intermediate numbers (included in MCH) and ephemeral session keys that are used to encrypt different parts of MCH. This modification, however, requires that the creation of a new secret number occur inside the intended recipient's device, that this new secret number remains within the credible device and that the new intermediate number is signed by the intended recipient's device before sending to the sender's device to confirm that the new ephemeral secret number is actually locked securely in the recipient's device. As before, the sender's device produces a new number independently and in addition to the sender's private key being deposited, and using this new secret number and the new intermediate number of the recipient creates a message session key to decrypt the message. The sender's device will also use the sender's new secret number to create a new sender's intermediate number that will be sent to the recipient's device as an MCH fragment, for eavesdropping purposes. In this method, the message session key would therefore contain, as desired, random material contributed by both the sender and by the recipient.

However, in this modified key exchange protocol, because the sender and recipient actually use the new Diffie-Hellman private keys for each message, the deposit properties disappear because the law enforcement agencies and the management of the company could never obtain these ephemeral session keys from deposit agents. Therefore, the needs of the depository system and the community of interests require that the message session key be sent as before in the MCH. Indeed, to ensure even eavesdropping, all fields that were previously disclosed as part of the MCH remain so. The field transferring the message session key to the sender (which is the only way to read the message to law enforcement agents eavesdropping on the sender) must also be included in the MCH to maintain the principle of equal listening. The message session key will be encrypted in MCH, as before, using the sender's public encryption key, to which the law enforcement agency will, however, have access. A new intermediate sender's number will be sent to the recipient as the first MCH fragment, as before, to allow law enforcement agencies to eavesdrop on the recipient and calculate the message session key. So, to exchange a Diffie-Hellman interactive technique key, this protocol requires that the recipient's new intermediate intermediate number be created inside and signed by his device, and requires that the new intermediate sender's number be added to the MCH rather than used instead of pre-established methods sending the key because it is the only way for members of the community of interests (law enforcement officers, employers and others) to be able to read the message. This method, however, would not be economical for other operations, such as direct telephone, network, or switched operations, because the device would have to remember too much, namely special intermediate numbers for each partner. This method can be advantageously used in mobile telephony, network registration etc. where real-time interactive sessions are desired.

176 458

Community of interest headers

MCH will generally be placed before the encrypted message as its header. In many existing electronic mail and documentation systems, a number of recipients have the ability to read one encoded message, using RSA transport in MCH design as discussed above, when encrypting the RSA session key using the public encryption key of each recipient. This is the case when several recipients are to receive the same encrypted message. The MCH header may contain for each intended recipient, its name followed by the message session key, RSA encrypted for each intended recipient, using the public encryption key of that recipient. Thus, any intended recipient can locate its entry in the MCH header, decrypt its copy of the message session key and read the message. Also with a number of intended recipients, the correctness of MCH is forced from two sides of communication: on the sender's side, the MCH output is imposed by the internal logic of the sender's device, this is a requirement that it create a valid MCH before encrypting the message: on the recipient's side, the MCH correctness is imposed by verification by the recipient's device of the digital signature of the sender's device. As previously stated, because copies of the recipient's message key are an integral part of the MCH, no recipient can read the message unless the MCH is sent and received intact, unlike in the Clipper system where the MCH itself is not associated with the key transfer mechanism.

With this concept of MCH formatting, MCH was not summarized as shown in Fig. 25. As in previous MCH formats, the authenticity of MCH is guaranteed by the digital signature of the sender's device 258. In addition, as before, the sender's and recipient's certificate of deposit numbers are encrypted with their individual public keys main deposit centers 251, 252. In this format, however, the MCH signed by the sender's device becomes a modified "recipient list" that is more flexible and easier to understand compared to the way modern encrypted email systems work. For example, the sender and recipient names (or system ID or addresses) are shown unencrypted in MCH 253, 254. Although this interferes with the anonymity of the sender and recipient, it is practically difficult to send a message in the e-mail system without marking the messages with the name and address of the sender and recipient, so the loss of secrecy is small. In addition, the employers' names of the sender and recipient 255,256 (or their unique IDs, such as tax numbers or DUNS numbers) are also shown unencrypted, hence the significant reduction in effort is used by the employer's security to find messages sent and received by their individual employees. Alternatively, instead of leaving the unencrypted blocks of sender, recipient and employer names, these entries could be read as well "sender" "recipient" "sender's employer" and "recipient's employer" (or their equivalents) unencrypted with real identifiers inside the encrypted areas as before. Thus, the intended recipient of the message would look for his unencrypted identification hash in the MCH and thus be able to decrypt and read only the portion of the MCH intended and encrypted for him.

In addition, this MCH format, as shown in Fig. 25, allows access to sub-units in an enterprise organization by specifying secondary enterprise lines (a, b, etc.). For employers who are aware of the secrecy, MCH could read the "sender b subunit of an enterprise" unencrypted as discussed above and include the identifier of the actual organizational unit of the enterprise in the encrypted area. Because each MCH record is labeled, there are no restrictions on the number of access layers in the enterprise; they all become in some sense the legitimate "recipients" of the message. In addition, unlike existing MCH formats, this MCH format may contain a message session key encrypted directly for the employer 257, so that the employer does not have to turn to the main escrow center and agents to obtain the message session key to decrypt it. Although it may conflict with the expectations of employees up to 24

176 458 regarding workplace secrecy, this format can allow employers to check and obtain their employee records with minimal effort

To create an MCH in this format, the sender must first obtain all the necessary names / codes and public keys of the intended recipients and their employers before sending the message. This information can be collected from the recipient's deposit certificate and from your own certificate. However, to generalize this approach and make this information available to the user who wants to send a message, the master escrow center must include in each standard certificate of deposit, as discussed earlier, a unique identification or code number and public encryption key of both the enterprise and its subunits. The layout of the certificate of deposit should be designed using repetitive subgroups to effectively maintain variable numbers of pages of the "community of interests". Each entry of a community of interest page would have a unique identification number, public encryption key, and possibly an instruction code (or tactical code, as discussed below) instructing the sender's device to encode the MCH record of this page. The instruction code should contain selection elements that give the device giving the ability to include (1) a unique page identification number, either unencrypted or using a nickname, eg "empl a": (2) the message session key in the encrypted or not area; (3) the unique identification number of the page in the encrypted area or not, (4) the time stamp or random number at the beginning of the encoded area or not. These (other possible) instruction codes can be specified as bitmask markers. The list of pages (and / or their codes), their public encryption keys and instruction markers could show the sender's device how to format MCH parts in the part regarding community of interests in accordance with the wishes of each party regarding partial or total anonymity. It is anticipated that in practice many parties to the community of interests will not want to have problems with anonymity because it will be much easier for them to find and identify their employees' messages if their own name and identification numbers are disclosed.

Decryption by recipients

When the intended recipient receives an encrypted message 191 and the MCH 192 field must perform a number of steps to read the message as shown in Fig. 19. First, the recipient must load his own valid deposit certificate 193 into the chip, because in the preferred embodiment of the invention, without that chip will not decrypt. Typically, the recipient's deposit certificate will already be stored in the device's memory in a pre-verification state. The recipient then loads the MCH 192 and the sender's 194 deposit certificate, which also contains a key that verifies the public signature of the sender's device (with the appropriate 195 certificate issued, if necessary, by a system-wide or global institution) to his chip 190. The chip of the sender 190 checks sender's 194 certificate of deposit to confirm that the private decryption key has been deposited. This is done using the manufacturer's public key to confirm the manufacturer's signature in the device certificate or, if necessary, the signature of the system-wide institution in the depository certificate and by checking that the deposit center signature in the sender's deposit certificate is correct. In a preferred embodiment, the system-wide public signature key 196 of the institution is directly used to check the 195 certificate of deposit. The recipient's chip then checks the mCh signature before acting to check that (1) the sending device is reliable, (2) the sender's key is deposited and also verified by the sender, and (3) MCH 192 is correct, i.e. the MCH is in the correct format and contains all required information. This is done by verifying the sender's device signature, the sender's device manufacturer's signature and, if necessary, the system-wide institution certificate issued to the manufacturer. To facilitate this verification process, the public keys of the manufacturer and system-wide institution should be placed in the recipient's chip 190. In the simplest case, the recipient should approve the sender's certificate of deposit only once based on his own embedded public key of the manufacturer or the key of the structure of a reliable system-wide unit Once their validity for a specific sender has been confirmed, the recipient needs to use only the pre-confirmed public sender's key confirmation of the MCH signature, which results in checking only one signature for the message. If either the sender's certificate 194 or MCH is invalid, the recipient's chip will not decrypt the message. Finally, after verifying these certificates and signatures, the recipient calculates the message session key based on the sender's intermediate number, which is included in the MCH and the recipient's own private key (its secret number) corresponding to his public key, which was distributed in his public encryption key certificate 193 Using the session key, the recipient decrypts the message sent by the sender.

Decryption by law enforcement agencies To take over and decrypt messages to and from an individual user, the law enforcement agency must have the authority of a court or permission to monitor the user's communications. The court authorization will most likely contain (1) "start monitoring" date and time at which the law enforcement agency can start monitoring user connectivity, "end monitoring" date and time after which the law enforcement agency cannot monitor user connectivity, and probably (3) ) the period of amnesty after the date of "end of monitoring", during this amnesty period, the law enforcement agency can keep the user's private key only to decrypt previously retrieved messages, but not to intercept and monitor additional user messages. By monitoring the sender's messages, the law enforcement agency adopts the message and identifies using the MCH the name and country of the sender's main escrow center to determine who to request the sender's private decryption key from. The law enforcement agenda then presents the legal authority and MCH of the seized message from the sender's main escrow center, which uses its private key to decrypt the sender's certificate number that was encrypted in the MCH. Using the sender's certificate number, the sender's main escrow center looks for the sender's name and the sender's escrow agents' names and discloses them all to the law enforcement agent along with the sender's device manufacturer's certificate that the law enforcement agent will need when decoding. The law enforcement agent then contacts each of the sender's escrow agents and presents them with the sender's name and authorization and obtains the sender's key fragments entrusted to him from each deposit agent. Since the preferred way of taking over and decrypting encrypted messages by law enforcement agencies according to the invention is to use the decoder box presented below, the law enforcement agency also requires agents to attach the public encryption key of the decoder box intended for law enforcement agents, so that key fragments can be sent directly to the decoder box intended for law enforcement agents, not to the agents themselves. Each escrow agent sends the sender's key fragment in its possession to the decoder box owned by law enforcement agents, as an encrypted message having the date of "monitoring start" and date "monitoring end" and optional "amnesty period so that the decoder box can meet deadlines authorization. The decoder box then decrypts and encrypts the key fragment messages, combines the key fragments and uses the reconstructed private key to obtain a session key for communication, which session key was encrypted by the sender in the MCH as a message sent to itself. The decoder box may then monitor and intercept messages to and from the sender only during the period specified in the permit and may continue to decrypt these intercepted messages only until the end of the amnesty period specified in the permit.

A similar procedure is used when monitoring messages to and from the recipient. The law enforcement agent identifies the name from the MCH message received

176 458 and the country of the recipient's main depository, and then presents the authorization and MCH of the seized message in the recipient's main depository that uses its private key to decrypt the number of the recipient's certificate that was encrypted in the MCH. Using the recipient's certificate number, the recipient's main deposit center looks for the recipient's name and the names of the sender's escrow agents and discloses them all to the law enforcement agent. The law enforcement agent then contacts each of the recipient's escrow agents and presents them with the recipient's name and authorization. Each escrow agent sends a key fragment that has been entrusted to it by the recipient to the decoder box of the law enforcement agent as an encrypted message to the decoder box having the date of "monitoring start", the date of "monitoring end" and the amnesty period for enforcing authorization deadlines by the decoder box. The decoder box then decrypts and encrypts the key fragments, combines them and uses the reconstructed private recipient key together with the intermediate number of the sender, which is at the beginning of each MCH, to calculate the message session key. The decoder box may then monitor and intercept messages to and from the recipient only during the period specified in the permit and may continue to decrypt these intercepted messages only until the end of the amnesty period specified in the permit.

In another embodiment of the invention, the format of the encrypted key fragment message sent by each escrow agent to the law enforcement agent's decoder box may be as follows:

User Certificate Number

Private Key Fragment: X (i)

Date and Time of Monitoring Start

Monitoring End Date and Time

Amnesty period authorized by the court (days / hours)

Date and Time (of this key fragment message)

Deposit Agent's signature [Deposit Agent Certificate]

In this format, all information except the Certificate Number would be encrypted with the encryption key of the decoder box. Because the key fragment messages from the escrow agents are encrypted for this specific decoder box, no other user or decoder box can read them. In addition, the "Start Monitoring" and "End Monitoring" dates and times instruct the decoder box when to start monitoring and decoding messages and when to end monitoring: The Amnesty Period gives the decoder box an additional, specific time to decode previously taken messages, after which the decoder box must break decode and erase private key data. Thus, the decoder box can be used to decrypt and monitor user communications up to the date specified in the authorization, after which time the decoder box and the clock placed in it will prevent further decryption. The decoder box could also refuse to process key fragment messages having the date and time of the message earlier than twelve (12) hours (or a certain period of time) or having an expiration date and an hour that has already passed

Implementation of the decoder box

In a preferred embodiment of the invention, the law enforcement agencies use a special tamper-resistant decoder box to intercept and decrypt messages of monitored users under certain specified and controlled conditions. An example of a decoder box and its process is shown in Fig. 20. The decoder box 200 is designed to be a reliable device with a design similar to the system of reliable devices of the invention and therefore: it can enforce various conditions to prevent the improper action of law enforcement agents. The decoder box 200 has the device's private signature key placed by the manufacturer and the manufacturer's public signature key that matches

176 458 private device signature key. In addition to the manufacturer's 202 certificate, the decoder box may also have a certificate issued by (or for) the law enforcement authority or the security department of the enterprise owning the decoder box, certifying the relationship between the decoder box and the law enforcement agency or security department and confirming that the decoder box is in its sole possession and control. The decoder box 200 may also have the ability to produce a public / private key pair, like a typical user chip according to the invention, for encrypting and decrypting administrative and control messages to the decoder box. The decoder box 200 also has the ability to securely store its private key and to issue the corresponding public encryption key in the 201 certificate it signed with the attached device certificate 201 signed by the manufacturer. Having this ability to produce (and use) a public / private key pair, it enables depository agents 206 of the eavesdropped user, after the enforcement agents present compliance with the law to the main depository center, permission to monitor user communications, send fragments of the key of this eavesdropped user 204 to the decoder box, encrypted using the decoder box's public encryption key and allows the decoder box to decrypt these key fragments using its private decryption key. However, unlike the typical user microchip of the invention, which decrypts the message and passes the unencrypted result to the user, the decoder box never seems to agents enforcing the private key of the user being sought. Instead, the decoder box stores this information securely until the end of the Amnesty Period specified in the authorization and in the key fragment message, after which the decoder box permanently erases this information.

Therefore, in order to perform its duties as a reliable device and to implement the date and time restrictions imposed in the eavesdropping permission, the decoder box must also contain a reliable set and confirmed date / time clock 205. The manufacturer of the decoder box certifies and legalizes the correctness and setting of the clock 205 in its properties list of known devices. When the decoder box 200 receives from key depositors 207 key fragments 204 containing time limits (based on authorization) before and after which the authorization is invalid, the decoder box 200 uses its internal clock 205 to confirm that the law enforcement agent's authorization is still valid. If the authorization is not yet valid, the decoder box will not monitor or decrypt the eavesdropped messages. If the authorization (and the adopted amnesty period) has expired, the private key of the eavesdropped user is erased and will not be restored again by the decoder box based on this authorization (unless a new authorization for a new period of time is issued). It should be noted that, although the reliable clock 205 is optional for a typical user chip, according to the invention, it is mandatory for the decoder box 200 to enable the decoder box to enforce the date and time restrictions given in the eavesdropping authorization. However, the user of a typical chip can participate in enforcing time constraints by maintaining the clock calibration of his chip. If the user's clock is not calibrated, the MCH created by the user's device during communication will contain a zero value of the date stamp field. In this case, the decoder box receiving the message will only be able to enforce the Monitoring End Date from the authorization by refusing decryption after the expiry of the authorization and amnesty periods. So the decoder box cannot enforce the Monitor Start Date because as long as the permit is still valid, it allows you to decrypt all MCHs submitted with zero time indicator value, even if they were taken before the authorization date and start monitoring time set. But if the user's clock is calibrated . the decoder box enforcing compliance with the law may and will refuse to decrypt all MCHs containing a valid and reliable time stamp with a date and time earlier than the Date and Time of Monitoring Start according to

176 458 lazy. Most preferably, the decoder box according to the invention will only decrypt messages that are reliably dated within the time periods specified in the authorization. It is anticipated that this will increase the resistance to potential abuse of authorization periods by law enforcement agencies and may motivate users to keep their devices calibrated. Indeed, where the system is used to encrypt a large number of messages in a data storage system, enforcing periods of time for subsequent permits or recovery commands may be highly desirable because otherwise many messages may become an object of inspection outside the legal scope of the order.

Law Enforcement Supervision Capabilities

In the deposit encryption system, there is a concern that law enforcement agents can easily be corrupt to obtain encryption keys that protect data of high economic value. For example, members of wealthy criminal organizations can steal a set of valuable industrial plans of a particular company, first by illegal wiretapping the company's communications to get certain message headers and names of deposit agents, then by corrupting low-paying police officials to demand permission to track drugs to obtain a private decryption key from the escrow agent, and finally use a private decryption key to steal the plans. Because encryption is now used to secure communication between multiple computers, it is no longer acceptable for law enforcement agencies to eavesdrop on telecommunications systems with minimal security. A much stronger set of security measures is needed to raise policy procedures and controls to the security level of modern business computers and prevent such situations from occurring.

One such safeguard for a reliable device is an internal counter for numbering each message control header. The counter will increase in order after each access. The sequential message number (MSN) can be placed in each encrypted message header so that it would not be visible to a stranger. This can be done by encrypting the number either (1) with the sender's public encryption key together with a copy of the sender's session key of the message, (2) with the public encryption key of the escrow agent or the sender or recipient, or (3) preferably by at least the sender, recipient and their depository agents, and possibly by all parties to the community of interests. However, the sender's escrow agent could also, as a tactic, decide to allow the serial number to be disclosed publicly, to save space, with little risk of disclosure. Double numbering of message control headers is critical, and numbering gaps should be avoided as much as possible.

Another security feature could be allowing the user to include the optional "title line" in the message control header. If the user is afraid of illegal eavesdropping on the basis of incorrect authorization, he could encode a short title such as "Plan # 123 to warn himself and others about the content of the message. Alternatively, the user could simply maintain his own recorder (in the mail software system) specifying the sequence of message numbers marked by device and user-marked titles. To save space, the title line would be zero if it was not written, which would be a common case.

These safeguards could be used as additional security fragments. First, the message sequence number generated by the device could be used to track the message by both the sender and recipient as well as law enforcement agencies and the judicial system. Although the access of a law enforcement agent may be difficult to effectively control, especially during a hot pursuit of criminals, and although the judicial system may not always be able to carefully analyze the demands of law enforcement agents before issuing a wiretap permit, it may show post-audit urgency to check the results of the tapping, or any tapping, or random tapping, or tapping, which for certain reasons

176 458 seem unusual. The reliable device of law enforcement agents, the decoder box, is therefore modified to include an internal recorder of subsequent message numbers and abbreviations (and title lines, if any) of the messages that it monitored and allowed them to be read by law enforcement agents. The electronic authorization sent to the decoder box by the escrow agents of the eavesdropped user together with a fragment of the user's key may also contain the public encryption key and the signature key of the court that issued the authorization. The decoder box is then capable of responding to a print request register of subsequent message numbers and title lines possibly encrypted with the key of an appropriately authorized recipient, such as the court that issued the permit.

In another embodiment, the decoder box will not start decrypting the monitored messages until it receives a specific court order matching the key fragments received from the escrow agents. For example, key fragment messages received from depository agents and encrypted using the public encryption key of the decoder box can be streamlined by including (from each depositary agent) the public encryption key and the signature key of the court that issued the authorization. Or deposit agents may cite key fragments in their communications for the date and number (if any) of the authorization and the decoder box can then receive from the court its public encryption key and signature key, as well as a court public key certificate that was attached to the original authorization for wiretapping. For example, court permission for depository agents can be streamlined and transfer the following data needed for a key fragment message.

The name of the Central Depository Center or ID number

Monitored User Certificate Number

Court name or ID number

Authorization Number (if any)

Date and Time of Authorization

Date and Time of Start of Monitoring

Monitoring End Date and Time

Maximum Number of Messages (optional) [Judge's signature]

Judge's Certificate

Certificate of the Authorizing Institution of the Judge (e.g. court, etc.)

Deposit agents could then "re-confirm" the public encryption key and court signature key for the decoder box by entering in the encrypted messages key fragments sent by the deposit agents to the decoder box as follows:

The name of the Central Depository Center or ID number

Monitored User Certificate Number

Name of the Deposit Agent or ID Number (sending this key fragment message)

Court name or ID number

The Court's Public Encryption Key

Authorization Number (if any)

Date and Time of Authorization

Maximum Number of Messages (optional)

Deposit Agent's signature [Deposit Agent Certificate]

The decoder box thus receives assurance that all messages of the key fragment will come from the same judge on the basis of the same authorization.

The fact that the decoder box also has a judge's public encryption key and a judge's signature key allows the judge to request and receive (secretly) a record of all subsequent message numbers and title lines of messages taken and decrypted by the box

176 458 decoder during the period of wiretapping, for control, after wiretapping for protection against unjustified and unlawful operation of law enforcement agents. In addition, the decoder box will not, erase, erase or reuse any memory intended to monitor the message register until the decoder box receives a separate command from the judge or court, confirmed by a previously received public signature key, stating that the decoder box can do so. Such an order may be issued either because the court has already received from the decoder box a register of monitored messages that it previously requested or because the court decided that there is no need to carry out an inspection in this case. If the message log monitoring memory becomes full, the decoder box will not decrypt further messages until the register is sent to the judge or court and receives a command signed by the court, allowing the decoder box to erase the register of monitored messages. The law enforcement agency may continue to intercept new messages during the disclosure of the monitored message registry, although new messages will not be decrypted until the full message register is disclosed for control. The decoder box also has the option of alerting law enforcement agents that the log of monitored messages is close to overflowing, so that they can request that the message log to be checked be unloaded so that the decoder box does not interrupt decryption. These transactions and connections can be fully automated and almost immediate.

Each record in the control register may contain, in addition to the message abbreviation, a second abbreviation resulting from the combination of (a) the message abbreviation and (b) the full text of the previous register entry, which are linked together and summarized again. This may prevent dishonest judicial personnel from adding, erasing or reordering records. This concept is discussed in US Patent Nos. 5,136,646 and 5,136,647 incorporated herein by reference.

As a complementary action, the court could later request the law enforcement agency to submit the message headers and the full content of the message abbreviations in the audit record that the court received. Also in its eavesdropping permission, the court could artificially limit to a value less than the full capacity of the message register, the number of messages monitored that can be decrypted by the decoder box before the message register and message headers had to be checked. Although this type of restriction would not affect the overall ability of law enforcement agents to investigate, as the forwarding of the register to the court for review is almost immediate, it could alert the court of unusual circumstances. In specific cases that require stronger control than the regular transmission of a monitored message registry to the court, the court may limit agents enforcing compliance with the right to request a new wiretap permit before reaching the full capacity of the message register.

Thus, if (1) both the sender and the recipient track in their local computer system the order of the message numbers they send and receive, and either the attached title lines in the message control headers or the message register, (2) both law enforcement agents and the court keep a complete record of each decrypted by law enforcement agents and (3) each message header contains a message abbreviation, In order to prevent one of the parties from changing the message later, to disguise their actions, reliable wiretapping control will be able to determine whether abuse or corruption by law enforcement agencies may have occurred. Although this system cannot, a priori, prevent the scenario of theft of plans outlined above, the awareness of the criminal organization that its activities can be fully audited by the court and the injured user can result in an assessment of the cost-effectiveness of incorrect police activities. It could also be regulated that the law enforcement agency records and presents to the court all communications seized on the basis of a permit and allows eavesdropping parties to request wiretapping control,

176 458 especially where the subject is related to business ventures and not by wiretap confirmation of allegations of a crime.

Stream data

In pipelining data communications, such as a telephone conversation, in which each message is a stream of a series of information packets from two or more users, it is impossible for the sending device to encrypt by hashing and sign the entire message as part of the MCH. Although it could be possible to send an MCH with each message packet, it would be very costly in terms of processing time and network bandwidth. Consequently, the MCH should be sent only once during the conversation. A preferred way to maintain the continuity of the encrypted data stream is to mark the talking user as the "sender" and enter the MCH at the beginning of the message, as before, including the sequential message number (MSN) and the first message guide (if any) signed by the device. Then, the sender's device could produce a series of unique sequential packet numbers (PSNs) whose sequence would start with zero at the beginning of each message. For all subsequent packages the device would only need to mix and sign this particular package and enter (and sign) the guide, MSN (the same for the whole message) and PSN for the package. The caller will perform similar actions for each packet he sends, referring to the caller's MSN for the message, sequentially numbering his own packets starting from zero and having the signature of the called device containing the packet guide, the caller's MSN and caller's PSN to create the "packet control header" (PCH). The devices can optionally turn on the current time and time elapsed since the commencement of communication (in seconds and milliseconds), which is already the case in the previously disclosed version of MCH. This could allow a more realistic reproduction of the conversation.

To further distinguish between caller and caller packets after transmission, it will also be desirable to include the talk page code (CPC) in a simple coding system that designates the transmission pages such as caller = 0, called = 1, and additional pages of the same encrypted session receive higher numbers. Or, instead of CPC, unique identification numbers may be used, such as device serial number, device serial number, and device manufacturer ID or combination number.

These methods can also be generalized as a method for generating a multilateral session key. For example, the caller could generate a session key and use the same key to initiate a conversation with several simultaneously called using RSA key transmission. There will be a separate MCH for each additional page, except the first two pages (calling and calling). The caller could treat the multi-party call as separate calls or as one call having the same session key but multiple CPCs. Everyone called would therefore be responsible for using the caller's MSN and for maintaining their own CPC and PSN. Alternatively, assuming the use of conventional two-way session key generation methods (such as Diffie-Hellman methods), conference calls could take place where the central side (e.g. system operator) places all calls and performs decryption and real-time encryption of each party's packets for all others. The central page could also be a unit that switches to the next called, in which case the packets of the called would be decrypted by the device of this unit and then re-encrypted using the session key which this called uses to connect with the other party or parties. See also B. Schneier "Applied Cryptography", J. Wiley 1994, p. 276 regarding the use of Diffie-Hellman on three or more pages.

The packet control header (PCH) could be worded as follows:

MSN of the Original Caller

User Conversation Site Code (caller = 0 etc.)

User's Package Sequence Number (PSN)

Time Interval from the Beginning of the Conversation (msec)

176 458

Guide (of this package) [Device Signature]

It could be beneficial not to send PCH with each message packet, which would significantly increase costs on some systems using short packets, but rather send PCH only periodically. This is related to the technique known as "sliding windows" in network connectivity, in which sequential numbering is not used for each packet but only for a large number of packets. Usually such a system dynamically adjusts the "window" or the number of packets that are sent between error checking based on linear noise, that is, making the window larger for a clean line, but making it smaller for a disturbed line that causes many failed attempts. If errors often appear, a small window would require the user to send only a small amount of data; if errors are rare, you do not need to perform frequent checking, except at a high cost to re-send lost data in the event of an error. The packet control headers can be directly entered into the sliding window scheme in the communication system to get the required ability to control the activities of the law enforcement agent at lower packet levels, while using the maximum capacity of modern communication networks.

To further increase the possibility of monitoring the eavesdropping process, it is advantageous to mark the end of the communication session with a special package. This packet can be sent automatically by the device to others before the user anticipates disconnection to prevent other user or law enforcement agents from claiming later that the conversation was or was not over if it was otherwise. This could be done by instructing each device to accept the "I want to end" input information from people using it after receiving which the device would send a "disconnect preparation" packet that would cause the other device to do the same. The devices would end their data streams with a "final" packet containing no additional data but preferably the sum of all packets sent and received, conversation time, etc.

Stamp

Another feature of this invention in its preferred embodiments, as discussed above when considering a decoder box, is a reliable, tamper-resistant date stamp which itself confirms that it can issue (or attach) a digitally signed time stamp (or date structures containing such a time stamp), which can be considered credible by third parties. Such date stamps are described in US Patent Nos. 5,001 752 and 5,136,643 issued by Addison M. Fisher. In its preferred embodiment shown in Fig. 21, the date stamp 210 (or subsystem) can be calibrated and run only by a reliable institution such as a manufacturer or authorized by the manufacturer, in the same way as a postal validator can only be certified by a US U.S. post office, and henceforth credible to the public and the postal system, as issuing only stamps of previously paid value. Once calibrated date stamp 210 or subsystem will respond to "time setting" 211 or recalibration instructions only if this instruction is signed by the manufacturer himself or by a body that has attached certificate 212 from the manufacturer or a person authorized by the manufacturer stating that this unit is authorized to set and calibrate the date (or subsystem) of this device. Setting the time according to the instructions can probably only be done directly in a unit authorized to set the time that is temporarily in physical possession of the device and can immediately delete instruction 211 to prevent the owner of the device from taking over the instruction and using it at a later date to reset the device clock.

Once calibrated and as long as it is undisturbed, the date stamp 210 will either attach time stamps 213 or include time stamps in structured data fields based on its internal clock mechanism, signing the 214 resulting date structures with its private

176 458 with the device key and providing the manufacturer's certificate 215. If the host device loses power, is manipulated, or receives instructions to stop using the date stamp, it will stop issuing time stamps. In this case, to avoid damaging other possibly useful functions that absolutely require a reliable timestamp, the timestamp will use a convention, such as filling the timestamp field with a pre-agreed value of zero, such as all binary zeros or binary ones (or equivalent convention) when structured data requires a timestamp. However, when a structured data field or host device requires that the actual time stamp is made as in the case of a decoder enforcement box, if the date stamp ceases to issue time stamps, the host device functions that require time stamps stop working, in the case of a decoder box the box refuses to decrypt the messages' ·, to avoid or minimize the possibility of a host power loss situation, each reliable date stamp can be advantageously equipped with its own long-life battery 216 only for use by the clock, some battery "low voltage" indicator to avoid loss of date stamp power before replacing the battery and some retaining elements adequate electric charge (such as a capacitor, second battery or optional external power supply) during battery replacement operations.

Each timestamp issued by the timestamp should have a timestamp certificate issued by the manufacturer (or other time setting organization) stating the quality and reliability of the timestamp clock, the date of its last setting, as well as its expected time drift. When the recipient receives the date structure digitally signed by the host device, the recipient knows that if the time stamp field contains the correct values, the signature and certificate of the device confirm the accuracy of the time given in the date structure when it was created, signed and sent. This certificate is based on (1) the credibility of the institution that recently calibrated the date clock, (2) the clock drift tolerance specified by the manufacturer in the device certificate and (3) the clock's ability to stop working in the event of manipulation or power outage. The recipient also knows that if the time stamp field is set to "zero", the clock was unable to calibrate reliably when the device created, signed and issued the date structure. This information regarding the reliable properties of the date stamp and its internal clockwork can be advantageously coded directly into the device certificate using a coding scheme corresponding to the feature values. However, this information could also result from the manufacturer's name and type of device, which would be published by the manufacturer in the product specification and certificate as part of the publicly issued "technical declaration" at the time the device certificate was issued.

Such time stamps could also be issued by the device as part of other message handling operations between MCH creation and decoding. These timestamps could be attached to the device user's personal signature when he signs other documents or operations using his personal signature key that is securely locked inside the device. The device could sign or co-sign a user signature time stamp element, or alternatively it could sign the entire user signature block (which includes a time stamp, also signed by the user along with the document abbreviation resulting from hash encryption). The device could therefore issue a certificate to make the time stamp reliable and certain for a third party who knows the manufacturer's public key.

Reliable update, exchange and exchange of the key

Another feature of the invention is a reliable tamper-proof device that contains a manufacturer's public key, a protected non-volatile memory area and a secured processor (CPU) and can update or add in a credible manner firmware procedures enabled by the manufacturer. A reliable device performs updating or adding by accepting entering data content containing new or up to 34

176 458 additional firmware codes suitable for this type of device and digitally signed by the manufacturer's signature, which signature ensures the device that a new firmware code has been developed, tested and approved by the manufacturer and that the device should therefore either (a) impose a new firmware code on one or more currently placed firmware programs or (b) add a new firmware code as one or more new software in the currently unused protected memory area. In a preferred embodiment, the protected memory should be of a flash type that can store information during a power outage, but can also be erased by the device (although relatively slowly) and reused, if desired, protected memory may also contain data collection areas (such as disk drives) in which updated or additional codes could be stored in encrypted form, to which the decryption key is known only to a reliable device. By remembering programs in encrypted form, the device protects them effectively from being modified by someone who does not know the decryption key. When the device receives such a signed set of new firmware code (or application software), the user enters the code together with the manufacturer's signature and gives the device instructions for the "firmware update process". The device then confirms the manufacturer's signature using the manufacturer's public signature key that was placed on the device during manufacture. If the manufacturer's signature is authentic, the code is accepted and the device performs the desired modification.

The process of reliably updating the firmware of a reliable device as described above can also be extended by the introduction of an authorized third party who wishes to update the firmware procedures belonging to the device functions associated with this third party, including the functions of the key deposit system, which can be widely designed and administered by the main banking deposit center regardless of the manufacturer of the reliable device. For third party upgrades, the manufacturer should sign the firmware upgrade certificate containing the third party public key of the firmware provider and issue it to the third party. The third party should then develop, test and approve the exchange or introduce additional firmware procedures, sign them with the third party's private signature key and attach your upgrade certificate to the manufacturer's certificate. Upon receiving such an upgrade, the user will load the signed code procedures and manufacturer's upgrade certificate to the device, and then issue instructions on the "third party firmware upgrade process". The device will then verify the third party's signature on new procedures based on the manufacturer's upgrade certificate, and then verify the upgrade certificate with the manufacturer's public signature key that was placed on the device during its manufacture. If both signatures are authentic, the upgrade is accepted and the device performs the desired upgrade. In addition to accepting instructions for upgrading or adding device firmware procedures, a reliable, tamper-resistant device can also accept replacement instructions or additional "instructions" of public keys placed during device manufacture. As discussed above, a reliable device may have public keys, in addition to the manufacturer's keys placed during the manufacture of the device. Such public "instruction" keys may contain the keys of one or more major depository centers as described in the invention. These embedded keys, including those of the manufacturer and other third party trustworthy parties, can be used to verify various certificates, such as certificates of deposit, device certificates, update certificates, time instruction instruction certificates and other devices presented on the basis of which it is to operate. In addition to relying only on the public keys entered during the manufacture of the device, the device can also accept external instructions for entering new public keys or changing existing ones. That the device accepts and remembers the public signature key in a non-public area

176 458 credible third party, the manufacturer will attach a new public key to the signed instruction data package (or certificate) signed by the manufacturer, instructing the device to reject the attached certificate and remember specific public instruction keys contained therein. A special package can also instruct the device as to the type of operations for which the new key is reliable (e.g. for use with a deposit key, used when renting a car, used for medical data, or in other applications). Having received such a package of public key data from the manufacturer, the device will first check the manufacturer's signature, and then accept and remember new public keys, including restrictions on their use. The manufacturer may also indicate third-party instructions when placing the public key, either during manufacture or later as part of the instructional data packet that one of the operations for which this third party key was approved is a replacement of its own, primary public signature confirmation key of the producer. Although this replacement of the manufacturer's own public signature key should almost never be required, it may happen that the corresponding private manufacturer's signature key (for issuing device certificates and other device instructions) may have been discredited by theft. Theft of the manufacturer's private signature key would allow the thief to issue seemingly important instructions to approve new deposit centers (of dubious credibility) or approve new time setting institutions. Alternatively, and more likely, the manufacturer's private signature key may be lost or damaged, preventing further valid instructions from being issued. Each of these cases could be described as a "disaster" in terms of computer systems and could result in the need to recall all devices of this manufacturer. However, according to the invention, the costs of such withdrawal could be avoided or reduced by allowing a credible third party to replace the manufacturer's discredited signature key. Assuming that the manufacturer has already placed in the device the keys of the instruction of one or many reliable third parties either during manufacture or later using the instruction data package and introduced the exchange of his own public key for operations that have the right to approve the third party's public key of instruction, the manufacturer should then request this credible third party to send a package of instructional data to all manufacturer's devices authorized to exchange the manufacturer's public signature key, thus saving himself and his users the potentially huge costs of physical replacement of all physical devices Because all device certificates issued by this the producer would also have to be replaced, this could be done by requesting each device requesting a certificate for its own device signature key. If the private key of the manufacturer were lost or destroyed, and not discredited, then all previous signatures would still be valid and the user would only have to present their old device certificate to receive a new device certificate issued for the same information and signed with the new manufacturer's signature key. The manufacturer could then return new device certificates (most likely via direct connection or email operations). Although it would also be expensive, it would be much cheaper and less harmful to the reputation of the manufacturer than the complete physical replacement of all reliable devices of this manufacturer.

The inclusion of a manufacturer's public key exchange mechanism or other reliable public instruction keys in a reliable device according to the invention could limit some of the systemic security risks presented by the use of an extensive system based on public keys. This would allow greater confidence in purely hierarchical deposit models, which generally allow shorter and simpler confirmation paths, requiring fewer certificates, less effort to determine which certificates to use, and less computational time for signatures.

176 458

Key exchange controlled by the owner

As described previously, the user also has the option of exchanging keys on the device, such as a pair of user keys, at any time after production. The user executes by issuing a programmable instruction to a reliable device to perform certain stages of the way of entrusting the keys, i.e. creating a new private and public encryption key, sending a key fragment to depository agents and finally receiving a new certificate of deposit from the main depository center. However, it is also desirable to allow the user's employer or sponsor (or owner if the user is another device or process) to (a) ensure that the user selects a deposit agent that the employer considers acceptable and (b) ensure that the employer, as the real owner of the device will be known to this selected deposit agent, so he will be able to demand from the escrow agent fragments of the user's key without first obtaining permission or a court order. The employer may require access to specific keys for a number of reasons, such as internal supervision, or for the recovery of the owner's encrypted data after the loss, theft or destruction of a particular device. The employer may also need to change the device keys for reasons such as for the device whose original encryption key or signature key has been discredited or erased, for a device that was given to another employee, or for a device whose organization has changed the keys in all encrypted devices in certain intervals as a tactic element.

In a preferred embodiment, the reliable device is pre-set by the manufacturer so that it will initiate the key creation and deposit process if it first receives the owner certificate for the device 220 such as that shown in Figure 22 containing the permanent serial number of the device 221 signed 225 by the manufacturer. The owner certificate 220 issued at the time of the enterprise's purchase to the purchaser of the device also includes the company name 222, the company's unique identification number 223 (such as Employer Identification Number (EIN) or Dun & Bradstreet Number (DUNS) and the company's public signature verification key 224, which corresponds to the private signature key retained by the company and which will be used to verify the change of the key or other instructions given by the company to the device. As a result of receiving this information, the device will only respond to key changes or other instructions signed using the enterprise owner's private key corresponding to the public key contained in the device owner's certificate.

Referring now to Fig. 23, where the employer (owner of the device) wants to change the device key 230, the employer issues to the device 230 a signed instruction 231 containing (1) the serial number of the device 232, the unique identification number of the owner 233, (2) the names of deposit agents 235 and the main deposit center 234, ( 3) date and time of issuing the key change instruction, (4) date and time of expiry of the key change instruction period, (5) the unique serial number 237 of the key change instruction and signs the manual with the employer's private signature key 238. Having received a valid owner certificate 239 and valid key change instruction 231 chip inside a reliable device 230 first confirms the manufacturer's signature on the owner certificate 239 and the employer's signature on the key change instruction 231. The reliable device then creates the key and performs the deposit process as before, including the unique owner's identification number 233 into each key fragment depositing package and sends the key fragment packages only to those depository agents who are designated by the employer in the key exchange instruction 231. Subsequent repetition of these instructions (which may be issued electronically) may be limited by designing the device in such a way that it retains in its non-volatile memory the serial numbers of the last few received key replacement instructions and refuses to execute the next instruction. Assuming that the device clock is OK, the next repetition of the key change instructions can only be limited by instructing the device clock to honor the date and time the instruction expires. In a preferred embodiment, a device whose clock is not calibrated would refuse to perform a key replacement instruction that has a non-zero date / time expiry date, but would execute it if the date / time values ​​were zero.

Having received from the user device packets of key fragments (or a changed key) containing the unique identification number of the owner, deposit agents and the main escrow center would write this unique identification number in their databases and then honor the owner's requests for access to the private encryption key. In a preferred embodiment, the depository agents and the main depository center would require that the key fragment packet marked with the owner's unique identification number is also accompanied by the device owner's certificate signed by the manufacturer. This device owner certificate would allow the escrow agents and the main depository center to act in accordance with the key request messages signed with the owner's private signature key corresponding to the public owner's key in the device owner's certificate.

In another embodiment, a trusted device may be allowed to accept key changes, trustee changes, ownership transfers, or other device owner's instructions without having to use a separate device owner's certificate. The requirement to use a separate owner certificate for the device instructions is an administrative burden because the owner must maintain the certificate database for all owned devices and place the appropriate certificate whenever he wants to change the device key or send any other instructions to the device. A better approach as shown in fig. 26 is to have one owner certificate issued by the manufacturer for public owner instruction keys for a given device family, the mech seller installs his public instruction verification key 261 inside device 260 when the device is sold, and then establishes a system based on the internal remembering of those keys. After the first sale of the device by the manufacturer to the owner, the device 260 will first verify the validity of the manufacturer's certificate 262 issued to the owner using the manufacturer's public instruction key 263, which was placed on the device by the manufacturer. If the owner instruction public key area 264 is empty, the machine will copy the owner instruction public key 261 from the manufacturer's certificate 262 issued to the owner to the owner public instruction key area 264 on the device. If the owner's public instruction key already exists on the device and is different from the one the owner is trying to boot the device into, the device assumes that the manufacturer sold the device to another entity. Since each device will have at most one first owner, the ownership of this device will be determined by the presence or absence of the owner's public instruction key 261 within device 260 instead of (or in conjunction with) the previous concept of owner certificate.

If the owner's public instruction key has not been installed, the device may be treated as a device belonging to a single consumer user that has no restrictions imposed on the change of the key or the transfer of ownership of the device; as such, the device will treat the non-existence of the installed owner's key as a signal that you should listen to the user's instructions without referring to the above discussed rules on changing the deposit key and transferring ownership. If the owner's public instruction key 271 has been installed in a reliable device 270 as shown in fig. 27 user instructions 272 regarding the change of the deposit change key and the transfer of ownership will not be executed unless these instructions are 273 signed with the appropriate private owner's signature key 274. Once the owner's signature has been verified, the reliable device performs the steps of the deposit change procedure as described previously. So the owner does not have to add the owner certificate proving his ownership to the given numbered device when he gives him instructions. However, the owner's signed instructions must obviously be limited to numbered devices or perhaps certain classes

176 458 devices, whose numbers correspond to the rule or pattern to avoid providing instructions to each device owned by the owner.

In addition, as shown in Fig. 28, the owner may send instructions to change the owner of the device by exchanging the originally installed public verification key of the owner's instructions with another (new buyer, new owner of the device). The device owner sends to the device 280 a change of owner instruction 282 containing the name and the public verification key of the new owner, signed with the private key 283 of the signature of the current owner instructions. The device verifies the owner change instruction 282 using the current owner's instruction key 281, replaces that key with the new owner's instruction key 284 and then only responds to the instructions of the new owner. In addition, the owner can also add another "secondary owner" by installing a second public instruction key. This second public instruction verification key has a "rights" field, indicating the instructions which operations he can authorize. These rights may include: changing the key, adding a second owner, removing one owner and returning to the device status of a consumer without a specific owner. However, these specific rights may contain more or less rights than or the same rights as the initial or original instruction verification key, including the right to replace or delete the original owner's instruction key.

General device registration

Let us note that the general methods of depositing a private decryption key and receiving a certificate of deposit discussed above can also be used in more general cases of registering a reliable device with a reliable third party and obtaining from this third party permission allowing the device to communicate with other reliable devices, not necessarily limited in scope and purpose for the key deposit situation. In this general process shown in Fig. 24, a programmable trustworthy device 240 that communicates with a trustworthy third party (TTP) 241 is equipped with a private signature key and manufacturer's certificate 242 for the corresponding public signature key. It also contains secured copies of the manufacturer's and system-wide (SWA) public keys of the manufacturer and institution, which can be the same and secured at the system level firmware that can support remote installations of an additional level of software applications and the corresponding public keys as discussed everywhere in this description. The device 240 can register with any of the potentially unlimited TTP 241 counts admitted to this general registration system by an issued institution certificate 243 signed by SWA (SWA could also establish confirmation for TTP authorization to be admitted to the system in accordance with well-known principles of confirmation hierarchy public keys). Once users register their devices with a given TPP, they will be able to engage in specialized operations with other exchange partners.

In the first stage of this process, the user initiates a request 244 to register his device 240 with a given confirmed TTP 241. This request 244 contains certain information 245 needed to identify the user and the nature of the registration request and is signed by the device and is accompanied by the device manufacturer's certificate 242 to secure the signature and device of known type. The selected TTP may also require other information and security either from the user or other parties verifying the user's identity, affiliation, creditworthiness, etc., which are outside the scope of this protocol but may affect the TTP's decision to grant or refuse the requested authorization for the operation. TTP 241 uses appropriate public keys to verify the manufacturer's signatures on device certificates 2421 device signature on information 245 in the user registration request.

When it is convinced that the user may be allowed to perform operations of the requested class, TTP 241 then issues a response 246 containing the certificate 247 specifically authorizing the device to perform these operations on behalf of the user. A device authorization certificate 247 issued by TTP typically contains TTP identification information,

176 458 user, user device and operations for which permission is issued, as well as a re-confirmed copy of the user's device public signature key as convenient (and as discussed later) so that the user does not have to submit his device certificate 242 in each subsequent operation with exchange partners . The TTP 246 reply may also contain downward firmware and / or keys 248 to be loaded on a reliable user device to allow it to perform authorized operations. Where the TTP 246 response calls the user to securely load new firmware or public keys to their device, the 246 response will also include a TTP authorization certificate 243 issued by SWA confirming the TTP public signature key and upload the firmware and public key update certificate. When a reliable user device 240 receives a 246 response, TTP uses its embedded SWA public signature key to verify the power of attorney certificate 243 and uses the TTP public signature key it contains to verify the firmware update 248, the public key and the device authorization certificate 247 TTP.

Referring again to Fig. 24, where the user wishes to perform operations with the exchange partner 250, his device will determine the date 249 in accordance with the principles contained in the hardware program installed in the device (either during manufacture or during subsequent charging), as was extensively discussed in this description and will sign operation 249 and attach a certificate for his public key. This certificate could be the 242 device manufacturer's certificate, but more likely it will be the TTP device authorization certificate 247, which contains a copy of the device's public key for convenience re-confirmed. The exchange partner 250 will typically use a public TTP key to verify the TTP signature in its device authorization certificate 247, and then use the public signature key it contains to verify the device signature on operation 249 to confirm that the device adapts to the operation protocol requirements imposed by the relevant software hardware. In case the exchange partner 250 does not yet have a specific public TTP signature verification key, the user can include 249 TTP SWA authorization certificate 243, which the exchange partner can verify using the SWA public key, which he must already have to participate in the system.

The generalized process so far described is general enough to allow (a) the deposit of a private encryption key in exchange for a certificate of deposit signed by the deposit center (TTP), where the information contained in or placed in the user's device certificate sent to the deposit center shows that the device is already equipped with software that can perform special functions of the cipher system described here with key deposit, or (b) if such a device is not so equipped but can be so equipped, loading a secured program extension, after installation of which the device will be able to meet the operational requirements of the depository system. Operation data 249 sent to exchange partner 250 can be an encrypted message preceded by a message control header, which is accompanied by an authorization 247 (user deposit certificate) issued through TTP 241 (main deposit center).

The generalized system shown in Fig. 24 thus has many highly desirable properties that can facilitate complex forms of business or government operations in an open communication network environment. In particular, there may be many different device manufacturers, as long as each participating device is capable of performing secured multi-stage operations and signing operations performed. There may also be a number of reliable third parties, each issuing a different type of operational authorization and each creating and confirming a different class of software applications, such as key deposit, digital financial management, car rental, or user medical records management. So although you can require the exchange partner (through user device protocols and software) to use a comparatively equipped reliable40

176 458 devices, this device can be manufactured, sold and equipped by parties other than those of the original user, but the operations of the original user will still be accepted and performed in accordance with the system's rules, as long as the partner has a copy of the public key 247 SWA signature verification, which allows all device versions and their programs to recognize each other and work together, when authorized to do so by SWA and its TTP. A few examples of doing business that can be implemented through this protocol include systems that impose operational requirements on (a) encryption using securely deposited keys, (b) managing digital representations of money and other valuable documents · ', (c) access to and the use of user's medical and other personal information.

Unique Owner Identification Number

Depending on the need to balance ease of use and confidentiality rights, the owner's unique identification number may also optionally appear in either (a) the user's (b) MCH depository certificate issued during normal communication, as well as in key fragment message to the escrow agent. It would be desirable for the investigator trying to decrypt the message to be able to determine by looking at the MCH containing the owner's identification number, whether one or both of the communication devices from which the MCH was taken belong to the respective owner. However, the need for secrecy, especially by some users, may suggest that the owner identification number is omitted in the MCH to increase communication secrecy. In the case where the owner's identification number is included only in the device's certificate of deposit, not in the MCH of messages, the investigator investigated hired by a specific employer with the task of determining whether a specific message comes from the employees of that employer, dealing with many MCH in which there are no device owners, would have to check with the main depository center listed in the MCH if the MCH comes from a device owned by the employer. The main escrow center could decipher the certificate number of the MCH message page whose keys are deposited at this main escrow center and check whether the user certificate was issued by the investigating employer. If so and if the investigator's request is signed using the employer's signature key (i.e. the investigator has authorization from the employer-owner to investigate), the main depository center would disclose this information. If the investigator is not authorized he will have to seek authorization or an order forensic to be able to track suspicious activity reflected in MCH owners of unknown device. It can be predicted that most device owners will not object to their name being given in an open manner in the certificates of deposit of their users and in MCH, because in most electronic communication systems it is impractical to hide information about the physical and logical network address that often clearly identifies institutions sending and receiving the message. So you don't lose a lot by publishing the unique identification numbers of the owners, and you get a lot by being able to check everything and choose messages by the name of the owner of the sending or receiving device.

The owner's unique identification number may, however, still be included in the employee's certificate of deposit or in MCH messages without public disclosure. The employee's deposit certificate and MCH should contain the Employer's Public Encryption Key along with other keys, as described above. These keys should normally be on the sender's and recipient's certificates of deposit (assuming that both the sender and recipient have employers). When the sender's device creates the MCH, it will enter into the MCH one or both unique employer identification numbers, each encrypted using the appropriate employer's public encryption key, so that in fact the sender's device uses the MCH to send a message containing that relevant employer to each employer-owner owner's unique ID, which only he can decrypt. This method is similar to the one discussed above 176 458 above, where the sender uses MCH to send the certificate numbers of both the sender and the recipient encrypted with the public encryption keys of their respective depository centers and to send the session key to the recipient (normal MCH function as well as to the sender) to enable eavesdropping on both sides. This technique allows the employer to easily determine which MCH belongs to his employees, while avoiding that all messages belonging to the employees of the owner-employer are easily identified in the message flow and in which the owner ID numbers are unencrypted and easy to obtain.

However, this approach has the disadvantage that the employer's unique identification number encrypted using the employer's public encryption key will always create the same and therefore recognizable value. A better implementation of this approach would be to encrypt a block of data containing the current time stamp (or a random number) along with the number of the employee's certificate of deposit (which the employer obviously has the right to know) with the employer's public key, so that the time stamp would give high variability to the block of encrypted data. A few bytes of clear "eye-catching" text such as "EMPL" (or possibly unique employer ID) could also be included in the encrypted block to enable decryption, of course, of the unit that is to decrypt the field (for other data, the items are in binary notation the individual could not have known them). In this case, proof of ownership of the employer is that only the employer is able to read this field. In addition, yet another random number can be added to the data block to increase variability, in case the timestamp is not sufficiently certain that it will be different in each case, and thus makes all MCH employers unique data blocks.

In this improved approach, which would be made for employers of both the sender and recipient in each message sent, it would be possible for employers and other sponsors to determine which messages were created or received by their employees, without having to submit the encrypted MCH of each message to the appropriate deposit center for determining whether or not any of these messages are from a device owned by the employer, so probably saving a considerable amount of money. Each employer will still have to contact the main escrow center and escrow agents as before to obtain his employee's private encryption key and must prove that he is actually the owner of the employee's device by signing his request with a private key that matches the public signature verification key contained in its owner's certificate issued by the device's manufacturer. At least, employers will save time, effort and expenses on additional requests to these pages regarding MCH messages, which, as it turns out, did not come from devices belonging to the owner. As before, if the employer suspects a criminal or me incorrect activity in messages that are accompanied by MCH from communications conducted by devices not owned by him, the employer can always contact the law enforcement agency, inform the agency about the suspected criminal activity and make the agenda asked the court to obtain authorization to intercept and / or decrypt these messages, which, as it turns out, comes from a third party not an employee, criminals or probable unit from the premises of the employer, employed or me, which uses encryption devices not owned and not registered by the employer.

This method of placing information in an encrypted MCH, so that information can be read only by the authorized party can, of course, be extended to other pages except the sender and recipient (each of which can decrypt the message session key), the main deposit center of each site (each of which can decrypt its users' certificate number) and the employer-owner of each site (each of which can decrypt its employee's certificate number or its own unique identification number of the owner to make sure that the communication device belongs to it, without ko42

176 458 the need to contact anyone, avoiding identification in every message). It can also be extended to other sites, such as branches of very large companies or, for example, local law enforcement agencies in countries where there is no obligation to obtain authorization. Of course, all information encrypted with these keys can also be shown as explicit, i.e. unencrypted, as discussed earlier, provided that these parties have no objection that they are openly named and routinely identified in each message. This information may also be omitted when it is not relevant to the site, e.g. if the user has no employer. In this simplified approach, one MCH format should be used for all situations, leaving blank fields when they do not apply. Otherwise, in a preferred embodiment, different MCH variable formats would be used in the same system, each format would be identified by a unique version of the number in the first field, so that each MCH processing device would be able to determine which fields to expect and divide accordingly . This method would allow infinite entry of pages into the MCH which would be the most flexible system possible. The calculation costs would mainly depend on how many of these fields are actually to be encrypted with the public encryption key of each separate page.

The employer can easily control the information contained in the MCH by attaching to each record a "tactical field" or instruction code containing a code instructing the employer's device what information to include in the MCH. As before, the instruction code could contain selection elements that give the employer the option of including the following information (1) the employer's name and unique identification number, either encrypted or using a nickname; (2) the word "employer" unencrypted with the employer's unique identification number encrypted inside the MCH field; (3) the user's certificate number in the encrypted field; (4) message session key in an encrypted field; (5) time stamp in the encrypted field; and (6) a random, mixed number in one of the other encrypted fields. Many of these options can actually be simultaneous. In addition, these tactical options may be the same for all members of the community of interest, including parties communicating with each other, to enable the parties to mark themselves with their postal or system ID, or more simply using the word "sender" or "recipient" in the relevant explicit MCH fields.

Multiple keys deposited simultaneously

In addition to the above-described software update and public key exchange properties of the manufacturer, a reliable device according to the invention should also be able to maintain and manage a number of encryption key deposit sets simultaneously. Normally, when the device starts the key exchange cycle, it is generating and depositing a new private decryption key and as a result receives a deposit certificate for the corresponding new public encryption key, the device will erase the previous private key to increase the device's confidence in the newly deposited private key Alternatively, the device could keep the previous private key only for a short time, for example, for the time needed to recover data encrypted in the pizza memory using the existing private encryption key. However, in an alternative example, the device may also accept and execute the key change instruction either from the user or the device owner, as described above to create a second valid certificate of deposit for the same private / public encryption key pair In this example, the device would conduct the deposit process using probably a different list of deposit agents and another main depository center and would receive another equally valid certificate of deposit for the same private / public pair encryption keys issued and signed by the second main depository center and could use it alternating with the first certificate of deposit. This second public encryption key certificate could be used when the user of the device travels internationally or corresponds with parties based in other countries, especially when those other countries wish to conduct legal surveillance of outbound and inbound communication to that country. In such cases, by re-registering the same device key in another country, the user (or his employer) may satisfy the possible legal requirements of another country, while the user or employer still has the convenient opportunity to do business with the original team of deposit agents in their own country (legal monitoring by the owner, recovery of the lost key, etc.). Then, to allow the owner to track his employees' MCH may be sufficient if the sender's and recipient's owner ID appears in each MCH, informing the owner that he actually has the opportunity to obtain the key. To save time and effort, the owner can then send such an MCH to the foreign main depository center and obtain the number of the foreign deposit certificate, the hidden device number and the hidden device certificate, but then ask its domestic deposit agents who can verify the owner's certificate already in their owned and issued real private key fragments. This procedure releases the owner of the device from additional legal formalities that could be required to obtain real key fragments from foreign deposit agents.

National security protection

The current US government policy allows unregulated use of encryption in the United States, but imposes heavy restrictions and penalties on the export of encryption devices, software or know-how. You can modify the current system to allow relatively free private use of cryptographic devices in the United States while imposing restrictions on their international use. Such a system would allow separate inter-operational "political zones" that are open to all hardware and software vendors, with minimal or no design change in standard message formats used throughout the system. It is furthermore desirable to allow the use of private escrow agents in purely intra-corporate situations in one country where the key deposit system is only used to enable individual enterprises to monitor and control the use of ciphers by their own employees, without the obligation to facilitate or enforce the law enforcement agents for messages, which have been encrypted using the keys deposited by the company. In particular, such companies could buy software and hardware for their own use, but they could refuse to accept the public obligation to provide access to private keys for a short time frame that could be desired by the law enforcement agent in the hot pursuit of criminals or terrorists.

This could be done assuming that all devices in the entire system are attached directly or indirectly to a system-wide institution (SWA) that (as previously disclosed) issues certificates to depository agents to major depository centers and device manufacturers to enable everyone to be recognized by system devices as authentic and reliable. For practical purposes, a national or global communication system must support the existence of many unrelated major depository centers and agents, each of which would have to be authenticated by the SWA as authentic. In each certificate issued to the main depository center or the SWA depository agent, it will mark it as either "public" or "private". The "public" main depository center or escrow agent is equipped and adapted to promptly respond to the authorization or call of a national security or law enforcement institution. Users whose keys are deposited with such agents may be allowed to conduct international communications. The "private" main escrow center or escrow agent are those escrow centers of one enterprise or country that have the key deposit system technology installed but do not take any action at the public service level. The SWA certificate for the master escrow center or escrow agent will also contain the country code. So any user deposit certificate that is issued and signed by the main depository center and has been attached

176 The 458 SWA certificate for the master escrow center will also have the user's country code. Let us note that it is convenient for the user's deposit certificate to also state its origin from a public or non-public deposit agent, although it may not be possible for SWA to enforce this information. This could allow the device to enforce these rules even more easily than the usual SWA certification requirements for a master escrow center.

Figures 29 and 30 show the enforcement of deposit requirements when sending and receiving encrypted international messages. As shown in Fig. 29, the reliable device 290 of the sender enforces this system by requiring the deposit certificates 291,293 for both the sender as well as the recipient and if the sender and the recipient do not have deposits in the same main depository center their depository certificates of the SWA main depository before sending an international message . Country codes 295,296 of the receiving user and his primary deposit center must match for the sending device 290 to send the message. Also, if the sender and recipient are from. different countries 295,2971 If any of the users are using the non-public main deposit center 298, 299, the sending device will refuse to initiate communication to such a recipient. As shown in fig. thirty a credible device of the recipient will also enforce the system's requirements by refusing to decrypt the message, if it was somehow created, when the sender and recipient are from different countries and if any of the users uses a non-public main depository center. These rules implement the desired policy of not allowing encrypted international communication outside the depository system, since the main depository center cannot falsify its public status confirmed by SWA and even if the main depository center could fake the user's country code (so that the user seems to belong to a foreign zone ), the device will not allow any discrepancy between the user's country codes and the main escrow center. Although these rules do not prevent the unlawful transport of a credible user device across the border, they allow easier adaptation to national restrictions by allowing them to maintain the key deposited in each country and communicate using the correct key in each political zone.

Version of the device for many users

Another feature of this invention is the ability of the same device to initiate and simultaneously conduct different communication sessions with different local and remote users. Many larger computers support many users who often register simultaneously through session terminals, but who may want to initiate encrypted sessions with other entities around the world. However, since it would be highly inefficient to require independent reliable devices for each user session in a shared computer, a reliable device could track the message session key by remembering it together with the unique message sequence number (MSN) for that session. Then, when additional message packets carrying the same MSN arrive, they can be decrypted and the responses encrypted without delay. In addition, the device could deposit private decryption keys of many users by combining each private user key with a unique user identification number and allow each key to be used only after presenting the appropriate user identity certificate such as password, smart card, PIN, biometric data, test response, etc. By marking the user identification number, password or equivalent for each public / private key pair, as it is created for the deposit, ordinary password controls such as length, expiry date, write lock and easy guess can then be done by the device to limit the possibilities unauthorized access.

The system and encryption method using deposited keys are presented here. The skilled person will appreciate that the invention may also be practiced in examples other than those described, which are presented for purposes of illustration and not limitation. The invention is limited only by the following claims.

176 458 Fig. 1Ά

<td>X</td><td>Recipient's Private Key (Exponent)</td>

<td>N X1 ...</td><td>Numbered Private Key Fragments</td>

<td>xi</td><td>i. Private Key Fragment</td>

<td>s</td><td>Ephemeral Private Sender Cry (Exponent)</td>

<td>and</td><td>Public Base Number</td>

<td>P</td><td>Public Prime Module Module]</td>

<td>DHX</td><td>Intermediate Number = a^xmod p</td>

<td>DHY</td><td>Intermediate Number = afood p</td>

<td>kdh</td><td>Derived Diffie-Hellman Message Key</td>

<td>V1 ... n</td><td>Intermediate Number Micali = a^ximod p</td>

<td>kmsg</td><td>Random or Derivative Message Key</td>

<td>M</td><td>Open Message</td>

<td>C</td><td>Encrypted message</td>

176 458

Fig.l®

<td></td><td>Public</td><td>Private</td>

<td>Signature</td><td>KS ⁺</td><td>KS</td>

<td>encryption</td><td>KE⁺</td><td>KE</td>

Fig. 1C &lt;KS⁺dev&gt; mfgr

<td> \ /</td><td> \ /</td><td> \</td>

<td></td><td></td><td></td>

<td></td><td></td><td></td>

the device's public signature key signed by the manufacturer (using the private mfgr key

KS ~ mfgr) ^ ΐβ.ΙΊ) (Message)

KErecir

<img file="PL176458B1_D0001.tif" />

message to be encrypted using the recipient's public encryption key

176 458

<td>box</td><td></td><td>Law Enforcement Agenda Decoder Box</td>

<td>ca</td><td>cal. n</td><td>Confirming Authority (Public Signature Keys)</td>

<td>dev</td><td></td><td>A reliable device</td>

<td>ea</td><td>Neal n ...</td><td>Escrow agent</td>

<td>ec</td><td>n ecl ...</td><td>Deposit center</td>

<td>mfgr</td><td>mfgrl ... n</td><td>Manufacturer of a reliable device</td>

<td>owner</td><td></td><td>Device owner (if different from user)</td>

<td>recip</td><td></td><td>Message recipient</td>

<td>sender</td><td></td><td>The sender of the message</td>

<td>swa</td><td>1 ... n /</td><td>A system-wide institution</td>

<td>user</td><td>user</td><td>A reliable device user</td>

Fig. 1F &lt;data&gt;, dev data

-dev = &lt;data&gt; KS \ dev (data). = (data) KE + Sender sender

176 458

Fig.2

Prior agreement of the (explicit) first p value of a

Page A

Page B

<img file="PL176458B1_D0002.tif" />

Common key a * y mod p known for A and B · but impossible to calculate by the eavesdropper

176 458

A User B Confirming Authority

<img file="PL176458B1_D0003.tif" />

176 458

Recipient at and this at

ca ca &lt;

N

ABOUT

<img file="PL176458B1_D0004.tif" />

N ca NN □ QOO

176 458 τΤ l / Ί

<img file="PL176458B1_D0005.tif" />

176 458

Ό

<img file="PL176458B1_D0006.tif" />

176 458

Fg- 9

<img file="PL176458B1_D0007.tif" />

176 458 fig, 10 (O&gt; 4

<img file="PL176458B1_D0008.tif" />

176 458

<img file="PL176458B1_D0009.tif" />

176 458

123

121

IN*

Fg.i3 &lt;

Fig.14

Version No.

No. Serial Certificate Deposit Center Name Country Code KE + ec Deposit Center (for LEAF use)

KE User Name + User (for Messages) KS + dev (for LEAF verification) Validity period

Signature of the Depository Center (Kmsg) K (j_evKmsg checksum

Serial number of the device LEAF checksum

Kfam

122 —124 —125

<td>kmsg</td><td>Symmetrical Message Key</td>

<td>Kdev</td><td>Built-in Symmetrical Device Key</td>

<td>Kfam</td><td>Symmetrical Key of the Clipper Family</td>

Version no. Name Mfgr Serial number Equipment Type / Model Equipment Date Mfgr KS + dev

Code Feature (optional) Signature Mfgr

176 458

Π3

Ν Φ

<img file="PL176458B1_D0010.tif" />

Ν □

176 458 fig. 16

Certificates

<img file="PL176458B1_D0011.tif" />

176 458 and in

Η

<img file="PL176458B1_D0012.tif" />

V

Ι- &amp;

\ ο r-

<img file="PL176458B1_D0013.tif" />

<td> &gt;</td><td>evl&gt; mfgr</td><td>σ3</td>

<td>about</td><td></td><td></td>

<td>Ό</td><td>CC</td><td>ol +</td>

<td>CC</td><td>Nd</td><td>CC</td>

<td>Nd</td><td>V</td><td>Nd</td>

N £

o3 i_

those

CC

<img file="PL176458B1_D0014.tif" />

rm ru ·

CCS

N

Ό

v&gt;

r176 458

FG18

Version Number (Message Key) KE + recip

Name of the Sender's Deposit Center (ecl)

-181

Sender's Deposit Center Country Code

Name of the Recipient's Deposit Center (ec2)

Recipient's Deposit Center Country Code (Sender's Deposit Certificate Number) KE + ecl (Message Key) KE + sender (to yourself) (Recipient's Deposit Certificate Number) KE + ec2

181

181

181

Time stamp (optional)

Sender Device Signature

176 458

<td>at Deposit y</td><td>Lorcy</td><td>&lt;N</td><td>04 Q AT 1</td>

<td>ABOUT</td><td></td><td> &gt;</td><td></td>

<td></td><td>Ό</td><td>ABOUT</td><td></td>

<td>ls</td><td>ABOUT</td><td>T3</td><td></td>

<td>"C.</td><td> +</td><td> +</td><td></td>

<td>Oh Ό</td><td>in</td><td> 09</td><td></td>

<td>uo</td><td>in</td><td>TZ</td><td></td>

‘2 £

<img file="PL176458B1_D0015.tif" />

so o \

<img file="PL176458B1_D0016.tif" />

€ β

N

Ό £

Λ

L

CC un σ \, _A

<img file="PL176458B1_D0017.tif" />

<img file="PL176458B1_D0018.tif" />

«J

N

Ό

C u u

Q09

La

<td>EC1 emu certificate</td><td>04 ABOUT AT</td><td>-swa</td>

<td>U&gt; what about&gt; »</td><td>+ CC</td><td></td>

<td>Uo?</td><td></td><td></td>

c3

N

T3

And u

· CL.

VI

176 458

<img file="PL176458B1_D0019.tif" />

CM O 'CM

WHAT

ABOUT'

CM

<td>u</td><td>Λ4 in</td><td>Λί IN</td><td>ul</td>

<td> +</td><td> 1</td><td> +</td><td> 1</td>

<td>σ&gt;</td><td>ω</td><td>uL</td><td>III</td>

<td>id</td><td>id</td><td>id</td><td>id</td>

<td>\from</td><td></td><td>\from</td><td></td>

<td></td><td></td><td>ul</td><td>O &lt;d</td>

<td></td><td></td><td> «1</td><td>fi Λ!</td>

<td>&lt;a jd</td><td></td><td>N AT</td><td>&lt;0 fi CO&gt; 1</td>

<td>c</td><td>ul</td><td>δ</td><td>-Η N CU&gt; 4</td>

<td></td><td> +</td><td>(rf</td><td>-ox</td>

<td>M</td><td>LU</td><td>«Ν</td><td>0 Ul</td>

<td>Λί</td><td>X</td><td>• l "ł</td><td></td>

<td>ul</td><td></td><td>CLL</td><td></td>

<td>sfc H</td><td>+ ul id</td><td>Well Mfgr</td>

<td> •</td><td></td><td>ul</td>

<td>fi</td><td></td><td>r4</td>

<td> 5</td><td></td><td>CU</td>

<td>ul</td><td></td><td>Ό</td>

<td></td><td>fi</td><td> 0</td>

<td> &amp;</td><td>and</td><td>Cu</td>

<td> ¢4</td><td>ul</td><td> 1</td>

<td></td><td></td><td>2σ&gt;</td>

<td>&lt;0 4d c</td><td>S -</td><td>isa; M</td>

<td> &gt;1</td><td></td><td>ol</td>

<td>N</td><td>S_co</td><td>Ό</td>

<td></td><td>AND^H</td><td> 0</td>

<td>Λί</td><td></td><td rowspan="2">CU</td>

<td>ul</td><td>from</td>

<td></td><td>Ό</td><td>&lt;TJ</td>

<td>&amp; -P</td><td> 4-&gt; 0</td><td>+ j H</td>

<td>In «ϋ</td><td>(d</td><td>(0 Φ</td>

<td>about *</td><td>Jd · Η</td><td>id H</td>

<td>U »H.</td><td>• Η 4d P</td><td>HO</td>

<td>^AT 44</td><td>UU fi Cn</td><td>44 H.</td>

<td> £ &gt;&lt;</td><td>&gt; i&gt; iU4</td><td>&gt; 1 ϋ</td>

<td>R +&gt;</td><td></td><td>P Ό)</td>

<td>® ti φ o</td><td></td><td>P (0 0) Art</td>

<td>* 3 U</td><td>At ul</td><td>L&gt; S</td>

176 458

<img file="PL176458B1_D0020.tif" />

<td>and 1&gt; 1 «3</td><td>1 &lt;d</td>

<td>P · Η</td><td>N g</td>

<td>&lt;ΰ 3</td><td> &gt;1</td>

<td>• rł &lt;0</td><td> 0 3</td>

<td> £ +»</td><td> 0</td>

<td>ω</td><td>&lt;d ε</td>

<td>P □</td><td>·· ΓΊ (L)</td>

<td> 0]</td><td>OO-P</td>

<td>Φ (fl 3</td><td>c 3 n</td>

<td>n rf tn</td><td>id + J&gt;</td>

<td>_ Ie cont</td><td> (0</td>

<td>(d N</td><td>Η -P</td>

<td>• P HJU</td><td>cum a</td>

<td>NC</td><td>Ό CO</td>

<td>ϋ Ό flj</td><td>OH V</td>

<td>0 0H</td><td>CU H</td>

<td>en e</td><td>m</td>

176 458

Τή.22

220

Version Number

Device Serial Number

Owner Name

Unique Owner ID

KS + owner

Date of purchase

Signature of Mfgr

-221

-222

-223

-224

- 225

176 458

239

<img file="PL176458B1_D0021.tif" />

New Admission Request Messages

176 458

Fg. 24

<img file="PL176458B1_D0022.tif" />

176 458

<td colspan="2">Fg.X</td>

<td>Version Number</td><td rowspan="2"> —254</td>

<td>The recipient's name</td>

<td>(Message Key) KE + odb (to recipient)</td><td></td>

<td>Name of the Recipient's Deposit Center (ecl)</td><td></td>

<td>(Recipient's Certificate Number) KE + ecl</td><td> —252</td>

<td>Recipient Employer Name la (empl la)</td><td> — 256</td>

<td>(Message Key, Recipient's Certificate No.) KE + empl la</td><td> —257</td>

<td>Recipient Employer Name 1b (empl 1b)</td><td> — 256</td>

<td>(Message Key, Recipient Certification No.) EC + empl 1b</td><td> —257</td>

<td>AND about •</td><td></td>

<td>Sender's name</td><td> —253</td>

<td>(Message Key) EC + Sender (to yourself)</td><td></td>

<td>Name of the Sender's Deposit Center (ec2)</td><td></td>

<td>(Sender's Certificate No.) KE + ec2</td><td> —251</td>

<td>Employer Name 2a Sender (empl 2a)</td><td> —255</td>

<td>(Message Key, Sender's Certificate No.) KE + empl 2a</td><td> —257</td>

<td> • • •</td><td></td>

<td>Sender Message Number</td><td></td>

<td>Message Abbreviation</td><td></td>

<td>Creation Time</td><td></td>

<td>Sender Device Signature</td><td> —258</td>

176 458 ko

<img file="PL176458B1_D0023.tif" />

ψ

<img file="PL176458B1_D0024.tif" />

<img file="PL176458B1_D0025.tif" />

176 458

ΟΟ

CM

<img file="PL176458B1_D0026.tif" />

οο

CM ώ

<img file="PL176458B1_D0027.tif" />

CM CM

176 458 α

ο

Η what

-Ζ £

&lt;

ο £

Η &lt;:

<img file="PL176458B1_D0028.tif" />

176 458 «

ο • * w * (Zł 'C

CU

-c

OS o-

<img file="PL176458B1_D0029.tif" />

UP Department of Publications. Circulation of 70 copies Price PLN 6.00.