CA2197206A1 - System and method for key escrow and data escrow encryption - Google Patents

System and method for key escrow and data escrow encryption

Info

Publication number
CA2197206A1
CA2197206A1 CA002197206A CA2197206A CA2197206A1 CA 2197206 A1 CA2197206 A1 CA 2197206A1 CA 002197206 A CA002197206 A CA 002197206A CA 2197206 A CA2197206 A CA 2197206A CA 2197206 A1 CA2197206 A1 CA 2197206A1
Authority
CA
Canada
Prior art keywords
user
drc
ari
access
drf
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002197206A
Other languages
French (fr)
Inventor
Steven B. Lipner
David M. Balenson
Carl M. Ellison
Stephen T. Walker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
McAfee LLC
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/289,602 external-priority patent/US5557346A/en
Application filed by Individual filed Critical Individual
Publication of CA2197206A1 publication Critical patent/CA2197206A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage

Abstract

A system and method for key escrow and data escrow cryptography are described. In key escrow cryptography, only public escrow keys are stored in the sender and the receiver. The sender encrypts a message using a secret session key (KS), and generates an encrypted leaf verification string (ELVS) and a first law enforcement access field (LEAF). The receiver generates a second LEAF for comparison with the first LEAF. In data escrow cryptography, an encrypting user generates a data recovery field (DRF), that includes an access rule index (ARI) and a user's secret (US). To recover US, a decrypting user sends the DRF to a data recovery center (DRC) that issues a challenge based on access rules (ARs) identified by the ARI. If the decrypting user meets the challenge, the DRC sends US to the decrypting user.

Description

WO 96ros673 2 1 9 7 2 ù 6 PcT~us9sJJo22l System and Method for Key Escrow and Data Escrow E~

Bach~ of the lnvention FYeld of the Invention The present mvention relates generally to data encryption, and more l~flni~,ul,llly to key escrow and data escrow encryption.

Related Art 1,.. ~ .

An United States Presidential ~ on April 16, 1993, referred to as the "Clipper initiative," called for the d.,v.,lv~lll.,lll of a hardware ;~pl~ ;"" of a classifed encryption algorithm called "Skipjack" . The Presidential ~nnn-mf f Tnf~nt f ~ rd the Skipjack algorithm as being ~ S~ .r~ ll.ly stronger than those currently available to thepublic." The hardware i".l,l....,..,lsl;.", of Skipjack would also include a capability called "key escrow" which allows the ~UV.,IIIIII~,IIl to recover the keys used for data encryption. The integrated circuit chip which ;,.. l,!~ .,.. -the Skipjack algorithm is called the "Clipper chip " and/or the "Capstone chip" .
The Clipper initiative (particularly the key escrow feature) attempts to preserve the ability of law UllrUl~,~lll.lll and national security to intercept and e~ploit the contents of u.,.. ~ ;... c while providing law-abiding citizens ~ 2~ with an encryption system much stronger than any now available to them.
The A~ '' of the Clipper initiative and the subsequent discussions made it clear that, while Skipjack is a stronger encryption algorithm than the 2 ~ 9 7 2 0 6 PCT/US95/10221 --2-- ~ ~

current ' ~ ' Data Encryption Standard (DES), law ~M UICI~ 1 entities considered that the ~)luli~claLiu~l of DES voice security devices would be a significant ;~ to their need to preserve the ability to :~rcnmrlich court-ordered wiretaps.
A great deal of resistance to the Clipper mitiative was evident in the public reaction to the April 16 . Objections were expressed m various forms, but the following key points stand out:

~ Many people objected to the potential for loss of privacy that would result from the dc~lvyll.~llL of key escrow ~lypiu~ la,uLy and the associated sharing of heretofore private ~ly~iu~la~Lic keys with gV.~llh~ll. escrow agents.

~ Many people raised objections to the ~ ..'s attempt to use the buying power of the gu~ hlll~,.lL to impose as de facto standards a family of encryption products that could be defeated at will by gU~.,IIUII-IIL agencies.

