Subject: RISKS DIGEST 16.53 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Sunday 6 November 1994 Volume 16 : Issue 53 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks), disclaimers ***** Contents: UK boy cracks S.Korean system (Mich Kabay) CMU blocks access to nasty newsgroups (Mich Kabay) Roll-Over Date Frozen? (Ed Ravin) Followup on Sears captures signatures (Steve Holzworth) Minnesota driver license (Daniel Frankowski) Re: CAPS-LOCK Considered Harmful (Jim Griffith) RFD: sci.engr.safety (Sethu R Rathinam) 2nd Conf. on Mathematics of Dependable Systems (Victoria Stavridou) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 06 Nov 94 15:46:40 EST From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: UK boy cracks S.Korean system >From the Reuter newswire (94.11.04) via CompuServe's Executive News Service: RTw 11/04 0417 S. Korea says slim chance hacker got nuclear data By David Brunnstrom SEOUL, Nov 4 (Reuter) - The South Korean atomic energy institute said on Friday there was a slim possibility a teenage British computer hacker stole secret nuclear data from its computer system. The Korea Atomic Energy Research Institute (KAERI) said it was investigating possible damage to its system after a report in the Washington Times newspaper on Thursday [94.11.03] which said the hacker managed to access it recently. The article goes on to make the following key points: o "James Christy, director of computer crime investigation at the U.S. Air Force's office of special investigations," speaking "at a conference on global organised crime convened by Washington's Center for Strategic and International Studies," said that "Data Stream" was a 16 year old in Britain. o The youth cracked a system at the Rome Air Development Center at Griffith Air Force Base in Rome, New York state. o He copied files from the "South Korean Atomic Research Institute (sic)" to the disks on the Rome system. [SKARI?] o The youth "curled up into a foetal position and cried when" the British police arrested him. o KAERI officials said that technical information "such as that on reactor systems and fuel rod design" was "stored separately from other data and protected by multiple passwords." o "Chung Joon-keuk, director of public information at the institute,....said .... it was still not clear whether the institute referred to in the Times was in fact KAERI and it was possible the article should have referred to the Korea Aerospace Research Institute (KARI)." M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn ------------------------------ Date: 06 Nov 94 15:46:49 EST From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: CMU blocks access to nasty newsgroups >From the United Press Intl newswire via CompuServe's Executive News Service: UPn 11/04 1054 College blocks computer sex access PITTSBURGH, Nov. 4 (UPI) -- Carnegie Mellon University of Pittsburgh said Friday it will block access on its campus computer system to sexually explicit material available on the worldwide computer network called the Internet. Carnegie Mellon officials said they are acting out of concern that the university could by subject to prosecution under Pennsylvania's pornography and obscenity laws. The article goes to to explain that University spokespersons admit they will be "be accused of stifling free expression" but feel that the risks are too high, especially since children can easily access these materials. The decision was said to have been difficult and painful for the administrators, who strongly support the tradition of academic freedom. The decision was criticized by a student spokesperson, who compared it to banning books. [Comments by MK: The anonymity of the Internet will continue to cause difficult problems related to access by children. Right now, the response of well-meaning administrators and others is to put blanket restrictions on everyone so as to prevent unsupervised use of the Internet by minors. Imagine a world where no one had developed the concept of an ignition key for automobiles. We can imagine well-meaning highway administrators concerned with access to the high-speed transportation infrastructure exclaiming, "Gosh, but with these highways and cars, children could travel to (gasp) brothels and pigsties! They could see things that their parents would never want them involved in." And so the highway administrators would shut down roads in an attempt to prevent access to bad places by children. In both the real world and this imaginary world, these difficulties are caused by the lack of identification and authentication in accessing the highways. In the real world, we have ignition keys for automobiles and severe penalties for stealing automobiles or driving without a permit. We have no accepted standards for access to networks. Parents who are concerned about access to a network by their children could take the responsibility of locking their computers or their modems. However, that's a pretty crude approach too--all or nothing. And what about the children's independence and growth? There are already devices available for controlling access to television; parents program the times, channels and duration of viewing permitted for their children, who punch in a PIN to gain personally-tailored access to the TV. Maybe as Internet access grows, there will arise sufficient interest and demand for menu systems for access to the Internet. Parents could select the sections of the Internet which they wish to allow for their children; children and parents could explore the Internet together and add or remove destinations and newsgroups as they see fit. Right now, CompuServe has access to Internet newsgroups. The administration has settled on a middle ground in restricting access to the Internet by limiting the _listings_ of newsgroups. In fact, however, if someone already knows the name of a newsgroup, they are free to subscribe even if it isn't listed. I think that we have to move beyond a crude TOTAL ACCESS / NO ACCESS dichotomy in regulating access to the Internet. We need finer granularity in our restrictions so that we don't infringe on the rights of adults. A final note. In a recent thread on the NCSA FORUM on CompuServe, there was a discussion about whether there were mechanisms for restricting BBS and Internet access by children. I answered, "Yes--one is PARENTAL RESPONSIBILITY."] M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle PA) ------------------------------ Date: Tue, 1 Nov 1994 13:15:13 -0500 From: Ed Ravin Subject: Roll-Over Date Frozen? Another one for the "date-dependent" bugs collection: Last month, all five hundred or so Fujitsu model SRS-1050 ISDN display phones here at Prodigy suddenly stopped their clocks at 11:59 PM September 30. [Typoed 31 fixed. PGN] The problem seems to be that the built-in clock on the phone freezes when trying to roll over into the first day of a two-digit month. Resetting the clock/calendar to the current date and time fixes the problem until the next month rolls around. While the clock is in its "stuck" state, the "message waiting" light will never go on, no matter how many voice mail messages are waiting for you (you still get the "stutter" dial tone, though). These phones were newly installed in December of last year -- their EPROMS are dated November 1993. Apparently this bug crept in around then and has been installed in all Fujitsu phones of that model since. I'm told the manufacturer will need to replace tens of thousands of EPROMs in the field for their various business customers who have deployed these phones. The new EPROMs will be tested by an outside company before being delivered to the customers. Until then, we need to manually reset our phones on November 1 and December 1. Previous RISKS reports of date bugs were usually overflows of 16 or 8 bit quantities -- is this a new record in lower limits? Ed Ravin, Prodigy Services Company 445 Hamilton Avenue White Plains, NY 10601 +1 914 448 4737 elr@wp.prodigy.com ------------------------------ Date: Mon, 31 Oct 1994 18:44:44 -0500 (EST) From: Steve Holzworth Subject: followup on Sears captures signatures Since my original post concerning Sears now digitizing signatures when you sign a credit card slip, bunches of people :-) have sent me Email, either asking for elaboration on the risks involved, or adding anecdotes of their own. I'll attempt to describe the potential risks as I see them. Summary of previous post: Sears in my area has recently started asking for people to sign their credit card receipts while the receipts are on what is obviously a small digitizing pad. Sears doesn't make it obvious that this is the function of the device. You can refuse to sign on the tablet. They'll probably have to call someone first to OK it. Potential Risks of digitized signatures: Capturing the act of signing gives the store more information than simply scanning a copy of a signed receipt would. In addition to the basic image of the signature, the tablet can also effectively record stroke information (direction of strokes, and possibly, pressure of strokes). This is important, because given stroke information, it is almost trivial to write a program to fake a signature with a pen plotter. Simply use the stroke points as control points for spline curves. Said control points can then be perturbed slightly to yield what appears to be the same signature STYLE, without being a direct copy of an existing signature. Of course, Sears wouldn't do anything so stupid. However, once the data is available, a disgruntled or entrepeneurial employee could sell the data to other parties. Let's see. Bill Gates goes to Sears and buys a screwdriver on his credit card. How much is his signature potentially worth on the market? Or, (for the really paranoid :-) ), some government agency, say, DEA, known to be overzealous at times, decides to "apply" your signature to some incriminating evidence... I don't believe Sears (and others mentioned) can perform dynamic signature verification on the fly. They can't possibly have that horsepower at the terminal (at present). Even simple credit card number verification takes 30 seconds or more. Imagine the complexities of looking up one of N million signatures, correlating it to the new sample, then issuing a go/no-go response in a reasonable time frame. The closest approximation to this so far is the Apple Newton handwriting recognition. It looks in a small (10k words) dictionary, has to be trained to your writing style over time, and still screws up often enough to cause some headaches. How tolerant is your customer base to having their charges denied when they KNOW they wrote a valid signature? More importantly, what REASON can Sears have for wanting this information? I proposed that they can't do anything useful with it yet, so why should we let them have it? Further, to the best of my knowledge, no credit card provider requires card owners to supply digitized signature information when initiating a transaction. My understanding is that, per the card issuer agreement with the merchant, the merchant CANNOT require ANY other identifying information, assuming they get an approval code from the card issuer. Keep in mind, you don't even SIGN a receipt for a mail-order purchase... Why should we let Sears et al digitize our signatures? One limited use of a digitized signature could be to display a specimen of your signature on POS terminal so the clerk can compare with your receipt. Of course, that is supposedly what the signature on the back of the card is for (among other things)... One responder mentioned that if the customer was signing paper on top of a tablet, it was unlikely that much information could be captured beyond stylus pressure. This is incorrect. I developed high-end CAD software for civil engineering and land planning for many years. All of the digitizers we used were capable of capturing positional information through quite a number of layers of vellum, mylar, and/or paper. This was necessary because much of engineering work involves tracing existing maps or drawings. Several responders stated that they had run into similar digitizers at Sears, Service Merchandise, and others. A few stated that my example of refusing to sign had encouraged them enough to "just say no" :-) next time. I'm not trying to be paranoid, but I attempt to see all of the angles when confronted with a situation as described above. I operate under the rule that unless you can give me an extremely good reason why I should give you some class of information about me, you don't get it. Numerous posts to RISKS have documented how quickly and easily information about someone is disseminated, and how difficult it is to correct misinformation, once it gets spread. I attempt to minimize acquisition of the information as a preemptive measure. Steve Holzworth SAS Institute x6872 SAS/Macintosh Development Team Cary, N.C. sch@unx.sas.com ------------------------------ Date: Fri, 4 Nov 1994 15:55:56 -0600 (CST) From: dfrankow@winternet.com (Daniel Frankowski) Subject: Minnesota driver license *City Pages*, a great free news weekly here in the Twin Cities (Minnesota USA), recently had an article [1] chock full of privacy issues and implications of the new Minnesota driver license (not "driver's" but "driver" on our license). I approached the article with deep suspicions about a new card, and came away only slightly less suspicious. The old license has been the same for 25 years. It has a picture, a license number and some personal information (address, height, weight, signature, birthdate, etc.). .. [O]fficials were tired of the ease with which the old card could be forged and altered. In early 1990, local police officials uncovered a forgery ring in the Twin Cities that used fake Minnesota licenses to open bank accounts and pass close to $1 million worth of bad checks. To make it harder to forge, the new card is printed in several fonts and the location of your (digitized and stored) picture depends on your age. For the information age, there is a barcode with your driver license number, and a magnetic stripe that can contain three lines of about 80 characters each, currently slated to contain a person's full name, date of birth, and driver license number. The article raises a plethora of issues, some of which follow. I have hastily tried to put them into categories, which unfortunately overlap. INFORMATION HANDLING RISKS - The state government assumes that the public should trust government agencies with these technologies. This resulted in a lack of public discussion or input because the government did not publicize the new card proposal. The article gave an example I had not heard why we should not trust government: upon dishonorable discharge from the US military, it assigned a code which potential employers and others could get. 257 meant "unfitness, homosexual acts," 261 was "psychiatric or psychoneurotic disorder," 287 was "unclean habits including venereal disease," and 289 "unsuitability, alcoholism." - Currently, the Driver Vehicle Services (DVS) department makes all their information public except social security number and medical information. That is, registration and title info, driving records, and the personal information from your license. The state sells it ("provides it for a fee"), and currently has 600 online accounts (presumably customers buying the information). They can sort by age, area, or size of person, for example. - The card is a universal identifier, a notion often reviled in RISKS. - The article mentions a national database of 7 million commercial drivers (only truckers?) called (and operated by) AAMVANET which went online January 1989. It contains each person's name, date of birth, social security number, and physical descriptors. "It was mandated by the federal government because truckers were getting licensed in multiple states to avoid suspensions." Barry Goleman is the president of AAMVANET, Inc., a subsidiary of the American Association of Motor Vehicle Administrators. "Goleman says that in the future, the system will include all drivers-- currently a total of 160 million, nationwide." - The license may be linked to issues unrelated to driving. In Wisconsin, your license may be suspended for failing to pay public fines. The article's example is a late book fine at the public library. RISKS OF SUDDENLY SWITCHING TECHNOLOGIES - The company producing them (Deluxe Check Corporation, big in Minnesota) promised quicker turnaround for new licenses, but their digitizing cameras overheated, and their incompatible transmission protocols lost about 4000 new pictures which have to be retaken. RISKS OF MAGNETIC STRIPES Goleman (see above) said "upward of" 22 states have magnetic stripe-reading technology for driver licenses already. - You, the card holder, cannot easily read the magnetic stripe to ensure that there are no mistakes because a special machine is required. - Businesses could modify credit card readers to read the license stripe "ostensibly to verify ID" and build databases of shopping habits and personal information. - Minnesota businesses are trying to get extra information put on the magnetic stripe. - A state group proposed distributing AFDC (welfare) money. The article hypothesized the card could be used (say) to track your location. Comments: At first, I was impressed with the fact that all information in the barcode and magnetic stripe would also be visible on the card. In other words, no hidden information. However, other points listed above drained away my relief. I noted a fatalism about the article: it catalogued frightening consequences without proposing solutions or interviewing privacy experts. This seems typical of even good journalism these days. So are there simple guiding principles about the use of information for a driver license? Would it be a good idea to pass a law requiring cash machines to be able to display (for free) any information on a magnetic stripe given the appropriate PIN #? How else can we solve the problems above? 1. Card Blanche, Jennifer Vogel, City Pages, Vol 16, No 725, October 26, 1994, pages 15-20. Dan Frankowski dfrankow@winternet.com ------------------------------ Date: Mon, 31 Oct 1994 16:05:19 -0800 From: griffith@netcom.com (Jim Griffith) Subject: Re: CAPS-LOCK Considered Harmful (Massey, RISKs-16.51) >IMHO, the worst button-placement crime is one almost every >computer manufacturer for the last 20 years has perpetrated: >the CAPS-LOCK key on the keyboard. This "risk" is made worse by the fact that different interfaces cause users to hack their way back to familiarity. We're currently having that problem at work, because our three-member UNIX team was imported intact from a SPARCstation shop to an HP-UX shop. SPARC keyboards have the caps lock in the "standard" position, while HP's stick the caps lock in the CTRL position and the CTRL key beneath the shift key (standard PC configuration). And each of us have addressed this in different ways. One user has learned the new keyboard, one user has simply switched the internal mapping for CTRL and CAPS using xmodmap (without relabelling the keys), and the third switched the mapping while also moving the ESC and a couple of other keys. The end result is that we can't use each other's machines without sacrificing as much as 25% efficiency (UNIX and vi being as CTRL-driven as they are). We have yet to see a case where this caused an unrecoverable disaster, but it's surely just a matter of time. Jim Griffith griffith@netcom.com [RISKS received a ton of responses on this subject. Sorry we can't use them all -- our readership would probably get totally fed up with me. PGN] ------------------------------ Date: 3 Nov 1994 15:32:41 -0500 From: rathinam@ins.infonet.net (Sethu R Rathinam) Subject: RFD: sci.engr.safety REQUEST FOR DISCUSSION (RFD) SCI.ENGR.SAFETY Name : sci.engr.safety Status : unmoderated Distribution : World Summary : Safety of Engineered Systems Proposed by : rathinam@ins.infonet.net (Sethu R Rathinam) Proposed Charter: This newsgroup is being proposed as an open forum to discuss safety issues of systems built by humans. All aspects of safety relating to the risk of (or actual) loss of human life, loss of non-human life and/or property fall within this charter. Safety issues and concerns relating to all phases in a product's life cycle as well as discussions of Regulatory Issues and System Safety Processes and Software issues relating to safety fall within this charter as well. Since various Engineering disciplines are involved, it is recommended the subject line be a clear reflection of the subject matter. Factual posts and informed discussion is encouraged and speculation should be kept to a minimum. Rationale: There is presently no group with a primary focus on safety, though various newsgroups discuss safety issues within the (relatively narrow) scope of that group. A more focussed group for safety will help people from one discipline have more visibility to safety issues and practices of other disciplines. Other: Newsgroup line "All aspects of Safety of Engineered Systems" Cross Postings: [This RFD is cross posted to many others. Please excuse duplication.] Voting process This is the Request For Discussion. There will be a 30 day discussion period (discussion will happen in news.groups - followup is set correctly, so if you follow-up to this message, your posting will appear in news.groups). This RFD may be modified incorporating suggestions, if required, during this period. If there is no serious disagreement, a Call For Votes (CFV) will be issued by a third party. The CFV will last between 21 and 31 days (as announced by the third party vote taker). Please follow the instructions of the vote taker when we get to that point in time. For the group vote to pass, there should be 100 more YES (create) votes than NO (don't create) votes AND at least two thirds of the valid votes are in favor of creation of the group. Sethu R Rathinam rathinam@ins.infonet.net ------------------------------ Date: Mon, 31 Oct 1994 21:32:54 -0800 From: Victoria Stavridou Subject: Mathematics of Dependable Systems THE INSTITUTE OF MATHEMATICS AND ITS APPLICATIONS 2ND CONFERENCE ON THE MATHEMATICS OF DEPENDABLE SYSTEMS (MDS 95) 4-6 September 1995 University of York, England ANNOUNCEMENT AND CALL FOR PAPERS The construction of dependable systems, by which we mean systems providing high levels of reliability, availability, safety and/or security, is a problem of considerable concern to both providers and users of information processing systems of all types. Historically, different aspects of system dependability (e.g. reliability and security) have been studied quite independently, albeit that many of the goals are similar. For example, the notion of certifying functionality assurance levels applies equally to reliable systems and secure systems. In addition, users will often require some combination of security and fail-safe operation. The purpose of MDS 95 is to consider the mathematical aspects of the provision of dependable systems, one goal being a comparison and possible unification of mathematical techniques for providing safe, reliable and secure systems. A number of different mathematical approaches have been taken to the overall problem, including probabilistic/statistical reasoning, formal models of safe, secure and reliable systems and logics of authentication and access control/privilege delegation. Papers on all these areas are solicited, the unifying theme being the application of mathematical techniques to the overall dependability problem. Hence papers will be particularly welcome which cross-fertilise the application domains. The conference will consider dependability for both hardware and software systems. PROGRAMME & PROCEEDINGS The conference will consist of three days of presentations by contributing authors. The programme will also include invited lectures by prominent researchers and practitioners in dependable systems theory and practice. Time will be made available for discussions. A digest of papers will be available to participants during the meeting and the proceedings will be published after the conference. INVITED SPEAKERS Monsieur P Chapront (GEC Alsthom, France), Professor J Knight (University of Virginia, USA) and Professor D L Parnas (McMaster University, Canada). SUBMISSIONS Five copies of complete papers (in English) should be sent to Mrs Pamela Bye, Conference Officer, The Institute of Mathematics and its Applications, 16 Nelson Street, Southend-on-Sea, Essex, SS1 1EF, England (Tel. +44 702 354020, Fax +44 702 354111, Email imacrh@v-e.anglia.ac.uk) by 31st March 1995. Authors will be notified of the outcome of their submission by 26th May 1995. Revised manuscripts will be due by 14th July 1995. Papers must not exceed 6,000 words in length (with full-page figures counted as 300 words). Each paper should include a short abstract and a list of keywords for subject classification. All papers will be refereed and the final choice will be made by the programme committee on the grounds of relevance, significance, originality, correctness and clarity. Submitted papers must not be published or be under consideration for publication elsewhere in the same or similar form. PROGRAMME COMMITTEE Programme Chair : V Stavridou (Royal Holloway, University of London), D Gollmann (Royal Holloway, University of London), M Ingleby (British Rail Research), J Jacob (University of York), N Jefferies (Vodafone Ltd), B Littlewood (City University), R Shaw (Lloyd's Register), B Wichmann (National Physical Laboratory). LOCATION The conference will be held at the University of York, a modern campus built around a lake with excellent facilities. The campus is two kilometers from the centre of the medieval walled city of York, and 60 kilometers from the North Yorkshire coast. The city is also well placed for the Pennines and Yorkshire Wolds. York is very well connected by rail to London, Edinburgh and Manchester and the nearest airports are Manchester and Leeds/Bradford. ------------------------------ Date: 20 October 1994 (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 (which is not automated). 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: or cwd risks:, depending on your particular FTP. Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY 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 . ------------------------------ End of RISKS-FORUM Digest 16.53 ************************