The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 17 Issue 27

Friday 18 August 1995

Contents

o Netscape transaction security breached in 8 days by 1 person
Lewis McCarthy
o Netscape security
Peter Shank
o NIST crypto announcement on export controls and key escrow
Anne Shepherd
o Intel Warns of Marred Motherboards
Edupage
o The traffic light does NOT think
Torsten Ihle
o Stale accounts and lifestreams
Martin Ewing
o Re: Insisting on explanations for failures
Paul C. Kocher
o The MSN is Hacker Heavan
Mike Wyman via Andy Chesterton
o Windows 95 Registration Wizard confusion
Elliott
o Re: Air-traffic control power struggles continue
Sergio Gelato
o What is reality anyway? Re: Which risks to fight first?
Peter da Silva
o Re: Ten years still too soon to tell
Mark Brader
o Privacy Digests
o Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

Netscape transaction security breached in 8 days by 1 person

<lmccarth@cs.umass.edu>
Wed, 16 Aug 1995 06:15:17 -0400 (EDT)

Many customers now routinely purchase products over the Internet using their World Wide Web (WWW) browsers. Netscape Commerce Server software accepts orders submitted from a Netscape WWW browser, which are filled out in an on-line web form and transmitted across the net to the server.

Using the Secure Sockets Layer (SSL) protocol, the customer's name, address, phone number, and credit card number are encrypted with the RC4 algorithm developed by Ron Rivest of RSA Data Security. Due to export restrictions placed upon cryptographic software by the U.S. government, the release of the Netscape software most commonly used is limited to encrypting with a key only 40 bits in length.

A recent demonstration strikingly illustrates that this provides insufficient confidentiality for the task at hand -- maintaining the privacy of credit card information. After a sample transaction had been executed, and the log of the encrypted server-browser traffic posted to the net, a private individual managed to decrypt the transaction information in just 8 days of CPU time. It would seem that secure commerce on the net, under bureaucratic constraints, is a risky proposition indeed.

-Lewis McCarthy <lmccarth@cs.umass.edu>
[Copies of the message from Damien.Doligez@inria.fr sent to cypherpunks@toad.com were forwarded to RISKS by Lewis, and by <elfchief@lupine.org>, Arve Kjoelen <akjoele@shiva.ee.siue.edu>, cdash@ludell.uccs.edu (Charlie Shub). I do not include the Doligez message and a lot of ensuing discussion. Also, I am told that a British team actually beat out Damien by a few hours. PGN]

Netscape security

Peter Shank <shank@netscape.com>
Thu, 17 Aug 1995 08:44:45 -0700

Late Tuesday evening a person from France posted a news article to the hacker community claiming success at decrypting a single encrypted message that had been posted as a challenge on the Internet sometime on or before July 14, 1994. His response to the challenge is described in an email that has been forwarded widely across the Internet.

What this person did is decrypt one encrypted message that used RC4-40 for encryption. He used 120 workstations and two parallel supercomputers for 8 days to do so. As many have documented, a single RC4-40 encrypted message takes 64 MIPS-years of processing power to break, and this roughly corresponds to the amount of computing power that was used to decrypt the message.

Important points to understand:

  1. He broke a single encrypted message. For him to break another message (even from the same client to the same server seconds later) would require *another* 8 days of 120 workstations and a few parallel supercomputers. The work that goes into breaking a single message can't be leveraged against other messages encrypted with other encryption keys.
  2. The standard way to determine the level of security of any encryption scheme is to compare the cost of breaking it versus the value of the information that can be gained. In this case he had to use roughly $10,000 worth of computing power (ballpark figure for having access to 120 workstations and a few parallel supercomputers for 8 days) to break a single message. Assuming the message is protecting something of less value than $10,000, then this information can be protected with only RC4-40 security. For information of greater value, currently available RC4-128 security should be used.
  3. Inside the US, software can support a range of stronger encryption options, including RC4-128, which is 2^88 times harder to break. Meaning that the compute power required to decrypt such a message would be more than 1,000,000,000,000 (trillion) times greater than that which was used to decrypt the RC4-40 message. This means that with foreseeable computer technology this is practically impossible.
