The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1988)
DOCUMENT: Rutgers 'Security List' for February 1988 (27 messages, 22726 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1988/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
From:      _*Hobbit* <HOBBIT@aim.rutgers.edu>  3-FEB-1988 21:39
To:        HOBBIT@aim.rutgers.edu
Somehow I don't think going to town papers would do jack.  Media people
wouldn't understand what you were driving at, and would probably make a
complete botch of the resultant story that would make *everybody* look bad,
on both sides of the battle.

_H*
-----------[000001][next][prev][last][first]----------------------------------------------------
From:      DORFMAN@ECLA.USC.EDU  5-FEB-1988 12:34
To:        security@aim.rutgers.edu
     The Data Systems Engineering organization at Lockheed in 
Sunnyvale, Calif., is establishing a small technical library, and 
we would like to obtain one book on Computer Security.  The book 
would be used as a technical introduction for software 
professionals with no specific background in computer security.
     We would appreciate any recommendations that readers of the 
Security List can provide.  If there is sufficient response, I 
will post a summary to the List.

Merlin Dorfman
ARPA: DORFMAN@ECLA.USC.EDU
UUCP: ...ucbvax!sun!sunncal!leadsv!laic!cosmos!galaxy::dorfman
408-756-8204
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      Nick Papadakis <nick@mc.lcs.mit.edu>  8-FEB-1988 13:03
To:        ROMKEY@XX.LCS.MIT.EDU
   From: Philip A. Earnhardt <S.PAE@DEEP-THOUGHT.MIT.EDU>
   A display ad on Page 10 of today's (7 feb 88) Sunday New York Times:

		!!! ANTI-VIRUS PROGRAM !!!
   NOW AVAILABLE. Anti Virus diskette that locates and eliminates unwante
   software viruses once and for all. $99.00 each. To place your order....

	Technology recapitulates phylogeny!

	A neat way to implement this would be as a 'benificent' virus
that runs around zapping any *other* viruses it finds.  But who watches
the watchmen, eh?  Maybe this $99 'immune system' has AIDS ...

	More evidence that security is simply a waste of time.

		- nic
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      decvax!decwrl!sun!seismo!esosun!dcdwest!sarge@ucbvax.Berkeley.EDU  9-FEB-1988 19:17
To:        AIM.RUTGERS.EDU!HOBBIT@sundc
I am a security officer for CPP Security Services here in San Diego
and have been for over 8 years now.

California Plant Protection (in Ca.) or CPP Security Services for
other parts of the country is a well organized company and they
even pay a liveable wage. When CPP bought Pinkerton Security you
can believe that CPP Paid a Hefty Sum. Most of the CPP Area
Managers act half way human to the guards. 

I may be a contracted Security Officer but I'm a professional one.

		Bob Heddles
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      andrew@frip.gwd.tek.com (Andrew Klossner)  10-FEB-1988 09:51
To:        misc-security@tektronix.tek.com
	"Is there any way to find out if someone else is using your
	SSN?"

You can query the Social Security Administration for a statement of
your earnings, which will reflect FICA tax payments for your account.
If there are extra payments, you can followup to find their source.

>From a RISKS article by Lance P. Keigwin (lance@ubvax.UUCP):

	"You can only get a complete record by seeing a Service or
	Claims representative, who must complete an SSA-450 for
	transmission to HQ in Baltimore.  Insist on a photocopy of it
	when it arrives.  Be troublesome, if necessary."

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com@relay.cs.net)   [ARPA]

-----------[000005][next][prev][last][first]----------------------------------------------------
From:      <NRAMESH@ecncdc.bitnet>  10-FEB-1988 09:51
To:        <security@rutgers.edu>
 I am looking for information on disaster planning for University computer
Centers.  I will appreciate any help.  Thanks
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      David S. Hayes <hqda_ai!merlin@uunet.uu.net>  10-FEB-1988 09:51
To:        uunet!misc-security@uunet.uu.net
     I'm interested in locks just out of curiosity.  (I don't have
my cat anymore.)  I'd like to take a locksmithing course, but I
don't know how to go about selecting one.

     I'd like a correspondence course.  It doesn't have to cover
every last technical innovation invented since last Tuesday, but
should be reasonably current.  Mostly I'm interested in things
like car and house locks, not the high-security electronic stuff.
It must be relatively inexpensive, since this is only a hobby.
Finally, it must provide whatever certifications are necessary to
get the basic tools of the trade.

     Recommendations gratefully accepted.  Thanks.
-----------[000007][next][prev][last][first]----------------------------------------------------
From:      dnelson@ddsw1.UUCP (Douglas Nelson)  10-FEB-1988 09:51
To:        codas!misc-security@rutgers.edu
Concerning tracking down the useage of your Social Security number, I once
worked for a company that subscribed to Trans-Union credit checking.  This
company offered you the ability to do a social security number trace, where
any occurances of your social security number in the country that would occur
from things even as small as a declined credit application would show.

This command was merely typing in 'TRCE xxxyyzzzz' and it would come back
with all the occurances of that SS number, and the applicants and/or account
holders, as well as their current and previous addresses.

I distinctly remember several times doing this (we did it in order to see
if the individual had credit at another address, etc) and having more than
one person show up under the identical SS number, and although occasionally
it may have been due to a mis-typing on the part of the data entry person
originally, most of the time it belonged to an addressee somewhere in Florida
or California or New York with a seemingly foreign name.

All I could suggest is that you go to your local credit checking agency and
see if they use Trans-Union credit checking or a compatible one that would
offer such a service.

I suppose it is pretty common knowledge that the first three digits of your
Social Security number indicate where you were born.  We also used that in
order to verify job applications when doing a background check.

