In January 1997, an ad-hoc group of cryptographers and computer scientists met to explore the technical implications, risks, and costs of the ``key recovery'', ``key escrow'' and ``trusted third party'' encryption systems being promoted by various governments. We have just completed a preliminary report of our findings. We have specifically chosen not to endorse, condemn, or draw conclusions about any particular regulatory or legislative proposal or commercial product. Rather, it is our hope that our findings will shed further light on the debate over key recovery and provide a long-needed baseline analysis of the costs of key recovery as policymakers consider embracing one of the most ambitious and far-reaching technical deployments of the information age. Our preliminary report is available as follows: On the web at: http://www.crypto.com/key_study In PostScript format via ftp: ftp://research.att.com/dist/mab/key_study.ps In plain ASCII text format via ftp: ftp://research.att.com/dist/mab/key_study.txt ======================================================================= THE RISKS OF KEY RECOVERY, KEY ESCROW, AND TRUSTED THIRD-PARTY ENCRYPTION Hal Abelson Ross Anderson Steven M. Bellovin Josh Benaloh Matt Blaze Whitfield Diffie John Gilmore Peter G. Neumann Ronald L. Rivest Jeffery I. Schiller Bruce Schneier 21 May 1997 Executive Summary: A variety of ``key recovery,''``key escrow,'' and ``trusted third party'' encryption requirements have been suggested in recent years by government agencies seeking to conduct covert surveillance within the changing environments brought about by new technologies. This report examines the fundamental properties of these requirements and attempts to outline the technical risks, costs, and implications of widely deploying systems that provide government access to encryption keys. The deployment of a global key-recovery-based encryption infrastructure to meet law enforcement's stated specifications will result in substantial sacrifices in security and greatly increased costs to the end-user. Building the secure infrastructure of the breathtaking scale and complexity demanded by these requirements is far beyond the experience and current competency of the field. Even if such an infrastructure could be built, the risks and costs of such a system may ultimately prove unacceptable. These difficulties are a function of the basic law enforcement requirements proposed for key-recovery encryption systems. They exist regardless of the design of the recovery system — whether the system uses private-key cryptography or public-key cryptography; whether the database is split with secret sharing techniques or maintained in a single hardened secure facility; and whether the recovery service provides private keys, session keys, or merely decrypts specific data as needed. All key-recovery systems require the existence of a highly sensitive and highly available secret key or collection of keys that must be maintained in a secure manner over an extended time period. These systems must make decryption information quickly accessible to law enforcement agencies without notice to the key owners. These basic requirements make the problem of general key recovery difficult and expensive — and potentially too insecure and too costly for many applications and many users. Attempts to force the widespread adoption of key-recovery encryption through export controls, import or domestic use regulations, or international standards should be considered in light of these factors. The public must carefully consider the costs and benefits of embracing government-access key recovery before imposing the new security risks and spending the huge investment required (potentially many billions of dollars, in direct and indirect costs) to deploy a global key recovery infrastructure.
Sun Microsystems is adapting SKIP E+, a Russian crypto product from Elvis + Co. (designed and implemented independent of Sun, but based on Sun's SKIP), installing it abroad under the SunScreen brand name, and selling it in foreign markets through third-party vendors. (Test copies are available if you do your Elvis sighting at http://www.elvis-plus.com.) RSA Data Security's Jim Bidzos said that RSA will do the same thing ; ``What better example of how export controls are simply obsolete? They serve no purpose other than to make U.S. companies jump through hoops.''  [References: 1. *Wall Street Journal*, 19 May 1997; 2. Julia Angwin in the *San Francisco Chronicle*, 20 May 1997, C1] I believe Trusted Information Systems is already doing this with a German DES crypto implementation in its firewall product. However, such implementations raise many interesting questions, such as who knows how to subvert or circumvent the crypto, and which governments or other organized entities are doing what to whom.
>From http://www.msnbc.com/news/75617.asp by the Associated Press. ... The interesting part is that Sun will sell Elvis+'s Secure Virtual Private Network for MS-Windows 3.11, 95 and NT under the name SunScreen SKIP E+ in August. The risks here include can Sun trust a Russian company to which Sun provided no technical assistance, therefore, I assume, no quality-control testing. It is one thing to bundle a paint program written by another company, but to resell a security product with your name on it without doing your own quality testing and cryptanalysis is very risky IMHO. Could Sun Microsystems find a backdoor that was included at the _request_ of a foreign government? I won't even start with the risks of legal action.. Michael C. Taylor <firstname.lastname@example.org> <http://www.mta.ca/~mctaylor/> Software Engineer, Mount Allison University, Canada [Depends on which color you paint your backdoor? PGN]
During my recent vacation in Britain, I picked up the 3 May 1997a issue of *The (London) Times*, with its 16-page pullout section giving the complete results of their general election two days before. I had happened to see on TV the results from Putney, where 10th-place Derek Vanbraam polled just 7 votes out of 43,995 cast there, I was naturally curious to see whether anyone had done worse. Apparently nobody did. But while I was looking through the section, I found something rather more interesting: SKIPTON & RIPON C Hold Electorate 72,042 (70,154) %Votes + Curry, D (C) 0 NaN Marchant, R (Lab) 0 NaN Mould, T (LD) 0 NaN Holdsworth, N (Ref) 0 NaN --------------------------------------- C Majority 0 NaN --------------------------------------- Total Vote 0 Turnout 0.00% followed by the presumably correct votes from 1992, and further information about the "winner" David Curry. The "+" means that Curry was already an MP and "majority" is British for his plurality or margin of victory. A slender margin indeed! :-) Of course, most of us here will recognize NaN as Not a Number, the result of dividing 0 by 0. According to the BBC web site, the actual results for the seat are: Curry, David Con 25,294 46.50% Mould, Thomas LibDem 13,674 25.20% Marchant, Robert Lab 12,171 22.40% Holdsworth, Nancy Ref 3,212 5.90% Majority 11,620 So the Times did in fact list the correct winner — but it appears that they did so only by accident. I'm not sure what order the candidates were shown in; it might be alphabetical by parties, or in order of the expected finish of the parties, or something completely arbitrary. In any case it isn't their actual order of finish, or alphabetical order, though it's close to both. The BBC web site reports are also wrong, though in a more subtle way. Notice that coincidental column of zeroes at the far right? That's no coincidence: it's a bug. The column should read 46.54%, 25.16%, 22.39%, and 5.91%. The same sort of thing is shown for other constituencies: poor Derek Van Braam (as they spell it — I don't know who's right) is shown with 0.00% of the vote in Putney, when in fact he got nearly 0.02%! All together now: "Hey Pat, I know there's no time to test it, but could you just change that program to print one more decimal place?" Mark Brader, email@example.com | "I conducted a Usenet poll ... on this subject ... SoftQuad Inc., Toronto | Laura is single. By a 2-1 margin." — Ken Perlow [By the way, the 9th-place candidate in Putney identified herself as an ``Independent Beauty''. I thought it a pity that the fringe vote in that southwest London district was so widely split that she also got under 100 votes.] [``Maybe she was a NaNy goat,'' PGN said, butting out no-billy.]
> A Really New Twist in Online Voting > by Ashley Craddock [From WiReD Online via PointCast] > 15 May1997 — Polling on the Web is notoriously inaccurate. Still, > designers at abortion.com <http://www.abortion.com> decided not to take > any chances when they asked people to answer the question, ``Where do you > stand on abortion?'' The site not only lets people vote multiple times, > but funnels votes on either side of the issue straight to the > anti-abortion tally. Key points made by the author: * Every click of the _pro-choice_ button purportedly adds two to five votes to the _anti-choice_ vote tally. * The results are wildly at variance with other information about the popularity of the two positions: with pro-choice:anti-abortion::53%:36% according to recent Gallup polls, the Web site shows 13% of the votes in favour of choice. [MK: I went to the site in question and found that contrary to the assertions in the article, voting for the pro-choice side did in fact increase the pro-choice tally appropriately--each time one ``voted.'' In any case, even with accurate tallies of votes cast but without strong identification and authentication to prevent multiple votes, ``voting'' on anything via the Net should be considered nothing other than amusement or propaganda. Peter Neumann commented to me, ``If anyone can vote multiple times, the whole thing should be condemned out of hand. You could automate [virtual] voters that would cast votes as fast as possible.'' In discussion of an earlier draft of this submission, one of PGN's reviewers wrote: > The bigger RISK, of course, is that any system with self-selecting voters > introduces a bias; the computer-related aspect is that the self-selection > can be much more focusing. I find it surprising that people actually seem > to care about the results of such polls. They remind me of the > ``kindergarten method'' for determining the sex of a kitten: take a vote > of the class. ] M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com
>From WIRED via PointCast: > Another Computer Bug: Ants in the Machine > by Ashley Craddock, 19 May 1997 > Stephanie Upps watched in horror as one of her final papers disappeared > off her PowerBook at 2 a.m. one night during her last semester as a > University of Texas graduate student. Her friends couldn't find the bug, > so she called the 1-800 support line in desperation. "They told me to > pull out the battery and give them the serial number," she says. "When I > did, it was just crawling with ants." Far from a fluke, Upps' encounter > with ants in the machine is happening to others with greater > frequency. "The problem's endemic across Texas," she said. The author makes the following key points: * Major problem is fire ants, an exotic introduced to the Southern US in the 1920s. * Fire ants seem to like living in and eating electrical equipment. * The critters may be attracted by electrical fields; Craddock writes,` "They have some short-range attraction to electricity," says Dr. Harlan Thorvilson of Texas Tech's Department of Plant and Soil Sciences. . . . "They become almost mesmerized and behave oddly, piling dirt against the wires and signaling to other members of their communities who come and join them." ' [MK: I don't want to make a mountain out of an ant-hill, but this looks like a case of form(icidae) over function. I expect further creepy puns from our moderator, perhaps about how the victims are engaged in formication and should ant-icipate trouble.] M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com [Turn on the fire-hider-ants; someone is in for a shock. PGN]
Call for Papers, WORKSHOP ON INFORMATION HIDING (pruned for RISKS) 15 - 17 April 1998, Portland, Oregon Many researchers are interested in hiding information or in stopping other people doing this. Current research themes include copyright marking of igital objects, covert channels in computer systems, subliminal channels in cryptographic protocols, low-probability-of-intercept communications, broadcast encryption schemes, and various kinds of anonymity services ranging from steganography through location security to digital elections. These closely linked areas of study were brought together in 1996 by a workshop on information hiding held at the Isaac Newton Institute in Cambridge. This was felt to be very worthwhile by the research community, and it was decided to hold a second workshop in 1998. This second international workshop on information hiding will be held in Portland, Oregon from the 15th to the 17th April 1998. See http://www.cl.cam.ac.uk/users/rja14/ihws.html for the call for papers. Papers should be submitted by 31 Dec 1997 to firstname.lastname@example.org (Program Chairman David Aucsmith, Intel Architecture Labs, 5200 N. E. Elam Young Parkway, Hillsboro, OR 97124-6497, USA). The program committee also includes Ross Anderson, Steve Low, Ira Moskowitz, Andreas Pfitzmann, Jean-Jacques Quisquater, Gus Simmons, and Michael Waidner. Details of the first (1996) information-hiding workshop are at http://www.cl.cam.ac.uk/users/fapp2/steganography/bibliography/workshop.html [Watch out for the invisible steganosauruses. PGN]
Jim Youll <email@example.com> writes in RISKS-19.16 about forged spam. I saw another side of the same incident. The spam Jim refers to was done via enterprise.net, a UK ISP. As a result of this (or another?) spam, enterprise.net recently stopped relaying mail to domains other than enterprise.net. I discovered this when mail to one of Enterprises' company customers (lfix.co.uk, a small consultancy) started bouncing. I reported it to firstname.lastname@example.org, but the reply I got was clearly from a low-level support person who did not understand the problem. The problem wasn't fixed, and after a week or two I gave up. The risks of an overly strict configuration and incompetent staffing hopefully include a loss of customers. --Arnt
In RISKS-19.14 Azeem Azhar reports on the power failure that took many of the UK's ISPs off-line simultaneously despite multiple redundant power supplies. At the end of his message he exhorts ISPs to: > The message: UK ISPs! Please think about your redundancy! A certain well-known workstation manufacturer certainly takes this issue seriously as, in a recent product description, they write "All components within this server are redundant." I'm inclined to agree, but perhaps not in the way they had in mind. The risk here is that people might actually read what you write... Bruce Horrocks EASAMS Limited Waters Edge,Riverside Way,Watchmoor Park, Camberley,Surrey,GU15 3PD,UK +44 1276 686777 Bruce.Horrocks@gecm.com
There is a risk of getting hooked on a good thing that comes free. Radio amateurs and physical scientists often need a good frequency standard, and the cheap and easy way is to tune in to the NIST broadcasts from Fort Collins, or any of the satellite transmitters. But there is a better way that is even cheaper---we all have atomic frequency standards in our living rooms. All the major television networks derive their base frequencies from atomic clocks, usually rubidium, the cheapest. They are far better than the FCC standards, but cost nothing compared to other TV production costs. Therefore the color subcarrier in our TV sets is phase locked to a frequency near 3.579545.. MHz, which is in fact, to atomic standards, equal to 63/176 of 10 MHz. Put a spare jack on your TV, multiply by 176/63 if you must, and you have an atomic clock. Where's the risk? As soon as you get hooked, you'll find that this only works for the major networks, and then only when the locals are running on direct feed (like during football games), and tinkering by the local stations can mess things up. Such tinkering is spreading, but the trick is still useful. Good things never last. Hal Lewis
Perhaps a more obvious limitation on clock synchronization is the limit that special relativity imposes on simultaneity. It's not meaningful to compare a clock in Denver with a clock in California to within a microsecond, because the two locations are about five milli-light-seconds apart. Andrew Klossner (email@example.com)
Actually, GPS uses a measurement of time that has the same definition of a second as UTC and TAI, but is offset a constant 19 seconds from TAI. This was the same as UTC in 1980 (the GPS epoch), but leap seconds have increased UTC's offset from TAI to 30 seconds (soon to be 31) while GPS time has remained unaffected. Anyone trying to reconcile GPS time with local civil time (based indirectly on UTC) has to take this into account. (Personally, I think computers should keep time in TAI and have a table of leap seconds along with the time zones and other human-generated time cruft.) The GPS clocks do take numerous relativistic effects into account; presumably TAI and UTC are canonically measured at some particular location, with its particular dilations and whatnot. Astronomers have time scales such as TDB (Barycentric Dynamic Time) which account for relativistic effects on the Solar-system scale, and have ways to deal with the fact that simultaneity isn't a well defined concept in the first place. The RISK of course is that something as apparently simple and mundane as time can actually be extremely complex, what with everything from leap years and time zones to leap seconds and relativity. It's awfully easy to code a simplified model of the universe into software, which will work for a while and then break subtly when the model and the universe diverge in a way that almost nobody actually understands.
There has been a lot of erudite talk recently about the various ways of defining time (see the current Encyclopedia Brittanica for more than you want to know), and Peter Ladkin has just raised the question of relativistic corrections to timekeeping (the fanciest were first mentioned by Einstein in 1916, and have been amply confirmed and understood for eighty years). At the accuracy of atomic clocks, a part in 10^15 or thereabouts, these corrections are considerable. A clock on the earth is off by a part in a billion compared to one on the moon, and a part in a million relative to one on the surface of the sun. So these are big big effects, scientifically speaking, and are thoroughly understood. What is lacking in our conversation so far is the definition of what is meant by time, also thoroughly dealt with by Einstein eighty years ago. According to general relativity it doesn't matter beans whether your clock is on Mars or the sun or a satellite, as long as you deal only with local matters, but it does matter if you use your local clock to deal with matters in another gravitational zone, or moving at a different speed (the latter is special relativity). That's why our local atomic clocks need correction if they are to be used to deal with the motion of the planets---they are at different gravitational potentials. On top of all that there is the problem of whether time can even be defined on a universal basis. The current standard cosmologies all admit to the existence of what is called a "world-time," to which all our clocks can be compared, but there exist entirely self-consistent cosmologies for which that isn't true. That gets into epistemology and Mach's principle, and is probably far beyond what the readers of Risks care about. My only point is that before you start dealing with relativistic corrections, you have to get your lexicon in order. It isn't as simple as fast clocks going slow, or earthbound clocks speeding up when the earth is at its aphelion, though there is a sense in which both statements are true. Like most things, time isn't a simple subject if you start digging. Use TAI for science and UTC for navigation, and all will be well. But if you travel to Sirius, be careful. Hal Lewis
As I recall from my California public education, clocks slow down as the gravitational field strength increases. In the limit, at the event horizon of a black hole, time stops. So, the clocks in Denver should run faster than the clocks in London since Denver is in a slightly weaker field. Mark
>The rest of us can easily live a small error. I'm >not worried about being a day off in the year 100K. Yes, but some people might be worried about being half a day off in the year 50,998. Greg Smith Advanced Microelectronics gsmith@AuE.com
* "no no" means No! It rarely means yes. * The 21st century starts Jan 1, 2000 because we took a vote and decided it. * Leonard Nimoy is just an actor. * We don't use local solar time, we use an arbitrary time that is about an hour or two off from local time, let alone GPS time. * Doing relativistic corrections for car speedometers would be lost in the noise And computers do not use leap-seconds and should not use leap-seconds. If we tried, we'd suffer from a very serious case of bit rot. What we do have are some kids who are so enamored with their new watches that keep time accurate to the nanosecond that they want all of us to suffer by comparison. They've even snuck it into our clocks so that we have 30 seconds of confusion since Jan 1, 1972 (according to http://tycho.usno.navy.mil/leapsec.html). Let's put an end to this silliness so that we can write programs that save and compare dates without being told that we are wrong or being made to feel guilty for making them work. It is now official, computers do not take into account leap-seconds. We now need to decorrect time routines that use GPS and other precise sources and fix them to return human time. We need to demand that leap-seconds no longer be added to UTC. We can declare Jan 1, 1998 as Leap Second Liberation Day. Who will tell the NEOS (http://maia.usno.navy.mil/) that we are going to stop taking their corrections and imposing them on our clocks? We then need to explain to astronomers (and others) that we are not stealing any time from them. We simply changed the naming scheme to reflect the one used by humans. They are free to apply whatever corrections they want. In fact, they should and, more to the point, they will. Because they care. And one principle of RISKS is to put the onus on those who care. We just need to stop feely guilty because we don't have the latest time keeping gizmo. This issue also points out a major weakness in the standards process — it is so boring and painful that only those with an axe to grind participate. Or those with a nifty cesium clock they want to show off. I'm not saying ignore the cesium clocks, just complicate time for those who care and not for the rest of us. PS: I sure hope that the Risks readers have a sense of humor. But I am serious about the basic points even if I tried to did attempt some humor. But I am or, at least, have been, part of the same cult of technology so am familiar with the symptoms.
Please report problems with the web pages to the maintainer