Text File

Subject: RISKS DIGEST 15.48 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Weds 9 February 1994 Volume 15 : Issue 48

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Notes on key escrow meeting with NSA (Matt Blaze) Re: Campaign and Petition Against Clipper (Dorothy Denning) Information on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Tue, 08 Feb 94 16:03:55 -0500 From: Matt Blaze <mab@research.att.com> Subject: Notes on key escrow meeting with NSA

(originally submitted last week, but lost somewhere in our news system)

A group from NSA and FBI met the other day with a group of us at Bell Labs to discuss the key escrow proposal. They were surprisingly forthcoming and open to discussion and debate, and were willing to at least listen to hard questions. They didn't object when asked if we could summarize what we learned to the net. Incidentally, the people at the meeting seemed to base a large part of their understanding of public opinion on Usenet postings. Postings to RISKS, sci.crypt and talk.politics.crypto seem to actually have an influence on our government.

Since the many of the points brought up at the meeting have been discussed in RISKS, it seems appropriate to post a summary here.

A number of things came out at the meeting that we didn't previously know or that clarified previously released information. What follows is a rough summary; needless to say, nothing here should be taken as gospel, or representing the official positions of anybody. Also, nothing here should be taken as an endorsement of key escrow, clipper, or anything else by the authors; we're just reporting. These notes are based on the collective memory of Steve Bellovin, Matt Blaze, Jack Lacy, and Mike Reiter; there may be errors or misunderstandings. Please forgive the rough style. Note also the use of "~ ~" for 'approximate quotes' (a marvelous Whit Diffie-ism).

NSA's stated goals and motives for all this: * DES is at the end of its useful life * Sensitive, unclassified government data needs protection * This should be made available to US Citizens * US business data abroad especially needs protection * The new technology should not preclude law enforcement access

They indicated that the thinking was not that criminals would use key escrowed crypto, but that they should not field a system that criminals could easily use against them. The existence of key escrow would deter them from using crypto in the first place. The FBI representative said that they expect to catch "~only the stupid criminals~" through the escrow system.

Another stated reason for key escrow is that they do not think that even government-spec crypto devices can be kept physically secure. They do expect enough to be diverted to the black market that they feel they need a response. NSA's emphasis was on the foreign black market...

There seems to be a desire to manipulate the market, by having the fixed cost of key escrow cryptography amortized over the government market. Any private sector devices would have to sell a much larger number of units to compete on price. (This was somewhere between an implication and an explicit statement on their part.)

When asked about cryptography in software, "~...if you want US government cryptography, you must do it with hardware~".

The NSA people were asked whether they would consider evaluating ciphers submitted by the private sector as opposed to simply proposing a new cipher as a "black box" as they did with Skipjack. They said they can't do this because, among other things, of the extraordinary effort required to properly test a new cipher. They said that it often takes from 8-12 years to design, evaluate and certify a new algorithm, and that Skipjack began development "~about 10 years ago.~" I asked if we should infer anything from that about the value of the (limited time and resource) civilian Skipjack review. They accepted the question with good humor, but they did say that the civilian review was at least presented with and able to evaluate some of the results of NSA's previous internal reviews.

Clipper chips should be available (to product vendors) in June. You can't just buy loose chips - they have to be installed in approved products. Your application interface has to be approved by NIST for you to get your hands on the chips.

An interesting point came up about the reverse-engineering resistance of the chips: they are designed to resist non-destructive reverse engineering. It was not clear (from the information presented at the meeting) whether the chips are equally resistant to destructive reverse-engineering. That is, the chips are designed to resist non-destructive reverse engineering to obtain the unit keys. They do not believe that it is possible to obtain the unit key of a particular chip without destroying the chip. They did not present any assertions about resistance to destructive reverse engineering, such that several chips can be taken apart and destroyed in the process, to learn the Skipjack algorithm. They said the algorithm was patented, but they may have been joking. ("~And if that doesn't scare you enough, we'll turn the patent over to PKP.~")