------------------
Douglas Nelson
dnelson@ddsw1.UUCP
------------------
-----------[000008][next][prev][last][first]----------------------------------------------------
From:      mcvax!ethz!prl@uunet.uu.net (Peter Lamb)  10-FEB-1988 09:51
To:        cernvax!misc-security@uunet.uu.net
Just to show that these things tend not to work anyway;
on a U**x box near me there is a copy of the Unix `secretmail'
stuff (public key encrypted local mail). The manual entry has a big
notice saying `not to be exported'.
The same company does not export `crypt'.

Of course this is irrelevant, since we have licensed Unix source
which predates the ban; it includes both crypt and secretmail.

I think the argument used by DEC etc, that it would cost too much
is a bit odd. Have they ever calculated how much it costs to
make two different distributions of their software? And not-for-export
software gets distributed anyway....

-- 
Peter Lamb
uucp:  seismo!mcvax!ethz!prl	eunet: prl@ethz.uucp	Tel:   +411 256 5241
Institute for Integrated Systems
ETH-Zentrum, 8092 Zurich
-----------[000009][next][prev][last][first]----------------------------------------------------
From:      Daniel Keizer <busu%cc.uofm.cdn@UBC.CSNET>  10-FEB-1988 14:41
To:        security@aim.rutgers.edu
An interesting note on PC-lock was recently posted.  I have seen PC-LOCK in
use and am quite impressed with the actual design of the program ... can't
remember the person who wrote this fine program though.  The program gives
you enough security that only someone who understands hard disks and the 
PC computer will be able to break it.  There is no way that I know of to
break the security by brute force, although there is a very easy way to
by-pass it.  I am not sure if I should be revealing this way or not, but
security by non-disclosure is no security at all.

PC-LOCK writes a new master hard disk boot block, just like FDISK.  But this
one has its own boot code.  As well, you might notice that when you boot
from a floppy, the hard disk light goes on for a second ... dos is reading
the hard disk to try and determine if it is valid.  It knows if it is
valid by modifying the last two bytes (ID field)  from 55 AA (hex) and 
it simply zeroes out one of those bytes.  So, booting from a floppy won't
recognize a hard disk in this fashion (invalid drive spec ...) but when booting
off of the hard disk itself, PC-LOCK takes hold and recognizes itself, and
boots up fine with the CLEANDSK.DRV device driver.  (which is where the 
password stuff is.)  

The actual driver program itself and the installation programs are *VERY*
well protected.  The author must be commended with his attempts to hide
his code (self-decrypting).  

The simple way to by-pass this is to use FDISK to reclaim the whole disk
back again.  You would have to get to that point by some other means.
Experimentation is fun.  The person un-protecting the disk in this means
would have to know the partition boundaries in order to make it work, but
PC-LOCK does not (as far as I can determine) work with more than one
partition (such as a UNIX/MINIX partition).  Nor would it work with a friends'
AT&T 6300.  Not sure why.  Anyone else have any experiences with PC-LOCK?

Dan Keizer
BUSU@CC.UOFM.CDN
BUSU@UOFMCC.BITNET
-----------[000010][next][prev][last][first]----------------------------------------------------
From:      simsong@amsterdam.columbia.edu  11-FEB-1988 02:10
To:        MSRS002%ECNCDC.BITNET@cunyvm.cuny.edu
Cc:        security@aim.rutgers.edu
Questions about the Novell Netware software:
1. What prevents the user from taking a snap-shot of memory and making
their own .EXE or .COM?

2. For that matter, what pervents them from using the DOS LOAD_PROGRAM
call, (without the execute-program version), to get a perfect image?
(This is how one program loads in overlays.  I do it all the time.)

3. I gather that the way EXECUTE ONLY works is that Novel has patched
DOS so that when it wants to read the blocks of an EXECUTE ONLY
program to load it into memory, it uses an undocumented BIOS READ DISK
BLOCK function.  Or would that be too simple?

................................................................simson
-----------[000011][next][prev][last][first]----------------------------------------------------
From:      sri_spam!csib!lgold@rutgers.edu  11-FEB-1988 18:08
To:        security@rutgers.edu
The version of Empire for the Atari ST has a cute protection scheme that
looks relatively easy to implement.  In order to run the program, you
have to have a copy of the manual.  Why?  The program asks you to type
in "the Nth word on page M" where N and M are two randomly selected
numbers.  If you don't have the manual in front of you, you can't type
the word in and can't run the program!

It doesn't necessarily stop people from copying the program, but it DOES
make it more of a pain-in-the-you-know-what to do so.

--Lynn
-----------[000012][next][prev][last][first]----------------------------------------------------
From:      Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>  13-FEB-1988 15:52
To:        "THE DOCTOR." <MSRS002%ECNCDC.BITNET@CUNYVM.CUNY.EDU>
   ... the .EXE files are
   flagged EXECUTE ONLY.  The only thing you can do to an execute only file is
   execute it and, if you're the system administrator, erase it.  All the extra
   files associated with the program are marked SHARABLE READ ONLY ( with a
   few annoying exceptions ).

Unless the programs wind up executing on the server (which doesn't
appear to be the case), there is no significant security difference
between labelling a file execute-only, and labelling it read-only; the
client has to be able to read the file across the network in order to
copy it into its address space to execute it.  If the students can
boot an arbitrary floppy on the PC's, or if they can patch the
operating system, they can get around this pseudo-security on the
client side.  This system may very well make it harder to steal the
software if you don't have source or symbol tables on the network code
and the protocols themselves are unpublished.  However, if you think
this is ``secure'', you're wrong.

Access control does no good on a network unless it is enforced on the
server end; the distinction between `read executable' and `read' is
enforced by the _client_, not the server.

					- Bill
-----------[000013][next][prev][last][first]----------------------------------------------------
From:      hp_sdd!dag@hp_lsd.hp.com  16-FEB-1988 18:08
To:        sdcsvax!misc-security@rutgers.edu
Tie the  operation of the software to a piece of hardware.  i.e.,
send a piece of HW that can be read by the PC.  Perhaps it has to
be inserted in the joystick loop, perhaps it has to be plugged on
to an RS-232 port, etc.

The  software  can be copied and  pirated,  but without the right
piece of HW on the system too, it won't run.
-----------[000014][next][prev][last][first]----------------------------------------------------
From:      "John O. Rutemiller" <Rutemiller@DOCKMASTER.ARPA>  18-FEB-1988 08:46
To:        security@aim.rutgers.edu
In the February 1988 issue of Popular Science there is an artical on
page 117 which talks about driveway detectors and lists some different
sources.

John
-----------[000015][next][prev][last][first]----------------------------------------------------
From:      "Robert W. Baldwin" <BALDWIN@xx.lcs.mit.edu>  19-FEB-1988 02:38
To:        security@rutgers.edu
	Does anyone have infomation about the capabilities and limitations