So in conclusion, we think RC4-40 is strong enough to protect consumer-level credit-card transactions -- since the cost of breaking the message is sufficiently high to make it not worth the computer time required to do so - -- and that our customers should use higher levels of security, particularly RC4-128, whenever possible. This level of security has been available in the U.S. versions of our products since last April. Because of export controls it has not been available outside the U.S. We would appreciate your support in lobbying the U.S. government to lift the export controls on encryption. If you'd like to help us lobby the government send email to export@netscape.com.

Finally, we'd like to reiterate that all this person has done is decrypt one single RC4-40 message. RC4 the algorithm and products which use the algorithm remain as secure as always.


NIST crypto announcement on export controls and key escrow

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 18 Aug 95 9:10:51 PDT

Contact: Anne Enright Shepherd (301) 975-4858

COMMERCE'S NIST ANNOUNCES PROCESS FOR DIALOGUE ON KEY ESCROW ISSUES

Furthering the Administration's commitment to defining a workable key escrow encryption strategy that would satisfy government and be acceptable to business and private users of cryptography, the Commerce Department's National Institute of Standards and Technology announced today renewed dialogue on key escrow issues.

A Sept. 6-7 workshop will convene industry and government officials to discuss key escrow issues, including proposed liberalization of export control procedures for key escrow software products with key lengths up to 64 bits, which would benefit software manufacturers interested in building secure encryption products that can be used both domestically and abroad.

Key escrow encryption is part of the Administration's initiative to promote the use of strong techniques to protect the privacy of data and voice transmissions by companies, government agencies and others without compromising the government's ability to carry out lawful wiretaps.

In a July 1994 letter to former Rep. Maria Cantwell, Vice President Gore said that the government would work on developing exportable key escrow encryption systems that would allow escrow agents outside the government, not rely on classified algorithms, be implementable in hardware or software, and meet the needs of industry as well as law enforcement and national security. Since that time, discussions with industry have provided valuable guidance to the Administration in the development of this policy. For example, many companies are interested in using a corporate key escrow system to ensure reliable back-up access to encrypted information, and the renewed commitment should foster the development of such services.

Consideration of additional implementations of key escrow comes in response to concerns expressed by software industry representatives that the Administration's key escrow policies did not provide for a software implementation of key escrow and in light of the needs of federal agencies for commercial encryption products in hardware and software to protect unclassified information on computer and data networks.

Officials also announced a second workshop at which industry is invited to help develop additional Federal Information Processing Standards for key escrow encryption, specifically to include software implementations. This standards activity would provide federal government agencies with wider choices among approved key escrow encryption products using either hardware or software. Federal Information Processing Standards provide guidance to agencies of the federal government in their procurement and use of computer systems and equipment.

Industry representatives and others interested in joining this standards-development effort are invited to a key escrow standards exploratory workshop on Sept. 15 in Gaithersburg, Md. This workshop is an outgrowth of last year's meetings in which government and industry officials discussed possible technical approaches to software key escrow encryption.

The Escrowed Encryption Standard, a Federal Information Processing Standard for use by federal agencies and available for use by others, specifies use of a Key Escrow chip (once referred to as "Clipper chip") to provide strong encryption protection for sensitive but unclassified voice, fax and modem communications over telephone lines. Currently, this hardware-based standard is the only FIPS-approved key escrow technique. NIST officials anticipate proposing a revision to the Escrowed Encryption Standard to allow it to cover electronic data transmitted over computer networks. Under this revised federal standard, the Capstone chip and other hardware-based key escrow techniques developed for use in protecting such electronic data also will be approved for use by federal agencies.

As a non-regulatory agency of the Commerce Department's Technology Administration, NIST promotes U.S. economic growth by working with industry to develop and apply technology, measurements and standards.

Note to editors: Readers who are interested in obtaining more information about the workshops can contact Arlene Carlton, (301) 975-3240, fax: (301) 948-1784, e-mail: carlton@micf.nist.gov.