The resistance to reverse engineering is not considered absolute by NSA. They do feel that "~it would require the resources of a national laboratory, and anyone with that much money can design their own cryptosystem that's just as strong.~"

They repeated several times that there are "~no plans to regulate the use of alternate encryption within the US by US citizens.~" They also indicated they "~weren't naive~" and didn't think that they could if they wanted to.

There were 919 authorized wiretaps, and 10,000 pen register monitors, in 1992. They do not have any figures yet on how often cryptography was used to frustrate wiretaps.

They do not yet have a production version of the "decoder" box used by law enforcement. Initially, the family key will be split (by the same XOR method) and handled by two different people in the authorized agencies. There is presently only one family key. The specifications of the escrow exploitation mechanism are not yet final, either; they are considering the possibility of having the central site strip off the outer layers of encryption, and only sending the session key back to the decoder box.

The escrow authorities will NOT require presentation of a court order prior to releasing the keys. Instead, the agency will fill out a form certifying that they have a legal authorization. This is also backed up with a separate confirmation from the prosecutor's office. The escrow agencies will supply any key requested and will not themselves verify that the keys requested are associated with the particular court order.

As an aside, we've since been informed by a member of the civilian Skipjack review committee that the rationale for not having the escrow agency see the actual wiretap order is so that they do not have access to the mapping between key serial numbers and people/telephones.

Regarding the scale of the escrow exploitation system, they said that they did not yet have a final operational specification for the escrow protocols, but did say that the escrow agencies would be expected to deliver keys "~within about 2 hours~" and are aiming for "~close to real time.~" Initially, the FBI would have the decoder box, but eventually, depending on costs and demand, any law enforcement agency authorized to conduct wiretaps would be able to buy one. The two escrow agencies will be responsible for verifying the certification from and securely delivering the key halves to any such police department.

The NSA did not answer a question as to whether the national security community would obtain keys from the same escrow mechanism for their (legally authorized) intelligence gathering or whether some other mechanism would exist for them to get the keys.

The masks for the Clipper/Capstone chip are unclassified (but are protected by trade secret) and the chips can be produced in an unclassified foundry. Part of the programming in the secure vault includes "~installing part of the Skipjack algorithm.~" Later discussion indicated that the part of the algorithm installed in the secure vault are the "S-tables", suggesting that perhaps unprogrammed Clipper chips can be programmed to implement other 80-bit key, 32 round ciphers.

The Capstone chip includes an ARM-6 RISC processor that can be used for other things when no cryptographic functions are performed. In particular, it can be used by vendors as their own on-board processor. The I/O to the processor is shut off when a crypto operation is in progress.

They passed around a Tessera PCMCIA (type 1) card. These cards contain a Capstone chip and can be used by general purpose PC applications. The cards themselves might not be export controlled. (Unfortunately, they took the sample card back with them...) The card will digitally sign a challenge from the host, so you can't substitute a bogus card. The cards have non-volatile onboard storage for users' secret keys and for the public keys of a certifying authority.

They are building a library/API for Tessera, called Catapult, that will provide an interface suitable for many different applications. They have prototype email and ftp applications that already uses it. They intend to eventually give away source code for this library. They responded favorably to the suggestion that they put it up for anonymous ftp.

Applications (which can use the library and which the NSA approves for government use) will be responsible for managing the LEAF field. Note that they intend to apply key escrowed Skipjack to other applications, including mail and file encryption. The LEAF would be included in such places as the mail header or the file attributes. This implies that it is possible to omit sending the LEAF -- but the decrypt chip won't work right if it doesn't get one.

When asked, they indicated that it might be possible wire up a pair of Clipper/Capstone chips to not transmit the LEAF field, but that the way to do this is "~not obvious from the interface we give you~" and "~you'd have to be careful not to make mistakes~". They gave a lot of attention to obvious ways to get around the LEAF.