of police radars for speed checking.  I'm looking for both technical
limitations of the devices and for procedural limitations that are
necessary to make a ticket stand up in court.  I'm aware that many state
courts do not accept radar evidence and others (like california) only
allow it to be used in a few places.
	One technical limitation seems to be that the device must have
a stable speed reading before it displays a speed for the officer.  One
two occassions I've seen a car suddenly slow down, and avoid getting a ticket.
On another occassion I saw two cars zoom past a police car, neither was
stopped, but when a single car passed doing the same speed, it was pulled
over.  This seems to be a procedural limitation to avoid the defense of
a driver claiming that the other car was speeding.
	Comments?

		--Bob
-----------[000016][next][prev][last][first]----------------------------------------------------
From:      Clement Taylor <CGTAYLO%erenj.bitnet@rutgers.edu>  22-FEB-1988 12:36
To:        Security Conference <SECURITY@rutgers.edu>
Gentlemen, I am the BITNET coordinator at Exxon Engineering. Does a
compendium exist of recent transmissions on this conference? I am
particularly interested is what is being discussed regarding "viruses"
CHRISTMAS EXECs etc. I may be called upon to justify our continued
participation in BITNET in light of these threats.  Thank you for your
assistance.
                                 Regards,
                                 Clem Taylor
                                 Exxon Research & Engineering
                                 180 Park Avenue
                                 Florham Park, New Jersey 07922
                                 (201) 765-3338

[Moderator note: Archives exist here at aim.rutgers.edu, but I don't recall
ever having seen anything about IBM-machine viruses.  Do some of you Bitnet
folks have more info?  _H*]
-----------[000017][next][prev][last][first]----------------------------------------------------
From:      Wm Brown III <Brown@GODZILLA.SCH.Symbolics.COM>  25-FEB-1988 17:07
To:        "David S. Hayes" <hqda-ai!merlin@uunet.uu.net>
I researched this several years ago and found that most of the commercially
available courses aren't worth your time and money unless you actually wish
to go into business as a locksmith.  Since most 'serious' students are being
funded by the VA or some other government program, the courses are geared to
absorb the exact number of dollars provided by these agencies and include a
large amount of information necessary for someone operating a business, but
of no interest to anyone else -- things like how to install locks or fix door
closer mechanisms.  Most of these programs are also aimed at students with 
very limited educations, and you will probably find them pretty boring.

The only way to learn about locks is to work with them.  Instead of spending
your money on a course, go out and buy a sample of each major type.  Take
them apart, put them back together, and play with them until you understand
and appreciate the subtleties of their designs.  You may wind up destroying
a few, but in doing so you will learn a lot.

There are a few good books on the subject.  One is published by TAB books,
(they also print a lot of basic electronics and computer introductory texts).
Some of the others, including some pretty sophistocated references which were
considered secret within the trade ten years ago, may now be bought from some 
of the companies which sell books on survival, weapons, Ninja-whatever, and 
other sleazy topics.  Many of these advertise in gun mags or (I am told) in 
some of the weekly tabloids seen at the supermarket.

The hardest part, by far, will be obtaining specialized tools such as picks
and raw materials like key blanks.  If you can find a local locksmith who is
willing to trust you, that's the best bet.  Otherwise, you may have to pay
scalper prices through the mail-order sleaze merchants mentioned above.  I
would start by asking the 'smith to sell you a Pippin file, which you will
need anyway.  This is a fairly innocuous instruent, and asking for one may
just get your foot in the door.

Finally, beware of legal problems.  In many places, possession of locksmithing
tools is grounds for arrest.  The burden will be on you to prove that you are
really a serious hobbyist!
-----------[000018][next][prev][last][first]----------------------------------------------------
From:      GOLD::HOBBIT 26-FEB-1988 08:54
To:        NET%"security-list",HOBBIT
[Here are the responses collected so far.  _H*]

Date: Sun, 14 Feb 88 14:54:56 EST
From: ncoast!smith%ncoast@mandrill.CES.CWRU.Edu
Subject: Computer Security Introductory Text

May I suggest _UNIX_System_Security_ by Patrick H. Wood & Stephen G. Kochan
published by Hayden Books (Division of SAMS)
ISBN: 0-8104-6267-2    $34.95 Retail.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Tue, 16 Feb 88 11:04:06 EST
From: "Michael J. Chinni, SMCAR-CCS-E" <mchinni@ARDEC.ARPA>
Subject: Re:  Computer Security Introductory Text

  Try contacting the following:
Computer Security Institute
43 Boston Post Road
Northborough, Massachusetts,   01532
(617)845-5050

  They put out a "Computer Security Handbook" that I have found very
interesting from a novices point-of-view.

	Mike Chinni <mchinni@ardec.arpa>

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Tue, 16 Feb 88 13:44:50 -0500
From: edelheit%community-chest.mitre.org@gateway.mitre.org
Subject: Re: Computer Security Introductory Text

