home *** CD-ROM | disk | FTP | other *** search
/ Cuteskunk BBS / cuteskunk.zip / cuteskunk / Unix-Hacking-Documents / key_study.txt < prev    next >
Text File  |  2003-06-29  |  65KB  |  1,240 lines

  1.                 The Risks of Key Recovery, Key Escrow,
  2.                   and Trusted Third-Party Encryption
  3.  
  4.                             Hal Abelson [1]
  5.                            Ross Anderson [2]
  6.                          Steven M. Bellovin [3]
  7.                             Josh Benaloh [4]
  8.                              Matt Blaze [5]
  9.                           Whitfield Diffie [6]
  10.                             John Gilmore [7]
  11.                           Peter G. Neumann [8]
  12.                           Ronald L. Rivest [9]
  13.                         Jeffrey I. Schiller [10]
  14.                           Bruce Schneier [11]
  15.  
  16.                      Final Report -- 27 May 1997 [12]
  17.  
  18.  
  19. Abstract:
  20.  
  21. A variety of ``key recovery,'' ``key escrow,'' and ``trusted
  22. third-party'' encryption requirements have been suggested in recent
  23. years by government agencies seeking to conduct covert surveillance
  24. within the changing environments brought about by new technologies.
  25. This report examines the fundamental properties of these requirements
  26. and attempts to outline the technical risks, costs, and implications
  27. of deploying systems that provide government access to encryption keys.
  28.  
  29.  
  30. Contents
  31.  
  32.    * Executive Summary
  33.    * Group Charter
  34.    * 1 Background
  35.         o 1.1 Encryption and the Global Information Infrastructure
  36.         o 1.2 ``Key Recovery'': Requirements and Proposals
  37.    * 2 Key Recoverability: Government vs. End-User Requirements
  38.         o 2.1 Communication Traffic vs. Stored Data
  39.         o 2.2 Authentication vs. Confidentiality Keys
  40.         o 2.3 Infrastructure: Local vs. Third-Party Control
  41.         o 2.4 Infrastructure: Key Certification and Distribution vs.
  42.           Key Recovery
  43.    * 3 Risks and Costs of Key Recovery
  44.         o 3.1 New Vulnerabilities and Risks
  45.              + 3.1.1 New Paths to Plaintext
  46.              + 3.1.2 Insider Abuse
  47.              + 3.1.3 New Targets for Attack
  48.              + 3.1.4 Forward Secrecy
  49.         o 3.2 New Complexities
  50.              + 3.2.1 Scale
  51.              + 3.2.2 Operational Complexity
  52.              + 3.2.3 Authorization for Key Recovery
  53.         o 3.3 New Costs
  54.              + 3.3.1 Operational Costs
  55.              + 3.3.2 Product Design Costs
  56.              + 3.3.3 End-User Costs
  57.         o 3.4 Tradeoffs
  58.              + 3.4.1 Key Recovery Granularity and Scope
  59.    * 4 Conclusions
  60.    * The Authors
  61.    * Notes
  62.  
  63.  
  64. Executive Summary
  65.  
  66. A variety of ``key recovery,'' ``key escrow,'' and ``trusted
  67. third-party'' encryption requirements have been suggested in recent
  68. years by government agencies seeking to conduct covert surveillance
  69. within the changing environments brought about by new technologies.
  70. This report examines the fundamental properties of these requirements
  71. and attempts to outline the technical risks, costs, and implications
  72. of deploying systems that provide government access to encryption keys.
  73.  
  74. The deployment of key-recovery-based encryption infrastructures to
  75. meet law enforcement's stated specifications will result in
  76. substantial sacrifices in security and greatly increased costs to the
  77. end-user. Building the secure computer-communication infrastructures
  78. necessary to provide adequate technological underpinnings demanded by
  79. these requirements would be enormously complex and is far beyond the
  80. experience and current competency of the field. Even if such
  81. infrastructures could be built, the risks and costs of such an
  82. operating environment may ultimately prove unacceptable. In addition,
  83. these infrastructures would generally require extraordinary levels of
  84. human trustworthiness.
  85.  
  86. These difficulties are a function of the basic government access
  87. requirements proposed for key-recovery encryption systems. They exist
  88. regardless of the design of the recovery systems - whether the systems
  89. use private-key cryptography or public-key cryptography; whether the
  90. databases are split with secret-sharing techniques or maintained in a
  91. single hardened secure facility; whether the recovery services provide
  92. private keys, session keys, or merely decrypt specific data as needed;
  93. and whether there is a single centralized infrastructure, many
  94. decentralized infrastructures, or a collection of different
  95. approaches.
  96.  
  97. All key-recovery systems require the existence of a highly sensitive
  98. and highly-available secret key or collection of keys that must be
  99. maintained in a secure manner over an extended time period. These
  100. systems must make decryption information quickly accessible to law
  101. enforcement agencies without notice to the key owners. These basic
  102. requirements make the problem of general key recovery difficult and
  103. expensive - and potentially too insecure and too costly for many
  104. applications and many users.
  105.  
  106. Attempts to force the widespread adoption of key-recovery encryption
  107. through export controls, import or domestic use regulations, or
  108. international standards should be considered in light of these
  109. factors. The public must carefully consider the costs and benefits of
  110. embracing government-access key recovery before imposing the new
  111. security risks and spending the huge investment required (potentially
  112. many billions of dollars, in direct and indirect costs) to deploy a
  113. global key recovery infrastructure.
  114.  
  115.  
  116. Group Charter
  117.  
  118. This report stems from a collaborative effort to study the technical
  119. implications of controversial proposals by the United States and other
  120. national governments to deploy large-scale ``key recovery'' systems
  121. that provide third-party access to decryption keys[13]. Insofar as is
  122. possible, we have considered the impact of these policies without
  123. regard to individual encryption schemes or particular government
  124. proposals. Rather, we have attempted to look broadly at the essential
  125. elements of key recovery needed to fulfill the expressed requirements
  126. of governments (as distinct from the features that encryption users
  127. might desire). This report considers the general impact of meeting the
  128. government's requirements rather than the merits of any particular key
  129. recovery system or proposal that meets them. Our analysis is
  130. independent of whether the key-recovery infrastructure is centralized
  131. or widely distributed.
  132.  
  133. We have specifically chosen not to endorse, condemn, or draw
  134. conclusions about any particular regulatory or legislative proposal or
  135. commercial product. Rather, it is our hope that our findings will shed
  136. further light on the debate over key recovery and provide a
  137. long-needed baseline analysis of the costs of key recovery as
  138. policymakers consider embracing one of the most ambitious and
  139. far-reaching technical deployments of the information age.
  140.  
  141. Although there are many aspects to the debate on the proper role of
  142. encryption and key recovery in a free society, we have chosen to focus
  143. entirely on the technical issues associated with this problem rather
  144. than on more general political or social questions. Indeed, many have
  145. suggested that the very notion of a pervasive government key recovery
  146. infrastructure runs counter to the basic principles of freedom and
  147. privacy in a democracy and that that alone is reason enough to avoid
  148. deploying such systems. This reasoning is independent of whether the
  149. key-recovery infrastructure is centralized or widely distributed. The
  150. technical nature of our analysis should not be interpreted as an
  151. endorsement of the social merits of government key recovery; in fact,
  152. we encourage vigorous public debate on this question.
  153.  
  154.  
  155. 1 Background
  156.  
  157. 1.1 Encryption and the Global Information Infrastructure
  158.  
  159. The Global Information Infrastructure promises to revolutionize
  160. electronic commerce, reinvigorate government, and provide new and open
  161. access to the information society. Yet this promise cannot be achieved
  162. without information security and privacy. Without a secure and trusted
  163. infrastructure, companies and individuals will become increasingly
  164. reluctant to move their private business or personal information
  165. online.
  166.  
  167. The need for information security is widespread and touches all of us,
  168. whether users of information technology or not. Sensitive information
  169. of all kinds is increasingly finding its way into electronic form.
  170. Examples include:
  171.  
  172.    * Private personal and business communications, including telephone
  173.      conversations, FAX messages, and electronic mail;
  174.    * Electronic funds transfers and other financial transactions;
  175.    * Sensitive business information and trade secrets;
  176.    * Data used in the operation of critical infrastructure systems
  177.      such as air traffic control, the telephone network, or the power
  178.      grid; and
  179.    * Health records, personnel files, and other personal information.
  180.  
  181. Electronically managed information touches almost every aspect of
  182. daily life in modern society. This rising tide of important yet
  183. unsecured electronic data leaves our society increasingly vulnerable
  184. to curious neighbors, industrial spies, rogue nations, organized
  185. crime, and terrorist organizations.
  186.  
  187. Paradoxically, although the technology for managing and communicating
  188. electronic information is improving at a remarkable rate, this
  189. progress generally comes at the expense of intrinsic security. In
  190. general, as information technology improves and becomes faster,
  191. cheaper, and easier to use, it becomes less possible to control (or
  192. even identify) where sensitive data flows, where documents originated,
  193. or who is at the other end of the telephone. The basic communication
  194. infrastructure of our society is becoming less secure, even as we use
  195. it for increasingly vital purposes. Cryptographic techniques more and
  196. more frequently will become the only viable approach to assuring the
  197. privacy and safety of sensitive information as these trends continue.
  198.  
  199. Encryption is an essential tool in providing security in the
  200. information age. Encryption is based on the use of mathematical
  201. procedures to scramble data so that it is extremely difficult - if not
  202. virtually impossible - for anyone other than authorized recipients to
  203. recover the original ``plaintext.'' Properly implemented encryption
  204. allows sensitive information to be stored on insecure computers or
  205. transmitted across insecure networks. Only parties with the correct
  206. decryption ``key'' (or keys) are able to recover the plaintext
  207. information.
  208.  
  209. Highly secure encryption can be deployed relatively cheaply, and it is
  210. widely believed that encryption will be broadly adopted and embedded
  211. in most electronic communications products and applications for
  212. handling potentially valuable data.[14] Applications of cryptography
  213. include protecting files from theft or unauthorized access, securing
  214. communications from interception, and enabling secure business
  215. transactions. Other cryptographic techniques can be used to guarantee
  216. that the contents of a file or message have not been altered
  217. (integrity), to establish the identity of a party (authentication), or
  218. to make legal commitments (non-repudiation).
  219.  
  220. In making information secure from unwanted eavesdropping,
  221. interception, and theft, strong encryption has an ancillary effect: it
  222. becomes more difficult for law enforcement to conduct certain kinds of
  223. surreptitious electronic surveillance (particularly wiretapping)
  224. against suspected criminals without the knowledge and assistance of
  225. the target. This difficulty is at the core of the debate over key
  226. recovery.
  227.  
  228.  
  229. 1.2 ``Key Recovery'': Requirements and Proposals
  230.  
  231. The United States and other national governments have sought to
  232. prevent widespread use of cryptography unless ``key recovery''
  233. mechanisms guaranteeing law enforcement access to plaintext are built
  234. into these systems. The requirements imposed by such government-driven
  235. key recovery systems are different from the features sought by
  236. encryption users, and ultimately impose substantial new risks and
  237. costs.
  238.  
  239. Key recovery encryption systems provide some form of access to
  240. plaintext outside of the normal channel of encryption and decryption.
  241. Key recovery is sometimes also called ``key escrow.'' The term
  242. ``escrow'' became popular in connection with the U.S. government's
  243. Clipper Chip initiative, in which a master key to each encryption
  244. device was held ``in escrow'' for release to law enforcement. Today
  245. the term ``key recovery'' is used as generic term for these systems,
  246. encompassing the various ``key escrow,'' ``trusted third-party,''
  247. ``exceptional access,'' ``data recovery,'' and ``key recovery''
  248. encryption systems introduced in recent years. Although there are
  249. differences between these systems, the distinctions are not critical
  250. for our purposes. In this report, the general term ``key recovery'' is
  251. used in a broad sense, to refer to any system for assuring third-party
  252. (government) access to encrypted data.
  253.  
  254. Key recovery encryption systems work in a variety of ways. Early ``key
  255. escrow'' proposals relied on the storage of private keys by the U.S.
  256. government, and more recently by designated private entities. Other
  257. systems have ``escrow agents'' or ``key recovery agents'' that
  258. maintain the ability to recover the keys for a particular encrypted
  259. communication session or stored file; these systems require that such
  260. ``session keys'' be encrypted with a key known by a recovery agent and
  261. included with the data. Some systems split the ability to recover keys
  262. among several agents.
  263.  
  264. Many interested parties have sought to draw sharp distinctions among
  265. the various key recovery proposals. It is certainly true that several
  266. new key recovery systems have emerged that can be distinguished from
  267. the original ``Clipper'' proposal by their methods of storing and
  268. recovering keys. However, our discussion takes a higher-level view of
  269. the basic requirements of the problem rather than the details of any
  270. particular scheme; it does not require a distinction between ``key
  271. escrow,'' ``trusted third-party,'' and ``key recovery''. All these
  272. systems share the essential elements that concern us for the purposes
  273. of this study:
  274.  
  275.    * A mechanism, external to the primary means of encryption and
  276.      decryption, by which a third party can obtain covert access to
  277.      the plaintext of encrypted data.
  278.    * The existence of a highly sensitive secret key (or collection of
  279.      keys) that must be secured for an extended period of time.
  280.  
  281. Taken together, these elements encompass a system of ``ubiquitous key
  282. recovery'' designed to meet law enforcement specifications. While some
  283. specific details may change, the basic requirements most likely will
  284. not: they are the essential requirements for any system that meets the
  285. stated objective of guaranteeing law enforcement agencies timely
  286. access, without user notice, to the plaintext of encrypted
  287. communications traffic.
  288.  
  289.  
  290. 2 Key Recoverability: Government vs. End-User Requirements
  291.  
  292. Key recovery systems have gained currency due to the desire of
  293. government intelligence and law enforcement agencies to guarantee that
  294. they have access to encrypted information without the knowledge or
  295. consent of encryption users. A properly designed cryptosystem makes it
  296. essentially impossible to recover encrypted data without knowledge of
  297. the correct key. In some cases this creates a potential problem for
  298. the users of encryption themselves; the cost of keeping unauthorized
  299. parties out is that if keys are lost or unavailable at the time they
  300. are needed, the owners of the encrypted data will be unable to make
  301. use of their own information. It has been suggested, therefore, that
  302. industry needs and wants key recovery, and that the kind of key
  303. recovery infrastructure promoted by the government would serve the
  304. commercial world's needs for assuring availability of its own
  305. encrypted data. Several recent government proposals (along with
  306. commercial products and services designed to meet the government's
  307. requirements) have been promoted as serving the dual role of assuring
  308. government access as well as ``owner'' access to encrypted data.
  309. However, the requirements of a government and the requirements of the
  310. commercial world and individual users are very different in this
  311. regard, so different that, in fact, there is little overlap between
  312. systems that address these two problems.
  313.  
  314. The ultimate goal of government-driven key recovery encryption, as
  315. stated in the U.S. Department of Commerce's recent encryption
  316. regulations, ``envisions a worldwide key management infrastructure
  317. with the use of key escrow and key recovery encryption items.''[15]
  318. The requirements put forward to meet law enforcement demands for such
  319. global key recovery systems include:
  320.  
  321.    * Third-party/government access without notice to or consent of the
  322.      user. Even so-called ``self-escrow'' systems, where companies
  323.      might hold their own keys, are required to provide sufficient
  324.      insulation between the recovery agents and the key owners to
  325.      avoid revealing when decryption information has been released.
  326.    * Ubiquitous international adoption of key recovery. Key recovery
  327.      helps law enforcement only if it is so widespread that it is used
  328.      for the bulk of encrypted stored information and communications,
  329.      whether or not there is end-user demand for a recovery feature.
  330.    * High-availability, around-the-clock access to plaintext under a
  331.      variety of operational conditions. Law enforcement seeks the
  332.      ability to obtain decryption keys quickly - within two hours
  333.      under current U.S. and other proposed regulations.[16] Few
  334.      commercial encryption users need the ability to recover lost keys
  335.      around the clock, or on such short notice.
  336.    * Access to encrypted communications traffic as well as to
  337.      encrypted stored data. To the extent that there is commercial
  338.      demand for key recovery, it is limited to stored data rather than
  339.      communications traffic.
  340.  
  341. In fact, the requirements of government key recovery are almost
  342. completely incompatible with those of commercial encryption users. The
  343. differences are especially acute in four areas: the kinds of data for
  344. which recovery is required, the kinds of keys for which recovery is
  345. required, the manner in which recoverable keys are managed, and the
  346. relationship between key certification and key recovery. Government
  347. key recovery does not serve private and business users especially
  348. well; similarly, the key management and key recoverability systems
  349. naturally arising in the commercial world do not adapt well to serve a
  350. government.
  351.  
  352.  
  353. 2.1 Communication Traffic vs. Stored Data
  354.  
  355. While key ``recoverability'' is a potentially important added-value
  356. feature in certain stored data systems, in other applications of
  357. cryptography there is little or no user demand for this feature. In
  358. particular, there is hardly ever a reason for an encryption user to
  359. want to recover the key used to protect a communication session such
  360. as a telephone call, FAX transmission, or Internet link. If such a key
  361. is lost, corrupted, or otherwise becomes unavailable, the problem can
  362. be detected immediately and a new key negotiated. There is also no
  363. reason to trust another party with such a key. Key recoverability, to
  364. the extent it has a private-sector application at all, is useful only
  365. for the keys used to protect irreproducible stored data. There is
  366. basically no business model for other uses, as discussed below.
  367.  
  368. In stored data applications, key recovery is only one of a number of
  369. options for assuring the continued availability of business-critical
  370. information. These options include sharing the knowledge of keys among
  371. several individuals (possibly using secret-sharing techniques),
  372. obtaining keys from a local key registry that maintains backup copies,
  373. careful backup management of the plaintext of stored encrypted data,
  374. or, of course, some kind of key recovery mechanism. The best option
  375. among these choices depends on the particular application and user.
  376.  
  377. Encrypted electronic mail is an interesting special case, in that it
  378. has the characteristics of both communication and storage. Whether key
  379. recovery is useful to the user of a secure E-mail system depends on
  380. design of the particular system.
  381.  
  382. The government, on the other hand, proposes a key recovery
  383. infrastructure that applies to virtually all cryptographic keys,
  384. including (especially) those used to protect communications sessions.
  385.  
  386.  
  387. 2.2 Authentication vs. Confidentiality Keys
  388.  
  389. Although cryptography has traditionally been associated with
  390. confidentiality, other cryptographic mechanisms, such as
  391. authentication codes and digital signatures, can ensure that messages
  392. have not been tampered with or forged. Some systems provide properties
  393. analogous to those of handwritten signatures, including
  394. ``non-repudiation'' - the recipient can prove to a third party that a
  395. message was signed by a particular individual.
  396.  
  397. Much of the promise of electronic commerce depends on the ability to
  398. use cryptographic techniques to make binding commitments. Yet some key
  399. recovery schemes are designed to archive authentication and signature
  400. keys along with confidentiality keys. Such schemes destroy the
  401. absolute non-repudiation property that makes binding commitments
  402. possible. Furthermore, there are simply no legitimate uses for
  403. authentication or signature key recovery. The private sector requires
  404. distinct keys for all signers, even when two or more individuals are
  405. authorized to send a given message; without that, the ability to audit
  406. transactions is destroyed. Government surveillance does not require
  407. the recovery of signature keys, either.
  408.  
  409. However, it is difficult to exclude authentication and signature keys
  410. from a key recovery infrastructure of the kind proposed by the
  411. government, because some keys are used for both signature and
  412. encryption.[17] Nor is it sufficient to exclude from the recovery
  413. system keys used only to protect financial transactions, since many
  414. electronic commerce schemes use keys that are general in scope. The
  415. same key might be used, for example, to encrypt personal electronic
  416. mail as well as to electronically sign contracts or authorize funds
  417. transfers.
  418.  
  419. It has been claimed that non-availability of a signature key can be a
  420. serious problem for the owner, who will then no longer be able to sign
  421. messages. But common practice allows for the revocation of lost keys,
  422. and the issuance of new keys with the same rights and privileges as
  423. the old ones. Recovering lost signature and authentication keys is
  424. simply never required.
  425.  
  426.  
  427. 2.3 Infrastructure: Local vs. Third-Party Control
  428.  
  429. For a key recovery scheme to be of value to the encryption user, it
  430. must allow tight control over depositing, recovering, and maintaining
  431. keys, tied to the user's own practices and requirements. Generally,
  432. only a small number of individuals will need the ability to recover
  433. any individual key, often working in the same location and personally
  434. known to one another. When a key does need to be recovered, it will
  435. frequently be a local matter, similar to the replacement of a
  436. misplaced office key or restoring a computer file with a backup copy.
  437. The hours at which the key recovery might take place, the
  438. identification of the individuals authorized for a particular key, the
  439. policy for when keys should be recovered, and other basic operational
  440. procedures will vary widely from user to user, even within a single
  441. business. Particularly important is the control over when and how
  442. ``recoverable'' keys are destroyed when they are no longer needed,
  443. especially for keys associated with sensitive personal and business
  444. records.
  445.  
  446. Similarly, there is usually no business need for secrecy in the
  447. recovery of keys or for the ability to obtain keys without the initial
  448. cooperation of the user. When key recovery is used in a business
  449. environment, it would generally be one component of the overall data
  450. management policy of that business. Users would normally be trusted to
  451. participate in assuring recoverability of their own keys, assisted by
  452. local management practices and supervision. When a key must be
  453. recovered, it will usually be because the users themselves realize
  454. that they do not have a copy of the correct key or because the
  455. keyholder is no longer available. Even the frequently-cited
  456. hypothetical example of the disgruntled employee who refuses to
  457. decrypt important files is probably most reliably and economically
  458. dealt with through business data management practices (such as
  459. management supervision and backup of business-critical plaintext) that
  460. do not require any centralized, standard key recovery mechanism. Even
  461. in this (rather unusual) case, there is no need to hide from the user
  462. the fact that a key has been recovered.
  463.  
  464. The U.S. government, on the other hand, proposes key recovery schemes
  465. that by their nature do not allow local control. The government's
  466. requirement for the ability to covertly recover keys on short notice
  467. and without notice to the key owner must almost by definition be
  468. implemented by a third party whose procedures are entirely divorced
  469. from those of the users. Even when the government permits an
  470. organization to manage its own keys, the key recovery agent will have
  471. to be fairly centralized and remote from the actual users. This
  472. requirement eliminates the first line of defense against misuse of key
  473. recovery: the vigilance of the most concerned party - the key owner.
  474.  
  475.  
  476. 2.4 Infrastructure: Key Certification and Distribution vs. Key
  477. Recovery
  478.  
  479. As electronic commerce and encryption use becomes more widespread,
  480. some form of ``Certification Authorities'' (CAs) will be needed in
  481. some applications to help identify encryption users. A CA is a trusted
  482. party that vouches for the identity (or some other attribute) of an
  483. encryption user. It is widely believed that development and use of
  484. certification authorities will be essential for secure and trusted
  485. electronic exchanges - and, consequently, will become a prerequisite
  486. to participation in electronic commerce and online communications.[18]
  487.  
  488. Although superficially similar, in that they are both concerned with
  489. key management, the nature of key recovery is completely different
  490. from that of key certification. The most important function of a
  491. certification authority is to certify the public keys used in digital
  492. signatures; key recovery, on the other hand, is concerned with keys
  493. used for confidentiality. More importantly, the operation of a
  494. certification authority does not require handling sensitive user data;
  495. a CA generally handles only users' public keys and never learns the
  496. associated secret keys. If a CA's secret key is compromised or
  497. revealed, the only direct damage is that the certificates from it can
  498. be forged. On the other hand, if a key recovery agent's secrets are
  499. compromised, the damage can be far greater and more direct: every user
  500. of that recovery agent might have its own secrets compromised.
  501.  
  502. Certification can (and currently does) exist without any form of key
  503. recovery. Conversely, a key recovery infrastructure can exist
  504. completely independently of any key certification infrastructure.
  505.  
  506. Several recent government proposals have attempted to associate key
  507. recovery with key certification. This proposed linkage between CAs and
  508. key recovery makes no sense technically. On the contrary, such
  509. linkages have serious liabilities. It is not even clear whether such a
  510. system would work. To the extent it might require depositing keys used
  511. for signature and identification, such systems create additional
  512. security risks; there is no justification (even given government law
  513. enforcement requirements) for third-party access to signature keys
  514. that, if compromised, could be used to impersonate people, or to forge
  515. their digital signatures. In fact, attempts at achieving key recovery
  516. through a certification infrastructure would likely be ineffective at
  517. meeting the goals of law enforcement. Many (indeed, most) encryption
  518. keys are not certified directly, and therefore would be beyond the
  519. reach of a certification-based recovery system.
  520.  
  521.  
  522. 3 Risks and Costs of Key Recovery
  523.  
  524. Key recovery systems are inherently less secure, more costly, and more
  525. difficult to use than similar systems without a recovery feature. Key
  526. recovery degrades many of the protections available from encryption,
  527. such as absolute control by the user over the means to decrypt data.
  528. Furthermore, a global key recovery infrastructure can be expected to
  529. be extraordinarily complex and costly.
  530.  
  531. The impact of key recovery can be considered in at least three
  532. dimensions:
  533.  
  534.    * Risk - The failure of key recovery mechanisms can jeopardize the
  535.      proper operation, underlying confidentiality, and ultimate
  536.      security of encryption systems; threats include improper
  537.      disclosures of keys, theft of valuable key information, or
  538.      failure to be able to meet law enforcement demands.
  539.    * Complexity - Although it may be possible to make key recovery
  540.      reasonably transparent to the end users of encryption, a fully
  541.      functional key recovery infrastructure is an extraordinarily
  542.      complex system, with numerous new entities, keys, operational
  543.      requirements, and interactions. In many cases, the key recovery
  544.      aspects of a system are far more complex and difficult to
  545.      implement than the basic encryption functions themselves.
  546.    * Economic Cost - No one has yet described, much less demonstrated,
  547.      a viable economic model to account for the true costs of key
  548.      recovery. However, it is still possible to make sound qualitative
  549.      judgments about the basic system elements, shared by all key
  550.      recovery schemes, that will have the most dramatic impact on the
  551.      cost of designing, implementing, deploying, and operating such
  552.      systems.
  553.  
  554.  
  555. 3.1 New Vulnerabilities and Risks
  556.  
  557. Any key recovery infrastructure, by its very nature, introduces a new
  558. and vulnerable path to the unauthorized recovery of data where one did
  559. not otherwise exist. This introduces at least two harmful effects:
  560.  
  561.    * It removes the inherent guarantees of security available through
  562.      non-recoverable systems, which do not have an alternate path to
  563.      sensitive plaintext that is beyond the users' control.
  564.    * It creates new concentrations of decryption information that are
  565.      high-value targets for criminals or other attackers.
  566.  
  567. These risks arise with cryptography used in communication and storage,
  568. but perhaps even more intensely with cryptography used in
  569. authentication. (They are compounded even further if any keys are used
  570. for more than one of these purposes.)
  571.  
  572.  
  573. 3.1.1 New Paths to Plaintext
  574.  
  575. Regardless of the implementation, if key recovery systems must provide
  576. timely law enforcement access to a whole key or to plaintext, they
  577. present a new and fast path to the recovery of data that never existed
  578. before.
  579.  
  580. The key recovery access path is completely out of the control of the
  581. user. In fact, this path to exceptional access is specifically
  582. designed to be concealed from the encryption user, removing one of the
  583. fundamental safeguards against the mistaken or fraudulent release of
  584. keys.
  585.  
  586. In contrast, non-recoverable systems can usually be designed securely
  587. without any alternative paths. Alternative paths to access are neither
  588. required for ordinary operation nor desirable in many applications for
  589. many users.
  590.  
  591.  
  592. 3.1.2 Insider Abuse
  593.  
  594. Like any other security system with a human element, key recovery
  595. systems are particularly vulnerable to compromise by authorized
  596. individuals who abuse or misuse their positions. Users of a key
  597. recovery system must trust that the individuals designing,
  598. implementing, and running the key recovery operation are indeed
  599. trustworthy. An individual, or set of individuals, motivated by
  600. ideology, greed, or the threat of blackmail, may abuse the authority
  601. given to them. Abuse may compromise the secrets of individuals,
  602. particular corporations, or even of entire nations. There have been
  603. many examples in recent times of individuals in sensitive positions
  604. violating the trust placed in them. There is no reason to believe that
  605. key recovery systems can be managed with a higher degree of success.
  606.  
  607. The risk of ``insider abuse'' becomes even more evident when attempts
  608. are made to design key recovery schemes that are international in
  609. scope. Such abuse can even become institutionalized within a rogue
  610. company or government. National law-enforcement agencies, for example,
  611. might abuse their key recovery authority to the advantage of their own
  612. country's corporations.
  613.  
  614.  
  615. 3.1.3 New Targets for Attack
  616.  
  617. The nature of key recovery creates new high-value targets for attack
  618. of encryption systems. Key recovery agents will maintain databases
  619. that hold, in centralized collections, the keys to the information and
  620. communications their customers most value. In many key recovery
  621. systems, the theft of a single private key (or small set of keys) held
  622. by a recovery agent could unlock much or all of the data of a company
  623. or individual. Theft of a recovery agent's own private keys might
  624. provide access to an even broader array of communications, or might
  625. make it possible to easily spoof header information designed to ensure
  626. compliance with encryption export controls. The key recovery
  627. infrastructure will tend to create extremely valuable targets, more
  628. likely to be worth the cost and risk of attack.
  629.  
  630. The identity of these new rich targets will be highlighted by the key
  631. recovery systems themselves. Every encrypted communication or stored
  632. file will be required to include information about the location of its
  633. key retrieval information. This ``pointer'' is a road map showing law
  634. enforcement how to recover the plaintext, but it may also show
  635. unauthorized attackers where to focus their efforts. Moreover, even
  636. those systems (such as split key systems) that can decrease these
  637. risks, do so with a marked increase in cost. For example, splitting a
  638. key in half at least doubles the recovery agent costs.[19] Such
  639. systems require multiple agents, costly additional coordination
  640. mechanisms, and faster response times necessary to assemble split keys
  641. and still provide fast access to plaintext. Regardless of how many
  642. times a key is split, law enforcement's demand for timely access will
  643. still require the development of fast systems for the recovery of key
  644. parts. Both the systems for key part assembly, and the ultimate whole
  645. key assembled for law enforcement, will present new points of
  646. vulnerability.
  647.  
  648.  
  649. 3.1.4 Forward Secrecy
  650.  
  651. Key recovery is especially problematic in communications systems, such
  652. as encrypted cellular telephone calls, because it destroys the
  653. property of forward secrecy. A system with forward secrecy is one in
  654. which compromising the keys for decrypting one communication does not
  655. reduce the security of other communications. For example, in an
  656. encrypted telephone call, the keys for encrypting a call can be
  657. established as the call is set up. If these keys are destroyed when
  658. the call is over, the participants can be assured that no one can
  659. later decrypt that conversation--even if the keys to some subsequent
  660. conversation are compromised. The result is that once the call is
  661. over, the information required to decrypt it ceases to exist; not even
  662. the parties to the call store the keys. Typically, keys are created
  663. and destroyed on a per-call basis, or even many times per call. This
  664. makes it possible to limit the costs and risks of secure processing
  665. and storage to the period of the call itself.
  666.  
  667. Forward secrecy is desirable and important for two reasons. First, it
  668. simplifies the design and analysis of secure systems, making it much
  669. easier to ensure that a design or implementation is in fact secure.
  670. Secondly, and more importantly, forward secrecy greatly increases the
  671. security and decreases the cost of a system, since keys need to be
  672. maintained and protected only while communication is actually in
  673. progress.
  674.  
  675. Key recovery destroys the forward secrecy property, since the ability
  676. to recover traffic continues to exist long after the original
  677. communication has occurred. It requires that the relevant keys be
  678. stored instead of destroyed, so that later government requests for the
  679. plaintext can succeed. If the keys are stored, they can be
  680. compromised; if they are destroyed, the threat of compromise ceases at
  681. that moment.
  682.  
  683.  
  684. 3.2 New Complexities
  685.  
  686. Experience has shown that secure cryptographic systems are deceptively
  687. hard to design and build properly. The design and implementation of
  688. even the simplest encryption algorithms, protocols, and
  689. implementations is a complex and delicate process. Very small changes
  690. frequently introduce fatal security flaws. Non-key recovery systems
  691. have rather simple requirements and yet exploitable flaws are still
  692. often discovered in fielded systems.
  693.  
  694. Our experiences designing, analyzing and implementing encryption
  695. systems convince us that adding key recovery makes it much more
  696. difficult to assure that such systems work as intended. It is
  697. possible, even likely, that lurking in any key recovery system are one
  698. or more design, implementation, or operational weaknesses that allow
  699. recovery of data by unauthorized parties. The commercial and academic
  700. world simply does not have the tools to properly analyze or design the
  701. complex systems that arise from key recovery.
  702.  
  703. This is not an abstract concern. Most of the key recovery or key
  704. escrow proposals made to date, including those designed by the
  705. National Security Agency, have had weaknesses discovered after their
  706. initial implementation. For example, since the system's introduction
  707. in 1993, several failures have been discovered in the U.S. Escrowed
  708. Encryption Standard, the system on which the ``Clipper Chip'' is
  709. based. These problems are not a result of incompetence on the part of
  710. the system's designers. Indeed, the U.S. National Security Agency may
  711. be the most advanced cryptographic enterprise in the world, and it is
  712. entrusted with developing the cryptographic systems that safeguard the
  713. government's most important military and state secrets. The reason the
  714. Escrowed Encryption Standard had flaws is that good security is an
  715. extremely difficult technical problem to start with, and key recovery
  716. adds enormous complications with requirements unlike anything
  717. previously encountered.
  718.  
  719.  
  720. 3.2.1 Scale
  721.  
  722. Key recovery as envisioned by law enforcement will require the
  723. deployment of secure infrastructures involving thousands of companies,
  724. recovery agents, regulatory bodies, and law enforcement agencies
  725. worldwide interacting and cooperating on an unprecedented scale.
  726.  
  727. Once widely available, encryption will likely be used for the bulk of
  728. network communications and storage of sensitive files. By the year
  729. 2000 - still early in the adoption of information technologies -
  730. fielding the ubiquitous key recovery system envisioned by law
  731. enforcement could encompass:
  732.  
  733.    * Thousands of products. There are over 800 encryption products
  734.      worldwide today, and this number is likely to grow dramatically.
  735.    * Thousands of agents all over the world. Proposed systems
  736.      contemplate many key recovery agents within this country alone;
  737.      other countries will want agents located within their borders.
  738.      Large companies will want to serve as their own key recovery
  739.      agents. Each of these agents will need to obtain U.S.
  740.      certification and possibly certification by other countries as
  741.      well.
  742.    * Tens of thousands of law enforcement agencies. There are over
  743.      17,000 local, state, and federal law enforcement agencies in the
  744.      United States alone that might seek key information for
  745.      authorized wiretaps or seized data.[20] National and local
  746.      agencies around the world will also want access to keys.
  747.    * Millions of users. Several million Web users today use encrypted
  748.      communications whenever their Web browser encounters a secure
  749.      page (such as many of those used for credit card transactions).
  750.      There will be an estimated 100 million Internet users by the year
  751.      2000, most of whom will be likely to regularly encrypt
  752.      communications as part of the next version of the standard
  753.      Internet protocols. Millions of other corporate and home computer
  754.      users will also regularly encrypt stored information or
  755.      intra-network communications.
  756.    * Tens of millions (or more) of public-private key pairs. Most
  757.      users will have several public key pairs for various purposes.
  758.      Some applications create key pairs ``on-the-fly'' every time they
  759.      are used.
  760.    * Hundreds of billions of recoverable session keys. Every encrypted
  761.      telephone call, every stored encrypted file, every e-mail
  762.      message, and every secure web session will create a session key
  763.      to be accessed. (Various key recovery scheme may avoid the need
  764.      for the recovery center to process these session keys
  765.      individually, but such ``granularity shifts'' introduce
  766.      additional risk factors - see Section 3.4.1 below.)
  767.  
  768. Ultimately, these numbers will grow further as improved information
  769. age technologies push more people and more data online.
  770.  
  771. The overall infrastructure needed to deploy and manage this system
  772. will be vast. Government agencies will need to certify products. Other
  773. agencies, both within the U.S. and in other countries, will need to
  774. oversee the operation and security of the highly-sensitive recovery
  775. agents - as well as ensure that law enforcement agencies get the
  776. timely and confidential access they desire. Any breakdown in security
  777. among these complex interactions will result in compromised keys and a
  778. greater potential for abuse or incorrect disclosures.
  779.  
  780. There are reasons to believe secure key recovery systems are not
  781. readily scalable. Order-of-magnitude increases in the numbers of
  782. requesting law enforcement agencies, product developers, regulatory
  783. oversight agencies, and encryption end users all make the tasks of
  784. various actors in the key recovery system not only bigger, but much
  785. more complex. In addition, there are significant added transaction
  786. costs involved with coordination of international key recovery regimes
  787. involving many entities.
  788.  
  789. The fields of cryptography, operating systems, networking, and system
  790. administration have no substantive experience in deploying and
  791. operating secure systems of this scope and complexity. We simply do
  792. not know how to build a collective secure key-management
  793. infrastructure of this magnitude, let alone operate one, whether the
  794. key-recovery infrastructure is centralized or widely distributed.
  795.  
  796.  
  797. 3.2.2 Operational Complexity
  798.  
  799. The scale on which a government-access key recovery infrastructure
  800. must operate exacerbates many of the security problems with key
  801. recovery. The stated requirements of law enforcement demand the
  802. construction of highly complex key recovery systems. Demands on the
  803. speed and process for recovering keys will greatly increase the
  804. complexity of tasks facing those trusted with key recovery
  805. information. Demands for ubiquitous worldwide adoption of key recovery
  806. will greatly increase the complexity and number of entities involved.
  807. Each of these will in turn have a significant impact on both the
  808. security and cost of the key recovery system.
  809.  
  810. Consider the tasks that a typical key recovery center will perform to
  811. meet one law enforcement request for a session key for one
  812. communication or stored file:
  813.  
  814.    * Reliably identify and authenticate requesting law enforcement
  815.      agents (there are over 17,000 U.S. domestic law enforcement
  816.      organizations).
  817.    * Reliably authenticate court order or other documentation.
  818.    * Reliably authenticate target user and data.
  819.    * Check authorized validity time period.
  820.    * Recover session key, plaintext data, or other decryption
  821.      information.
  822.    * Put recovered data in required format.
  823.    * Securely transfer recovered data, but only to authorized parties.
  824.    * Reliably maintain an audit trail.
  825.  
  826. Each of these tasks must be performed securely in a very short period
  827. of time in order to meet government requirements. For example, the
  828. most recent U.S. Commerce Department regulations governing recovery
  829. agents require two hour turnaround of government requests, around the
  830. clock. The tasks must be performed by agents all over the world
  831. serving millions of clients and responding to requests from both those
  832. clients and numerous law enforcement agencies.
  833.  
  834. There are few, if any, secure systems that operate effectively and
  835. economically on such a scale and under such tightly-constrained
  836. conditions - even if these requirements are relaxed considerably
  837. (e.g., one day response time instead of two hours). The urgent rush
  838. imposed by very short retrieval times, and the complexity of the tasks
  839. involved, are an anathema to the careful scrutiny that should be
  840. included in such a system. If there is uncertainty at any step of the
  841. access process, there may be insufficient time to verify the
  842. authenticity or accuracy of a retrieval request.
  843.  
  844. It is inevitable that a global key recovery infrastructure will be
  845. more vulnerable to fraudulent key requests, will make mistakes in
  846. giving out the wrong key, and will otherwise compromise security from
  847. time to time. While proper staffing, technical controls, and sound
  848. design can mitigate these risks to some extent (and at considerable
  849. cost), the operational vulnerabilities associated with key recovery
  850. cannot be eliminated entirely.
  851.  
  852.  
  853. 3.2.3 Authorization for Key Recovery
  854.  
  855. One of the requirements for a key recovery operation is that it must
  856. authenticate the individual requesting an archived key. Doing so
  857. reliably is very difficult.
  858.  
  859. ``Human'' forms of identification - passports, birth certificates, and
  860. the like - are often easily counterfeited. Indeed, news reports
  861. describe ``identity theft'' as a serious and growing problem.
  862. Electronic identification must be cryptographic, in which case a key
  863. recovery system could be used to attack itself. That is, someone who
  864. steals - or recovers - a signature key for a law enforcement officer
  865. or a corporate officer could use this key to forge legitimate requests
  866. for many other keys. For that matter, if a sensitive confidentiality
  867. key were stolen or obtained from the repository, it might be possible
  868. to use it to eavesdrop on other key recovery conversations.
  869.  
  870. In contrast, a business's local, day-to-day key recovery process could
  871. rely on personal identification. A system administrator or supervisor
  872. would know who had rights to which keys. Even more questionable
  873. requests, such as those over the phone, could be handled
  874. appropriately; the supervisor could weigh such factors as the
  875. sensitivity of the information requested, the urgency of the request
  876. as known a priori, and even the use of informal authentication
  877. techniques, such as references to shared experiences. But none of
  878. these methods scale well to serve requests from outside the local
  879. environment, leaving them unsuitable for use by larger operations or
  880. when requests come from persons or organizations not personally known
  881. to the keyholders.
  882.  
  883.  
  884. 3.3 New Costs
  885.  
  886. Key recovery, especially on the scale required for government access,
  887. will be very expensive. New costs are introduced across a wide range
  888. of entities and throughout the lifetime of every system that uses
  889. recoverable keys.
  890.  
  891. The requirements set out by law enforcement impose new system costs
  892. for designing, deploying, and operating the ubiquitous key recovery
  893. system. These costs include:
  894.  
  895.    * Operational costs for key recovery agents - the cost of
  896.      maintaining and controlling sensitive, valuable key information
  897.      securely over long periods of time; of responding to both law
  898.      enforcement requests and legitimate commercial requests for data;
  899.      and of communicating with users and vendors.
  900.    * Product design and engineering costs - new expenses entailed in
  901.      the design of secure products that conform to the stringent key
  902.      recovery requirements.
  903.    * Government oversight costs - substantial new budgetary
  904.      requirements for government, law enforcement, or private
  905.      certification bodies, to test and approve key recovery products,
  906.      certify and audit approved recovery agents, and support law
  907.      enforcement requests for and use of recovered key information.
  908.    * User costs - including both the expense of choosing, using, and
  909.      managing key recovery systems and the losses from lessened
  910.      security and mistaken or fraudulent disclosures of sensitive
  911.      data.
  912.  
  913.  
  914. 3.3.1 Operational Costs
  915.  
  916. The most immediately evident problem with key recovery may be the
  917. expense of securely operating the infrastructure required to support
  918. it. In general, cryptography is an intrinsically inexpensive
  919. technology; there is little need for externally-operated
  920. ``infrastructure'' (outside of key certification in some applications)
  921. to establish communication or store data securely. Key recovery, on
  922. the other hand, requires a complex and poorly understood - and hence
  923. expensive and insecure - infrastructure.
  924.  
  925. The operational complexity described in the previous section
  926. introduces substantial ongoing costs at each key recovery center.
  927. These costs are likely to be very high, especially compared with the
  928. ordinary operational expenses that might be expected in commercial key
  929. recovery systems. Government key recovery requires, for example,
  930. intensive staffing (7x24 hours), highly trained and highly trusted
  931. personnel, and high-assurance hardware and software systems in order
  932. to meet the government's requirements in a secure manner. Theses costs
  933. are borne by all encryption applications, even those where key
  934. recovery is not beneficial to the user or even to law enforcement.
  935.  
  936. It remains unclear whether the high-risk, high-liability business of
  937. operating a key recovery center, with limited consumer demand to date,
  938. will even be economically viable.
  939.  
  940.  
  941. 3.3.2 Product Design Costs
  942.  
  943. Key recovery also increases the difficulty and expense of designing
  944. user-level encryption software and hardware. These costs vary
  945. depending on the particular application and the precise nature of the
  946. recovery system, but could be substantial in some cases. Integrating
  947. key recovery, especially in a secure manner, can also substantially
  948. delay the release of software. Given the highly competitive nature and
  949. short product life-cycles of today's hardware and software markets,
  950. such delays could discourage vendors from incorporating it at all, or
  951. worse, encourage sloppy, poorly-validated designs. Compatibility with
  952. older products presents special challenges and further increases these
  953. costs.
  954.  
  955.  
  956. 3.3.3 End-User Costs
  957.  
  958. Without government-driven key recovery, encryption systems can easily
  959. be fielded in a way that is largely transparent to their users. Highly
  960. secure communication and storage need require nothing further than the
  961. purchase of a reputable commercial product with strong encryption
  962. features tested in the marketplace. The use of that encryption need
  963. require nothing more than the setting of an option, the click of an
  964. icon, or the insertion of a hardware card. We are fully confident
  965. that, in an unregulated marketplace, many applications will ship with
  966. such high-quality user-transparent encryption built in. This is
  967. already happening at negligible cost to the user.
  968.  
  969. In contrast, the use of a secure key recovery system requires at least
  970. some additional user effort, diligence, or expense. In addition to the
  971. purchase of an encryption product, one or more key recovery agent(s)
  972. must be chosen. The user must enter into an important (although
  973. possibly implicit) contractual relationship with that agent, a
  974. relationship that will govern the potential disclosure of the most
  975. sensitive key information - now and for years to come. In many cases,
  976. there will need to be some communication of key information between
  977. user and the recovery agent. (Although some products will come with a
  978. built-in key, prudent users may want to change their keys on a regular
  979. basis. Also, software, especially mass-market ``shrink-wrapped''
  980. software, cannot usually be economically distributed with unique keys
  981. installed in each individual copy).
  982.  
  983. The burdens on key recovery users continue long after data have been
  984. encrypted. Key recovery agents will maintain the ability to decrypt
  985. information for years. During that time, an agent might relax its
  986. security policies, go bankrupt, or even be bought out by a competitor
  987. - but will retain, and in fact must retain, the ability to decrypt.
  988. Diligent and concerned encryption users will need to be aware of the
  989. fate of their key recovery agents for years after their initial
  990. encryption use.
  991.  
  992. These burdens will apply to all users of encryption. Each use of
  993. encryption may entail the entry into a contractual relationship with a
  994. third-party key recovery agent. Under any rational business model,
  995. each such instance will entail some additional cost.
  996.  
  997.  
  998. 3.4 Tradeoffs
  999.  
  1000. Some aspects of key recovery can be easily shifted along a spectrum
  1001. from higher cost to higher risk. While it may be possible to field a
  1002. particular key escrow system in a relatively secure way, this often
  1003. results in tremendous costs to the user. While relatively simple and
  1004. inexpensive key escrow systems exist, they often jeopardize security.
  1005. For example, a poorly-run key recovery agent, employing less-skilled
  1006. low-paid personnel, with a low level of physical security, and without
  1007. liability insurance could be expected to be less expensive to operate
  1008. than a well-run center.
  1009.  
  1010. Interestingly, security and cost can also be traded off with respect
  1011. to the design itself. That is, the simplest designs, those that are
  1012. easiest to understand and easiest to verify, also tend to require the
  1013. most stringent assumptions about their environment and operation or
  1014. have the worst failure characteristics. For example, imagine a design
  1015. in which session keys are sent to the recovery center by encrypting
  1016. them with the center's globally-known public key. Such a system might
  1017. be relatively simple to design and implement, and one might even be
  1018. able to prove that it is secure when operated correctly and under
  1019. certain assumptions. However, this is among the worst possible designs
  1020. from a robustness point of view: it has a single point of failure (the
  1021. key of the recovery agent) with which all keys are encrypted. If this
  1022. key is compromised (or a corrupt version distributed), all the
  1023. recoverable keys in the system could be compromised. (We note that
  1024. several commercial systems are based on almost exactly this design.)
  1025.  
  1026.  
  1027. 3.4.1 Key Recovery Granularity and Scope
  1028.  
  1029. One of the most important factors influencing the cost and security
  1030. of key recovery is the granularity and scope of the keys managed by
  1031. the key recovery system. In particular, it is important to understand
  1032. two issues:
  1033.  
  1034.    * Granularity: the kinds of keys (user, device, session, etc.) that
  1035.      are recoverable.
  1036.    * Scope: the consequences of compromising a recovery agent's key.
  1037.  
  1038. Granularity is important because it defines how narrowly-specified the
  1039. data to be recovered from an agent can be and how often interactions
  1040. (by the user and by law enforcement) with the recovery agent must take
  1041. place. Various systems have been proposed in which the recovery agent
  1042. produces ``master'' keys that can decrypt all traffic to or from
  1043. individual users or hardware devices. In other systems, only the keys
  1044. for particular sessions are recovered. Coarse granularity (e.g., the
  1045. master key of the targeted user) allows only limited control over what
  1046. can be recovered (e.g., all data from a particular individual) but
  1047. requires few interactions between law enforcement and the recovery
  1048. center. Finer granularity (e.g., individual session keys), on the
  1049. other hand, allows greater control (e.g., the key for a particular
  1050. file or session, or only sessions that occurred within a particular
  1051. time frame), but requires more frequent interaction with the recovery
  1052. center (and increased design complexity).
  1053.  
  1054. Also important is the scope of the recovery agent's own secret. Most
  1055. key recovery systems require the user software or hardware to send
  1056. keys to the recovery agent by encrypting them with the recovery
  1057. agent's public key. If a recovery agent has only a single such key,
  1058. that key becomes an extraordinarily valuable, global, single point of
  1059. failure. Worse, because the recovery agent must use the secret
  1060. component of this key in order to decrypt the keys sent to it (or at
  1061. least any time a key is recovered), its exposure to compromise or
  1062. misuse is also increased. To address this vulnerability, a recovery
  1063. agent may have many such keys, perhaps one or more for each user.
  1064. However, negotiating and distributing these keys to the users
  1065. introduces still other complexities and vulnerabilities.
  1066.  
  1067.  
  1068. 4 Conclusions
  1069.  
  1070. Key recovery systems are inherently less secure, more costly, and more
  1071. difficult to use than similar systems without a recovery feature. The
  1072. massive deployment of key-recovery-based infrastructures to meet law
  1073. enforcement's specifications will require significant sacrifices in
  1074. security and convenience and substantially increased costs to all
  1075. users of encryption. Furthermore, building the secure infrastructure
  1076. of the breathtaking scale and complexity that would be required for
  1077. such a scheme is beyond the experience and current competency of the
  1078. field, and may well introduce ultimately unacceptable risks and costs.
  1079.  
  1080. Attempts to force the widespread adoption of key recovery through
  1081. export controls, import or domestic use regulations, or international
  1082. standards should be considered in light of these factors. We urge
  1083. public debate to carefully weigh the costs and benefits of
  1084. government-access key recovery before these systems are deployed.
  1085.  
  1086.  
  1087. The Authors
  1088.  
  1089.      Harold (Hal) Abelson is a Professor in the EECS department at MIT
  1090.      and a Fellow of the IEEE. He is co-author of the textbook
  1091.      Structure and Interpretation of Computer Programs and the 1995
  1092.      winner of the IEEE Computer Society's Education Award. Abelson is
  1093.      currently on leave from MIT at Hewlett-Packard Corporation, where
  1094.      he serves as scientific advisor to HP's Internet Technology
  1095.      Group.
  1096.  
  1097.      Ross Anderson teaches and directs research in computer security,
  1098.      cryptology and software engineering at Cambridge University in
  1099.      England. He is an expert on engineering secure systems, how they
  1100.      fail, and how they can be made more robust. He has done extensive
  1101.      work on commercial cryptographic systems, and recently discovered
  1102.      flaws in a British government key escrow protocol.
  1103.  
  1104.      Steven M. Bellovin is a researcher on cryptography, networks and
  1105.      security at AT&T Laboratories. He is co-author of the book
  1106.      Firewalls and Internet Security: Repelling the Wily Hacker. In
  1107.      1995 he was a co-recipient of the Usenix Lifetime Achievement
  1108.      Award for his part in creating Netnews. He is a member of the
  1109.      Internet Architecture Board.
  1110.  
  1111.      Josh Benaloh is a Cryptographer at Microsoft Research and has
  1112.      been an active researcher in cryptography for over a decade with
  1113.      substantial contributions in the areas of secret-ballot elections
  1114.      and secret sharing methods and applications. Before joining
  1115.      Microsoft, he was a Postdoctoral Fellow at the University of
  1116.      Toronto and an Assistant Professor at Clarkson University.
  1117.  
  1118.      Matt Blaze is a Principal Research Scientist at AT&T Laboratories
  1119.      in the area of computer security and cryptology. In 1994 he
  1120.      discovered several weaknesses in the U.S. government's
  1121.      ``Clipper'' key escrow system. His research areas include
  1122.      cryptology, trust management, and secure hardware. In 1996 he
  1123.      received the EFF's Pioneer Award for his contributions to
  1124.      computer and network security.
  1125.  
  1126.      Whitfield Diffie is a Distinguished Engineer at Sun Microsystems
  1127.      specializing in security. In 1976 Diffie and Martin Hellman
  1128.      created public key cryptography, which solved the problem of
  1129.      sending coded information between individuals with no prior
  1130.      relationship and is the basis for widespread encryption in the
  1131.      digital information age.
  1132.  
  1133.      John Gilmore is an entrepreneur and civil libertarian. He was an
  1134.      early employee of Sun Microsystems, and co-founded Cygnus
  1135.      Solutions, the Electronic Frontier Foundation, the Cypherpunks,
  1136.      and the Internet's ``alt'' newsgroups. He has twenty years of
  1137.      experience in the computer industry, including programming,
  1138.      hardware and software design, and management.
  1139.  
  1140.      Peter G. Neumann is a Principal Scientist in the Computer Science
  1141.      Lab at SRI. He is Moderator of the Risks Forum (comp.risks),
  1142.      author of Computer-Related Risks (Addison-Wesley), and co-author
  1143.      of the National Research Council study report, Cryptography's
  1144.      Role in Securing the Information Society (National Academy
  1145.      Press). He is a Fellow of the AAAS, ACM and IEEE.
  1146.  
  1147.      Ronald L. Rivest is the Webster Professor of Electrical
  1148.      Engineering and Computer Science in MIT's EECS Department. He is
  1149.      also an Associate Director of MIT's Laboratory for Computer
  1150.      Science. He is perhaps best known as a co-inventor of the RSA
  1151.      public-key cryptosystem and a founder of RSA Data Security, Inc.
  1152.  
  1153.      Jeffrey I. Schiller is the Network Manager at MIT and has managed
  1154.      the MIT campus computer network since its inception in 1984.
  1155.      Schiller is the author of the Kerberos Authentication System,
  1156.      serves as the Internet Engineering Steering Group's Area Director
  1157.      for Security, and is responsible for overseeing security-related
  1158.      Working Groups of the Internet Engineering Task Force (IETF).
  1159.  
  1160.      Bruce Schneier is president of Counterpane Systems, a
  1161.      Minneapolis-based consulting firm specializing in cryptography
  1162.      and computer security. He is the author of Applied Cryptography
  1163.      and inventor of the Blowfish encryption algorithm.
  1164.  
  1165.  
  1166. Notes
  1167.  
  1168. [1] MIT Laboratory for Computer Science/Hewlett-Packard, <hal@mit.edu>
  1169.  
  1170. [2] University of Cambridge, <ross.anderson@cl.cam.ac.uk>
  1171.  
  1172. [3] AT&T Laboratories - Research, <smb@research.att.com>
  1173.  
  1174. [4] Microsoft Research, <benaloh@microsoft.com>
  1175.  
  1176. [5] AT&T Laboratories - Research, <mab@research.att.com>
  1177.  
  1178. [6] Sun Microsystems, <diffie@eng.sun.com>
  1179.  
  1180. [7] <gnu@toad.com>
  1181.  
  1182. [8] SRI International, <neumann@sri.com>
  1183.  
  1184. [9] MIT Laboratory for Computer Science, <rivest@lcs.mit.edu>
  1185.  
  1186. [10] MIT Information Systems, <jis@mit.edu>
  1187.  
  1188. [11] Counterpane Systems, <schneier@counterpane.com>
  1189.  
  1190. [12] The latest version of this document can be found on the
  1191. world-wide-web at <http://www.crypto.com/key_study>, in PostScript
  1192. format at <ftp://research.att.com/dist/mab/key_study.ps> and in ASCII
  1193. text format at <ftp://research.att.com/dist/mab/key_study.txt>.
  1194.  
  1195. [13] This report grew out of a group meeting at Sun Microsystems in
  1196. Menlo Park, CA in late January 1997, including many of the authors and
  1197. also attended by Ken Bass, Alan Davidson, Michael Froomkin, Shabbir
  1198. Safdar, David Sobel, and Daniel Weitzner. The authors thank these
  1199. other participants for their contributions, as well as the Center for
  1200. Democracy and Technology for coordinating this effort and assisting in
  1201. the production of this final report.
  1202.  
  1203. [14] The National Research Council's comprehensive 1996 report on
  1204. cryptography includes a detailed examination of the rising importance
  1205. of encryption. National Research Council, Cryptography's Role in
  1206. Securing the Information Society (1996).
  1207.  
  1208. [15] Dept. of Commerce, ``Interim Rule on Encryption Items,'' Federal
  1209. Register, Vol. 61, p. 68572 (Dec. 30, 1996)
  1210.  
  1211. [16] For example, the recent British ``Trusted Third-Party'' system
  1212. proposes similar law enforcement demands, requiring one hour
  1213. turnaround time for TTP recovery agents. See U.K. Department of Trade
  1214. and Industry, ``LICENSING OF TRUSTED THIRD-PARTIES FOR THE PROVISION
  1215. OF ENCRYPTION SERVICES,'' (March 1997) (Public Consultation Paper).
  1216.  
  1217. [17] In fact, it is technically straightforward for two parties to use
  1218. their authentication keys to negotiate encryption keys for secure
  1219. communication. Any system that distributes trusted authentication keys
  1220. would ipso facto serve as an infrastructure for private communication
  1221. that is beyond the reach of government surveillance.
  1222.  
  1223. [18] There is a great deal of debate about the appropriate role of
  1224. government in regulating CAs. CAs may ultimately be large,
  1225. centralized, or even government-certified entities, or smaller,
  1226. locally-trusted entities. At this early stage in their deployment, no
  1227. consensus has emerged on what government role is appropriate. For an
  1228. excellent overview of the debate over CA regulation, see Michael
  1229. Froomkin, ``The Essential Role of Trusted Third-Parties in Electronic
  1230. Commerce,'' 75 Oregon L. Rev. 49 (1996).
  1231.  
  1232. [19] Storage of a smaller key part is not necessarily cheaper than
  1233. storage of the whole key, and the preferred key-splitting methods
  1234. generally produce key parts each of which is as large as the whole
  1235. key.
  1236.  
  1237. [20] U.S. Department of Justice, Bureau of Justice Statistics,
  1238. Sourcebook of Criminal Justice Statistics 1995 (1996), p. 39.
  1239.  
  1240.