Intel Warns of Marred Motherboards (Edupage, 17 Aug 1995)

Edupage <info@ivory.educom.edu>
Thu, 17 Aug 1995 21:40:11 -0400

Intel and other computer companies are trying to determine the extent of problems caused by a flaw in an RZ-1000 EIDE controller chip that's included in some early PCI motherboards manufactured by PC Tech. The flaw was discovered in 1994 and was corrected through a software "patch," but the latest version of OS/2 disables that patch. (Investor's Business Daily 16 Aug 95 A15)

[I thought perhaps the SUBJECT line was a typo, and that we would now have to worry about UNmarried motherboards. PGN]

The traffic light does NOT think

Torsten Ihle <ihle@iki101.inf.tu-dresden.de>
Thu, 17 Aug 1995 11:15:50 +0200

The following is my rough translation of the article "Die Ampel denkt nicht" I just read in the German weekly newspaper "Zeit" from August, 11 1995, p.12.

The "intelligent street" - a foolish flop
The traffic light does not think

Stuttgart. - There is no doubt about it, there are intelligent traffic lights. They do recognize, when to switch from red to green. Also, an electronic display exhibits intelligence, if it alerts us about a traffic jam 15 kilometers (km) ahead. Indeed, our traffic signs become more and more intelligent. We report on an experiment to replace the common sense of a driver by traffic signs - a failed experiment, though.

At April 29th 1995 the federal minister for traffic and transportation, Matthias Wissmann, and the state minister for traffic and transformation of Baden Wuertemberg, Hermann Schaufler, pressed a little green button: The "traffic control (literally influence) machinery" at the federal street 27 in the south of Stuttgart started to work. A pilot experiment at a length of 18 km was supposed to end the brass-age: Instead of stupid speed-limit 80 km/h signs in the future there will be "variable speed limits" thanks to "automatic video sequence processing", "radar technology" and "computer based computational methods". The small group was sure: this was the advent of the "intelligent road".

The drivers at this heavily frequented segment got a different impression the other morning. The DM 14.000.000 equipment suggested a speed limit of 120 km/h - during a traffic jam. And during the way home at the evening the super device surprised onece again: It did rain cats and dogs, which triggered the highly sensitive sensors to announce "wet street".

The obvious flop made the ministry of traffic and transportation to stick red crosses over the displays. At July 19th started the second trial. Since then it is allowed to race. Where in former times a speed limit of 80 km/h was in effect for noise and emission reduction, the computer did allow 120 km/h, in non urban areas there was no speed limit at all. Some days ago a vespa-driver fell down, causing a jam, but the "light fiber optical traffic sign" did suggest 120 km/h. Fortunately, the drivers thought it over and did brake. Police and city authorities stopped the madness. Due to their protests, the installation displays constantly 100 km/h in the city area.

There is a saying around Stuttgart: "With 40 the Swabian becomes sensible, others not in eternity". Why should a traffic installation make a difference.

Phillip Mausshardt

This "translation" is not to be considered as a contribution to the intellectual heritage of this century (due to my limited ability to use the English).

There are, however some reports on successfully installing such devices, namely by Kuehne et. al., e.g. in:

Kuehne, R.D. and Roediger, M.B. Macroscopic simulation model for freeway traffic with jams and stop-start waves. In: Proceedings of the 1991 Winter Simulation Conference, pp 762-770

For the interested (and German reading), I can provide more references. I do not know, however, which research team was involved with the traffic control system described above.

Torsten Ihle, Dipl. Inf., TU-Dresden ihle@iki101.inf.tu-dresden.de

Stale accounts and lifestreams (Frankowski, RISKS-17.26)

Martin Ewing <martin.ewing@yale.edu>
Wed, 16 Aug 1995 00:09:49 -0400

Dan Frankowski's account (RISKS-17.26) of problems with an old frequent flyer account points up a new generic risk: Our electronic "shadows" accrete all kinds of data over a lifetime. Apart from the problem of bad guys getting access, it is rather difficult for us to retrieve our own data. In addition to stale f.f. accounts, we may need to get tax records, Social Security income data, house purchase and repair cost information, investment cost, etc., sometimes back to day zero.

