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…
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: herwin@cs.gmu.edu or erwin@trwacs.fp.trw.com
Please report problems with the web pages to the maintainer