I would suggest that you look at "Tutorial: Computer and Network
Security" by Abrams and Podell.  It is published by IEEE Computer
Society Press (order # 756).  It can be ordered by calling 
1-800-CSBOOKS.

Jeff Edelheit		(edelheit@gateway.mitre.org)
The MITRE Corporation	7525 Colshire Drive
McLean, VA   22102		(703) 883-7586
-----------[000019][next][prev][last][first]----------------------------------------------------
From:      goldstein%star.DEC@src.dec.com  26-FEB-1988 11:14
To:        SECURITY@aim.rutgers.edu
[Moderator note: Thanx also to Chris Kent <kent@decwrl> for forwarding this
as well; one outgoing copy is plenty...   _H*]

I read John Gilmore's mail, forwarded to SECURITY a few months ago,
with great interest. I wondered, could our export control laws really
be as rational as he claims? So I forwarded the memo to our company
export lawyers for comment. I am not really surprised at the outcome:
we are not so lucky. John's arguments are incorrect, and export of
all crypto software is in fact strictly regulated. I attach the gory
details I got back from our lawyers.

There have been some other comments recently to the effect of "why
bother regulating crypto export when it slips out anyway with public
comain software". There are a couple of things to be said:

(1) Like it or not, it's the law. Large corporations like DEC operate
    at a high level of visibility, and must hew to the straight and
    narrow far more than garage shops and private individuals. If we
    screw up legally, you can guarantee the government will be on our
    case pronto. We still have painful memories of the 782 fiasco a
    couple of years ago. That and related events at the time cost the
    company $1.5M to get its export license back, when
    (a) the export controls in question were Dept. of Commerce, and
    (b) it was far less clear that we had actually violated any laws.

(2) Given our general climate of free trade and communication, it is
    inevitable that some crypto software will slip past the export
    controls. The government does not have the resources to go after
    each individual violation. However, you can rest assured that
    repeated violators will be (and have been) brought on the carpet.
    Keep in mind that the "public" networks are to a large extent
    funded with government money. If a pattern of export violations
    develops on these networks, their very existence could be jeopardized.

					Andy Goldstein
					VMS Development
********************************

    _____________________________
    |   |   |   |   |   |   |   |
    | d | i | g | i | t | a | l |    I n t e r o f f i c e  M e m o
    |___|___|___|___|___|___|___|

TO:  "TO" Distribution               DATE:  16 February 1988  
                                     FROM:  Tom Ehrgood
CC:  "CC" Distribution               DEPT:  Corporate Law
                                     TEL:   (202) 383-5698
                                     LOC:   WNP

SUBJECT: Controls Over The Export Of Cryptographic Software

This memo answers points made in an October 27, 1987, memo by John
Gilmore, which we received on January 28th.  Gilmore's memo, which I am
separately forwarding, argues that the posting of cryptographic software
to certain widely available bulletin boards places that software in the
"public domain," with the consequence that export licenses are not
required for the exports of that software.  Gilmore's analysis has been
given wide distribution on various networks. 

Gilmore is mistaken in his analysis and in his conclusion.  Given the
high national security sensitivity of cryptography, generally, and DES
encryption, specifically, it is important to set the record straight.

The fundamental points that Gilmore gets wrong are:

  o  Exports of cryptographic software are governed by the State
     Department's International Traffic in Arms Regulations ("ITAR"),
     not by the Commerce Department's Export Administration
     Regulations ("EAR").  Exports would be governed by Commerce's
     EAR only if State waived jurisdiction.

  o  Although State Department regulations contain a "public domain"
     exemption for technical data, cryptographic software does
     not qualify as "technical data," and thus the "public domain" 
     exemption does not apply.

A legal analysis follows.

                              DISCUSSION

I.  State Department Control Over Cryptographic Software
    ----------------------------------------------------
  
    A.  Cryptographic software is a "defense article" 
        ---------------------------------------------

Section 38 of the Arms Export Control Act authorizes the President to
control the export and import of "defense articles" and "defense
services."  This statutory authority -- which includes the authority to 
to "designate those items which shall be considered as defense articles 
and defense services" -- was delegated to the Department of
State, which in turn has implemented the statutory authority through
promulgation of the International Traffic in Arms Regulations ("ITAR"),
22 C.F.R. Subch. M.  

The term "defense article" is defined in section 120.7 of ITAR to mean 
"any item designated in section 121.1," which contains the United States 
Munitions List.  

Category XIII of the Munitions List provides in paragraph (b) as 
follows:

    Speech scramblers, privacy devices, CRYPTOGRAPHIC DEVICES AND 
    SOFTWARE (ENCODING AND DECODING), and components specifically
    designed or modified therefore, ancillary equipment, and protective
    apparatus specifically designed or modified for such devices, 
    components, and equipment.  (Emphasis added.)

Since "cryptographic . . . software" is thus included on the United 
States Munitions List, it is a "defense article" subject to the State 
Department's ITAR controls over exports of such articles.

At certain low thresholds, it may not be clear whether software
containing certain encryption functionality in a technical sense
constitutes "cryptographic software" within the meaning of Category
XIII(b), above.  Section 120.5 of ITAR establishes a procedure under
which "[t]he Office of Munitions Control will provide, upon written
request, a determination on whether a particular article is included on
the United States Munitions List."  Questionable cases may be resolved 
by following this procedure.

Assuming that encryption software does constitute "cryptographic 
software" within the meaning of Category XIII(b), State Department 
export licenses are required, REGARDLESS OF WHETHER THE ENCRYPTION IS 
BASED ON THE DES ALGORITHM.  The relevance of DES vs. non-DES lies in 
the ease with which licenses can be obtained, not in whether licenses
are required. 

    B.  The State Department's "public domain" exemption does not
        apply to exports of "defense articles."
        ---------------------------------------------------------

Part 123 of ITAR contains rules governing export licenses for the export 
of "defense articles."  The basic rule is stated in Section 123.1(a) as
follows:

    Any person who intends to export a defense article must obtain a
    license from the Office of Munitions Control prior to the export 
    unless the export qualifies for an exemption under the provisions 
    of this Subchapter.

Part 123 sets forth a number of exemptions in sections 123.16 through
123.22.  None is these exemptions covers the posting of cryptographic
software on a bulletin board. 

Section 126.5 exempts from the licensing requirement any exports of
unclassified defense articles or unclassified technical data to Canada
for end-use in Canada or return to the United States.  This exemption 
would be potentially applicable only if the ONLY exports that might take 
place as a result of the bulletin board posting were exports to Canada.  
(See section 120.10, which defines "export" to include "[s]ending or
taking defense articles outside the United States in any manner.")  In
any event, care would have to be taken to ensure that applicable
documentation requirements are met to invoke properly the exemption. 

Part 125 of ITAR contains rules governing exports of technical data.  
Section 125.1(a) provides:

    The export controls of this part apply to the export of technical
    data . . . . Information which is in the "public domain" (see 
    section 120.18) is not subject to the controls of this chapter.

Section 120.18 defines "public domain" as follows:

      "Public domain" means information which is published AND WHICH 
    IS GENERALLY ACCESSIBLE TO THE PUBLIC:
      (a) Through sales at newstands and bookstores;
      (b) Through subscriptions which are available without restriction
    to any individual who desires to obtain or purchase the published
    information; 
      (c) Through second class mailing privileges granted by the U.S.
    Government; or,
      (d) At libraries open to the public.

(Emphasis added.)  This definition is a much more restrictive one than 
the analogous Commerce GTDA regulation analyzed by Gilmore:  a bulletin 
board posting of information would not fall within ITAR's public domain 
unless that posting qualified under paragraphs (a)-(d) of section 
120.18.  A posting would not appear to so qualify.  (This memo does not
take any position on whether bulletin board posting would place
Commerce-controlled technical data into Commerce's public domain;
specific information about the technical data and the bulletin board
would be necessary.) 

Regardless of how the ITAR "public domain" applies to bulletin board
postings in general, the posting of cryptographic software cannot fall
within the "public domain" provision, because, per section 125.1(a) 
above, the "public domain" provision applies to "technical data."
Cryptographic software -- a "defense article" (see Section I.A above) --
does not constitute "technical data" under ITAR.  More on that below.

The term "technical data" is defined in section 120.21 as follows:

      "Technical data" means for purposes of this subchapter:
      (a) Classified information relating to defense articles and
    defense services;
      (b) Information covered by an invention secrecy order;
      (c) Information which is directly related to the design,
    engineering, development, production, processing, manufacture,
    use, operation, overhaul, repair, maintenance, modification, or
    reconstruction of defense articles.  This includes, for example,
    information in the form of blueprints, drawings, photographs,
    plans, instructions, computer software and documentation.  This
    also includes information which advances that state of the art of
    articles on the U.S. Munitions List.  This does not include 
    information concerning general scientific, mathematical or 
    engineering principles.

"Technical data" per this definition thus consists either of 
information "relating to defense articles" (par. (a)) or information 
directly related to the doing of things to "defense articles" (par. (c)).
[Paragraph (c) is not relevant here.]  Since cryptographic software is
itself a "defense article," it cannot simultaneously qualify as
"technical data."  Moreover, different ITAR Parts govern exports of
"defense articles" (Part 123) and exports of "technical data" (Part
125). 

Of course, not all encryption materials (DES or otherwise) necessarily
take the form of "cryptographic software" controlled under Category
XIII(b) of the Munitions List.  Non-Category XIII(b) materials will
qualify as "technical data" within the meaning of the section 120.21 and
will thus be eligible for "public domain" treatment if the specific ITAR
conditions apply. 

II.  Commerce Department Controls Over Cryptographic Software
     -------------------------------------------------------- 

Section 370.10 of Commerce's Export Administration Regulations state the
general rule that Commerce does not control exports of State
Department-controlled items.  Specifically, subsection (a) provides: 

    (a) U.S. Munitions List.  Regulations administered by the Office of
    Munitions Control, U.S. Department of State, Washington, D.C. 20520,
    govern the export of defense articles and defense services on the U.S.
    Munitions List. 

Thus, Gilmore's statement that the State Department's concerns about 
exports of crypt commands are "enforced" by Commerce is wrong.

What has complicated the picture and confused Gilmore is that Commerce's
Commodity Control List -- Commerce's counterpart to the United States
Munitions List -- contains a category 1527A covering "cryptographic
equipment . . . and software controlling or performing the function of
such cryptographic equipment."   Gilmore identified this regulatory control 
provision, but he misinterpreted it.  

Gilmore found the note in category 1527A, which states that 

    Exporters requesting a validated license from the Department of 
    Commerce must provide a statement from the Department of State,
    Office of Munitions Control, verifying that the equipment 
    intended for export is under the licensing jurisdiction of the
    Department of Commerce.

Gilmore mistakingly says, however, that "we are not requesting a
validated license, we are using the general license, so this requirement
does not apply . . . ."  Gilmore missed the 1527A heading: "Validated
License Required:  Country Groups QSTVWYZ."  These designated country 
groups comprise every country in the world except Canada.  Consequently, 
a validated license issued by Commerce is required in order to make any 
export of 1527A-controlled cryptographic software.  And because a
validated license is required, exporters seeking such a license must,
per the note quoted above, submit a State Department statement
"verifying" that Commerce has jurisidiction over that cryptographic
software.  Such a statement would generally take the form of an ITAR
section 120.5 commodity jurisdication determination. 

In sum, unless the State Department has issued a statement verifying
Commerce jurisdiction over the cryptographic software that Gilmore has
in mind, Commerce's controls do not apply.  And without such a
statement, Gilmore's analysis of section 379.3 of EAR (General License
GTDA) is completely irrelevant. 

III.  Conclusions
      -----------

Gilmore's conclusion that the posting of cryptographic software to a 
bulletin board places it in the public domain and thus exempts it from 
export licensing controls is flat-out wrong.  U.S. law is clear:  in 
order to export "cryptographic software" within the meaning of 
Category XIII(b) of the United States Munitions List to any country 
other than Canada, a State Department export license is required.
If there is any reason to believe or suspect that a non-U.S. or 
non-Canadian national will gain access to that bulletin board, an export 
to a third country should be assumed and a license is required..

If there is any question whether specific encryption software 
constitutes "cryptographic software" within the meaning of 
Category XIII(b), clarification can be obtained under procedures 
established pursuant to section 120.5 of ITAR.

A determination from State under 120.5 that it does not have 
jurisdiction is the prerequisite to bringing the control question into 
Commerce's export regulations.  

IT IS IMPERATIVE THAT NO DIGITAL EMPLOYEE ACT IN RELIANCE ON GILMORE'S
ANALYSIS OR HIS CONCLUSIONS. 
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 88 10:34:51 CST
From:      Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>
To:        security@aim.rutgers.edu
Subject:   SSNs, the SSA, and giving out info
[There was another burst of SS-related messages, the gist of which was that
was that the first three digits might indicate the card's area of origin.  
In addition, there was more about the privacy issue.  Here are some of the
msgs...  _H*]

************************

Date: Thu, 25 Feb 88 10:34:51 CST
From: Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>
To: security@aim.rutgers.edu
Subject: SSNs, the SSA, and giving out info

> I suppose it is pretty common knowledge that the first three digits of your
> Social Security number indicate where you were born.  We also used that in
> order to verify job applications when doing a background check.

Does someone have this info on-line that they could post it to this list?
I'd like to have a copy of the data; it can't be more than 1000 lines long,
so it could be sent out.

Also, in the light of the long-term discussion of SSNs and just what
info the SSA will give out on you (or others), I was rather surprised to
read the following in a recent local newspaper advice column. (St. Louis
Post-Dispatch, "Martha Carr" (fake-name local advice column)):

Dear Martha: I have an older first cousin with whom I communicate only
at holiday time, by Christmas and birthday cards. Our Christmas card to
her was returned this year, and we did not receive one from her. Is
there some place we could check to see if she is still alive? She was
working at the local water company, but I don't know the name of it. She
is 63 and widowed, with no children.

ANSWER: You might call the long-distance operator for the region in which
your cousing worked for the name of the water company there and then check
with the personnel office staff for such information as is available.

If they cannot answer your questions directly, they may be willing to
give you her Social Security number. You can then trace her whereabouts
through the Social Security Administration.     <----!!!! What?!?!?!!!---WM

At 63, she may have retired, and if she is receiving Social Security
payments, you might be able to get her current address. If she is
deceased, the SSA should be able to tell you that, also.
***END***

Wow! I have not yet had the chance to go by an SSA office to ask about
that; there's one in the government-offices building in which I work,
but I've been busy and they always have long waiting lines. But I mean
to check this out. I can't believe that the newspaper advice columnist
would publish this if they hadn't already checked with the SSA to find
out if this is really something that SSA does, but it sure goes against
ALL the stuff I've seen on the net about this topic for years!

I'll follow up when I find out more. I don't read the paper regularily,
so I don't know if there was a later column retracting this claim.

Will Martin


Date: 25 Feb 88 20:11:25 GMT
From: matt@brl-smoke.arpa

>I suppose it is pretty common knowledge that the first three digits of your
>Social Security number indicate where you were born.  We also used that in
>order to verify job applications when doing a background check. 

I hope that's not common knowledge, because all those first three digits
indicate is the location of the Social Security office where you applied
for your Social Security account.  I'd hate to think that my job
application could be turned down because my Social Security Number
begins with a "0" (New England) although I was born outside New England.

					-- Matt Rosenblatt
					(matt@amsaa-seer.ARPA)


Date: Thu, 25 Feb 88 19:55:09 PST
From: judice%unxa.DEC@decwrl.dec.com

>>...I suppose it is common knowledge that the first three digits of
the ssn indicate place of birth [paraphrased]...

I was of the assumption that the middle two digits indicate YEAR of
birth - I noticed this once while looking at a list of people in my 
group and was *surprised* to see those with my birthyear always had the
same middle digits. 

Given NNN-MM-OOOO, where NNN=place of birth, MM=year of birth it leaves
only 9999 possible people to be born in NNN area in MM year??

Can anyone explain?

/ljj


Date: Wed, 6 Apr 88 23:13:18 EDT
From: simsong@westend.columbia.edu

Yes, about the Social Security Administration:

They are generally the best source of information about the use and
abuse of SSNs.  They have recommended repeatedly that the government
and private industry not use SSNs.  They will tell you that 2 million
people use duplicate SSNs.  They will tell you about the 14 pocketbook
numbers.  They will tell you about check digits, and the fact that
it's a real problem that the SSN doesn't have one.

They will also play conduit, as you said.  They will not tell you if
the person is deceased.  They will act as if the person is alive.

Part of their charter is the absolute confidentiality of their
records.  In the 1950s, a Dick Tracy comic had the famous detective
finding a suspect by a "friend at the Administration" using SSN.  The
director of the administration wrote a letter to the cartoonist saying
that such a thing could never happen.

Apparently, they forward messages to people all the time.  The main
reason they do it is to act as a national registry of people for
tracking down heirs.  They are very good at it.

................................................................simson


Date: Thu, 7 Apr 88 01:53 CST
From: Derek Andrew <ANDREW%SASK.BITNET@CORNELLC.CCS.CORNELL.EDU>

> Well, I finally had a chance to check today. The word from them is that
> the SSA will NOT give an inquirer info about a person just because that
> inquirer provides the subject's SSN.

I once had an accident and tried to trace the owner of the other vehicle
by using the license number.  The police and security services would not
help me.  They claimed they do not ever provide that kind of information
and it is impossible to find out.

We get our cable TV feed from Detroit.  The news people there did a story on
tracing people.  They first asked a person if they could trace them.  Then
they followed them to their car, wrote down their license plate number and,
through filling out of proper forms, found out who the person was, where they
lived, how much money they made, where they worked, the status of the family
and credit rating and other information --- ALL STARTING ONLY FROM THE LICENSE
PLATE !!!

The moral is that if you ask the "authority" if they will do it, they probably
won't, but fill out the right form and pay the money ($5 for a license plate)
and you may get the opposite reaction from their "official" verbal answer.

Of course it reminds me of a joke...how can you tell when the civil servant
is lying?  His/her lips are moving...

Derek Andrew, andrew@sask on the bitnet


Date: Thu, 7 Apr 88 09:27:48 EDT
From: "Robert L. Krawitz" <rlk@Think.COM>

The problem isn't necessarily the SSA giving out information, of
course.  The problem is that the SSN acts as a convenient unique
identifier (UID) for each individual US citizen.  This enables private
organizations to gather information on individuals and cross-correlate
it with other organizations.

I was recently asked for my driver's license number when buying a CD
player at a local store with cash (this was a $130 player; flames
about that to /dev/null, please).  In Massachusetts the default
driver's license number is the SSN; at the time I got my license last
fall, I wasn't aware that it could be something else.  I asked the
salesman why this was needed, since after all I was paying cash.  He
mumbled something about registering the warranty with the
manufacturer, which struck me as complete nonsense.  I told him that I
wasn't about to give out my number to the store, especially as I paid
cash for the equipment.  Finally he just entered all zeros on the
terminal (one of those data-entry jobs), which I considered
satisfactory.  Does anyone have any idea just why a store would want
my number for a cash purchase?  I have a few ideas, but I'm not
completely certain:

1)  This is the procedure followed for credit card purchases, so the
data entry form includes this anyhow.

