[10307] in Commercialization & Privatization of the Internet
[Clipper: Notes on key escrow meeting with NSA (AT&T)] (fwd)
daemon@ATHENA.MIT.EDU (SAMSAM@vm1.yorku.ca)
Fri Feb 18 01:27:27 1994
From: SAMSAM@vm1.yorku.ca
Resent-From: Sam Sternberg <SAMSAM@vm1.yorku.ca>
Resent-To: com-priv@psi.com, banisar@washofc.cpsr.org, mech@eff.org,
Date: Thu, 17 Feb 1994 03:32:08 -0800
To: SAMSAM@vm1.yorku.ca
----------------------------Original message----------------------------
>
>Read especially carefully the paragraph which describes how the key
>escrow will work.
>
>
>From: mab@research.att.com (Matt Blaze)
>Subject: Notes on key escrow meeting with NSA
>Organization: AT&T
>Date: Wed, 2 Feb 1994 21:02:55 GMT
>Message-ID: <mab.760222975@merckx>
>Originator: mab@merckx
>Sender: news@cbnewsj.cb.att.com (NetNews Administrator)
>Nntp-Posting-Host: merckx.l1135.att.com
>Lines: 162
>
>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 sci.crypt and
>talk.politics.crypto seem to actually have an influence on our
>government.
>
>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~".
>
>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 reverse engineering the data
>in the chip without destroying the chip. It is not clear (from the
>information presented at the meeting) whether the chips are equally
>resistant to destructive reverse-engineering 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 athorized
>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.
>
>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.
>
>- ------- End of Forwarded Message
>
>
>------- End of Forwarded Message
>
>