Dave Gelernter at Yale has developed a "lifestream" database model which would capture and organize (by date, as I understand it) all your electronic data, starting with your birth certificate. In addition to all your financial transaction data, there would be all your e-mail, significant images, school homework, all the versions of all the programs you ever wrote, etc. We can imagine carrying this all around on an optical disk in your wallet or on a super smart card. (How much of it should be accessible to other parties like the IRS or to legal subpoena is an interesting question. Encryption might be a good idea, if you can remember a key throughout your whole life!)

I don't know if a comprehensive personal "lifestream" is going to be available any time soon, but the technology is almost there. As a concept, it may help to sharpen our ideas about electronic risks. It certainly would help to find that old account number.

Martin Ewing, Yale Science & Engineering Computing Facility
<martin.ewing@yale.edu> http://minerva.cis.yale.edu/~ewing

Re: Insisting on explanations for failures (Kamens, RISKS-17.26)

Paul C. Kocher <pck@netcom.com>
Tue, 15 Aug 1995 23:54:09 -0700

Dell specializes in selling inexpensive computers. Customers who want the cheapest hardware are going to have to face some extra risks, such as the chance of failing to be notified about a buggy BIOS.

Few software companies provide toll-free support, but I don't think this is necessarily bad. I would often prefer paying $50 for a program with minimal support over spending $100 for the same program with better support. Books, third parties, toll- call support, etc. can provide support if I don't mind paying slightly more.

There are risks everywhere, and we have to decide how much effort and money to invest in avoiding them. In the case of the PC clone industry, there are many suppliers and the market is extremely competitive, so consumers can decide whether the risks associated with choosing a low-cost supplier are worth taking.

Don't get me wrong; I'm not recommending that market forces set safety standards, but I also don't think it's necessarily bad that companies cut some corners in order to provide more competitive prices.

Paul Kocher pck@netcom.com (formerly kocherp@leland.stanford.edu)

The MSN is Hacker Heavan

<andyc@praxiss.demon.co.uk>
Fri, 18 Aug 1995 08:34:28 -0700

[Below is an article, forwarded with the authors permission. The risks are obvious. I wonder how the risks can be reduced. Andy Chesterton]

As most of us are aware, the commercial online services, such as AOL, Compuserve and Prodigy, represent certain risk to the unsophisticated user. Unfortunately, the Microsoft Network (MSN) raises the vulnerability of such users to unprecedented heights.

Key to this vulnerability is the richness and complexity of the MSN/Windows 95 environment. What is most dangerous is the ability for the author of an e-mail or (certain) BBS documents to embed "objects" in that document. These objects can be readily disquised to appear totally benign to the casual user and be nothing more than MSN navigational aids. Once double-clicked by the recipient, these objects can readily infect the recipient's PC with a virus. Worse, what this object could do is only limited by one's imagination. It is worthwhile noting that MSN appears to be migrating to an open architecture, with the MSN user connecting through the Internet. If this is true, there is nothing which prevents an object, once activated, from transmitting information stored on the user's PC to any other location on the Internet.