2)  This would go into a database somewhere to form a picture of my
spending habits.

harvard >>>>>>  |		Robert Krawitz <rlk@think.com>
bloom-beacon >  |think!rlk
ihnp4 >>>>>>>>  .		rlk@a.HASA.disorg


Date: Mon, 16 May 88 14:22
From: JPETTWAY%sunrise.bitnet@aramis.rutgers.edu

If you think that someone else may have used your social security number, how
can you find out for sure. Is there anyway to get a check run on it.  I
remember there was some discussion about it earlier but I don't remember
exactly what was said.

                                                       Jenita
-----------[000021][next][prev][last][first]----------------------------------------------------
From:      Chris McDonald STEWS_SD 678_2814 <cmcdonal@wsmr10.ARPA>  27-FEB-1988 15:46
To:        security@aim.rutgers.edu
I would suggest the IEEE Tutorial "Computer and Network Security", edited by
Marshall D. Abrams and Harold J. Podell.  IEEE Computer Society order number is
756; IEEE catalog number is EH0255-0.

I am also attaching a selected list of publications which I distribute to
anyone who tells me they want to get "serious" about information security.

Chris Mcdonald
White Sands Missile Range
---------------------------------------

                            SELECTED BIBLIOGRAPHY
				      in
                    AUTOMATED INFORMATION SYSTEMS SECURITY

