Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The British government's Department of Trade and Industry has sneaked out
proposals on licensing encryption services. Their effect will be to ban PGP
and much more besides.
I have put a copy on http://www.cl.cam.ac.uk/users/rja14/dti.html as
their own web server appears to be conveniently down.
Licensing will be mandatory:
We intend that it will be a criminal offence for a body to offer
or provide licensable encryption services to the UK public without
a valid licence
The scope of licensing is broad:
Public will be defined to cover any natural or legal person in the UK.
Encryption services is meant to encompass any service, whether provided
free or not, which involves any or all of the following cryptographic
functionality - key management, key recovery, key certification, key
storage, message integrity (through the use of digital signatures) key
generation, time stamping, or key revocation services (whether for
integrity or confidentiality), which are offered in a manner which
allows a client to determine a choice of cryptographic key or allows
the client a choice of recipient/s.
Total official discretion is retained:
The legislation will provide that bodies wishing to offer or provide
encryption services to the public in the UK will be required to obtain
a licence. The legislation will give the Secretary of State discretion
to determine appropriate licence conditions.
The licence conditions imply that only large organisations will be able to
get licences: small organisations will have to use large ones to manage
their keys (this was the policy outlined last June by a DTI spokesman). The
main licence condition is of course that keys must be escrowed, and
delivered on demand to a central repository within one hour. The mere
delivery of decrypted plaintext is not acceptable except perhaps from TTPs
overseas under international agreements.
The effect of all this appears to be:
1. PGP servers will be outlawed; it will be an offence for me to sign your
pgp key, for you to sign mine, and for anybody to put my existing signed
PGP key in a foreign (unlicensed) directory
2. Countries that won't escrow, such as Holland and Denmark, will be cut out
of the Superhighway economy. You won't even be able to send signed
medical records back and forth (let alone encrypted ones)
3. You can forget about building distributed secure systems, as even
relatively primitive products such as Kerberos would need to have their
keys managed by a licensed TTP. This is clearly impractical. (The paper
does say that purely intra-company key management is OK but licensing is
required whenever there is any interaction with the outside world, which
presumably catches mail, web and so on.)
There are let-outs for banks and Rupert Murdoch:
Encryption services as an integral part of another service (such as in
the scrambling of pay TV programmes or the authentication of credit
cards) are also excluded from this legislation.
However, there are no let-outs for services providing only authenticity and
nonrepudiation (as opposed to confidentiality) services. This is a point
that has been raised repeatedly by doctors, lawyers and others - giving a
police officer the power to inspect my medical records might just
conceivably help him build a case against me, but giving him the power to
forge prescriptions and legal contracts appears a recipe for disaster. The
scope for fraud and corruption will be immense.
Yet the government continues to insist on control of, and access to, signing
keys as well as decryption keys. This shows that the real concern is not
really law enforcement at all, but national intelligence.
Finally, there's an opportunity to write in and protest:
The Government invites comments on this paper until 30 May 1997
Though if the recent `consultation' about the recent `government.direct'
programme is anything to go by, negative comments will simply be ignored.
Meanwhile, GCHQ is pressing ahead with the implementation of an escrow
protocol (see http://www.cs.berkeley.edu/~daw/GCHQ/casm.htm) that is broken
(see http://www.cl.cam.ac.uk/ftp/users/rja14/euroclipper.ps.gz).
In Grey's words, ``All over Europe, the lights are going out''
Ross
In the *Globe&Mail*, 27 Mar 1997, p. A6, their Applied Science Reporter tells another story of how governments are fearful of uncontrolled human communications. [MK: Some background: Canada, like the US and Russia, is so wide that many people in the Western areas must vote after vote-counting has begun in Eastern regions. Election officials have long been concerned about the effects of releasing late public-opinion polls and also preliminary vote-counts from the East; they claim (I have never seen any reference to evidence, but this is not my field of expertise) that knowing these data influences the vote by discouraging votes or by changing them. There are therefore strict rules in Canada on what the news media may say in the run-up to the actual vote.] > Elections Canada scrambling to plug cyberspace loophole: > Officials hope to bring election law to the wilds of the Internet. > by Mary Gooderham > Elections Canada is scrambling to jam its finger in the electronic dike. > > Officials have decided that the Internet will face the same rules as other > news media when it comes to disseminating public opinion polls within 48 > hours of election day and releasing vote results early on election night. The reporter makes the following key points: * The Canada Elections Act forbids premature "publishing" voting results by any means. * The 48-hour blackout on advertising by political parties does _not_ apply to the Net. * John Enright, a spokesperson for Elections Canada, said that the Office would investigate and prosecute any breach of the Act, but admitted that actually catching violators who use the Net is "virtually impossible." * Professor John Courtney (political science, University of Saskatchewan) raised the question of whether the Office would try to forbid electronic mail from residents of the east to residents of the west. [Comments by MK: So the bureaucrats are trying to push back the tide again. I expect this sort of nonsense from authoritarians in the PRC, Burma, and so on; it's distressing to see people in Canada uttering such rubbish. What's next, an attempt to stop people in Newfoundland from phoning their friends in British Columbia to safeguard the sacred innocence of Westerners? The problem here is that the Elections Canada officials are stuck in a primitive analogy. Change their view of the Net as a medium for "publishing" to a view that does not try to force the models of the past on the current reality and the problem disappears. The Net is _not_ merely like newspapers, nor merely like a bookstore, nor merely like a fax machine, nor merely like a billboard. These folks need a dose of general semantics: the symbol is not the thing. As Professor Courtney is quoted as saying in the article, "The question is: Does it affect how you vote or whether you vote?" The fundamental issue is not technological: it is whether a government has any business at all controlling what information individuals willingly seek out.] Mich M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com
http://www.zdnet.com:80/intweek/daily/970327x.html Inter@ctive Week March 27, 1997 New Browser Security Flaw Discovered By Will Rodger > Internet browsers set up to protect users' credit card numbers from theft > are unwittingly handing out those numbers to untold numbers of other Web > sites as visitors follow links from those sites to other, insecure ones, > officials from Netscape Communications Corp. and Microsoft Corp. confirmed > Wednesday. The hole, though thus far unexploited, now appears to be the > most serious flaw yet discovered in the way Internet browsers handle > confidential information over the Internet. > "The place people will crack it is not the places people worry about > security but the ones they don't," said Daniel Klein, a Pittsburgh-based > consultant who discovered the hole earlier this month. "This is a big > hole." :: Both MS and Netscape say patches may take weeks to release. > "This is a serious problem," said Eugene Spafford, director of the > Computer Operations, Audit, and Security Technology program at Purdue > University in Indiana. "This isn't a good response because it's not clear > how many other people are going to be impacted by it." > > But Steven Bellovin, a computer security researcher at AT&T Corp. labs, > warned Microsoft and Netscape could find the problem difficult to > surmount. "The reality of software engineering making a quick and dirty > fix to a large program is likely to cause more problems than it fixes," he > said. "First you have to decide what the fix is." [...] > > But if a visitor who has just filled out a secure form then clicks on a > highlighted link to another Web site, all bets may be off. The information > that Web user typed in securely suddenly gets transferred to the logs of > the next machine, credit card numbers and all. :: Server-side remedies include referring visitors to an in-house dummy page to "wipe the browser's feet," or use the POST command instead of GET. > Users finally, can protect themselves by typing in Internet addresses > manually instead of using links from "secure" pages. Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc. [Starkly excerpted by Dave. PGN]
Netscape's JavaScript includes a command, window.open(...), for spawning a new browser window from within a web page. This feature, when combined with the fact the Netscape (by default) will display text/html MIME attachments as regular web pages, can be used to create a denial-of-service attack. A particularly obnoxious individual (let's call him A. User), created an web page containing JavaScript code to spawn an infinite number of new browser windows. Someone visiting this page will immediately see windows popping up all over the screen, with no way to gracefully exit Netscape; it stops responding to keyboard or mouse input while tied up executing the spawn loop. Now, another user (B. User) posted a message to comp.misc, warning people not to visit the offending web page. The problem is that B. User included the document source for the page as a text/html MIME attachment. Anyone viewing the message with the Netscape news reader will immediately execute the spawner. The only way (for me, at least) to stop the errant JavaScript code was to (Unix) kill Netscape. This touches upon RISKs discussed here before, particularly those that involve shipping software with minimal security set as the default. One can imagine a scenario where some malcontent spams several mail addresses with this attachment, with a good chance that an unlucky recipient will be using the Netscape mail viewer in its default JavaScript-enabled mode. This attack mechanism goes some way towards achieving what the "Good Times" e-mail claimed to do in word, if not in deed. I'm now running with JavaScript disabled. The document source is off of A. User's home page at <http://www.olywa.net/jwalker/j0ck.htm> - remember to view it with JavaScript turned off! Ted Wong <tmw5@cornell.edu> Information Technology Section, Mann Library, Cornell University
Was: Risks of random-number servers The notion that the random pool used in a cryptographically secure PRNG "runs out" of entropy is not one I agree with. With a properly-seeded cryptographic PRNG, there shouldn't be any limit to the amount of random material you can produce (unless the crypto function starts failing). A secure PRNG is simply a good stream cipher. Although it's possible to use a one time pad and use as much input entropy as output material, this would be very cumbersome and isn't at all needed for encryption or a PRNG. Instead, the design goal to to make sure that that someone who doesn't know the entire key or PRNG seed cannot distinguish the output from a truly random sequence of equal length with a probability significantly better than guessing randomly. In other words, a well-seeded ryptographic PRNG should be perfect. (In contrast, PRNGs based on physical phenomena often produce output with biases and other major imperfections and really should only be used for seeding cryptographic PRNGs) Not all of the high-speed stream ciphers in use today meet the requirements for being a good PRNG, so care has to be taken when designing or selecting PRNG algorithms. One aso has to make sure to use adequate key lengths (e.g., a single- DES PRNG shouldn't be used to generate triple-DES keys and the PRNG state needs to be big enough!), seed update functions must remix the state completely, the PRNG must not cycle, etc. Other things can also go wrong — for example, several applications have had PRNG failures because one of the most widely-used PRNGs has the property that seeding with seed block "A" followed by "B" is the same as seeding with "B" then "A". Seeding with a large number of low-entropy seed blocks thus produces a PRNG state with much less entropy than would normally be expected. Methods for collecting initial seed data are generally platform- specific and sometimes cause problems in crypto products (though most companies seem to have learned from Netscape's lesson). There are various approaches which can be used for seeding, but I usually combine seed material from three sources: event timing data (keystroke, mouse, etc.), the user's private key (or, better, a hash/HMAC of the private key) combined with the date/time, and state saved from last time the PRNG was used. Any one of the three should be enough to thwart attacks. Throwing in additional data from a random number server wouldn't hurt, though it also doesn't help since the data isn't generated and delivered in a secure enough manner. (You also have to be careful that the random server can't be used to compromise the PRNG!) As I mentioned before, it's usually fine to leave a PRNG alone once it's seeded, though occasionally it's useful to update the PRNG state periodically to ensure that past compromises of the state will get fixed automatically. However, in practice someone who can compromise the PRNG state can often just as easily compromise the PRNG software itself, so this is often overkill and just leads to a false sense of security. Paul
Today's (Thursday, March 27, 1997) LA Times reports on the use of computers in the State Senate — The story begins: >Computers Bring Down Load of Trouble > Money: After spending $1.2 million on laptops, Senate is still relying on > what was to have been made obsolete--paper. > By CARL INGRAM, Times Staff Writer > > SACRAMENTO--In one of his first acts as the new leader of the Senate two > years ago, Bill Lockyer ordered the tradition-bound chamber into the > high-tech age by outfitting all 40 senators with laptop computers at their > desks. But, after spending $1.2 million, the Senate finds itself relying > on what was to have been made obsolete--paper. And goes on to report that at most 10 senators actually use the laptops. The cost was in 2 waves — the first system no one liked ($750K), and the second one ($508K) with "cartoonish" graphics and a touch screen buttons. Complaints include, too hard to read (especially text of bills), and too slow when really needed (everyone needs it at the same time). It also reports the Assembly members are far more accepting of the simpler system installed there. (Available at least today online: http://www.latimes.com/HOME/NEWS/STATE/t000027706.html) Keith Price price@usc.edu
On 28 Mar 1997, a local Washington DC radio station (WTOP) reported that the traffic lights at a downtown intersection (17th and Constitution) were green in all directions at the same time. This was reported by drivers calling in on cell phones, and was apparently recurring over at least a half hour during the rush hour. This is a very dangerous situation given the number of reckless driving incidents in the region over the last few months. I have not yet heard whether any accidents occurred because of this flaw. >From earlier reports on the system, DC uses a sychronization system that "rolls" green lights down the major streets at a rate designed to control traffic. This implies that there is an overall plan to the layout, as manual control of so many lights should be nearly impossible. I'm very curious, given this assumption, as to how this situation occurred in the first place. I can understand that the timings could go into the wrong synchronization if they were being adjusted, but I had always thought that the default behavior in such situations should be to change all the affected lights to flashing red, which means "stop before proceeding". Are traffic light control systems built without this kind of safeguard? David Pipes robear@access.digex.net
(I received this by e-mail in response to the item I posted to RISKS. It is posted here with the author's permission but edited slightly to improve readability.) Date: Thu, 27 Mar 97 16:33:19 >From: "Robt. Miller" <robtmil@prolog.net> Subject: Re: all-ways green lights (DeBert, RISKS-18.94) Last year my family and I were coming home from somewhere or other and at an intersection noticed cars going slowly, some were stopped with people looking at the lights - sure enough, they were all green. Fortunately, someone noticed it, possibly because a 7/11 type store sat catercorner[*] to the light, enabling a view of both lights at the same time. This particular intersection hosted a state road and another heavily travelled road which, needless to say, should have been more tragic than it was. talk robtmil@cable019054.cable.eph.ptd.net [* Robert had "caddycorner". Webster's gives "catercorner" (with "cater" from quatre), or alternatively "kitty-corner" (presumably because "Kater" auf deutsch = our english "cat" — ergo, a francogerman pun in English). The design doctrine that traffic lights must never be four-way green is therefore presumably "caterchism". PGN]
A couple of years ago, I had an accident where a woman pulled out in front of me. I was heading home from work. My light was green, and she claimed her light had turned green also. (Note: The lights in this intersection were new and had only been installed weeks before.) There were no witnesses, so the police officer was not yet able to issue a citation--Both of us claimed to have the green light. He said he would need to get back with us when the fault was determined, probably later in the week. Both of our cars were drivable, so we left the accident scene. The next day, I was driving home from work again along the same route and approached the intersection where the previous day's accident scene had taken place. There, in the intersection was an accident that looked exactly like the accident I had been in the day before. I decided to pull over and ask them a few questions. Both of these accident victims claimed their lights had been green. Coincidence? I don't think so. Two different and yet identical accidents that occur at the same intersection at around the same time during the day, with all involved individuals claiming their light was green. This was a little too much for me. I ended up calling the investigating officer and my insurance company and telling them about this. (All of us involved in the accidents exchanged phone numbers). The police said they would investigate this. The funny thing is that the police later denied that there was a problem with the lights, yet for the next few days, they had repairmen out working on the lights in that intersection. I have since watched those lights carefully, but have never seen this occurrence happen again.
A few years ago I learning something about actual traffic-control devices. The engineers are acutely aware of the issue of safety in the face of failures of both hardware and software, and the certification process in most countries requires documentation of careful attention to these issues. These devices are subject to very rough treatment: lightning, power spikes, shrapnel from automobile accidents, salt water. They are designed to fail safe: sturdy low level hardware interlocks (like relays and steppers) should prevent any software fault, and any hardware fault outside the interlocks themselves, from causing an unsafe configuration like all-green. Most faults in the interlock subsystem itself should put the device into a failsafe mode like all-blink-red. I'd think that the most likely cause of the nightmare all-green fault would be incorrect maintenance of the device, in which maintenance workers crossed wires or disabled interlocks. Someone from the manufacturer should have a very thorough look at the traffic control device involved in that accident in San Francisco. Barak A. Pearlmutter <bap@cs.unm.edu>, http://www.cs.unm.edu/~bap/ Assistant Professor, Computer Science Dept, Univ New Mexico [As RISKS readers have observed, there is a big difference between "should prevent" and "do prevent". PGN]
Yet another example of direct-mail marketers' software failing to divine the proper form of address for their intended recipient (from _National Review_, 24 Mar 1997, p. 5): American Family Publishers sends Assemblies of God church in Bushnell, Fla., a sweepstakes notice: "God, we've been searching for you." If He wins, "what an incredible fortune there would be for God! Could you imagine the looks you'd get from your neighbors? But don't just sit there, God." Kevin Hogan kahogan@EECS.Berkeley.EDU (510) 664-2533 http://www-ucsee.EECS.Berkeley.EDU/~kahogan/
It's not factually accurate. Dr. Eugene Schultz was never head of computer security at the U.S. Department of Energy - he was one of the people who started up the CIAC team at LLNL. That means he was a UC Berkeley employee. Quite a stretch if you ask me. I don't know about the rest of the story, but normally when one completely false statement appears, you can expect that everything else is likely to be tainted. [Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225] [The alleged Schultz quote is apparently something like 18 months old, and Gene has maintained in the past that he was grossly misquoted — as I recall, he has claimed he never said that SECRET-level *classified* information was obtained, although by inference you might suspect that there could have been sensitive information, and that the aggregation of the UNCLASSIFIED information could have been deemed SECRET. (Gene is unavailable this week, so I cannot get a first-hand comment from him.) Unfortunately, to the unwashed, all DoD computer information seems to be called "secret" unless it is posted to a newsgroup or available on the Web. On the other hand, if any SECRET information had been disclosed, that knowledge would itself most likely have been classified SECRET — in which case it wouldn't appear in RISKS until declassified! PGN]
"undocumented assembler code"? The assembler is not the problem. Shoddy practices are. I try to write assembler routines for a high-performance realtime embedded system using meaningful data structures and commented flow of control; I review C programs with constants named "STATE_1" and "STATE_2" and variables with single-letter names (and I don't just mean "i" for a loop) or names like "data". At least names like "temp" are vaguely honest. I forgot who wrote in CACM many years ago, regarding then-new languages like Pascal and Ada which supposedly enforced better standards, "One can write Fortran in any language". -Harlan Rosenthal
Martin Minow passes along a Swedish article estimating Swedish Y2K costs at $4000 per capita. I find many of the estimated Y2K costs hard to believe: Is the total cost of all software ever written this large? In the US, a similar estimate would put our Y2K cost at a trillion dollars. There is a real problem, but some people have made a business of exaggeration. A serious discussion of the costs might be warranted. I haven't looked at the report that MMs message points to. [Life is short. I don't read reports of flying saucers either.] Rich Schroeppel rcs@cs.arizona.edu
Please report problems with the web pages to the maintainer