The unit key is generated via Skipjack itself, from random seeds provided by the two escrow agencies (approximately monthly, though that isn't certain yet). They say they prefer a software generation process because its correct behavior is auditable.

Capstone (but not Clipper) could be configured to allow independent loading of the two key halves, in separate facilities. "~It's your money [meaning American taxpayers].~"

The LEAF field contains 80 bits for the traffic key, encrypted via the unit key in "~a unique mode <grin>~", 32 bits for the unit id, and a 16 bit checksum of some sort. (We didn't waste our breath asking what the checksum algorithm was.) This is all encrypted under the family key using "~another mode <grin>~".

They expressed a great deal of willingness to make any sort of reasonable changes that vendors needed for their products. They are trying *very* hard to get Skipjack and key escrow into lots of products.

Finally, I should make clear that "Clipper" is more properly called the "MYK-78T".

[Matt, Thanks for the contribution, and thanks for making careful distinctions among the escrow initiative (EEI), the algorithm (Skipjack), the telephone implementation (Clipper), and the computer system/network implementation (Capstone). Much of what has been written on the subject has been confused because those distinctions were not consistently made. PGN]

------------------------------

Date: Wed, 09 Feb 1994 17:23:28 -0500 (EST) From: denning@cs.cosc.georgetown.edu (Dorothy Denning) Subject: Re: Campaign and Petition Against Clipper

CPSR has announced a petition campaign to oppose the Clipper initiative. I would like to caution people about signing the petition. The issues are extremely complex and difficult. The Clipper initiative is the result of considerable deliberation by many intelligent people who appreciate and understand the concerns that have been expressed and who worked hard to accommodate the conflicting interests. The decisions that have been made were not made lightly.

I would like to respond to some of the statements that CPSR has made about Clipper in their campaign and petition letters:

The Clipper proposal, developed in secret by the National Security Agency, is a technical standard that will make it easier for government agents to wiretap the emerging data highway.

The standard (FIPS 185) is not a standard for the Internet or any other high speed computer network. It is for the telephone system. Quoting from FIPS 185: "Data for purposes of this standard includes voice, facsimile and computer information communicated in a telephone system. A telephone system for purposes of this standard is limited to a system which is circuit switched and operating at data rates of standard commercial modems over analog voice circuits or which uses basic-rate ISDN or a similar grade wireless service."

The standard will not make it any easier to tap phones, let alone computer networks. All it will do is make it technically possible to decrypt communications that are encrypted with the standard, assuming the communications are not superencrypted with something else. Law enforcers still need to get a court order just to intercept the communications in the first place, and advances in technology have made interception itself more difficult. The standard will make it much harder for anyone to conduct illegal taps, including the government.

The purpose of the standard is to provide a very strong encryption algorithm - something much stronger than DES - and to do so in a way that does not thwart law enforcement and national security objectives. Keys are escrowed so that if someone uses this technology, they cannot use it against national interests.

Industry groups, professional associations and civil liberties organizations have expressed almost unanimous opposition to the plan since it was first proposed in April 1993.

"The public does not like Clipper and will not accept it ..."

The private sector and the public have expressed nearly unanimous opposition to Clipper.

As near as I know, neither CPSR nor any other group has conducted any systematic poll of industry, professional societies, or the public. While many people have voiced opposition, there are many more organizations and people who have been silent on this issue. The ACM is in the process of conducting a study on encryption. CPSR is a member of the study group, as am I. Steve Kent is chair. Our goal is a report that will articulate the issues, not a public statement either for or against. The International Association for Cryptologic Research has not to my knowledge made any official statement about Clipper.

The Administration ignored the overwhelming opposition of the general public. When the Commerce Department solicited public comments on the proposal last fall, hundreds of people opposed the plan while only a few expressed support.

Hundreds of people is hardly overwhelming in a population of 250 million, especially when most of the letters were the same and came in through the net following a sample letter that was sent out.

The technical standard is subject to misuse and compromise. It would provide government agents with copies of the keys that protect electronic communications. "It is a nightmare for computer security."

I have been one of the reviewers of the standard. We have completed our review of the encryption algorithm, SKIPJACK, and concluded it was very strong. While we have not completed our review of the key escrow system, from what I have seen so far, I anticipate that it will provide an extremely high level of security for the escrowed keys.

The underlying technology was developed in secret by the NSA, an intelligence agency responsible for electronic eavesdropping, not privacy protection. Congressional investigations in the 1970s disclosed widespread NSA abuses, including the illegal interception of millions of cables sent by American citizens.

NSA is also responsible for the development of cryptographic codes to protect the nation's most sensitive classified information. They have an excellent track record in conducting this mission. I do not believe that our requirements for protecting private information are greater than those for protecting classified information. I do not know the facts of the 1970s incident that is referred to here, but it sounds like it occurred before passage of the 1978 Foreign Intelligence Surveillance Act. This act requires intelligence agencies to get a court order in order to intercept communications of American citizens. I am not aware of any recent evidence that the NSA is engaging in illegal intercepts of Americans.

Computer security experts question the integrity of the technology. Clipper was developed in secret and its specifications are classified.

The 5 of us who reviewed the algorithm unanimously agreed that it was very strong. We will publish a final report when we complete or full evaluation. Nothing can be concluded from a statement questioning the technology by someone who has not seen it regardless of whether that person is an expert in security.

NSA overstepped its legal authority in developing the standard. A 1987 law explicitly limits the intelligence agency's power to set standards for the nation's communications network.

The 1987 Computer Security Act states that NIST "shall draw on the technical advice and assistance (including work products) of the National Security Agency."

There is no evidence to support law enforcement's claims that new technologies are hampering criminal investigations. CPSR recently forced the release of FBI documents that show no such problems.

CPSR obtained some documents from a few FBI field offices. Those offices reported no problems. CPSR did not get reports from all field offices and did not get reports from local law enforcement agencies. I can tell you that it is a fact that new communications technologies, including encryption, have hampered criminal investigations. I personally commend law enforcement for trying to get out in front of this problem.

If the plan goes forward, commercial firms that hope to develop new products will face extensive government obstacles. Cryptographers who wish to develop new privacy enhancing technologies will be discouraged.

The standard is voluntary -- even for the government.

Mr. Rotenberg said "We want the public to understand the full implications of this plan. Today it is only a few experts and industry groups that understand the proposal.

I support this objective. Unfortunately, it is not possible for most of us to be fully informed of the national security implications of uncontrolled encryption. For very legitimate reasons, these cannot be fully discussed and debated in a public forum. It is even difficult to talk about the full implications of encryption on law enforcement. This is why it is important that the President and Vice-President be fully informed on all the issues, and for the decisions to be made at that level. The Feb. 4 decision was made following an inter-agency policy review, headed by the National Security Council, that examined these issues using considerable input from industry, CPSR, EFF, and individuals as well as from law enforcement and intelligence agencies. In the absence of understanding the national security issues, I believe we need to exercise some caution in believing that we can understand the full implications of encryption on society.

As part of the Feb. 4 announcement, the Administration announced the establishment of an Interagency Working Group on Encryption and Telecommunications, chaired by the White House Office of Science and Technology Policy and National Security Council, with representatives from Commerce, Justice, State, Treasury, FBI, NSA, OMB, and the National Economic Council. The group is to work with industry and public interest groups to develop new encryption technologies and to review and refine encryption policy. The NRC's Computer Science and Telecommunications Board will also be conducting a study of encryption policy.

These comments may be distributed.

Dorothy Denning, Georgetown University

------------------------------

Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. PLEASE read it as a newsgroup if possible and convenient for you. Undigestifiers are available throughout the Internet, but not from RISKS.

Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line; others may be ignored! Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially .UUCP folks. If you cannot read RISKS locally as a newsgroup (e.g., comp.risks), or you need help, send requests to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS".

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>YourName<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories.

IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM .

ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

------------------------------

End of RISKS-FORUM Digest 15.48 ************************