~ Some people objected to the hlLIuducliùll of a classified algorithm as the standard for the protection of ~ i. J
iuhrullllaLiu-l. DES is public and has had wide scrutiny in its fifteen year life. There were '"L.~' ~1;''''~ th~at Skipjack might have a defect or trap door (other than the key escrow process).
These objections were not quieted by the favorable review of Skipjack by a panel of outside ~lypl,~

~ Many people (especially suppliers of IM vllllaLiull Technology products) objected to the l~;UAUhCII~IIL for a hardware 21i i~ because of its cost and because of the limitations that the need to ~ nmmr ' ' a ~u ~ hll.,llL-designed chip hmposes on overall system or product design.

2t 97206 WO 96105673 PCT/lJS9~i/10221 In August 1993, the National Institute of Standards and Technology (NIST) anmounced a l,OV~ tiV~ program with industry to explore possible approaches to the;,, ~pl~ ;. " . of key escrow m software (without the need for dedicated hardware -----r ' such as the Clipper or Capstone chips).
There are a number of issues that mtertwme in any discussion of this topic. Such issues include hardware ;",pl " ~ .,. classified encryption :llg~lrithmc, and how much trust one must put in the user of the encryption process. These issues are considered below. However, before addressing these issues, it will be useful to consider key escrow.

~ey l~scrow Cr~ O,, 1,~

Key esc}ow adds to products that implement ~,lypLu~la~lly features that allow autborized parties to retrieve the keys for encrypted . and t_en decrypt the ,- ~ using such keys. In the Clipper initiative, keys for each encryption device are ~. - h. ~ ily divided into two halves (each equal in length to the original key) and the halves are held by two separate escrow agents. Both escrow agents must cooperate (to regenerate the orjginal key) before the ~ from a given device can be decrypted. For Clipper, the escrow agents are gUv~lllll~l~ agencies who require assurance that the law c. ~VI~ agency requesting the keys has a court order ~llth~\ri7ing a wiretap for the ~ in question.
A number of needs have been cited to justify key escrow ~ly~Lv~ hy .
Some apply to the needs of law c.lfv~ t and national security, while others apply to the needs of individual users or Ul~

- ~ Law ~ 'Ul~ -lt and national security agencies are concerned that growing use of encrypted c . ,.. , .. ~ will impair their ~ ability to use court-ordered Wil~ u;llg to solve crimes and prevent acts of terrorism. Widespread use of key escrow .,.y~u~ would preserve this ability for these agencies, _ ~ . _ _ _ , ~ . ~ . _ ... . .... . ... . .. . . _ wo s6/0s673 2 1 9 72 a 6 PCT/US95/10221 while providing the public with the benefits of good cluality ~,ly~u~ plly. In the case of law cl~rul~,..ll.,.lL and national security, yu~ IUII.IIL escrow agents provide access to c.",, ,;. ~ when authorized by a court order.

~i ~ Some ~,uluuldLiul~ have expressed a concern that careless or malicious ~ ' of keys by employees might deny the uul,uul~Liull access to its valuable i~Ull,., Liun. Key escrow cly~uLu~ lly at the corporate level has been advocated as a mechanism by which such corporations might regain access to their hlrullll~Liun. In this sort of qpplirqtinn one might have senior ~ or personnel offices serve as escrow agents who would permit an employee's supervisor to gain access to his or her files or ~..".., .; -li.."~

~ Individuals who use encryption for their own hl~ul~ Liu~ may forget or lose the passwords that protect their encryption keys, die, or become ;~ Key escrow ~,lypLu~ lly has been proposed as a safety mechanism for such individuals. In tbis case, an individual might select friends or attorneys as escrow agents who would allow the individual (or perhaps the executor of his or her estate) access to protected ;.,rO".,-~i ~ In some cases, ~uv.~ llL agencies have the authority to monitor the business c ., ~ "" . ~l innC of their employees . Such authority applies, for example, in military and national security incrqllqrinnc where it is used to detect the misuse of classified or sensitive infi~nqfinn Key escrow ~Iy~uLu~ hy offers such agencies the u~u~iulliiy to exercise their authority to monitor even for encrypted ~ ~ ~ " "~ In this application, S_ securit,v officers mlght serve as escrow agents who would grant access to line managers or ~

The Clipper initiative focuses on the first of the four .l~u~lic.~liu..~ for key escrow cited above. In addition, the Clipper initiative couples the S hlL udu~lion of key escrow with the introduction of Skipjack, a new classified encryption algorithm much stronger than the ~ d DES.
Opponents of the Clipper initiative have argued that a key escrow encryption system such as Clipper can be defeated by ~ users such as organrzed crime, who have the ability to write or buy their own encryption system (without key escrow) and either ignore the key escrow products altogether or encrypt first under their own system and then under the key escrow system. Other options are open to pairs of users who wish to cooperate to defeat key escrow, and some opponents of the Clipper initiative have suggested that the only way to deter such options is to forbid non-escrowed encryption by law and to enforce the law with a vigorous program of monitoring ~.. .....;~ ~~;.-.. ~--an n~ ~pP~ g prospect to say the least.
Proponents of the Clipper initiative counter that they are well aware that pairs of Cou~ d~ g users have many ways to avoid key escrow. The objective that these proponents cite is to make it difficult or impossible for asingle "rogue" user to ~ r securely with parties (or more precisely with escrowed encryption devices) that believe they are engaged in a ... l.ll.. ;l li... where both c... l.. l.. ,......... ;~ ~.1~ are faithfully fûllowing the escrow rules.
The "single rogue user" scenario constitutes a test for a key escrow system. A successful key escrow system (hardware or software) should prevent a single rogue user from exploiting the ~ IY,UIU~I~AUI-Y in the escrowedproduct, and from defeating or bypassing the product's key escrow features, ~ while still enabling secure ~.. ,.. ,;. -I;n~l with other users (products) that believe that they and the rogue user are ;~pl~ .1;~ the escrow features correctly.

, wo s6ros673 2 ~ 9 7 2 0 6 r 1"-~ S/~

The "Clipper" chip addresses the "single rogue user" by embedding the key for each individual ~ ~m session in a Law EllfUl~ lt Access Field (LEAF) that is encrypted under a secret key (the Family Key) that is common to all "Clipper" chips. the embedded i..r.,~ i.,.. includes a S checksum that depends on the session key. The receivmg "Clipper" chip also holds the Family Key; thus, it can decrypt the LEAF and verify that the checksum is the correct one for the current session key (which both chips must share in private for .. ,.. , " 1;.. to be successful and secure). All "Clipper" chips share the embedded Family Key and rely on the ~ luof hardware of the chip to protect the Family key from disclosure.

Hardware I, ' of Key Escrow CrJ, O,, '1~

There are several factors that support the decision to require the use of separate hardware in the design of the key escrow products proposed as part of the Clipper initiative (Clipper and Capstone chips). Some of these factors, discussed below, are related to the introduction of key escrow ~y~tu~ lly, some to the use of a classifed encryption algorithm, and some to the choice of a eul~ tiYe standard for the design of encryption products.

~ Separate hardware provides a degree of protection for the encryption process difficult to obtain in software systems. An errant or malicious computer program can not corrupt the encryption algorithm or key ,.~ embedded in a hardware encryption device such as the Clipper or Capstone chip.

~ Separate bardware provides a degree of protection for the key escrow process difficult to obtain in software systems. While software can manipulate the externally visible parameters of the 3 2 ~ 9 7 2 0 6 PCT/US95110221 . .

escrow process, hardware at least provides some assurance that the escrow operations are performed or verified.

~ If a classified encryption algoritbm such as Skipjack is used, separate hardware that; .1,~ special protective measures may be essential to protect the design of the algoritbm from disclosure.

~ Secret ~Iy~Lu~la~ , keys can be provided with a high degree of protection on a hardware device since u~ .ly~t~,d keys need never appear outside the device. In contrast, it is difficult or even impossible to protect secret keys embedded in software from users with physical control of the underlyrng computer hardware.

~ ~olif"aLi~J~. of an encryption capability is perceived to be easier to control with respect to accounting for controlled devices and restriction of exports with hardware devices than with embedded software.

The list above makes it clear that some of the need for hardware in the Clipper initiative derives from a need to protect the classified Skipjack algoritbm, some from ( ~ Live design of the encryption system, and some from a need to protect the escrow process.

Use of a Classified Data Enayptlon Algonthm .

The Skipjack encryption algorithm that was introduced with the Clipper irlitiative is claimed to be much stronger than existing publicly available algoritbms such as DES. Having a strong algorithm is a valuable sellmg point 25for any new encryption initiative. But, as the discussion above pomted out, . _ _ _ _ . _ _ _ . _ .. . . . ... .. .. ...

wo 96/0s673 -8- 2 1 9 7 2 0 6 PCTluS95110221 protecting a classified algorithm from disclosure requires, at least at the current state of technology, a hardware; " ,p~ ,, that embodies special measures to resist reverse ..~vi,.... ;,.~
Classified encryption algorithms are often considered much stronger than those in the public domain since the algorithms used to protect ..,at classifed ;~ r ~ are classified. But because they are not avai]able for public review, ~ that classified algoritbms be used to protect ~..,rl~ r~ are suspect due to the possible existence of unknown deliberate trapdoors or ..,.;,.~. ..I;IIIIAI flaws. While DES was initially viewed with suspicion by some7 it was subject to intense public scrutiny and its principal strength now is that even after fifteen years, no serious flaw hasbeen fouad.
Key escrow techniques as such do not require classified algoritbms and can be used with publicly available algorithms such as DES and IDEA or with proprietary but ~ :ri. d algorithms such as RSADSI's RC2 aad RC4. If a publicly available or proprietary ~~ :fi d algorithm were used in a product that embodied key escrow ~,ly~u~laplly, it would not be necessary to have a hardware ;~ ' i.... for the purpose of protecting the encryption algorithm from disclosure (although there are other reasons for hllpl~,lll~,...i..,5 key escrow ~Iy~JLu~l_plly in hardware, as the above list indicates).
This; ~ p fl ~ between hardware i. ,.p~ and classified algorithm has caused i...., :,1..,.I.lr confusion in examining the feasibility of software key escrow approaches. If one requires a classified algorithm, one must use hardware to protect the algorithm whether one i.. l,l . ~ key escrow or not. If one chooses an " . ,. 1~ ~i ri. ~ public or proprietary algorithm, one is free to implement in hardware or software. The decision to implement m hardware and software is driven by other factors, such as those identifled in the above list.

WO 96/05673 2 ~ 9 7 2 0 6 r~l,u~v~l g Benefits and ~ of Software F~

Historically, encryption systems tbat have been used to protect sensitive ; r~.. ." - i,... have been; ~l~L ~ ~s ~1 as separate hardware devices, usually outboard "boxes" between a computer or u system and a ~ circuit. Such devices are designed with a high level of checking for operational integrity in the face of failures or malicious attack, and with especially careful measures for the protection of ~Iy~L/~ Jh;_ fimctions and keys.
Software encryption systems have historically been viewed with suspicion because of their limited ability to protect their algorithms and keys.The paragraphs above discussed the issues associated with protecting classified (or secret) encryption algorithms from disclosure. Over and above these issues is the fact that an encryption algorithm ;,,,1.l .,. .,l~d m software is subject to a variety of attacks. The computer's operating system or a user can modify the code that i-~ the encryption algorithm to render it ineffective, steal secret ~,ly~L~ ;C keys from memory, or, worst of all, cause the product to leak its secret ~,ly~Lo~la~ ic keys each time it sends or receives an encrypted message.
The principal di~d ~ .IIIL..~ ,~, of usmg encryption hardware, and therefore the primary advantage of integrated software i"~ , is cost. When encryption is i.,.pl. ,. 1~ d in hardware, whether a chip, a board or peripheral(such as a PCMCIA card) or a box, end users have to pay the price. Vendors must purchase chips and design them into devices whose costs go up because of the additional "real estate" required for the chip. End users must purchase more expensive devices with integrated encryption hardware, or must buy PCMCL~ cards or similar devices and then pay the price for adding a device interface to their computing systems or dedicating an existing interface to encryption rather than another function such as that performed by a modem or disk.

WO 96105673 2 1 9 7 2 ~ ~ PCTlU~i95110221 -10- , A second major advantage of software i",~ is simplicity of operation. Software solutions can be readily integrated mto a wide variety of ,1;. ,.r;~.C Generally, the mass market software industry, which attempts to sell products in quantities of hundreds of thousands or millions, seeks to implement everything it can in software so as to reduce .1.1,. .-,11 .. ;~ on hardware variations and CO-'~;L-"~'~;I"'' and to provide users with a maxrmum of useful product for minimum cost Summary of the Invention The present mvention is directed to a system and method for key escrow ~Iy~lv2~ Ly for use in a system comprising a sender and a receiver.
By "sender" we mean a program or device that encrypts data for subsequent transport or storage. By "receiver" we mean a program or device that decrypts data that has been received or retrieved from storage. Only public keys are stored in vhe sender and the receiver so there is no need for secrecy of the software. According to a first .. 1,.. 1;.. ~ of the present invention, the sender encrypts a message using a secret session key (KS), and generates a leaf verification string (LVS) by combining an unique program idenvifier (UIP), a public portion of a program unique key (KUpub), and a signature.
The signature represents the UIP and KUpub signed by a private portion of a key escrow ~I~,v, .. ,." . .;.. g facility (KEPF) key (I~EPFpriv). An encrypted LVS
(ELVS) is formed by encrypting LVS using KS.
The sender encrypts the KS using vhe KUpub to generate a first encrypted session key (EKS), and generates a frrst law e l~rul.clu~,uL access field (LEAF) by encrypting a I ' of vhe first EKS and the UlP with a copy of a public portion of a family key (KFpub) stored in the sender. The encrypted message, the ELVS, and the first LEAF are transmitted from the sender to the receiver.
The receiver operates as follows. The receiver stores therein a public portion of the KEPF key (KEPFpub) and a public portion of the Family Key ~ wos6/0s673 -11- 2 ~ 97206 PCT/lJSgS/10221 (KFpub). The receiver decrypts ELVS using KS and extracts the UIP, KUpub, and the signature from the LVS, and verif~es the signature using KEPFpub. If the v"lir.u.lliull succeeds, the receiver then encrypts the KS
using the extracted KUpub to generate a second encrypted session key (EKS).
The receiver generates a second LEAF by encrypting a ~.",.l,;.,~li.", of the secûnd EKS and the extracted UIP with a copy of the KFpub stored in the receiver. The receiver then compares the first LEAF to the second LEAF.
If the first LEAF is equal to the second LEAF, then the receiver decrypts the encrypted message using the KS.
This . ., .l lû~ of the present invention operates so that, with neither tamper resistance nor secrecy of the hardware or software of the sender ûr the receiver, no party having modified the hardware or software of either the sender or receiver can I ~u~ rully with an u~ n~l;l;. d receiver or sender and, at the same time, prevent law ~ VI~,.,III.IIL from gaining authorr~ed access to the cl In a second .. ,.l,n~l;.. : of the present invention, the sender encrypts a message using a secret session key (KS), and generates a LVS by combining KSI and KS2, where KS = KSI XOR KS2. An ELYS is formed by encrypting LVS using KS. In addition, the sender encrypts KSI and KS2 using the public key (KEApubl and KEApub2) of each escrow agent to generate EKSI and EKS2, I~ iv~ly. Finally, the sender generates a first LEAF by ~"~ ;..g EKSI and EKS2. The encrypted message, the ELVS, and the LEAF are transmitted from the sender to the receiver.
The receiver in the second c.lll,odilll~llL operates as follows. The receiver stores therein KEApubl and KEApub2. The receiver decrypts ELVS
using KS and extracts KSI and KS2. The receiver then generates a trial KS by exclusive-OR'ing KSI and KS2. If the trial KS is equal to KS, then the receiver uses its copies of KEApubl and KEApub2 to compute a second LEAF.
If the second LEAF is equal to the first LEAF, then the receiver decrypts the encrypted message using KS.

WO 96/05673 PCT/US95/102~1 ~
-12- 2 1 9 72~6 Finally, in a third ~ ..,i.o~ of the present invention drawn to data escrow ~,ly~Lug~4~h~, an encrypting user encrypts a file using a secret storage key (KS) and generates a data recovery field (DRF) comprising an access rule index (~RI) and KS encrypted by a data recovery center (DRC) public key (DRCpub). DRCpub is acquired in an initial l~,~iDLI4liu~l phase wherein the AR defning user defines a set of access rules (ARs) that control potential lateraccesses to the DRF contents. After the DRC receives the AR from the AR
defning user, the DRC returns the ARI to be included in one or more DRFs attached to subsequent encrypted files.
To decrypt the file encrypted with KS, a normal decrypting user uses whatever mechanism is customary for specifying or accessmg a storage key, KS. Failing that, emergency access is achieved via the DRF. In this case, the emergency decryptmg user extracts the DRF attached to the encrypted message and sends the DRF to the DRC. The DRC challenges the emergency l~i decrypting user accordmg to the ARs defmed by the AR defining user andsends a message containing KS to the emergency decrypting user if the emergency decrypting user meets the challenge.
In alternative ~ o~ " ,1~, KS is not an encryption key but rather any piece of rrmfi~Pr~i~l i. Cu~muLiul~ that can ft inside the DRF. In all cases, the DRC limits access to emergency decrypting users who can meet the challenge defmed by the AR indicated by the ARI in the DRF.
Further features and advantages of the present invention, as well as the structure and operation of various ~Il.bodi~ D of the present invention, are described in detail below with reference to the a~ g drawings. In the 2~ drawings, like reference numbers indicate identical or functionally similar elements.

~ Wo 96/05673 2 ~ 9 72 0 5 PCTJUS9SJI0221 Brief Description of the F'igures The present invention will be described with reference to the a~cu~l~)dllyil~ drawmgs. wherein:
FIG. 1 is a block diagram of a key escrow ~lyL)Lu~;ld~ll;._ system according to a first ~lllbvdLl~,ll. of the present mvention;
FIGS. 2-9 and 17 are flowcharts depicting the key escrow .,lylJLu~ ld~ , system according to the ftrst cllll ' of the present invention;
FIG. 10 is a block diagram of a key escrow uly,ulu~ldl)lli~ system according to a second ~IUbOVilll.llL of the present invention;
FIGS. 11-16 are flowcharts depicting the key escrow ~,~y,ulv~l~,vL~, system according to the second .lllhodilll.l.i of the present invention;
FIG. 18 is a block diagram of a data processor according to an ~ ",i.V.i; ....l of the present invention.
FIG. 19 is a block diagram of a data escrow uly~ulu~ld~ system according to a third ....ho.l;.. ll of the present invention;
FIGS. 20, 2~ and 26 are data flow diagrams depicting the process of access rule definitions;
FIGS. 21-23 and 25 are flow charts depicting access rule definitions;
FIG. 27 is a preferred ~ .o.i;.,.. ~ of the ~,UI~Llul,Liu,l of a data recovery field;
FIG. 28 is a flow chart depicting the processing of emergency access requests;
FIG. 29 is a flow chart of an exemplary challenge-response cycle;
FIG. 30 is a data flow diagram depicting a challenge-response cycle embedded within an emergency access request; and FIG. 31 is a data flow diagram depicting a retrieval of an access rule from a data recovery field.

Detailed Descript on of the Preferred F' ~r ' S

The present invention is directed to a system and method for key escrow and data escrow .,~ u~ lly. Preferably, the present invention is ;I. l ! .,...,-..~ in software. However, the present invention works equally well when ~ ". ., ~1 using hardware.
The present invention preferably employs an ~~ ri J data encryption algorithm. Thus, the objection that software caMOt protect a classified encryption algorithm does not apply to the present invention.
Another objection against software is that it cannot ensure that the key escrow software will function correctly and not be modified by a user to bypass or corrupt the escrow process. It is noted that this objection is not limited to just software, but also applies to hardware illl~ which allow software to control the flow of information to and from the hardware encryption device.
Another objection against software is that it is impossible to embed secret l,ly~Lu~ hiL keys in a software product without a sigmficant risk that they would be disclosed. The present invention addresses and solves this problem inherent in Lull~ lLiondl software i",~ il."~ of key escrow by not embedding secret keys or private keys in the sender and receiver software modules. This feature of the present invention is discussed below.
Preferably, in the present invention, encryption and decryption operations are performed using any well known, l"" I ~;ri. .~ and publicly available algorithms such as DES and IDEA or with any well known, 1~lululi~taly but l~ iri. ~ algorithms such as RSADSI's RC2 and RC4. The specific details of the encryption and decryption algorithm are not material to the present invention.
The following symbols are used herein.
[a]b indicates that "a" is encrypted using key "b"; similarly, encrypt(e,f) indicates that "e" is encrypted using key "f".

~ WO 9610S6~3 2 1 9 7 2 0 6 ~CT/US95/10221 {x}y indicates that "x" is digitally signed using well known procedures using key "yn; similarly, sign(a,b) indicates that "a" is digitally signed usingkey "b" .
alb indicates tbat "a" is ~ ' with "b".
decrypt(m,n) indicates that "m" is decrypted using key "n".
extract(g,h) indicates tbat "h" is extracted using well knownprocedures from u~ ' value "g".
verify(a,b,c,) indicates that the signature "b" or "a" is verified using key "cn xor(o,p) indicates that "o" is bitwise exclusive-OR'ed with "p".
As used herein, values having labels with a suffix "priv" are considered to be private or secret. Values having labels with a suffix "pub" are considered to be public.
Concerning the symbol .~ ,s.,.l~d by Z=[X]Y (X encrypted by Y), rf Y is a public key, and Z needs to be re-built by some other program not having the private key Cul~ ' g to Y, then this encryption needs to be direct with all unused bits around X either known or ' to the re-building process. If there is no need to re-build Z, this can be either direct or indirect encryption. That is, one can equivalently compute Z=([X]KI,[K,]Y) (where Ki is a uul~ liulla], randomly chosen, symmetric encryption key) and achieve the same functional result. This may be desirable if X is larger than the quantity one can encrypt directly under Y in one pass.
Similarly, one might also compute Z=([X]K2,[K21K,,[KI]Y).

Overview of the Present Invention Described below are three ~ . ,1 ,o.li" .. . ,1~, two applyimg to a system and method of key escrow uly~lu~la~ and a third applying to data escrow ~,lylJw~;laL)lly. The first two .,lldl ' generally share the following preferred features:
;

wo 96/05673 2 ~ 9 7 2 0 6 PCT/US9sll0221 ~

~ Both rll l.o.l,.~ ensure that no party having modified the software of sender or receiver can . .~ successfully with an ~ d receiver or sender and, at the same trme, deny law; ~ authorized access to the ~..~...".,.,.;~-l;....

~ For both; ' ' , the receiving party to a i .. , , .. ,;, l ;""
lc~ullaLlu~,L~ the sender's LEAF to verify that the received LEAF is both valid and the correct LEAF for the current encrypted ~ ,., This choice counters smgle rogue attacks.

~ Both use an escrow protocol based on public key ~ly~)Lu~ lly to build the law, r ~ llL access field (LEAF) that makes the user's keys available to law ~,..,ul.,.,...~ . authorities. This choice obviates the need to include in the software products any secret keys that would be part of the escrow process.

~ Both preferably use ~ public or proprietary encryption algorithms to perform all ~y~JLu~ y functions.

The third ~ ~c..l;. ,1 on tbe other hand, focuses on the recovery of stored h.rul~ Lic n rather than the recovery of transmitted hlrullll~liull. In this ~ bodilll~, the data recovery field (DRF), an analogous structure to the LEAF, allows a user to function in a similar role to the law ~.. r~,.~.. , authorities of the previous rll,l.o1ll11 .,l~ Access can be obtained not only through a court imposed order but also tbrough any set of access rules (ARs) defined by the sender.

~ W 096/05673 2 1 q 7 2 0 6 PCTiUS9~10221 1. F~rst ~ 5. ' FIG. 1 is a block diagram of a key escrow system 102 according to a first ~ ,o~ of the present imvention. The key escrow system 102 rncludes a key escrow pluL facility (KEPF) 106, two or more key S escrow agents (KEAs) 110, 114, sending and receiving entities 124, 130, and a law c~u~ ,.lL decryptor 120.
A block diagram of the sending entity 124 is shown in FIG. 18.
Preferably, the sending entity 124 is a data processing device 1802 havmg a central processrng unit (CPU) 18v4 commected to other devices via a data bus 1810. The CPU 1804 operates in accordance with control logic 1806.
Control logic 1806 is preferably a computer program, such that the CPU 1804 operates m accordance wivh h~LIuu~ivl~ contained in the computer program.
The data processing device 1802 also includes a ~ or storage device 1808, a monitor 1812, a keyboard 1814, and a printer 1816.
~ "",--"-~ betweenthesendingentity124andotherdevices,suchasthe receiving entity 130, are achieved by operation of the c-~ or storage device 1808, which is any well known transmitter or storage medium.
In accordance with the present invention, the control logic 1806 enables the sending entity 124 (and, in particular, the CPU 1804) to operate as discussed herein. For example, the control logic 1806 (when executed by the CPU 1804) enables the sending entity 124 to perform the steps shown in FIG. 7.
The structure of the receiving entity 130 is similar to the sendmg entity 124 and, thus, the above description applies equally well to the receiving entity 130. However, in accordance with the present invention, vhe control logic 1806 in the receiving entity 130 enables the receiving entity 130 (and, in particular, the CPU 1804) to operate as discussed herein. For example, the control logic 1806 (when executed by the CPU 1804) enables the receiving entity 130 to perform the steps shown in FIG. 8.

wo 96/05673 2 ~ 9 7 2 0 6 PCT/USg5/10221 Since the control logic 1806 in both the sending and receiving entities 1247 130 preferably represent software, the sending and receiving entities 124, 130 are sometimes called herein "programs" . However, it should be understood that such "programs" represent a device 1802 operating in accordance with software. Also, according to an alternate r~ o~ - d of the invention, the sendmg and receiving entities 124, 130 are , ' ' entirely in hardware (for example, the CPU 1804 and the control logic 1806 represent hardware state machine(s)).
As mentioned above, one difference between this system 104 and the Clipper/Capstone system is that this system 104 uses public key .~ly,uiu~ ,u}lr m place of cull~,.lii.,llal (symmetric) cryptography to generate the law ~.llrUI-~,.II.,.II access field or LEAF. As is well known, with symmetric ~_lyLIlu~ lly~ sender and receiver share a key that is used to control both encryption and decryption. With ~ Iy~iu~ hy, encryption and decryption use separate keys which cannot be computed from one another.
Thus, an encryption key can be made public (a "public key") and anyone can send a secret message which can only be decrypted by the holder of the ~UIlc~)Ulldillg ("private") decryption key. The use of public key ~ ly~ hr allows the software programs 124, 130 to generate and validate LEAFs without having to store secret keys or private keys. Only public quantities need be embedded in the software programs 124, 130 and, therefore the present invention does not need to preserve the secrecy of its own structure or content. The elements of the system 102 shall now be described.

1.1 Tl1e Key Escrow r,~ Facility The key escrow Aul U~l.lllUllill~ facility (KEPF) 106 is within a protected c.lvilulull.,.lL 104. A protected Cll~dlOlul~ 104 is defined as a physically andprocedurally secured area whose protection is adequate to the value of all h~ru~llldLiull that will be protected by any key escrow encryption program.

~ WO 96105673 2 1 9 7 2 0 6 PCT/US95/10221 The REPF 106 includes various ~ ly~Lo~ hi~-related data 108 Such data 108 stored m the KEPF 106 cannot be accessed by persons or entities outside the protected .llYil~ ' 104 The maDner in which the KEPF 106 initializes such data 108 shall now be described witb reference to a flowchart 202 m FlG 2 The KEPF 106 is initialized with two public/private key pairs The furst is a KEPF pu~lic/private key pair, initialized in steps 206, 208, 210, and 212, which is used to sign and l~ other ~ that are generated and distributed by the KEPF 106. The KEPF key pair is generated externally and loaded into the KEPF 106 (step 208), or generated internal to the KEPF 106 (step 210) Controls can be applied to the generation and custody of the KEPF key pair as they are to tbe family and seed keys that are used by the Clipper/Capstone chip ~)1-1~1~''1 :.,g facility The KEPF
public/private key pair is stored m a memory device in step 212 The second key pair used by the KEPF is a family key (KF) and is rnitialized during steps 214, 216, 218, 220, and 222 KF is preferably generated external to the KEPF 106 (step 216), although it may be generated internally (step 218) Only the public component (KFpub) is sent to the KEPF
106 (step 222) The ,;ollc~v~ g private component (KFpriv) is loaded into the Law Eurul~,~.u.. lL Decryptor (LED) 120 (step 220) The private component of KF can also be split into halves and escrowed 1.2 Law Erf,,, Decryptor The Law El~u~ ~u~,Decryptor (LED) 120 is also within the protected .llYhu~ulllt 104 the LED mcludes the Family Private Key KFpriv 122 The LED 120 initializes the Family Private Key 122 as shown in Figure 4 In step 406, the LED obtains the private component of KF, KFpriv, which is stored in a memory device in step 408.

wo s6ios673 21 9 7 2 0 6 PCT/US9SJ10221 1.3 Generati~tg Program r ' ~

On an ongoing basis, the KEPF 106 signs and optionally generates unique program parameters for each program instance, just as the ClippertCapstone IJIU~I ' ,, facility programs each individual chip. In S particular, as shown in a flowchart 302 of FIG. 3, the BPF 106 in step 306 sends the KEPFpub and KFpub to a softw~are ~lldul/h.~,l 118. Soeps 308-324 are then performed for each program instance.
In step 308, the KEPF 106 generates or acquires a program unique identifier (UIP) and a program unique key (KU). Preferably, KU is an ~y publictprivate key pair. KU is generaoed within the KEPF 106 and may be seeded with externally generated parameters that are loaded mto the KEPF 106. The private component of KU (KUpriv) is split into halves (308). This is preferably done by generating a random bit string as long as KUpriv which becomes KUprivl and calculating KUpriv2 as the exclusive-OR
of KUpriv~ and KUpriv. Other procedures could alternatively be used to split KUpriv.
In step 310, the UIP and individual private key halves are escrowed with the two escrow agents (KEAs) 110, 114. Specifically, as shown in a flowchart 501 in FIG. 5, the escrow agent 110 receives the UIP and KUprivl (step 504) and stores UIP and KUprivl (step 506). These steps are repeaoed for each program instance, as indicaoed by step 508. The operation of the other escrow agent 114 is identical to this.
In steps 312 and 314, the KEPF 106 sends the program unique p~r~lmPtPrs~ UIP and KUpub, to the software vendor 118 to be embedded into the software program product. In step 312, the KEPF 106 uses well known procedures to digitally sign these parameters using its privaoe key, KEPFpriv, and sends the signature along with the r~ to the software vendor ll8 (step 314). The ~)IU~;I.IIIIlllillg faciliy public key (KEPFpub) and the family key public component (KFpub) are also sent to the vendor 118. Steps 308-314 are repeated for each program instance, as indicated by step 316.

~ WO 96105673 2 ~ 9 7 2 ~ 6 PCT/US9SJ10221 1.4 Generatrng the Software Product If the KEPF 106 ~ its public key KEPFpub to the vendor 118 by an out of band (secure) chamlel, the vendor 118 can reliably sets of parameters (KFpub, UIP, KUpub) received from the KEPF 106. This is the case since, as is well known, data encrypted (or digitally signed) with a private key can be decrypted (or verified) by anyone possessing the cullcD~ùl~dillg public key. Also, data encrypted with a public key can be decrypted only using the ~:UII~ lUlldillg private key.
As lC~ ' in a flowchart 602 of FIG. 6, as the software vendor 118 III~IIULILLUIC~ software copies of its product, it embeds KFpub and KEPFpub in the product code (step 608). It had received KFpub and KEPFpub from the KEPF 106 (step 606). Each instance of the program must be initiali_ed with:
KEPFpub KFpub KUpub unique to that instance of the program UIP unique to that instance of the program S = {KFpub, KUpub, UlP}KEPFpriv unique to that instance of the program.
This data can reside in the code of the program or in a storage file associated with the program. KEPFpub, KFpub, and S must come from the KEPF. KUpub, KUpriv, and UIP can be generated by the KEPF, the vendor or the program itself during Ij7~tion S must be generated by the KEPF
only on receipt or generation of a valid KUpub, KUpriv, pair and the successful escrowing of KUpriv.
~ Preferably, the vendor 118 embeds the program unique parameters (UIP, KUpub and the associated signatures) for each program into the media for the program (step 612). UIP, KUpub and the associated signatures were received from the KEPF 106 in step 610. Steps 610 and 612 are performed for each software product, as indicated by step 614.

.

WO 96/05673 2 1 9 7 2 0 6 PCT/USgS/10221 ~

The data described above is l~ip-..,.,.lkd by reference nurnber 126 in the sending program 124 and reference number 132 in the receiving program (FIG. 1).
Note that no secret keys or private keys are present within the software product. Only public quantities, KEPFpub, KFpub, and KUpub are embedded m the software product.
In cases where a software product is distributed on CDROM media that is nl~n~lfA~ cd in bulk (and can not accept unique serial number or key .rJllllf~LiU -), or where it is installed on a shared storage device for access by multiple users, it is not feasible to embed a unique KUpub, UIP and the associated signatures for each copy of the product. In these cases, the user of the product can be required to run an installation prograrn that retrieves KUpub, and UIP and their signature over a network or f...l",.", ;l li...~ Ime.
The operation of the product's encryption function can be made contingent on the execution of the installation program and possession of KUpub, UIP, and the cullc~pul~lillg valid signature.
Smce the only quantities that are needed to customi7e the escrow software for its user are signed digitally and public, there is no risk to retrieving them over a network or other insecure .. ".. ;,-lin., channel.
Their r.f)nfiflf~ntiAlity is not at issue, and their integrity can be A.. lh. .l;. . ~ :1 using KEPFpub which is cor unon to all users and copies of the product and can be embedded by tbe vendor 118.
An alternative to having the product retrieve KUpub and UIP is to have the product generate UIP and KU during the i~itiAli7Atir)n process and send all f ""'p~ ' (UIP, KUpub and KUpriv) to the KEPF 106 encrypted under KEPFpub. In this variation, the KEPF 106 would split KUpriv and distribute the halves to the escrow agents 110, 114, sign [UIP ¦ KUpub], KUpub and send ~'IJIP ¦KUpub~KEPFpriv back to the product.

WO 96/05673 2 i 9 7 2 0 6 PCTIl~S95121~222 1.5 Opera~ron of the Send~ng Program As .c~.~ ' by a ffowchart 702 in FIG. 7, the sendmg program 124 receives a data message M in step 706. In step 708, the sending program 124 and the receiving program 130 use any well known procedure for negotiating a secret session key 708. In steps 710 and 712, the sendmg program 124 encrypts and tnen transmits the data message M using the secret (or private) session key KS. This encrypted message C is denoted by [M]KS.
Also in step 710, the sending program 124 generates a LEAF by encrypting the session key KS under the program unique public key KUpub to thereby generate [KS]KUpub. [KS]KUpub is also called the encrypted session key, or EKS. The EKS is . ~ 1 with the program unique identifer UIP to thereby generate [KS]KUpub I UIP. This value is encrypted with tne family public key KFpub. The resulting LEAF is symbolized as [[KS]KUpub I UlP]KFpub. Note that in the present invention encryption of M
is ~r~ d usmg symmetric encryption while encryption in the LEAF
under keys KUpub and KFpub is ~ d using a~y~ iC~ rather than symmetric clyL/lu~la~lly.
Also in step 710, the sendmg program 124 generates a EEAF
~ir1atiull string (LVS) that includes: (1) the sending program 124's program unique identifier UIP, (2) program unique public key KUpub, and (3) the signature S applied to those two quantities by the key escrow ~lvglallllllil4 facility 106, i.e., {UIP I KUpub3KEPFpriv (these three items are called the leafirlcatiOll string, LVS). This strmg is encrypted under the session key, KS.
Thus, the ELVS, is ~c~ P~,I as follows:
[UIP l KUpub I ~UIP,KUpub}KEPFpriv]KS
In step 712, C, LEAF, and ELVS are sent to the receiving program 130.

W096~5673 2 ~ 9 72 ~ 6 PCT~S95/10221 ~

1.6 Operation of the Receiving Program As lc~c.~ll~d in a flowchart 802 of FIG. 8, the receiving program 130 in step 806 negotiates a secret session key KS with the sending program 124 (this ~.VllC.pUlldS to step 708 in FIG. 7). In step 808, the receiving program 130 receives C, LEAF, ana ELVS from the sendmg program 124.
In step 820, the receiving program 820 decrypts the encrypted message C using the session key KS to recover the message M. However, prior to domg so, the receiving program 820 must ' the LEAF to ensure that the sendrng program 124 has included a valid LEAF as part of the message ll~ n This is done during steps 810, 812, 814, and 816.
Note that the receiving program 130 cannot decrypt the LEAF, since it does not have a copy of the family private key KFpriv. Instead, according to the present invention, the receiving program 130 ' the LEAF
by lc~,ul~LIul,Lillg it. This is possible since the receiving program 130 has been provided with all of the CU1lllJUII.~ that make up the LEAF either through ....,.""l,: -l;..,. external to the operation of the escrow system (KF
and KS) or because they were sent signed in the encrypted LEAF ~.iflc.lLiu string ELVS.
Specifically, in step 810 the receiving program 130 decrypts the encrypted leaf ~ ;flu~Liu.. string ELVS using the session key KS to obtain the leaf verification string LVS, or UIP l KUpub l {UIP ¦ KUpub}KEPFpriv. Then in step 810 the receiving program 130 verifies that tbe received copies of the sending program 124's program unique key KUpub and program unique identifier UIP (which are in the LVS) are correct and authentic. This is done in step 812 by verifying the collc~,uolldiulg signature S or {UIP ¦KUpub}KEPFprlv using KEPFpub If the leaf verification string LVS is authentic (as determmed in step 812~, then the receiving program 130 in step 814 recalculates the LEAF
(this is called the "test_LEAF" in FIG. 8) using KS, KFpub, and the sending ~ W 096~5673 2 I q 7 2 0 6 PCT/U59~10221 program 124's KUpub and UIP. If the calculated LEAF is identical to the one received (as determined in step 816), then the LEAF is valid. Accordingly, the receiving program 130 accepts and decrypts the message (step 820).
Otherwise, the receiving program 130 rejects the message (step 818).
S The use of the session key KS to encrypt the leaf ~liGcdLiull strmg LVS is not necessary to the function of verifying the LEAF. Instead, this step protects the sendimg program 124's UIP and KUpub from disclosure to parties who are not in ~ ,ai.l,. with it.

1.7 LaW Er~fL Decryptor The law ~llrul-~ decryptor (LED) 120, which is operated by the law l~ vlc~ llt agency, contains the family private key KFpriv (indicated as 122 in FIG. 1). This is represented in a flowchart 402 of FIG. 4, where the LED 120 receives the KFpriv from the KEPF lû6 in step 406 (CUllC:~/Ulldill~ to step 220 in FIG. 2 in the case where KFpriv is generated in the KEPF 106; where KFpriv is generated outside the KEPF 106 by an external entity, not shown, then the external entity sends the KFpriv to the LED 120). In step 408, the LED 120 stores the KFpriv in a memory device of the LED 120.
Since the LED 120 has possession of KFpriv, tbe LED 130 can decrypt the LEAF. This operation is ~c~cscl~v d in a flowchart 1702 in FIG. 17. In step 1706, the LED 120 receives C, LEAF, and ELVS from the sending program 124. In step 1708, the LED 130 decrypts the LEAF usmg KFpriv, and extracts the UIP from the decrypted LEAF (called "plain_LEAF" in FIG. 17). In steps 1710, 1712, 1714 and 1716, the LED 120 uses UIP to obtain the sending program l 24 ' s unique private key o ., . ~ , KUprivl and KUpriv2, from tlie respective key escrow agents 110, 114. If either key - escrow agent indicates that they cannot find the private key component cullc;,~ulldillg to UIP, then the LEAF is invalid (step 1724). In step 1718, theT Fn 130 combines KUpriv, and KUpriv2 using preferably a well known .

WO 96/05673 2 t 9 7 2 0 6 PCT/US95/10221 ~

exclusive-OR operation to form the sending program 124's program unique key, KUpriv. KUpriv is stored in the LED 120 in step 1720. With KUpriv, the LED 130 in step 1722 decrypts the session key KS. Also in step 1722, given KS, the LED 120 decrypts the message.

2. Second F~ L~ ', On-line Escrow Agents The key escrow protocol of the Clipper initiative has been criticized since it was initially disclosed because of the fact that a device whose unique key (KU in the original Clipper scheme) has been withdrawn from the escrow agents is subject to decryption from the time of withdrawal onward. While the stated policy of the Clipper initiative is that unique keys will be erased from the law cllrulcc~ decryptor (LED) once the wiretap, ll./,.;,,.l;,.l, has expired, that policy is cold comfort to individuals who fnd key escrow nnarp~ ing to begm with.
The first cll.l,odi~,l.L of the software key escrow system of the present imvention, described above, shares with the Clipper initiative the use of a device unique key (KUpriv) that is loaded into the law Cl ru~c.,ll~l~L decryptorLED 120 and that must be erased when a wiretap ~ li"" ;~ ll, has expired.
In addition, it is possible tbat a malicious user with a modifed software product can harvest and reuse the escrow h.rul~ Liu.. (UIP and KUpub) for any other user with whom he or she securely potential deficiency, in that it can cause the law c.lru.c.,l.l~l.L agency to retrieve KUpriv for irmocent partner.
The second, ",1...,1;.,.. -: of the software key escrow system of the present invention addresses and solves these concerns. The second ~",I.o.~ does away with the unique key (KU, KUpub, KUpriv) and identifier (UIP). Instead, each sender splits its session key KS and encrypts one fragment under the public key of each escrow agent. This scheme still i..uu.~u. a LEAF and a LEAF verification string, but it does away with the KEPF and srmplifies the role of the vendor.

~ wo s6/0s673 ' -27- 2 1 9 7 2 0 6 PcT/uS9!i/10221 Figure lO is a block diagram of the second ~.. .,l ,n~ KEApub~ and KEApriv, (designated as 1008) a}e stored in the key escrow agent 1006, and KEApub2 and KEApriv2 (designated as 1012) are stored in the key escrow agent 1010 Note that there is no key escrow ~)IU~I~IIIL.IIIIIg facility (KEPF).
However, there is some entity (not shown; this entity could be called the KEPF) im the protected ell~ ilUI~ 1004 that initializes the key escrow agents lOû6 and 11)10. Such ini~iuli7utinn is IC~l~ ' by a flowchart 1102 in FIG.
11, where in step 1108 the entity obtains KEApubl and KEApub2 from an e~ternal source (not shown). Alternatively, in steps 1110 the entity generates KEApub" KEApriv~, KEApub2, and KEApriv2, sends KEApriv~ and KEApub~
to key escrow agent 1006, sends KEApriv2 and KEApub2 to key escrow agent 1010, and erases KEApriv~ and KEApriv2. In step 1114, the entity stores KEApub~ and KEApub2. In step 1116, the entity sends KEApubl and KEApub2 to the software vendor 1014. Alternatively, as shown in FIG. 10, KEApub, and KEApub2 are sent to the software vendor 1014 from key escrow agents 1006 and 1010.
The vendor 1014's sole role is to embed in each program instance the code that i., .pl~ . ~ - . '~ the key escrow functions and the public keys of two (or more) escrow agents (KEApubl and KEApub2). These keys are l~lc~ lt d by 1020 and 1026 in the sending program 1018 and the receiving program 1024, respectively. The operation of the software vendor 1014 is IC,UlC~I.~d in FIG. 12, where in step 1206 the software vendor 1014 receives KEApubl and KEApub2 from the key escrow agents 1006, 1010, in step 1208 the software vendor 1014 stores KEApub, and KEApub~, and in steps 1210 and 1212 the software vendor 1014 embeds KEApub, and KEApub2 in each software program.
~ The sending program 1018 operates as shown in a flowchart 1302 of FIG. 13. In step 1306, the sending program 1018 receives a message M. In step 1308, the sending program 1018 negotiates a secret session key KS with the receiving program 1024 using any well known procedure. In step 1310, the sendmg program 1018 encrypts the messagce M using the session key KS.

W096/05673 2 1 9 7 2 0 6 PCT~US95110221 ~

In step 1312, the sending program 1018 splits the session key KS into two halves KSI and KS2. Preferably, this is known by assigning a random number to KS" and then assigning KS2 to the exclusive-OR of this random number and KS. The sending program 1018 also generates a LEAF durimg step 1312. The LEAF is equal to the, of (I) KS, encrypted under KEApubl and (2) KS2 encrypted under KEApub2. and can be represented by:

LEAF = ([KSJKEApub, I [KS2]KEApub2) The LEAF need not be encrypted with KFpub, since KEAprivj are not available to anyone and ~Ic.. ~ 41)1y the only path to these decrypting services is via the LED. The KEApubj ~llcly~LiOIl~ are enough to preserve the privacy of the LEAF contents without resorting to KFpub encryption. However, if there is some ~:,.", ..,..:, -lif~n~ path to the "escrow" (decrypting) agents other than through the LED or if there are to be different classes of user, some of which the LED may not be allowed to access, the family key, KFpub, provides needed security. It should be noted that this embodiment is not limited to a 2-way split session key. In alternative n,, ~ any number of splits, from 1 on up may be utilized. The general LEAF is Icl~lc~..ll.~,d by:
LEAF = ([KSI]KEApub,, [KS2]KEApub2, ..., [KSnlKEApubn) or LEAF = [[KS,]KEApub" [KS2]KEApub2, ..., [KS_n]KEApubn]KFpub forn > 0 The choice of LEAF ~ull~LI-lcLlu~l depends on whether or not extra protection from KFpub encryption is desired. At some point, however, encryption of all pieces under one KFpub key may become prohibitive when ~1.. ,~:.1. ;.. g the size of that one key.

~ WO 96/05673 2 t 9 7 2 0 6 PCT~s95,l022l Further in step 1312, the sending program 1018 generates a leaf v.,lir.~.Liull string LVS that is equal the ,.n of KS~ and KS2. The encrypted leaf v~,lir~ iull string ELVS is then generated and is equal to the LVS encrypted using the session key KS.
In step 1314, C, LEAF, and ELVS are sent to the receiving program 1026.
The operation of the receiving program 1024 is shown in a flowchart 1402 of FIG. 14. In step 1406, the receiving program 1024 receives C, LEAF, and ELVS from the sending program 1018. In step 1408, the session key KS is negotiated (this step cullca,uulllla to step 1308 in FIG. 13). Then, the receiving program 1024 checks the leaf v.,lir~ liull string LVS and then Ic:C,Ul~ the LEAF. Specifically, m step 1410 the receiving program 1024 decrypts the encrypted leaf v~lirl~ Liull string ELVS
using KS to obtain the leaf ~.,lir~ ~Liun string LVS. The putative KSI and KS2 called trial_KSl and trial KSl are extracted from LVS. Then, the receiving program 1024 generates the session key KS (called "trial_KS" in step 1412) by exclusive-OR'ing trial_KS, and trial_KS2 that were just extracted from LVS. In step 1412, the receiving program 1024 compares trial_KS with the negotiated session key KS. If they are not equal, then the LEAF is bad and the message is rejected (step 1418).
If they are equal, then in step 1414 the receiving program 1024 uses its copies of KEApub, and KEApub2 to recompute the LEAF. This is done by encrypting trial KSI using KEApubl and encrypting trial_KS2 using KEApub2 to thereby generate trial_EKS~ and trial_EKS2, ~~ ,.,Liv~ly. Then, a LEAF called test_LEAF is computed by ~ g trial_EKS, and trial_EKS2 In step 1416, the receiving program 1024 determines if trial_LEAF is equal to the LEAF. If they are not equal, then the message is rejected (step 1418). If they are equal, then the LEAF is validated and the message M is decrypted using KS.

wo 96/05673 2 1 9 7 2 0 6 PCT~S95/10221 ~

The operation of the law cllrul~ ll.,.lL decryptor LED 1016 is shown J in a flowchart 1502 of FIG. 15. In step 1506, the LED 1016 receives the C, LEAF, and ELVS from the sending program 1018. In step 1508, EKS, and EKS2 are extracted from the LEAF. In step 1510, the LED 1016 sends EKS, to key escrow agent (KEA) 1006 and sends EKS2 to KEA 1010. Also, the LED 1016 discloses a proper court order to each escrow agent 1006, 1010.
Each agent 1006, 1010 verifies the validity of the court order, records its effective dates, and generates a secret key half KS, or KS2 using either KEApriv, or KEApriv2 for that particular court order and issues it to the LED 1016. This is l~pl.. ,~.itcd by step 1512, where the LED 1016 receives KS~ from KEA~ 1006 and KS2 from KEA2 1010. The LED 1016 combines the returned KS, and KS2 to yield KS (step 1514), and decrypts the message using KS (step 1516).
Any submission of key parts for that wiretap to an escrow agent 1006, 1010 by the LED 1016 must be encrypted in the CUllCa,UUlld;llg key.
The escrow agents 1006, 1010 delete the secret keys KS" KS2 on the expiration of the court order and are therefore unable to comply with any requests for keys after the expiration of the order. Since all c~
with the escrow agents 1006, 1010 must be encryFted for security, this process Jadds no execution time to that operation.
The operation of KEA, 1006 is shown in a flowchart 1602 in FIG. 16.
KEAI 1006 and KEA2 1010 are identical, so the following description applies equally well to KEA2 1010. In step 1606, the KEAI 1006 receives EKS, from the LED 1016. In step 1608, the KEA, 1006 decrypts EKS, using KEApriv, to obtain KS,. In step 1610, the KEA, 1006 sends KS, to the LED 1016.
Since there is no database linking a UIP to any individual targeted in a court order, the escrow agents 1006, 1010 have no choice but to trust the LED 1016's association of an individual targeted by a court order with a specific wiretap. The protocol described above may be modifled to include a UIP in the LEAF portions sent to the escrow agents 1006, 1010, to enable ~ 2~ 97205 those agents 1006, 1010 to maintam a list of program instances targeted under each court order for later auditing.
This second ....l.,~.i;",~ .,1 has the advantage that there is no product unique key to be disclosed to the LED 1016. Once surveillance ceases, the S LED 1016 has no furlher ability to decrypt the sending program 1018's unless it again requests the services of the escrow agents 1006, 1010. As a side çffect, there is no potential for a rogue application to trick the LED 1016 mto wial~lu~hlg the unique keys of innocent users.
This second .",l~o.li",. ~I requires the escrow agents 1006, 1010 to be on line and involved with every decryption of a new session key. This is not considered to be a disadvantage since the escrow agents 10Q6, 1010 are committed to round-the-clock operation as part of the Clipper initiative. On-line computer systems at the escrow agents can be expected to respond within 0.2 seconds, provided they have hardware support for public key decryption, and reliable ~ between escrow agents and LED should be easy enough to provide.

3. T7zird ~ Data Recovery Centers A third application of this technology applies to Data Recovery Centers (DRCs). This third .. 1,~.. 1;,.,.. : is directed to the provision of emergency access to stored encrypted data in the event of the loss of the normal decryption key. It involves no key escrow or escrow agents and has no lllh with third parties (specifically any DRCs) except during an rnitial, I~ dLiull phase and during the process of emergency access.
This rllll-O,~ is similar to the second rllli,O~, .l where no databases of escrowed keys and therefore no escrowed keys and escrow agents exist. This cl.ll,o-li..l..llL, Iike the second r~l)O~ 1, is directed towards decryption services. In the second ~ u~ , directed to law cllrOl-.ll..,ll.
interests, the entities p.lrullll;llg the decryption services were called Escrow WO 96/0~i673 2 ~ 9 7 2 0 5 PCI'/U595110221 ~

Agents, even though they performed no escrow functions In this , to appeal to corporate and individual interests, the entities performing the decryption services are named the DRCs.
~,J Figure 19 illustrates a block diagram of an ~,llVilVllnl~,l.i 1902 according S to this third ~",I,n~l;,.. :.,l The .,ll~;lUlllll~,~li 1902 includes a data recovery center (DRC) 1910 (optionally redundant) situated in a protected cllvilulull.lll 1904. The protected cl~;lull~ ,.lL 1904 is established and maintained by any entity wishing to provide services pursuant to the tbird ~,lllbUdilll~,lli of the present invention (as described herein). For example, the protected CIIV;IUIL.. ~,IIL 1904 may be established and maintained by a public UI~ dLiUll (such as a state division of motor vehicles) or a private ul~ll~aLiull (such as a Cul~uldLiOll), or a plurality and/or UUlllbilldLiUII of public/private entities. Preferably, the DRC 1910 represents software executrng on a suitably equipped computer system.
Fumctional elements 1912 (normal file decryption), 1914 (file encryption), 1916 (emergency file decryption) and 1918 (AR defmition) represent a user in the four different operational modes. In the following description, the four elements wiil be referred to as the normai decr,vpting user, the encrypting user, the emergency decrypting user, and the AR defmmg user respectively. It should be understood that these users do not necessarily represent the same party.
In this clllbO ihll~,llL, the AR defming user 1918 first negotiates with the DRC to obtain a DRC public key (DRCpub). The AR defming user 1918 then creates an access rule (AR) definition and registers that AR defmition with 2~ DRC 1910. The DRC 1910 sends an access rule index (ARI) I,UlI.:~JOnlling to that AR back to the AR defning user 1918. The AR definmg user 1918 then stores any new DRCpub, the new ARI and an attached comment in the AR file 1920.
The encrypting user 1914 encrypts a File F with a storage key (KS) to generate an encrypted file C=[F]KS. The encrypting user 1914 is any entity wishing to encrypt data and store such encrypted data. For example, the ~ W096105673 2 1 97206 PC'r/lJS9~/10221 encrypting user 1914 may be a commercial software program (such as a word processor program, a ~I,."a~ program, a database program, a program, etc.) rumling on a camputer.
The encrypting user 1914 creates a data recovery field (DRF) S comprismg an access rule index (ARI) and the KS encrypted by DRCpub.
The ARI and DRCpub values are retrieved from the ARI file 1920. The ARI
value is generated by tbe DRC 1910 during the initial set-up phase between the AR defining user 1918 and the DRC 1910. The DRF is attached to the encrypted message C and is sent by the encrypting user 1914 to a storage medium 1922. If it is desired to allow for lc~,u~llucLiun of the DRF during a later verification phase, the encrypting user 1914 also generates a DRF
Verification String (DVS) and attaches it to the DRF. The (optional) DVS
consists of the ARI which was used in the DRF, encrypted m the storage key, KS.
In this third l."~-o-l;,.-.,l the encrypted message and the DRF are stored in a storage medium 1922 pending retrieval by either the normal decrypting user 1912 or the emergency decrypting user 1916. Typically, the normal decrypting user 1912 is the same person as the encrypting user 1914 who has access to the storage key, KS, without requiring any reference to the DRC.
An emergency access situation occurs when an emergency decrypting user 1916 does not have the KS required to decrypt the message. For example, this may happen in a corporate e~ vll,ll.,l,L when a manager needs access to data encrypted by an employee, but the employee is not present and the manager does not know the employee's storage key, KS. It may also happen when the encrypting user 1914 forgets KS or the normal means for generating it or gaining access to it. To access the KS, the emergency decrypting user 1916 extracts the DRF from the storage medium 1922 and sends it to the DRC 1910. The DRC 1910 responds with a challenge previously defined by the AR defining user 1918 at the registration phase and selected by the encrypting user 1914 during encryption and releases the KS

. _ _ _ _ _, . . _ .... .. . .. .. . . . = . ..

W096/0~673 2 1 9 7 2 0 6 PCT~S95/10221 ~

contained within the associated DRF to the emergency decrypting user 1916 if the emergency decrypting user 1916 successfully meets the challenge. In this scenario, the emergency decrypting user 1916 can generally be described as a party priYileged to the i " r~ " criginated by the encrypting user 1914 S (e.g., IIIA.I L~
From a broader perspective, the KS within the DRF could represent any confidential piece of hlrulluAALioll to which the encrypting user 1914 desires to control access. In other words, the intended use of the KS after retrieval by an emergency decrypting user 1916 does not limit the scope of use of this ~ bo.lhll~
Preferably, the data recovery center 1910, tbe client 1918, and the user 1916 each represent a data processing device operating accordmg to iu~LIu~liul.D or commands from a controller. (In some C:lUbO~liUI~ the data processing device includes a processor, in which case the processor operates according to instructions or commands from the controller.) In one clllhodiul~, the controller represents a hardware state machine. In an alternate ~,ho~ ..1 the controller represents a computer program in an electronic/magnetic form that is directly readable by a computer. Preferably, the computer program is distributed as a computer program product ~such as a floppy disk having control logic electronically or mAvnPlieAlly recorded thereon), or via a ,,...., -Ill ~AI;~-- ~ network.

3.1 Data Recovery F'~eld Where the first two emho~limPnlA~ refer to a Law E-lrul~,.,.l~.l,L Access Field (LEAF), the third ~ ..,1,~,1;..,...1 refers to a Data Recovery Field (DRE).
Since emergency access is provided only to emergency decrypting users 1916 in this c",bod.".~ (e.g., an encrypting user 1914 himself or his employer), the preferred mode of this ~",l.o.l;...~ ~L avoids the splitting of KS. Clearly,in alternative modes, key splitting remains a possible ;..,pl. .". ,~I-l;rm should an encrypting user 1914 desire it.

WO 96105673 PCrNS9~10221 2 ~ 97206 It should be noted that m alternative ~.."l,r~ t' KS need not be a storage key (i.e., encryptmg key). The datum inside a DRF can be any datum which the encrypting user 1914 wishes to encrypt and store. The enclosure of such a datum inside a DRF is functionally equivalent to the encryption of S that datum rn a file with a storage key (KS) generated at random. The randomly generated storage key (KS) is included within the DRF attached to the file and forces the file's owner to access the file's contents as an emergency decryptmg user 1916.
Further UUIIII)~I;DOn to the second PmhorlimPm is evident through ..... ,~ ;.,. of a LEAF with n=1 and no KFpub encryption. For this example, the LEAF is comprised of [KS,]EApub, where [YlX means Y, encrypted with key X. In UUIIII)~I;DUII, the DRF of the third ~lllbOllillll,llL is comprised of [ARIlKS]DRCpub. Here, the index to an access rule (AR) defmed by an encrypting user 1914 is ( ' with the storage key (KS) chosen by the encrypting user 1914 and then encrypted in the public key of the DRC, DRCpub. If the encrypting user 1914 views the DRC 1910 as potentially hostile, an alternate r..ll.Oil;",. .,i i".l.l~ ,. .. ~ a DRF ~

[ARII,KSl]DRCpub~,[ARl2,KS2]DRCpub2,. . .,[ARln,KS"lDRCpubn In this alternate r~ l ~hr~rl; l l ~i, at least k of the n KSj pieces need to be obtained to recover KS and the n DRCs 1910 are disjoint and not subject to ~""'1';'"'; ~ of more than (k-1) parties. This splitting of KS into shares is ",l,l;~h d via any well known secret-sharing mPr h:~nicm An example of such a secret-sharing mechanism is described in A. Shamir, "How to Share a Secret", in the ~'.,. ". ~l: -';l-"~ of the ACM, vol. 22, no. 11, pp. 612-613, November 1979, hl~ol~l ' herein by reference m its entirety.
Finally, since the DRF provides the encrypting user 1914 himself with a service, there is no need to strongly enforce its correct UUIIDLIU~.LiUll. Theencrypting user 1914 is not inclined to circumvent a service he desires, uses voluntarily and possibly paid some amount of money to acquire. In addition, _ _ _ _ _ _ _ . , _ _ _ _ . . ... .... ........

wo s6l0s673 2 1 9 7 2 0 6 PCTIus9sll0221 ~

any refusal to decrypt (as in the frrst two ~,.,ho.li.. :-) based on an incorrect DRF is ari iUl~ )l ;(lL~. action for storage encryption. The damage of a bad DRF is done at the time of encryption and detection of an incorrect DRF at decryption time is ineffective. Therefore, in a preferred ~ mho~lim~ nt, either no DRF verification or ~,flfll,~tiul~ in the form of a bdCk~luulld "sniffer" is i~ p 1~ As further described below, a "sniffer" is a process which randomly selects files, checks their DRF formats (using a format-checking senice provided by the DRC 1910) and in case of incorrect format, notifies the creator of the file (and possibly his manager) of the flaw. This provides moderate social or adluilli~tl~lLiv~ pressure at or shortly after encnption timeto remedy a failure to generate proper DRFs. The generation of improper DRFs can happen by accident or oversight rather tban by malicious intent.

3.2 DRF Venficahon It is possible that an encrypting user 1914, without any intended malice, uses a version of software which doesn't attach DRFs to files (possibly because that option isn't enabled at the time), or which mistakenly attaches (tbrough a flaw in the software) an incorrect DRF, or which incorrectly constructs DRFs. Several options exist for detecting such problems and minimi7ing the extent of the potential damage from them. These options (described below) include sniffing for format, random re-building of DRFs, random ~,ifl~ Liull by the DRC 1910, and doing nothing, i.e., performing no ~.liflc~lLiu.l (the no v.,liflu.~Liull option is discussed above). Since accessing DRFs is a ven infrequent occurrence, any time delay in detecting bad DRFs is likely to be less than the time until the DRF is needed, thus permitting the encrypting user 1914 time to recreate a proper DRF.

~ WO 9610~73 2 1 9 7 2 o 5 J'C~/US95J~0221 3.2.1 Sniffingfor Forma:t It is good practice in general to have a file "sniffer" program which scans storage devices (such as storage device 1922), reading records and possibly ~ ;. .z bad blocks. Disk storage can go bad without bemg read and a bad block is not detected umtil it is read. If detection is delayed for too long after the data is written, backup copies of that data might also have gone bad. A "sniffer" attempts to find such blocks before their backup copies go bad.
A "sniffer" can operate in conjunction with the DRC 1910 by checking not only for bad data blocks but also for bad format DRFs. This ba~k~lUUUId process should not, for security reasons, have access to the bits of the encrypted files. For example, in one ~ll.I,Q~ ....,1, the files and the "sniffer"
process could reside on a commercial file server not under the control of the company or person who owns the data. The "sniffer", however, can select DRFs from files (having been modified to recognrze their existence) and send them to their respective DRCs 1910, getting back from the DRC 1910 a boolean answer mdicating whether the DRF is encrypted properly or not.
This detects improper DRF format or lack of a DRF witbin an encrypted file.
In an alternate ~ ,.,.l;",~ . where a DRC 1910 is U~ ;l..Lll..d by work from such "sniffing", the "sniffer" can be ,UlU~l_llUll~d to select a pseudo-random number and use that value to control whether to verify a particular DRF with the effect that only some percentage of the DRFs Cll~,UUlUClCd are verified. That percentage can be varied to adjust the work load presented to the DRC 1910. If the DRC 1910 replies that a DRF is bad, either it or the "sniffer" (or both) could generate an audit log entry and notify the file's owner (and possibly others in the owner's I~ lAg. .~'' ~ chain) of the error. ?~ I C of lists of persons to nûtify and methods of delivering that ~ nntif~ inn are commonly understood ~,lu~lAul.l.lllg practices and are not described here in greater detail.

WO 96/05673 2 1 9 7 2 0 6 PCTIUSgS/10221 3.2.2 Random re-building of DRFs The "sniffer" cannot verify that the storage key (KS) inside a DRF is valid because it does not have access to KS or to the private key necessary IO
decrypt the DRF. If a DRF is of the form that is re-built (by using the public key algorithm to build the DRF directly, rather than by having the public key algoritbm encrypt a secondary storage key, KS2, which is in turn used to encrypt the DRF contents), and if the encrypting user 1914 has attached a DRF Verification String (DVS), then the emergency decrypting user 1916/program can verify the DRF by rebuilding it. In the event of detection of error through this process, the normal decrypting user 1916/program would generate an audit log entry and, in one ~."l,.,ll;.,....I send messages (throughwhatever preferred means) to the file's owner and otber in the corporate Unlike the .... ~ case of the earlier ~
however, it is not proper to refuse to decrypt in this w~ a~dn~c Refusal to decrypt stored data implies loss of access to that data and it is lul~ v~Liù~of access to data that the DRC 1910 is intended to provide.
Since this rebuilding is a time-consuming operation and since the purpose of tbis re-building is to make the encrypting user 1914 more vigilant about the software being used, one ~Illbodi~ t envisions that the decrypting software re-builds only a randomly selected percentage of all DRFs. It is expected that the knowledge tbat this re-building occurs occasionally is enough to increase encrypting user 1914 vigilance.

3.2.3 Random r~",r~ " by the DRC

In alternative cllll)odilll.,llta, the DRF formats do not permit re-buildmg .
Even these formats, however, can be verified by the decrypting program, but the DRC 1910 must participate m the v.,lirl.,~ltiull process. For this reason, this DRF format might be randomly selected for ~ ir~ liull with a much lower percentage than any other kmd.

~ WO 96/05673 2 1 9 72 0 6 PCT/llS95/10221 .
In one .. l)~ of ~ iL,dLiull involving the DRC 1910, the encrypting user 1914 obtains an emergency access decryption of the file and verifies that the process works. In another cllll)o~ ll.llL, interaction betweenthe encrypting user 1914 and the DRC 1910 is reduced during ~,lirlc.~Liull. In this ~ .1; .,1, the decrypting program, after obtaining a storage key (KS) and decrypting the file, sends that KS and the DRF together to the DRC 1910, asking the DRC 1910 only to decrypt the DRF and reply whether the KS that was sent and the KS inside the DRF's datum are identical.
Access rule challenge and response is not required in this case because as a method of gaining access to a file by an outsider, this method amounts to a brute force key test but one in which each test involves c~".""", -l;.,,.
costs and is therefore slow and not subject to hll~l v ~ .lll.lll with hlll~l u ~ ,.lL~
in the speed of VLSI circuitry. It is therefore slower than alternate methods of attack and therefore not an increased security risk.

3.3 Access Rules There are two kinds of access rules (ARs) defined by the present invention, basic ~ tests and compound d ~ -, - rules. An AR
is specified by the AR defining user 1918 who defines it and sends it to the DRC 1910. In response, the DRC 1910 grants the AR defining user 1918 an access rule index (ARI). The encrypting user 1914 can then use the ARI to include in a DRF or the AR defining user 1918 can use the ARI in the definition of other ARs. This interaction between the AR defining user 1918 and the DRC 1910 is called the lc~ Ll~Liull phase and is described in greater detail below. The DRC 1910, in turn, uses an ARI to locate the associated AR and uses that rule to control challenges to the emergency decrypting user 1916 to determine the decrypter's right to access.
~ An ~ .... .....test is an example of a relatively simple AR. If the emergency decrypting user 1916 passes the test, then the emergency decrypting user 1916 gains access. More generally, the emergency decrypting ~0- .

user 1916 receives either access or a success token, which is used to respond to other challenges. A compound ~ l,.";,~li.", rule, on the other hand, specifies a group of ARls, some (or all) of which need to be saîisfied in order for the AR to be satisfied.

3.3.1 A~ ~r- - Tes~s ln one ellll,odi~ ,..L, a basic ' test includes a method for proving one's identity. In particular, it can include shared secrets (e.g., mother's maiden name), ~,ly~lu~ " protocols, third party (e.g., ~lirl.,a~ -thatthepersonpresentingdatatobevalidated possesses a pre-specifed driver's license and matches the picture, description and signature on that license), biometric tests (e.g., retnal scans~, or any other ,.. .11 1. . 'i. -I i. ..~
Additional ' tests mclude multiple prompt/reply pairs. In a multiple prompt/reply pair, an AR defining user 1918 can specify a list of N prompts and their associated replies. The AR defining user 1918 also specifies the numbers A and K (K <A <N) such that when the DRC 1910 employs the ~ i.l.. test, it randomly selects A of the N prompts to challenge the emergency decrypting user 1916. The emergency decryptmg user 1916 attempts to provide corTect replies to all selected prompts. If the emergency decrypting user 1916 gets K or more replies correct, the ,..,il,...li.,.l;,,~l test is satisfied. This variation of a shared secret test is provided for emergency decrypting users 1916 who may have trouble lr..l ..l .i"g a particular typed string but who might remember K of A of them with greater probability.
~5 Finally, in a preferred rll,l)n,l;,.,. .~l of d~ ", by shared secret, nnnfirl.-nti~lity is provided for the reply portion. Specifically, instead of storing the reply as a readable text string, during both lI,~ iUII and responses to challenges a cryplogr:lrh~ lly strong hash of the prompt and reply is formed. This hash value is ASCII encoded and sent to the DRC 1910 ~ wos6/0s673 . 11- 2~ 97206 PCTIUS95/10221 as the reply string. This c~-nfi~nri~ y permits an AR defining user 1918 to employ ~",l.- ~ g memories as a reply on the theory that such memories are unlikely to be either forgotten or shared.

3.3.2 A~ . Rules In one ~ .. 1,.,,1;.. ,1, a compound i.. ,~ rule takes the form-[n, k, ARII, ARI2, ..., ARIn]; k <n This rule is satisfied if k of the n ARIs given are satisfied. The ARs referenced by these ARls may be created by the AR defining user 1918 or by other persons known to the AR defining user 191~. For example, an AR can be created to represent the d~ rule for a company's corporate emergency access and the ARI can be listed as an optional emergency access method for each employee.
In particular, if the uol~v~ vn had a corporate ARI=c, and the employee had an individual ARI=e, the employee could create and use an ARI=u defined as u = [2, 1, e, c]. Through this definition, any file which included "u" as the ARI in its DRF is available in case of emer~ency by satisfying the ARI of either the employee or the COIlJUl~lliull.
It should be noted vhat a group with n=k is equivalent to a logical-AND of the group's rules thus implying that all ARls must be satisfied.
Similarly, a group wivh k= I is equivalent to a logical-OR of the group's rules meaning that any one of the ARls must be satisfied. A group with n= 1 and k=1 is an ARI that indirectly references another ARI.
. . = .
3.4 Use of D~CAccess to 1, ' Data Escrow The emergency access provided by a DRC 1910 does not take the place of normal access to an encrypted file. It is assumed that the normal access to = . = _ , _ _ _ _ _ ,, _ ........... ... .. ...

wo 96l05673 2 i ~ 7 2 0 6 PCTIUSgS/10221 -42- .

a storage key (KS) proceeds without paying attention to the DRF. In this situation, the normal decrypting user 1912 is the same person as the encrypting user 1914 and has knowledge of the storage key (KS) or of a method of obtaining KS; l p ~ of the DRC 1910. Thus, in most cases the DRC 1910 will never know that the encryptmg user 1914 has evén created the DRF for a file. EIowever, this invention permits a new kind of storage encryption in which the storage key is chosen randomly (e.g., by the encrypting program). (~u~ lly~ in this .ll~ln)dil~ L, tne only method of access is via the emergency use of a DRF By proper defnition of ARs, this option permits an encrypting user 1914 to implement a data escrow mechanjsm in which the grantee of the data would hold it at all times in encrypted form, and would receive use of that encrypted data only upon the c~ticf~rtif)n of a potentially complex AR. No individual person, not even the data's origmal encrypting user 1914, would be able to decrypt it without satisfying that AR.
To implement this option, one needs only a trusted DRC 1910 that would never release a decrypted DRF except upon cs~ticfi~ti~n of the ~.UII~ )Ulld;llg AR. In addition to the description of a DRC 1910 below, a DRC 1910 may be encased in a tamper-resistant enclosure and have no override access defuned. In one clllbodilll.llL, the trusted DRC 1910 is highly fault-tolerant through Icdulld~lll,y .

3.5 Ove~r~de Access In some emho~impntc~ an override access is provided. Specifically, in response to any challenge from the DRC 1910 for satisfaction of an AR, the challenged emergency decrypting user 1916 may respond "override". The emergency decrypting user 1916 is then challenged according to an override AR defined for that DRC 1910. For example, the override AR could require that 3 of 5 previously designated company officers agree to override. The definition of such a policy is via the access rule mP~-h:micm described earlier (and further described below).

~ WO 96/05673 2 t 9 7 2 ~ 6 p,~" s9s,l022l The same effect is also achieved by having the AR defining user 1918 always define and use a compound ~ rule as described earlier (e.g., u = [2, 1, e, c]). However, the override m~-rh~nicm saves the AR
defining user 1918 time in lc~i~L dliu.l and provides a guarantee that a S ~ ~ vi,hlg entity (such as ,, t) will be allowed access to all files, i~l IJ~ ...1. .11 of any actions on the part of any employee.

3.6 Operation of the DRC

Use of the emergency access capability provided by the DRC 1910 involves several separate steps:

(1) R~-gictr~tinn (2) Listing of Defined ARls, (3) Creation of DRFs, (4) Emergency Access Requests, (5) Challenge-Response Protocol, and (6) Receipt and Use of Decrypted DRF Data.

In addition to these steps, it should be noted that hlrulllldtiull to and from the DRC 1910 is frequently ~nfi~ntiAl and therefore, in a preferred r~nl,o.li,.,. .~l, the ;"lp L .." .,l-linn of the DRC 1910 includes encryption of all 1,.,1- -- li.lll~ between the DRC 1910 and the users 1916 and 1918. For that purpose, the DRC's public key (DRCpub) is used to ~:l a randomly chosen session key from the AR defming user 1918 (or the emergency decrypting user 1916) to the DRC 1910. In addition, the AR defming user 1918 (or the emergency decryptmg user 1916) includes inside the encrypted request to the DRC 1910, which reply key the DRC 1910 should - 25 use for the return message. In addition to cr~nf31rnti:l1ity, there is also the question of Since an AR defining user 1918 defines himself by providing AR definitions during lc~ LldLiull, there is no further AR

. .

~L4- .

defming user 1918 . ~h..,~ ;o., needed for the DRC 1910/AR defining user 1918 The DRC 1910 itselF, however, requires ~l. d;~ l by well known public key methods. This is ;i- o " . .~ through widespread publication of the DRC's public key using a variety of channels or signatures on the DRC's public key by a key which is either widely known or trusted (or both). If the AR defining user 1918 uses an untrusted DRC public key, then the AR
defining user 1918 is vulnerable to improper behavior by the DRC 1910 and will be unable to provide convincing evidence identifying that DRC 1910 for the purposes of legal remedy.

3.6.1 P~eg~strahon DRC 1910 I~,~;aLlaLiull (i.e., havimg an AR defming user 1918 register with a DRC 1910) involves the creation of ARs and acceptance by the AR
defining user 1918 of an access rule index (ARI) for each AR. Figure 20 illustrates generally the AR definition process between an AR defining user 1918 and DRC 1910. In this overview, the AR definition process comprises the following steps: (1) the AR defining user 1918 sends an AR
definition to the DRC 1910, (2) the DRC 1910 sends a new ARI to the AR
defining user 1918, and (3) the AR defming user 1918 files the new ARI with an optional ~ .~Luly cornment in the ARI file 1920.
The ARI is a value created by the DRC that allows the DRC to locate the AR definitions ~;ull~a~ulldillg to the ARL In a preferred ~ bodi~ ,L, the ARI contains an address at which the AR definitions are stored.
The registration process is further .~.I...,.~t~,d by a flowchart in Figure 21. In step 2106, the AR defining user 1918 obtains a DRC public key (this step is described in Section 3.6.1.1). In step 2108, the AR defining user 1918 chooses the desired l~;iall~Liull interaction. These le~,iaLI~ILiu ;..', .,..1;.--,~ include the acquisition of a new DRCpub in step 2112, creatinga new AR definition in step 2114, redefining an existing AR in step 2116, and ~ wo s6/0s673 2 1 9 7 2 0 6 PCT/IJS95/1022~

-45- .

obtaining an ARI listing in step 2118. The acquisition of a new DRCpub is described in section 3.6.1.1, the creation of a new AR is described m sections 3.6.1.2, 3.6.1.4, 3.6.1.5 and 3.6.1.6, the l~d, r~u,iull of an existing AR is described in section 3.6.1.3, and the obtaining of an ARI listmg is described in section 3.6.2.

3.6.1.1 ~1.',, . of DRCpub The initial DRC public key, here labeled DRCpub(0), is available from advertising l~ ~l ,l ;" a i. . . or through messages from other people . The security of further public key diaLI;I/u~iul~ hinges on the LluaiwulLllill~,,a of this initial key because public key a~lh ~ ., techniques can not establish absolute trust. Rather they can establish only equivalency of trust.
The DRC 1910 generates new DRC public keys from time to time, in order to minimize the volume of data which achieves emergency access umder any one key. The greater the volume that can be accessed under one key the greater the temptation for an adversary to attempt to break that particular key The DRC 1910 retains all generated DRC public-key/private-key pairs, so that anemergencydecryptinguserl916caninitiateasecure....,.. ..;~-';..nusing any of the DRCpub keys.
After a trusted DRC public key is obtained by an AR defming user 1918, the DRC 1910 returns a signed version of that DRC public key to the AR defining user 1918 (step 2106 in Figure 21). The most current DRC
public key is returned in every DRC 1910 interaction with any AR defning user 1918 as a text block appended to the DRC's normal message. On a special request by the AR defining user 1918, wherein the AR defming user 1918 sends the numher "i" (desired key number) and "k" (old key llumber), the DRC 1910 will return the new key, DRCpub(i), signed by a - prior key, DRCpub(k), of the encrypter's choice.

.

WO 96/05673 2 1 9 7 2 0 6 PCT/US95/10221 ~

~6-3.6.1.2 Crea~ion of a new Access Rule Figure 22 illustrates the process of creating a new AR that begins with step 2206 where an AR defining user 1918 sends an AR definition to the DRC 1910 which records that definition. In step i208, the DRC 1910 returns an ARI to the AR defining user 1918. The AR defining user 1918 receives this ARI in step 2210 and, after attaching an optional descriptive comment provided by the AR defining user 1918, appends the ARI record to the ARI
file. The ARI file already contains the DRCpub and any other ARls which the AR defining user 1918 has already acquired.

0 3.6.1.3 Rc ' ,~ " of an exis~ing Access Rl~le Figure 23 illustrates the process wherem an AR defning user 1918 desires to change the definition of an existing AR. Although an AR defining user 1918 is free to generate new ARs at will, a re-definition is required when there already exist files encrypted under a given ARI and the AR defining user 1918 decides to change the emergency access procedure for those existing files. To perform this re-definition, the AR defming user 1918 in step 2306 sends to the DRC 1910 the new AR definition and also the ARI ~,UII-~/Ulldillg to the AR to be defined. The AR defrning user 1918 is then challenged by the DRC 1910 in step 2308 with the ARs attached to the old ARI. If the AR
defining user 1918 fails the challenge issued by the DRC 1910, the l~der~ iu request is denied in step 2110. If the AR defrning user 1918 successfuUy meets the challenge the AR defining user 1918 is allowed to change the AR
definitions for that ARI in step 2312. For the embodiment where the DRC 1910 records an AR defining user's 1914 network address with each defrned ARI, the request for re-defrnition must come from that network address.

~ wo 96/05673 2 1 9 7 2 G 6 PCT~US9~l022l 3.6.1.4 Third Par~ Access Rules There are, from the AR defining user's 1914 point of view, third-party rule5builtu5ingthenormalA,,~ ;f-~;.".testsandgrouprules.
For example, an AR defming user 1918 rnight register with some human-staffed service to get All~ by the AR defining user's 1914 driver's license or any biometric measure (e.g., palm print, retnal scan, etc.) As shown in Figure 24, that service (1) receives tne AR defining user's 1914 license number (without requiring an in-person visit) and (2) generates an AR
which only the service 2404 could successfully satisfy, (3) receiving an ARI
for it, in return. The service 2404 next (4) attaches the resulting ARI to a record of the AR defming user's 1914 license number in the service's ARI
file 2406 and then (5) gives the resulting ARI to the AR defning user 1918.
The AR defining user 1918 would (6) make an indirect AR to that ARI (the imdirect AR definition is described in more detail below), (7) get an ARI for that new AR, and (8) file that ARI (now owned by the AR defining user 1918 rather than the service 2404) in the ARI file 2408.

3.6.1.5 Definihon of an Al '' ' ' . (group) Rule Figure 25 illustrates the process of generating a group Al~ll,.,, ;, .i.", rule. First, in step 2506, an AR defining user 1918 retrieves from his own ARI file one or more ARls to be mcluded m the group. The AR defining user 1918 sends that list in a group defmition to the DRC in step 2508, along with a number "K" indicating the number of group elements that must be satisfied to satisfy the group, and receives from the DRC 1910 an ARI ~,UII~pOlll.~
to that group in step 2510. Finally, in step 2512, the AR defming user 1918 stores the new ARI in the client's ARI file.

W096/05623 2 ~ 9 7 2 0 6 PCTiUS95/10221 3.6.1.6 Creation of an Indirect Access Rule As shown in Figure 26, the creation of an indirect AR proceedssimilarly but refers to someone else's ARI. In that case, the other person's 2606 AR~ would (1) arrive by some trusted ....,.., ~ channel rather than from the AR defming user's 1914 own ARI file 1920. The rest of the process (2)-(4) is the same as the AR definition process described above.

3.6.2 Listrng of Defined ARls An AR defining user 1918 can also ask for a listing of the status of all ARs defined by that AR defining user 1918. In one ~Illbo.li~ ll, the ; ~ ir, ~l;.. , of an AR defming user 1918 is by network address. In other e".l.o-l;,-....l~ it could be by way of an AR and its ARI defned only for the purpose of identifying ownership of ARs or it could be whatever ~ i r.. ~ 1 ;. ,n method is normal to the network or c-.,."- .;, ~ connection used by the DRC 1910. However, if a DRC 1910 is cFesigned to rrlask network addresses, an ARI can also serve as an owner identifier. In this r~ d; ~;, the owner presents his identifying ARI while asking for a listing. The DRC 1910, would then challenge the owner to prove their identity (using the identifying ARI) and oniy then provide the listing.

3.6.3 Creation of DRJi's Figure 27 illustrates a preferred embodiment of the Cu.~LIu~Liull of a DRF 2730. In this ~ an encrypting user's 1914 software creates a DRF 2730 by u~ an ARI 2706 (selected by the encrypting user 1914, depending on which AR the encrypting user 1914 wants to use) and some small User's Secret rLUS] 2708. The US 2708 is often (but not limited to) a key for the symmetric encryption for a file (i.e., KS), but can be any data which the encrypting user 1914 wants to encrypt. This c, is ~ WO 96/05673 2 1 9 72 0 6 PCT/US95/10221 called the DRF contents (DRFC) 2714. The DRFC 2714 is then encrypted using a DRCpub resulting m the Encrypted DRFC (EDRFC) 2722. The EDRFC 2722 is ~ with the Key Identifier (KI) 2712 that uniquely identifies the DRCpub used to make the EDRFC 2722. In a preferred ~ u~ the Kl 2712 comprises a network address for the DRC [DRC
ID] 2702 r - ' with a DRCpub key number 2704. An example of this KI 2712 is "drc~tis.com,4".

3.6.4 ~ Access Requests When an emergency decrypting user 1916 needs to decrypt a file whose storage key (KS) is available inside a DRF and the normal access to KS
fails, he can use the DRF attached to the file. More generally, whenever the emergency decrypting user 1916 needs whatever small secret (i.e., US 2708) is held inside the DRF, the emergency decrypting user 1916 can issue an emergency access request to the DRC 1910.
Figure 28 illustrates the method of obtaining emergency access. First, m step 2806, the ernergency decrypting user 1916 extracts from the storage medium 1922 the DRF that is attached to the file of interest (or the DRF alone if that is what is of interest) and then, in step 2808, sends the extracted DRF
to the DRC 1910. In step 2810, the DRC 1910 issues a challenge defrned by the AR definition for the ARI in the extracted DRF.
Figure 31 illustrates the processrng steps performed by DRC 1910 in issuing the challenge to the emergency decrypting user 1916. First, in step 3106, the DRC 1910 uses the Kl 2712 to identify DRCpub then retrieves, in step 3108, the DRC private key Cwl~lJulldill~ to that particular DRCpub.
In step 3110, the DRC 1910 decrypts EDRFC 2722 to obtain DRFC 2714 and retrieves the ARI 2706 from the DRFC 2714 in step 3112. Finally, the DRC 1910, in step 3114, uses ARI 2706 to locate the ~UlI-~p~Jlld;ll~ AR (e.g ., AR residing at the address ARI) and challenges the emergency decrypting user 1916 in step 3116.

wo 96ios673 2 1 9 7 2 0 6 PCT/USgS/10221 Referring again to Figure 28, if the emergency decrypting user 1916 fails to meet the challenge in step 2812, emergency access is denied in step 2814. If the emergency decrypting user 1916 meets the challenge in step 2812, the DRC 1910 sends the DRFC 2714 to the emergency decrypting S user 1916 in step 2816. The emergency decrypting user 1916 receives theDRFC 2714 in step 2818 and extracts the US 2708 from the DRFC 2714 in step 2820.
In one r.l.hv~7;~ steps 2806 and 2820 are performed by the software which initially created the file and the DRF. In this c ~ the location of the DRF within or alongside the file ~or database record, or whatever item is encrypted) is under the control of some application software rather than the DRC 1910 or its encrypting user 1914.
In one .,llLodil~ L, steps 2808 through 2818 are per~formed by the emergency decryptmg user's 1916 software, to provide an easy, seamless mterface to the DRC 1910. In a preferred ~ ho~ the emergency decrypting user's 1916 software writes the DRF to a file in step 2806 and retrieves the DRFC from a file in step 2820, allowing steps 2808 through 2814 to be performed by a separate application which is purely a DRC client.
According to one rll.hO.l;,. :, steps 2808 and 2818 involve well known methods for providing secure ildll~ .. of hhfvllll~Liull. The preferred . .l~h~ uses symmetric encryption with a session key chosen at random by the emergency decrypting user 1916. That key is encrypted in DRCpub and ' (along with a Kl 2712 to identify the key used) to the DRC 1910 along with the encrypted message. That message includes a command to the DRC 1910 to use a given (randomly chosen) key for c-"."~ back to the emergency decrypting user 1916 in step 2818.
In this maMer, the emergency decrypting user 1916 does not need to create a public key for key ~ ". purposes.

wos6/0s673 -51- 2 1 97206 PCT/U595/10221 3.6.5 (~ Response Protocol The process of responding to challenges mirrors the nested structure of the relevant AR definition. Figure 29 shows the challenge-response cycle.
In step 2906,~the DRC 1910 issues a challenge ~w~ich can be thought of as a remote-procedure-call [RPC]) and the AR defining user 1918 or emergency decryptmg user 1916 responds to that challenge in step 2908. Figure 30 shows this cycle as it pertdins to an emergency access request.
If the ARI identifies an AR ~ lihlg a simple ~ i.." test, then the emergency decrypting user 1916 has all of the hlrullll~Liull to providethe correct response. However, if the ARI specifies an AR lc~lcDc.lLillg a group or indirect AR, then the emergency decrypting user 1916 needs to perform non-local work in order to get the correct response. This non-local work will involve further nested RPCs. If the ARI specifies an mdirection, then the RPC is from one emergency decrypting user 1916 to another emergency decrypting user 1916. In various situations, the RPC could involve network ~ ~ ~" "~ " l. ~ or merely the hand-carrying of data on a floppy disk (e.g., if the indirection is for the purpose of physical d"~;~ .II;~AI;~...).
For every challenge issued by the DRC 1910, the DRC 1910 includes a Sequence token (SEQ). The SEQ is an encrypted datum which only the DRC 1910 can decrypt and which includes the recursive stdck of challenges along with the transaction number and a strong checksum on the contents of the SEQ (to detect tampering). For example, if ARI = 17 specifies a group of which ARI = 5 is a member, the first Sequence token will list a recursion depth of 1 and the set [17] as the stack. The emergency decrypting user 1916 is then challenged with a group challenge that lists the members of the group. The decrypting user 1916 chooses one of these to satisfy first, for example 5, and recursively calls the DRC 1910 to challenge the emergency decrypting user 1916 to satisfy ARI=5. That recursive call includes the SEQ which the DRC 1910 provided with the group challenge . When the DRC 1910 performs the recursive RPC, calling the emergency decrypting user 1916 to satisfy W096105673 2 1 9 7 2 ~ 6 PC~rUS9~/10221 ARI=5, that call will include a SEQ listing a recursion depth of 2 and a stack of [17,5]-In a preferred ~..,l.~lli.,....,l there are two conditions under which the DRC 1910 issues a challenge to a emergency decrypting user 1916. In the frrst condition, the emergency decrypting user 1916 submits a DRF 2730 for emergency access. This submission includes no other i~r.~" ~ A, and starts a new tr:ln~orrinn If this challenge gets a correct response, the DRC 2730 returns the DRFC 2714.
In the second condition, the emergency decrypting user 1916 submits a request to be challenged as part of fulfilling a group or indirection. This submission includes a SEQ identifying the transaction and recursive stack of which this recursive challenge is a part. The emergency decrypting user 1916 submitting that request need not be the same emergency decrypting user 1916 who submitted the DRF 2730 which started this trArro~ n If this challenge gets a correct response, the DRC 1910 returns a SUCCESS token which includes the same ;~ro""~ as the SEQ along with the fact of success.
In response to a srmple challenge (a p~ L/i c~ly or a digital signature, for example), the emergency decrypting user 1916 replies with the SEQ and the correct response. In return, the DRC 1910 :provides either the DRFC 2714 or a SUCCESS token.
In response to a group or indirect challenge, the emergency decrypting user 1916 provides one or more SUCCESS tokens which the DRC 1910 verifies as being part of this transaction and as correctly satisfying the groupor indirect AR. In return, the DRC 1910 provides either the DRFC 2714 or a SUCCESS token.
In addition, in a preferred rllll,olli~ to keep from having either the DRC 1910 or the emergency decrypting user 1916 maintain state (i.e., the contents of all variables which will be used by the computer program issuing the RPC between getting the answer from the RPC and returning to the program's caller) across RPCs, the DRC 1910 includes a state token with every RPC it initiates and the emergency decrypting user 1916 includes a state 2 ~ ~7206 token with every RPC it initiates. The responder to the RPC returns that token, if any, with its response. Those tokens are encrypted m a key known only to the originator and include ;~ ~ r ~ n to permit the originator to verifythat the token goes with the SEQ with which it is - , ' As a result, the state of the DRC 1910 and emergency decrypting user 1916 are mamtained over this recursive set of RPCs in which the identity of tlle caller keeps changing hands.

3.6.6 Receipt and Use of the DRFC

As mentioned above, the successful completion of an emergency access request is the return of a DRFC 2714 to the emergency decrypting user 1916.
The purpose of the challenge-response is to verify that the emergency decrypting user 1916 making the request is authorized to receive the DRFC 2714. Since the DRFC 2714 comprises an ARI 2706 by the AR
defming user 1918, any subsequent emergency decrypting user 1916 who can satisfy that AR 2706 has, L"caulndbly, been granted authority by the AR
defining user 1918 to have access.
Once the DRFC 2714 is returned to the emergency decrypting user 1916, the emergency decrypting user's 1916 software has the lcalJvll~;bilily for using the DRFC 2714 to provide access to the file (i.e., for extracting the US 2708 from the DRFC 2714, and perhaps for using the US 2708 to decrypt other data). Again, it should be noted that in other ~,p~ , the DRFC 2714 itself could be the u~v,l"~ltiull desired (e.g., a safe ....",I,;,.~ "). In this case there is nothing extensive needed in the software which receives the DRFC 2714.
While various c,-,l-o.liu"~,"l~ of the present invention have been described above, it should be understood that they have been presented by way - of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described WO 96/05673 2 1 9 7 2 0 6 PCTlUS9~i/lOZ~I ~

-54- .

exemplary ~",I,o,~ , but should be defined only in accordance with the following claims and their eyu;v-l

Claims (49)

What Is Claimed Is:
1. A method for controlling an emergency decrypting user's access to a secret encrypted by a file encrypting user in a data recovery field (DRF), wherein the access to the message is controlled by an access rule (AR) defined by an AR defining user, comprising the steps of:
(1) the AR defining user defining an access rule (AR) to control access to the secret and sending said AR to a data recovery center (DRC);
(2) said DRC returning an access rule index (ARI) corresponding to said AR to the AR defining user;
(3) the file encrypting user retrieving said ARI and generating the DRF, the DRF comprising said ARI and the secret encrypted by a DRC
public key;
(4) the emergency decrypting user sending the DRF to said DRC;
(5) said DRC presenting a challenge to the emergency decrypting user with said AR corresponding to said ARI in the DRF; and (6) said DRC sending the secret to the emergency decrypting use if the emergency decrypting use meets the challenges of said DRC.
2. A system for controlling access to user secret (US), the system comprising:
a data recovery center (DRC) for storing access rules (ARs);
an AR defining user that defines an AR to control access to the US, said AR defining user registering said AR with said DRC, wherein said DRC
returns an access rule index (ARI) that said AR defining user stores in an ARI
file;
a file encrypting user that creates a data recovery field (DRF), wherein said DRF comprises an ARI retrieved from said ARI file and the US
encrypted by a DRC public key;

-56- .

an emergency decrypting user that recovers the US by sending said DRF to said DRC and correctly responding to a challenge defined by an AR
that said ARI in said DRF references in said DRC.
3. A method for controlling access to a secret, the method comprising the steps of:
(1) an access rule (AR) defining user defining an AR to control access to the secret and sending said AR to a data recovery center (DRC);
(2) said DRC returning an access rule index (ARI) corresponding to said AR to said AR defining user;
(3) said AR defining user storing said ARI in an ARI file;
(4) the file encrypting user retrieving said ARI from said ARI file and generating a data recovery field (DRF), said DRF comprising said ARI
and the secret encrypted by a DRC public key.
4. A system for controlling access to a user secret (US), the system comprising:
a data recovery center (DRC) for storing access rules (ARs);
an AR defining user that defines an AR to control access to the US, said AR defining user registering said AR with said DRC, wherein said DRC
returns an access rule index (ARI) that said AR defining user stores in an ARI
file;
a file encrypting user that creates a data recovery field (DRF), wherein said DRF comprises an ARI retrieved from said ARI file and the US
encrypted by a DRC public key.
5. A method for a file encrypting user to control access by an emergency decrypting user to a user's secret (US), the access being defined by access rules (ARs) that are registered by an AR defining user with a data recovery center (DRC), the method comprising the steps of:

(1) retrieving an access rule index (ARI) from an ARI file, said ARI corresponding to an AR that the file encrypting user selects to control access to the US;
(2) generating a data recovery field (DRF), said DRF comprising the US and said ARI encrypted with a DRC public key (DRCpub); and (3) storing said DRF in a storage medium.
6. The method of claim 5, wherein said step of generating said DRF further comprises the steps of:
(a) concatenating the US with said ARI to produce a DRF contents (DRFC);
(b) encrypting said DRFC with a DRC public key to produce an encrypted DRFC (EDRFC); and (c) concatenating said EDFRC with a key identifier (KI), wherein said KI comprises a DRC ID and a DRC public key number.
7. The method of claim 5, wherein said step (2) comprises the step of generating a DRF of the form:

[ARI1,US1]DRCpub1,[ARI2,US2]DRCpub2,...,[ARIn,USn]DRCpubn, wherein US1, US2,...,USn are shares of US.
8. The method of claim 5, further comprising the step of verifying said DRF with a file sniffer program, said file sniffer program identifying bad format DRFs.
9. A file encrypting user that controls an emergency decrypting user's access to a user's secret (US), the access being defined by access rules (ARs) that are registered by an AR defining user with a data recovery center (DRC), the file encrypting user comprising:

means for retrieving an access rule index (ARI) from am ARI file, said ARI corresponding to an AR that the file encrypting user selects to control access to the US;
means for generating a data recovery field (DRF), said DRF
comprising the US and said ARI encrypted with a DRC public key; and means for storing said DRF in a storage medium.
10. The file encrypting user of claim 9, wherein said means for generating said DRF further comprises:
means for concatenating the US with said ARI to produce a DRF
contents (DRFC);
means for encrypting said DRFC with a DRC public key to produce an encrypted DRFC (EDRFC); and means for concatenating said EDFRC with a key identifier (KI), wherein said KI comprises a DRC ID and a DRC public key number.
11. The file encrypting user of claim 9, wherein said DRF is of the form:

[ARI1,US1]DRCpub1,[ARI2,US2]DRCpub2,...,[ARIn,USn]DRCpubn, wherein US1, US2,...,USn are shares of US.
12. The file encrypting user of claim 9, further comprising a file sniffer program, said file sniffer program identifying bad format DRFs.
13. An access rule (AR) defining user that registers an AR with a data recovery center (DRC), wherein the AR controls access by an emergency access decrypter to a user secret (US), the AR defining user comprising:
means for defining an access rule (AR) to control access to the US;
means for sending said AR to the DRC;

means for receiving from the DRC an access rule index (ARI) corresponding to said AR; and means for storing said ARI in an ARI file.
14. The AR defining user of claim 13, wherein said AR is an authentication rule that verifies a user's identity.
15. The AR defining user of claim 14, wherein said AR comprises N prompt/reply pairs, said AR defining user specifying the numbers A and K
(K ~ A ~ N) such that said AR definition is satisfied if a user correctly responds to K of the A prompt/reply pairs that the DRC randomly selects.
16. The AR defining user of claim 13, wherein said AR is a group authorization rule of the form [n, k, ARI1, ARI2,..., ARIn], k ~ n, such that said AR definition is satisfied if k of the n ARIs are satisfied.
17. The AR defining user of claim 13, further comprises means for redefining an old AR, said means for redefining comprising:
means for sending a new AR and an ARI to the DRC, said ARI
indexing said old AR that the AR defining user desires to redefine with said new AR; and means for responding to a DRC challenge based on said old AR.
18. A method for an access rule (AR) defining user to register an AR with a data recovery center (DRC), wherein the AR controls access by an emergency access decrypter to a secret, the method comprising the steps of:
(1) defining an access rule (AR) to control access to the secret;
(2) sending said AR to the DRC;
(3) receiving from the DRC an access rule index (ARI) corresponding to said AR; and (4) storing said ARI in an ARI file.
19. The method of claim 18, wherein said AR is an authentication rule that verifies a user's identity.
20. The method of claim 19, wherein said AR comprises N
prompt/reply pairs, said AR defining user specifying the numbers A and K (K
~ A ~ N) such that said AR definition is satisfied if a user correctly responds to K of the A prompt/reply pairs that the DRC randomly selects.
21. The method of claim 18, wherein said AR is a group authorization rule of the form [n, k, ARI1, AR12, ..., ARIn], k ~ n, such that said AR definition is satisfied if k of the n ARIs are satisfied.
22. The method of claim 18, further comprising the step of redefining an old AR, said step of redefining further comprising the steps of:
(a) sending a new AR and an ARI to the DRC, said ARI indexing said old AR that the AR defining user desires to redefine with said new AR;
and (b) responding to a DRC challenge based on said old AR.
23. A method for an emergency decrypting user to gain access to a secret, the secret being stored in a data recovery field (DRF) by a file encrypting user, wherein the DRF comprises an access rule index (ARI) and the secret encrypted by a data recovery center (DRC) public key, the ARI
indicating a storage location of an access rule (AR) within the DRC, the AR
being defined by an AR defining user, the method comprising the steps of:
(1) sending the DRF to the DRC;
(2) meeting a challenge from the DRC, said challenge based on the AR referenced by the ARI in the corresponding DRF; and (3) receiving the secret from the DRC if the challenge from the DRC is successfully met.
24. An emergency decrypting user that gains access to a user secret (US), the US being stored in a data recovery field (DRF), wherein the DRF
comprises an access rule index (ARI) and the US encrypted by a data recovery center (DRC) public key, the ARI indicating a storage location of an access rule (AR) within the DRC, the AR being defined by an AR defining user, the emergency decrypting user comprising:
means for sending the DRF to the DRC;
means for responding to a challenge from the DRC, said challenge based on the AR referenced by the ARI in the corresponding DRF; and means for receiving the US from the DRC if the challenge from the DRC is successfully met
25. A method for a data recovery center (DRC) to control access by an emergency decrypting user to a secret encrypted by a file encrypting user, the file encrypting user generating a data recovery field (DRF) comprising the secret and an access rule index (ARI) encrypted with a DRC
public key, the method comprising the steps of:
(1) receiving the DRF from the emergency decrypting user requesting access to the secret encrypted in the DRF;
(2) challenging the emergency decrypting user with said AR
corresponding to the ARI in said received DRF; and (3) sending the secret to the emergency decrypting user if the emergency decrypting user successfully meets the DRC's challenge.
26. A data recovery center (DRC) to control access by an emergency decrypting user to a user secret (US) encrypted by a file encrypting user, the file encrypting user generating a data recovery field (DRF) comprising the US and an access rule index (ARI) encrypted with a DRC
public key, the DRC comprising:
means for receiving the DRE from the emergency decrypting user requesting access to the secret encrypted in the DRF;

means for challenging the emergency decrypting user with said AR
corresponding to the ARI in said received DRF; and means for sending the US to the emergency decrypting user if the emergency decrypting user successfully meets the DRC's challenge.
27. A method for a data recovery center (DRC) to control access to a secret, the method comprising the steps of:
receiving an access rule (AR) definition from an AR defining user in communication with said data recovery center, said AR definition defining at least a portion of a procedure for authenticating a future user's identity, thereby controlling the future user's access to the secret;
generating an AR index (ARI) and associating said ARI with said AR;
and communicating said ARI to said AR defining user.
28. A data recovery center (DRC) that controls access to a secret, comprising:
means for receiving an access rule (AR) definition from an AR
defining user in communication with said data recovery center, said AR
definition defining at least a portion of a procedure for authenticating a future user's identity, thereby controlling the future user's access to the secret;
means for generating an AR index (ARI) and associating said ARI with said AR; and means for communicating said ARI to said AR defining user.
29. A method for key escrow cryptography, comprising the steps of:
(1) encrypting in a sender a message using a session key (KS) to form an encrypted message;
(2) splitting in said sender said KS to form a first session key portion (KS1) and a second session key portion (KS2);

(3) generating in said sender a law enforcement access field (LEAF) by concatenating at least a first encrypted session key portion, obtained by encrypting said KS1 with a public portion of a key associated with a first escrow agent (KEApub1), with a second encrypted session key portion, obtained by encrypting said KS2 with a public portion of a key associated with a second escrow agent (KEApub2), said LEAF being useful for authenticating said sender, said first and second escrow agents being located in a protected environment.
30. The method of claim 29, further comprising the step of:
(4) generating in said sender a leaf verification string (LVS) by concatenating at least said KS1 with said KS2.
31. The method of claim 30, further comprising the step of:
(4b) encrypting in said sender said LVS using said KS to generate an encrypted LVS (ELVS).
32. The method of claim 31, further comprising the step of:
(5) transmitting said encrypted message, said LEAF, and said ELVS from said sender to a receiver.
33. The method of claim 32, further comprising the following steps which are performed by said receiver:
(6) decrypting said ELVS using said KS to recover said LVS, and extracting at least said KS1 and said KS2 from said LVS;
(7) generating a second LEAF by concatenating at least a first trial encrypted session key portion, obtained by encrypting said extracted KS1 with a copy of said KEApub1, with a second trial encrypted session key portion, obtained by encrypting said extracted KS2 with a copy of said KEApub2;
(8) comparing said first LEAF with said second LEAF; and (9) if said first LEAF is equal to said second LEAF, then determining that said first LEAF is authentic.
34. The method of claim 33, further comprising the following steps which are performed by said receiver:
(10) combining at least said extracted KS1 with said extracted KS2 to form a trial session key;
(11) comparing said KS with said trial session key; and (12) if said KS is not equal to said trial session key, then determining that said first LEAF is not authentic.
35. The method of claim 34, further comprising the following step which is performed by said receiver:
(13) if said first LEAF is determined to be authentic, then using said KS to decrypt said encrypted message.
36. The method of claim 33, wherein said copies of said KEApub1 and KEApub2 are stored in said receiver.
37. The method of claim 33, wherein said copies of said KEApub1 and KEApub2 are stored in an external file that is accessible to said receiver.
38. The method of claim 29, wherein said KEApub1 and KEApub2 are stored in said sender.
39. The method of claim 29, wherein said KEApub1 and KEApub2 are stored in an external file that is accessible to said sender.
40. The method of claim 29 in which a private portion (KEApriv1) of said KEApub1 is maintained by said first escrow agent, and a private portion (KEApriv2) of said KEApub2 is maintained by said second escrow agent, the method further comprising the steps of:
(4) extracting in a protected environment entity at least said first encrypted session key portion and said second encrypted session key portion from said LEAF;
(5) decrypting in said first escrow agent said first encrypted session key portion using said KEApriv1 to obtain said KS1;
(6) decrypting in said second escrow agent said second encrypted session key portion using said KEApriv2 to obtain said KS2;
(7) combining in said protected environment entity at least said KS1 and said KS2 to obtain said KS; and (8) decrypting said encrypted message using said KS.
41. A method of generating a software program product operable to support key escrow crytography, comprising the steps of:
(1) generating in a protected environment a public portion (KEApub1) and a private portion (KEApriv1) of a key associated with a first escrow agent, said first escrow agent located in said protected environment;
(2) generating in said protected environment a public portion (KEApub2) and a private portion (KEApriv2) of a key associated with a second escrow agent, said second escrow agent located in said protected environment;
and (3) sending at least said KEApub1 and said KEApub2 to one or more software vendors.
42. The method of claim 41, further comprising the steps of:
storing said KEApub1 and said KEApriv1 in said first escrow agent;
and storing said KEApub2 and said KEApriv2 in said second escrow agent.
43. The method of claim 41, further comprising the steps of:

storing at least said KEApub1 and said KEApub2 in each program instance.
44. A receiver method for use in a system comprising a sender, the sender having encrypted a message using a session key (KS) to form an encrypted message, the sender also having split said KS to form a first session key portion (KS1) and a second session key portion (KS2), the sender also having generated a first law enforcement access field (LEAF) by concatenating at least a first encrypted session key portion, obtained by encrypting said KS
with a public portion of a key associated with a first escrow agent (KEApub1), with a second encrypted session key portion, obtained by encrypting said KS2 with a public portion of a key associated with a second escrow agent (KEApub2), said first and second escrow agents being located in a protected environment, the sender further having generated a leaf verification string (LVS) by concatenating at least said KS1 with said KS2, the sender also having encrypted said LVS using said KS to generate an encrypted LVS (ELVS), said receiver method comprising the steps of:
(1) receiving said encrypted message, said first LEAF, and said ELVS;
(2) decrypting said ELVS using said KS to recover said LVS, and extracting at least said KS1 and said KS2 from said LVS;
(3) generating a second LEAF by concatenating at least a first trial encrypted session key portion, obtained by encrypting said extracted KS1 with a copy of said KEApub1, with a second trial encrypted session key portion, obtained by encrypting said extracted KS2 with a copy of said KEApub2;
(4) comparing said first LEAF with said second LEAF; and (5) if said first LEAF is equal to said second LEAF, then determining that said first LEAF is authentic.
45. The receiver method of claim 44, further comprising the steps of:

(6) combining at least said extracted KS1 with said extracted KS2 to form a trial session key;
(7) comparing said KS with said trial session key; and (8) if said KS is not equal to said trial session key, then determining that said first LEAF is not authentic.
46. The receiver method of claim 44, further comprising the step of:
(6) if said first LEAF is determined to be authentic, then using said KS to decrypt said encrypted message.
47. A sender, comprising:
means for encrypting a message using a session key (KS) to form am encrypted message;
means for splitting said KS to form a first session key portion (KS1) and a second session key portion (KS2); and means for generating a law enforcement access field (LEAF) by concatenating at least a first encrypted session key portion, obtained by encrypting said KS1 with a public portion of a key associated with a first escrow agent (KEApub1), with a second encrypted session key portion, obtained by encrypting said KS2 with a public portion of a key associated with a second escrow agent (KEApub2), said LEAF being useful for authenticating said sender, said first and second escrow agents being located in a protected environment.
48. A receiver for use in a system comprising a sender, the sender having encrypted a message using a session key (KS) to form an encrypted message, the sender also having generated an encrypted leaf verification string (ELVS) by encrypting the combination of KS1 and KS2, where KS = KS1 XOR KS2, with KS, the sender also having generated a first law enforcement access field (LEAF) by concatenating the encryption of KS1 with public key KEApub1 and the encryption of KS2 with public key KEApub2, said receiver comprising:
means for receiving said encrypted message and said first LEAF;
means for reconstructing a second LEAF using a copy of said KS and public information;
means for comparing the first LEAF to said second LEAF;
means for determining that the first LEAF is authentic if the first LEAF is equal to said second LEAF; and means for decrypting said encrypted message using the KS if it is determined that the first LEAF is authentic.
49. A system for generating a software program product operable to support key escrow cryptography, the system representing a protected environment and comprising:
means for generating a public portion (KEApub1) and a private portion (KEApriv1) of a key associated with a first escrow agent, said first escrow agent located in said protected environment;
means for generating a public portion (KEApub2) and a private portion (KEApriv2) of a key associated with a second escrow agent, said second escrow agent located in said protected environment; and means for sending at least said KEApub1 and said KEApub2 to one or more software vendors.
CA002197206A 1994-08-11 1995-08-11 System and method for key escrow and data escrow encryption Abandoned CA2197206A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US08/289,602 1994-08-11
US08/289,602 US5557346A (en) 1994-08-11 1994-08-11 System and method for key escrow encryption
US08/390,959 US5557765A (en) 1994-08-11 1995-02-21 System and method for data recovery
US08/390,959 1995-02-21

Publications (1)

Publication Number Publication Date
CA2197206A1 true CA2197206A1 (en) 1996-02-22

Family

ID=26965728

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002197206A Abandoned CA2197206A1 (en) 1994-08-11 1995-08-11 System and method for key escrow and data escrow encryption

Country Status (9)

Country Link
US (3) US5557765A (en)
EP (1) EP0775401A1 (en)
JP (1) JPH10508438A (en)
CN (1) CN1158195A (en)
AU (1) AU3321795A (en)
BR (1) BR9508548A (en)
CA (1) CA2197206A1 (en)
MX (1) MX9700980A (en)
WO (1) WO1996005673A1 (en)

Families Citing this family (259)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292568B1 (en) 1966-12-16 2001-09-18 Scientific-Atlanta, Inc. Representing entitlements to service in a conditional access system
US5870474A (en) * 1995-12-04 1999-02-09 Scientific-Atlanta, Inc. Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providers
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US8352400B2 (en) 1991-12-23 2013-01-08 Hoffberg Steven M Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore
GB9320793D0 (en) * 1993-10-08 1993-12-08 Secr Defence Cryptographic receiver
US5557765A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for data recovery
US5557346A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for key escrow encryption
US6272632B1 (en) 1995-02-21 2001-08-07 Network Associates, Inc. System and method for controlling access to a user secret using a key recovery field
US6424717B1 (en) 1995-04-03 2002-07-23 Scientific-Atlanta, Inc. Encryption devices for use in a conditional access system
US20040136532A1 (en) * 1995-04-03 2004-07-15 Pinder Howard G. Partial dual-encrypted stream utilizing program map tables
US6157719A (en) * 1995-04-03 2000-12-05 Scientific-Atlanta, Inc. Conditional access system
US6937729B2 (en) * 1995-04-03 2005-08-30 Scientific-Atlanta, Inc. Representing entitlements to service in a conditional access system
US6246767B1 (en) 1995-04-03 2001-06-12 Scientific-Atlanta, Inc. Source authentication of download information in a conditional access system
US8548166B2 (en) 1995-04-03 2013-10-01 Anthony J. Wasilewski Method for partially encrypting program data
US7224798B2 (en) * 1995-04-03 2007-05-29 Scientific-Atlanta, Inc. Methods and apparatus for providing a partial dual-encrypted stream in a conditional access overlay system
US6560340B1 (en) 1995-04-03 2003-05-06 Scientific-Atlanta, Inc. Method and apparatus for geographically limiting service in a conditional access system
US6105134A (en) * 1995-04-03 2000-08-15 Scientific-Atlanta, Inc. Verification of the source of program information in a conditional access system
US6252964B1 (en) 1995-04-03 2001-06-26 Scientific-Atlanta, Inc. Authorization of services in a conditional access system
US5852665A (en) * 1995-04-13 1998-12-22 Fortress U & T Ltd. Internationally regulated system for one to one cryptographic communications with national sovereignty without key escrow
IL113375A (en) * 1995-04-13 1997-09-30 Fortress U & T Ltd Internationally regulated system for one to one cryptographic communications with national sovereignty without key escrow
US5757924A (en) * 1995-09-18 1998-05-26 Digital Secured Networks Techolognies, Inc. Network security device which performs MAC address translation without affecting the IP address
US6088515A (en) 1995-11-13 2000-07-11 Citrix Systems Inc Method and apparatus for making a hypermedium interactive
GB2308282B (en) * 1995-12-15 2000-04-12 Lotus Dev Corp Differential work factor cryptography method and system
US5764772A (en) * 1995-12-15 1998-06-09 Lotus Development Coporation Differential work factor cryptography method and system
EP0872077B1 (en) * 1995-12-29 2009-09-23 Scientific-Atlanta, Inc. Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providers
US5768373A (en) * 1996-05-06 1998-06-16 Symantec Corporation Method for providing a secure non-reusable one-time password
US5901227A (en) * 1996-06-20 1999-05-04 Novell, Inc. Method and apparatus for implementing partial and complete optional key escrow
US5796830A (en) * 1996-07-29 1998-08-18 International Business Machines Corporation Interoperable cryptographic key recovery system
US5764767A (en) * 1996-08-21 1998-06-09 Technion Research And Development Foundation Ltd. System for reconstruction of a secret shared by a plurality of participants
US6052780A (en) * 1996-09-12 2000-04-18 Open Security Solutions, Llc Computer system and process for accessing an encrypted and self-decrypting digital information product while restricting access to decrypted digital information
US5937066A (en) * 1996-10-02 1999-08-10 International Business Machines Corporation Two-phase cryptographic key recovery system
US6483920B2 (en) * 1996-12-04 2002-11-19 Bull, S.A. Key recovery process used for strong encryption of messages
FR2763192B1 (en) * 1996-10-18 1999-07-02 Bull Sa METHOD FOR RECOVERING KEYS IMPLEMENTED FOR A STRONG MESSAGE ENCRYPTION
US5974151A (en) * 1996-11-01 1999-10-26 Slavin; Keith R. Public key cryptographic system having differential security levels
US5907618A (en) * 1997-01-03 1999-05-25 International Business Machines Corporation Method and apparatus for verifiably providing key recovery information in a cryptographic system
EP0951767A2 (en) 1997-01-03 1999-10-27 Fortress Technologies, Inc. Improved network security device
EP0856968A3 (en) 1997-01-24 2000-12-06 Nec Corporation Encryption key processing system to be incorporated into data recovery system or key setting system for generating encryption key
US7212632B2 (en) 1998-02-13 2007-05-01 Tecsec, Inc. Cryptographic key split combiner
US5920630A (en) * 1997-02-25 1999-07-06 United States Of America Method of public key cryptography that includes key escrow
US6396805B2 (en) * 1997-03-25 2002-05-28 Intel Corporation System for recovering from disruption of a data transfer
US6249585B1 (en) * 1998-04-08 2001-06-19 Network Associates, Inc Publicly verifiable key recovery
WO1998047260A2 (en) * 1997-04-11 1998-10-22 Network Associates, Inc. Publicly verifiable key recovery
JPH10301773A (en) * 1997-04-30 1998-11-13 Sony Corp Information processor and method therefor and recording medium
US6694433B1 (en) * 1997-05-08 2004-02-17 Tecsec, Inc. XML encryption scheme
US6389136B1 (en) 1997-05-28 2002-05-14 Adam Lucas Young Auto-Recoverable and Auto-certifiable cryptosystems with RSA or factoring based keys
US6202150B1 (en) 1997-05-28 2001-03-13 Adam Lucas Young Auto-escrowable and auto-certifiable cryptosystems
US6122742A (en) * 1997-06-18 2000-09-19 Young; Adam Lucas Auto-recoverable and auto-certifiable cryptosystem with unescrowed signing keys
DE69720971T2 (en) * 1997-05-28 2003-10-30 Siemens Ag Computer system and software protection method
US6282295B1 (en) 1997-10-28 2001-08-28 Adam Lucas Young Auto-recoverable and auto-certifiable cryptostem using zero-knowledge proofs for key escrow in general exponential ciphers
US6243466B1 (en) 1997-08-29 2001-06-05 Adam Lucas Young Auto-escrowable and auto-certifiable cryptosystems with fast key generation
US6314190B1 (en) * 1997-06-06 2001-11-06 Networks Associates Technology, Inc. Cryptographic system with methods for user-controlled message recovery
US6061454A (en) * 1997-06-27 2000-05-09 International Business Machines Corp. System, method, and computer program for communicating a key recovery block to enable third party monitoring without modification to the intended receiver
US6775382B1 (en) 1997-06-30 2004-08-10 Sun Microsystems, Inc. Method and apparatus for recovering encryption session keys
US6185308B1 (en) * 1997-07-07 2001-02-06 Fujitsu Limited Key recovery system
JP3076273B2 (en) * 1997-07-07 2000-08-14 日本電気株式会社 Key recovery condition encryption device and decryption device
JPH1127253A (en) 1997-07-07 1999-01-29 Hitachi Ltd Key recovery system, key recovery device, recording medium for storing key recovery program and key recovery method
US6229894B1 (en) * 1997-07-14 2001-05-08 Entrust Technologies, Ltd. Method and apparatus for access to user-specific encryption information
US6058188A (en) * 1997-07-24 2000-05-02 International Business Machines Corporation Method and apparatus for interoperable validation of key recovery information in a cryptographic system
US7515712B2 (en) 1997-08-01 2009-04-07 Cisco Technology, Inc. Mechanism and apparatus for encapsulation of entitlement authorization in conditional access system
US6549626B1 (en) 1997-10-20 2003-04-15 Sun Microsystems, Inc. Method and apparatus for encoding keys
EP0912011A3 (en) * 1997-10-20 2001-11-28 Sun Microsystems, Inc. Method and apparatus for encoding and recovering keys
US6098056A (en) * 1997-11-24 2000-08-01 International Business Machines Corporation System and method for controlling access rights to and security of digital content in a distributed information system, e.g., Internet
US20050114705A1 (en) * 1997-12-11 2005-05-26 Eran Reshef Method and system for discriminating a human action from a computerized action
JP4313873B2 (en) * 1998-01-30 2009-08-12 キヤノン株式会社 Electronic device and data processing method
US8077870B2 (en) * 1998-02-13 2011-12-13 Tecsec, Inc. Cryptographic key split binder for use with tagged data elements
US7095852B2 (en) * 1998-02-13 2006-08-22 Tecsec, Inc. Cryptographic key split binder for use with tagged data elements
WO1999049613A1 (en) * 1998-02-20 1999-09-30 Fortress Technologies, Inc. Cryptographic key-recovery mechanism
US6324650B1 (en) * 1998-03-16 2001-11-27 John W.L. Ogilvie Message content protection and conditional disclosure
US6298445B1 (en) 1998-04-30 2001-10-02 Netect, Ltd. Computer security
US6584310B1 (en) * 1998-05-07 2003-06-24 Lucent Technologies Inc. Method and apparatus for performing authentication in communication systems
US6941463B1 (en) 1998-05-14 2005-09-06 Purdue Research Foundation Secure computational outsourcing techniques
US6957341B2 (en) * 1998-05-14 2005-10-18 Purdue Research Foundation Method and system for secure computational outsourcing and disguise
US6370251B1 (en) 1998-06-08 2002-04-09 General Dynamics Decision Systems, Inc. Traffic key access method and terminal for secure communication without key escrow facility
US6336187B1 (en) 1998-06-12 2002-01-01 International Business Machines Corp. Storage system with data-dependent security
US6317829B1 (en) * 1998-06-19 2001-11-13 Entrust Technologies Limited Public key cryptography based security system to facilitate secure roaming of users
US6219790B1 (en) * 1998-06-19 2001-04-17 Lucent Technologies Inc. Centralized authentication, authorization and accounting server with support for multiple transport protocols and multiple client types
US7111173B1 (en) * 1998-09-01 2006-09-19 Tecsec, Inc. Encryption process including a biometric unit
US6311270B1 (en) * 1998-09-14 2001-10-30 International Business Machines Corporation Method and apparatus for securing communication utilizing a security processor
GB9820558D0 (en) * 1998-09-21 1998-11-11 Post Office A secure data transfer system
US7174457B1 (en) * 1999-03-10 2007-02-06 Microsoft Corporation System and method for authenticating an operating system to a central processing unit, providing the CPU/OS with secure storage, and authenticating the CPU/OS to a third party
US7194092B1 (en) 1998-10-26 2007-03-20 Microsoft Corporation Key-based secure storage
US7139915B2 (en) * 1998-10-26 2006-11-21 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US6438695B1 (en) * 1998-10-30 2002-08-20 3Com Corporation Secure wiretap support for internet protocol security
US6530024B1 (en) 1998-11-20 2003-03-04 Centrax Corporation Adaptive feedback security system and method
JP2000165373A (en) 1998-11-25 2000-06-16 Toshiba Corp Enciphering device, cryptographic communication system, key restoration system and storage medium
US6473508B1 (en) 1998-12-22 2002-10-29 Adam Lucas Young Auto-recoverable auto-certifiable cryptosystems with unescrowed signature-only keys
WO2000041103A1 (en) * 1998-12-31 2000-07-13 Perfecto Technologies Ltd. Method and system for discriminating a human action from a computerized action
US6396929B1 (en) 1998-12-31 2002-05-28 International Business Machines Corporation Apparatus, method, and computer program product for high-availability multi-agent cryptographic key recovery
US7171000B1 (en) 1999-06-10 2007-01-30 Message Secure Corp. Simplified addressing for private communications
US7966078B2 (en) 1999-02-01 2011-06-21 Steven Hoffberg Network media appliance system and method
US7162452B1 (en) 1999-03-25 2007-01-09 Epstein Michael A Key distribution via a memory device
US7136838B1 (en) * 1999-03-27 2006-11-14 Microsoft Corporation Digital license and method for obtaining/providing a digital license
US6973444B1 (en) * 1999-03-27 2005-12-06 Microsoft Corporation Method for interdependently validating a digital content package and a corresponding digital license
US6901145B1 (en) 1999-04-08 2005-05-31 Lucent Technologies Inc. Generation of repeatable cryptographic key based on varying parameters
US6625734B1 (en) * 1999-04-26 2003-09-23 Disappearing, Inc. Controlling and tracking access to disseminated information
US7499551B1 (en) 1999-05-14 2009-03-03 Dell Products L.P. Public key infrastructure utilizing master key encryption
DE19925910B4 (en) * 1999-06-07 2005-04-28 Siemens Ag Method for processing or processing data
US20020019932A1 (en) * 1999-06-10 2002-02-14 Eng-Whatt Toh Cryptographically secure network
US20020101998A1 (en) * 1999-06-10 2002-08-01 Chee-Hong Wong Fast escrow delivery
US6988199B2 (en) 2000-07-07 2006-01-17 Message Secure Secure and reliable document delivery
WO2001013293A1 (en) * 1999-08-12 2001-02-22 Matsushita Electric Industrial Co., Ltd. Electronic information backup system
US7757097B2 (en) * 1999-09-03 2010-07-13 Purdue Research Foundation Method and system for tamperproofing software
US7287166B1 (en) 1999-09-03 2007-10-23 Purdue Research Foundation Guards for application in software tamperproofing
US7461022B1 (en) 1999-10-20 2008-12-02 Yahoo! Inc. Auction redemption system and method
US7039713B1 (en) * 1999-11-09 2006-05-02 Microsoft Corporation System and method of user authentication for network communication through a policy agent
CN100340079C (en) * 1999-12-07 2007-09-26 三洋电机株式会社 Device for reproducing data
US6757824B1 (en) * 1999-12-10 2004-06-29 Microsoft Corporation Client-side boot domains and boot rules
US6938013B1 (en) 2000-01-05 2005-08-30 Uniteller Financial Services, Inc. Money-transfer techniques
FR2804561B1 (en) * 2000-01-31 2002-03-01 France Telecom COMMUNICATION METHOD WITH SEQUESTRE AND ENCRYPTION KEY RECOVERY
US6978385B1 (en) 2000-03-01 2005-12-20 International Business Machines Corporation Data processing system and method for remote recovery of a primary password
US7412604B1 (en) 2000-03-28 2008-08-12 International Business Machines Corporation Using biometrics on pervasive devices for mobile identification
US6823070B1 (en) * 2000-03-28 2004-11-23 Freescale Semiconductor, Inc. Method for key escrow in a communication system and apparatus therefor
DE10025626A1 (en) * 2000-05-24 2001-11-29 Deutsche Telekom Ag Encrypt data to be stored in an IV system
US20040073617A1 (en) 2000-06-19 2004-04-15 Milliken Walter Clark Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail
US7093020B1 (en) 2000-06-29 2006-08-15 Sungard Sct Inc. Methods and systems for coordinating sessions on one or more systems
US20020029269A1 (en) 2000-06-29 2002-03-07 Campus Pipeline, Inc. Methods and systems for coordinating the termination of sessions on one or more systems
US20020057284A1 (en) 2000-06-29 2002-05-16 Dalby Richard Sean Methods and systems for delivering announcements to users of an information system
WO2002005061A2 (en) * 2000-07-06 2002-01-17 David Paul Felsher Information record infrastructure, system and method
US7251728B2 (en) 2000-07-07 2007-07-31 Message Secure Corporation Secure and reliable document delivery using routing lists
AU2001283215A1 (en) * 2000-08-14 2002-02-25 Yahoo, Inc. Offline-online incentive points system and method
US8307098B1 (en) * 2000-08-29 2012-11-06 Lenovo (Singapore) Pte. Ltd. System, method, and program for managing a user key used to sign a message for a data processing system
US20020048372A1 (en) * 2000-10-19 2002-04-25 Eng-Whatt Toh Universal signature object for digital data
US7181017B1 (en) 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US7359518B2 (en) * 2001-04-05 2008-04-15 Intel Corporation Distribution of secured information
US6944300B2 (en) * 2001-06-22 2005-09-13 International Business Machines Corporaton Method for migrating a base chip key from one computer system to another
US8006280B1 (en) * 2001-12-12 2011-08-23 Hildebrand Hal S Security system for generating keys from access rules in a decentralized manner and methods therefor
US8065713B1 (en) 2001-12-12 2011-11-22 Klimenty Vainstein System and method for providing multi-location access management to secured items
US7681034B1 (en) 2001-12-12 2010-03-16 Chang-Ping Lee Method and apparatus for securing electronic data
US7380120B1 (en) 2001-12-12 2008-05-27 Guardian Data Storage, Llc Secured data format for access control
US7178033B1 (en) * 2001-12-12 2007-02-13 Pss Systems, Inc. Method and apparatus for securing digital assets
US10033700B2 (en) 2001-12-12 2018-07-24 Intellectual Ventures I Llc Dynamic evaluation of access rights
US7562232B2 (en) 2001-12-12 2009-07-14 Patrick Zuili System and method for providing manageability to security information for secured items
US7260555B2 (en) 2001-12-12 2007-08-21 Guardian Data Storage, Llc Method and architecture for providing pervasive security to digital assets
US7783765B2 (en) 2001-12-12 2010-08-24 Hildebrand Hal S System and method for providing distributed access control to secured documents
US7565683B1 (en) 2001-12-12 2009-07-21 Weiqing Huang Method and system for implementing changes to security policies in a distributed security system
US7921284B1 (en) 2001-12-12 2011-04-05 Gary Mark Kinghorn Method and system for protecting electronic data in enterprise environment
US7478418B2 (en) 2001-12-12 2009-01-13 Guardian Data Storage, Llc Guaranteed delivery of changes to security policies in a distributed system
US10360545B2 (en) 2001-12-12 2019-07-23 Guardian Data Storage, Llc Method and apparatus for accessing secured electronic data off-line
US7631184B2 (en) 2002-05-14 2009-12-08 Nicholas Ryan System and method for imposing security on copies of secured items
US7921450B1 (en) 2001-12-12 2011-04-05 Klimenty Vainstein Security system using indirect key generation from access rules and methods therefor
USRE41546E1 (en) 2001-12-12 2010-08-17 Klimenty Vainstein Method and system for managing security tiers
US7921288B1 (en) 2001-12-12 2011-04-05 Hildebrand Hal S System and method for providing different levels of key security for controlling access to secured items
US7930756B1 (en) 2001-12-12 2011-04-19 Crocker Steven Toye Multi-level cryptographic transformations for securing digital assets
US7950066B1 (en) 2001-12-21 2011-05-24 Guardian Data Storage, Llc Method and system for restricting use of a clipboard application
US20030149884A1 (en) * 2002-02-01 2003-08-07 Randolph Hernandez Electronic information content control
US7146009B2 (en) * 2002-02-05 2006-12-05 Surety, Llc Secure electronic messaging system requiring key retrieval for deriving decryption keys
US8176334B2 (en) 2002-09-30 2012-05-08 Guardian Data Storage, Llc Document security system that permits external users to gain access to secured files
EP1345395B1 (en) * 2002-03-15 2013-05-08 Alcatel Lucent Method for intercepting communication connections
GB2386710A (en) * 2002-03-18 2003-09-24 Hewlett Packard Co Controlling access to data or documents
US7890771B2 (en) 2002-04-17 2011-02-15 Microsoft Corporation Saving and retrieving data based on public key encryption
CA2425010C (en) * 2002-04-17 2013-11-19 Microsoft Corporation Saving and retrieving data based on public key encryption
US7487365B2 (en) * 2002-04-17 2009-02-03 Microsoft Corporation Saving and retrieving data based on symmetric key encryption
US7748045B2 (en) * 2004-03-30 2010-06-29 Michael Frederick Kenrich Method and system for providing cryptographic document retention with off-line access
US8613102B2 (en) 2004-03-30 2013-12-17 Intellectual Ventures I Llc Method and system for providing document retention using cryptography
GB0210325D0 (en) * 2002-05-04 2002-06-12 Gaffney Philip M Secure data delivery
US7941662B2 (en) * 2002-05-31 2011-05-10 Broadcom Corporation Data transfer efficiency in a cryptography accelerator system
US8393001B1 (en) 2002-07-26 2013-03-05 Mcafee, Inc. Secure signature server system and associated method
US7512810B1 (en) 2002-09-11 2009-03-31 Guardian Data Storage Llc Method and system for protecting encrypted files transmitted over a network
US7836310B1 (en) 2002-11-01 2010-11-16 Yevgeniy Gutnik Security system that uses indirect password-based encryption
US7207067B2 (en) * 2002-11-12 2007-04-17 Aol Llc Enforcing data protection legislation in Web data services
US7577838B1 (en) 2002-12-20 2009-08-18 Alain Rossmann Hybrid systems for securing digital assets
US7890990B1 (en) 2002-12-20 2011-02-15 Klimenty Vainstein Security system with staging capabilities
US9818136B1 (en) 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US7370212B2 (en) 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
US8510571B1 (en) 2003-03-24 2013-08-13 Hoi Chang System and method for inserting security mechanisms into a software program
US20040230817A1 (en) * 2003-05-14 2004-11-18 Kenneth Ma Method and system for disaster recovery of data from a storage device
US8707034B1 (en) 2003-05-30 2014-04-22 Intellectual Ventures I Llc Method and system for using remote headers to secure electronic files
US7152693B2 (en) * 2003-05-30 2006-12-26 International Business Machines Corporation Password security utility
US7730543B1 (en) 2003-06-30 2010-06-01 Satyajit Nath Method and system for enabling users of a group shared across multiple file security systems to access secured files
US9118710B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc System, method, and computer program product for reporting an occurrence in different manners
US9100431B2 (en) 2003-07-01 2015-08-04 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US8984644B2 (en) 2003-07-01 2015-03-17 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9350752B2 (en) 2003-07-01 2016-05-24 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US20070113272A2 (en) 2003-07-01 2007-05-17 Securityprofiling, Inc. Real-time vulnerability monitoring
US9118711B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118709B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118708B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Multi-path remediation
FR2857184A1 (en) * 2003-07-04 2005-01-07 Thomson Licensing Sa METHOD OF ENCRYPTING / DECEIVING A MESSAGE AND ASSOCIATED DEVICE
US7555558B1 (en) 2003-08-15 2009-06-30 Michael Frederick Kenrich Method and system for fault-tolerant transfer of files across a network
US8127366B2 (en) 2003-09-30 2012-02-28 Guardian Data Storage, Llc Method and apparatus for transitioning between states of security policies used to secure electronic documents
US7703140B2 (en) 2003-09-30 2010-04-20 Guardian Data Storage, Llc Method and system for securing digital assets using process-driven security policies
US7290278B2 (en) 2003-10-02 2007-10-30 Aol Llc, A Delaware Limited Liability Company Identity based service system
US8396216B2 (en) 2003-11-21 2013-03-12 Howard G. Pinder Partial dual-encryption using program map tables
US7702909B2 (en) * 2003-12-22 2010-04-20 Klimenty Vainstein Method and system for validating timestamps
US8312262B2 (en) * 2004-04-30 2012-11-13 Qualcomm Incorporated Management of signing privileges for a cryptographic signing service
US7707427B1 (en) 2004-07-19 2010-04-27 Michael Frederick Kenrich Multi-level file digests
US7748032B2 (en) 2004-09-30 2010-06-29 Citrix Systems, Inc. Method and apparatus for associating tickets in a ticket hierarchy
US20060069662A1 (en) * 2004-09-30 2006-03-30 Citrix Systems, Inc. Method and apparatus for remapping accesses to virtual system resources
US7680758B2 (en) 2004-09-30 2010-03-16 Citrix Systems, Inc. Method and apparatus for isolating execution of software applications
US8095940B2 (en) 2005-09-19 2012-01-10 Citrix Systems, Inc. Method and system for locating and accessing resources
US7711835B2 (en) 2004-09-30 2010-05-04 Citrix Systems, Inc. Method and apparatus for reducing disclosure of proprietary data in a networked environment
US8171479B2 (en) 2004-09-30 2012-05-01 Citrix Systems, Inc. Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers
US8613048B2 (en) * 2004-09-30 2013-12-17 Citrix Systems, Inc. Method and apparatus for providing authorized remote access to application sessions
US8347078B2 (en) 2004-10-18 2013-01-01 Microsoft Corporation Device certificate individualization
US8336085B2 (en) 2004-11-15 2012-12-18 Microsoft Corporation Tuning product policy using observed evidence of customer behavior
US8024568B2 (en) 2005-01-28 2011-09-20 Citrix Systems, Inc. Method and system for verification of an endpoint security scan
DE102005004612A1 (en) * 2005-02-01 2006-08-10 Siemens Ag Method for connecting to encrypted communication links in a packet-oriented network
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
US8725646B2 (en) 2005-04-15 2014-05-13 Microsoft Corporation Output protection levels
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US20060265758A1 (en) 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
US20060288225A1 (en) * 2005-06-03 2006-12-21 Jung Edward K User-centric question and answer for authentication and security
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US20070083610A1 (en) * 2005-10-07 2007-04-12 Treder Terry N Method and a system for accessing a plurality of files comprising an application program
US7779034B2 (en) 2005-10-07 2010-08-17 Citrix Systems, Inc. Method and system for accessing a remote file in a directory structure associated with an application program executing locally
US8131825B2 (en) 2005-10-07 2012-03-06 Citrix Systems, Inc. Method and a system for responding locally to requests for file metadata associated with files stored remotely
KR100750153B1 (en) * 2006-01-03 2007-08-21 삼성전자주식회사 Method and apparatus for providing session key for WUSB security, method and apparatus for obtaining the session key
US7499552B2 (en) 2006-01-11 2009-03-03 International Business Machines Corporation Cipher method and system for verifying a decryption of an encrypted user data key
US20070174429A1 (en) 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
US7685630B2 (en) * 2006-05-04 2010-03-23 Citrix Online, Llc Methods and systems for providing scalable authentication
US10062062B1 (en) 2006-05-25 2018-08-28 Jbshbm, Llc Automated teller machine (ATM) providing money for loyalty points
US9704174B1 (en) 2006-05-25 2017-07-11 Sean I. Mcghie Conversion of loyalty program points to commerce partner points per terms of a mutual agreement
US8668146B1 (en) 2006-05-25 2014-03-11 Sean I. Mcghie Rewards program with payment artifact permitting conversion/transfer of non-negotiable credits to entity independent funds
US7703673B2 (en) 2006-05-25 2010-04-27 Buchheit Brian K Web based conversion of non-negotiable credits associated with an entity to entity independent negotiable funds
US8684265B1 (en) 2006-05-25 2014-04-01 Sean I. Mcghie Rewards program website permitting conversion/transfer of non-negotiable credits to entity independent funds
US20080022120A1 (en) * 2006-06-05 2008-01-24 Michael Factor System, Method and Computer Program Product for Secure Access Control to a Storage Device
US20070297001A1 (en) * 2006-06-22 2007-12-27 Brian Podl Multi-function peripheral remote alert notification system and method
FR2905216B1 (en) * 2006-08-25 2009-03-06 Thales Sa METHOD FOR CUSTOMIZING A SECURITY COMPONENT, IN PARTICULAR IN AN UN-PROTECTED ENVIRONMENT
US8245050B1 (en) 2006-09-29 2012-08-14 Netapp, Inc. System and method for initial key establishment using a split knowledge protocol
JP2008103936A (en) 2006-10-18 2008-05-01 Toshiba Corp Secret information management device, and secret information management system
US8533846B2 (en) 2006-11-08 2013-09-10 Citrix Systems, Inc. Method and system for dynamically associating access rights with a resource
GB2446199A (en) 2006-12-01 2008-08-06 David Irvine Secure, decentralised and anonymous peer-to-peer network
US8015039B2 (en) * 2006-12-14 2011-09-06 Sap Ag Enterprise verification and certification framework
US8611542B1 (en) 2007-04-26 2013-12-17 Netapp, Inc. Peer to peer key synchronization
US8824686B1 (en) 2007-04-27 2014-09-02 Netapp, Inc. Cluster key synchronization
US8196182B2 (en) 2007-08-24 2012-06-05 Netapp, Inc. Distributed management of crypto module white lists
US20090064134A1 (en) * 2007-08-30 2009-03-05 Citrix Systems,Inc. Systems and methods for creating and executing files
US9774445B1 (en) 2007-09-04 2017-09-26 Netapp, Inc. Host based rekeying
US8171483B2 (en) 2007-10-20 2012-05-01 Citrix Systems, Inc. Method and system for communicating between isolation environments
US20090182668A1 (en) * 2008-01-11 2009-07-16 Nortel Networks Limited Method and apparatus to enable lawful intercept of encrypted traffic
US8169436B2 (en) * 2008-01-27 2012-05-01 Citrix Systems, Inc. Methods and systems for remoting three dimensional graphics
MY153097A (en) * 2008-03-28 2014-12-31 Exxonmobil Upstream Res Co Low emission power generation and hydrocarbon recovery systems and methods
US8189794B2 (en) * 2008-05-05 2012-05-29 Sony Corporation System and method for effectively performing data restore/migration procedures
CA2933829C (en) * 2008-07-18 2019-03-12 Absolute Software Corporation Privacy management for tracked devices
EP2345222B1 (en) * 2008-10-10 2016-08-24 Telefonaktiebolaget LM Ericsson (publ) Lawful authorities warrant management
US8090797B2 (en) 2009-05-02 2012-01-03 Citrix Systems, Inc. Methods and systems for launching applications into existing isolation environments
CN102473129B (en) * 2009-07-16 2015-12-02 株式会社日立制作所 Export the management system of the information of the restoration methods representing corresponding with the basic reason of fault
US8913992B2 (en) * 2010-11-03 2014-12-16 Stephan V. Schell Methods and apparatus for access data recovery from a malfunctioning device
US9135460B2 (en) * 2011-12-22 2015-09-15 Microsoft Technology Licensing, Llc Techniques to store secret information for global data centers
US9094489B1 (en) * 2012-05-29 2015-07-28 West Corporation Controlling a crowd of multiple mobile station devices
US11032259B1 (en) * 2012-09-26 2021-06-08 Pure Storage, Inc. Data protection in a storage system
US10623386B1 (en) * 2012-09-26 2020-04-14 Pure Storage, Inc. Secret sharing data protection in a storage system
US8745415B2 (en) * 2012-09-26 2014-06-03 Pure Storage, Inc. Multi-drive cooperation to generate an encryption key
CN103248476B (en) * 2013-05-02 2016-10-26 华为数字技术(苏州)有限公司 The management method of data encryption key, system and terminal
US9094377B2 (en) * 2013-08-16 2015-07-28 Netflix, Inc. Key generation and broadcasting
US10263770B2 (en) 2013-11-06 2019-04-16 Pure Storage, Inc. Data protection in a storage system using external secrets
US11128448B1 (en) 2013-11-06 2021-09-21 Pure Storage, Inc. Quorum-aware secret sharing
US9516016B2 (en) 2013-11-11 2016-12-06 Pure Storage, Inc. Storage array password management
US10275396B1 (en) * 2014-09-23 2019-04-30 Symantec Corporation Techniques for data classification based on sensitive data
US10694352B2 (en) 2015-10-28 2020-06-23 Activision Publishing, Inc. System and method of using physical objects to control software access
CN106453966B (en) * 2016-12-05 2020-01-17 北京奇虎科技有限公司 Interaction prompting method and device between mobile communication devices
US10693639B2 (en) * 2017-02-28 2020-06-23 Blackberry Limited Recovering a key in a secure manner
JP7321481B2 (en) * 2017-07-03 2023-08-07 株式会社 エヌティーアイ First communication device, second communication device, method, computer program
US11374760B2 (en) 2017-09-13 2022-06-28 Microsoft Technology Licensing, Llc Cyber physical key
US10546276B2 (en) * 2017-09-13 2020-01-28 Microsoft Technology Licensing, Llc Cyber ownership transfer
CN108242999B (en) * 2017-10-26 2021-04-16 招商银行股份有限公司 Key escrow method, device and computer-readable storage medium
JP2022549671A (en) * 2019-09-25 2022-11-28 コモンウェルス サイエンティフィック アンド インダストリアル リサーチ オーガナイゼーション Cryptographic services for browser applications
US11606206B2 (en) * 2020-01-09 2023-03-14 Western Digital Technologies, Inc. Recovery key for unlocking a data storage device

Family Cites Families (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4200770A (en) * 1977-09-06 1980-04-29 Stanford University Cryptographic apparatus and method
US4405829A (en) * 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
US4386233A (en) * 1980-09-29 1983-05-31 Smid Miles E Crytographic key notarization methods and apparatus
NL8301458A (en) * 1983-04-26 1984-11-16 Philips Nv METHOD FOR DISTRIBUTING AND USING ENCRYPTION KEYS.
US4590470A (en) * 1983-07-11 1986-05-20 At&T Bell Laboratories User authentication system employing encryption functions
US4926480A (en) * 1983-08-22 1990-05-15 David Chaum Card-computer moderated systems
US4947430A (en) * 1987-11-23 1990-08-07 David Chaum Undeniable signature systems
FR2618002B1 (en) * 1987-07-10 1991-07-05 Schlumberger Ind Sa METHOD AND SYSTEM FOR AUTHENTICATING ELECTRONIC MEMORY CARDS
US4868877A (en) * 1988-02-12 1989-09-19 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5005200A (en) * 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5214702A (en) * 1988-02-12 1993-05-25 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5313637A (en) * 1988-11-29 1994-05-17 Rose David K Method and apparatus for validating authorization to access information in an information processing system
US5191611A (en) * 1989-04-03 1993-03-02 Lang Gerald S Method and apparatus for protecting material on storage media and for transferring material on storage media to various recipients
US4996711A (en) * 1989-06-21 1991-02-26 Chaum David L Selected-exponent signature systems
GB8927623D0 (en) * 1989-12-06 1990-02-07 Bicc Plc Repeaters for secure local area networks
DE68925695D1 (en) * 1989-12-13 1996-03-28 Ibm Computer system security device
EP0439847B1 (en) * 1990-01-29 1997-10-22 Security Technology Corporation Optionally moderated transaction systems
US5163091A (en) * 1990-01-29 1992-11-10 Graziano James M Knowledge based system for document authentication (apparatus)
US5263157A (en) * 1990-02-15 1993-11-16 International Business Machines Corporation Method and system for providing user access control within a distributed data processing system by the exchange of access control profiles
JP3080382B2 (en) * 1990-02-21 2000-08-28 株式会社日立製作所 Cryptographic communication system
US5226080A (en) * 1990-06-22 1993-07-06 Grid Systems Corporation Method and apparatus for password protection of a computer
US5224163A (en) * 1990-09-28 1993-06-29 Digital Equipment Corporation Method for delegating authorization from one entity to another through the use of session encryption keys
FR2671205B1 (en) * 1990-12-27 1995-01-20 Telemecanique METHOD FOR CONTROLLING THE USE OF A COMPUTER WORKSTATION BY PASSWORD AND COMPUTER WORKSTATION USING THE SAME.
JPH06102822A (en) * 1991-09-26 1994-04-15 Rooreru Intelligent Syst:Kk File security system
US5200999A (en) * 1991-09-27 1993-04-06 International Business Machines Corporation Public key cryptosystem key management based on control vectors
US5265164A (en) * 1991-10-31 1993-11-23 International Business Machines Corporation Cryptographic facility environment backup/restore and replication in a public key cryptosystem
US5276901A (en) * 1991-12-16 1994-01-04 International Business Machines Corporation System for controlling group access to objects using group access control folder and group identification as individual user
US5210795A (en) * 1992-01-10 1993-05-11 Digital Equipment Corporation Secure user authentication from personal computer
GB9205774D0 (en) * 1992-03-17 1992-04-29 Int Computers Ltd Computer security system
US5280527A (en) * 1992-04-14 1994-01-18 Kamahira Safe Co., Inc. Biometric token for authorizing access to a host system
US5313521A (en) * 1992-04-15 1994-05-17 Fujitsu Limited Key distribution protocol for file transfer in the local area network
WO1993021708A1 (en) * 1992-04-20 1993-10-28 Silvio Micali Verifying secret keys in a public-key cryptosystem
US5276737B1 (en) * 1992-04-20 1995-09-12 Silvio Micali Fair cryptosystems and methods of use
US5315658B1 (en) * 1992-04-20 1995-09-12 Silvio Micali Fair cryptosystems and methods of use
US5341426A (en) * 1992-12-15 1994-08-23 Motorola, Inc. Cryptographic key management apparatus and method
US5351293A (en) * 1993-02-01 1994-09-27 Wave Systems Corp. System method and apparatus for authenticating an encrypted signal
US5299263A (en) * 1993-03-04 1994-03-29 Bell Communications Research, Inc. Two-way public key authentication and key agreement for low-cost terminals
US5436972A (en) * 1993-10-04 1995-07-25 Fischer; Addison M. Method for preventing inadvertent betrayal by a trustee of escrowed digital secrets
US5371794A (en) * 1993-11-02 1994-12-06 Sun Microsystems, Inc. Method and apparatus for privacy and authentication in wireless networks
US5481613A (en) * 1994-04-15 1996-01-02 Northern Telecom Limited Computer network cryptographic key distribution system
US5557346A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for key escrow encryption
US5557765A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for data recovery
US5564106A (en) * 1995-03-09 1996-10-08 Motorola, Inc. Method for providing blind access to an encryption key

Also Published As

Publication number Publication date
US5745573A (en) 1998-04-28
JPH10508438A (en) 1998-08-18
AU3321795A (en) 1996-03-07
MX9700980A (en) 1998-05-31
US5991406A (en) 1999-11-23
BR9508548A (en) 1998-11-03
US5557765A (en) 1996-09-17
CN1158195A (en) 1997-08-27
EP0775401A1 (en) 1997-05-28
WO1996005673A1 (en) 1996-02-22

Similar Documents

Publication Publication Date Title
US5991406A (en) System and method for data recovery
US5956403A (en) System and method for access field verification
US7783887B2 (en) Method and apparatus for providing television services using an authenticating television receiver device
US6002772A (en) Data management system
US7362868B2 (en) Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
JP3656688B2 (en) Cryptographic data recovery method and key registration system
US6741991B2 (en) Data management system
US6334118B1 (en) Software rental system and method for renting software
US20090193249A1 (en) Privacy-preserving information distribution system
US20080310619A1 (en) Process of Encryption and Operational Control of Tagged Data Elements
US20060282674A1 (en) Data management system
CN105740725A (en) File protection method and system
US20030229782A1 (en) Method for computer identification verification
KR100286904B1 (en) System and method for security management on distributed PC
Johnson et al. A secure distributed capability based system
US10402573B1 (en) Breach resistant data storage system and method
Balenson et al. A new approach to software key escrow encryption
CN110445756B (en) Method for realizing searchable encryption audit logs in cloud storage
Said et al. A multi-factor authentication-based framework for identity management in cloud applications
KR20030097550A (en) Authorization Key Escrow Service System and Method
US20040093310A1 (en) Transaction system and method
AU2021101878A4 (en) Computerized design model for encryption in blockchain transaction systems
Iftekhar et al. Implementation of blockchain for secured criminal records
Nazarko et al. OVERVIEW OF DATABASE INFORMATION PROTECTION APPROACHES IN MODERN DATABASE MANAGEMENT SYSTEMS
Rantos Key recovery in a business environment

Legal Events

Date Code Title Description
FZDE Discontinued