Subject: RISKS DIGEST 17.27 REPLY-TO: risks@csl.sri.com RISKS-LIST: Risks-Forum Digest Friday 18 August 1995 Volume 17 : Issue 27 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Netscape transaction security breached in 8 days by 1 person (Lewis McCarthy) Netscape security (Peter Shank) NIST crypto announcement on export controls and key escrow (Anne Shepherd) Intel Warns of Marred Motherboards (Edupage) The traffic light does NOT think (Torsten Ihle) Stale accounts and lifestreams (Martin Ewing) Re: Insisting on explanations for failures (Paul C. Kocher) The MSN is Hacker Heavan (Mike Wyman via Andy Chesterton) Windows 95 Registration Wizard confusion (Elliott) Re: Air-traffic control power struggles continue (Sergio Gelato) What is reality anyway? Re: Which risks to fight first? (Peter da Silva) Re: Ten years still too soon to tell (Mark Brader) Privacy Digests Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 16 Aug 1995 06:15:17 -0400 (EDT) From: lmccarth@cs.umass.edu Subject: Netscape transaction security breached in 8 days by 1 person 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 [Copies of the message from Damien.Doligez@inria.fr sent to cypherpunks@toad.com were forwarded to RISKS by Lewis, and by , Arve Kjoelen , 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] ------------------------------ Date: Thu, 17 Aug 1995 08:44:45 -0700 From: shank@netscape.com (Peter Shank) Subject: Netscape security 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. ------------------------------ Date: Fri, 18 Aug 95 9:10:51 PDT From: "Peter G. Neumann" Subject: NIST crypto announcement on export controls and key escrow 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. ------------------------------ Date: Thu, 17 Aug 1995 21:40:11 -0400 From: info@ivory.educom.edu (Edupage) Subject: Intel Warns of Marred Motherboards (Edupage, 17 Aug 1995) 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] ------------------------------ Date: Thu, 17 Aug 1995 11:15:50 +0200 From: ihle@iki101.inf.tu-dresden.de (Torsten Ihle) Subject: The traffic light does NOT think 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 ------------------------------ Date: Wed, 16 Aug 1995 00:09:49 -0400 From: martin.ewing@yale.edu (Martin Ewing) Subject: Stale accounts and lifestreams (Frankowski, RISKS-17.26) 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 http://minerva.cis.yale.edu/~ewing ------------------------------ Date: Tue, 15 Aug 1995 23:54:09 -0700 From: pck@netcom.com (Paul C. Kocher) Subject: Re: Insisting on explanations for failures (Kamens, RISKS-17.26) 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) ------------------------------ Date: Fri, 18 Aug 1995 08:34:28 -0700 From: andyc@praxiss.demon.co.uk Subject: The MSN is Hacker Heavan [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 ------------------------------ Date: Thu, 17 Aug 95 12:05:30 From: enh-a@ugrad.cs.york.ac.uk Subject: Windows 95 Registration Wizard confusion 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 ------------------------------ Date: Wed, 16 Aug 1995 13:16:41 +0200 From: Sergio Gelato Subject: Re: Air-traffic control power struggles continue > 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)" , and John Pearson . There may have been others as well. Perhaps it was an inadvertent test to see who is reading carefully... PGN] ------------------------------ Date: 1 Aug 95 21:27:59 GMT (Tue) From: peter@nmti.com (Peter da Silva) Subject: What is reality anyway? Re: Which risks to fight first? 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 ------------------------------ Date: Tue, 1 Aug 95 21:51:21 EDT From: msb@sq.sq.com (Mark Brader) Subject: Re: Ten years still too soon to tell (Turney, Risks-17.22) > 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. ------------------------------ Date: 17 August 1995 From: RISKS-request@csl.sri.com Subject: Privacy Digests 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. * The PRIVACY Forum is run by Lauren Weinstein. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the first text in the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". Information and materials relating to the PRIVACY Forum may also be obtained via ftp to "ftp.vortex.com", gopher at "gopher.vortex.com", and World Wide Web via: "http://www.vortex.com". * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. 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 ------------------------------ Date: 9 August 1995 (LAST-MODIFIED) 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. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to the newly automated , with first text line SUBSCRIBE or UNSUBSCRIBE [with option of E-mail address if not the same as FROM: on the same line]. HELP gives instructions on using the Majordomo listserver in other ways. CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.27 ************************