Here is my first cut at what I plan to say. Not real exciting, but I don't know how much knowledge to assume in the audience. I would be grateful for a pointer to any commercial key escrow services that are actually in operation today. And doubly grateful for a pointer to one that does not rely on a proprietary encryption scheme and/or one that allows/requires key splitting for extra security. Key Escrow in Secure Electronic Commerce October 19, 1995 4:30 pm - 5:50 pm Outline Intro: In this talk I will... * Begin with why business wants/needs *data* CKE * Turn then to law enforcement focus on communications KE * Explain how govt hardball on export control in pursuit of Comm KE threatens needed CKE -- or at least US companies' share of that market... * Discuss pending issues I. Commercial key escrow, the WHAT, WHY, WHO and HOW A. WHAT Give someone (internal/external) copies of keys (private/ symmetric) used in the course of business 1. Essential (from corporate perspective) for a. all encrypted, stored corporate data b. keys with power (1) to sign things in corporate name e.g. buy/sell (2) to issue certificates 2. Less essential (from corporate perspective) a. for email keys but still pretty important if you might have to reconstruct exchanges of messages at a later date. b. for telephone keys although useful if you think there will be need for you and/or police to spy on your employees, eg. investigate fraud/theft. B. WHY 1. Irresponsible for corporation not to encrypt data and some communications if these are of commercial value to competitors/otherwise sensitive 2. Irresponsible to encrypt data (and maybe also communications) and not have fail-safe means of access a. employees lose their keys b. employees die c. employees quit (and vanish or do some vandalism) d. employees are suspected of engaging in hanky- panky C. WHO Escrow agent could be 1. internal a. only viable solution right now unless you are satisfied with, e.g., RSA non-interoperable crypto system b. but are you hacker-proof? 2. external, e.g. a. TIS licensed "Data Recovery Center" (but there are none in existence today) b. bankerstrust c. govt agency (someday? but not today) d. can use split key systems for increased security. [but is anyone actually offering such a service?] One problem with external is that NONE of the liability issues are resolved. E.G. Suppose private escrow agent complies in good faith with facially valid warrant, but warrant is l D. HOW Here we have more doubts than knowledge Not clear yet what security precautions commercial escrow agents will offer. Can assume: 1. Secure systems 2. Contract-driven mechanism for verifying IDs/bona fides of persons attempting to take out data 3. Contract-driven assurances of speed of response 4. split key systems with different escrow agents? II. Legal implications of commercial key escrow Three families of issues: 1. data owner liability for not escrowing 2. escrow agent liability for errors 3. Government access to keys A. It is irresponsible NOT to escrow keys if you encrypt data. And it is increasingly irresponsible not to encrypt. Hence some form of escrow will become practically mandatory. 1. Query: won't this make it easier for the government to get access to my data? Answer: must distinguish between stored data and communications. You are escrowing the keys not the data itself. The data remains secure in your own machine/tape/safe/whatever. There it's subject to subpoena just like paper records. So encryption + escrow is no substitute for destroying the smoking gun, but it's also no more danger than ordinary records. Escrowing keys used for communication makes those communications more vulnerable to government interceptions. Strong, unescrowed, keys may defeat even a lawful subpoena for a wiretap. Escrowed keys are vulnerable to legal (at least) wiretaps. 2. More on "practically mandatory": The government may make it a condition of doing certain kinds of business, e.g. govt contracting, that only escrowed encryption be used. Similarly, the government may be willing to engage in secure communications with the public, but only via system that are limited to escrowed keys. 3. Still more on "practically mandatory": carrot & stick of export controls (see below). B. Escrow agent liability for errors Currently, rights and resp of customer vs. escrow agents depend on whether escrow agent is public or private 1. Public escrow agent -- low accountability? In the "Clipper 1" proposals, the escrow system lacked any legal guarantees for the people whose keys are generated by the government and held by the escrow agents. Indeed, the Attorney General's escrow procedures stated that they þdo not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance.þ In short, the government disclaimed in advance any reliance interest that a user of an EES-equipped device might have in the government's promise to keep the key secret. A victim of an illegal wiretap would have a cause of action under Title III against the wiretapper, but, it appears, no remedy against the escrow agents, even if the escrow agents acted negligently or failed to follow their own procedures. The Attorney General's procedures themselves are merely directives. They are not even legislative rules, which might be subject to notice and comment restrictions before being rescinded. A future administration could, if it wanted, secretly instruct the escrow agents to deliver copies of the keys to an intelligence or law enforcement agency, or even White House þplumbers,þ thereby violating no law or regulation (the plumbers, though, would violate Title III when they used the information). Because the chip-unique keys were voluntarily disclosed to the government, the chip's owner might lack a þlegitimateþ (that is, enforceable) expectation of privacy in the information. If the intercepted communication were an e-mail or a file transfer, rather than a telephone call, the chip owner subject to an illegal or inadvertent disclosure by the escrow agents may be in a particularly weak position if the information ever makes its way to court: many Title III protections granted to voice communications do not apply to transfers of digitized data. Shortly before the 103d Congress adjourned, Congressman George Brown introduced the Encryption Standards and Procedures Act of 1994, which would have waived the sovereign immunity of the United States for þwillfulþ but unauthorized disclosures of key fragments by its officialsþand excluded liability in all other circumstances. In the absence of similar legislation, however, there may currently be no monetary remedy even for a þwillfulþ disclosure. 2. Private escrow agent -- contract accountability, tort, maybe bailee/trustee (dubious) If you want software key escrow today, you have to be your own escrow agent, or go to a private escrow agent because there is no government agency ready and able to act in this capacity (and few private bodies!) Given current liability rules, you would be better off with a private body than the government anyway (tradeoff: maybe more security in government agency (?) vs. more recourse against private party). The "son of clipper" trial balloon floated this fall suggested that export permission would be given to (relatively) strong (ie. 64 bit max) software cryptosystems, if those systems were designed to ensure that the keys were escrowed with an "approved escrow agent". NIST solicited comments in Sept. '95 as to a. what sort of bodies would be suitable, and b. what terms and conditions should govern the escrow agents. c. What procedures need to be developed for the storage and safeguarding of keys? d. Performance criteria (e.g., around-the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? e. Under what circumstances will key escrow agents in foreign countries be approved? f. Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? [The last point is potentially ominous...if access to digital signature infrastructure is conditions on using KE, then this makes export control hardball look like small beer] To date there has been no public feedback from NIST subsequent to the meeting except that they are revising the criteria in light of what they heard. [Can GG tell us more?] C. Government access to keys NB that government seems primarily interested in communications; business main focus is/should be DATA. Now with "Son of Clipper" (software KE), the government has relaxed the suggestion that keys be generated and escrowed via hardware (e.g. Fortezza), but has substituted onerous criteria it hopes it can persuade (threaten?) industry to apply to software, including: III. (Mostly specious) Arguments Against Commercial Key Escrow [with apologies to Marc Rotenberg, Electronic Privacy Information Center, who posted the quoted material to USENET several months ago] A. Bad for business 1. "Increased network vulnerability. The key escrow configuration necessarily increases the likelihood of communications compromise and improper interception by third parties. Computer crime will skyrocket." Very unrealistic and alarmist. While as a theoretical matter it is clearly true that the sharing the keys with the escrow agent must create an avenue of attack that did not exist before, the risk can be very greatly reduced by a. key splitting (never send the whole key to anyone at any time) b. secure communications with very secure algorithms between escrow agent and customer [NB that US government export policy implicates this to the extent it makes strong crypto non-exportable] 2. "Policy incoherence. The key management needs of business differ sharply from the real-time intercept plans of law enforcement. The latter has little to do with the former." Probably true, but irrelevant to the matter at hand: business needs escrowing for its own disaster recovery needs. 3. "Complexity. Has anyone really given thought to how many communications will be encrypted in 20 years and what the key management requirements will be to develop a unitary key escrow system to satisfy the government's concerns?" Maybe, maybe not. But businesses need CKE now. Keys don't live for ever, and a sound security plan will include provisions for retiring keys as they age. Age makes keys vulnerable a. technological change makes bruting longer keys possible b. the longer the key is out there the more time attackers have to brute (or otherwise compromise) the key B. Bad for civil liberties 1. "Emergency circumstances taps. The current wiretap law permits the initiation of a wiretap *without court order* upon a certification that emergency circumstances exist. If this procedure is built into the CKE procedure, then there will be *no judicial review* prior to the disclosure of keys." True. But these taps are currently rare, and limited to cases like kidnapping where lives are at stake. It's fairly unlikely that a business will ever encounter one of these. 2. "The future of PGP. Will PGP and other non-escrow schemes be permitted if CKE is adopted? What will be the implications for developers and companies in the communications industry?" Voluntary CKE in and of itself is not going to affect the legality of alternative un-escrowed crypto. The politics are hard to predict: one can imagine arguments that mandatory escrow is not needed because it's being done voluntarily; and also arguments that the increasing voluntary CKE means that there's less reason not to make it mandatory. My guess: no great effect one way or the other. The issue will be settled by larger things e.g. what's more scary -- Oklahoma City or Ruby Ridge? IV. Recent Developments in key escrow A. NIST initiatives NIST is currently putting "final touches" on draft export criteria, under auspices of inter-agency working group. NIST hopes to "notice" revised draft criteria in fed register, perhaps within the next month; then a 60day comment period, with a 1-day live meeting in DC sometime during the comment period. When NIST has final version of inter-agency recommendations set, they will be turned over to the state dept to implement; state can do what it likes. One possible model for State Dept. action is a change to the ITAR. V. Outstanding Issues A. Why would any foreign company use US govt approved crypto in light of new focus on economic intelligence, e.g. Japan spy case? Possible govt responses: 1. foreign govt might have copy of key? share key? 2. foreign-based, but US-approved, escrow agent might hold/share key B. MANDATORY CKE? 1. Legislation? 2. "milder variants" a. export control club (is 64 bits enough?) b. data vs. communications issue c. Digital signature infrastructure access club (informal talks suggest this is not likely, but not formally ruled out....) C. Enabling ("technical") legislation 1. Title III exemption for escrow agent 2. Authority to "certify" escrow agents 3. liability rules for escrow agents D. Enabling regulations 1. Care & feeding of escrow agents, a. eg. sample criteria for being approved and/or sample contract between government and escrow agent b. performance criteria for escrow agents e.g. response time E. Liability in the absence of legislation 1. First, find someone actually selling escrow services with an interoperable product. 2. Or, resign yourself to eg RSA keys. A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin@law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's hot here. And humid.