A UPI story today says that a Canadian teenager defrauded a cellular phone network out of $500,000 worth of long distance calls by changing greetings in voice mail boxes so that they would approve calls billed to the Rogers Cantel, Inc. network. Cantel blames Bell Canada's automated long-distance billing service. Apparently Cantel has started offering customers a service that will keep their cellular phones from accepting third-party calls. Chuck Weinstock
The 6 Jan 1994 New York Times carries an article (business section, pages C1 and C4) by John Markoff about General Magic's Telescript language. The article likens software agents to viruses and worms and concentrates on the liability issues associated with a developing "ecology" of bits of software moving around through networks. My first reaction was that the folks at General Magic can't be too happy about the NYT putting this spin on its new product. After all, the problem with viruses and worms is not precisely that they travel but that they multiply, and few applications of agents, at least the ones most commonly envisioned, require unbounded replication. But then I wondered, how safe are we in a world that includes a widely distributed programming language in which a ten-year-old can write a heavy-duty worm? And Risks readers will guffaw at the following sentence in the article's last paragraph: "In an effort to lock the doors against potential vandals, General Magic has designed Telescript so that many of the most common computer security loopholes are impossible". It goes on to mention that General Magic has licensed encryption technology from RSA Data Security. I'm looking forward to the first few reverse-engineered Telescript products. Best wishes to General Magic. Phil Agre, UCSD
[The following item is copyrighted by the 1994 N.Y. Times, and appeared on Thursday, 13 Jan 1994. It is reproduced in RISKS with the permission of its author. Any further reuse requires permission of the New York Times. PGN] REDWOOD CITY, Calif. The Clinton administration's newly articulated information technology policy of persuasion, rather than dictation, is getting an early test. At an industry conference in Redwood City this week, computer hardware, software and telecommunications companies as well as a major bank, are saying they intend to adopt an industry coding standard for protecting the privacy of electronic communications, rather than support a standard being pushed by the administration. Unlike the administration-backed standard, the technology, which has been commercialized by RSA Data Security Inc., does not provide an electronic ``trapdoor'' that would enable law-enforcement agencies to eavesdrop on digital communications. The administration, whose standard is known as the Clipper chip, contends that a trapdoor is necessary to detect criminal activity or espionage because sophisticated encryption techniques can make digital phone calls or computer communications nearly impervious to wiretaps. Wednesday, Hewlett Packard Co. became the last of the leading United States computer companies to license the RSA software, joining Apple Computer, IBM, Sun Microsystems, Digital Equipment and Unisys. Several companies announced at the conference that they planned to begin selling products that embed RSA's software. Among them are General Magic, a software developer; National Semiconductor; a consortium of five cellular data companies, and Bankers Trust Co. The conference was sponsored by RSA, which is based in Redwood City, and attracted many of the nation's best non-government cryptographers a group of code makers and code breakers who have generally been hostile to any form of government restrictions on their technology. They have sparred for more than a decade with the National Security Agency, the main proponent of the Clipper chip. The agency is responsible for monitoring electronic communications worldwide for the government, in the name of national security. In addition to opposition from the cryptographers, the government's Clipper chip proposal has already stirred bitter opposition from civil liberties organizations and computer user groups, who fear the Clipper chip would make electronic communications too easy for anyone to eavesdrop. Now the industry's rush to embrace an encryption standard that does not provide a way for the government to listen to data or voice conversations is certain to put new pressure on the Clinton administration, which is now in the final stages of a classified review of its Clipper standard. ``It's clear that what is going on here today is contrary to the way the NSA wants the world to move,'' said Lynn McNulty, associate director for computer security at the National Institute for Standards and Technology, a Commerce Department agency. The institute proposed the Clipper standard last April, although most of its technical development was done by NSA researchers. Despite their defiance, researchers attending the conference worried that the government might still have the means to enforce its vision of a coding standard. ``They have the trump card that we don't have,'' said Bruce Schneier, a former government cryptography researcher, who is the author of a textbook titled ``Applied Cryptography.'' ``They could make it a law that it's mandatory to use their standard.''
Washington D.C. 1-25-94 and Encryption Export Control [This message was received rather late, even if the R.S.V.P. deadline was extended from 2 Jan! But you may want to respond anyway. Besides, the Cantwell Bill is included below, and it may be of interest to many RISKS readers. PGN] This is an invitation to join members of the security community, Administration officials, and members of Congress in a discussion of security on the National Information Infrastructure and encryption export controls. The meeting will be held at the Washington Convention Center on January the 25th, 1994. The meeting will begin at 8 a.m. and will adjourn at 3 p.m. The purpose of this meeting is in response to a request from Secretary of Commerce Ron Brown at the recent 1993 Technology Summit in San Francisco. Secretary Brown asked that a meeting be held to bring together industry and government to start an open dialog, which will help shape information security policy as the United States moves forward into a more global economy. Everyone will have a chance to express their opinions and concerns. During this meeting individual committees will be formed to study and make recommendations on specific areas of information security as it relates to the NII ( this will also become known as the International Information Infrastructure). R.S.V.P.'s are required NO LATER THAN January 2, 1994 [apparently extended to 10 Jan. PGN]. Please call Paul Gates at the National Computer Security Association (717) 258-1816. All attendees will be sent an agenda, a copy of the NII, the Clinton Administration's Technology Policy and a copy of the Cantwell Bill which deals with encryption export controls. NOTE: If you cannot attend in person but would still like to participate we will be offering on-line opportunities. Sharon Webb voice# (404) 475-8787Director, Legislative Affairs, National Computer Security Association P.S. Attached please find a copy of the Cantwell Bill, my comments and the NCSA's Encryption Export Control Survey . Please send ALL responses to either my fax #(404) 740-8050 OR EMAIL to me via SHARONWEBB@ DELPHI.com 103D Congress 1st Session H.R. 3627 IN THE HOUSE OF REPRESENTATIVES Ms. CANTWELL (for herself and____) introduced the following bill which was referred to the Committee on_____________________________. A BILL To amend the Export Administration Act of 1979 with respect to the control of computers and related equipment. Be enacted by the Senate and House of Representatives of the United States of America in Congress assembled, SECTION 1. GENERALLY AVAILABLE SOFTWARE. Section 17 of the Export Administration Act of 1979 (50 U.S.C. App. 2416) is amended by adding at the end thereof the following new subsection "(g) COMPUTERS AND RELATED EQUIPMENT - "(1) GENERAL RULE. - Subject to paragraphs (2) and (3) the Secretary shall have exclusive authority to control exports of all computer hardware, software and technology for information security (including encryption), except that which is specifically designed or modified for - "(A) military use, including command, control and intelligence applications; or "(B) Cryptanalytic Functions "(2) ITEMS NOT REQUIRING LICENSES - No validated license may be required, except pursuant to the Trading With The Enemy Act of the International Emergency Economic Powers Act (but only to the extent that the authority of such Act is not exercised to extend controls imposed under this Act), for the export or reexport of- "(A) any software, including software with encryption capabilities, that is "(i) generally available, as is, and is, and is designed for installation by the user or "(ii) in the public domain or publicly available because it is generally accessible to the interested public in any form; or "(B)" any computing device solely because it incorporates or employs in any form software (including software with encryption capabilities) exempted from any requirement for a validated license under subparagraph (A). "(3) SOFTWARE WITH ENCRYPTION CAPABILITIES - The Secretary shall authorize the export or reexport of software with encryption capabilities for nonmilitary end-uses in any country to which exports of such software are permitted for use by financial institutions not controlled in fact by united states persons, unless there is substantial evidence that such software will be - "(A) diverted to a military end-use or an end-use supporting international terrorism: "(B) modified for military or terrorist end-use; or "(C) re-exported without requisite United States authorization. "(4) DEFINITIONS - As used in this subsection- "(A) the term 'generally available' means, in the case of software (including software with encryption capabilities), software that is offered for sale, license, or transfer to any person without restriction through any commercial means, including, but not limited to, over-the-counter retail sales, mail order transactions, phone order transactions, electronic distribution, or sale on approval; "(B) the term 'as is' means, in the case of software (including software with encryption capabilities), a software program that is not designed, developed, or tailored by the vendor for specific purchasers, except that such purchasers may supply certain installation parameters needed by the software program to function properly with the purchaser's system and may customize the software program by choosing among options contained in the software program; "(C) the term 'is designed for installation by the purchaser' means, in the case of software (including software with encryption capabilities - "(i) the software company intends for the purchaser (including any licensee or transferee), who may not be the actual program user, to install the software program on a computing device and has supplied the necessary instructions to do so, except that the company may also provide telephone help line services for software installation, electronic transmission, or basic operations; and- "(ii) that the software program is designed for installation by the purchaser without further substantial support by the supplier; "(D) the term 'computing device' means a device which incorporates one or more microprocessor-based central processing units that can accept, store, process or provide out-put of data; and "(E) the term 'computer hardware', when used in conjunction with information security, includes, but is not limited to, computer systems, equipment, application-specific assemblies, modules and integrated circuits". END of BILL FROM: Secure Systems Group International, Inc TO: Bob Bales Director, National Computer Security Association (717) 258-1816 Re: Encryption Export Bill (Cantwell) Bob - Here are some of the comments that we passed along to Maria Cantwell's office regarding the Bill on the export of encryption technologies. I hope you find it useful. I understood the purpose of this Bill was to reduce export controls and restrictions of software that is either based on encryption or that contained encryption. As I read the Bill everything was fine until paragraph (3) -( You understand that I am reading this from a laypersons point of view and if you can clear up any misinterpretations I would appreciate it). In paragraph (3) the Bill states software containing encryption can be exported freely "unless there is substantial evidence that such software will be: (A) diverted to a military end-use or end-use supporting international terrorism: (B) modified for military or terrorist end user or (C) re-exported without requisite United States Authorization." or that software which is "... specifically designed or modified for (A) military use, including command, control, and intelligence applications; or (B) cryptanalytic functions I think that before I or others from the security side decide to support or not to support this Bill we have some questions that need answers. 100 Nobel Court, Suite 400, Alpharetta, GA. 30202 Voice (404) 475-8787 FAX (404) 740-8050 Member of National Computer Security Association and the American Electronics Association 1. Who will be asked to determine whether such restrictions are appropriate? The NSA? The CIA? The FBI? Does it remain the same as under the current law? Assuming that the technical overview of military applications for encryption remains the NSA - what makes it in their interest to let ANY encryption out of the country that will make their job more difficult? (A little like letting the fox guard the chickens) 2. What constitutes substantial evidence 'of or 'designed for' military use? Is it measured by the relative strength of the algorithm or key management system or by the mere fact it is longer than the DES which is 56 bits? I feel that some sort of definition needs to be included. What can and what cannot be exported? A list of commercially available encryption software algorithms that are pre-approved - (i.e. DES, RSA, PGP, RC4, DSS, etc.) would be nice. Is selling an encryption product to a foreign military contractor the same as selling to the military itself, and who makes the judgment call? 3. Will export licenses be required - will denials be explained so that the exporter and the public understand the reasons for the denial? 4. If a denial is issued, will the exporter have any forum for appeal? Since Secretary of Commerce Ron Brown has exclusive control over the export rules, it is obvious that the intelligence community can have a single, important, point of focus for influence. (Yes I an slightly suspicious). In theory, the intelligence overseers could disapprove any license to a FRIENDLY Government or customer on the assumption that their military would use it just because its within their borders. It is unlikely that German forces will revert to DES, but their interest in RSA or PGP or triple DES may have such applications. It would still be in the NSA's best interest to limit the export of such software. My major objection to the Bill as I have understood it is that Commerce, based on advice from the intelligence community (i.e. NSA), still has arbitrary control over what encryption may be exported or not. How is this that much different from what we have today? This version of the Bill would still permit the Secretary to arbitrarily restrict export of some algorithms with no technical benchmarks in place (i.e. length of key, number of bits). There will be some algorithms that the U.S. would want to restrict it would be a great help to all to compile a list of accepted algorithms for export such as is done with computer exports which are measured in MIPS. In general, I like the Bill - we NEED it ! - but I feel that it leaves a lot of room for confusion. Let me know what your thoughts are on this - thanks. Sharon Webb, President National Computer Security Association Encryption Export Control Survey The purpose of this survey is to quantify the business opportunities lost because of the U.S. policy on the exportation of encryption algorithms such as DES, RSA, etc. If we are to make ANY impact AT ALL, the security community needs to let Congress that economic HARM is being done due to the export control on encryption technologies. Please take the time to fill this out and return it to NCSA NO LATER THAN FRIDAY JANUARY 7, 1994. NCSA FAX (717) 243-8642. The results will be presented to Congress in order to further efforts to release export controls on certain encryption technologies. 1) Are you a manufacturer of products that utilize encryption methods? YES NO 2) What forms of encryption do you use? 3) Is you product Hardware Software or Both . 4) Have you experienced a loss of sales OVERSEAS due to export controls? YES NO (If the answer is YES, please list the country, the customer (optional), the dollar amount lost and who got the business (Competitor). If there is a way for you to be able to know WHY a bid was lost let us know.) 5) Have you experienced a loss of sales HERE in the U.S. and Canada to foreign competition? YES NO (If the answer is YES, please list the customer (Optional), the dollar amount and who got the business (Competitor). 6) What percentage of your business is U.S. based? International? (what country(ies) make up the largest portion of your International sales? Who are you? (Optional) and additional comments: (Use additional paper if necessary) Attached is a file called NCSASUR.DOC. This file contains an open invitation to the meeting in Washington D.C. on January 25th. Italso contains a copy of the Cantwell Bill and my comments. The final page is the VERY IMPORTANT NCSA Encryption Export Control Survey. We need as many QUALIFIED (names and phone numbers attached) responses ASAP!!!! Thank You Sharon Webb - Director, Legislative Affairs NCSA voice#(404) 475-8787 fax# (404) 740-8050 email SHARONWEBB@Delphi.com
In the message below, I try to be careful to use "allegedly", "claimed", etc., to indicate information that I have been lead to believe was correct but that I have not checked up on myself. By using these words, I do not mean that the statements are incorrect or correct, only that I am not sure of their veracity. On Friday, 8-Jan-1994, I received a message (apparently originally sent on Tuesday) that discussed a certain company that was (allegedly) advertising "free Internet access" but required you to Fax them a credit card number. This message was from someone who claimed to be in a position of knowing all the service providers in that area and had checked up on that company. The message indicated that the "Suite" address was just a P.O. Box at a non-US Postal Service provider and the phone number just got you to voice mail. The message also indicated that the Internet address you would get was not registered with the INTERNIC and was not in a couple of (milnet) hosts tables. I took the message at face-value (I still have no reason to doubt the sender or his intent) and sent a message to another very large and wide-spread mailing list that was a warning about giving your credit card number out to receive Internet access without checking out the company. Thankfully, I chose not to give the name of the company. A few hours later, David Oppenheimer pointed out in a reply to that same mailing list that the Internet address did in fact exist and was registered to a company of the same name. The addresses were different (different states) but at this point, I suspect that it is the same company. I received the original message as a private one from a friend and also saw it distributed on a largish mailing list (to which it had been forwarded from another mailing list). (On Saturday, I informed the list I saw it on of the corrections that Oppenheimer pointed out.) I wonder how many people saw the original message that contained some apparently incorrect information. This kind of misinformation can spread so quickly. The corrections may not reach all the people who saw the first message. (I've just now learned of 8 other mailing lists it was forwarded to.) There are some lessons to be learned: 1. Don't give your credit card number to anyone without checking them out. 2. Don't presume that the info in a message is correct just because someone sent it. 3. Don't be too quick to spread information that you haven't checked out personally. Misinformation can spread like wildfire. Furthermore, for all I know (not being a lawyer), you might be held legally responsible for spreading it. 4. Don't presume that the sender of a message is who he says he is. (NOTE: The sender of the original message may really be who he says he is. However, *I* haven't checked on that.) 5. After reading the above, how do you know I am who I say I am? [I know Mabry and he would never play tricks. He's very reliable. I also checked out the original offer. It was indeed genuine, although somewhat misleading. The Internet connections may have been free, but the users are still going to get stuck for higher-than-usual telephone charges. PGN.] Mabry Tyson Tyson@AI.SRI.COM The views and opinions expressed are mine personally and do not necessarily represent the views, opinions, or policies of my employer.
Aerospace Daily carried some articles recently that may be able to shed some light on the problems of software development. On 1/6/94, there was an article on how rigid management appeared to have had a role in the Mars Observer failure. On 1/7/94, there was a similar article on problems with the C-17. The 1/6/94 article was particularly interesting, as it suggested that the failure of the Mars Observer had to do with the use of fuel system parts that had not been qualified for deep space missions. This may have occurred due to management turmoil, leading to the departure of technically-qualified middle management. Without that layer of technical management, the risks of using unqualified parts were not recognized during design reviews. The 1/7/94 article suggests that the C-17 problems were similarly due to a TQM program that eliminated the echelon of technical management that was usually responsible for ensuring a successful system integration. These two data points are consistent with my experience on the BMDSTP program (discussed in an earlier RISKS). Although, as I indicated, the middle-echelon technical managers on that program were not markedly better than managers I've met since then, they did possess the necessary expertise in their areas to ensure a successful integration of that system. This suggests that the usual management approach to the development of complex computer systems all too often lacks an echelon of technical management necessary to the successful integration of those systems. And it suggests TQM has exacerbated this by eliminating that echelon in some organizations that had previously avoided this problem. Comments? Harry Erwin Internet: firstname.lastname@example.org or email@example.com
Please report problems with the web pages to the maintainer