innovation, and ensure that communications privacy will be carried
forward into the next decade.
In the past several months we have become aware that the federal
government has failed to take advantage of opportunities to promote
communications privacy. In some areas, it has considered proposals
that would actually be a step backward. The area of cryptography is a
prime example.
Cryptography is the process of translating a communication into a
code so that it can be understood only by the person who prepares the
message and the person who is intended to receive the message. In the
communications world, it is the technological equivalent of the seal
on an envelope. In the security world, it is like a lock on a door.
Cryptography also helps to ensure the authenticity of messages and
promotes new forms of business in electronic environments.
Cryptography makes possible the secure exchange of information through
complex computer networks, and helps to prevent fraud and industrial
espionage.
For many years, the United States has sought to restrict the use of
encryption technology, expressing concern that such restrictions were
necessary for national security purposes. For the most part, computer
systems were used by large organizations and military contractors.
Computer policy was largely determined by the Department of Defense.
Companies that tried to develop new encryption products confronted
export control licensing, funding restrictions, and classification
review. Little attention was paid to the importance of communications
privacy for the general public.
It is clear that our national needs are changing. Computers are
ubiquitous. We also rely on communication networks to exchange
messages daily. The national telephone system is in fact a large
computer network.
We have opportunities to reconsider and redirect our current policy
on cryptography. Regrettably, our government has failed to move thus
far in a direction that would make the benefits of cryptography
available to a wider public.
In late May, representatives of the State Department met in Europe
with the leaders of the Committee for Multilateral Export Controls
("COCOM"). At the urging of the National Security Agency, our
delegates blocked efforts to relax restrictions on cryptography and
telecommunications technology, despite dramatic changes in Eastern
Europe. Instead of focusing on specific national security needs, our
delegates continued a blanket opposition to secure network
communication technologies.
While the State Department opposed efforts to promote technology
overseas, the Department of Justice sought to restrict its use in the
United States. A proposal was put forward by the Justice Department
that would require telecommunications providers and manufacturers to
redesign their services and products with weakened security. In
effect, the proposal would have made communications networks less well
protected so that the government could obtain access to all telephone
communications. A Senate Committee Task Force Report on Privacy and
Technology established by Senator Patrick Leahy noted that this
proposal could undermine communications privacy.
The public opposition to S. 266 was far-reaching. Many individuals
wrote to Senator Biden and expressed their concern that cryptographic
equipment and standards should not be designed to include a "trapdoor"
to facilitate government eavesdropping. Designing in such trapdoors,
they noted, is no more appropriate than giving the government the
combination to every safe and a master key to every lock.
We are pleased that the provision in S. 266 regarding government
surveillance was withdrawn. We look forward to Senator Leahy's
hearing on cryptography and communications privacy later this year.
At the same time, we are aware that proposals like S. 266 may reemerge
and that we will need to continue to oppose such efforts. We also
hope that the export control issue will be revisited and the State
Department will take advantage of the recent changes in East-West
relations and relax the restrictions on cryptography and network
communications technology.
We believe that the government should promote communications
privacy. We therefore recommend that the following steps be taken.
First, proposals regarding cryptography should be moved beyond the
domain of the intelligence and national security community. Today, we
are increasingly dependent on computer communications. Policies
regarding the appropriate use of cryptography should be subject to
public review and public debate.
Second, any policy proposal regarding government eavesdropping
should be critically reviewed. Asking manufacturers and service
providers to make their services less secure will ultimately undermine
efforts to strengthen communications privacy. While these proposals
may be based on sound concerns, there are less invasive ways to pursue
legitimate government goals.
Third, government agencies with appropriate expertise should work
free of NSA influence to promote the availability of cryptography so
as to ensure communications privacy for the general public. The
National Academy of Science has recently completed two important
studies on export controls and computer security. The Academy should
now undertake a study specifically on the use of cryptography and
communications privacy, and should also evaluate current obstacles to
the widespread adoption of cryptographic protection.
Fourth, the export control restrictions for computer network
technology and cryptography should be relaxed. The cost of export
control restrictions are enormous. Moreover, foreign companies are
often able to obtain these products from other sources. And one result
of export restrictions is that US manufacturers are less likely to
develop privacy-protecting products for the domestic market.
As our country becomes increasingly dependent on computer
communications for all forms of business and personal communication,
the need to ensure the privacy and security of these messages that
travel along the networks grows.
Cryptography is the most important technological safeguard for
ensuring privacy and security. We believe that the general public
should be able to use this technology free of government restrictions.
There is a great opportunity today for the United States to play a
leadership role in promoting communications privacy. We hope to begin
this process by this call for a reevaluation of our national interest
in cryptography and privacy.
Mitchell Kapor, Electronic Frontier Foundation
Marc Rotenberg, CPSR
John Gilmore, EFF
D. James Bidzos, RSA
Phil Karn, BellCore
Ron Rivest, MIT
Jerry Berman, ACLU
Whitfield Diffie, Northern Telecom
David Peyton, ADAPSO
Ronald Plesser, Information Industry Association
Dorothy Denning, Georgetown University
David Kahn, author *The Codebreakers*
Ray Ozzie, IRIS Associates
Evan D. Hendricks, US Privacy Council
Priscella M. Regan, George Mason University
Lance J. Hoffman, George Washington University
David Bellin, Pratt University
Eugene Spafford, Purdue University
Steve Booth, Hewlett-Packard
Steve Kent
Dave Farber, University of Pennsylvania
------------------------------
Date: 20 Jul 91 18:12:23 GMT
From: sl4r7@cc.usu.edu
Subject: File 7--Reasonable laws on computer crime
All this talk of clamping down on hackers has made me think about what
would make good laws on computer crime. Below is a summary of what I
think would make for resonable laws on hacking (or cracking, whatever
you like to call it.) Note, I have probably left out several things.
I hope that a little bit of discussion will hone the list a bit and make it
nice and pretty. (Optimistic aren't I :-) )
I try to separate several of the activities into different crimes that vary
in seriousness. This list should go from the least serious to the most
serious, more or less.
1. Computerized Nuisance: Using a computer system and/or network or
communication system with intent to create a public nuisance.
This would be a light misdemeanor.
(This is meant to deal with those who do things like dial the entire
phone exchange or any like thing to make themself a pest. I
included intent to try to exclude those who are just incompetent
and didn't realize what they were doing.)
2. Computer Trespass: This would include accessing a computer system
without permission from the owner/operator. This does not include
failed attempts to login and would also be a misdemeanor.
(This is meant to cover those who break into a system and just
look around without causing damage.)
3. Computer Vandalism: Using a computer to access a computer system or
other service with intent to cause damage, but without intent to
profit financially. Dammage would include deleting files, reformating
disks, causing a crash, or depriving the owner/operator from using
the system or the data on the system. On a first offense with minimal
damage, this would be a misdemeanor. On second offenses or cases where
the damage was estimated to cost over $5,000? this could be a 3rd
degree felony.
(This should cover hackers who deliberatly crash a system as
well as ex-employees looking to get even. The latter is more
likely IMHO. The estimation of value would need to be done by an
unbiased third party.)
4. Computer Sabotage: As #3, but with intent to profit financially or
commercially. This would be a felony, possibly a 2nd degree if the
stakes were high enough. (I don't know how much this would be used,
but it's a possibility.)
5. Theft of Information: Using a computer and/or network or communications
system to obtain a copy of proprietary (non-public) data, information
or software that is of significant value ($1000? determined by
a third party) to the owner. I would divide this into two sections.
The first would be for people who never intended to profit from the
stolen information. This would be serious misdemeanor on the first
offence, and a felony on any following offenses. The second would
be for those who intended to make a profit. This would be a third
degree felony or perhaps a second degree felony if the value were
high enough and the offender had a record of this in the past.
Credit cards, calling cards: I think misuse of these should be covered
separately. Though if some one hacks a computer to get the card
numbers it would probably be covered by the above laws. (I think
they are already, perhaps some one who knows more about credit card
laws could add more.)
I haven't addressed laws about e-mail and the like, because I wanted to keep
it as specific to computer break-ins as posible. (And I'm out of time :-) )
So, what do you think? Wait a minute! I've got to get my asbestos suit on.
------------------------------
Date: Fri, 26 Jul 91 16:34:22 EDT
From: Jerry Leichter <leichter@LRW.COM.UUCP>
Subject: File 8--re: Bill Vajk's latest comments
I found Bill Vajk's comments in Cu Digest, #3.26 somewhat depressing.
Here's a bright guy, willing to take the time to, for example, wade
through legal texts, who still seems unable to separate what he WANTS
the law to say, so as to get the RIGHT outcome in some PARTICULAR
case, from what it either DOES say or SHOULD say as a matter of good
social policy.
Let's look at the matter of copyrights an publication first.
>I was unable to discover the exact requirements currently mandate for
>deposit of software in order to support a copyright.
First we need to get the language right. I know of no legal
significance to the term "support" with respect to a copyright. In
order to sue for copyright infringement (and ONLY in that case is such
action REQUIRED), you must first register the copyright with the
Copyright Office. The Office has regulations governing mandatory
deposit for registration (37 C.F.R. Chapter II, Sections 202.19 -
202.21). The regulations, as published in 1978, contain exceptions,
including (Section 202.19(c)(5)) "computer programs [and other things,
like databases] ... published ... only in the form of
machine-readable copies ... from which the work could not ordinarily
be visually perceived except with the aid of a machine...." In
October 1989, the Copyright Office issued final regulations governing
machine-readable copies. These regulations eliminated the exception
of 202.19(c)(5), authorizing the Office to demand deposit. Note,
however, that the demand is not automatic. Normally, the Copyright
Office only issues demands for material the Library of Congress tells
it it wants. Appendix B to Part 202 includes a statement that the
current policy of the Copyright Office and the Library of Congress is
to demand the deposit only of materials in PC-DOS, MS-DOS or "other
compatible formats such as Xenix [?]", or Macintosh formats.
So, deposit MAY be required. But WHAT must be deposited? If the
October 1989 regulations follow the proposed regulations issued for
comment in September 1986 - which I believe is the case - then deposit
of computer programs for which trade secret protection is also
claimed, which have been published only in machine-readable form, can
take one of four forms: The first and last 25 pages (or equivalent)
of source code, with no more than half the material blacked out; the
complete first and last 10 pages of source code; the first and last 25
pages of object code, containing at least 10 consecutive pages with
nothing blacked out; or, for programs of less then 25 pages, the whole
thing with no more than half blacked out. In addition, it is possible
to petition for exceptions or suggest alternative forms of deposit.
It's worth noting that, even if a full deposit were required, the
deposited information, while a matter of public record, is NOT really
fully public: It can be examined at the Copyright Office but may not
be removed or copied.
It's also worth noting that there is a completely separate deposit
requirement for the Library of Congress, mandated under a different
part of the law (Section 407 of the 1976 Copyright Act). This applies
only to published material, and there are a variety of exceptions. As
I noted before, failure to deposit under this regulation has no effect
on copyright, although it may subject you to fines.
>The Rose indictment calls the source code "confidential and
>proprietary." It is confidential in an AT&T security employee's dream,
>and that's about the extent.
AT&T provides copies of this software only under strict licenses. It
goes after violaters, and they've done so for years. (Consider the
Lyons book case.) While copies have "leaked", copies of the Unix
sources are by no means freely available. I think AT&T could make a
strong case for the claim that the sources remain "confidential and
proprietary".
>Leichter suggests that AT&T could claim to have never published the
>source code. This would be true if sale or offer to sell were a
>requirement. 17 USC addresses these issues with the term "vend"
>instead of "sell." The source code we're talking about has been
>published all right, and is in no way entitled to a "trade secret"
>status.
Nonsense. It's been licensed on a restricted basis. (Hardly anyone
sells software - you lose control of it too easily. No one I know of
sells sources.)
Two kinds of words occur in legal documents: "Terms of art"
(technical terms that have taken on specific legal meanings) and
normal English words. In copyright law, "publication" has essentially
its normal English meaning. Black's Law Dictionary, for example,
defines it as "The act of making public a book, writing, map, chart,
etc.; that is, offering or communicating it to the public for sale or
distribution of copies." ("Publication" used to be a very significant
event because it terminated the common-law copyright that protected
unpublished works, and started the clock running on statutory
copy-right protections. The 1976 Copyright Revision Act abolished
common law copy-rights, and the enabling registration under the Berne
treaty revised this area yet again, so the old concept is long dead.
Curiously, "publication" IS a term of art in another context: For a
will to be valid, it must be "pub-lished". However, in this case,
"publication" is accomplished by showing it to two (three?) witnesses,
whose signature is proof of such publication. "Publication" can also
become an issue in tort law: To sue for libel, you have to show the
material as "published". Again, there is a special meaning.)
Given the way AT&T licenses its source code, it is clear that they
don't intend to publish it. In fact, later in the same issue of Cud,
Craig Neidorf even includes a copy of AT&T's notice:
Copyright (c) 1984 AT&T
All Rights Reserved
* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T *
* The copyright notice above does not evidence any *
* actual or intended publication of such source code. *
AT&T is hardly alone in taking this route to protecting its sources:
It's a commonly-recognized technique, recommended by practitioners in
the field. I don't know if this has been tested in court, but keep in
mind that the judges who decide on the issue will come from the same
basic legal community that recommends the technique today. Mr. Vajk,
who thinks he knows better, will not be asked for his opinion.
Even in the unlikely case that a court threw out this method of
protection, I'll give you excellent odds that legislation would be
introduced in Congress within a very short time to restore it: The
computer business is just too important to this country, and too much
of the competitive advantage of American companies stems from software
protected under these terms. Congress won't care a whit about the Len
Rose's of this world, but they WILL act if they can be convinced that
the Japanese or the Koreans or whoever are about to walk in and copy
all this important American software, and that no one will be able to
stop them.
>Leichter defends the errors made by law enforcement, stipulating that
>they have to learn how to deal with computer crime. Agreed, in
>principle, but not in detail. The problems I am addressing have to do
>with the general approach law enforcement seems to be taking to
>solving all crime these days. The Constitution hasn't changed
>recently.
I suggest Mr. Vajk learn a little history. He might try, for example,
to talk to a Japanese-American citizen who spent time in American
internment camps in World War II. Or to a woman who needed an
abortion before Roe v. Wade. (Actually, he may soon be able to find
many women to talk to on that issue.)
>Essentially the same rules have applied to investigations. What does
>an officer have to learn about computer criminality in order to keep
>him from kicking in two doors because some law abiding individual
>tried to get into a bbs that was no longer a bbs? What does he have
>to be taught in order to have the patience necessaGolgo 13qñx ₧ÑéJonathanªæ δ 617-449-5165 SYSOPV╚ñô╓■ñô╒/ ╪x ▓▓ ,Φ P═Vƒ ? ? ┐ ? ? ? ? ? ?urse, but I'm not at all sure that more
of this goes on today than in the past.
Anyhow, let's get back to the case at hand and look at it from the
side of the police. They receive a report from a doctor's office
saying that someone is trying to break into their system. So, as a
start we have a complaint from a high-status individual. Beyond that,
if someone IS trying to break in, there is potential for serious harm:
Beyond the issues of privacy, ANY unauthorized access to medical
records has at least the potential to lead to incorrect diagnosis and
treatment, possibly causing someone grave harm. So this is certainly
worth investigating.
Anyhow, relying on the doctors, who the police assume know more about
their system than the police do, the police assume someone IS trying
to break in. They check the phone records and find one or two
suspects. The evidence available is sufficient to convince a judge to
issue a search warrant.
Now, you can already object and say "why not talk to the suspects
first". For a very simple reason: If they are, in fact, guilty
you'll likely find out nothing of value from them, but you'll tip your
hand and perhaps give them the chance to destroy evidence, something
that can be done very quickly on a computer. No, much safer to get
the search warrant first; that's exactly what search warrants are
supposed to be for.
Finally, the police show up at the suspect's house and find no one
there. The search warrant authorizes them to gain access to the house
and search it. It includes the authority to break in if necessary;
and policy probably says that a warrant should normally be executed as
quickly as possible. Why? I can think of at least two reasons:
Waiting may lead to someone being warned that the police have been
around (and consider how quickly evidence on a computer could be
destroyed by a simple phone call while the police wait patiently
outside); and, besides, posting an officer to wait for the return of
the suspect is expensive. Police departments are perpetually
under-manned, and if you phrase the question as "is the guy's front
door more important than the taxpayer's money, not to mention the
protection a cop doing something more useful than baby-sitting a front
door could provide" and you may see things a bit differently.
Does that mean that I think the action of the police was correct in
this instance? With 20-20 hindsight, it's easy to see that they too
quickly came to the conclusion that a crime was taking place. That's
a direct result of lack of training and experience with the computing
world. I hope they've learned from this experience; I'd bet they
have.
Given the realities of day-to-day law enforcement, I think they acted
reasonably given the limited time, data, and resources available to
them. I wish it could have come out differently, and I sympathize
with the computer owners who got so unlucky, but this is not a perfect
world and mistakes can and do happen.
>We are seeing some of the fallout from our permissiveness regarding
?RICO.
Actually, I don't really disagree with you here. What the police did
in this case is NOTHING compared to what Federal prosecutors under
Rudolph Guilliani did in various insider-trading cases. The publicity
almost got Guilliani elected mayor of New York; now, most of the cases
are collapsing in the courts.
>These issues have nothing to do with computer criminality as opposed
>to using sensible investigative techniques. Are we in an age where
>we've been subjected to so many shoot-em-up cops versus the bad guys
>TV shows that people here on usenet, among the best educated, most
>sensible souls in the US, can accept kicking in doors and summary
>confiscation of personal property as a valid and reasonable outcome
>from calling the wrong phone number a few times?
I don't accept it as a reasonable outcome; I accept that this is not a
perfect world, that law enforcement personnel must work under
conditions of limited training, information, resources, and time, and
under pressure from the public to "do something" about crime. Errors
happen. Sometimes the system is too rough; sometimes it's too
lenient. (Don't believe that? Try reading Cuckoo's Egg.) If you
know of a way to improve it, given the real world - not some ideal
world in which everyone is reasonable and honest - please, let's hear
about it.
------------------------------
Date: Sat, 27 Jul 91 14:51:21 EDT
From: Edward Vielmetti <emv@OX.COM>
Subject: File 9--Chaos Computer Club archives at titania.mathematik.uni-ulm.de
The archives of the Chaos Computer Club are at
titania.mathematik.uni-ulm.de:info/CCC/
Here's a rough translation into English of their READ_ME file.
- translation of titania.mathematik.uni-ulm.de:info/CCC/LIES_MICH
If almost all of the texts in the CCC Archive are in German, shouldn't
the READ_ME file be called LIES_MICH, eh? :-)
Here follows our electronic CCC Archive; everything about the CCC that
flies around on the networks should land here. Should. Anyone who
has anything else, texts or questions, or... ==> mail to ccc-ulm@rz.uni-ulm.de
For reasons of space most everything is in UNIX compress format. You
must transfer them in binary mode!
To transport them to VMS you must rename the files, since VMS has room
for only one "." in the filename and the VMS compress uses the suffix
_Z.
==> ftp> binary
ftp> get "blubber.blaeh.Z" blubber.bleah_z
(should work with most VMS ftps, or try it without the "")
If you want to transfer the files through a gateway, like e.g. BITFTP,
then they need to be uuencoded, otherwise you get data salad
[Datensalat]. See bitftp.txt.
First uudecode, then decompress, and the text files will be readable.
For VMS, Atari-ST, MS-DOOF uhh.. MS-DOS and Amiga there are files in
the directories under soft/tools to for unpacking. If you have
compress and uudecode for other operating systems, please send me the
programs.
Contents:
=========
chalisti Network newspaper
congress Text and documentation from the yearly Chaos
Communication Congress
dokumente diverse and various documents
eV Information about the organization itself
listen Lists of NUAs, BBSes etc. [NUA? --Ed]
virun Documents about computer viruses
have phun Framstag (framstag@rz.uni-ulm.de)
-- MSEN Archive Service file verification
titania.mathematik.uni-ulm.de
total 16
drwxrwsr-x 2 ftp-adm 512 Jun 8 12:06 chalisti
-rw-rw-r-- 1 ftp-adm 5491 May 15 13:21 LIES_MICH
-rw-rw-r-- 1 ftp-adm 3890 May 15 01:41 ls-lR
drwxrwsr-x 2 ftp-adm 512 May 14 21:03 listen
drwxrwsr-x 4 ftp-adm 512 Apr 21 19:33 congress
drwxrwsr-x 2 ftp-adm 512 Apr 19 21:10 eV
drwxrwsr-x 2 ftp-adm 512 Apr 19 19:43 dokumente
drwxrwsr-x 2 ftp-adm 512 Apr 18 21:29 viren
found chaos-computer-club ok
titania.mathematik.uni-ulm.de:info/CCC/
------------------------------
Date: Mon, 22 Jul 91 14:44:12 MET
From: afp!gna!comsat!coop@TFD.COM (Agent Cooper)
Subject: File 10--Late reply to Dutch Crackers article (CUD3.19)
First I want to make clear that I'm not one of the 'hackers' who broke
into american military computers. I'm a friend of them and was asked
to reply on the article in the last CUD.
There doesn't exist an organized group in Holland that is 'hacking'
american military computers, about 8 'hackers' not organized as a
group which are in some case friends of eachother but in most cases
don't know eachother were targeting military computers in 1990. Some
of them are still doing this others switched to other systems and
areas of 'hacking' in search of new challenges.
The 'hackers' are high-school-students, programmers, university
students and software developers, all with a considerable knowledge of
various computer systems. They didn't use 'hacker cook-books' but used
mostly new /forgotten software bugs which they found themselves. Many
CERT advisories conceirning system security in 1990 were a direct
cause of this. Their main goal wasn't only finding new bugs, curiosity
or boredom it was a mixture of those. Because they sometimes 'hacked'
over 400 computers per day (per hacker) their activities looked
pre-fabricated.
Not only military computers on the internet were searched but also
systems on X.25 and dialups. The information was in some cases
confidential. Files which I have seen contained very sensitive
(marked confidential etc.) information (from accidents to spy reports
& such) that made the information found by the hackers from 'the
cuckoo's egg' and the 'LOD E911' people look like child-play. The
information was not falsified as far as I could see, things I checked
were all true. Most of the 'hackers' are conceirned about what they
found and some even contacted U.S. government agencies.
What was shown on dutch television didn't have to do much with this.
The person on TV. was no 'hacker'. It was a friend of a 'hacker' in
need of money who got a harmless account on a U.S. military computer.
The Utrecht university gateway shown was seldomly used by the real
'hackers' and was expendable for the TV show.
At the end of 1990 some of the hackers noticed certain gateways &
system were being monitored, which didn't really bother them cause
they switched paths & routines regularly. In the last issue of the
dutch hacker magazine 'Hacktic' (C. Stoll seems to read it looking at
his remarks) there was an article in which they published traces,
logfiles and personal mail of system operators and security people.
>From these files you can see that the problem in Holland isn't that
there is no real law against hacking but that the problem is that they
can't find the 'hackers'. There have been cases in Holland in which
