CA2176032A1 - Cryptographic system and method with key escrow feature - Google Patents

Abstract

The invention provides a cryptographic system and method with a key escrow feature that uses a method for verifiably splitting users' private encryption keys into components and for sending those components to trusted agents chosen by the particu-lar users, and provides a sys-tem that uses modern public key certificate management enforced by a chip device that also self-certifies. In a preferred embodiment of this invention, the chip encrypts or decrypts only if certain conditions are met, namely, (1) if a valid "sender certifi-cate" and a valid "recipient certificate" are input, where "valid" means that the par-ticular user's private decryp-tion key is provably escrowed with a specified number of escrow agents and that the master escrow center is registered and certified by the chip manufacturer, and (2) if a valid Message Control Header is generated by the sender and validated by the recipient, thereby giving authorized investigators sufficient information with which to request and obtain the escrowed keys. A further preferred embodiment of this invention provides a method for generating verifiably trusted communications among a plurality of users, comprising the steps of escrowing at a trusted escrow center a plurality of asymmetric cryptographic keys to be used by a plurality of users; verifying each of said plurality of keys at the escrow center;
certifying the authorization of each of said plurality of keys upon verification; and initiating a communication from each of said plurality of users using a respective one of said plurality of keys contingent upon said certification.

Description

wo 95/19~72~ ` 2 1 7 6 0 3 2 r~ s o~ I
~ ~ =
CRYPTOGRAPHIC SYSTEM AND
METHOD WITH KEY ESCROW FEATURE
BACKGROUN~ QF T~ TNVENTION
This invention relates to cryptographic communication6 systems. More particularly, this invention relates to the secure generation, certification, storage and distribution 5 of cryptographic keys used in cryptographic communications systems. Still more particularly, this invention relates to a system of cryptographic key escrow and public-key certificate management enforced by a self-certifying chip device .
The development and proliferation of sophisticated computer technology and distributed data processing systems has led to a rapid increase in the transfer of information in digital form. This information is used in finAn~ ;Al and banking matters, electronic mail, electronic data inter-15 change and other data processing systems. Transmission of this information over unsecured or unprotected ; ra-tion ~hAnnPl s: risks exposing the transmitted information to electronic t:avt:sdLv~ing or alteration. Cryptographic communications systems preserve the privacy of these trans-20 missions by preventing the monitoring by unauthorizedparties of messages transmitted over an insecure channel.
Cryptographic communications systems also ensure the integrity of these transmissions by preventing the altera-tion by unauthorized parties of information in messages 25 transmitted over an insecure channel. The cryptographic ; cations systems can further ensure the integrity and authenticity of the transmission by providing for recognizable, unforgeable and document-~lPrPn~lPnt digitized signatures that can prevent denial by the sender of his own 3 0 message .
Cryptographic systems involve the encoding or encrypting of digital data transmissions, including . _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _, . _ Wo95/19672 21 7 6 032 r~ c I ~
digitized voice or video transmissions, to render them ;nl ehensible by all but the intended recipient. A
plaintext message consisting of digitized sounds, letters and/or numbers is encoded numerically and then encrypted 5 using a complex mathematical algorithm that transforms the encoded message based on a given set of numbers or digits, also known as a cipher key. The cipher key is a sequence of data bits that may either be randomly chosen or have 6pecial mathematical properties, ~lorontq;n~ on the algorithm 10 or cryptosystem used. Sophisticated cryptographic algorithms implemented on computers can transform and manipulate numbers that are hundreds or thousands of bits in length and can resist any known method of unauthorized decryption. There are two basic classes of cryptographic 15 algorithms: symmetric key algorithms and asymmetric key a lgorithms .
Symmetric key algorithms use an identical cipher key for both encrypting by the sender of the communication and decrypting by the receiver of the ; c~tion. Symmetric 20 key cryptosystems are built on the mutual trust of the two parties sharing the cipher key to use the cryptosystem to protect against distrusted third parties. The best known ~iy ~ ic key algorithm is the National Data Encryption Standard tDES) algorithm first published by the National 25 Institute of Standards and Technology. See Federal Reaister, Nar. 17, 1975, Vol. 40, No. 52 and Aug. 1, 1975, Vol. 40, No. 149. The sender cryptographic device uses the DES algorithm to encrypt the message when loaded with the cipher key (a DES cipher key is 56 bits long) for that 30 session of communication (the session key). The recipient cryptographic device uses an inverse of the DES algorithm to decrypt the encrypted message when loaded with the same cipher key as was used for encryption. However, the adequacy of symmetric key cryptosystems in general has been 35 questioned because of the need for the sender and the recipient to exchange the cipher key over a secure channel to which no unauthorized third party has access, in advance of the desired communications between the sender and

2 l 7 6 0 3 2 recipient . This process of f irst securely exchanging cipher keys and only then encrypting the communication is often slow and cumbersome, and is thus unworkable in situations requiring spontaneous or unsolicited communica-5 tions, or in situations requiring communications betweenparties unfamiliar with each other. Noreover, interception of the cipher key by an unauthorized third party will enable that party to eavesdrop on both ends of the encrypted conversation.
The 6econd class of cryptographic algorithms, asymmetric key algorithms, uses different cipher keys for encrypting and decrypting. In a cryptosystem using an a~y L.ic key algorithm, the user makes the encryption key public and keeps the decryption key private, and it i5 not 15 feasible to derive the private decryption key from the public encryption key. Thus, anyone who knows the public key of a particular user could encipher a message to that user, whereas only the user who is the owner of the private key corrPcr~n~l; n~ to that public key could decipher the 20 message. This public/private key system was first proposed in Diffie and Hellman, "New Directions in Cryptography, "
IEEE Transactions on Information Theory, Nov. 1976, and in U.S. Patent No. 4,200,770 (Hellman et al.), both of which are hereby incorporated by ref erence .
An early type of asymmetric key algorithm allows secure communication over an insecure channel by inter-active creation by the communicating parties of a cipher key for that session of communication. Using the asymme-tric key algorithm, two interacting users simultaneously and im4r-rPnri~ntly generate a secure cipher key that cannot be deduced by an eavesdropper and that is to be used C,Y LL ically to encode that session of communications between the users. This interactive method of generating a secure cipher key was described by Diffie and Hellman in their 1976 paper. Under this prior art method, known as the Interactive Diffie-Hellman scheme, shown in FIG. 2, each of the two users A, B randomly chooses a secret number 21,22 and then computes an int~ iAte number 23,24 using Wo 95/19672 2 1 7 6 0 3 2 PCT/US95/00531 two publicly-known numbers and the secret number 21, 22 chosen by that user. Each user next transmits the inter-mediate number 23, 24 to the other user and then computes the secret (symmetric) cipher key 25 using his own secret number 21,22 and the intermediate number 24,23 just received from the other user. The interactively generated cipher key 25 is then used symmetrically by both users as a DES or other ~y I~L iC cipher key to encrypt and decrypt that session of commurlications over an otherwise insecure channel in the manner of symmetric key algorithm communi-cations . This interactive process requires only a f ew seconds of real time, and all digital communications, including digitized sound or video transmissions, in a particular session can be en~;Ly~1_ed merely by pushing a button at the outset of a session to initiate the inter-active key exchange process. Because all the numbers chosen in the Interactive Dif f ie-Hellman key generation scheme are very large, the computations are infeasible to invert and the secret cipher key cannot be computed by an elve2,dL~yer, thus preserving the privacy of the communi-cation. Because the computations are infeasible to invert, each user knows that any communication received using this algorithm was not altered and could have been sent only by the other user, thus preserving the integrity and authenticity of the communication. This interactive key exchange method, however, requires the parties to interact in real time in order to create the cipher key and may not be useful for unsolicited communications or unfamiliar parties . In particular, the Interactive Dif f ie-Hellman key exchange scheme does not work for store-and-forward electronic-mail style messaging or f or long-term storage of ts in an electronic data storage system, because the recipient is not on-line to negotiate the session key.
A modified, non-interactive form of the Diffie-Hellman scheme, known as Certified Diffie-Hellman, can be used when the communicating parties are not on-line together. The initial, certification step of the Certified Diffie-Hellman se6sion key generation scheme is shown in FIG. 3. One WO 95/19672 2 1 7 6 0 3 2 ~ 3~
user, the recipient-to-be, randomly choose6 a secret number 31 (his private key) and then computes an intr- ; Ate number 33 using two publicly-known numbers 32 and the secret number 31 chosen by that user. That user then sends 5 proof of identif ication along with the intermediate number and the two public numbers, which numbers together form his public key 34, to a certifying authority that then issues a public key certificate 35 digitally signed 36 by the issuing certifying authority binding the user's identity to 10 the user's Diffie-Hellman public key information 34. The public key 34 publicized by that user remains the same until he decides to rekey and choose another private key 31. Messaging using the Certified Diffie-Hellman method is 6hown in FIG. 4. In order to transmit a message to that 15 user, a sending user first obtains the receiving user's certificate 35 and verifies the certifying authority's signature 36. The sender next computes the session key 42 for that c ication session using the recipient's intr~ te number 33 (from the recipient's certificate) 20 and the sender's own secret number 41 (his private key), which he chooses at random. The sender then encrypts a message 43 using the session key 42 and places his own intrr~ te number 40 unencrypted at the head of the i cation. ~pon receiving the ~ ; r!~Ation, the 25 recipient computes the session key 42 using the sender's unencrypted int~ ; A te number 4 0 and his own secret number 31 (or private key), and then uses the session key 42 to decrypt the message 43. As with the Interactive Diffie-Hellman scheme, the session key generated in the 30 Certified Diffie-Hellman scheme is then used by both parties to encrypt and decrypt communications during that session over an otherwise insecure channel using a conventional symmetric algorithm, such as DES. The Certified Diffie-Hellman scheme, however, requires that a 35 trusted entity or a certifying authority sign the receiving user's public key certificate so that a sending user can trust that the information contained within is correct. In addition, the private key randomly chosen by the sender, Wo 95/19672 2 1 7 6 0 3 2 r~
.
with which he computes both the session key and the intermediate number for that r nmm~-nil-~tion~ must not be identical to the private key that i5 connected to the sender's own public key certificate; in order to avoid 5 others learning his permanent private key numbers (~;u~ LQ~ i n~ to the public key numbers that have been certified), the sender should keep them distinct from any Qrh~ 1l1 private keys or int~ te numbers that are generated only for specific messages.
Another asymmetric key algorithm, named the RSA
algorithm after the inventors Rivest, Shamir and Adleman, is described in U.S. Patent, No. 4,405,829 (Rivest et al.), which is hereby incorporated by reference, and involves the difficulty of factoring a number that is the product of two 15 large prime numbers . As with the Interactive Dif f ie-Hellman scheme, the RSA algorithm is relatively straightforward to compute but practically infeasible to invert. Thus, it is not feasible to derive the private key from the public key and, in this way, the privacy of the 20 communication is preserved. Once a message is encrypted with the public key using the RSA algorithm, only the private key can decrypt it, and vice versa. As with the Certified Dif$ie-Hellman scheme, the RSA algorithm requires a trusted entity to certify and publicize the users' public 25 keys. In contrast to ]~oth Diffie-Hellman schemes, however, the RSA algorithm does not itgelf generate a "session key"
to be used symmetrically by the parties. Instead, the public encryption key f or a particular user directly encrypts c ~icAtion~ to that u5er and that user'5

3 o private decryption key decrypts those communications encrypted with the user's public key. In this way, the RSA
algorithm is a pure asymmetric key algorithm.
However, because the RSA algorithm is complex and involves .:~uu~ iation of the me5sage by very large 35 numbers, encrypting or decrypting a message of even moderate length using the RSA algorithm requires a great deal of time. Thus, it is much simpler, faster and efficient to use the RSA asymmetric algorithm to transport _ _ _ _ _ _ _ _ _ _ _, . _ _ .. _ .. . _ . _ .. . . . . . . . .... .

~WO9~/19672 21 76032 , "" ~, a DES cipher key f or use in a :.y LL ic algorithm . This prior art mode of operation is known as RSA key transport and is shown in FIGS. 5 and 6. For example, referring to FIG. 5, a user could generate a random DES key 51 and 5 encrypt a message 52 with that DES key. The user would then encrypt the DES key 51 with an intended receiving user's public RSA encryption key 53 and transmit the DES-encrypted message 54 along with the RSA-encrypted DES key 55 to the receiving user. After receiving the 10 transmission, as shown in FIG. 6, the recipient decrypts the DES key 51 using his private RSA decryption key 56 and uses that DES key 51 to decrypt the message 52. Because the DES algorithm reguires much less time and expense to compute than does the RSA algorithm, the symmetric DES key 15 is used to encrypt and decrypt the actual message, while the a2,y LL 1C RSA keys are used to encrypt and decrypt the ay ' ic DES key.
The RSA public/private key cryptosystem also provides for a digital "signature" that is both message dependent 20 and signer rlPrPnrlPnt, and can be used to certify that the received message was actually sent by the 5ender and that it was received unaltered. RSA digital signature is based on the additional property of RSA that, in addition to allowing the user's private key to decrypt only those 25 ~ ;cations encrypted using that user's public key, permits a user's private key to encrypt messages that can be decrypted only by that user's public key. Because only the user has the private key, use of the private key to encrypt allows for proof of origin that can be verified by 30 anyone with access to the user's public key. In practice, the sender f irst uses his private key to encode the message text into a signed message, which can be decrypted by anyone but could have come only from the sender. If desired, the sender may then optionally use the recipient's 35 public encryption key to encipher the signed message to be transmitted. Upon receipt of the ciphertext, the recipient decrypts the ciphertext with his private decryption key, if n~CPcSAry~ and decodes the signed message with the sender's _ _ _ _ _ _ _ _ _ _ _ _ . _ .. ..

WO 95/19672 2 1 7 6 0 3 2 PCT~S95/00531 public encryption key. secause only the sender knows his unique private key, only the sender could have sent the particular "signed" message; the signature thus verifies the identity of the sender. Also, because the recipient 5 ha6 only the sender's public key, the sender cannot claim that the recipient or an unauthorized third party altered or fabricated his message; the signature thus prevents repudiation of the message by the sender. Furthermore, because only the sender's private key transforms the lO original message and only the sender knows his unique private key, neither the recipient nor an unauthorized third party could have altered the message; the signaturQ
thus certif ies the integrity of the message .
The RSA algorithm also provides for another type of 15 digital signature that uses a hashing function to create a short message digest that is unique to each document.
FIGS. 7 and 8 show RSA signature creation and RSA signature verification, respectively, using a hashing function. A
hashing function is another complex mathematical algorithm 20 that is "one-way, " i.e. so that it is infeasible to reconstruct the document from the hash result, and is "collision-free," i.e. so that it is infeasible to produce another document that will hash to the same digest. As shown in FIG . 7, the sender f irst passes the message 72 25 through a haæhing algorithm 73 to produce the message digest 74 and then encrypts the digest with his RSA private key 75, forming a compact digital signature 76 that is attache~d to the message 72. After receiving the transmission of the message 72 and the message digest 76, 3 O as shown in FIG . 8, the recipient decrypts the sender ' 8 RSA
encrypted message digest 76 (the digital signature) using the sender's RSA public key 77. The recipient also uses the same hashing algorithm 73 to produce a message digest 74 ~rom the received message. The two message digests 35 resulting from the two transformations performed by the recipient should be identical, thus verifying that the message was signed by the sender.

WO 95119672 ~ 2 1 7 6 0 3 2 .
Another system of digital signature, called DSA for Digital Signature Algorithm, may also be used for sender verif ication . The DSA Algorithm was disclosed in U . S .
Patent Application Serial No. 07/738,431, which is hereby 5 incorporated by ref erence in its entirety . The DSA
Algorithm has properties that are similar to those of the RSA signature algorithm in that the sender passes the message through a hashing algorithm to produce a message digest and then encrypts or signs the message digest using 10 his private key; the recipient verifies the encrypted digest using the sender's public key. However, unlike the RSA signature algorithm that returns the original message digest when the recipient decrypts the signature block, the DSA verification algorithm results only in a positive 15 confirmation of the validity of the signature;
communications encrypted using an intended recipient's public key cannot later be recovered by decryption with the recipient's CULLel 1JV~ ;ng private key. For this reason, the DSA algorithm may be used ~uite capably for digital 20 siyl,~LuLes, but not for key transport or for direct message encryption .
In order for the public/private key system to operate efficiently, users must trust a centralized key certifying authority to be responsible for publicizing and updating a 25 directory of public encryption keys. The key certifying authority must be trusted by all users, both senders and recipients, to distribute the correct public keys for all users so that no r~ are transmitted to unintended recipients. To this end, as discussed above and elaborated 30 below, the certifying authority would distribute each user's name and public encryption key information, and would affix its own digital signature to the distributed information in order to certify the correctness of the information. ~owever, when more than one entity, or a 35 hierarchy of entities, is involved in the certification process, there are several different methodologies or "trust models" for clet~rm;n;n~ how a user will process the certificates. The three main models are (1) a pure _g_ .

Wo 95/19672 2 1 7 6 0 3 2 PCT/US95/00531 hierarchical model, (2) a model using cros6-certification between multiple hierarchies, and ( 3 ) a " local trust"
model. These models are described in detail in the standards ~lo ~ American National Standard X9.30, 5 "Public Key Cryptography Using Irreversible Algorithms for the F;nAnrjAl Services Industry: Part 3: Certificate Management f or DSA" (American Bankers Assn ., Washington , D.C., 1992), which is hereby incorporated by reference in its entirety. Although there is not yet a general 10 consensus as to which of the a~uv~ ntioned trust models is best, it i5 assumed throughout this disclosure that an appropriate, generally accepted certification trust model will be established and adhered to whenever certif icates issued by more than one entity are involved.
The public/private key system described above takes into account the privacy interests of the users who wish to transmit and receive communications privately. In addition, however, there are also the law enforcement and national security interests of yUV~::r nts to be 20 cnn~ ~ed. The ability of the yUV~L -- L to monitor or eaves.lLu~ on otherwise private electronic transmissions for law enfuI L and national security purposes must be preserved so that suspected criminals, terrorists and foreign spies are not permitted to conspire beyond the 25 reach of the law. Whereas telephone communications can be monitored through wiretapping, cryptographic algorithms make the enciphered data unable to be deciphered even by powerful code-breaking computers. The increase in the volume and percentage of digital and digitized trans-30 missions encrypted with advanced algorithms will, there-fore, serve to frustrate and thwart the lawful ~uv~ ~nt electronic surv~; l l Anre of these communications, especially if cryptographic devices are widely implemented in telephones, computers, facsimile r-~-h;n~ and all other 35 data processing equipment.
One way to enable the U,UV~::L L or other authorized investigators to monitor communications of suspected criminals is to require all users of cryptographic .. ., . . . . , _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Wo 95/l9672 2 1 7 6 0 3 2 PCTIUS95100~31 communications to escrow their private decryption keys with either a private authority or the government, i.e. allow either the private authority or the government to be the trusted custodian of the users ' priYate decryption keys .
5 When n"-F,cs;-ry for 6urve;llAn~p~ the ~-.)Vt:l -nt then will have acces6 to or will be able to gain access to the private keys in order to monitor all encrypted communica-tions. This method, however, is unworkable because it contains insufficient safeguards against abuse by the lO y~v~L ~ of the private decryption keys and against possible leaking of the private decryption keys to unauthorized third parties either by theft from the (~OV-L -nt or the private authority or by corruption of y~)v_L -nt or private authority personnel.
Another method of escrowing private decryption keys to preserve both user privacy interests and law enf~ L
security interests is by using a system such as the method described in "Fair Public Key Cryptosystems, " proposed by silvio Micali at CRYPTO 92 in March 1993 and p--hl i Ch~d by 20 the Laboratory for Computer Science of the MAqca~-hllcettS
Institute of Technology on October 13, 1993, and in U.S.
Patent No. 5,276,737, both of which are hereby incorporated by reference. By this method, shown in FIGS. 9-11, a user who wishes to certify his public key for encryption 25 purposes must escrow his private key in the following manner . As shown in FIG 9, the user f irst breaks his private key 91 into several "pieces" 92, each of which can be individually verified 9O to be a valid part of the complete private key 91. The private key can be 30 reconstructed only with knowledge of all the pieces or some specified number of them. The user then sends 93 each piece to a different escrow agent or agency 94, who, as shown in FIG. lO, verifies 95 the piece as a correct part of the private key 91 using a special algorithm and 35 ,_ icates this verification 96 to a master escrow center. Referring to FIG. 11, after receiving verification 96,97 that each piece of the private key is correct, the master escrow center can then issue a certificate 98 for Wo 95/19G72 2 1 7 6 0 3 2 PCTIUS95/00531 the user's public key 99, allowing it to be used in a privacy sy6tem with the assurance that, if need be 2nd pursuant only to a warrant or court order, law enf orcement agencies will be able to obtain the 6ecret pieces of the private key from the user'6 cho6en e6crow agents, recombine them and monitor the ; c ~tions of that user. By thi6 6y6tem, u6er6 can be a66ured of the privacy of their encrypted transmissions, and g~ver nt can be assured of its ability to gain access to encrypted transmissions upon a 6howing of need. Because no one entity normally ever ha6 access to the complete private key and because the u6er chooses entities that he trusts, the chances of unlawful or corrupt actions are greatly reduced. Also, because a wider range of entities would be eligible as escrow agents, the chances of simultaneously compromising all the escrow agents, and thereby disrupting all trusted commerce, is even further reduced.
The ma6ter e6crow center, as a trusted authority certifying the authenticity of the u6er'6 public key, periodically i66ues a publicly-available certificate attesting or notarizing the connection between the public encryption key and its owner's identifying information.
The certif icate of authenticity assure6 the 6ender that tran6missions to that named public key u6er will in fact be received and read only by the intended recipient. The certificate is usually in an internationally recognized electronic format, such as the one 6pecified in CCITT
R~ tion X. 509 and i66ued a6 an international standard by the International Standards Organization lISO).
An example of a public encryption key e6crow certificate format i6 shown in FIG. 12. The certificate contain6, among other thing6, the name of the organization or key management center that created the certif icate (the i66uer) 121, the owner'6 public key 122, the owner's identifying information 126, a certificate serial number 123, and validity starting and ending dates 124. The issuer's digital signature 125 "seals" the certificate and prevents its alteration.

W0 95119C72 2 1 7 6 0 3 2 r~ O7~.c - -The U.S. U~UVt:L -nt, however, has proposed as a UOV~:L -nt (and possible industry) standard another method to enable it to escrow private decryption keys and to monitor communications. The U.S. guv~L -nt has developed 5 a microcircuit, called the "Clipper chip, " that can be built into ~,IVt:L ~ and commercially-produced telephones and computer devices. The Clipper chip is a low-cost chip that may be used f or bulk encryption and key management;
the Capstone chip is a more advanced version of the Clipper 10 chip that adds digital signature and message digest capabilities. Like other encryption systems, the Clipper chip uses a symmetric encryption algorithm, albeit a classified algorithm called Skipjack, that scrambles telephone and digital computer data communications in a 15 manner similar to DES, but using an 80-bit key. Each Clipper chip has a unique serial number, a Clipper family key common to all Clipper chips and its own ~y ic private device key that will be needed by authorized yuv~:L -nt ;~gpnrip~ in order to decode r- ~agPc encoded by 20 a device containing the chip. When the device containing the chip is manufactured, the unique private device key will be split into two ~ ---nts (called "key splits") and deposited separately with two key escrow data bases or agencies that will be established within the yuv~L L.
25 Law enfuL ~ agents can gain access to these private device keys by obtaining a warrant or other legal authori-zation to wiretap or monitor the communications and by presenting the warrant to the two escrow agencies.
When users of Clipper chip devices wish to 30 communicate, they first agree on a symmetric session key with which to encrypt the communications. Any method of deriving the symmetric session key, such as Interactive Diffie-Hellman key derivation process, and any method of transporting the DES session key between users, such as RSA
35 transport, may be used. At the start of each ~ ; ~a-tion, each user sends to the other a Law Enforcement Access Field (LEAF) that contains enough information to allow law enfuL. ~ L agents to wiretap or monitor the communication.

wo g5/19672 ~ 2 1 7 6 0 3 2 PCT/US95100531 .
The believed format of the Clipper LEAF is shown in FIG. 13 (note that because the precise details of the LEAF format, creation and verif ication are currently classif ied " secret"
by the U.S. s~uv~ -nt, this tl;~c~1~5ion and FIG. 13 are 5 both somewhat speculative). To form the LEAF, the session key is first encrypted using the private device key; then the device-key ~ y~ed session key, the sender device's serial number and a ~h~rl'~11m (a verifying value) of the original unencrypted session key are together encrypted lO with the Clipper family key to complete the LEAF. The message is then encrypted using the chosen session key.
The session-key-encryp~ed message and the family-key-encrypted LEAF are together transmitted to the recipient.
Upon receiving the communication, the receiving user first 15 loads the received LEAF into his Clipper chip in order to check whether the LEAF is valid and whether the session key encrypted within the LEAF matches the session key previously received. If the LEAF is valid, the Clipper chip will decrypt the message with the chosen session key 20 that was previously received.
A law enfuL. L agent lawfully wiretapping or monitoring the communication, however, does not know the session key and thus must f irst decrypt the LEAF in order to obtain the session key. The agent intercepts the 25 desired LEAF, decrypts it using the Clipper family key and then presents the chip serial number from the LEAF and a court-ordered warrant or other legal authorization to the two y~.v~ L escrow agents, receiving in return the two key splits of the wire-tapped user's private device key.
30 The agent combines the two escrowed device key components and uses the resulting device key to decrypt the device-key-encrypted session key from the LEAF. The session key can then be used to decrypt the actual messages from the communications. The requirement that the sender and 35 recipient each create a LEAF and validate the other's LEAF
insures that law enf~L~ ~ agents will have a reasonable chance at intercepting the LEAF, since each LEAF is expected to pass betw~een the users over the same communica-WO 95/~9672 2 1 7 6 0 3 2 PCTIUS9SJ00531 tions medium. Further, it allows law enforcement toselectively monitor only one suspected user by decrypting the LEAF generated by that user, regardless of which user originated the communication.
Unfortunately, there are many technical problems with the yuv~ ' s Clipper chip proposal, mostly stemming from the fact that the private keys to be escrowed are p~ ly PTnh~dded in the Clipper chips during manufac-ture. Because the private encryption key for a particular device is burned into the chip and cannot be changed, the chip and probably the entire device that contains it must be discarded if compromised. It is preferable for the user of a particular device to be able to rekey, reescrow and recertify the device at will if ~ e is suspected or at regular intervals to avoid potential compromise. In addition to the inability of the user to rekey and reescrow, the user of the Clipper device has no choice of the number or the identities of the key escrow agents employed by the yOvt:L ~ to safeguard his private key.
Instead, the private key splits are deposited in two escrow data bases or agencies established by the yUYt:L -nt.
Users may not trust the Clipper chip devices due to the risk that the y~Jve:L ~ may have complete access to any tr~n~ ion or transaction through the device, access that could be abused or corrupted. Users may also desire that their keys be escrowed with more trustees than the govern-ment provides, in order that their private keys will be more secure. If the concept of key escrow is to have significance, each user must be able to choose his own 3 0 trustees with whom to escrow his private keys, based upon the level of trust desired.
Also, it is believed that the government Clipper system allows users to communicate only ~y Lically and in real time, and does not provide any direct support for store-and-forward electronic-mail type messaging. Prior to encrypting communications, the sender and recipient must f irst agree on a ~y ~L iC session key with which to encrypt the communications. Typically, this key exchange Wo 95/19G72 2 1 7 6 0 3 2 PCT/US95100531 is done using the Interactive Diffie-Hellman scheme, the only key exchange method believed to be supported by the Clipper chip. Thus, unless they wish to arrange their own key management system, users are restricted to 5 6imultaneous, interactive 1; ~ations, such as real-time voice or facsimile communications. In order to use store-and-forward electronic-mail type messaging, however, a user must be able to access the intended recipient's public key, such as by using a Certified Diffie-Hellman or a certified lO RSA key transport scheme, even if the intended recipient is not available for an interactive on-line communication.
Because it is believed that the u,uvc, nt~s Clipper system does not facilitate this, store-and-forward messaging is difficult. The government's proposed standard system thus 15 may tend to limit the communications capabilities of users to on-line interaction.
Moreover, under the ~uvc-~ -nt system, the users' employers have no access to the encrypted data or transmis-sions of their employees. Employers, on whose behalf the 20 employees are developing, communicating or transmitting confidential or proprietary data, must retain the right to gain access to their employees ' data or transmissions .
Many situations could arise wherein encrypted information would be available only to the specific employees directly 25 engaged in using the cryptographic systems and not to the management or boards of directors who are responsible for those employees and who own the corporate data rcsuur u es.
By encrypting data or communications, employees could develop or appropriate f or themselves new programs, pro-30 ducts and technologie~ or could conduct illegal activitiesand transactions, all without their employers' knowledge.
Also, - ~ c L or reorganization of staf f and changes of storage facilities could result in the loss of massive amounts of information that was important enough at the 35 time of encryption to be encrypted. See Donn B. Parker, "Crypto and Avoidance of Business Information Anarchy"
(Invited speaker presentation at First Annual AC Conference on Computer and Communication Security, November 3-5, 1993, W0 95/19672 2 17 6 0 3 2 r~ J c c .
Reston, VA), which is hereby incorpor~ted by reference.
Aside from the originator of the data ~r the sender of the transmissions, the Clipper chip allows only the government to have access to the transmissions. Although employers 5 could seek a court-issued warrant in order to monitor their employees ' ~ tions, employers may wish to monitor their internal officers in a more discreet fashion than by initiating a f ederal investigation any time suspicion is aroused .
Furtht- ~, mandating a classified algorithm that is ~m-~trlrlr~rl in the chip and thus available only in hardware and only from yuY~:L ~-authorized chip manufacturers injects the ~UVC:L ^-lt into the rapidly changing and highly competitive market f or communications and computer hardware. A yuv L L agency or a yuv~L -nt-authorized manufacturer may be unable or unwilling to design and market advanced devices and products specially tailored for particular companies as would a private manuf acturer . If the yuv~~ authorizes only certain vendors to manufac-ture the chips having the classified algorithm, competition will be reduced and the technology will be prevented from being inC~L~uLc-ted into other products. Additionally, because the details of the Skipjack algorithm have not been made public, suspicion has arisen as to whether the algorithm could be insecure, due either to an oversight by its designers or to the deliberate introduction by the yuvl L of a trap door. An important value of crypto-system design is that the privacy and security of the encrypted messages should depend on the secrecy of the relevant key values, not on the secrecy of the system's details .
It is, therefore, desirable to provide a commercial - key escrow system that uses published algorithms, operates in a manner that inspires the users' trust and confidence, - 35 and solves the problems posed by national security and law enf Ol . L demands .

Wo 9S/19672 2 1 7 6 0 3 2 p~ "~
.
It i5 also desirable to provide a commercial key escrow system that uses priYate keys that may be changed by the user at will or at regular intervals.
It is further desirable to provide a commercial key 5 escrow system that allows the user to choose the key escrow agents to safeguard his private key or the separate pieces of his private key.
It is still further de6irable to provide a commercial key escrow system that contains safeguards against 10 ullL~aLLicted ~uv~ ~nt access, yet allows access by the employers of the users or by the countries of which the foreign users are citizens.
It is also desirable to provide a commercial key escrow system that offers an alternative to the U.S.
15 Guv, L's proposed Clipper chip system.
STTMMARY OF THE INVENTION
It is one object of this invention to provide a commercial key escrow system that uses published algorithms, operates in a manner that inspires the users ' 20 trust and confidence, and solves the problems posed by national security and law enfuL. L demands.
It is another obj ect of this invention to provide a commercial key escrow system that uses private keys that may be changed by the user at will or at regular intervals.
It is a further object of this invention to provide a coTnmercial key escrow system that allows the user to choose the key escrow agents to saf eguard his private key or the separate pieces of his private key.
It is still a further object of this invention provide a commercial key escrow system that contains safeguards against ullLeaLLicted yuv~l L access, yet allows access by the employers of the users or by the countries of which the foreign users are citizens.

~W09sll9672 2 1 76032 I~ J~
It i8 yet another obj ect of this invention to provide a commercial key escrow system that of f ers an alternative to the U.S. G~V_L L's proposed Clipper chip system.
These and other objects of the invention are accomp-5 lished in accordance with the principles o~ the inventionby providing a cryptographic key escrow system that uses a method, such as the Micali "Fair" escrow method, for verif iably splitting users ' private encryption keys into Ls and f or sending those components to trusted 10 agents chosen by the particular users, and by providing a system that uses modern public key certificate management, enforced by a chip device that also self-certifies. In a preferred Pmho~l;r t o~ this invention, the new chip encrypts or decrypts only if certain conditions are met, 15 namely, ~1) if a valid "sender certificate" and a valid "recipient certificate" are input, where "valid" means that the particular user's private decryption key is provably escrowed with a specif ied number of escrow agents and that the master escrow center is registered and certif ied by the 20 chip manufacturer, and (2) if a valid Message Control Header is generated by the sender and validated by the recipient, thereby giving authorized investigators suffi-cient information with which to request and obtain the escrowed keys. Because this invention relies upon a system 25 of certificate management, it can be made very flexible and ;n/l~-r~nrl~nt of location and time, unlike purely on-line systems . The methods f or escrowing a private decryption key and receiving an escrow certificate are also applied herein to a more generalized case of registering a trusted 30 device with a trusted third party and receiving authori-zation from that party enabling the device to communicate with other trusted devices.
A further preferred ~mho~l; L of this invention provides a method for generating verifiably trusted 35 c ; cations among a plurality of users, comprising the steps of escrowing at a trusted escrow center a plurality of asymmetric cryptographic keys to be used by a plurality of users; verifying each of said plurality of keys at the Wo 9S/19672 - 2 1 7 6 0 3 2 P~
escrow center; certifying the authorization of each of said plurality of keys upon verification; and initiating a communication from each of said plurality of u6ers using a respective one of said plurality of keys contingent upon 5 6aid certif ication. Further embodiments of this invention provide for ~lc.ro~; n~ o:E communications by authorized law enf orcement agents, based upon use of the Message Control Header included with each communication, using a special law enfuL~ - t decoder box and auditing of the law lO enfu~, ~ wiretaps to prevent abuse by law enfuL
and other officials. Further preferred embodiments provide for rekeying and upgrading of device firmware using a certificate system, and encryption of stream-oriented data.
BRIEF DESt~RTPTIQN OF THE DRAWINGS
The above and other objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the "~ nying drawings, in which the reference characters refer to like parts throughout and in which:
FIGS. lA - lG are lists of symbols and abbreviations that are used in the f igures of this invention;
FIG . 2 is a f lowchart showing the steps of the prior art Interactive Dif f ie-Hellman key derivation method;
FIG . 3 is a f lowchart showing the steps of the certification portion of the prior art Certified Diffie-Hellman method;
FIG . 4 is a f lowchart showing the steps o~ the messaging portion of the prior art Certified Diffie-Hellman method;
FIG. 5 is a flowchart showing the steps of encryption using the prior art RSA key transport method;
FIG . 6 is a f lowchart showing the steps of decryption using the prior art RSA key transport method;
FIG . 7 is a f lowchart showing the steps of signature creation using the prior art RSA method;

~Wo95119672 21 76032 r~ c- I
FIG. 8 is a flowchart showing the steps of si~nature veriication using the prior art RSA method;
FIGS. 9-11 are flowcharts that together show the steps of the prior art Micali key escrow process;
FIG. 12 i5 an example of the format for a prior art public encryption key escrow certificate;
FIG. 13 is an example of the believed format of the Clipper device Law Enfu, I_ Acces6 Field (LEAF);
FIG. 14 is an example of the format for a device certif icate issued by the manuf acturers of the device of the present invention;
FIG . 15 is a f lowchart showing the steps of a method of verif iably escrowing a key with only one escrow 2~,gent;
FIG. 16 is a flowchart showing the steps of a method of verifiab~y escrowing a key, ba6ed on the tru6ted device alone;
FIG . 17 is a f lowchart showing the steps of a method of 6ending an encrypted message with a Nessage Cont~rol Header (MCH);
FIG. 18 is an example of a MCH in RSA key transport format;
FIG . 19 is a f lowchart showing the steps of a method of receiving an encrypted message with a MCE~;
FIG . 2 0 is an example of a NCI~ decoder box and a flowchart for its process flow;
FIG. 21 is an example of a self-certifying trusted timestamp device;
FIG. 22 is an example of the format for a device owner certificate issued lly the manufacturer of the device of the present invention;
FIG. 23 is a flowchart 5howing the 5tep5 of a method of rc ~ ing a key (rekeying) by the owner of the device of the present invention; and Wo 95119G72 2 1 7 6 0 3 2 PCI/US95/00531 ~
FIG. 24 is a flowchart showing the 6teps of a method for regi6tration of the trusted device of the present invention with a trusted third party.
DT~TTT~n DES~ RTPTION OF TEIE INVENTION
Public key cryptosystems, including the use o~ digital 6ignatures, can potentially be the cornerstone of the creation of national, or even global, paperless electronic ~ln_ ~ ~,, 6y6tQms. Use of these systems will have enormous commercial signif icance in terms of cost5 5avings . The critical element in the development and widespread acceptance of these systems is the reliance placed upon the underlying cryptosystems and the digital 5ignatures by governments, banks, corporation5 and other u5er5, including individual users. Reliance on the5e systems should arise not from trust by each user of its own internal system or of other users, but rather from trust by each user of the public key cryptosystem and of the certification r-^h~ni! -it provides. The commercial crypto5ystem of the present invention 6atisf ies these concerns by using self -certifying 20 and, therefore, trusted, encryption devices as the impartial arbiters of trust.
In a preferred Drlnorl;---nt of the present invention, the tamper-resistant c1lip, or a tamper-resistant trusted device containing the chip, that performs the encryption, 25 decryption and digital signature is o~nhP~ Dd with a non-modifiable public/private 5ignature key pair unique to that chip and with a "manufacturer's certificate." The D~h~A~D~
manufacturer's certificate enable5 the device containing the chip (a) to digitally "sign" dol Ls and ~ ; ca-30 tions ("data structures") u5ing it5 own private devicesignature key proving that they uniquely originated from that device and (b) to prove by app~n~l;n~ the manufac-turer's certificate to documents and communications that those data structure5 can be trusted because the 35 originating device is one of known and trusted type and is made by that trusted manuf acturer . The manuf acturer ' 5 certif icate in ef f ect say5, "The deYice who5e private key ~ WO g~/19672 2 1 7 6 0 3 2 r~
matches the public key certif ied herein is of type XXX .
Signed, Manufacturer. " Because the private signature key is PmhpA~lpd in a tamper-resistant manner and because the manufacturer is trugted, ~ln_ ts and communications 5 issued by the device and signed using the private signature key will also be trusted.
A preferred PmhO~i ~ of the present invention contains eight major phases of use: (1) creation or manufacture of the chips contained in the device, (2) lO registration of the device's encryption key with escrow agents, (3) normal encryption and decryption of user message6, (4) deco~l;n~ of communications by authorized law enful. ~ agents, (5) rekeying and upgrading of the device by the owner or employer, (6) auditing of law 15 enforcement wiretaps, (7) encryption of stream-oriented data, and ( 8 ) national security saf eguards .
M~nl]facture of the Tr~l~ted Device Manufacture of trusted devices of the present invention is based on the presence of the following general 2 0 f eatures:
(1) An Pmhp~ pd microprocessor (or mi~:Locu,-~Luller), a miniature computer that mediates all outside access and perf orms various computational and y~ UyL ~,.,",ing operations;
(2) An optional cryptographic coprocessor, which can 25 perform standard mathematical encrypting and decrypting operations at much higher speed than can a general purpose microprocessor and which will preferably contain a hardware noise source, such as a diode noise source, to assist in the generation of certifiably random numbers as needed for 30 cryptographic key generation;
(3) An input-output interface or subsystem to assist in handling the flow of data and c, n(~ to and from the miUL U~L uCt:560r ~ which may include a status display or monitor; an~

t4) A memory subsystem that may potentially employ several types of memory storage technology, each having a different characteristics of pPr~-nPnre and accessibility, 6uch as (a) Read Only Memory ("ROM") that can contain 5 pPrr nPnt and unchangeable programs and data, (b) Electrically Erasable PL~YL hle Read Only Memory KU..-- ) or "FLASH" memory, that can contain semi-PPrr-nPnt ~L~yL~II..O and data, i.e. they can be changed but nevertheless are not lost when device power is lost or shut 10 off , and tc~ Random Access Memory ("RAM"), which can be used for temporary calculations and temporary data storage but is lost when power is shut of f .
The entire device is designed and manufactured in such a way that all its elements, including especially the 15 pPrr-nPnt and semi-pPrr~npnt memory areas, are shielded from tampering that might reveal their contents or alter their modes of operation. One way to shield the device elements from tampering is through the use of special coatings that are difficult to remove without destroying 20 the information that underlies the coatings. In addition, there are other f eatures that can cause the memory to be erased if any alteration to the physical Pn~ l o~ re of any of the memory areas is attempted or if suspicious actions that may signal tampering attempts, such as cooling the 25 device to ~hnrrr-l ly low temperatures in an attempt to deactivate and defeat the device' s internal defense n; F'mC, occur. Some of these protective features may require a constant source of hattery power, such that the device can take electrical actions to delete important data 30 if tampering is suspected. The present invention does not specify any particular preferred method of making the devices tamper-resistant, but rather relies on existing or future technologies that may be or may become generally regarded as providing an acceptable degree of protection 35 from unauthorized disclosure or modification of the data contained in the devices. A device with such characteris-tics is sometimes referred to as a tamper-resistant secure module (TRSM), of which a current example is the Clipper/-.
Capstone device, discussed earlier, commercially availablefrom Mykotronx, Inc.
The manufacturer of the chips may be any of the many major computer microprocessor chip manufacturers. The 5 manufacturer should preferably be one who is known to the cryptographic industry and is trusted with respect to chip quality and security and the integrity of its manufacturing process .
The chips manufactured in order to be used in an lO ~ of this invention would include the following c:~r1h;l;ties. The chip would first include an PmhP~ Pfl device public/private key pair for device signatures to be issued by the device, where the private signature key is non-readable and tamper-resistant. The cryptographic 15 signature keys may be of any acceptable cryptographic type, such as RSA. However, because RSA has both encryption and signature capabilities and because it is desirable to isolate the signature and encryption processes, the cryptographic signature key should preferably be DSA. The 20 chip would also include an PmhP~ d and tamper-resistant manufacturer's certificate for the device signature key, an example of the format for which is shown in FIG. 14. The device containing the chip can append this certif icate to its siy,.a~uL~s in order to prove that the siyl~a~uLe:S
25 originated from a device of known and trusted type having the qualities described below.
A chip manufactured for use in an Pmho~l;r ~ of the present invention would also include the manufacturer's public signature verif ication key PmhPfl~lP~l within the chip 30 in a tamper-resistant manner. The manufacturer's public signature key can be used by the user to verify instruc-tions received from others by ~hPrki n~ whether those instructions have attached a valid digital signature created by the manufacturer' s private signature key, in 35 order to determine whether those instructions originated with the manufacturer or one trusted by the manufacturer.
The chip may also include PmhP~ Pd and tamper-resistant WO 95/1~672 ~. 2 1 7 6 0 3 2 ~ u~
public in6tructions keys that can be used by the user to verify instructions received from others. The public instructions key could be the public key of some other trusted entity , such a= Bankers Trust Co ., selected by the 5 manufacturer or could be the public key of a trusted national or global system-wide authority, and may optionally be ~mhPrlrl~ into the chip by the manufacturer for use as a "short-cut" to avoid having to verify the extra manufacturer-to-trusted-entity certificate. The lO manufacturer could install several instruction keys of various qualified key escrow houses that the manufacturer selects and believes to be capable and trusted.
Furth, e:~ the chip used in an ~mho-l;r--lt of the present invention would have the ability to generate a 15 public/private key pair for encryption and decryption of data and communication6 by the individual user. The cryptographic encryption keys may be of any acceptable asymmetric cryptographic type, such as RSA. The crypto-graphic keys should, however, preferably be of the Diffie-20 Hellman type, i.e. the user's secret number is the privatekey and the user's publicized int~ ;Ate number is the public key, which are together used in the Certified Diffie-Hellman scheme to generate a session key that is used to encrypt and decrypt communications. The private 25 key so generated is then stored inside the chips in a non-readable and tamper-resistant manner. In addition, the chip would also have the ability, once a public/private encryption key pair for that device has already been generated, to rekey and generate a new public/private 3 0 encryption key pair in place of the previous key pair . In another ~mho~ -nt, Interactive Diffie-Hellman key genera-tion can also be used, as ~;CC~lcs~rl later, in order to ensure that all senders and recipients contribute new random numbers to generate the message session keys.
In the preferred ~mhorl;r-nt of this invention, the trusted device will have the ability to decrypt encrypted communications only on two conditions . The f irst condition i6 that valid ma5ter escrow center certificates for .
the sending and the recipient devices must have been fed into the device prior to its receiving the encrypted trans-mission. Each certificate is valid if it is signed by a master escrow center certifying that the private decryption 5 key of that device has been escrowed with one or more gualif ied escrow agents, and pref erably with two or more Micali-style agents that employ a verifiable key-splitting protocol . This master escrow center certif icate either must be ~ -n;ed by another certificate issued by the 10 manufacturer establishing the named master escrow center as a valid escrow agent, or must be signed by a third party (a trusted national or global system-wide authority) named as a holder of a public instructions key ~mh~ d into the chip by the manufacturer. The second condition for decryp-15 tion is that the message to be decrypted must be precededby a valid Message Control Header (~CH) data f ield (the format for which will be described later) so that law enfuL. ~ or employer security personnel will have sllffi-cient data from which to obtain the recipient's escrowed 20 private keys and therewith monitor the communication.
In another ~mho~lir~~L of this invention, the chip will also have the ability to generate a public/private key pair to be used for user signatures, distinct from the ~ ' ?d key pair that is used for device signatures. As with the 25 device signature key pair, the cryptographic user signature keys may be of any acceptable cryptographic type, such as RSA, but should preferably be DSA, again to avoid any poss-ible confusion with the keys used for message encryption.
The user signature private key should be non-readable and 30 tamper-resistant. The user would use the signature private key to sign his communications for sender verification and non-repudiation purposes. In still another ' ~;- L of this invention, the chip also has the ability to use the device signature key in order to sign a request for 35 certification of the user public signature key that it has generated for the user, thus proving that the user signature key pair was generated by, and the private key is being safeguarded by, a device of known tamper-resistant Wo 9~ll9G72 2 1 7 6 0 3 2 ~ /L~
.
properties. In further embodiments of this invention, the chip may also have a hardware noise source, such as a diode noise source, to generate random numbers during key genera-tion, and a unique physical device serial number to allow 5 the device or its actions to be tracked in accounting, network management and inventory systems. In this embodi-ment, the device signature would certify not only that the user's device is of known tamper-resi6tant properties but also that every key or random number generated by the lO device was randomly generated anew each time using a high-quality random number generator, preferably a diode noise 60urce .
In manufacturing the trusted device containing the chip of the present invention, the chip's memory i5 divided 15 into at least three general area6 as follows: (1) perma-nent and non-modif iable memory space containing data and firmware Pll~hPrl~lP~l into the chip during manufacture; (2) semi-parr-nPnt and modifiable memory space containing data, 6uch as the user's private encryption and signature keys, 20 generated for the u6er and held in trust for the user by the chip, which data and keys may be utilized by the chip to make digital siy~ Lu-es or to decrypt on the user's behalf but which are never disclosed outside the device;
and (3) non-pp~-npnt and temporary memory space containing 25 work area used for temporary storage of the inputs, inter-mediate results and f inal results of various data processing operations. DPrPn~qin~ on the design, these three general areas could each reside in a different type of memory storage system, such as ROM for permanent data, 3 0 EEPROM or FLASH memory f or user data held in trust, and RAM
f or volatile temporary storage . Another approach might be to use FLAS~I memory for both permanent and non-rPrr~nf~nt data. Yet another option is to utilize a chip operating system that would manage the microprocessor's memory using 35 a directory of objects. Under this approach, one portion o~ memory can be devoted to a table or directory of the other items in memory and may include standardized information for each object, such as:

W0 95/19672 ~ S c .
- logical name (e.g., "manufacturer's public key");
- type ( e . g ., key , certif icate , code routine , etc. ~;
- start address and length of data (in bytes);
- date last modified (optional);
- protection level (po~r-npnt~ user or volatile);
- disclosure level (externally readable or not externally readable).
In this manner, 60 long as the whole memory is equally lO tamper-resistant, no special areas need be designated for protected or non-protected data because the mi.:L .J~I .,c~ssor can readily enforce the desired level of protection based on the code contained in the relevant directory entry for the data object. This scheme can also apply to firmware 15 code routines just as easily as to data, and may be advantageously applied when upgrading or replacing trusted firmware eode routines without needing to physically replaee the device or any of its memory units.
The protected memory areas of a device of a preferred 20 embodiment of the present invention might contain the following types of information, including both data and f irmware program code.
A. perr-nontlY Fmho~ o~l bv Manufacturer 1. MaY Be ExternallY Disclosed a. system-wide authority public key ( optional ) b. manufacturer public key c. manufacturer certificate from system-wide authority d. deviee publie key e. device certificate from manufacturer f. deviee unique serial number g. firmware version numbers h. trusted bank public instruction keys 2. Mav Not Be Externallv Disclosed a. device private signature key _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .
3. Firmware a. operating system and file system b. basic cryptographic library routines c. escrsw system routines d. other trusted applications code B. Çenerated bY User Q~erations ~n~l Held in Trust fQr User 1. Mav Be Externallv Disclosed a. user's public encryption key b. user's public encryption key escrow certif icate c. user's public signature key d. user's public signature key certificate 2 . MaY Not Be Extern~ l l Y l)isclosed a. user' s private decryption key b. user's private signature key C. Other Non-Volatile Read-Write Storaqe (Optional) a. CUL. ~ undents' signature certificates b. correspondents ' escrow certif icates c . . ~ L e~ondents ' device certif icates ( f or MCH verification) D. Workinq Storaqe (Could Be Volatile) Public keys (all types), certificates (all types), hash values, signature blocks, other data stru~!tures being ~Lo.~ssed.
25 Rev Escrow Proces6 After the chip o~ the present invention has been manufactured and prior to using the chip to encrypt or decrypt communications, the user's public decryption key must be registered with a master escrow center or with 30 escrow agents approved by the chip manufacturer. Either the user may perform this operation himself or the manu-facturer may initialize and register the chip with an _ _ _ _ _ _ _ , W0 95/19672 ~ 2 1 7 6 0 3 2 P~
escrow agent during manufacture, thus relieving the user of the requirement to escrow his keys by himself. However, the manufaclturer could still leave the user the option to rekey by himself at a later time. For many individual 5 users, allowing the manufacturer to register the chip, either with or without a rekey option, will be sufficient.
In addition, consumers would most likely trust in the escrow agents chosen by the chip manuf acturer . Corpora-tions or other employers could program their own chips and 10 the chip5 of their employees, and could register the chips with escrow agents of their own choice. Corporations, how-ever, would generally not permit their employees to rekey on their own, because this could result in 1055 of control over c.,-~u-~t.e information and assets, as discussed above.
In order to generate and register a decryption key, the user (or whatever entity is performing the operation) invokes a f irmware program that has been ~mh~ into the chip and that instructs the chip to perform the particular steps of the Micali key escrow method or of the specif ic key escrow method that is used. See FIGS. 9-11, 15 and 16.
Using whichever method is chosen for escrowing the private key with one or more escrow 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 the other, public numbers that will be required, if those numbers have not already been set by some other prior random generation). The chip will store the private key in a non-readable and tamper-resistant manner. As shown in FIG. 15, the private decryption key can be escrowed with a single escrow agent. The trusted device 150 first generates a public/private encryption key pair 151 for the user and then sends to the escrow center 153 an encrypted and signed message 152 consisting of the encryption key pair 151 and the device serial number 154, with the manufacturer's certificate 155 for signature verification.
The escrow center 153 verif ies the signatures, decrypts the message packet and stores the user ' 5 private decryption key. The escrow center 153 also sends to the user a signed WO95/19672 2176032 r~ c^- I
certificate 156 consisting of the user's device serial number 154 and the user's public encryption key 151 and the device's public signature verification key 157, with the escrow center's certificate 158 ~or siynature veri~ication.
5 Once the user's device Yerifies the escrow center's signature, registration is complete.
If the private key is to be escrowed with more than one escrow agent, then the chip will then break the private key into several pieces called key splits, according to a 10 specific formula. Using the Micali escrow method and algorithm described earlier and shown in FIG. 9, the chip will next compute certain values 90 using the special Micali algorithm such that each value is based upon a mathematical transformation of one of the private key 15 pieces 92. The chip then forms one share packet for each trustee or escrow agent 94 designated by the user, each share packet 93 containing the unique serial number of the user's device, one private key split and the set of certain values that enable the particular trustee to verify the 20 received private key split as a valid part of the complete private key, without giving the trustee knowledge of the complete private key. As ~1; cc--c5Pd later, if the user is not the owner of the device but rather, for example, an employee of the employer-owner, the trustee share packet 25 would also include the unique identif ication number of the owner of the device and the device ' s owner certif icate so that employer-owner would be able to obtain the private key of the employee-user without having to f irst obtain a warrant. The chip then signs each trustee share packet 30 using the unique device private signature key and attaches the manufacturer's certificate for the transmitting chip, thereby attesting that the information transmitted originated from a device of known and trusted type.
Finally, the chip will output each signed trustee share 35 packet ~or delivery by the user to a trusted escrow agent.
There is another, preferred way for the master escrow center to verify the separate key splits, without using the Micali method, by relying upon the trusted device alone.

_ _ _ _ _ _ _ _ _ , WO9~/19672 21 76032 F~l/u,,~
.
Using this method of verifying the key splits, shown in FIG. 16, the chip generates one random number for each key split of the private encryption key. The chip then forms one share packet 161 for each trustee or escrow agent 163 5 designated by the user, each packet containing the unique number of the user's device, one private key split and one of the random numbers. The chip signs each trustee share packet using the unique device private signature key and attaches the manufacturer's certificate 162 for the 10 transmitting chip, thereby attesting that the information transmitted originated from a device of known and trusted type. As with the Micali method, the chip will then output each signed trustee share packet 161 for delivery by the user to a trusted escrow agent 163. In addition, the chip 15 must also create a message (encrypted) 164 to the master escrow center 165 containing, among other things, the user ' s public encryption key and the names of the escrow agents designated by the user and along with the random number given with the key splits to each respective escrow 2 0 agent .
It is possible, however, because each trustee share packet contains a private key split, that a third party with access to communications from a user to the escrow agents could read the contents of all the user' s share 25 packets and recombine the private key splits within those packets in order to reassemble the complete private key.
Then, using the private key, that third party could decrypt and encrypt communications in the name of the user. The best way to avoid this situation is by using encrypted 30 communications systems when sending share packets from users to escrow agents. The user would obtain the public encryption key certif icate 166 of each escrow agent selected for escrowing the user's private key, where each certif icate is signed by the master escrow center 35 certifying that the particular escrow agent is trusted by the master escrow center to receive and store a key split packet, and would then verify the master escrow center's signature either using a certificate from the device's Wo 9~/19672 21 7 6 0 3 2 r~ c~o~~ I
.
manufacturer (or from a sy6tem-wide authority) or using a preP~hPrlr9Prl instructions key. The device would then encrypt f or each escrow agent based upon that agent ' s certified public encryption key a transmission 161 that 5 includes the user ' s private key share packet . Alterna-tively, the manuf acturer could embed into the chip the public encryption keys of several trusted escrow agents matched with an instructions key for each, as ~liccllq5e~
earlier, in order for the user to send his private key 10 splits to escrow agents trusted by the holder of the instruction keys, which is typically the master escrow center. This way, all the escrow agents in the master escrow center's or the manufacturer's "family" could decrypt user requests for escrow, while sparing the user 15 the burden of obtaining the public encryption key certif icates of all escrow agents .
Once each escrow agent or trustee 163 receives the ~kYLu~riate share paclcet 161 from the user or from the user' s device, the trustee inspects the private key split 20 received in the trustee share packet 161 from the user's device and, together with the master escrow center 165, verif ies that it is ~ valid and correct part of the complete private key. It is nP~-PCC Iry for the escrow agents and the master escrow center to have a reliable 25 means of proving or verifying that the fragments of the user's private decryption key have in fact been deposited.
It is desirable that verification of the key splits be accomplished by the escrow agents and the master escrow center without ever inspecting or possessing those 30 r.c.,, Ls itself, or ever bringing them together in one location. The Micali "Fair" escrow system provides one highly trusted way for the escrow center to verify the separate deposits of the key fragments. In the Micali method, shown in FIGS. 10 and 11, this verification is done 35 with the set of certain values that were computed by the user's chip during preparation of the share packet through use of a special Micali algorithm and that were included with ~he key split in each share packet to the escrow WO 95/19672 2 1 7 6 0 3 2 p, "" , .
agents . The Micali algorithm and key split verif i-cation are known in the art and need not be repeated here. Each trustee 94 then stores the device's manufacturer's certificate for later use in decoding, and approves the key 5 split 93 by sending an appropriate signed message 96 to the master escrow center, along with the user's name and device certificate, and by signing and storing the key split 90.
Only when presented with either (a) a warrant or court order or (b) a signed request from the lawful owner of the 10 device will the trustee reveal the piece (or pieces) of a given privalce decryption key in its possession.
Using the preferred escrow and verification method relying on the trusted device alone, shown in FIG. 16, each trustee 163 transmits a message 167 to the master escrow 15 center 165 identifying the user's name, public encryption key, device number and the random number it received. In addition, the user device sends a packet to the master escrow center 165 containing the random numbers used f or verification of the private key splits, and that packet 20 should be encrypted using the master escrow center's public encryption key. The master escrow center 165 receives the messages 164 ,167 from the user device and from the trustees 163, and verifies that the individual random number received from each trustee matches the random number that 25 the user device stated was given to that trustee. Note that under this method the escrow agents 163 and master escrow center 165 rely solely upon the trusted device's signature on the share packets 161 to assure themselves that the escrow is proper . This escrow and verif ication 30 method does not need to perform any secondary mathematical operations in order to verify that the escrow is proper or that the public key presented for certification matches the deposited key r,., Ls. Although from the standpoint of public, user or systemwide trust, it might still be 35 desirable to utilize a verifiable key escrow algorithm such as the Nicali process, it is clearly not necessary and may be ~ rpn~pd with when the added cost of using such a process cannot be justified. In addition, by this method WO 93/19672 2 1 7 6 0 3 2 r~ 5 C-- 1 of relying upon the trusted device alone, there is no llmit to the complexity of the key splitting schemes that can be devised, because there is no need to devise complex secondary algorithms to verify correct performance of any given scheme. It is necessary only to trust the integrity of the device manufacturer that P~he~ P~l the firmware code and to trust that the device will resist tampering.
After verifying all the user's private key splits, the master escrow center itself further ~pproves the public encryption key that cuLLe~yollds to the private decryption key that was approved by all the user ' s trustees; the master escrow center 165 approves the public key by issuing a signed certificate 168 (called the master escrow center certificate, the public encryption key certificate, or simply, the escrow certificate) certifying that the private key corrPsp~n~;ng to the public key being certified has already been escrowed in the proper fashion. The public signature key of the user's device, obtained from the device's manufacturer's certificate, can also be placed in the master escrow center certificate, thus eliminating the need to send or reverify the device manufacturer certif icate at later points in the process . The master escrow center certificate could be formatted as follows:
Version Number Escrow Certif icate Serial Number Master Escrow Center Country Code Master Escrow Center Name Master Escrow Center Public Encryption Key (for use in creating LEAF~
User Distinguished Name User Public Encryption Key (hereby being certif ied) User Device Public Signature Verification Key (to verify device signature) Validity Date (start/end) Master Escrow Center Signature [Master Escrow Center System-wide Certif icate ]

WO 95/19672 2 1 7 6 0 3 2 ~ u~
.
Public encryption key certificates that have been issued by the master escrow center are distributed and can be used either by the device owner in order to activate his device to originate encrypted messages or by others to encrypt 5 messages to the owner of the device containing that user ' s public/private encryption key pair.
It should be noted that the present invention does not require more than one escrow agent to be the recipient of the user's private encryption key splits; in some cases, it 10 might be enough merely to deposit the user's private decryption key with a single escrow agent (or escrow center). However, in order to enhance user and public trust in the system, it is desirable to split the user's private decryption key among several escrow agents such 15 that all the key splits, or some specified number of them, are required in order to reassemble the user ' s key and decrypt his communications. It is further desirable that each escrow agent be an in~Pr-~n~ nt, trusted business operation, thereby effecting "split knowledge, " so that in 20 the event of attempted corruption, bribery, extortion or abuse, it will be much more difficult to wrongfully obtain the user ' s private decryption key than it would be if the private key were stored with a single entity. It is also desirable that the entities be separated yeoyL(~ ically in 25 order to further suppress attempted subversion or corruption .
~n~ ryption of Communications A user who desires to send an encrypted communication to another user must have an escrow certif icate f or his own 30 device and an escrow certificate for the intended recipient's public encryption key, because the device of the present invention will neither encrypt nor decrypt if either is missing. First, the sender must load his own - valid certificate into the device, typically when he first 35 receives it from the master escrow center. Then, the intended recipient's public key certificate can be obtained either from the intended recipient directly, from a WO9~/19~72 217 6032 r~ ) c - I
directory service listing public key certificates, or from the sender'6 local file, e.g. a file of users with whom the sender has previously exchanged encrypted communications.
In one embodiment of the present invention, because the 5 sender's device will not encrypt and the recipient's device will not decrypt unless the recipient's public encryption key certif icate is "valid, " in order f or the recipient ' s device to decrypt the encrypted message, the recipient's public encryption key certif icate must be signed by either (a) the recipient device's manufacturer (this is unlikely to be the case because device manufacturers will most probably not be escrowing user' s private keys); (b) the master escrow center, and ar- -r~ied by a manufacturer's certif icate approving the master escrow center as a valid 15 trustee; or (c) a trustee or master escrow center whose instructions key was ~Tnh~ into the device during manufacture. Using the intended recipient's certified public encryption key as set forth in the recipient's public encryption key certificate, the sending user then 20 generates a session key for use by both the sender and the recipient to encrypt and decrypt the communication. This session key can be generated preferably using the Certified Diffie-Hellman method or, alternatively, any other es~uivalent system. In the Certified Diffie-Hellman method, 25 the user first randomly generates his ephemeral private key for that message and then computes the session key based upon his own private key and the recipient' s public key (i.e., the recipient's int~ te number and the two public numbers, which are all contained with the 30 recipient's public encryption key certificate). Then, using the session key, the sender encrypts the message to be sent to the recipient user.
However, in deciding whether or not to send an encrypted message to the intended recipient, the sender may 35 be unable to verify the properties of the recipient's public encryption key certif icate or of the digital signatures thereon if the sender ' s device were made by a manufacturer different from the one that made the WO 95/19672 2 1 7 6 0 3 2 r~
.
recipient's device. The fact that the recipient's device was made by a differQnt manufacturer would prevent the sender's device from easily verifying either the manufacturer's signature or the certificate of the 5 manufacturer (that certified the master escrow center that signed the recipient's key escrow certificate) stating that the recipient's master escrow center is valid and ~v~ vv~:d by that manufacturer. Likewise, the recipient's chip would be unable to verify these conditions with respect to the 10 sender's certificate before decrypting. EnfL~L~_ 1 of the escrow restriction on both parties i5 needed in order to enable law enforcement agents to lawfully intercept and decrypt messages being both sent and received by a given suspected user, without nPcPqqArily obtaining the other, 15 non-monitored party's private decryption key and, thereby, access that non-monitored party's unrelated messages.
One way to address this issue, while still allowing more than one manufacturer to make cryptographic devices, is to embed into the device or into a certif icate issued by 20 either the user's master escrow center or the chip manufacturer a public key from a trusted national entity, for example the Federal Reserve Bank ("FRB"), which could be used to verify yet another certificate issued by the FRB
to each of the other various master escrow centers or 25 manufacturers. Such a certificate would verify the trustworthiness of the particular master escrow center or manufacturer and would be signed by the FRB. A sending user could then obtain the public encryption key certif icate of an intended recipient and could trust the 3 0 master escrow center that issued the certif icate because the master escrow center was accredited by the FRB, rather than by the chip manufacturer, as certified by the FRB
public key or certificate. Also, the signature of a particular device could be trusted because the other 35 manufacturer that certified that device was accredited by the FRB, as certified by the FRB certificate or public key.
In order to deal with this issue on a less parochial United States-based level and promote a more international and WO95/19672 21 7 6 032 r~ s~ - I
worldwide system, the public key of a trusted global entity, such as the Bank for International Settlements in Switzerland, could be ^rh~ le~l into either the trusted device, the FRB certificate or the master escrow center or 5 manufacturer certificate (d~rPntl;n^j upon the trust model employed), and could operate the same way di~:c--csesl regarding the FRB key, in order to accredit master escrow centers and manufacturers on a worldwide basis. Another way, albeit one not involving U.S. or world authorities, lO for one device to trust the escrow centers certified by another manufacturer is for the device manufacturers or master escrow centers to cross-certify each other. This would allow the sender's device to help enforce the recipient's escrow restrictions by allowing the sender's 15 device to verify the certification path of the recipient's escrow certif icate back through the recipient ' s device manufacturer or master escrow center to his own. In the preferred ^mho~;r ~, the public key of a trusted system-wide entity would be ~ into the trusted device and 20 would operate the same way di~ s~l above regarding the FRB or global entity key, in order to accredit all the master escrow centers and manuf acturers on a system-wide bas is .
Whenever any user, entity or device "verifies" a 25 digitally signea "certificate, " whether a manufacturer's certificate or an escrow certificate, issued by a certifying authority or manuf acturer, it is common practice in most or all actual and proposed public key certificate management systems (and it is assumed throughout this 30 disclosure) that the user, entity or device also checks any applicable "certificate revocation list" ("CRL") in order to determine whether the certifying authority or other issuer has distributed, propagated or otherwise made available a list of revoked certif icates that is updated in 35 accord with an appropriate security policy and whether, based upon the issuer name and certif icate number, the certif icate has been revoked . A certif icate issued to a user could be revoked for death, name or employment change, or 10s5, theft or destruction of the device (the personal smart card) containing the private key . A certif icate issued to an entity may be revoked due to cessation of b~lcinPcc~ name change, or loss, theft or destruction of the 5 device containing the private key . A certif icate issued to a device may be revoked due to loss, theft, removal from service or destruction of the device. The c hel-k; n~ of CRLs during certif icate verif ication is well-described in the public literature (e.g., ANSI X9.30 - Part 3) and does not 10 require further discussion. All users, entities and devices will normally have access to appropriate telecom-munications facilities and can retrieve CRLs or perform inquiries as desired. Likewise, under the present invention, all entities issuing CRLs are presumed to make 15 them available to all interested parties.
Messaqe Control Header Format When sending an encrypted ~ ; cation, the sending user must also form a suitable Message Control Header (MCH) field containing the following information:
(1) The sender's int~ ;Ate number for the encrypted message, computed by the sender using the sender's randomly generated ~rh ~l private key that was also used by the sender to compute the session key with which the message was encrypted. The recipient user must have this inter-mediate number in order to compute the session key for decrypting the message.
( 2 ) The name and country code of the sender ' s master escrow center.
(3) The name and country code of the recipient's master escrow center, obtained from the recipient's public key certif icate .

(4) The sender's escrow certificate number, encrypted using the public encryption key of the sender's master escrow center (obtained from the sender's escrow certificate) so that only the sender's master escrow center may decrypt it.

Wo 95/19G72 2 t 7 6 ~ 3 2 PCT/US95/00531

(5) The sender's intermediate number (different from the sender's previous intP -~l;ate number) that was used by the sender to compute the ~rh ~l session key with which the sender ' 6 certif icate number was encrypted to the 5 sender's master escrow center. The sender's master e6crow center must have this number in order to compute the er~ ~l key for decrypting the sender's certificate number .

(6) The session key for the encrypted message, 10 encrypted using the sender's own public key tthe inter-mediate number from the sender's own public certificate), so that in effect the sender sends the message session key to himself. Law enforcement can gain access to this message session key once it obtains the sender's private 15 key _ ~ntS from the sender's escrow agents.

(7) The sender's intermediate number (different from the sender's two previous int~ -~iAte numbers) that was used by the sender to compute the ephemeral key with which the message session key was encrypted to himself. Law 20 enfL", L must have this number in order to compute, using also the senderrs private key (his secret number) obtained from the sender's master escrow center, the -- ~1 key for decrypting the message session key.

(8) The recipient's certificate number, encrypted 25 using the public encryption key of the recipient's master escrow center (obtained from the recipient's escrow certif icate) 50 that only the recipient ' s master escrow center may decrypt it

(9) The sender's int~ 'iAte number (different from 30 the sender's three previous int~ ~iAte numbers) that was used by the sender to compute the ephemeral key with which the recipient ' 5 escrow certif icate number was encrypted to the recipient's master escrow center. The recipient's master escrow center must have this number in order to 35 compute the ephemeral session key for decrypting the ~ecipient's certificat~ ~b~

WO95/19672 - 2 t 7 6 032 ~ .. r - I
.

(10) Timestamp (optional), for tracking purposes and possibly to assi6t in the enforcement of warrant date and time restrictions.

(11) The signature of the sender's device.

(12) The sender's public key escrow certificate issued by the sender ' 8 master escrow center . The sender ' 8 escrow certificate contains the sender's device public signature key, which the master escrow center had pre-verified and then copied from the sender's device's manufacturer's certif icate .

(13) The master escrow center's certificate from the FRB, the manufacturer or whatever system-wide authority is trusted, if the recipient's chip is made by a different manufacturer, appended to the sender's escrow certificate.
The certificate of the manufacturer, the FRB or the system-wide authority is needed only for the first communication between the two parties . The certif icate could also be a cross-certificate from the recipient's manufacturer or master escrow center.
The MCH thus described could be summarized as follows:
Sender Int~ te Number (to allow the recipient to decrypt the message) Sender Naster Escrow Center Country Code Sender Master Escrow Center Name Recipient Master Escrow Center Country Code Recipient Master Escrow Center Name Sender Escrow Certificate Number, encrypted for Sender Master Escrow Center Sender Int~ -'iAte Number (for encrypting the sender certificate number) Message Session Key, encrypted for sender Sender Intermediate Number (for encrypting the message session key to the sender) Recipient Escrow Certificate Number, encrypted for Recipient Master Escrow Center Sender Int~ te Number (for encrypting the recipient certificate number) Timestamp Sender Device MCH Signature ... _ _ ... . _ . .

WO9~i119672 ,` ' ~ $` ' 2 1 7 6~32 P~
.~:f.
[Sender Escrow Certificate~
[ Es crow Center Cert i f i cate ]
FIG . 17 show6 a process f or 6ending an encrypted mes6age 176 with a MCE~. The entire MCE~ 172 (the appended certificates 173,174,175 are not technically part of the MCH) i6 signed by the sender's device 171, using the device private DSA signature key, with the ~mh~ d certificate of the manufacturer ArpPn-q~d thereto (within the sender's escrow certificate) in order to certify the device's public signature key. This guarantees that the entire MCH is delivered intact to the recipient and that the recipient's chip can easily verify that the MC~I has not been modified.
The manuf acturer ' s certif icate might be accompanied by an national (FRB) or a world-authority certificate to certify the trustworthiness of the manufacturer of the sender' s chip in case the recipient's device was manufactured by a di f f erent manuf acturer .
In another . - '; nt of this invention, a second, shorter NC~ f ormat could be used f or the case in which total privacy is not crucial. In this MCH, neither the Sender Certif icate Number nor the Recipient Certif icate Number are encrypted for the respective master escrow center . Not encrypting the certif icate numbers saves much time and space in creation of the MCH. In still another ~mho~ nt of this invention, a third, even shorter ~CI~
format could be used for the common case in which the sender and the recipient both utilize the same master escrow center for key escrow purposes, by making EC1 identical to EC2. By eliminating the need in the MCE~ for identifying information of the second master escrow center and for the special intP ^~ te number that is used for encrypting the recipient certif icate number to the second master escrow center, the MCH can be made signif icantly shorter. Furthermore, the size of the MCi~ could be further reduced by using RSA ~cey transport to encrypt a DES key for the message and for each of the three encrypted inner LEAF
components. According to this method, each sender Wo 95/19672 2 1 7 6 0 3 2 F~
int~ te number would be replaced by a smaller RSA-wrapped DES key. Thus, the sender could RSA-encrypt the message session key for the recipient and eliminate the need for the first int~ te number in the MCH. The 5 sender could also RSA-encrypt the message session key for himself (actually, for law enforcement to decrypt later) and thus eliminate the need for the third intP ~ te number in the MCH. The sender could further RSA-encrypt his own and the recipient ' s certif icate numbers and thus 10 eliminate the need for the second and fourth intP -';Ate numbers in the MCH. As shown in FIG. 18, eliminating the four int~ te numbers and its associated encryption and replacing each intP -';~te number with a smaller RSA
transport encryption 181 saves a significant amount of 15 space of the MCH size.
Contribution of R;ln~lom Material Some may be concerned that a message session key Py~h~n~P~l u5ing only the RSA key transport method or the Certified Diffie-Hellman scheme is not sufficiently secure 20 because, with either of these two methods, although both the sender and the recipient provide information, only the sender generates the message session key. However, under military standards for secure communication, both sender and recipient must contribute random material in generating 25 a session key prior to each communication session, apparently in order to reduce the chance that the sender might use a weak key or use the same kay repeatedly and thereby subject the recipient to an undesired security risk against his will. The system of trusted devices contem-30 plated under this invention can alleviate this fear in twoways. First, it can ensure that the sending device will generate each key separately using random numbers derived from the noise of a built-in hardware noise source, such as a reverse-bias diode, as fl;~cll~FP~ earlier. Then, so long 35 as the device signs the MCH or message control header, the recipient would be assured that each message session key and the random numbers used in generating it are strong and WO95/19672 ~,; ~ ~ , 2 1 7 6 0 32 P~
unique. Still,t ~ e insistent upon greater security may demand contribution of random material by both sides of the ;cation, as defined for Type-l military systems for class i f led inf ormation .
Thus f ar in this disclosure, the sender has been described as generating message session keys based on the recipient' s public sncryption key as contained in his escrow certificate, but not based on random material received from the recipient during the setup phase of the communication . Arranying f or the sender to receive a contribution from the recipient, however, creates a new problem. The recipient cannot simply be allowed to generate a Dif f ie-Hellman intP ' i ~te number on his own and send it to the sender f or use in generating a message session key, because the recipient then would no longer be using the escrowed private key within his trusted device to decrypt messages and because their communications could never be monitored by law enf orcement . Continued success in enf orcing the escrow scheme requires that neither sender nor recipient be able to read a message without using a registered trusted device.
In order to allow a situation in which both the sender and the recipient contribute random material to the message session key prior to _ ; cating, the initial key-exchange protocol may be modified to allow a would-be recipient's device to generate a new Prh ~l Diffie-Hellman secret number, separate and apart f rom that recipient's escrowed private key, that will be used to compute a new int~ te number that will, in turn, be sent to the sender for use computing the mes6age session key f or encrypting the message . The recipient ' s escrowed private key would still be used to generate the inter-mediate numbers (; n~ Pcl in the MCH) and the Prh al session keys that are used to encrypt the various portions of the NCH. This modification requires, however, that generation of the new secret number occur inside the would-be recipient's device, that this new secret number remain inside the trusted device, and that the new intermediate .
number be signed by the would-be recipient's device prior to being sent to the sender ' s device f or the purpose of attesting that the new ephemeral 6ecret number is indeed confined securely inside the recipient's device. As 5 before, the sender's device generates a new secret number that is separate and apart from the sender's escrowed private key and, using that new secret number and the recipient's new intermediate number, generates the message session key for decrypting the message. The sender's lO device will also use the sender's new secret number to generate the sender's new intermediate number, which will be sent to the recipient's device as an element of the MCH
for wiretapping purposes. In this method, the message session key would, therefore, include random material 15 contributed by both the sender and the recipient, as des ired .
However, under this modified key-exchange protocol, because the recipient and sender in effect use new Diffie-Hellman private keys for each message, the escrow feature 20 still "disappears, " as law enfuL, ~ and coL~uuLC,te management would never be able to obtain those ~rh~
message session keys from the escrow agents. Therefore, the needs of the escrow system and the community of interest require that the message session key be trans-25 ported in the MCH as before. In fact, in order to assureequality of tapping, all fields that were before disclosed as part of the MCH remain so. The field transporting the message session key to the sender (which is the only way for law enfurc L agents who are wiretapping the sender 30 to read the message) must still be included in the MCH in order to preserve the principle of equality of tapping.
The message session key will be encrypted into the MCH, as before, using the sender's public encryption key, to which law enfo~ will still have access. The sender's new 35 int~ -9; ~te number will be sent to the recipient as the first element of the MCH, as before, in order to allow law enf~,L. ~ to wiretap the recipient and compute the message session key. Thus, in order to ac~ '-te the WO 95/19672 ~ ) 2 1 7 6 0 3 2 PCT/US95100531 Interactive Diff; P-HPl l~-n key exchange technique, this protocol requires that the would-be recipient ' s new inter-mediate number be generated inside and be signed by his device, and requires that the sender's new intermediate 5 number be added to the MCH, not used in place of the previously stated key transport methods, as that is the only way the community of interest ( law enf UL . L, employers, and others) can read the message. This method, however, would not be economical for transactions besides lO on-line phone, network, or dial-up transactions, because the device would have to r~ ' -r too much, i. e. the special intermediate numbers for each counterparty. This method is preferably to be used in cellular phone, network logons, etc., through which a purely real-time interactive 15 session is desired.
r ~.n;ty of Tnterest Headers The NCH will generally be placed bef ore the encrypted message, as a message header. In many current electronic mail and document systems, several recipients are enabled 20 to read one encoded message, using the RSA transport P~ho~li t of the MCEI design as discussed above, by RSA-encrypting the message session key using the public encryption key of each recipient. That is, when several recipients are intended to receive the same encrypted 25 message, the MCH header can include, for each intended recipient, the intended recipient's name followed by the message session key, RSA-encrypted to each intended recipient using that recipient's public encryption key.
Thus, each intended recipient can locate his entry in the 30 MCH header, decrypt his copy of the message session key and read the message. Even with several intended recipients, the correctness of the MCH is enforced on both ends of the communication: on the sending end, the MCH output is enforced by the internal logic of the sender's device, i.e.
35 the requirement that it create a valid MCH prior to encrypting a message; on the receiving end, the MCH
coLL~uLl-ess is enforced by verification by the receiver's W095/19672 21 76032 F~ ,,S~: ~
device of the digital signature of the sender's device. As previously noted, because the recipients' copies of the message key are integral to the MCH, no recipient can decrypt the message unless the MCH is sent and received intact, unlike the Clipper system in which the MC~ is not itself linked to the key transport ---hAni c~.
Under this MCH formatting concept, the MCH could be summarized as shown in FIG. 25. As in previous MCH
formats, the authenticity of the MCH is guaranteed by the digital signature of the sender~s device 258. Furth~
as before, the escrow certificate numbers of the sender and the recipient are encrypted under the public encryption keys of their respective master escrow centers 251, 252 . In this format, however, the MCH, signed by the sender's device, becomes a modified "list of recipients" that is more flexible and easier to understand in relation to the way contemporary encrypted electronic mail systems work.
For example, the sender's and recipient's names (or system IDs or addresses) are now shown unencrypted in the MCH
253, 254 . Although this impinges on the anonymity of the sender and the recipient, as a practical matter it is dif f icult to send r e 5 ,_ag~C in an electronic mail system without tagging the messages with the names and addresses of the senders and recipients. Hence the loss of privacy is slight. In addition, the names of the sender's and recipient's employers 255,256 (or their uni~ue IDs, such as tax numbers or DUNS numbers~ are also shown unencrypted, thus greatly reducing the burden on the employers ' security staffs to find messages sent and received by their respec-3 0 tive employees . Alternatively, instead of leaving the sender, recipient and employer name blocks unencrypted, these entries could just as well read "sender, "
"addressee," "sender's employer" and "recipient's employer"
(or their equivalents) unencrypted, with the actual identifiers inside the encrypted areas, as before. Thus, an intended recipient of the communication would look in the NCH for his unencrypted identifying abbreviation and in Wo9S/19672 ~ ' ' 7 ~ ~ 2 1 7 6032 this way will attempt to decrypt and read only the portions of the NCH that are directed to and encrypted f or him.
In addition, this MCH format as shown in FIG. 25 allows access by possible sub-units within the employer 5 or~anization, by defining secondary employer lines (a, b, etc. ) . For secrecy-conscious employers, the MCH could read "sender empl sub-unit b" unencrypted, as discussed above, and contain the actual company unit identif ier in the encrypted area. Because each MCH entry is labeled, there lO is no limit on how many layers of employer access there can be; all of them become in some sense authorized "recipients" of the message. Furthermore, in contrast to previous NCH f ormats, this MCH f ormat can include the message session key encrypted directly to the employer 257 15 80 that the employer need not go to the master escrow center and agents in order to obtain the message session key for decrypting the message. Although possibly impinging on employee expectations of privacy in the workplace, this format can allow employers to check or 20 recover their employees' files with minimal effort.
In order to create a MCH in this f ormat prior to 6ending a communication, the sender must first obtain all the n~cp~c~ry names/codes and public keys of the intended recipients and their employers . This inf ormation can be 25 garnered from the recipient's escrow certificate and from his own escrow certif icate . However, in order to generalize this approach and make this information available to a user who desires to send a communication, the master escrow centers must include into each user ' s 30 standard form escrow certificate, as discussed earlier, the unique identification or code number and public encryption key of both his employer and any employer sub-units. The escrow certificate layout could be designed by using repeating subgroups, for efficient h~n~9l in~ of variable 35 numbers of "community-of-interest" parties. Each community-of -interest party entry would have a unique identif ication number, a public encryp~ion key and, possibly, an instruc-tion code (or policy code, as .liCCllccPd below) instructing WO 9~/19672 2 1 7 6 0 3 2 PCTIUS95100531 the sender's device how to encode that party's MCH entry.
The instruction code could include elements of choice giving the sending device the options of including (1) the party's unique identification number either unencrypted or using an alias, e.g., "empl-a;" (2) the message session key in the coded area or not; (3) the party's unique identifi-cation number in the coded area or not; and ( 4 ) the time-stamp or a random number at the start of the coded area or not. These (and possibly other) instruction codes could be defined as bitmask flags. The list~of parties (and/or their codes), their public encryption keys and the instruc-tion flags would tell the sender's device how to format the community-of-interest portions of the MCH in accord with the desires of each party for partial or total anonymity.
It is anticipated that in practice, many community-of-interest parties will not bother with anonymity, because it will be much easier for them to search for and identify their employees' messages if they keep their own names and identif ication numbers in the clear .
DecrYPtion bY Reci~ients When the intended recipient receives the encrYpted message 191 and the MCH field 192, several things must be done in order for the recipient to read the message, as shown in FIG. 19. First, the recipient must load his own valid escrow certificate 193 into his chip 190 because, under the preferred ~mho~l;~ L of this invention, the chip will not decrypt without it. Typically, the recipient' s escrow certificate will already be stored in the device's memory in a pre-verif ied state . The recipient next loads the MCH 192 and the sender's escrow certificate 194, which also contains the sender'6 device's public signature verification key (with the appropriate system-wide, national or world authority certificate 195, if n,-cr,~:~Ary into his chip 190. The recipient's chip 190 checks the sender's escrow certificate 194 in order to verify that the sender ' s private decryption key has been escrowed . This is done by using the public key of the manufacturer to verify Wo95/19672 ` - i ~ 2 1 7 6032 .
the signature of the manufacturer on the device certificate or, if ner~6s~ry, the signature of the system-wide authority on the escrow center certificate and by rherl~;nr~
whether the escrow center's 6ignature on the sender's 5 escrow certif icate is valid . In the pref erred ~mhr7fl; ~
the public signature key 196 of the sy6tem-wide authority is used to directly verify the escrow certif icate 195 . The recipient's chip then checks the NCH signature before proceeding in order to verify that (1) the sending device 10 is trusted, (2) the sender's key is escrowed, as also verified by the 6ender, and (3) the MCH 192 is valid, i.e.
the MCH is in the proper format and contains all the requisite information. This is done by verifying the sender's device signature, the sender's device manufac-15 turer's certificate signature and, if necessary, themanufacturer's system-wide authority certificate. The manufacturer's and the system-wide authority's public keys could be: -1c'e~l into the recipient's chip 190 to facilitate this verif ication process . In the simplest 20 case, the recipient need validate the sender's escrow certificate 194 only once, against its own f-mhpA~
manufacturer's public key or system-wide trusted entity instructions key. Once those are shown to be valid for a particular 6ender, the recipient needs only to use the 25 sender' s pre-validated device public key to validate the MCH signature, resulting in only a single signature validation per message. If either the sender's certificate 194 or the MCH 192 is invalid, the recipient's chip will not decrypt the mes6age. Finally, after verifying these 30 certificates and signatures, the recipient computes the message session key based upon the sender's int~ te number, which was included in the MCH, and the recipient's own private key (his secret number) corresponding to his public key as publicized in his public encryption key 35 certificate 193. Using the se5sion key, the recipient decrypts the message sent by the sending user.

W0 9~119672 2 1 7 6 0 3 2 P~ u,,,~
.
Decrv~tion bv Law Enf orcement In order to intercept and decrypt communications to and from a particular user, law enforcement must have court authorization or a warrant to monitor that particular 5 user's communications. The court authorization will, in all probability, include (l) a "6tart monitoring" date and - time at which law enfur~ may begin to monitor the user's c icationS~ (2) an "end monitoring" date and time after which law enforcement may not monitor the user's lO communications, and possibly (3) a grace period to follow the "end monitoring" date, during which grace period the law enforcement may retain the user's private key in order only to decrypt the previously-intercepted communications but not to intercept or monitor any additional communica-15 tions of that user. In monitoring the c~ tions ofthe sending user, law enf OL ~ ~ intercepts the communi-cation and identifies from the MCH the name and country of the sender's master escrow center in order to ~1PtP~m;nP
from whom to request the sender's private decryption key.
20 Law enful~ ~ then presents the court authorization and the MCH from the intercepted - ;cation to the sender's master escrow center, which uses its private key to decrypt the sender's certificate number that was encrypted into the MCH. Using the sender's certificate number, the sender's 25 master escrow center looks up the sending user's name and the names of the sender's escrow agents, and reveals them all to the law enfuL, ~ agent along with the sender's device manufacturer certificate, which law enforcement will need later during decoding. The law enfuL. ~ agent then 3 0 contacts each of the sender ' s escrow agents and presents to it the sender's name and the warrant, and obtains from each escrow agent the key splits entrusted to it by the sender.
Because the preferred method of intercepting and decrypting encrypted communications by law enforcement in this inven-35 tion is by using the decoder box specified below, the lawenfu~ ~ request to the escrow agents will also include the public encryption key of the law enfuL, L decoder box, so that the key splits can be sent directly to the law Wo 95/19672 2 l 7 6 0 3 2 PCT/US9~/00~31 enf orcement decoder box and not to the law enf orcement agents themselves . Each escrow agent sends the sender ' s key split in its possession to the law enforcement decoder box as an encrypted message having a "start monitoring"
5 date, an "stop monitoring" date and an optional "grace period" so that the decoder box can enf orce the terms of the warrant. The decoder box then decrypts the encrypted key split ~ f e, combines the key splits and uses the sender's reassembled private key to obtain the session key 10 for the communication, which session key was encrypted by the sender into the MCH as a message sent to himself. The decoder box can then monitor and intercept communications to ~nd from the sender only during the monitoring period specif ied in the warrant, and can continue to decrypt those 15 intercepted communications only until the end of the grace period specif ied in the warrant .
A similar procedure is used to monitor ~~nmm~lnicationS
to and from the recipient. From the MCH of the intercepted communication, law enf orcement identif ies the name and 2 0 country of the recipient ' s master escrow center and then presents the warrant and the MCH f rom the intercepted communication to the recipient ' s master escrow center, which uses its private key to decrypt the recipient's certificate number that was encrypted into the MCH. Using 25 the recipient's certificate number, the recipient's master escrow center looks up the recipient ' s name and the names of his escrow agents and reveals them all to the law enf~L, ~ agent. The law enf~rc ~ ~ agent then contacts each of the recipient's escrow agents and presents to it 30 the recipient's name and the warrant. Each escrow agent sends the key split entrusted to it by the recipient user to the law enf ~ decoder box as a message encrypted to the decoder box having a "start monitoring" date, a "stop monitoring" date and a grace period for enforcement 35 of the terms of the warrant by the decoder box. The decoder box then decrypts the encrypted key split6, com-bines them and uses the recipient' s resulting rf.;-ccF~mhlf.
private key, along with the sender's intermediate number, Wo 9~/19672 - - 2 1 7 6 0 3 2 p~""~
which is at the head of each MCH, to compute the session key for the communication. ~he decoder box can then monitor and intercept communications to and from the recipient only during the monitoring period specif ied in 5 the warrant, and can continue to decrypt those intercepted communications only until the end of the grace period specif ied in the warrant .
In another Prho~ir-~lt of the present invention, the format for each escrow agent's encrypted key split message 10 to the law enf~ decoder box might be as follows:
User's Certificate Number Private Key Fragment: X(i) Begin Monitoring Date and Time Stop Monitoring Date and Time Court-allowed Grace Period (days/hours) Date and Time (of this key split message) Escrow Agent signature [Escrow Agent Certificate]
In this format, all information except for the Certificate 20 Number would be encrypted under the encryption key of the decoder box. Because the key split messages from the escrow agents are encrypted for that particular decoder box, no other user or decoder box can read them. Further-more, the "Begin Monitoring" and "Stop Monitoring" dates 25 and times instruct the decoder box when to begin monitoring and ~lPco~;nq communications and when to stop monitoring;
the Grace Period allows the decoder box an additional, specif ied time period to decode any backlog of the pre-viously intercepted communications, after which time period 30 the decoder box must stop decoding and must erase the subject's private key. Thus, the decoder box can be used to decrypt the monitored user's communications until the date specif ied in the warrant, at which time the decoder box and its embedded time clock prevent any further decryp-35 tion. The decoder box could also refuse to process keysplit ~ s~gPc having a Message Date and Time older than Wo 95119672 i~ r 2 1 7 6 0 3 2 ~ c ~~
S~
twelve ~12) hours (or some other specified time period) or having an ~xpire Date and Time that has already pasæed.
Decoder Box ImPlementa~ion In a preferred embodiment of this invention, law 5 enf~ L employs a special tamper-resistant decoder box for intercepting and decrypting the communications of monitored users under certain def ined and controlled conditions. An example of a decoder box and its process flow is shown in FIG. 20. The decoder box 200 is designed lO to be a trusted device of a similar design within the system oP trusted devices of the present invention and, theref ore, can enf orce various conditions in order to prevent improper action by law enforcement agents. The decoder box 200 has a private device signature key Pmh~
15 by the manufacturer and a manufacturer's public signature key certificate 202 for the public signature key that matches the device private signature key. In addition to the manufacturer's certificate 202, the decoder box may zllso have a certificate 203 issued by (or on behalf of) a 2 0 law enf ur. 1_ authority or corporate security department that owns the decoder box, attesting or notarizing the cnnnecti on between the decoder box and the law enforcement or security authority, and attesting that the decoder box is under its sole possession and control. The decoder box 25 200 also has the ability to generate a public/private key pair, just like the regular user chip of the present invention, for encryption and decryption of administration and control messages to the decoder box. The decoder box 200 further has the abilities to store its private key 3 0 securely and to issue the COLL ~ 1; n~ public encryption key within a certificate 201 signed by itself, with its device certif icate 202 signed by the manufacturer attached.
Having this ability to generate (and use) the public/pri-vate key pair enables the escrow agents 206 of a wiretapped 35 user, upon presentation by law enforcement agents to the master escrow center of a warrant to monitor the user~s communications, to send the key splits 204 of that wire-Wo 95/19672 ~ 2 1 7 ~ 0 3 2 r~ c - .
.
tapped user to the decoder box encrypted using the decoder box' s public encryption key and enables the decoder box to decrypt those key splits using its private decryption key.
However, unlike a regular user chip of the present inven-5 tion, which decrypts a message and returns the unencryptedresult to the user, the decoder box never outputs the wire-tapped user' 5 private key to the law enforcement agents.
Instead, the decoder box stores this inf ormation securely until the end of the Grace Period specif ied in the warrant 10 and in the key split -sa~C, at whiqh time the decoder box erases the information p~rr-n~ntly Accordingly, in order to perform its duties as a trusted device and enforce the date and time restrictions imposed by the wiretap authorization, the decoder box 200 15 must also contain a trusted, calibrated and certified date/time clock 205. The decoder box manufacturer certifies and attests to the validity and the calibration of the clock 205 when the manufacturer issues a device certificate 202 with its list of known device properties.
20 When the decoder box 200 receives from the escrow agents 207 the key splits 204 containing time limits (based upon the warrant) before or after which the warrant is not valid, the decoder box 200 uses its internal time clock 205 to verify that the law enforcement warrant is still valid.
25 If the warrant is not yet valid, the decoder box will not monitor or decrypt the communications of the wiretapped user. If the warrant (and any applicable grace period) has expired, the wiretapped user's private key is erased and will not be recreated again under that warrant by the 3 0 decoder box (unless a new warrant having a new time period is issued). It should be noted that, although the trusted time clock 205 is optional for a regular user chip of the present invention, it is mandatory for the decoder box 200 in order to allow the decoder box to enforce the date and 35 time limits of the wiretap warrant. Elowever, the user of the regular user chip can assist in the time limit enforce-ment by maintaining the calibration of his chip's time clock. If the user's clock is not calibrated, the ~CH

W0 9~/19672 ` ` ` ~ 2 17 6 0 3 2 r~ J/lJb~
generated by the user's device during communications will contain a null value in the timestamp f ield . In that ca6e, the decoder box intercepting the c~ i rntion will be able to enforce only the Stop Monitoring Date of the warrant by 5 refusing to decrypt after the expiration of the warrant and grace periods. Then, the decoder box cannot enforce the Begin Monitoring Date because, as long as the warrant is still valid, the warrant allows decrypting of all MCHs 6ubmitted with null timestamp values even if they were lO intercepted prior to the warrant period Begin Monitoring Date and Time. But, if the user's clock is calibrated, the law enf.l~ L decoder box can and will refuse to decrypt all MCHs containing a valid and trusted timestamp for a date and time prior to the warrant Begin Monitoring Date 15 and Time . Most pref erably, the decoder box of the present invention will decrypt only communications that are reliably timestamped during the warrant time periods. It is anticipated that this added immunity from potential abuse of warrant time periods by law enf orcement may 20 motivate users of the chip of this invention to maintain their chips in a calibrated state. Indeed, where the system is used to encrypt large numbers of messages in a data storage system, the enforcement of time periods for a later warrant or discovery order may be highly desirable, 25 because otherwise many mes6ages outside the lawful scope of the order might become subj ect to inspection .
Law Enf C~L l_ __. L Auditinq Features With an escrowed encryption system, there is a concern that law enfuL~ agents might be easily bribed in order 30 to obtain cryptographic keys that protect data of high economic value. For example, members of a well-funded criminal enterprise might be able to steal a set of valuable industrial plans from a particular company, first by illegally tapping that company's communications in order 35 to obtain some message headers and escrow agent names, then by bribing a low-paid police official to request a warrant for a drug investigation in order to obtain the company's WO95/19672 21 76032 I~IJIJ~
private decryption key from the escrow agents, and finally by using the private decryption key to steal the plans.
Because encryption is now used f or secure communication between many computers, it i5 no longer acceptable for law 5 enfuL- L to wiretap a tF~ ;cations system with minimal safeguards. A much ~LLU~ L set of safeguards is needed in order to bring police procedures and controls up to the level of modern corporate computer security practices and prevent this type of situation from l0 occurring. j `
One such safeguard for the trusted device is an internal counter f or numbering each message control header, which counter will increase sequentially after each access.
The message sequence number (MSN) can be placed in each 15 message header encrypted so that it would not be visible to an outsider. This can be done by encrypting the number either (l) under the sender's public encryption key, along with the sender ' s copy of the message session key, t 2 ) under the public encryption key of the escrow agent of 20 either the sender or the recipient, or (3) preferably under at least the sender, receiver, and their escrow agents, and possibly under all parties in the community of interest.
However, the sender's escrow agent could also, as a matter of policy, elect to allow the sequence number to be 25 displayed in the clear, on the grounds of economy of space and the low risks of exposing it. It is critical to avoid duplicate numbers of message control headers, and gaps in numbering should also be avoided to the extent possible.
Another afeguard feature might be to allow the user 30 to include an optional secret "title line" in the message control header. If a user feared illegal tapping under ; , U,U~:L warrants, the user could encode a short title, - 6uch as "Plan ~123, " in order to alert himself and others to the contents of the message. Alternatively, a user 35 could simply keep his own log (through a mail software system) relating the device-assigned message sequence numbers and the user-assigned titles. In order to save Wo 95llgG72 ~ 2 1 7 6 0 3 2 l l~u~
space, the title line would be of length zero if no title was entered, as would often be the case.
A third protection is to add to the signed portion of the message control heacler a digest or hash of the message 5 contents in order to prevent either the user or law enfu~ L from later ~ imin~ that the contents of the decrypted message were other than as actually sent. That is, for example, the user could not later substitute a harmless message for the drug deal message that had 10 previously been sent, nor could corrupt law enforcement officials later substitute a drug deal or harmless message for the valuable industrial plans the officials were stealing .
These saf eguards could be used as additional security 15 measures. First, the sender device-generated message sequence number would be used to track the message, by both sender and receiver, as well as by law enfuL. ~ and the court system . Although law enf u~ ~ access may be difficult to effectively control, especially during the hot 20 of pursuit of criminals, and although the court system may not always be able to carefully analyze law enfuL.
requests prior to issuing wiretap authorizations, diligence after the fact can be exercised in order to audit the results of a wiretap, either of every wiretap, of a random 25 sample of wiretaps, or of wiretaps that in some way appear unusual. The trusted device of the law enfuL. ~ agents, the decoder box, is therefore modified to include a secure internal log of the message sequence numbers and message digests (and title lines, if any) of the messages that it 30 h~s monitored and allowed to be read by law enforcement.
The electronic authorization sent to the decoder box by the escrow agents of a wiretapped user with that user's key splits may also include the public encryption and signature keys of the court that issued the warrant. The decoder box 35 is then able to respond to a request to print out the log of message sequence numbers and title lines, possibly encrypted under the key of a suitably authorized recipient such as the court that issued the warrant.

Wo95/19672 2 1 76032 E~~ Y - .
In another pmho8;- 1_, the decoder box will not start to decrypt the monitored communications until it receives a specif ic court order that matches the key splits received from the escrow agents. For example, the key split messages that are received from the escrow agents and encrypted using the decoder box's public encryption key can be Pnh Inr~d to include (from each escrow agent) the public encryption and signature keys of the court that issued the warrant. Or, the escrow agents might refer in their key split ,~s to the date and number (if any) of the warrant, and the decoder box might then receive from the court the court's public encryption and signature keys, as well as the court's public key certificate that had been attached to the original wiretap authorization. For example, the court authorization to the escrow agents can be Pnh;-nrPcl to convey the following data, which is needed for the key split message:
Naster Escrow Center Name or ID Number Monitored User ' s Certif icate Number Court Name or ID Number Warrant Number (if any) Date and Time of Warrant Begin Monitoring Date and Time Stop Monitoring Date and Time Maximum Number of Messages (optional) [ Judge S ignature ]
Judge Certif icate Judge Certifier Certificate (e.g., court, etc. ) The escrow agents could then "recertify" the court's public encryption and signature keys to the decoder box by having the encrypted key split messages from the e6crow agents to the decoder box include the following additional - information, which must be present in each key split from each escrow agent:
Master Escrow Center Name or ID Number Monitored User's Certificate Number Escrow Agent Name or ID Number ( sending this key split message) --6 }--wo 95/19672 ~ 2 1 7 6 0 3 2 F~
Court Namq~ or ID Number Court Pùblic Encryption Key Court Public Signature Key Warrant Number (if any) Date and Time of Warrant Maximum Number of ~essages (optional) Escrow Agent Signature [Escrow Agent Certificate~

The decoder box thus receives the as6urance that all the 10 key split messages came from the same judge and the same warrant .

The fact that decoder box also has the judge~s public encryption and signature keys allows the judge to request and receive ( in conf idence) the log of all message sequence 15 numbers and message title lines intercepted and decrypted by the decoder box during the wiretap period ~ as a post-wiretap audit to safeguard against unjustified, unlawful or corrupt conduct of law enfu~ . ~ agents. Furthermore, the decoder box will not delete, erase, or reuse any memory 20 assigned to the monitored message log until the decoder box receives a separate order from the judge or court, verified again6t the previously received public signature key~
stating that the decodeL- box may do so~ Such an order wi be isBued either because the court has already received 25 from the decoder box the monitored message log that it previously requested~ or because the court has decided that no audit is needed in this instance. If the monitored message log memory storage area becomes full ~ the decoder box will not decrypt any more meBsages until the log is 30 sent to the judge or court and an order signed by the court is received allowing the decoder box to erase the monitored message log. Law enforcement can continue to intercept new messages pending clearing of the monitored message log, although the new messages will not be decrypted until the 35 full message log has been cleared for audit. The decoder box will also have a feature alerting law enfuL~ ~ that the monitored message log is nearing capacity, so that they t that the messa e audit l=~ be uploaded so :hat WO 95/19672 2 1 7 6 0 3 2 PCrrUS9S~00531 the decoder box will not cease decrypting. These transac-tions and communications may be fully automated and nearly instantaneous .
Each entry in the audit log may contain, in addition 5 to a digest of the mes6age, a 6econd digest that is the product of (a) the message digest plus (b) the full text of - the previous log entry concatenated together and redi-gested. This can prevent any .7;qhon~t court personnel from adding, deleting or resequencing the entries in the 10 log . This concept is ~7 i ccl7qq~d in U. r7 . Patents Nos .
5,136,646 and 5,136,647, which are hereby incorporated by ref erence .
As a followup action, the court could later request that law enf Or t submit the message headers and the 15 full content of the message digests in the audit log that the court has received. Also, in its wiretap authoriza-tion, the court could artificially limit to less than full message log capacity the number of monitored ~ c that may be decrypted by the decoder box bef ore the monitored 20 message log and message headers must be audited. Although this type of limit would have no effect on the overall ability of law enfu. ~ ~ to investigate, because do7wn-loading of the log to the court for auditing is almost instantaneous, it miqht alert the court to unusual circum-25 stances. In specific cases that re~uire controls that are~LUlly~L than merely sending the monitored message log to the court, the court might limit law enfur~ to less than full message log capacity before law enfuL. ~ must seek a new warrant to monitor additional communications.
Thus, if (1) both sender and receiver keep track of the sequence numbers of the messages they send and receive, and either associate title lines in the message control headers or log the messages in their local software systems, (2) both law enforcement and the court retain a complete log of each message decrypted by law enfc,7 . ~, and (3) each message header includes a digest of the message in order to prevent any party from later altering WO 95/19672 - ; 2 1 7 6 0 3 2 the message to cover up its actions, then a credible post-tapping audit can determine whether there might have ~een any abuse or corrupt action by the law enf orcement agency .
Although this system still cannot prevent, a priori, the 5 stolen plan scenario mentioned above, the knowledge by the criminal enterprise that its actions can be fully audited by both the court and the subj ect users can provide a worthwhile check on improper police actions. It might also be made a matter of regulation that the law enf orcement 10 agency record and submit to the court all ---~saq~c intercepted under a warrant and allow the wiretapped parties to request an audit of the wiretap, particularly where the subject is associated with a business enterprise and no criminal charges are f iled based upon that wiretap .
15 Str~m-oriente~ ~ata In C~ ni~ations involving stream-oriented data, such as a telephone call, in which each ~ ; cation consists of a 6tream of several message packets from two or more users, it is impossible for the sender device to hash and 20 sign the entire message as part of the MCH. Although it might be possible to send a MCH with each packet of a communication, doing so would be very costly in terms of processing time and network bandwidth. Hence, the MCH
should thus be transmitted only once, at the time of call 25 setup. A preferred way to handle continuous streams of encrypted data is to designate the calling user as the "sender" and to negotiate the MCH at the start of communi-cation, as before, including the message sequence number ~MSN) and hash of the first packet (if any) signed by the 30 device. Then, the sender's device could generate a series of unique packet sequence numbers (PSN), whose sequence begins with zero at the start of each communication. For all subsequent packets, the device needs only to hash and sign that particular packet, and to include (and sign~ the 35 hash, MSN (same for entire message) and the PSN for the packet. The callee will perform similar actions for each packet it sends, by referencing the caller's MSN for the Wo 95/19G72 2 1 7 6 0 3 2 PCTIUS95100531 communication, sequentially numbering its own packets starting with zero, and having the callee device sign a group consisting of the packet hash, the caller's MSN and the callee's PSN, thereby forming a "packet control header"
(PCH). The devices might optionally include the current time as an offset from the time start of the communication (in seconds or milliseconds), which is already present in previously disclosed versions of the MCH. This could enable the call to be replayed more realistically.
In order to further distinguish the caller's and callee's packets after the communication, it will also be desirable to include a call party code (CPC) with a simple coding scheme assigning numbers to the parties to the ~ ication, such as caller=O, callee=l, and any additional parties to the same encrypted session receiving higher numbers. Or, in place of the CPC, a unique identification number, such as the device serial number, the device serial number plus the device manufacturer ID
number, or the hash of the foregoing, may be used.
These methods could also be generalized as a method for multi-party session key generation. For example, a caller could generate a session key and use that same key to initiate calls with several callees simultaneously using RSA key transport. There will then be a separate MCH for each added party after the first two parties (caller and callee). The caller's device could treat the multi-party call as separate calls or as a single call having the same P~ession key but having multiple CPCs. Each callee would then be responsible for using the caller's MSN and for maintaining its own CPC and PSN. Alternatively, assuming use of conventional two-party session key generation methods (such as Diffie-Hellman methods), conference calls could exist in which a central party (e . g., a system operator) places all the calls and performs real-time - 35 decrypting and re-encrypting of each party's packets for all the others. The central party could also be the individual who patches in the next callee, in which case that callee's packets would be decrypted by that _ _ . , . ,,,, .. ,, . _,, . , . , . , _ . , _ . , , .. _ . , . , , , . _ WO 95/19G72 r ~ .~ 21 7 6 0 3 2 r~
individual's device and then re-encrypted using the session key (s) that the callee is using to communicate with the other party (or parties). See also B. Schneier, APPlied CrYPtQqraPhy~ J. Wiley 1994, p. 276, regarding use of 5 Diffie-Hellman with three or more parties.
A Packet Control Header (PCH) could be formulated as follows:
Original Caller's ~SN
User Call Party Code (CPC~ (caller=0, etc. ) User Packet Sequence Number (PSN) Time Offset from call setup (msec) Hash (of this packet) [ Device S ignature ]
It might be pref erable not to send a PCH with each 15 packet of communication, due to resulting heavY overhead in some systems that use short packets, but rather to send the PCH only periodically. This is akin to the technique known as "sliding windows" in network communications, in which packet sequencing and retries are not performed for each 20 packet but only for large numbers of packets. Usually such systems dynamically adjust the "window, " or the number of packets that are sent between error checks, based on line noise, i.e. making the ~indow large for a clear line but making it small for a noisy line that is causing many error 25 retries. If errors occur often, a small window would require the user to resend only a small amount of data; if errors are rare, h~rk;ng can be performed infrequently, albeit with a high cost to resend lost data in case of an error. Packet control headers could be directly integrated 30 into the sliding window scheme of a communication system, thereby providing the desired capacity to audit law enforcement actions dow1l to the packet level, while also allowing maximum system thluuyll~ul_ in a modern communications network.
To further strengt1len the auditability of the wiretap process, it i5 advantageous to positively mark the end of a communications session with some special packet. This Wo 9~/19672 2 1 7 6 0 3 2 r~l~u~
packet may be sent automatically by each device to the other~; prior to disconnecting, unbeknownst to the users, in order to prevent either the users or law enf UL . L agents from later claiming that a conversation either had or had 5 not ended, when the opposite in fact oc.;uLL~d. This could be accomplished by instructing each device to accept a "want to hang up now" input from its human user, whereupon the device would send out a "prepare to di~ nnPct" packet, which would then stimulate the other device(s) to do the 10 same. The device(s) would terminate their data streams with a "final" packet containing no additional data but preferably including the totals of all packets sent and received, call duration, etc.
Ti ' z~rn DeviCe Another feature of this invention in its preferred ' ~ , as discussed above regarding the decoder box, is a trusted and tamper-resistant timestamp device that self-certifies that it can issue (or affix) digitally signed timestamps (or data structures containing such 20 t;--- I ) that can be considered trustworthy by third parties. Such timestamp devices are described in U. S .
Patents Nos. 5,001,752 and 5,136,643, by Addison M.
Fischer. In its preferred ~mhodir L~ shown in FIG. 21, the timestamp device 210 (or subsystem) can be calibrated 25 and set into operation only by a trusted authority, such as the manuf acturer or one trusted by the manuf acturer, in much the same way that a postage meter can be set only by the local United States Postal Service branch office and is from then on trusted by the public and the postal system to 3 0 dispense postage-meter stamps only up to the prepaid amount. Once calibrated, the timestamp device 210 (or subsystem) will respond to a "t;r- ~t" instruction 211 (or recalibration) only if that instruction is signed either by the manufactul-er itself or by an entity that has attached a 35 certificate 212 from the manufacturer, or one trusted by the manufacturer, stating that the entity is trusted to set and calibrate the timestamp device (or subsystem) of the Wo 95/19672 2 1 7 6 0 3 2 T~llu.,' ~~ ~ I
host device. The time-set instruction operation would probably need to be perf ormed in person with the time setting authority taking momentary physical possession of the device and immediately erasing the time-set instruction 5 211 in order to prevent the possibility of a device owner capturing the instruction and replaying it at a later time in order to "back-date" a device's clock.
Once calibrated and for as long as it is undisturbed, the timestamp device 210 will affix timestamps 213 or 10 complete timestamp data in structured data f ields based upon its internal clock r- ~ni~, signing 214 the resulting data structures with its private device key and furnishing its manufacturer certificate 215. If the host device should lose power, be tampered with or receive an 15 instruction to deactivate itself, the time6tamp device will cease issuing timestamps. In that case, in order to avoid impairing other possibly useful functions that do not as an absolute matter require trusted timestamps, the timestamp device will utilize a convention, such as filling the 20 timestamp field with a pre-agreed "null" value, 5uch a6 all binary zeros or binary ones (or an equivalent convention~, when a structured data field calls for a timestamp to be entered. However, when a structured data f ield or the host device requires that an actual timestamp be issued, such as 25 in the ca6e of a law enforcement decoder box, if the time-stamp device has ceased to issue timestamps, the host device f~ln~t; t~n$: that require timestamps will not operate;
in the case of the decoder box, the box will refuse to decrypt intercepted communications. In order to avoid or 30 minimize the o~;.;u~ ce of the situation o~ lost host device power, each trusted timestamp device should pre-ferably be equipped with its own separate long-lived battery 216 for clock use only, some "low battery" warning indicator to prevent timestamp device loss of power before 35 a battery change and some means of retaining an adequate electrical charge (such as a storage capacitor, a second battery compartment or an optional external power supply) during battery change operations.

Wo 95/19C72 ~ 2 1 7 6 0 3 2 r .
For each timestamp is6ued by the timestamp device, there could be a timestamp device certif icate issued by the manufacturer (or another time-setting authority) 6tating the quality and reliability of the timestamp clock, the 5 date on which it was last set, as well as its expected time drift. When a recipient user receives a data structure that has been digitally signed by the host device, that recipient knows that, if the timestamp field is completed with a valid value, the device's signature and certificate 10 certify that the time was correct when the data structure was created, signed and issued. This certification is based on (l) the trustworthiness of the authority that most recently calibrated the timestamp clock, (2) the clock's drift tolerances as stated by the manufacturer in the 15 device certificate, and (3) the clock's ability to deactivate itself upon tampering or a loss of power. The recipient further knows that, if the timestamp field contains a "null" value, then the timestamp clock was not in a state of trusted calibration at the time the device 20 created, signed and issued the data structure. This information concerning the trusted properties of the timestamp device and its internal clock r- ~ ~n;Fm can be preferably encoded directly into the device certificate using a suitable attribute-value coding scheme. However, 25 this information could also be implied from the manufac-turer name and device type, which could be published by the manufacturer in a specification and performance certifica-tion as part of a publicly stated "policy statement" at the time the device certif icate is issued .
3 0 Such timestamps could also be issued by the device as part of other message h;-n-ll ing operations beside ~CH
creation and ~lecotl;n~. These timestamps could be attached to the personal signature of the device ' s user when the user signs another document or transaction using his personal signature key, which is securely confined inside the device. The device would sign or co-sign the timestamp element of the user's signature, or might alternatively sign over the user's entire signature block (which WO95/19G7~ ; i 2 1 7 6032 r~
contained the timestamp, also signed by the user, along with the hash-result message digest of the document). The device could then supply its certif icate in order to make the timestamp believable and trustworthy to a third party 5 who knows the manufacturer's public key.
Tr~ ted U~qradinq. Re~lacinq and RekeYinq Another feature of this invention is a tamper-resis-tant trusted device that contains an Pmh~ manufac-turer's public key, a protected non-volatile memory area lO and a secure central processor unit (CPU) and can upgrade or supplement in a trusted manner any f irmware routines ~mherl~led by the manufacturer. The trusted device does the upgrading or supplementing by accepting as input a body of data containing new or additional f irmware code that is 15 suitable for that type of device and is digitally signed with the manufacturer's signature, which signature assures the device that the new firmware code has been developed, te6ted and approved by the manufacturer and that the device should theref ore either ( a ) overlay one or more currently 20 ~Toh~ firmware routines with the new f irmware code or (b) add the new f irmware code as one or more new routines in a currently unused area of protected memory. In the pref erred embodiment, the protected memory would be of the FLASH type, which can retain its information indefinitely 25 while powered down but can also be erased by the device (albeit, relatively slowly) and reused if desired. The protected memory could also include any data storage area (such as a disk drive), whether or not tamper-resistant, in which the code to be upgraded or supplemented could be 30 stored in an encrypted form for which the decryption key is known only by the trusted device. 8y storing the ~1~UyLC~
in an encrypted form, the device effectively prevents them from being modif ied by anyone without knowledge of the decryption key. When the device receives such a signed 35 body of new firmware (or software) code, the user inputs the code along with the manufacturer's signature and issues a II~L uceOO f irmware upgrade" instruction to the device .

WO 95/l9C72 2 1 7 6 0 3 2 PCTIUS95~0053]
The device then verifies the manufacturer's signature using the public signature key of the manufacturer, which was prnhP~lPd in the device during manufacture. If the manufacturer's signature verifies, the code is accepted and 5 the device performs the desired upgrade.
The process of a trusted upgrade to the f irmware of a - trusted device a6 described above can be further extended to A~ Ate authorized third parties that desire to upgrade firmware routines that pertain to device functions 10 relevant to those third parties, including functions such as the present key escrow system, which may be largely designed and administered by a bank master escrow center independently of the trusted device manufacturer. In an instance of third party upgrade, the manufacturer could 15 sign a f irmware upgrade certif icate containing a public key of the third party f irmware provider and issue it to that third party. The third party could then develop, test, and approve replacement or additional firmware routines, sign them with the third party' s private signature key, and 20 attach its upgrade certificate from the manufacturer thereto. Upon receiving such an upgrade, the user would load both the signed code routines and the manufacturer's upgrade certificate into the device and then issue a ~I~JL ocess third party f irmware upgrade" instruction . The 25 device would then verify the third party's signature on the new code routines against the manufacturer's upgrade certificate and then verify the upgrade certificate against the manufacturer's public signature key that was in the device during manufacture. If both signatures 30 verify, the upgrade is accepted and the device performs the desired upgrade.
In addition to accepting instructions to upgrade or supplement device f irmware routines, a tamper-resistant trusted device can also accept instructions to replace or 35 supplement "instructions" public keys that were ~nhe~ Pd during manuf acture . As discussed earlier, a trusted device may have public keys besides those of the manufacturer clrl~l during manufacture of the device. Such _ .. . . . .... ... _ ... . _ . ... _ .. . . . . _ Wo 95/1967Z - ~ ~ 21 7 6 0 3 2 PCT/I~S95/00531 t "instructions" public keys might include those of one or more master escrow centers as described in the present invention. These Pmh~ d keys, including those of the manufacturer or other trusted third parties, can be used to 5 verify various certificates such as escrow certificates, device certif icates, upgrade certif icates, time-set instruction certif icates and others that may be presented to the device f or it to act upon . In addition to relying only on public keys ~ during manufacture, the device lO can also accept external instructions to embed new public keys or to replace existing ones. In order for a device to accept and store in a non-public area the public signature key of a trusted third party, the manufacturer will enclose the new public key in a signed instruction data packet (or 15 certificate) signed by the manufacturer instructing the device to discard the enclosing certif icate and store the designated public instructions key within. The special packet may also instruct the device as to what types of transactions the new key is trusted (e.g., for use with a 20 key escrow application, car rental application, medical data application, or other use). Upon receiving such a public key data packet from the manufacturer, the device would first verify the manufacturer's signature and then accept and store the new public key along with the 25 restriction on the public key's use.
The manufacturer may also designate at the time of ~mhelltl;n~ a third party public instructions key, either during manufacture or later as part of an instructions data packet, that one of the transactions f or which that third 30 party key is approved is the replacement of the manufac-turer's own underlying public signature verification key.
Although such a repl~c L of the manufacturer's own public signature key should almost never be required, there is the chance that the manufacturer's cvLLe2~ullding private 35 signature key (for issuing device certificates and other in6tructions to the device) might be c~ through theft. Theft of the manufacturer's private signature key would allow the thief to issue seemingly valid instruc-WO9~/19672 21 76032 F~~
.
tions, to approve new escrow centers (of dubious trust-worthiness) and to approve new time set authorities.
Alternatively, and more likely, the manufacturer's private signature key might simply be lost or destroyed, thus 5 preventing the issuance of any further valid instructions.
Either of these events would be classified as a "disaster"
in computer systems terms and could result in all of that manufacturer's devices having to be recalled. However, through the present invention, the expense of such a recall 10 could be prevented or mitigated by allowing a trusted third party to replace the manufacturer's compromised signature key. ~Ccllmin~ that the manufacturer had already Pmharl~lecl the instructions keys of one or more trusted third parties into the device, either during manufacture or later using 15 an instructions data packet, and had included the replace-ment of its own public key among the transactions that the third party's public instructions key could approve, the manufacturer could then turn to that trusted third party and request that it issue an instruction data packet to all 20 of the manufacturer's devices authorizing the replacement of the manufacturer's public signature key, thus saving itself and its users the potentially huge expense of physically replacing all the physical devices. Because all the device certif icates issued by that manufacturer would 25 also have to be replaced, this could be accomplished by having each device issue a certif icate request f or the device's own public device signature key. If the manufac-turer ' s private key was lost or destroyed, and not compro-mised, then all previous signatures would still be valid 3 0 and a user would need only to present his old device certif icate in order to have a new device certif icate issued for the same information signed by the manufac-turer's new signature key. The manufacturer would then return new device certificates (most likely via an on-line 35 or an electronic-mail transaction). While this would still be expensive, it would be far cheaper and less detrimental to the reputation of the manufacturer than the wholesale W095/1967Z ~ 21 76032 F~l/lm _~ I
physical replacement of all of that manufacturer's trusted devices in the f ield.
The incorporation into the trusted device of the present invention of a ---h~niFm to replace a manufac-5 turer's public key or any other trusted public instructionskey could mitigate some of the systemic security risks that are posed by the use of system-wide root public keys. This would allow greater reliance upon purely hierarchical trust models, which generally allow shorter and simpler certifi-10 cation paths requiring fewer certificates, less effort todetermine which certificates to utilize and less computa-tional time to verify the signatures.
Owner-Controlled Rekevin~
As previously described, the user also has the option 15 of rekeying his device as to its user encryption key pair at any time after manufacture. The user does this by issuing a f irmware instruction to the trusted device to perform the particular steps of the key escrow method, i.e.
to generate a new private and public encryption key pair, 20 send the key splits to the escrow agents and ultimately receive a new escrow certificate from the master escrow center. IIowever, it is also desirable to permit a user's employer or sponsor (or owner, if the u6er is another device or proces6) to control the key and rekey processes 25 in order (a~ to make sure that the user selects escrow agents that the employer deems acceptable and (b) to assure that the employer, as the true owner of the device, will remain known to those selected escrow agents and hence will be able to request the user' s key splits from the escrow 30 agents without having to first obtain a warrant or court order. The employer may require access to a particular device's keys for any number of reasons, such as to conduct internal surv~ n~ e or to recover encrypted proprietary data after the relevant device has been lost, stolen or 35 destroyed. The employer may also need to rekey the device for any of a number of reasons, such as for a device whose previous encryption or signature keys have been c~ ed Wo 9~/19672 2 1 7 6 0 3 2 P~ .C- -or erased, for a device that has been given to a different ~mployeQ, or for a device whos~ owner-organization rekeys all cryptographic devices at periodic intervals as a matter of policy.
In the preferred ~ , the trusted device is pre-6et by the manuf acturer such that it will not initiate - the key generation and escrow process unless the device first receives an owner's certificate for the device 220, such as one shown in FIG. 22, containing the particular device's p~rr-nF~nt serial number 221 and signed 225 by the manufacturer. The owner's certificate 220, issued at the time of purchase by the manufacturer to the corporate purchaser of the device, also contains the corporation's name 222, the corporation's unique identification number 223 (such as Internal Revenue Service Employer Identifi-cation Number ~EIN) or Dun & Bradstreet Number (DUNS) ) and the ~_uL~Vr~tiOn'S public signature verification key 224, which corresponds to the private signature key retained by the corporation and which will be used to verify rekey or 2 0 other instructions issued by the corporation to the device .
Sllh~P~l~nt to receiving this information, the device will respond only to rekey or other instructions that are signed using the culyur~te owner's private signature key corres-ponding to the public key contained in the device's owner's certificate.
Referring now to FIG. 23, when the employer (the owner of the device) desires to rekey the device 230, the employer issues a signed instruction 231 to the device 230, ;nrlll~;n~ (1) the device's serial number 232, the unique owner identification number 233, (2) the names of the escrow agents 235 and the master escrow center 234, (3) the date and time of the rekey instruction, ( 4 ) the date and time of the rekey instruction expiration 236 and (5) the rekey instruction unique serial number 237, and signs the 35 instruction using the employer's private signature key 238.
Upon receipt of a valid owner's certificate 239 and a valid rekey instruction 231, the chip within the trusted device 230 first verifies the manufacturer's signature on the WO95/19672 ' 2 1 76032 ~ c-c~ I
owner~s certificate 239 and the employer's signature on the rekey instruction 231. The trusted device then completes the key generation and escrow process, as before, including the owner's unique identification number 233 within each 5 escrow share packet, and sends the share packets only to the escrow agents 235 designated by the employer in the rekey instruction 231. Subsequent replay of these instruc-tions (which may be issued electronically) can be limited by designing the device so that the device retains in non-10 volatile storage the serial numbers of the last severalrekey instructions it received and refuses to execute the instructions again. ~csllmin~ the device's time clock is maintained in good order, subsequent replay of the rekey instructions can also be limited merely by instructing the 15 device's time clock to honor the expiration date and time in the instruction. In a preferred Pmhor~ nt, a device whose clock is l]nrAl ihrated would refuse to process a rekey instruction that has a non-null expiration date/time but would proceed if the expiration date/time were left null.
Upon receiving from a user device the key (or rekey) split share packets containing a unique owner identif ica-tion number, the escrow agents and master escrow center would record that unique identif ication number in their respective databases and would subsequently honor requests from that owner for access to the private encryption key.
In a preferred Pmhorl;--nt, the escrow agents and escrow center would each require that a key split share packet that designates a unique owner identification number must also be A~ , n; ed by the respective device owner certificate signed by the manufacturer. This device owner certif icate would allow the escrow agents and the master escrow center to act upon key request messages signed with the owner's private signature key corresponding to the owner's public key in the device owner's certificate.
In another Pmho~ir-nt, the trusted device can be allowed to accept rekey, reescrow, ownership transfer or other instructions from the device owner without having to use a separate device owner's certificate. ~he requirement Wo95/19672 2 1 7 6 0 3 2 1 ~,u~
of having to use a separate owner ' s certif icate f or instructions to the device is an administrative burden, because the owner must maintain a database of certificates for all its owned devices and locate the appropriate 5 certif icate each time it wants to rekey a device or send the device some other instructions. A better approach, as shown in FIG. 26, is to have the manufacturer issue the owner a single certificate for the owner's public instruc-tions key for a given family of devices, let the seller 10 install its public instructions verification key 261 inside the device 260 when the device 260 is sold, and then insti-tute a system based on the internal storage of those keys.
Upon initial sale of the device by its manufacturer to an owner, the device 260 will first verify the validity of the 15 owner's manufacturer certificate 262 using the manufac-turer's public instructions key 263 that was o~ d within the device by the manufacturer. If the owner public instructions key area 264 within the device is blank, the device will copy the owner' s public instructions key 261 20 from the owner's manufacturer certificate 262 into the owner public instructions key area 264 of the device. If an owner public instructions key already exists in the device and i~ different from that of the owner attempting to initialize the device, the device assumes that the 25 manufacturer has sold the device to another entity.
Because each device will have at most one primary owner, ownership of that device will be detclrm; nf~ by the presence or absence of an owner's public instructions key 261 inside the device 260, in lieu of (or in addition to) the prior 30 concept of an owner's certificate.
If no owner public instructions key is installed, the device is c~q; ~l~red to be a single-user consumer device that is ullL~a~ricted with regard to rekeying or ownership transfer of the device; as such, the device will consider 35 the non-existence of an installed owner's key as a signal to obey the user's instructions without invoking the rekey, ~ees~;L~,.. and ownership transfer rules discussed above. If an owner public instructions key 271 has been installed Wo95/19672 - 21 76032 r~ c- I
within the trusted device 270, as shown in FIG. 27, then user rekey, re-escrow and ownership transfer instructions 272 will not be processed unless those instructions are signed 273 by the ~:uLLe~ ding owner private signature key 274. Once the owner's signature 273 has been verified, the trusted device 270 performs the steps of the re-escrow pL~I~eduLe~ as described previously. Thus, the owner need not append an owner ' s certif icate proving his ownership of a given numbered device when instructing that device.
However, the owner's signed instructions must of course be limited to a numbered device or perhaps to some class of devices whose device numbers conform to a given rule or template, in order to prevent the instructions from being f ed into every device owned by that owner .
In addition, as shown in FIG. 28, the owner can send an instruction to transfer device ownership by replacing the originally-installed owner public instructions verifi-cation key with another ~from the buyer, the new owner of the device) . The device owner sends an ownership transf er instruction 282 to the device 280, including the new owner's name and public instructions verification key, signed using the current owner' s private instructions signature key 283. The device verifies the ownership transfer instruction 282 using the current owner's public instructions key 281, replaces that key with the new owner's public instructions key 284 and thereafter responds to instructions only from the new owner. In addition, the owner could also add another "sernn~rv owner" by installing a second public instructions key. This second public instructions verification key would have a "rights"
field, indicating for which operations it is authorized to accept instructions. Among those rights might be: rekey, addition of another owner, deletion of an owner (same as a conditional sale), deletion of all owners , and reverting back to a consumer device having no stated owner. However, these defined rights may include more or fewer rights than, or the same amount of rights as, the original or primary ~ WO 95119672 2 1 7 6 0 3 2 r~
instructions verification key, including the right to replace or remove the primary owner instructions key.
Generalized Device Re~istration Note that the foregoing general methods for escrowing 5 a private decryption key and receiving an escrow certif i-cate can also be applied to the more general case of registering a trusted device with a trusted third party and receiving an authorization from that third party enabling the device to communicate with other trusted devices, not 10 necP~Arily limited in scope or purpose to the key escrow situation. In this general process, depicted in FIG. 24, a yLuyL hle trusted device 240 that communicates with a trusted third party (TTP) 241 is equipped with a private signature key and a manufacturer'6 certificate 242 for the 15 C~lLL~IJ(...~1;ng public signature key. It also contains secure copies of the manufacturer's and systemwide (or global) authority's (SWA) public keys, which could be the same, and secure system-level firmware that can support the remote installation of additional application-level 20 firmware and related public keys, a6 fli~rllcsPd Pl~PwhPre in this disclosure. The device 240 can register with any one of a potentially unlimited number of TTPs 241 that are admitted into this general registration system by having been issued a certificate of authority 243 signed by the 25 SWA (the SWA could also appoint an additional tier of certifiers to authorize TTPs to be admitted to the system, in accord with well known principles of public key certification hierarchies). Once users have registered their devices with a given TTP, they can then engage in 30 EpPciAl;~ed transactions with other trading partners.
In the f irst step of this process, the user initiates a request 244 to reqister his device 240 with a given certified TTP 241. This request 244 contains some informa-tion 245 to identify the user and the nature of the regis-35 tration request and is signed by the device and accompanied by the manufacturer's device certificate 242 in order to vouch for the signature and the known type of the device.
~79~

Wo 9'./19G72 ~ 2 1 7 6 0 3 2 1 ~ ~ ,' C-- J
The selected TTP 241'~y also request other information and assurances from either the user or from other parties to verify the user~s identity, affiliation, creditworthiness, etc., which are outside the scope of this protocol but may 5 influence the TTP's decision to grant or deny the desired authorization to perform transactions. The TTP 241, using the appropriate public keys, verifies the manufacturer's signature on the device certificate 242 and the device signature on the information 245 in the user's registration 10 request 245 .
When satisf ied that the user can be permitted to engage in the requested class of transactions, the TTP 241 then issues a response 246 containing a certificate 247 specifically authorizing the device to perform those 15 transactions on behalf of the user. The TTP's device authorization certificate 247 will typically contain infor-mation identifying the TTP, the user, the user's device, and the transactions for which permission is granted, as well as a recertified copy of the user's device public 20 signature key as a matter of convenience (and as later ~7.; CCl7CC/~r7) 50 that the user need not submit his device certif icate 242 in each subsequent transaction with trading paL L~ r /~. The TTP response 246 may also contain down-loadable firmware and or public keys 248 to be loaded into 25 the user's trusted device to enable it to perform the authorized transactions. Where the TTP response 246 calls for the user to securely load new firmware or public keys into his device, the response 246 will also include the TTP's certificate of authority 243 issued by the SWA
30 certifying the TTP's public signature key and conveying firmware and public key upgrade authority. When the user's trusted device 240 receives the TTP's response 246, it uses its '--''--' SWA public signature key to verify the TTP's certificate of authority 243 and uses the TTP public 35 signature key contained therein to verify the firmware and public key upgrades 248 and the TTP's device authorization certificate 247.

W095119672 2 1 ~6032 i~,l/tJ~7.~
Referring again to FIG. 24, when the user wishes to perform a transaction with a trading partner 250, its device will formulate the transaction data 249 in accord with the rules embodied in the firmware program installed 5 on the device (either at time of manufacture or upon subsequent downloading), as has been extensively ~1; CCllC~
throughout this disclosure, and will sign the transaction 249 and attach a certificate for its corresponding public key. This certificate could be the manufacturer's device lO certificate 242 but will more likely be the TTP's device authorization certificate 247, which contains a copy of the device public key recertified for convenience. The trading partner 250 will typically utilize the public key of the TTP to verify the TTP's signature on its device authoriza-15 tion certificate 247 and then use the device public signa-ture key contained therein to verify the device's signature on the transaction 249, thereby confirming the device's compliance with the transaction protocol requirements imposed by the relevant f irmware . In the event that the 20 trading partner 250 does not already have the specific TTP ' s public signature verif ication key, the u6er can include in his transaction 249 the TTP's SWA certificate of authority 243, which the trading partner can verify using the SNA public key, which it must already possess in order 25 to be a participant in this system.
The generalized process thus far described is general enough to allow (a) the escrowing of a private encryption key in return for an escrow certificate signed by an escrow center (TTP), where the information contained or implied in 30 the user device certificate conveys to the escrow center that the device is already equipped with firmware that is capable of performing the specialized functions of the herein-described key escrow encryption system, or (b) if such device is not so equipped but is capable of be~ m;n~
35 so equipped, the downloading of a secure software upgrade that upon installation will enable the device to fulfill the escrow system transactional requirements. The transac-tion data 249 sent to the trading partner 250 can be an Wo 95/19672 , ~ 2 1 7 6 0 3 2 r~
ncrypted message pref ixed by a mes6age control header and n;ed by an authorization 247 (the user's escrow certificate), as issued by a TTP 241 ~the master escrow center) .
The generalized system of FIG. ~4 therefore possc~cq-~q many highly desirable properties which can facilitate complex forms of business and y~ L -nt transactions in open communication network environments. In particular, there can be many different device manufacturers, as long as each participating device i5 able to execute secure multi-step transactions, download f irmware to perf orm additional types of secure multi-step transactions, and sign the transactions so created. Also, there can be any number of trusted third parties, each issuing a different type of transactional authorization and each creating and certifying a different class of firmware application, such as key escrow, digital cash management, car rental or user medical records management. Thus, although a trading partner may be required (by the user device's firmware and protocols) to utilize a comparably equipped trusted device, that device may be made, issued and equipped by different parties than those of the original user, yet the original user ' s transactions will still be accepted and processed in accord with the system rules, so long as the partner possesses a copy of the SWA public signature verif ication key 247, which enables all versions of the devices and their ~L~yLC~ 5 to recognize each other and work together, if so certif ied by the SWA and its TTPs . Some examples of business purposes that can be fulf illed by this protocol include systems that enforce transactional requirements for (a) encryption using provably escrowed keys, (b) management of digital representations of cash or other high-value tln_ ~_5, and (c) access to and use of medical or other personal information of the user.
Uniaue Owner Identification N~mh-~r DPr-on~lin~ on the need to balance ease of use with priYacy rights, the unique owner identification number may WO 95119672 2 1 7 6 0 3 2 r~
.
also optionally appear in either (a) the user's escrow certificate or (b) MCHs issued during normal communica-tions, as well as in the key split messages to escrow agents. It would be desirable for an investigator 5 attempting to decrypt communications to be able to deter-mine by looking at a NCH containing the owner identifica-ticn number whether one or both of the devices involved in the communication from which the NCH was taken belong to a given owner. However, other privacy interests, including lO those of certain owners, might suggest that the owner identification number be omitted from the NCH in order to enhance the privacy of communications. In cases in which the owner identif ication number is included only in the device escrow certif icate and not in the NCHs of communica-15 tions, an investigator, hired by a particular employer inan attempt to determine whether a particular communication originated from employees of that employer, cullL~ùllLed with many NCHs that have no listed device owners, would inquire of a master escrow center listed in a given NCH whether 20 that NCH originated from a device owned by the employer.
The master escrow center would decrypt the certif icate number of the party to the NCH communication whose keys are escrowed with that master escrow center and check whether that user certificate was issued to the investigator's 25 employer. If so, and if the investigator's request is signed using the employer-owner's signature key (i.e., the investigator has authori2ation from the employer-owner to investigate), the master escrow center would reveal this information. If the investigator has no authorization, the 30 investigator would then be required to seek a warrant or court order to investigate suspicious activity ref lected in NCHs of unknown device owners. It is anticipated that most device owners will not object to being openly named in their user's escrow certificates and NCHs, because in most 35 electronic communications systems it is impractical to suppress the physical and logical network address informa-tion that often stro~Sgly identifies the sending and receiving institution of a given message. Thus, little is Wo 9~119672 2 1 7 6 0 3 2 r~ e ~ ~, lost by publicizing the unique owner identification numbers, and much is gained by providing the ability to quickly sift and sort messages by sender device owner and recipient device owner names.
The unique owner identif ication number may, however, still be included within the employee's escrow certificate or within the MCHs of communications without being publi-cized. The employee's escrow certificate and MCHs would include an Employer Public Encryption Rey along with the other keys as described above. These keys would normally be present in both the sender ' s and recipient ' s escrow certificates (~CCllm;n~ that both sender and recipient have employers). When the sender's device forms the MCH, it will incorporate into t1le MCH one or both employer unique identification numbers, each encrypted using the public encryption key of the respective employer so that, in effect, the sender's device uses the MCH to send to each employer-owner a message consisting of that respective employer-owner' s own unique ID that only it can decrypt.
This method is similar to that discussed above regarding the sender's use of the MCH to send the certificate numbers of both the sender and recipient encrypted under the public encryption keys of their respective escrow centers, and to send the message session key to the recipient (the MCH's normal function) as well as to the sender in order to allow tapping of both parties. This technique allows the employer to readily determine which MCHs belong to its employees, while avoiding a situation in which all messages belonging to the owner-employer's employees are readily identifiable in the message traffic flow and in which owner ID numbers are unencrypted and readily obtainable.
Still, this approach has the drawback that the unique employer identification number encrypted using the employer public encryption key will always produce the same, and thus r~co~ni 7;~hle~ value. A better implementation of this approach would be to encrypt a d~ata block containing a current ti-- La.l,~ (or another random number) along with the employee's escrow certificate number (which the employer _ W0 95/19672 2 1 7 6 0 3 2 r~
.
clearly has the right to know) under the employer's public kQy, so that the timestamp would give high variability to the encrypted data block. Several bytes of a distinct "eyecatcher" text, such as "EMPL" (or possibly the 5 employer's unique ID, space permitting) could also be included inside the encrypted block in order to make S~ "C~fUl decryption obvious to an entity that is decrypting the f ield ( in case the other data items are in binary, in which case one might not know for sure). In lO this case, proof of the employer's ownership consists of the employer merely being able to read this f ield . In addition, yet another random number could be added to the data block for increased variability, in case the timestamp is not sufficiently trusted to be different each time and 15 to therefore make all employer MCH data blocks unique.
~ his; uv~d approach, which would be done for the employers of both the sender and recipient with every message that is sent, would make it possible for employers and other a~u..suL ~, to determine which communications were 20 generated or received by their employees without having to submit the encrypted NCH for every communication to the ~yylu~Liate escrow center for a det~rm;n~tion as to whether or not any of those _ ; cations originated from a device owned by that employer, thus probably saving a considerable 25 amount of money. Each employer will still have to contact the master escrow center and the escrow agents, as before, in order to obtain its employee ' s private encryption key, . and must prove that it is in f act the owner of the employee's device by signing its requests with the private 30 signature key that matches the public signature verifica-tion key contained in its owner certificate as issued by the device manufacturer. At least the employers will be spared the time, effort and expense of any additional requests to those parties regarding the MCHs of communica-35 tions originating from what later turn out to be non-owned devices. And, as before, if an employer suspects criminal or other; uyeL activity in messages ~ccnnr;lnied by MCHs from communications by non-owned devices, the employer can WO 95/19672 2 1 7 6 0 3 2 r~ .c- I
.
always contact an appropriate law enforcement agency, tell that agency why it su6pects criminal activity and have that agency go to court to obtain a warrant f or interception and/or decoding of those communications, which appear to be 5 originated by third party non-employee criminals or, more likely, by individuals on the employer's premises, whether employee6 or not, who are using encryption devices not owned by and registered to the employer.
This method of placing information in the MCH
10 encrypted so that the inf ormation can be read only by the party entitled to read it can obviously be extended to parties in addition to the sender and recipient (each of whom can decrypt the message session key), each party' s master escrow center (each of which can decrypt its 15 respective user's certificate number), and each party's employer-owner (each of whom can decrypt its employee's certif icate number or its own unique owner identif ication number, so as to ascertain whether it owns the communi-cating device without having to contact anyone else, while 20 avoiding being identified on every message). This can also be extended to other parties such as divisions within a very large company or, for example, local law enfuL.
in certain foreign nations that have no warrant require-ments. Of course, all the information encrypted under 25 these keys could also be show~n in the clear, i.e. unen-crypted, as ~; ccllcc~(l earlier, providing that these parties have no objections to being openly named and routinely identif iable on every message . This inf ormation can also be omitted whenever a party is irrelevant, for example when 30 a user has no employer. The simplistic approach would be to use one MCH format for all situations, leaving fields blank when inapplicable. Otherwise, the preferred embodi-ment would be to utilize various different MCH formats within the same system, each format being identified by a 35 unique version number in the first field, such that each device processing a MCH would be able to dPt~rm; n-~ which f ields to expect and parse the MCH accordingly . This method would allow for an indef inite nesting of interested WO 9~119672 - 2 1 7 6 0 3 2 .
parties in the MCH, which would be the most flexible possi-ble system. The computational overhead would depend mainly on how many of those fields actually had to be encrypted under each respective party ' s public encryption key .
An employer can more easily conlrol the information that is ; n~ q in the MCH by accompanying each entry with - a "policy f ield" or an instructions code containing code instructing the employer's device as to what information to include in the MCH. As before, the instructions code could include elements of choice giving the employer options of including the following information: (l) the employer's name and unique identif ication number, either encrypted or using an alias; (2~ the word "employer" unencrypted, with the employer ' s unique identif ication number encrypted inside a MCH f ield; ( 3 ~ the user certif icate number in an encrypted field; (4) the message session key in an encrypted field; (5) a timestamp in an encrypted field; and (6) a random confounder number within any of the other encrypted fields. Nany of these options can be in effect simultaneously. In addition, these policy options would be the same for all members of the community of interest, including the parties to the communication themselves, thereby allowing the parties to be labeled by their mail or system IDs or simply by using the word "sender" or "receiver" in the relevant clear MCH fields.
MultiPle Simultaneous ~scrowed KeYs In addition to the above-described features for upgrading device f irmware routines and f or replacing manufacturer's public keys, the trusted device of the present invention should also have the ability to maintain and manage several sets of escrowed encryption keys - simultaneously. Normally, when the device begins the cycle of rekeying, i.e., generating and escrowing a new private decryption key, and as a result receives an escrow 35 certificate for the coLLt~ ding new public encryption key, the device will erase the previous private key in order to f orce reliance of the device on the newly escrowed Wo 95/1967~ ~ 2 1 7 6 0 3 2 private key. Alternatively, the device could retain the previous priYate key f or only a short time as needed, e . g .
f or the time needed to recover data encrypted into data storage using the previous private encryption key. How-5 ever, in an alternate embodiment, the device may alsoaccept and process a re-escrow instruction, either from the user or from the device owner as described above, to create a second valid escrow certif icate concerning the same pri-vate/public encryption key pair. In this ~rho~;r-ntl the lO device would proceed with the escrow process using quite possibly a different list of escrow agents and a different master escrow center, and would receive a different, equally valid escrow certificate for the same public/pri-vate encryption key pair that is signed and issued by the 15 second master escrow center and can be used interchangeably with the first escrow certificate. This second public encryption key certif icate can be of use in cases in which the device's user travels internationally or corresponds with parties located in other countries, especially when 20 those other nations may desire to conduct lawful surveil-lance of communications originating or terminating in that other nation. In such cases, by re-escrowing the same device key in another nation, the user ( or the user ' s employer) could help to satisfy possible legal requirements 25 in that other nation, while still allowing the user or employer the convenience of doing business with the ori-ginal set of escrow agents in his own nation (lawful owner monitoring, Lt~ C:Ly of lost key, etc. ) . Then, in order to allow the owner to track its employees ' IlCHs, it may be 30 enough if the sender and recipient owner IDs appeared in each MCH, thus telling the owner that it does indeed have the ability to obtain the key. To save time and effort, the owner may then send such an MCH to the foreign master escrow center to obtain the f oreign escrow certif icate 35 number, the underlying device number and the underlying device certificate, but then apply to its domestic escrow agents who can verify the owner's certificate already in their possession and release the actual private key splits.

W09s/19672 ~ 21 76032 r~"~
This procedure relieves the device owner of any extra legal formalities that might be required in order to obtain the actual ke~ splits from the foreign escrow agents.
National Ser!llrity Ex~ort SafequarAc The current policy of the United States ~-,v~, -nt is to allow unregulated use of encryption within the United States by American citizens but to impose heavy restrictions and penalties for the export of encryption devices, software or know-how. It ~is possible to modify the present system to allow relatively free private use of cryptographic devices in the United States while simul-taneously imposing restrictions on their international use.
Such a system could allow separ~te inter-operable "policy domains" that are open to all software and hardware vendors with minimal or no design changes to the standard message formats used throughout the system. It is further desir-able to allow the use of private escrow agents in purely intra CUL~U' ~ te~ single country situations, in which the key escrow system is being used solely to allow a particu-2 0 lar corporation to monitor and control its own employees ' uses of encryption, without any obligation, express or implied, to facilitate law enforcement access to ~ ic;~-tions that have been encrypted using keys the corporation has escrowed. In particular, such companies might buy the software and hardware for their own use but might decline to assume any public duty to provide access to private keys in short time frames, as might be desired by law enforce-ment in hot pursuit of criminals or terrorists.
This can be done by f irst assuming that all devices throughout the system are linked directly or indirectly to a system-wide authority (SWA) that (as previously dis-closed) issues certif icates to escrow agents, master escrow centers and device manufacturers in order to enable each to be recognized by devices within the system as being authen-tic and trustworthy. A national or global communications system must f or practical purposes support the existence of multiple and unrelated master escrow centers and agents, Wo 9S/19672 ~ 2 1 7 6 0 3 2 r ~
.
each of which must be certif ied by the SWA as being authentic. In each certif icate issued to a master escrow center or to an escrow agent, the SWA will designate it as either "public" or "private. " A "public" master escrow center or escrow agent is one that is equipped and committed to respond promptly to national security or law enforcement warrants and s~lhro~n~. Users whose keys are escrowed with such agents may be permitted to engage in transborder communications. A "private" master escrow center or escrow agent includes those single-company or single _~u-.L- ~ key centers that have installed key escrow system technology for their own use but do not undertake any commitment to a public level of service. The certifi-cate from the SWA to the master escrow center or escrow agent will also include a country code. Then, each user's escrow certificate that is issued and signed by a master escrow center and has the master escrow center SWA certif i-cate attached will also carry the user's country code.
Note that, as a matter of convenience, the user's escrow certificate should also state that it originates from either a public or non-public escrow agent, although it may not be possible for the SWA to enforce the cuLLa. ~l-ess of that information. This could allow the device to enforce these rules even more easily than always requiring the master e6crow center'6 SWA certificate.
FIGS. 29 and 30 show the enforcement of the e6crow requirement when 6ending and receiving international cryptographic communications. A6 6hown in FIG. 29, the tru6ted device 290 of the sender enforces this system by requiring the escrow certificates 291,293 of both the sender and the recipient, and, if the sender and recipient are not escrowed with the same master escrow center, their master escrow center SWA certificates 292,294, prior to 6ending an international ~ ; cAtion. The country code6 295,296 of the recipient user and its master escrow center must match in order for a sending device 290 to send a c i cAtion. Furthermore, if the sender and recipient are in different countries 295,297 and if either user is W095/19672 2176032 r~"~
.
using a non-public master escrow center 298, 29g, the sending device will refuse to originate a communication to that recipient. As shown in FIG. 30, the recipient trusted device 300 will also enforce this system by refusing to 5 decrypt a communication, if one is somehow originated, in which the sender and recipient are in different countries and if either user is using a non-public master escrow center. These rule6 will effectuate the desired policy of disallowing unescrowed international cryptographic communi-10 cations, because the master escrow center cannot falsifyits public status, which is certified by the SWA, and, even if the master escrow center could falsify the user's country code (to make the user appear to belong in a foreign domain), the devices will not allow a discrepancy 15 between the user's and the master escrow center's country codes. Although these rules do not prevent a user from ~ , _ U~t:L ly transporting his trusted encryption device across national boundaries, they do allow easy compliance with national requirements by permitting him to maintain an 20 escrowed key in each nation and to c~ ; cate using only the proper key in each policy domain.
Multi-User Device Versions ~
Another feature of this invention is the ability to initiate and simultaneously manage several different 25 sessions of communications with different local or remote users using the same device. Many larger computers support multiple users who are often simultaneously logged on via t~rm;n~l sessions but who may wish to initiate encrypted sessions with other entities around the world. ~lowever, 30 because it would be highly inefficient to require a separate trusted device for each user session on a shared computer, the trusted device could track the message session key for each communication by storing it along with a unique message sequence number (NSN) for that session.
35 Then, when any additional message packets bearing that MSN
arrive, they could be decrypted, and responses encrypted, without delay. Furthermore, the device could escrow the Wo gS/19672 21 7 6 0 3 2 r.~
private decryption keys of æeveral users while linking each user private key with a particular user unique identif ica-tion number and allowing each key to be used only on presentation of some suitable user authentication, such as 5 a pA~..JL-I, smart card, PIN, biometric, challenge response, etc . By assigning a user identif ication number and pass-word or the equivalent to each public/private key pair as it is generated ~or escrow, the usual controls on pass-Words, such as length, expiration, retry lockouts and ease 10 of gll~scin~ could then be imposed by the device in order to limit the possibility of unauthorized access.
Thus, a cryptographic system and method with key escrow feature is provided. One skilled in the art will appreciate that the present invention can be practiced by 15 other than the described ~nho~l; nts, which are presented for purposes of illustration and not limitation, and the present invention is limited only by the claims that ~ollow.

-

Claims (343)

What is claimed is:

1. A method for generating verifiably trusted private cryptographic digital communications among a plurality of users while enabling an external entity to monitor said communications, comprising the steps of:
escrowing with at least one trusted escrow center a plurality of asymmetric cryptographic keys to be used by a plurality of users for cryptographic communications;
certifying the escrow of each of said plurality of keys by said at least one escrow center;
encrypting a communication from a first user of said plurality of users to a second user of said plurality of users using a first key of said plurality of keys;
including with said encrypted communication a message control header containing information sufficient to identify said at least one trusted escrow center; and decrypting said encrypted communication by said second user of said plurality of users using a second key of said plurality of keys;
wherein said step of decrypting said encrypted communication by said second user is contingent upon certification of said keys of said first and second users and upon presence in said communication of a valid message control header.

2. The method of claim 1 wherein said step of encrypting a communication from said first user is contingent upon certification of said keys of said first and second users and upon presence in said communication of a valid message control header.

3. The method of claim 1 wherein said first user and said second user are identical such that said communication is encrypted from said first user to himself for storage .

4. The method of claim 1 wherein each user has a plurality of randomly generated asymmetric cryptographic keys comprising a plurality of matching pairs of public keys and private keys that are to be used for encryption and decryption of cryptographic communications, such that each user has at least one matching pair of public and private cryptographic keys.

5. The method of claim 4 wherein said step of escrowing further comprises, for each user, the steps of:
breaking the private key of said at least one matching pair of keys into shares;
providing each of at least one trustee with at least one share of said private key;
providing each of said at least one trustee with verification information to allow said trustee to verify the correct receipt of said at least one share of said private key; and verifying by said at least one trusted escrow center of correct receipt by each of said at least one trustee of said at least one share of said private key.

6. The method of claim 5 wherein said step of escrowing further comprises the step of encrypting a communication to said at least one escrow center containing said user private key, such that said step of breaking is performed by said escrow center.

7. The method of claim 6 wherein said step of encrypting a communication to said at least one escrow center containing said user private key further comprises the step of said user digitally signing said communication.

8. The method of claim 5 wherein said step of breaking further comprises breaking the private key of each user into N
shares such that all N shares are required in order to reconstruct said private key.

9. The method of claim 5 wherein said step of breaking further comprises breaking the private key of each user into N
shares such that, for M<N, only M shares are required in order to reconstruct said private key.

10. The method of claim 5 wherein said step of providing each of at least one trustee with at least one share of said private key further comprises the step of encrypting a communication to each of said at least one trustee containing said at least one share of said user private key.

11. The method of claim 10 wherein said step of providing each of at least one trustee with verification information further comprises the step of encrypting to each of said at least one trustee a communication containing said verification information.

12. The method of claim 11 wherein said step of encrypting a communication to each of said at least one trustee containing said at least one share of said user private key is performed by said user and further comprises the step of said user digitally signing said communication.

13. The method of claim 12 wherein said step of encrypting a communication to each of said at least one trustee containing said verification information is performed by said user and further comprises the step of said user digitally signing said communication.

14. The method of claim 13 wherein said step of encrypting a communication to each of said at least one trustee containing said at least one share of said user private key is performed by said escrow center and further comprises the step of said escrow center digitally signing said communication.

15. The method of claim 14 wherein said step of encrypting a communication to each of said at least one trustee containing said verification information is performed by said escrow center and further comprises the step of said escrow center digitally signing said communication.

16. The method of claim 5 wherein said step of verifying by said at least one escrow center comprises, for each trustee, the steps of:
notifying by said trustee to said escrow center of receipt of said at least one share of said private key of said user;

communicating by said trustee to said escrow center of said verification information; and validating by said escrow center of correct receipt by said trustee of said at least one share of said private key of said user based upon correct communication by said trustee of said verification information.

17. The method of claim 16 wherein said step of communicating by said trustee to said escrow center of said verification information comprises the step of encrypting a communication to said escrow center containing said verification information.

18. The method of claim 17 wherein said step of encrypting a communication to said escrow center containing said verification information further comprises the step of said trustee digitally signing said communication.

19. The method of claim 5 wherein each of said plurality of users has a unique digital identification code, and wherein said method further comprises the step of providing each of said at least one trustee with the unique digital identification code of said user.

20. The method of claim 1 wherein said step of certifying the escrow of each of said plurality of keys further comprises issuing an escrow certificate by said at least one escrow center for each of said plurality of cryptographic keys notarizing the connection between said cryptographic key and a corresponding user and attesting that said cryptographic key has been escrowed.

21. The method of claim 20 wherein said step of certifying the escrow of each of said plurality of keys further comprises the step of sending a copy of said escrow certificate to said corresponding user.

22. The method of claim 20 wherein said step of certifying the escrow of each of said plurality of keys further comprises the step of making said escrow certificate available to others of said plurality of users.

23. The method of claim 22 wherein said step of making said escrow certificate available comprises placing said escrow certificate in an escrow certificate directory accessible to such users.

24. The method of claim 1 further comprising the step of certifying the trustworthiness of said at least one trusted escrow center by a superior authority.

25. The method of claim 24 wherein said step of certifying the trusted escrow center comprises the step of issuing a certificate by said superior authority for each of said at least one trusted escrow center notarizing the trustworthiness of said escrow center f or the purpose of escrowing.

26. The method of claim 25 wherein said step of certifying the trusted escrow center further comprises the step of sending a copy of said superior authority certificate to said corresponding trusted escrow center.

27. The method of claim 25 wherein said step of certifying the trusted escrow center further comprises the step of making said superior authority certificate available to others of said plurality of users.

28. The method of claim 25 wherein said superior authority comprises a system-wide authority.

29. The method of claim 25 wherein said superior authority comprises at least one manufacturer of trusted devices.

30. The method of claim 29 wherein said step of certifying the trusted escrow center further comprises the step of issuing a manufacturer certificate by a system-wide authority for each of said at least one manufacturer of devices notarizing the trustworthiness of said at least one manufacturer of devices and attesting to the ability of each of said devices manufactured to randomly generate asymmetric cryptographic keys and to store said keys in a non-readable tamperproof manner.

31. The method of claim 30 wherein said step of certifying the trusted escrow center further comprises the step of sending a copy of said manufacturer certificate to said corresponding manufacturer.

32. The method of claim 30 wherein said step of certifying the trusted escrow center further comprises the step of sending a copy of said manufacturer certificate to the users of devices manufactured by said manufacturer.

33. The method of claim 4 wherein said step of certifying the escrow of each of said plurality of keys further comprises issuing an escrow certificate by one escrow center for each of said matching cryptographic key pairs notarizing the connection between said matching cryptographic key pair and a corresponding user and attesting that said private key of said matching cryptographic key pair has been escrowed.

34. The method of claim 33 wherein said step of certifying the escrow of each of said plurality of keys further comprises the step of sending a copy of said escrow certificate to said corresponding user.

35. The method of claim 33 wherein said step of certifying the escrow of each of said plurality of keys further comprises the step of making said escrow certificate available to others of said plurality of users.

36. The method of claim 35 wherein said step of making said escrow certificate available comprises placing said escrow certificate in an escrow certificate directory accessible to said users.

37. The method of claim 33 wherein said step of certifying the escrow of each of said plurality of keys further comprises verifying the escrow of the private key of each of said matching cryptographic key pair by said at least one escrow center prior to issuing said escrow certificate.

38. The method of claim 37 wherein said escrow certificate for said matching cryptographic key pair comprises an identification of said certificate issuing escrow center, a digital code identification of said escrow certificate, and said public key of said matching cryptographic key pair.

39. The method of claim 38 wherein said step of including a message control header comprises the step of forming a cryptographic message control header packet comprising an identification of said first user's escrow center and said digital code identification of said first user's escrow certificate.

40. The method of claim 39 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said second user's escrow center and said digital code identification of said second user's escrow certificate.

41. The method of claim 40 wherein:
said first user's escrow center and said second user's escrow center are identical; and said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said first and second users' escrow center and said digital identification codes of each of said escrow certificates.

42. The method of claim 39 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an employer or supervisor of said first user.

43 . The method of claim 42 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an employer or supervisor of said second user.

44. The method of claim 43 wherein:
said first user's employer or supervisor and said second user's employer or supervisor are identical;
said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said first and second users' employer or supervisor and said digital identification codes of each of said escrow certificates.

45. The method of claim 39 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising a timestamp indicating the date and time of formation of said message control header by said first user.

46. The method of claim 45 wherein:

said user has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the step of certifying the trustworthiness of said timestamp.

47. The method of claim 46 wherein said step of certifying the trustworthiness of said timestamp comprises issuing a certificate by a superior authority notarizing the trustworthiness of said timeclock for the purposes of generating said timestamps.

48. The method of claim 47 wherein said step of certifying said timestamp further comprises appending said timeclock certificate to each of said timestamps generated.

49. The method of claim 47 wherein said superior authority comprises a system-wide authority.

50. The method of claim 47 wherein said superior authority comprises the manufacturer of said timeclock.

51. The method of claim 46 wherein said superior authority comprises an escrow center, and said timeclock certificate is issued in said escrow certificate and is based on a determina-tion of the device manufacturer and device information during said escrow process.

52. The method of claim 39 further comprising the step of monitoring said cryptographic communication by said external entity having a wiretap authorization.

53. The method of claim 51 wherein said step of monitoring further comprises the steps of:

intercepting said encrypted communication by said external entity;
presenting said wiretap authorization and said message control header to said first user's escrow center;
obtaining the private key of said matching cryptographic key pair of said first user that has been escrowed with said first user's escrow center; and using said private key of said first user to decrypt said encrypted communication.

54. The method of claim 53 wherein said step of presenting further comprises the steps of:
extracting from said message control header said identification of said first user's escrow center and said digital identification code of said first user's escrow certificate; and presenting said wiretap authorization and said digital identification code of said first user's escrow certificate to said first user's escrow center.

55. The method of claim 54 wherein said first user has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the steps of:
forming a cryptographic message control header packet comprising a timestamp indicating the date and time of formation of said message control header by said first user; and certifying the trustworthiness of said timeclock for the purposes of generating timestamps.

56. The method of claim 55 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

57. The method of claim 53 wherein said wiretap authorization is subject to at least one predefined restriction.

58. The method of claim 57 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains a start date and time, before which said step of obtaining said private key of said first user may not occur.

59. The method of claim 58 wherein said at least one predefined restriction comprises a further time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said first user may not occur.

60. The method of claim 53 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said first user may not occur.

61. The method of claim 53 wherein said step of obtaining the private key of said first user further comprises the steps of:
retrieving said at least one share of said first user's private key from said at least one trustee; and reconstructing said private key from said retrieved shares of said private key.

62. The method of claim 61 wherein said step of obtaining is performed by said escrow center.

63. The method of claim 61 wherein said step of obtaining is performed by said external entity.

64. The method of claim 38 wherein said step of including a message control header comprises the step of forming a cryptographic message control header packet comprising an identification of said second user's escrow center and said digital identification code of said second user's escrow certificate.

65. The method of claim 64 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an employer or supervisor of said second user.

66. The method of claim 64 further comprising the step of monitoring said cryptographic communication by said external entity having a wiretap authorization.

67. The method of claim 66 wherein said step of monitoring further comprises the steps of:
intercepting said encrypted communication by said external entity;
presenting said wiretap authorization and said message control header to said second user's escrow center;
obtaining the private key of said matching cryptographic key pair of said second user that has been escrowed with said second user's escrow center; and using said private key of said second user to decrypt said encrypted communication.

68. The method of claim 67 wherein said step of presenting further comprises the steps of:
extracting from said message control header said identification of said second user's escrow center and said digital identification code of said second user's escrow certificate; and presenting said wiretap authorization and said digital code identification of said second user's escrow certificate to said second user's escrow center.

69. The method of claim 68 wherein said first user has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the steps of:

forming a cryptographic message control header packet comprising a timestamp indicating the date and time of formation of said message control header by said first user; and certifying the trustworthiness of said timeclock for the purposes of generating timestamps.

70. The method of claim 69 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

71. The method of claim 67 wherein said wiretap authorization is subject to at least one predefined restriction.

72. The method of claim 71 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains a start date and time, before which said step of obtaining said private key of said second user may not occur.

73. The method of claim 72 wherein said at least one predefined restriction comprises a further time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said second user may not occur.

74. The method of claim 73 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said second user may not occur.

75. The method of claim 67 wherein said step of obtaining the private key of said second user further comprises the steps of:
retrieving said at least one share of said second user's private key from said at least one trustee; and reconstructing said private key from said retrieved shares of said private key.

76. The method of claim 75 wherein said step of obtaining is performed by said escrow center.

77. The method of claim 75 wherein said step of obtaining is performed by said external entity.

78. The method of claim 4 wherein for each matching pair within said plurality of matching pairs of public keys and private keys, only said private key can decrypt communications encrypted using said public key.

79. The method of claim 78 wherein said first key of said plurality of keys used by said first user to encrypt said communication to said second user comprises a public key of said second user.

80. The method of claim 78 wherein said second key of said plurality of keys used by said second user to decrypt said encrypted communication comprises a private key of said second user.

81. The method of claim 1 wherein said step of encrypting a communication further comprises the steps of:
generating a unique cipher key for use in both encrypting and decrypting cryptographic communications between said first and second users; and encrypting said communication to said second user by said first user using said cipher key.

82. The method of claim 81 wherein said step of generating a unique cipher key comprises the steps of:
computing an intermediate number of said second user by said second user using a private key of said second user and at least one public number;
obtaining said second user's intermediate number by said first user; and computing said cipher key by said first user using a private key of said first user and said intermediate number of said second user;

such that said communication from said first user to said second user encrypted with said cipher key can be decrypted only with said cipher key.

83. The method of claim 82 wherein said intermediate number of said second user and said at least one public number comprise a public key of said second user.

84 . The method of claim 82 wherein said first key of said plurality of keys used by said first user to encrypt said communication to said second user comprises said private key of said first user used in said step of computing said cipher key.

85. The method of claim 82 wherein said second key of said plurality of keys used by said second user to decrypt said encrypted communication comprises said private key of said second user used in said step of computing an intermediate number.

86. The method of claim 82 further comprising the step of computing an intermediate number of said first user by said first user using a private key of said first user and said at least one public number.

87. The method of claim 86 wherein said step of including a message control header further comprises the step of forming a message control header packet comprising said intermediate number of said first user and said at least one public number.

88. The method of claim 87 wherein said step of decrypting said encrypted communication by said second user further comprises the steps of:
computing said cipher key by said second user using said private key of said second user and said intermediate number of said first user; and decrypting said communication from said first user by said second user using said cipher key.

89. The method of claim 81 wherein said step of generating a unique cipher key comprises the step of generating said cipher key interactively by each of said first and second users.

90. The method of claim 89 wherein said step of generating said cipher key interactively by each of said first and second users comprises the steps of:
computing a first intermediate number by said first user using a private key of said first user and at least one public number;
computing a second intermediate number by said second user using a private key of said second user and said at least one public number;
computing said cipher key by said first user using said private key of said first user and said second intermediate number; and computing said cipher key by said second user using said.private key of said second user and said first intermediate number;
such that said a communication either from said first user to said second user or from said second user to said first user encrypted using said cipher key can be decrypted only with said cipher key.

91. The method of claim 90 wherein said first key of said plurality of keys used by said first user to encrypt said communication to said second user comprises said private key of said first user used in said step of computing a first intermediate number.

92. The method of claim 90 wherein said second key of said plurality of keys used by said second user to decrypt said encrypted communication comprises said private key of said second user used in said step of computing a second intermediate number.

93. The method of claim 90 wherein said step of decrypting said encrypted communication by said second user further comprises the step of decrypting by said second user of said communication from said first user with said cipher key.

94. In a cryptographic system having a plurality of trusted devices, each trusted device having at least one matching pair of randomly generated asymmetric cryptographic keys wherein a public key of said matching pair of keys is used for encryption of cryptographic communications to said device and a corresponding private key of said matching pair of keys is used for decryption of said cryptographic communications, a method for generating verifiably trusted cryptographic communications among a plurality of devices while enabling an external entity to monitor said communications, comprising the steps of:
escrowing with at least one trusted escrow center at least one private key of said matching pair of cryptographic keys for each of said trusted devices;
certifying the escrow of said private key of said matching pair of keys of each of said devices by said at least one escrow center;
encrypting a communication from a first of said devices to a second of said devices using a public key of said matching pair of keys of said second device;
including with said encrypted communication a message control header containing information sufficient to identify said at least one trusted escrow center; and decrypting said encrypted communication by said second device using a private key of said matching pair of keys of said second device;
wherein said step of decrypting said encrypted communication by said second device is contingent upon certification of said private keys of each of said first and second devices and upon presence in said communication of a valid message control header.

95. The method of claim 94 wherein said step of encrypting a communication from said first device is contingent upon certification of said private keys of each of said first and second devices and upon presence in said communication of a valid message control header.

96. The method of claim 94 wherein, for each of said at least one matching pair of asymmetric cryptographic keys, only said private key can decrypt communications encrypted using said public key.

97. The method of claim 94 wherein said first device and said second device are identical such that said communication is encrypted from said first device to itself for storage.

98. The method of claim 94 wherein each trusted device has the ability to randomly generate said at least one matching cryptographic key pair and store said pair of keys in a secure, tamper-resistant and non-readable fashion.

99. The method of claim 98 wherein each said trusted device has a manufacturer, further comprising the step of certifying by a superior authority of the ability of said device to randomly generate and store said keys.

100. The method of claim 99 wherein said step of certifying the manufacturer comprises the step of issuing a certificate by said superior authority for said manufacturer notarizing the trustworthiness of said manufacturer and the ability of said device to randomly generate and store said keys.

101. The method of claim 99 wherein said superior authority comprises a system-wide authority.

102. The method of claim 94 wherein said step of escrowing further comprises, for each trusted device, the steps of:
breaking said private key into shares;
providing each of at least one trustee with at least one share of said private key;
providing each of said at least one trustee with verification information to allow said trustee to verify the correct receipt of said at least one share of said private key; and verifying by said at least one trusted escrow center of correct receipt by each of said at least one trustee of said at least one share of said private key.

103. The method of claim 102 wherein:

each of said at least one trusted escrow center has at least one matching pair of public and private cryptographic keys that are to be used for encryption and decryption of cryptographic communications; and said step of escrowing further comprises the step of encrypting a communication to said at least one escrow center containing said trusted device private key, such that said step of breaking is performed by said escrow center.

104. The method of claim 103 wherein:
said encryption keys of said at least one trusted escrow center are preembedded in said trusted device by the manufacturer of said device, such that a group of at least one escrow center has been chosen by said manufacturer for escrow purposes; and said step of escrowing further comprises the step of encrypting a communication containing at least one share of said private key to one escrow center from among said group of at least one escrow center using one of said preembedded escrow center encryption keys.

105. The method of claim 103 wherein said encryption key of said at least one escrow center is obtained by said device from an escrow certificate directory accessible to said device.

106. The method of claim 103 wherein said step of encrypting a communication to said at least one escrow center containing said trusted device private key is performed by said device and further comprises the step of said device digitally signing said communication.

107. The method of claim 102 wherein:
each of said at least one trustee has at least one matching pair of public and private cryptographic keys that are to be used f or encryption and decryption of cryptographic communications; and said step of breaking is performed by said device.

108. The method of claim 107 wherein:

said encryption keys of said at least one trustee are preembedded in said trusted device by the manufacturer of said device, such that a group of said at least one trustee has been chosen by said manufacturer for escrow purposes; and said step of providing each of at least one trustee with at least one share of said private key further comprises the step of encrypting a communication with at least one share of said private key to each of at least one trustee from among said group of said at least one trustee using one of said preembedded trustee encryption keys.

109. The method of claim 108 wherein said step of encrypting a communication to each of said at least one trustee is performed by said device and further comprises the step of said device digitally signing said communication.

110. The method of claim 108 wherein said step of providing each of at least one trustee with at least one share of said private key further comprises the step of encrypting a communication to said escrow center comprising an identification of each of said at least one trustee that received a share of said private key.

111. The method of claim 108 wherein said step of providing each of at least one trustee with verification information further comprises the step of encrypting to each of said at least one trustee a communication containing said verification information.

112. The method of claim 111 wherein said step of encrypting a communication to each of said at least one trustee containing said verification information is performed by said device and further comprises the step of said device digitally signing said communication.

113. The method of claim 111 wherein said step of providing each of at least one trustee with verification information further comprises the step of encrypting a communication to said escrow center comprising (a) an identification of each of said at least one trustee that received said verification information and (b) said verification information.

114. The method of claim 102 wherein said step of breaking further comprises breaking said private key into N shares such that all N shares are required in order to reconstruct said private key.

115. The method of claim 102 wherein said step of breaking further comprises breaking said private key into N shares such that, for M<N, only M shares are required in order to reconstruct said private key.

116. The method of claim 102 wherein said step of providing each of at least one trustee with at least one share of said private key further comprises the step of encrypting a communication to each of said at least one trustee containing said at least one share of said private key.

117. The method of claim 116 wherein said step of encrypting a communication to each of said at least one trustee containing said at least one share of said device private key further comprises the step digitally signing said communication.

118. The method of claim 116 wherein said step of providing each of at least one trustee with verification information further comprises the step of encrypting to each of said at least one trustee a communication containing said verification information.

119. The method of claim 118 wherein said step of encrypting a communication to each of said at least one trustee containing said verification information further comprises the step of said escrow center digitally signing said communication.

120. The method of claim 102 wherein said step of verifying by said at least one escrow center comprises, for each trustee, the steps of:
notifying by said trustee to said escrow center of receipt of said at least one share of said private key of said device;
communicating by said trustee to said escrow center of said verification information; and validating by said escrow center of correct receipt by said trustee of said at least one share of said private key of said device based upon correct communication by said trustee of said verification information.

121. The method of claim 120 wherein said step of communicating by said trustee to said escrow center of said verification information comprises the step of encrypting a communication to said escrow center containing said verification information.

122. The method of claim 121 wherein said step of encrypting a communication to said escrow center containing said verification information further comprises the step of said trustee digitally signing said communication.

123. The method of claim 102 wherein each of said plurality of trusted devices has a unique digital identification code, and wherein said method further comprises the step of providing each of said at least one trustee with the unique digital identification code of said device.

124. The method of claim 102 further comprising the step of certifying the trustworthiness of said at least one trusted escrow center by a superior authority.

125. The method of claim 124 wherein said step of certifying the trusted escrow center comprises the step of issuing a certificate by said superior authority for each of said at least one trusted escrow center notarizing the trustworthiness of said escrow center for the purpose of escrowing.

126. The method of claim 125 wherein said superior authority comprises a system-wide authority.

127. The method of claim 125 wherein said superior authority comprises at least one manufacturer of devices.

128. The method of claim 127 wherein said step of certifying the trusted escrow center further comprises the step of issuing a certificate by a system-wide authority for each of said at least one manufacturer of devices notarizing the trustworthiness of said at least one manufacturer of devices and attesting to the ability of each of said devices manufactured to randomly generate matching pairs of asymmetric cryptographic keys and to store said keys in a non-readable tamperproof manner.

129. The method of claim 94 wherein said step of certifying the escrow of said private key further comprises the step of issuing an escrow certificate by one escrow center for each of said matching cryptographic key pairs of said device notarizing the connection between said public and private keys of said matching cryptographic key pair and a corresponding device, and attesting that said private key of said matching cryptographic key pair has been escrowed.

130. The method of claim 129 wherein said escrow certificate for each of said matching cryptographic key pairs comprises an identification of said certificate-issuing escrow center, a digital identification code of said escrow certificate, and said public key of said matching cryptographic key pair.

131. The method of claim 129 wherein said step of certifying the escrow of said private key further comprises, prior to said step of issuing said escrow certificate, the step of validating by said certificate-issuing escrow center of the escrow of said private key of said matching cryptographic key pair.

132. The method of claim 131 wherein said step of validating by said at least one escrow center comprises, for each trustee, the steps of:
notifying by said trustee to said escrow center of receipt of said at least one share of said private key of said device;
communicating by said trustee to said escrow center of said verification information; and verifying by said escrow center of correct receipt by said trustee of said at least one share of said private key of said device based upon correct communication by said trustee of said verification information.

133. The method of claim 132 wherein said step of communicating by said trustee to said escrow center of said verification information comprises the step of encrypting a communication to said escrow center containing said verification information.

134. The method of claim 133 wherein said step of encrypting a communication to said escrow center containing said verification information further comprises the step of said trustee digitally signing said communication.

135. The method of claim 131 wherein said escrow certificate for each of said matching cryptographic key pairs comprises an identification of said certificate-issuing escrow center, a digital identification code of said escrow certificate, an identification of said device, and said public key of said matching cryptographic key pair.

136. The method of claim 135 wherein said step of including a message control header comprises the step of forming a cryptographic message control header packet comprising an identification of said first device's escrow center and said digital identification code of said first device's escrow certificate.

137. The method of claim 136 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said second device's escrow center and said digital identification code of said second device's escrow certificate.

138. The method of claim 137 wherein:
said first device's escrow center and said second device's escrow center are identical;
said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said first and second devices escrow center and said digital identification codes of each of said escrow certificates.

139. The method of claim 136 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an owner of said first device or of an employer or supervisor of the user of said first device.

140. The method of claim 139 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an owner of said second device or of an employer or supervisor of the user of said second device.

141. The method of claim 140 wherein:
said owners of said first and second devices or said employers or supervisors of said users of said first and second devices are identical;
said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said owner, employer or supervisor and said digital identifications code of each of said escrow certificates.

142. The method of claim 136 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising a timestamp indicating the date and time of formation of said message control header by said first device.

143. The method of claim 142 wherein:
said device has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the step of certifying the trustworthiness of said timestamp.

144. The method of claim 143 wherein said step of certifying the trustworthiness of said timestamp comprises issuing a certificate by a superior authority notarizing the trustworthiness of said timeclock for the purposes of generating said timestamps.

145. The method of claim 144 wherein said step of certifying said timestamp further comprises appending said timeclock certificate to each of said timestamps generated.

146. The method of claim 144 wherein said superior authority timeclock comprises a system-wide authority.

147. The method of claim 144 wherein said superior authority timeclock comprises the manufacturer of said device.

148. The method of claim 144 wherein said superior authority timeclock comprises an escrow center.

149. The method of claim 143 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

150. The method of claim 143 wherein said timeclock can be set or calibrated only by an entity authorized by the manufacturer of said timeclock.

151. The method of claim 136 further comprising the step of monitoring said cryptographic communication by said external entity having a wiretap authorization.

152. The method of claim 151 wherein said step of monitoring further comprises the steps of:
intercepting said encrypted communication by said external entity;
presenting said wiretap authorization and said message control header to said first device's escrow center;
obtaining the private key of said matching cryptographic key pair of said first device, which private key has been escrowed with said first device's escrow center; and using said private key of said first device to decrypt said encrypted communication.

153. The method of claim 152 wherein said step of presenting further comprises the steps of:

extracting from said message control header said identification of said first device's escrow center and said digital identification code of said first device's escrow certificate; and presenting said wiretap authorization and said digital identification code of said first device's escrow certificate of said first device to said first device's escrow center.

154. The method of claim 153 wherein said first device has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the steps of:
forming a cryptographic message control header packet comprising a timestamp indicating the date and time of formation of said message control header by said first device; and certifying the trustworthiness of said timeclock for the purposes of generating timestamps.

155. The method of claim 154 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

156. The method of claim 151 wherein said step of using said private key of said first device to decrypt said communication is performed by said external entity.

157. The method of claim 152 wherein said step of using said private key of said first device to decrypt said communication is performed by said escrow center.

158. The method of claim 152 wherein said wiretap authorization is subject to at least one predefined restriction.

159. The method of claim 158 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains a start date and time, before which said step of using said private key to decript said communication may not occur.

160. The method of claim 158 wherein said at least one predefined restriction comprises a further time restriction, such that said wiretap authorization contains an end date and time, after which said step of using said private key to decript said communication may not occur.

161. The method of claim 158 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains an end date and time, after which said step of using said private key to decript said communication may not occur.

162. The method of claim 152 wherein said step of obtaining the private key of said first device further comprises the steps of:
retrieving said at least one share of said first device's private key from said at least one trustee; and reconstructing said private key from said retrieved shares of said private key.

163. The method of claim 162 wherein said step of obtaining is performed by said escrow center.

164. The method of claim 162 wherein said step of obtaining is performed by said external entity.

165. The method of claim 162 wherein:
said step of breaking further comprises breaking said private key into N shares such that all N shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving each of said at least one share of said private key from each of said at least one trustee such that all N shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from all said N retrieved shares of said private key.

166. The method of claim 162 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said at least one device private key share, such that said step of reconstructing said private key is performed by said external entity.

167. The method of claim 166 wherein said step of encrypting a communication to said external entity containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

168. The method of claim 165 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said at least one private key share, such that said step of reconstructing said private key is performed by said escrow center.

169. The method of claim 168 wherein said step of encrypting a communication to said escrow center containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

170. The method of claim 162 wherein:
said step of breaking further comprises breaking said private key into N shares such that, for M<N, only M shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving said at least one share of said private key from said at least one trustee such that at least M
shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from said at least M retrieved shares of said private key.

171. The method of claim 170 wherein said step of retrieving at least M shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said device private key share, such that said step of reconstructing said private key is performed by said external entity.

172. The method of claim 171 wherein said step of encrypting a communication to said external entity containing said device private key share further comprises the step of said trustee digitally signing said communication.

173. The method of claim 170 wherein said step of retrieving at least M shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said device private key share, such that said step of reconstructing said private key is performed by said escrow center.

174. The method of claim 173 wherein said step of encrypting a communication to said escrow center containing said device private key share further comprises the step of said trustee digitally signing said communication.

175. The method of claim 135 wherein said step of including a message control header comprises the step of forming a cryptographic message control header packet comprising an identification of said second device's escrow center and said digital identification code of said second device's escrow certificate.

176. The method of claim 175 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an owner of said second device or of an employer or supervisor of the user of said second device.

177. The method of claim 175 further comprising the step of monitoring said cryptographic communication by said external entity having a wiretap authorization.

178. The method of claim 177 wherein said step of monitoring further comprises the steps of:
intercepting said encrypted communication by said external entity;

presenting said wiretap authorization and said message control header to said second device's escrow center;
obtaining the private key of said matching cryptographic key pair of said second device, which private key has been escrowed with said second device's escrow center; and using said private key of said second device to decrypt said encrypted communication.

179. The method of claim 178 wherein said step of presenting further comprises the steps of:
extracting from said message control header said identification of said second device's escrow center and said digital code identification of said second device's escrow certificate; and presenting said wiretap authorization and said digital code identification of said second device's escrow certificate to said second device's escrow center.

180. The method of claim 179 wherein said first device has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the steps of:
forming a cryptographic message control header packet comprising a timestamp indicating the date and time of formation of said message control header by said first device; and certifying the trustworthiness of said timeclock for the purposes of generating timestamps.

181. The method of claim 180 wherein said step of certifying the trustworthiness of said timestamp comprises issuing a certificate by a superior authority notarizing the trustworthiness of said timeclock for the purposes of generating said timestamps.

182. The method of claim 181 wherein said step of certifying said timestamp further comprises appending said timeclock certificate to each of said timestamps generated.

183. The method of claim 181 wherein said superior authority comprises a system-wide authority.

184. The method of claim 181 wherein said superior authority comprises the manufacturer of said device.

185. The method of claim 181 wherein said superior authority comprises an escrow center.

186. The method of claim 180 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

187. The method of claim 180 wherein said trusted timeclock can be reset or recalibrated only by an entity designated by the manufacturer.

188. The method of claim 178 wherein said step of using said private key of said second device to decrypt said communication is performed by said external entity.

189. The method of claim 178 wherein said step of using said private key of said second device to decrypt said communication is performed by said escrow center.

190. The method of claim 178 wherein said wiretap authorization is subject to at least one predefined restriction.

191. The method of claim 190 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains a start date and time, before which said step of obtaining said private key of said second device may not occur.

192. The method of claim 190 wherein said at least one predefined restriction comprises a further time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said second device may not occur.

193. The method of claim 190 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said second device may not occur.

194. The method of claim 178 wherein said step of obtaining the private key of said second device further comprises the steps of:
retrieving said at least one share of said second device's private key from each of said at least one trustee; and reconstructing said private key from said retrieved shares of said private key.

195. The method of claim 194 wherein said step of obtaining is performed by said escrow center.

196. The method of claim 194 wherein said step of obtaining is performed by said external entity.

197. The method of claim 194 wherein:
said step of breaking further comprises breaking said private key into N shares such that all N shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving each of said at least one share of said private key from each of said at least one trustee such that all N shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from all said N retrieved shares of said private key.

198. The method of claim 197 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said at least one device private key share, such that said step of reconstructing said private key is performed by said external entity.

199. The method of claim 198 wherein said step of encrypting a communication to said external entity containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

200. The method of claim 197 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said at least one device private key share, such that said step of reconstructing said private key is performed by said escrow center.

201. The method of claim 200 wherein said step of encrypting a communication to said escrow center containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

202. The method of claim 194 wherein:
said step of breaking further comprises breaking said private key into N shares such that, for M<N, only M shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving said at least one share of said private key from said at least one trustee such that at least M
shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from said at least M retrieved shares of said private key.

203. The method of claim 202 wherein said step of retrieving at least M shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said device private key share, such that said step of reconstructing said private key is performed by said external entity.

204. The method of claim 203 wherein said step of encrypting a communication to said external entity containing said device private key share further comprises the step of said trustee digitally signing said communication.

205. The method of claim 202 wherein said step of retrieving at least M shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said device private key share, such that said step of reconstructing said private key is performed by said escrow center.

206. The method of claim 205 wherein said step of encrypting a communication to said escrow center containing said device private key share further comprises the step of said trustee digitally signing said communication.

207. The method of claim 94 wherein said step of encrypting a communication further comprises the steps of:
generating a unique cipher key for use in both encrypting and decrypting cryptographic communications between said first and second devices; and encrypting by said first device of said communication to said second device with said cipher key.

208. The method of claim 207 wherein said step of generating a unique cipher key comprises the steps of:
computing an intermediate number of said second device by said second device using said private key of said second device and at least one public number;
obtaining said second user's intermediate number by said first user; and computing said cipher key by said first device using said private key of said first device and said intermediate number of said second device;
such that said communication from said first device to said second device encrypted using said cipher key can be decrypted only using said cipher key.

209. The method of claim 208 wherein said private key of said second device is randomly generated by said second device.

210. The method of claim 208 wherein said intermediate number of said second device comprises said public key of said second device.

211. The method of claim 208 wherein said intermediate number of said second device and said at least one public number comprise said public key of said second device.

212. The method of claim 208 further comprising the step of computing an intermediate number of said first device by said first device using said private key of said first device and said at least one public number.

213. The method of claim 212 wherein said private key of said first device is randomly generated by said first device.

214. The method of claim 212 wherein said step of including a message control header further comprises the step of forming a message control header packet comprising said intermediate number of said first device and said at least one public number.

215. The method of claim 214 wherein said step of decrypting said encrypted communication by said second device further comprises the steps of:
computing said cipher key by said second device using said private key of said second device and said intermediate number of said first device; and decrypting said communication from said first device by said second device using said cipher key.

216. The method of claim 207 wherein said step of generating a unique cipher key comprises the step of generating said cipher key interactively by each of said first and second devices.

217. The method of claim 216 wherein said step of generating said cipher key interactively by each of said first and second devices comprises the steps of:
computing a first intermediate number by said first device using said private key of said first device and at least one public number;

computing a second intermediate number by said second device using said private key of said second device and said at least one public number;
computing said cipher key by said first device using said private key of said first device and said second intermediate number; and computing said cipher key by said second device using said private key of said second device and said first intermediate number;
such that said a communication either from said first device to said second device or from said second device to said first device encrypted using said cipher key can be decrypted only with said cipher key.

218. The method of claim 217 wherein said private key of said first device is randomly generated by said first device.

219. The method of claim 217 wherein said private key of said second device is randomly generated by said second device.

220. The method of claim 217 wherein said step of decrypting said encrypted communication by said second device further comprises the step of decrypting by said second device of said communication from said first device using said cipher key.

221. In a cryptographic system having a plurality of trusted devices, each trusted device having at least two matching pairs of randomly generated asymmetric cryptographic keys, wherein a public key of the first matching pair of keys is used for encryption of cryptographic communications to said device and a corresponding private key of said first matching pair of keys is used for decryption of said cryptographic communications, and wherein a private key of the second matching pair of keys is used for digitally signing digital data and a corresponding public key of said second matching pair of keys is used for verification of said digital signature, a method for generating verifiably trusted cryptographic communications among a plurality of user devices while enabling an external entity to monitor said communications, comprising the steps of:

escrowing with at least one escrow center at least one private decryption key of each of said trusted devices;
certifying the escrow of said at least one private decryption key of each of said devices by said at least one escrow center;
certifying at least one private signature key of each of said devices;
encrypting a communication from a first of said user devices to a second of said user devices using a public encryption key of said second device;
including with said encrypted communication a message control header containing information sufficient to identify said at least one trusted escrow center; and decrypting said encrypted communication by said second device using a private decryption key of said second device;
wherein said step of decrypting said encrypted communication by said second device is contingent upon certification of said private decryption keys of each of said first and second devices and upon presence in said communication of a valid message control header.

222. The method of claim 221 wherein said step of encrypting a communication from said first device is contingent upon certification of said private decryption keys of each of said first and second devices and upon presence in said communication of a valid message control header.

223. The method of claim 221 wherein said first device and said second device are identical such that said communication is encrypted from said first device to itself for storage.

224. The method of claim 221 wherein each trusted device has the ability to randomly generate said at least two matching cryptographic key pairs for encryption and decryption and for signature and verification, and the ability to store each of said pairs of keys in a secure, tamper-resistant and non-readable fashion.

225. The method of claim 224 wherein each said trusted device has a manufacturer, and said step of certifying at least one private signature key further comprises the step of certifying by a superior authority of the ability of said device to randomly generate and store said keys.

226. The method of claim 225 wherein said step of certifying the ability of said device further comprises the step of issuing a manufacturer certificate by said superior authority notarizing the trustworthiness of said manufacturer and the ability of devices manufactured by said manufacturer to randomly generate and store said keys in a non-readable tamperproof manner.

227. The method of claim 226 wherein said superior authority comprises a system-wide authority.

228. The method of claim 226 wherein said manufacturer certificate is appended to each signature issued using a private signature key generated by said manufacturer.

229. The method of claim 221 further comprising the step of certifying the trustworthiness of said at least one escrow center by a superior authority.

230. The method of claim 229 wherein said step of certifying the escrow center comprises the step of issuing a certificate by said superior authority for each of said at least one escrow center notarizing the trustworthiness of said escrow center for the purpose of escrowing.

231. The method of claim 230 wherein said superior authority comprises a system-wide authority.

232. The method of claim 230 wherein said superior authority comprises at least one manufacturer of devices.

233. The method of claim 221 wherein said step of escrowing further comprises, for each user device, the steps of:
breaking said private decryption key into shares;
providing each of at least one trustee with at least one share of said private key;

providing each of said at least one trustee with verification information to allow said trustee to verify the correct receipt of said at least one share of said private key; and verifying by said at least one escrow center of correct receipt by each of said at least one trustee of said at least one share of said private key.

234. The method of claim 233 wherein each of said at least one escrow center comprises a trusted device, and said step of escrowing further comprises the step of encrypting a communication to said at least one escrow center containing said user private decryption key, such that said step of breaking is performed by said escrow center.

235. The method of claim 234 wherein said step of breaking further comprises breaking said private key into N shares such that all N shares are required in order to reconstruct said private key.

236. The method of claim 234 wherein said step of breaking further comprises breaking said private key into N shares such that, for M<N, only M shares are required in order to reconstruct said private key.

237. The method of claim 234 wherein:
the public encryption key of only one escrow center is preembedded in said user device by the manufacturer of said device, such that said escrow center has been chosen by said manufacturer for escrow purposes; and said step of escrowing further comprises the step of encrypting a communication to said escrow center using said preembedded escrow center encryption key.

238. The method of claim 234 wherein:
the public encryption keys of at least one escrow center are preembedded in said user device by the manufacturer of said device, such that a group of at least one escrow center has been chosen by said manufacturer for escrow purposes; and said step of escrowing further comprises the step of encrypting a communication containing at least one share of said private key to one of said group of at least one escrow center using one of said preembedded escrow center public encryption keys.

239. The method of claim 234 wherein said pubic encryption key of said at least one escrow center is obtained by said user device from an escrow certificate directory.

240. The method of claim 234 wherein said step of encrypting a communication to said at least one escrow center containing said user device private encryption key further comprises the step of said device digitally signing said communication using said private device signature key.

241. The method of claim 234 wherein said step of providing each of at least one trustee with at least one share of said private key further comprises the step of said escrow center encrypting a communication containing said at least one share of said private key to each of said at least one trustee.

242. The method of claim 241 wherein said step of encrypting a communication to each of said at least one trustee containing said at least one share of said device private key further comprises the step of said escrow center digitally signing said communication.

243. The method of claim 241 wherein said step of providing each of at least one trustee with verification information comprises the step of said escrow center including said verification information in said communication to said each of at least one trustee containing said at least one share of said private key.

244. The method of claim 243 wherein said step of encrypting a communication to each of said at least one trustee further comprises the step of said escrow center digitally signing said communication.

245. The method of claim 233 wherein each of said at least one trustee comprises a trusted device, and said step of breaking is performed by said device.

246. The method of claim 245 wherein said step of breaking further comprises breaking said private key into N shares such that all N shares are required in order to reconstruct said private key.

247. The method of claim 245 wherein said step of breaking further comprises breaking said private key into N shares such that, for M<N, only M shares are required in order to reconstruct said private key.

248. The method of claim 245 wherein:
the public encryption keys of said at least one trustee are preembedded in said user device by the manufacturer of said device, such that a group of at least one trustee has been chosen by said manufacturer for escrow purposes; and said step of providing each of at least one trustee with at least one share of said private key further comprises the step of said user device encrypting a communication containing at least one share of said private key to each of at least one trustee from among said group of at least one trustee using one of said preembedded trustee public encryption keys.

249. The method of claim 248 wherein said step of encrypting a communication to each of at least one trustee further comprises the step of said user device digitally signing said communication.

250. The method of claim 248 wherein said step of providing each of at least one trustee with at least one share of said private key further comprises the step of said user device encrypting a communication to said escrow center, for later user in said step of verifying, comprising an identification of each of said at least one trustee that received a share of said private key from said user device.

251. The method of claim 248 wherein said step of providing each of at least one trustee with verification information comprises the step of said user device including said verification information in said communication to said each of at least one trustee containing said at least one share of said private key.

252. The method of claim 251 wherein said step of encrypting a communication to each of said at least one trustee further comprises the step of said user device digitally signing said communication.

253. The method of claim 233 wherein said step of verifying by said at least one escrow center comprises, for each trustee, the steps of:
notifying by said trustee to said escrow center of receipt of said at least one share of said private key of said user device;
communicating by said trustee to said escrow center of said verification information; and validating by said escrow center of correct receipt by said trustee of said at least one share of said private key based upon correct communication by said trustee of said verification information.

254. The method of claim 253 wherein said step of communicating by said trustee of said verification information comprises the step of said trustee encrypting a communication to said escrow center containing said verification information.

255. The method of claim 254 wherein said step of encrypting a communication to said escrow center containing said verification information further comprises the step of said trustee digitally signing said communication.

256. The method of claim 233 wherein said step of certifying the escrow of said at least one private decryption key further comprises the step of issuing an escrow certificate by one escrow center for each matching key pair of each said user device notarizing the connection between said public and private keys and said corresponding device, and attesting that said private decryption key of said matching key pair has been escrowed.

257. The method of claim 256 wherein said step of certifying the escrow of said private decryption key further comprises, prior to said step of issuing said escrow certificate, the step of validating the escrow of said private decryption key.

258. The method of claim 257 wherein said step of validating the escrow of said private decryption key comprises, for each trustee, the steps of:
notifying said escrow center of receipt by said trustee of said at least one share of said device's private decryption key;
communicating said verification information by said trustee to said escrow center; and verifying by said escrow center of correct receipt by said trustee of said at least one share of said device's private decryption key based upon correct communication by said trustee of said verification information.

259. The method of claim 258 wherein said escrow center comprises a trusted device, and step of communicating said verification information by said trustee to said escrow center comprises the step of encrypting a communication to said escrow center containing said verification information.

260. The method of claim 259 wherein said trustee comprises a trusted device, and step of encrypting a communication to said escrow center further comprises the step of said trustee digitally signing said communication using a private signature key.

261. The method of claim 260 wherein said step of verifying further comprises verifying the signature of trustee on said communication containing said verifying information.

262. The method of claim 256 wherein said escrow certifi-cate comprises an identification of said certificate-issuing escrow center, a digital identification code of said escrow certificate, and said public encryption key corresponding to said escrowed private decryption key.

263. The method of claim 262 wherein said step of including with said encrypted communication a message control header comprises the step of forming a cryptographic message control header packet comprising an identification of said first user device's escrow center and said digital identification cord of said first user device's escrow certificate.

264. The method of claim 263 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said second user device's escrow center and said digital code identification of said second user device's escrow certificate.

265. The method of claim 264 wherein:
said first device's escrow center and said second user device's escrow center are identical;
said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said first and second devices' escrow center and said digital code identifications of each of said escrow certificates.

266. The method of claim 263 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an owner of said first user device or of an employer or supervisor of the user of said first user device.

267. The method of claim 266 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an owner of said second user device or of an employer or supervisor of the user of said second user device.

268. The method of claim 267 wherein:
said owners of said first and second user devices or said employers or supervisors of said users of said first and second user devices are identical;
said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of said owner, employer or supervisor and said digital code identifications of each of said escrow certificates.

269. The method of claim 263 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising a timestamp indicating the date and time of formation of said message control header by said first user device.

270. The method of claim 269 wherein:
each said trusted device has a timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the step of certifying the trustworthiness of said timestamp.

271. The method of claim 270 wherein said step of certifying the trustworthiness of said timestamp comprises issuing a certificate by a superior authority notarizing the trustworthiness of said timeclock for the purposes of generating said timestamps.

272. The method of claim 271 wherein said step of certifying said timestamp further comprises appending said timeclock certificate to each of said timestamps generated.

273. The method of claim 271 wherein said superior authority timeclock comprises a system-wide authority.

274. The method of claim 271 wherein said superior authority timeclock comprises the manufacturer of said device.

275. The method of claim 270 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

276. The method of claim 263 further comprising the step of monitoring said cryptographic communication by said external entity having a wiretap authorization.

277. The method of claim 276 wherein said step of monitoring further comprises the steps of:

intercepting said encrypted communication by said external entity;
presenting said wiretap authorization and said message control header to said first user device's escrow center;
obtaining the private decryption key of said first user device, which has been escrowed with said first user device's escrow center; and using said private decryption key of said first user device to decrypt said encrypted communication.

278. The method of claim 277 wherein said step of presenting further comprises the steps of:
extracting from said message control header said identification of said first user device's escrow center and said digital identification code of said first user device's escrow certificate; and presenting said wiretap authorization and said digital identification code of said first user device's escrow certificate to said first user device's escrow center.

279 . The method of claim 278 wherein said first user device has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the steps of:
forming a cryptographic message control header packet comprising a timestamp; and certifying the trustworthiness of said timeclock for the purposes of generating timestamps.

280. The method of claim 279 wherein said step of certifying the trustworthiness of said timestamp comprises issuing a certificate by a superior authority notarizing the trustworthiness of said timeclock for the purposes of generating said timestamps.

281. The method of claim 280 wherein said step of certifying said timestamp further comprises appending said timeclock certificate to each of said timestamps generated.

282. The method of claim 280 wherein said superior authority timeclock comprises a system-wide authority.

283. The method of claim 279 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

284. The method of claim 277 wherein said step of using said private decryption key of said first user device to decrypt said communication is performed by said external entity.

285. The method of claim 277 wherein said step of using said private decryption key of said first user device to decrypt said communication is performed by said escrow center.

286. The method of claim 277 wherein said wiretap authorization is subject to at least one predefined restriction.

287. The method of claim 286 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains a start date and time, before which said step of obtaining said private key of said first device may not occur.

288. The method of claim 287 wherein said at least one predefined restriction comprises a further time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said first device may not occur.

289. The method of claim 286 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said first device may not occur.

290. The method of claim 277 wherein said step of obtaining the private key of said first device further comprises the steps of:

retrieving said at least one share of said first user device's private key from said at least one trustee; and reconstructing said private key from said retrieved shares of said private key.

291. The method of claim 290 wherein said step of obtaining is performed by said escrow center.

292. The method of claim 290 wherein said step of obtaining is performed by said external entity.

293. The method of claim 290 wherein:
said step of breaking further comprises breaking said private key into N shares such that all N shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving each of said at least one share of said private key from each of said at least one trustee such that all N shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from all said N retrieved shares of said private key.

294. The method of claim 293 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said at least one device private key share, such that said step of reconstructing said private key is performed by said external entity.

295. The method of claim 293 wherein said step of encrypting a communication to said external entity containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

296. The method of claim 293 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said at least one device private key share, such that said step of reconstructing said private key is performed by said escrow center.

297. The method of claim 296 wherein said step of encrypting a communication to said escrow center containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

298. The method of claim 290 wherein:
said step of breaking further comprises breaking said private key into N shares such that, for M<N, only M shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving said at least one share of said private key from said at least one trustee such that at least M
shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from said at least M retrieved shares of said private key.

299. The method of claim 298 wherein said step of retrieving at least M shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said device private key share, such that said step of reconstructing said private key is performed by said external entity.

300. The method of claim 299 wherein said step of encrypting a communication to said external entity containing said device private key share further comprises the step of said trustee digitally signing said communication.

301. The method of claim 298 wherein said step of retrieving at least M shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said device private key share, such that said step of reconstructing said private key is performed by said escrow center.

302. The method of claim 301 wherein said step of encrypting a communication to said escrow center containing said device private key share further comprises the step of said trustee digitally signing said communication.

303. The method of claim 262 wherein said step of including with said encrypted communication a message control header comprises the step of forming a cryptographic message control header packet comprising an identification of said second user device's escrow center and said digital identification code of said second device's escrow certificate.

304. The method of claim 303 wherein said step of including a message control header further comprises the step of forming a cryptographic message control header packet comprising an identification of an owner of said second user device or of an employer or supervisor of the user of said second user device.

305. The method of claim 303 further comprising the step of monitoring said cryptographic communication by said external entity having a wiretap authorization.

306. The method of claim 305 wherein said step of monitoring further comprises the steps of:
intercepting said encrypted communication by said external entity;
presenting said wiretap authorization and said message control header to said second user device's escrow center;
obtaining the private decryption key of said second user device, which has been escrowed with said second user device's escrow center; and using said private decryption key of said second user device to decrypt said encrypted communication.

307. The method of claim 306 wherein said step of presenting f urther comprises the steps of:
extracting from said message control header said identification of said second user device's escrow center and said digital identification code of said second user device's escrow certificate; and presenting said wiretap authorization and said digital identification code of said second user device's escrow certificate to said second device's escrow center.

308. The method of claim 307 wherein said first device has a trusted timeclock for generating timestamps indicating the date and time of formation of said cryptographic communication and said message control header; and said step of including a message control header further comprises the steps of:
forming a cryptographic message control header packet comprising a timestamp; and certifying the trustworthiness of said timeclock for the purposes of generating timestamps.

309. The method of claim 309 wherein said step of certifying the trustworthiness of said timestamp comprises issuing a certificate by a superior authority notarizing the trustworthiness of said timeclock for the purposes of generating said timestamps.

310. The method of claim 309 wherein said step of certifying said timestamp further comprises appending said timeclock certificate to each of said timestamps generated.

311. The method of claim 309 wherein said superior authority timeclock comprises a system-wide authority.

312. The method of claim 309 wherein said superior authority timeclock comprises the manufacturer of said device.

313. The method of claim 308 wherein said trusted timeclock can be set or calibrated only by the manufacturer of said timeclock.

314. The method of claim 306 wherein said step of using said private decryption key of said second user device to decrypt said communication is performed by said external entity.

315. The method of claim 306 wherein said step of using said private decryption key of said second user device to decrypt said communication is performed by said escrow center.

316. The method of claim 306 wherein said wiretap authorization is subject to at least one predefined restriction.

317. The method of claim 316 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains a start date and time, before which said step of obtaining said private key of said second device may not occur.

318. The method of claim 317 wherein said at least one predefined restriction comprises a further time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said second device may not occur.

319. The method of claim 317 wherein said at least one predefined restriction comprises a time restriction, such that said wiretap authorization contains an end date and time, after which said step of obtaining said private key of said second device may not occur.

320. The method of claim 306 wherein said step of obtaining the private decryption key of said second user device further comprises the steps of:
retrieving said at least one share of said second user device's private key from each of said at least one trustee; and reconstructing said private key from said retrieved shares of said private key.

321. The method of claim 320 wherein said step of obtaining is performed by said escrow center.

322. The method of claim 320 wherein said step of obtaining is performed by said external entity.

323. The method of claim 320 wherein:
said step of breaking further comprises breaking said private key into N shares such that all N shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving each of said at least one share of said private key from each of said at least one trustee such that all N shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from all said N retrieved shares of said private key.

324. The method of claim 323 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said at least one device private key share, such that said step of reconstructing said private key is performed by said external entity.

325. The method of claim 324 wherein said step of encrypting a communication to said external entity containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

326. The method of claim 323 wherein said step of retrieving all N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said at least one device private key share, such that said step of reconstructing said private key is performed by said escrow center.

327. The method of claim 326 wherein said step of encrypting a communication to said escrow center containing said at least one device private key share further comprises the step of said trustee digitally signing said communication.

328. The method of claim 320 wherein:
said step of breaking further comprises breaking said private key into N shares such that, for M<N, only M shares are required in order to reconstruct said private key;
said step of retrieving said at least one share of said private key comprises retrieving said at least one share of said private key from said at least one trustee such that at least M
shares of said private key are retrieved; and said step of reconstructing said private key comprises reconstructing said private key from said at least N retrieved shares of said private key.

329. The method of claim 328 wherein said step of retrieving at least M shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said external entity containing said device private key share, such that said step of reconstructing said private key is performed by said external entity.

330. The method of claim 329 wherein said step of encrypting a communication to said external entity containing said device private key share further comprises the step of said trustee digitally signing said communication.

331. The method of claim 328 wherein said step of retrieving at least N shares of said private key further comprises, for each of said at least one trustee, the step of encrypting a communication to said at least one escrow center containing said device private key share, such that said step of reconstructing said private key is performed by said escrow center.

332. The method of claim 331 wherein said step of encrypting a communication to said escrow center containing said device private key share further comprises the step of said trustee digitally signing said communication.

333. A method of authorizing a trusted device to conduct an electronic transaction between a first user and a second party, and providing assurance that said trusted device will engage in said electronic transaction in accordance with predetermined rules which cannot be changed by the user, said method comprising:
electronically transmitting from said trusted device to a third party a request for authorization to engage in said electronic transaction, said request including the identity of said trusted device;

determining, by said third party, that said trusted device should be authorized to engage in said transaction, at least in part in accordance with a determination that said trusted device will operate in accordance with said rules;
electronically transmitting from said third party to said trusted device authorization to engage in said electronic transaction, said authorization including certification that said third party provided said authorization;
electronically transmitting from said trusted device to said second party said certification as assurance that said trusted device is authorized to engage in said electronic transaction and will do so only in accordance with said rules; and electronically transmitting transaction data from said trusted device to said second party in accordance with said rules.

334. A method as in claim 333 wherein said authorization transmitting step includes the step of transmitting said rules from said third party to said trusted device.

335. A method as in claim 333 wherein said trusted device contains said rules prior to said authorization transmitting step.

336. A method as in claim 333 wherein said authorization transmitting step includes the step of appending a digital signature of said third party to said certification.

337. A method as in claim 333 wherein said request transmitting step includes the step of transmitting certification of said identity of said trusted device digitally signed by a manufacturer of said trusted device.

338. A method as in claim 333 wherein said determining step includes the step of determining whether said device is tamper-resistant based upon said identity of said trusted device.

339. A method as in claim 333 wherein said trusted device has associated with it a public key and a private key of an assymetric cryptosystem and said request transmitting step includes the step of transmitting said device public key to said third party.

340. A method as in claim 337 wherein said identity certification includes a public key of a public-private key pair for said trusted device and said request transmitting step includes appending a digital signature of said trusted device created with said device private key to said request so that said third party can confirm that said request came from said trusted device.

341. A method as in claim 333 wherein said trusted device has associated with it a first key and a second key of an assymetric cryptosystem and said step of transmitting transaction data to said second party includes a step of appending a digital signature of said trusted device created with said first key.

342. A method as in claim 340 wherein said step of transmitting transaction data to said second party includes the step of transmitting said second key to said second party.

343. A method as in claim 341 or 342 wherein said first and second device keys are private and public keys, respectively.