1.  Information Systems Security Products and Services Catalogue, October 1987,
National Security Agency.

	Catalogue contains five chapters:  Endorsed Cryptographic Products
List; NSA Endorsed Data Encryption Standard (DES) Products List; Protected
Services List; Evaluated Products List; and Preferred Products List.

2.  Evaluated Products List for Trusted Computer Systems, National Computer
Security Center.

3.  COMPUSECese Computer Security Glossary, 1 October 1985, National Computer
Security Center.

4.  Trusted Computer System Evaluation Criteria (DoD 5200.28-STD), CSC-STD-001-83, 
December 1985, National Computer Security Center

5.  Password Management Guideline, CSC-STD-002-85, 12 April 1985, National
Computer Security Center.

6.  Guidance for Applying the Department of Defense Trusted Computer System
Evaluation Criteria in Specific Environments, CSC-STD-003-85, 25 June 1985,
National Computer Security Center.

7.  Technical Rationale Behind CSC-STS-003-85:  Computer Security Requirements,
CSC-STD-004-85, 25 June 1985.

8.  Magnetic Remanence Security Guideline, CSC-STD-005-85, 15 November 1985,
National Computer Security Center.

	The guideline has a For Official Use Only exemption under Section 6,
Public Law 86-36 (50 U.S. Code 402).  Distribution authorized to U.S.
Government agencies and their contractors to protect unclassified technical,
operational, or administrative data relating to operations of the National
Security Agency.