In theory, embedded objects can be interrogated to ensure their validity. Unfortunately, this interrogation process is not likely to be carried out by the average user. Even if it is, the user is not likely to understand what they are looking at. It is like warning automobile drivers to look under the hood of their car before starting it to make sure there is not a bomb inside. Most drivers would assume that the odds were with them. Those that did check would have no idea what they were looking at. (At least that's my feeling when I look under the hood of my car :-).

Microsoft's position appears to be that the MSN user is no more vulnerable than one who uses a competing system. I would maintain that this position is just not true. With system complexity comes excessive vulnerability. MSN rates a 9 in complexity. The other services a 4.

The bottom line: Users of MSN are placing themselves at significant risk. If one must use MSN, avoid at all cost activating (double-clicking) objects in e-mail messages and BBS posts. Sophisticated users may think they know what they are doing, but it probably won't be long before they are outwitted by someone who figures out how to totally disguise an object's true purpose.

-Mike Wyman wyman@tiac.net

Windows 95 Registration Wizard confusion

<enh-a@ugrad.cs.york.ac.uk>
Thu, 17 Aug 95 12:05:30

It strikes me reading these articles on RISKS that someone has confused two Microsoft products. Microsoft SMS (Systems Management Server) collects information about the machines on a corporate network to aid administration. In particular, it collects autoexec.bat and config.sys files, and identifies "packages" installed on the machines (these packages and how they're recognised is configured by the administrators).

I'd guess that someone's been reading too many press releases and blurred the Windows 95 Registration Wizard with the SMS inventory. One of the risks of having so much advertising material flying around...

Elliott

Re: Air-traffic control power struggles continue

Sergio Gelato <gelato@oort.ap.sissa.it>
Wed, 16 Aug 1995 13:16:41 +0200

> radius of about 357 square miles,

Since when are radii measured in SQUARE miles?

[THANKS. I was thinking of making something out of ROUND miles instead of SQUARE miles, and forgot to go around the square. PGN]

[Also noted by "Michael J. Chinni, (AMSTA-AR-IMN)" <mchinni@PICA.ARMY.MIL>, and John Pearson <john@huiac.apana.org.au>. There may have been others as well. Perhaps it was an inadvertent test to see who is reading carefully... PGN]


What is reality anyway? Re: Which risks to fight first?

Peter da Silva <peter@nmti.com>
1 Aug 95 21:27:59 GMT (Tue)

From: Raymond.Turney@ncal.kaiperm.org
> The reason for the interest in the effects of the Internet and VR
> technology is simply that they are unknown. People are reporting problems
> with "Internet addiction", and as an old gamer I can see where there might
> be a problem with people preferring VR flight simulators to their real
> lives.

One thing that has been happening throughout history is that the sorts of activities considered to comprise people's "real lives" have changed, over and over again. How would a hunter-gatherer or a primary farmer or a medieval villein or a monk view our "real lives" today?

Except for a minority we're pretty much out of touch with nature, with the divine, even with our livelihood. We don't hunt, harvest, butcher, or otherwise gather or process our own food. Hardly any of us engage in daily prayer. I assume that most readers of this forum don't believe in the literal truth of our scriptures the way people did only a few hundred years ago.

By the standards of most of history, we're hopeless technology addicts today.

We shouldn't be so quick to judge people who prefer VR to their "real lives".

How real is *your* life? I know when we've got a project in house my life six days a week consists of work 9AM to 9PM, living in a reality of cables and backups and little antique-white squares on a pleasant lilac background.

Peter da Silva Network Management Technology Incorporated
1601 Industrial Blvd. Sugar Land, TX 77478 USA +1 713 274 5180

Re: Ten years still too soon to tell (Turney, Risks-17.22)

Mark Brader <msb@sq.sq.com>
Tue, 1 Aug 95 21:51:21 EDT

> To see why, consider the history of nineteenth-century railroading.

And it was also apparent how to avoid a large part of the problem. Use broader gauge tracks -- move the rails farther apart -- in relation to width the cars. In Britain, the Great Western Railway was built with tracks of 7' or 7'0.25" (2134-2140 mm) gauge, where others chose the 4'8.5" (1435 mm) that soon afterward became the standard. But the GWR's passenger cars were almost the same width as their competitors'. When involved in a derailment or collision, they almost always *stayed upright* -- so unless the car was actually smashed, people would not likely be trapped inside it.

Of course, there is no computer relevance whatever to this story of a system that was technically superior in safety and other respects, but which lost out to one that was more common and cheaper.

Mark Brader msb@sq.com SoftQuad Inc., Toronto
This article is in the public domain.


Privacy Digests

<RISKS-request@csl.sri.com>
17 August 1995

Periodically I will remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern.

There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing detailed discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available.
PGN

Please report problems with the web pages to the maintainer

Top