----MESSAGE-BEGIN---- <1988020213590000> From: _*Hobbit* 3-FEB-1988 21:39 To: HOBBIT@aim.rutgers.edu Subj: superuser abuse 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* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020404540000> From: DORFMAN@ECLA.USC.EDU 5-FEB-1988 12:34 To: security@aim.rutgers.edu Subj: [606] Computer Security Introductory Text 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020705230000> From: Nick Papadakis 8-FEB-1988 13:03 To: ROMKEY@XX.LCS.MIT.EDU Subj: [619] immunological/antibody program From: Philip A. Earnhardt 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020811370000> From: decvax!decwrl!sun!seismo!esosun!dcdwest!sarge@ucbvax.Berkeley.EDU 9-FEB-1988 19:17 To: AIM.RUTGERS.EDU!HOBBIT@sundc Subj: [520] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020902110000> From: andrew@frip.gwd.tek.com (Andrew Klossner) 10-FEB-1988 09:51 To: misc-security@tektronix.tek.com Subj: [1064] Submission for misc-security "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] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020902110001> From: 10-FEB-1988 09:51 To: Subj: [121] Info re disaster planning I am looking for information on disaster planning for University computer Centers. I will appreciate any help. Thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020902110002> From: David S. Hayes 10-FEB-1988 09:51 To: uunet!misc-security@uunet.uu.net Subj: [764] locksmithing courses 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020902110003> From: dnelson@ddsw1.UUCP (Douglas Nelson) 10-FEB-1988 09:51 To: codas!misc-security@rutgers.edu Subj: [1836] 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 ------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020902110004> From: mcvax!ethz!prl@uunet.uu.net (Peter Lamb) 10-FEB-1988 09:51 To: cernvax!misc-security@uunet.uu.net Subj: [779] Re: distribution of sensitive software like DES 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020907010000> From: Daniel Keizer 10-FEB-1988 14:41 To: security@aim.rutgers.edu Subj: [1999] RE: Secure labs with PC-LOCK 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988020918300000> From: simsong@amsterdam.columbia.edu 11-FEB-1988 02:10 To: MSRS002%ECNCDC.BITNET@cunyvm.cuny.edu Subj: [673] Security in PC labs. 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988021010280000> From: sri_spam!csib!lgold@rutgers.edu 11-FEB-1988 18:08 To: security@rutgers.edu Subj: [984] Re: copy protection for micro software 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988021208120000> From: Bill Sommerfeld 13-FEB-1988 15:52 To: "THE DOCTOR." Subj: [1410] Re: Security in PC labs. ... 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988021510280000> From: hp_sdd!dag@hp_lsd.hp.com 16-FEB-1988 18:08 To: sdcsvax!misc-security@rutgers.edu Subj: [361] Re: re: copy protection for micro software 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988021701060000> From: "John O. Rutemiller" 18-FEB-1988 08:46 To: security@aim.rutgers.edu Subj: [155] re: Driveway Metal Detectors 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988021718580000> From: "Robert W. Baldwin" 19-FEB-1988 02:38 To: security@rutgers.edu Subj: [897] police radar 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022104560000> From: Clement Taylor 22-FEB-1988 12:36 To: Security Conference Subj: [665] BITNET Security 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*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022409270000> From: Wm Brown III 25-FEB-1988 17:07 To: "David S. Hayes" Subj: [2498] locksmithing courses 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022501140000> From: GOLD::HOBBIT 26-FEB-1988 08:54 To: NET%"security-list",HOBBIT Subj: [1298] Summary of msgs re: Intro to Computer Security [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" 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 -*-*-*-*-*-*-*-*-*-*-*-*-*-*- 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022503340000> From: goldstein%star.DEC@src.dec.com 26-FEB-1988 11:14 To: SECURITY@aim.rutgers.edu Subj: [14996] Export of "public domain" crypto software [Moderator note: Thanx also to Chris Kent 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022504345100> Date: Thu, 25 Feb 88 10:34:51 CST From: Will Martin -- AMXAL-RI 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 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 > 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" 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 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022608060000> From: Chris McDonald STEWS_SD 678_2814 27-FEB-1988 15:46 To: security@aim.rutgers.edu Subj: [4363] For dorfman@elca.usc.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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022622310000> From: gnu@hoptoad.uucp (John Gilmore) 28-FEB-1988 06:11 To: hobbit@aim.rutgers.edu Subj: [4646] [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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022702300000> From: gwyn@brl_smoke.arpa 28-FEB-1988 10:10 To: misc-security@uunet.uu.net Subj: [1043] Re: locksmithing courses 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022704460000> From: new@udel.edu 28-FEB-1988 12:26 To: sri-spam!csib!lgold@rutgers.edu Subj: [791] Re: copy protection for micro software 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022903250000> From: "Marshall D. Abrams" 1-MAR-1988 11:05 To: security@aim.rutgers.edu Subj: [3572] Aerospace Computer Security Applications Conf. - Call for Papers 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988022916020000> From: NET%"iconsys!bryan@uunet.uu.net" 1-MAR-1988 23:42 To: misc-security@uunet.uu.net Subj: [1193] Question--Exporting the DES Algorithm 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 ----MESSAGE-END----