9.  Personal Computer Security Considerations, NCSC-WA-002-85, December 1985,
National Computer Security Center.

10.  Security of Personal Computer Systems:  A Management Guide, January 1985,
National Bureau of Standards Special Publication 500-120.

11.  Security Guidelines for Microcomputers and Word Processors, March 1985,
Department of Energy.

12.  Advisory Memorandum on Office Automation Security Guideline, 16 January
1987, National Telecommunications and Information Systems Security Committee.

13.  A Guide to Understanding "Audit" in Trusted Systems, NCSC-TG-001,
28 July 1987, National Computer Security Center.

14.  Trusted Network Interpretation, NCSC-TG-005, 31 July 1987, National
Computer Security Center.

15.  Computer Security:  An Overview of National Concerns and Challenges,
Report # 83-135 SPR, Congressional Research Service.

16.  Proceedings of the IEEE Symposium on Security and Privacy, Annual,
Computer Society of the Institute of Electrical and Electronics Engineers, INC.

	IEEE Proceedings are available from the Computer Society of the IEEE,
Post Office Box 80452, Worldway Postal Center, Los Angeles, CA  90080.

17.  Federal Information Processing Standards (FIPS) #31, #39, #41, #46, #48,
#65, #73, #74, #81, #83, #102, #112.

	FIPS are available from the National Technical Information Service,
Springfield, VA  22161.

18.  Datapro Reports on Information Security, Datapro Research Corporation.

	Customer Service number for Datapro is 800-328-2776.

19.  Lobel, Jerome, Foiling the System Breakers, New York, NY, McGraw-Hill, 1986.

20.  Parker, Donn, Computer Security Management, Reston, VA, Reston Publishers,
1981.

21.  Parker, Donn, Crime by Computer, New York, NY, Scribner, 1976.

22.  Carroll, John, Computer Security, 2nd Edition, Stoneham, MA, Butterworth
Publishers, 1987.

23.  The MIS Information Security Resource Manual, 1986, MIS Training
Institute.

24.  Computer Security Buyers Guide, Computer Security Institute.

	The Computer Security Institute is a professional association for
computer security specialists.  The Institute's telephone number and mailing
address are:  617-393-2600/Computer Security Institute, 360 Church Street,
Northborough, MA  01532.  

25.  Kochan, Stephen G. and Wood, Patrick H., UNIX System Security,
Indianapolis, Indiana, Hayden Books, 1985.
-----------[000022][next][prev][last][first]----------------------------------------------------
From:      gnu@hoptoad.uucp (John Gilmore)  28-FEB-1988 06:11
To:        hobbit@aim.rutgers.edu
[Moderator note: I pulled this off sci.crypt; some of you may not
have seen it yet.   _H*]

I'm glad to see that a lawyer has finally looked over the analysis of
PD cryptographic software export controls that I did a while ago.  I
still think we have a free country but will go look up the regulations
they quote, to make sure.  It may be that before we post something, we
have to put it in a magazine or newsletter, or offer it on floppies to
anyone who sends in $5 -- no big deal.  I would prefer to have a court
rule that posting something to 8000 machines, many of which are
public-access, and including it in a software library accessible to
anyone, is making it "freely available to the public".  But for that to
happen, somebody will have to take somebody to court, and so far there
are no volunteers.

The point is that information which is freely available to anyone in
the US can be exported.  If any Tom, Dick, or Harry in the states can
get it, there should be no grounds to hassle somebody over exporting it.

Realize that the lawyer who came up with this opinion is paid by DEC to
keep DEC out of trouble.  The safest thing to do, in the short term,
is to turn and run from any kind of trouble.  I just think that the long
term trouble caused by only the government having privacy is worth
facing the short term trouble.

