what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

arm-of-nsa.txt

arm-of-nsa.txt
Posted Dec 21, 1999

Paper on "The Arm" of the NSA

tags | encryption
SHA-256 | bfc274baaa14e2a92b1f7476a9d0e9bbf4c18253c7b2d5e6d5e971d3425c327b

arm-of-nsa.txt

Change Mirror Download
http://cnn.com/TECH/computing/9807/27/security.idg/index.html

The long, strong arm of the NSA
July 27, 1998
Web posted at: 4:15 PM EDT
by Ellen Messmer

FORT MEADE, Maryland (IDG) -- Back in the days of the cold war, Washington
insiders used to joke that NSA stood for "No Such Agency." The government
denied the very existence of this group, which is dedicated to
intercepting and decoding foreign communications.

That was then. Today the National Security Agency is well known, and
spends a lot of time leaning on software, switch and router vendors,
pushing them to re-tool their products. The agency's goal: to ensure that
the government has access to encrypted data.

The industry is facing a year-end deadline to add a government-approved
back door into network gear. Vendors that don't provide this access risk
losing export privileges.

Cruising up and down Silicon Valley, NSA spooks from the agency's Fort
Meade headquarters have been making pit stops at companies ranging from
industry leaders Netscape Communications Corp. and Sun Microsystems, Inc.
to start-ups such as VPNet Technologies, Inc. in order to get a peek at
products still on the drawing board.

The NSA wants software vendors to make sure that any product with strong
encryption have some way for the government to tap into the data. And
because practically every commercial network application, router or switch
these days includes encryption or an option for it, almost every vendor
now has to answer to the NSA if it wants to export.

Hot line to the NSA

It's gotten to the point where no vendor hip to the NSA's power will even
start building products without checking in with Fort Meade first. This
includes even that supposed ruler of the software universe, Microsoft
Corp. "It's inevitable that you design products with specific
[encryption] algorithms and key lengths in mind," said Ira Rubenstein,
Microsoft attorney and a top lieutenant to Bill Gates. By his own account,
Rubenstein acts as a "filter" between the NSA and Microsoft's design teams
in Redmond, Wash. "Any time that you're developing a new product, you will
be working closely with the NSA," he noted.

When it comes to encryption, it's widely known that a 40-bit encryption
key is easily breakable and hence rather useless. Until not long ago, this
is what the U.S. government allowed for the export of software.

But the Clinton administration a year and a half ago said it would allow
the export of products with stronger encryption keys by any vendor that
agreed to add a "key-recovery" feature to its products by year-end -
giving the government access to encrypted data without the end user's
knowledge.

According to Bill Reinsche, Department of Commerce undersecretary for the
Bureau of Export Controls, about 50 vendors have submitted plans for
government-approved key-recovery, also called data-recovery. These
companies, which include IBM, were rewarded with Key Management
Infrastructure (KMI) export licenses to export products with 56-bit or
stronger encryption until year-end.

But some companies are discovering that dealing with the Commerce
Department for a KMI license means more involvement with the NSA.

The Bureau of Export Control is actually just a front for the NSA, said
Alison Giacomelli, director of export compliance at VPNet Technologies,
Inc., a San Jose, Calif.-based vendor of IP-based encryption gateways.
"The NSA has sign-off authority on these KMI licenses," Giacomelli said.
In return for the KMI license, VPNet opened itself up for an NSA audit.

"They've already come out once, and they'll be coming out again,"
Giacomelli said. VPNet remains committed to meeting the deadline for
adding key-recovery to its product but has one major problem: uncertainty
about what the NSA really wants. The confusion means "there's a lot of
risk . . . in terms of engineering and resources," Giacomelli said.

Clearly wary of granting the government supervision over its products,
Microsoft has stubbornly refused to submit a data-recovery plan, even
though the Redmond giant already includes a data-recovery feature in its
Exchange Server.

"The Exchange Server can only be used when this feature is present,"
Rubenstein said. "Because we haven't filed a product plan, it's harder for
us to export this than for companies that have filed plans."

But in an odd-couple sort of joint-partner arrangement, Microsoft and the
NSA did work together to build what's called Server Gated Cryptography.
Primarily intended to help banks use Web servers to do business
internationally, the technology lets a server with a special digital
certificate provide 128-bit encryption support to a Web browser outside
the U.S.

Sybase, Inc., which also submitted a plan to add key-recovery to its
products, found it hard to satisfy the government's demands. "They
approved our technological approach but disapproved each of our
applications with it," said Sybase President and CEO Mitchell Kertzman.
"It's been frustrating."

Documents recently obtained under the Freedom of Information Act (FOIA) by
the Washington, D.C.-based Electronic Privacy Information Center contain
the data-recovery plan Netscape filed at the Commerce Department last
year.

Netscape's plan explains that the "escrow of private encryption keys"
could be achieved by developing client and server products that can only
issue an X.509 digital certificate after the private key has been
escrowed. The key can only be held by an entity chosen by the intranet
administrator who handles security policy.

The Netscape plan called for introducing a certificate server with
recovery capabilities in the first quarter of this year, with the
introduction of S/MIME clients with basic recovery features in the second
quarter.

Netscape hasn't actually carried out this plan, and the company declined
to discuss it. Netscape attorney Peter Harter would only say officially,
"We had no choice but to submit the plan, no matter how much we opposed
key-escrow, in order to be part of the ongoing dialog."

Other FOIA documents show that Netscape was regularly briefing the NSA on
its product plans since 1996 and that then NSA Deputy Director William
Crowell took a special interest in trying to dissuade Netscape from using
strong encryption.

Crowell, now vice president for product marketing and strategy at Cylink
Corp., said he had frequent discussions with Netscape, especially
concerning changes to Netscape Navigator. "Their product didn't have a
separate signature key, so if the government used the product for
key-escrow later, you'd have to store the signature key with a third
party, which we thought was a bad idea," Crowell said. He added that
Netscape Navigator 3.0 adopted the changes the NSA wanted.

According to Crowell, the NSA has a great deal of expertise in securing
communications, and it wants to ensure that products bought by the Defense
Department meet NSA standards. "In addition, as part of the NSA's
intelligence mission, [the agency needs] to have a thorough understanding
of where commercial products are headed."

Taher Elgamal, author of the Netscape data-recovery plan, who recently
left Netscape to start his own venture, said Netscape had no choice but to
maintain constant contact with the NSA. "They're costing the industry a
lot of money," Elgamal said.

Others agree. "Everyone in Silicon Valley, including us, has to have
specific staff - highly paid experts - to deal with them," said Chris
Tolles, security group product manager at Sun. "Their job is to wrangle
this from a policy standpoint."

Sun has had run-ins with the NSA in the past. Two years ago, the NSA
objected to Sun including encryption in the exportable version of Java
1.1. The end result was that Sun stripped encryption out of Java 1.1 and
the software was delayed by about six months.
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close