I'll have more to say later.
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
		"Watch me change my world..." -- Liquid Theatre
-----------[000023][next][prev][last][first]----------------------------------------------------
From:      gwyn@brl_smoke.arpa  28-FEB-1988 10:10
To:        misc-security@uunet.uu.net
I think Belsaw's course would fit your needs fairly well.  I took
this course in my spare time many years ago; it covered the basics
adequately, and you would mail in the results of exercises (such
as a key you had made by the impression method) for evaluation by
an instructor.  Belsaw offered their own line of supplies (a key
machine came as part of the course), and it shouldn't be too hard
to establish your bona fides with locksmith supply distributors.
Belsaw advertises in magazines like Popular Science.
-----------[000024][next][prev][last][first]----------------------------------------------------
From:      new@udel.edu  28-FEB-1988 12:26
To:        sri-spam!csib!lgold@rutgers.edu
Marauder (sp?) for the Amiga also uses the copy-protection scheme that
asks for certain words from the manual. Sinc the program is designed to
copy copy-protected disks, the normal mechanisms would not protect it.
In addition, the manual is printed in light blue, I assume non-repro blue.
Shortly after the program came out, a program named "find" came out that you
start before you run Marauder. When Marauder asks for word 6 on page 3, 
simply type "find 6 3" and find will tell you the word. Find does not
violate the copyright on the manual because it looks into Marauder's 
addres space to get the word; I know because there is at least one
word that Marauder "knows" incorrectly, but find will find tell you
what the program expects.
                                          - Darren
-----------[000025][next][prev][last][first]----------------------------------------------------
From:      "Marshall D. Abrams" <abrams@mitre.arpa>  1-MAR-1988 11:05
To:        security@aim.rutgers.edu
		Call for Papers
Fourth Aerospace Computer Security Applications Conference
December 12-16, 1988, Sheraton World Hotel, Orlando, Florida

		The Conference

Operational requirements for civil and military 
systems under development increasingly stress  the necessity for information 
to be readily accessible to users and operators.  This produces an 
apparent conflict with policies and directives which require total 
protection of system data from compromises of privacy, confidentiality, 
and integrity.  Accomplishing both of these sets of requirements requires 
the application of the maturing technology of computer security to 
new systems throughout their development cycle.  In addition, operational 
approaches to satisfy system requirements and accommodate the implementation 
of engineering technology require intensified research and development.

This conference will explore technology applications
in two complementary aspects:  first, the policy issues and 
operational requirements for both civil and military systems; and 
second, the hardware and software tools and techniques being developed 
to satisfy system requirements.  Special emphasis will be placed on 
specific examples of systems applications.

A three-day technical conference exploring the  
application of computer security technology will be preceded by two 
days of tutorials dealing with policy matters, technology applications, 
and  other areas.  Introductory and advanced surveys will be offered 
as well as advanced courses exploring specialized technological areas.

		Areas of Interest Include:
 
	* Trusted DBMSs and Operating Systems
	* Network Security
	* Current and Future Trusted System 
	* Technology
	* Space Station Requirements
	* Certification, Evaluation and 
	* Accredition
	* Policy and Management Issues
	* Advanced Architectures
	* C3I Systems
	* Risk/Threat Assessments
	 
		Papers and Tutorials

Technical papers and tutorials which address  
the application of computer security technologies in the aerospace 
environment are solicited.  Original research, analyses and approaches 
for defining the computer security issues and problems identified 
in the Conference's interest areas; methodological approaches for 
analyzing the scope and nature of computer security issues; and, potential 
solutions are of particular interest.  Full unclassified papers or 
unclassified abstracts of classified papers, must be mailed before 
20 May, 1988.  Material should be sent to:

	Dr. William T. Bisignani                
	Technical Program Chairman  
	Booz-Allen & Hamilton Inc.
	4330 East-West Highway
	Bethesda, MD  20814

Tutorial Proposals including a detailed outline 
and a resume of presentor(s) must be mailed before 20 May, 1988 to:

	Dr. Dixie B. Baker                      
	Tutorial Program Chairwoman
	The Aerospace Corporation
	P.O. Box 92957
	2350 East El Segundo Blvd.
	El Segundo, CA 90245-4691

Classified Sessions: Classified sessions at the SECRET level are planned.

		Vendor Exhibit

A technical exhibit program is planned 
for interested vendors displaying computer and physical security products.  
Inquiries should be sent to 

	Mr. Robert D. Kovach 
	Aerospace Computer Security Associates
	c/o ORI, Inc.
	1375 Piccard Drive
	Rockville, MD  20850

	Additional Information

For more information or to receive future mailings,
please contact the conference chairman:

   Dr. Marshall D. Abrams, phone: (703) 883-6938
   The MITRE Corporation, 7525 Colshire Drive
   Mail Stop Z670, Mc Lean, VA   22102
   E-mail address: abrams@mitre.arpa
-----------[000026][next][prev][last][first]----------------------------------------------------
From:      NET%"iconsys!bryan@uunet.uu.net"  1-MAR-1988 23:42
To:        misc-security@uunet.uu.net
What exactly is the policy regarding exportation of software object
code implementing (in one form or another) the National Bureau of
Standards Federal Information Processing Data Encryption Standard
(DES) algorithm?

The AT&T UNIX Operating System Release 2.2 and Release 3 license
agreements state that the "crypt" program, library, and associated
documentation are not to be distributed with international versions of
the operating system.  Careful examination of the source code,
however, reveals the following:

1)   The "crypt" library is not the sole source for the crypt(3)
     routine.  The generic C library includes the same crypt routine
     as contained in the "crypt" library.  The difference is that in
     the "crypt" library, there are additional decryption routines.

2)   There appears to be nothing special about the "crypt" program.
     It does not differ in its use of the DES algorithm from "login".

My question is: exactly what may not be exported (by law, not
tradition), and why is exportation proscribed?

Please respond via E-Mail.  Thank you for your help.

-- 
Bryan J. Cardoza
Quality Assurance Manager
Icon International, Inc.
{ihnp4,uunet}!iconsys!bryan

END OF DOCUMENT