Volume 5, Number 26 27 June 1988 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief Dale Lovell Editor Emeritus: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Al Arango FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. Copyright 1988 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and are used with permission. The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. We publish EVERYTHING received. Table of Contents 1. ARTICLES ................................................. 1 A By Law proposal ........................................ 1 EchoMail, Blessing or Bane? .............................. 7 Killing Viruses .......................................... 9 2. NOTICES .................................................. 23 The Interrupt Stack ...................................... 23 Latest Software Versions ................................. 23 FidoCon '88 Registration Form ............................ 25 FidoNews 5-26 Page 1 27 Jun 1988 ================================================================= ARTICLES ================================================================= Neal Curtin 1:343/1 Change to the By Laws The following is submitted as a set of proposed amendments to the BY-LAWS of the International FidoNet Association. They are proposed to the Chairman of the Bylaws Committee, and to the Board of Directors of the said International FidoNet Association. Proposal 1. Current Wording. Preamble: IFNA NODELIST: The list, prepared by the IFNA Vice President - Technical Coordinator, of active nodes in the IFNA NETWORK. IFNA NETWORK: The current set of systems which have been certified as FidoNet compatible and conform to policies established by the Board of Directors. PUBLIC ACCESS: A system that has a telephone number published in the IFNA Nodelist, and in addition provides services to the public. Suggested Wording: Nodelist: The list, prepared by the various Zone Coordinators, of active nodes within their zone, and on file with the International Coordinator. Network: The current set of systems which have been certified as Fidonet compatible, and conform to the policies established by their respective net, region, and zone. PUBLIC ACCESS: A system that has a telephone number published in the Nodelist, and in addition provides services to the public. Added wording: International Coordinator: The individual elected by the various zones and regional coordinators to arbitrate and rule on inter-zonal disputes. In addition, the International Coordinator is the person responsible for coordination FidoNews 5-26 Page 2 27 Jun 1988 between the zones and is responsible for establishing new zones as the case may arise. Rationale: These changes are proposed to eliminate the implication, real or perceived, that the association owns, controls, or manipulates the FidoNet network. Proposal #2 Proposed changes to section 1 Current wording: 1(a) Regular Member. To be eligible, an applicant: must be the system operator in good standing of a PUBLIC ACCESS node; must have paid any dues required; is entitled to one vote. 1(b) Associate Member. Any person who is not eligible to be a Regular Member, but who is interested in electronic communications, is eligible to be an Associate Member by paying required dues. Associate Members have all of the rights of a Regular Member except the right to vote. 1(c) Commercial Member. Any entity using the IFNA NETWORK for the conduct of any business is eligible to be a Commercial Member by paying required dues. Any Commercial Member also satisfying the requirements to be a Regular Member shall be entitled to vote. Proposed wording: 1(a) Regular Member. To be eligible, an applicant: must be the system operator in good standing of a PUBLIC ACCESS node; must be listed in a nodelist; must have paid any dues required; is entitled to one vote. 1(b) Associate Member. Any person who is listed in a nodelist. or who is interested in electronic communications, is eligible to be an Associate Member by making application for membership. Associate Members have all of the rights of a Regular Member except the right to vote. 1(c) Commercial Member. Any entity using the IFNA NETWORK for the conduct of any business is eligible to be a Commercial Member by paying required dues. Any Commercial Member also satisfying the requirements to be a Regular Member shall be entitled to vote. Rational: These changes are designed to broaden the scope of eligibility, and include all sysops who are listed in a FidoNet Compatible nodelist. FidoNews 5-26 Page 3 27 Jun 1988 Proposal 3. Proposed changes to Section 2 and 3. Current wording 2. Applications for membership shall be submitted to the Secretary. In the case of any applicant whose character, reputation or conduct might make him an undesirable member, the Secretary shall refer the application to the Executive Committee for review; in all other cases, the Secretary shall have the authority to grant membership. 3. The Secretary shall notify members of the expiration of their membership not less than thirty days prior to expiration. In determining membership status, memberships renewed within thirty days of expiration shall be regarded as continuous. Proposed changes 2. Applications for membership shall be submitted to the Membership Committee. In the case of any applicant whose character, reputation or conduct might make him an undesirable member, the membership Committee shall refer the application to the Executive Committee for review; in all other cases, the Membership Committee shall have the authority to grant membership. 3. The Membership Committee shall notify members of the expiration of their membership not less than thirty days prior to expiration. In determining membership status, memberships renewed within thirty days of expiration shall be regarded as continuous. Rational: The secretary does not now, nor has he ever been, involved in membership. The application goes to the Treasurer, who notifies the Membership Services Committee, who sends out the membership card. Proposal #4 Proposed changes to section 25 Current wording: 25. The following voting divisions are established: Division 2 Europe, Africa Division 10 CA NV Division 11 IL IN KY MI OH WI - USA and ON PQ PEI NS NB NF -Canada Division 12 HI Asia, Australia, Antarctica Division 13 DE DC MD NJ NY PA VA Division 14 IA KS MN MO NB ND SD Division 15 AZ CO NM UT WY FidoNews 5-26 Page 4 27 Jun 1988 Division 16 CT ME MA NH RI VT Division 17 AK ID MT OR WA - USA and BC ALB SSK -Canada Division 18 AL FL GA MS NC SC TN Division 19 AR LA OK TX, South America, Mexico, Central America Proposed change: 25. The following voting divisions are established: Division 2 Europe, Africa Division 3 Australia, Southern Pacific Division 4 AlterNet Division 5 GoodEggNet Division 6 Canada Division 7 Central and South America Division 8 IL IN KY MI OH WI Division 9 DE DC MD NJ NY PA VA Division 10 IA KS MN MO NB ND SD Division 11 AZ CO NM UT WY Division 12 CT ME MA NH RI VT Division 13 AK HI ID MT OR WA Division 14 AL FL GA MS NC SC TN Division 15 AR LA OK TX These divisions may be changed by a two thirds vote of the Board of Directors, and should include new zones and new Nodelists of over 100 systems. Rational: The current system does not give enough representation on the board to overseas areas and tends to be inflexible. Proposal #5 Proposed changes to section 28 Current Wording: 28. The Secretary shall: record the proceedings of all meetings of the Board and of the Executive Committee; promptly furnish copies of the minutes of these meetings to all officers and members of the Board;publish such minutes in FidoNews; be responsible for the maintenance of the corporate status of IFNA and the filing of all reports and certificates which may be required of IFNA under the corporation laws of the State of Missouri; be the archivist of IFNA; maintain the corporate membership and voting records of IFNA; performs other duties as described in applicable Bylaws. To the extent that may from time to time be required by law, he shall act as agent for the service of process but only while present in the State of Missouri and he is not authorized to accept service of process elsewhere. Proposed Change: 28. The Secretary shall: record the proceedings of all FidoNews 5-26 Page 5 27 Jun 1988 meetings of the Board and of the Executive Committee; promptly furnish copies of the minutes of these meetings to all officers and members of the Board; publish such minutes in FidoNews; be responsible for the maintenance of the corporate status of IFNA and the filing of all reports and certificates which may be required of IFNA under the corporation laws of the State of Missouri; be the archivist of IFNA; maintain voting records of IFNA; performs other duties as described in applicable Bylaws. To the extent that may from time to time be required by law, he shall act as agent for the service of process but only while present in the State of Missouri and he is not authorized to accept service of process elsewhere. Rational: Eliminates the requirement that the secretary maintain the membership roster. Proposal #6 Proposed changes to section 30 Current wording: 30. The Vice President - Technical Coordinator shall: be responsible for maintenance and distribution of the master NODELIST; creation and distribution of the weekly update file for the master NODELIST; ensuring the smooth operation of the IFNA NETWORK as prescribed by the Board of Directors; serve as a member of the Technical Standards Committee. Proposed change: 30. The Vice President - Technical Coordinator shall: serve as a member of the Technical Standards Committee, and be responsible for the development and publication of standards for system software so as to ensure compatibility between the various nodes. The VP-TC will assist the various Coordinators in technical matters. Rational: This change to eliminate the implied or perceived implication of that IFNA desires or wants to control the nodelist. The reference to the IC is dropped and would no longer be a IFNA position. Proposal #7 Proposed changes to section 40 Current wording: 40. There shall be an official publication maintained by IFNA, in the form of a weekly journal, the name of which shall be FidoNews. A copy of this journal shall be available each week to every member of IFNA in good standing. The General management of this journal shall be in the hands of the President. The policy of the journal shall be FidoNews 5-26 Page 6 27 Jun 1988 determined by the Board of Directors. Proposed change: 40. There shall be an official publication maintained by IFNA, in the form of a weekly journal, the name of which shall be FidoNews. A copy of this journal shall be available each week to all listed nodes. The general management of this journal shall be in the hands of the President. The policy of the journal shall be to publish all submitted articles of interest to the FidoNet community, within the bounds of legality and good taste. Rational: This change is to eliminate the reference that the journal is only for IFNA members, and to give some firm direction to the editorial staff. Respectively submitted by Neal Curtin, Network Coordinator, Net 1:343. ----------------------------------------------------------------- FidoNews 5-26 Page 7 27 Jun 1988 Bob Morris FN 1:141/333, 1:141/386 AN 7/1, 7/13, 7:46/1, 7:46/2 and 7:46/3 Echomail, the thing which allows our users (you remember them) to communicate with the rest of the world on things that are bothering them, technical issues, as well as speciality areas. EchoMail has become something of a monster, what we all use to help support and have become "HOOKED" on is now being used as the carrot which the EchoMail Backbone, REC's, NEC's and what ever use to limit our links to other systems across the world. EchoMail was designed by Jeff Rush and it was a GREAT idea of getting the same message out to a lot of people at the same time. But in today's environment, EchoMail has established a new power point to control what we all do for our users, including what type modems are utilized, the hours that echomail can be picked up, the systems which can called to pick up these areas and last, but not least, who we can align ourselves with when it comes time to use software to process this whole mess. In this Sysop's mind, it has become a monster which in the last 20 months has accomplished the following items without the least amount of trouble. 1. The splitting of the Network (FidoNet as we knew it in January of 1987) into different Networks. 2. The demise of good working relationships. 3. The phrase "FLAME ON". 4. The inability of people to "read" humor or anything else within the written word. This has lead to many people not being able to understand the context of many of the messages that we all read on a daily basis. 5. The demise of IFNA as well as causing it to become unable to accomplish anything based upon the problems associated with Electronic Mail especially that of Echo- Mail. 6. The establishment of the *EC positions, which when they started, were needed, but now they duplicate the *C positions and are now wielding more power and control than their contemporaries within the FidoNet Administrator Positions. 7. The disenchantment of Sysops as a whole about the world of BBSing, causing them to DROP OUT entirely, or at the least the seeking of Alternatives to the HATEMail which now proliferates the AREAS.BBS today. FidoNews 5-26 Page 8 27 Jun 1988 8. The establishment of EchoMail areas which do nothing but allow people who moderate EchoMail areas a place to discuss what is happening within the world of echomail and to discuss how to furthur control who can get direct access to an EchoMail area. If you read this article as "Sour Grapes" (one less than a FLAME) then that is what I intended it to do. If you read it as an indictment of the EchoMail process as it exists today, then, again, it is something that I intended to do. If you read this article and feel as though I am saying that the need for an enforcement procedure is bad, then I have again accomplished what I set out to do. If you read this and find that someone is imposing a set of rules upon the manner in which you and your USER must share ideas, thoughts and other information which is posted in the EchoMail Areas, then again, I have accomplished what I set out to do. I am NOT saying that EchoMail Coordination is bad, I am saying that the people who Coordinate the running of the EchoMail distribution are imposing a set of rules and regulations which have not been accepted by the Sysop Community as a whole. I am also stating that pickups outside of a region, as long as they are closed loops, stand little if any chance of generating duplicates within any given region. Links outside of a given Region provide for a backup link in case of disaster or full disk drives. Within AlterNet, there is a stated Policy concerning EchoMail, that Policy is to "Be Polite, and if you cannot add anything to a conference which is Positive, then do not use the conference" this Policy is followed by the vast majority of the AlterNet Community, unfortunately, it does not have to apply to the FidoNet Community. EchoMail, from my view point, has broadened my scope as far as what is happening within the Networks, but it has soured me as far as my view point of other Sysops and also the way that they look at me. It is a two way street, no one wins, and only AT&T, SPRINT, MCI, GTE and PCP have won as they get all the neat profits from our expenses. A few last points, do we really need all 225 conferences? Do we really need all of this to make sure that our users get a couple of EchoMail areas? Or are we doing this just so that our Blood Pressure gets up at least once a day? Bob Morris FN 141/333, 141/386 AN 7/1, 7/13, 46/1, 46/2, 46/3 ----------------------------------------------------------------- FidoNews 5-26 Page 9 27 Jun 1988 Lee Kemp, Communet 1:221/162.14 7 June 1988 K I L L I N G V I R U S E S 1. INTRODUCTION Numerous utilities have been released for detecting "virus" programs before they damage hard disks or get passed on. Unfortunately this won't work. Existing viruses will continue to spread from diskettes already infected, and will re-infect computers that have been through it before. New more virulent strains will be developed to overcome each new detection utility released (perhaps by infecting the utilities themselves!) I believe I've figured out a method that WILL work. The World Health Organization managed to stamp out smallpox through a coordinated international campaign and I believe we can do the same for ALL computer viruses - but it will require a coordinated campaign. This article lays out the basic idea and asks for help. Help through any constructive criticisms or alternative proposals, help through negative, destructive "flames" if the idea is all wrong, so I'll stop wasting time on it, and help from any software developers willing to "send code". However I am not interested in corresponding about whether destructive Trojan viruses actually exist and whether they will become a serious problem. Its far too late to be discussing THAT. First, some reasons why its worth working on the solution I propose. 1.1 There is NO way to detect viruses None of the methods currently used have the SLIGHTEST chance of detecting a reasonably well designed Trojan, let alone a genuine virus. Tests that are just done when software is first received, and just consist of running a utility over it once, or installing a TSR monitor, are ALREADY completely useless. Any jerk can write a Trojan that won't do anything suspicious while it's being tested, and the test utilities themselves are likely to be a target for more sophisticated viruses. Ideas like continually monitoring disk writes are ok for the first generation of Trojans but simply won't work with the next generation. Actually they will become positively dangerous. A virus could simply recognize the particular TSR that's monitoring it, grab the interrupts back, and send reassuring messages to the SysOp, while it doesn't even bother to WAIT before starting to infect other software! A false sense of security is MUCH worse than the knowledge that anything you make available for download FidoNews 5-26 Page 10 27 Jun 1988 COULD be a virus. Source code for IBM ROM BIOS is available in the Technical Reference manuals for anyone who wants to write Trojans that access disk controllers directly. Also there are ways to do apparently "legitimate" disk writes that do no immediate damage but can trigger an infection later. Much more sophisticated approaches to delayed action are available than using the DOS date function. Checksums of operating system files and their dates and times are easily bypassed. Proper testing requires at least the sort of insulation from the hardware and operating system that is provided by a 386 running in virtual 8086 mode. Worse, there are even ways around THAT, which I won't go into here. Anyone familiar with the secure design of operating systems understands that there is NO way an application program can be prevented from doing whatever it damn well pleases when the underlying CPU hardware doesn't run in a protected mode. OS/2 and Unix run in a protected mode but MSDOS normally doesn't, and CAN'T on XTs and ATs. Even protected mode isn't enough, given the practical realities of normal security precautions. Controlled experiments with Unix viruses have achieved root privileges in less than an hour, with an average of 30 minutes. (F. Cohen, "Computer Viruses: Theory and Experiments", University of Southern California, August 1984, cited in Wood and Kochan, "Unix System Security", Hayden Book Company, 1985) The SERIOUS work in computer security is being done on how to protect a system when you have complete source code for everything run on it - and THAT is damn difficult. ADA and Pascal are languages intended to allow you to figure out what the source code actually does, but C is the language of micro applications and its designed for efficiency, not correctness proofs. Take a look at the fast table driven CRC routines used in most FidoNet mailers these days. How many C programmers have the faintest idea what they ACTUALLY do? Serious computer security work also deals with problems like "compiler viruses", that install themselves in any software compiled, including new versions of the compiler. Who REALLY knows what's in most microcomputer object code - not even the authors! There is NO serious work being done on protection from real mode applications running on 80x86 machines. Because it SIMPLY CAN'T BE DONE. Now sit back and think about the implications of that for 3000 FidoNet nodes around the world continually exchanging software FidoNews 5-26 Page 11 27 Jun 1988 with each other and their users! This network can spread a deadly virus around the world within DAYS (if not hours). 1.2 We don't have time for testing ANY partially useful testing system for the next generation of viruses would require tests EVERY time a copy of ANY software is made available for distribution, and fairly elaborate procedures to ensure the testing is done on an uninfected machine with uninfected test utilities. Even factory fresh diskettes from major software houses have ALREADY been infected, so what's to stop the latest upgrade of some commercial package infecting a machine that's been carefully kept "clean"? Even Harvard couldn't persuade Lotus to let them retain their policy of ONLY running software for which they had compiled the source code themselves. BBS SysOps just don't have the time to properly test files they make available for download, even to detect fairly crude Trojans. Neither do end users. Even PARTIALLY useful serious tests simply won't be widely used until AFTER there has been some MAJOR damage done. The time wasted on serious testing will then be almost as damaging as actual loss of data. 1.3 We can't afford to just keep quiet and hope The first generation of diskette based viruses has now become of sufficient public interest for full page articles in daily newspapers as well as computer magazines. It is therefore CERTAIN that some warped people will take up the challenge to design the next generation. It is also very likely to happen SOON. In case anybody thinks that mentioning all this could give people ideas, I should point out that the technical points made above will be obvious to anybody TRYING to figure out how to get past present detection utilities. People who have ALREADY shown much more sophistication with Unix viruses will now be focussing their attention on personal computer diskette based viruses as a result of the newspaper publicity if nothing else. I am deliberately refraining from mentioning some approaches that are obvious to me, but that may not be thought of immediately by just ANYBODY contemplating a virus program, in case that can give an extra breathing space. But I KNOW that there ARE ways to unleash delayed action virus programs that CANNOT be detected by ANY feasible method. I don't think it will be long before these more sophisticated approaches become general public knowledge too. A basic issue is that viruses involve quite different problems from simple Trojans. They can spread WITHOUT doing overt damage. I am writing a separate technical paper on all this, which shows FidoNews 5-26 Page 12 27 Jun 1988 that FidoNet itself is in special "clear and present danger" with more than the usual problems faced by all BBSes. Anyone wanting a copy should NetMail me direct, explaining why they have a legitimate "need to know" and with an undertaking not to pass on the information. This paper is not available for file request but will be crashed direct to responsible software developers interested in working on solutions. I sent a message about these problems to the International Coordinator of FidoNet nearly three months ago. He replied to other matters in the same message in a manner indicating that he had not understand anything I said to him, and he did not reply at all on this issue. Judging from that and other indications, I do not believe that the authorities within FidoNet who ought to take the initiative to do something about this situation are likely to do so. (For that matter my experience with the IC is that he also thinks he can avoid other serious problems by sticking his head in the sand). I see no choice but to now pass on the information direct to interested and responsible software developers. There's no point refraining from public discussion, when full page articles about computer viruses are appearing in daily newspapers, and when people responsible for administration of FidoNet won't listen AT ALL. Ok, now as well as being necessary to look at new solutions, it's also URGENT to do so. 2. WHY ITS URGENT "Computer AIDS" is likely to have as devastating an effect on BBSes and FidoNet as the original AIDS has already had on gays, and is now having on the wider community. Unless something is done NOW, we are CERTAIN to eventually be hit by some really deadly virus that has been spread to literally thousands of public access BBS systems through FidoNet and will then, months later, cause literally millions of dollars worth of damage to data on literally tens of thousands of users hard disks. The problem is THAT serious. Apart from jerks, there are economic interests that actually stand to GAIN from destructive viruses, because public domain software, and the "sharing" of other software that often occurs among people who use public domain software, directly competes with their own commercial interests. As Nicholas Rothwell points out in his article on "Computer AIDS": But what if one does not want to create trouble, but rather to destroy trust? For that is what is at stake. Without open communication, without "public domain" software, without free exchange of academic and technical software, the personal computer revolution is FidoNews 5-26 Page 13 27 Jun 1988 hamstrung. There are plenty of technically competent people in FidoNet who are out to destroy trust and are opposed to open communication. I'll be going into that in a later article. Last month a report for the European Commission issued a formal blunt warning that computer networks across the member nations of the European Community were not safe: Unless action is taken to improve levels of computer and network security, the consequences for individual enterprises could be severe, even catastrophic. For FidoNet the consequences would be catastrophic, not just "severe". It is one of the world's largest computer networks, but with virtually NO security and LOTS of jerks. We are supposed to be a network dedicated to the free exchange of information. If instead we become known as a network that has done millions of dollars worth of PREDICTABLE damage that COULD have been avoided by SIMPLE countermeasures, then both individual SysOps and IFNA could be held legally responsible for the damage resulting from negligently failing to take those countermeasures. Quite apart from the legal consequences, a really devastating virus attack would give the words "BBS" and "FidoNet" a brand recognition somewhere between Tylenol and anal sex. If the countermeasures aren't in place BEFORE major damage is done, there will be an atmosphere of incredible paranoia about using ANY software from BBSes and user groups. It could even be quite difficult working on solutions in that atmosphere. Also interests opposed to public domain software and the free exchange of information could take the opportunity to impose regulation and controls on a VERY unpopular minority. 3. WHAT IS TO BE DONE? Fortunately there IS an approach that CAN stop viruses, and COULD be widely used as soon as its available. I hope I've given enough reasons for people to take a serious interest in my proposals despite their unfamiliarity. Here goes. The way biological immune systems develop antibodies to attack foreign bodies is to first identify what SHOULD be present and then deduce what should not. We can do that using "digital signatures" just as the immune system recognizes molecular signatures. Since there is NO practical way to determine whether unknown software is a virus or not, the ONLY feasible approach to "safe software" is to identify KNOWN software and use nothing else. The logic of that is both compelling and frightening. It has FidoNews 5-26 Page 14 27 Jun 1988 already led to quite serious restrictions on the "promiscuous" way that people exchange software. If the current trend continues, open BBSes will become less and less viable and the "free exchange of information" will be replaced by tightly controlled distribution channels. AT PRESENT the only way to identify "known" software, is through writing and compiling it yourself, or buying it from a commercial distributor in a shrink wrapped package. Even these precautions aren't worth much against compiler viruses and given the level of security at most software publishers. Turned around, the same logic suggests we need to find another way to identify "known" software. Fortunately there IS another way, suitable for BBS public domain and shareware software. 3.1 Authentication by digital signature Software authors and publishers can use public key encryption or other digital signature techniques to authenticate their software releases with their personal "signature". This merely requires that they run a standard encryption utility on each package before distribution. An explanation of how public key encryption works is in FidoNews 428. Authentication is the key to killing viruses while preserving the free exchange of information. It doesn't actually kill them, but it provides a way we can only use "known" software WITHOUT tightly controlled distribution channels. Essentially the use of public key digital signatures just establishes that any two items that can be decrypted with the same "public key" signature MUST have both come from the same person. It's that person's personal signature and there is no way that anybody else could "forge" it. Because an item can be decrypted with a particular public key, it must have been encrypted using the corresponding "secret key" that was generated simultaneously with the public key by the person who published that public key. Since this "secret key" cannot be deduced from knowledge of the public key, the person who encrypted using it must therefore be the person who published the original public key (unless they let somebody else get hold of a copy!) A digital signature doesn't prove who the person that uses it really is, or how trustworthy they are, or whether they originally wrote the document they are signing. But it DOES allow each software author (or other distributor) to establish their own "reputation". In practice most users won't want to keep the public keys of large numbers of software authors and publishers, and new authors and publishers need a way to get their software accepted. FidoNews 5-26 Page 15 27 Jun 1988 This requires intermediary "recommenders" and "software certifiers" who publish "signed" lists of signatures which they recommend as trustworthy, or reissue software they trust under their own "signatures". They may also issue signed "warnings" about infected software they have come across, and who signed it. Some SysOps and user groups may want to advise their users which signatures they personally recommend as trustworthy. That's up to them and it's up to their users what notice to take of their advice. Some software collectors may want to keep close tabs on who releases what, and reissue copies under their own signature as evidence that they consider an item to be uninfected. That's equivalent to the responsibility that anyone takes now, when they pass on a copy of ANYTHING to anybody else. A valuable service can be performed by such "software certifiers". When things settle down, end users should be able to rely on relatively few signatures, and with the side benefit of automatically produced catalogs of software available. It's very important that there be convenient ways for recommendations and warnings to be passed on and accepted or rejected automatically according to users preferences as to which advice they consider trustworthy. It's equally important that there be no central authority who is the sole source of such advice. It IS possible for such "advice" to be processed automatically, by users, with no hassles, despite coming from a multitude of sources. I'll explain that later. The essential point is that we ALL rely on such advice and recommendations now, including published lists of Trojans. The difference with my proposal is that we can automate it and know where it's really coming from. More important, we can know which software EXACTLY is being recommended or warned against. Instead of lists warning about certain utility names and version numbers, we will see (automatically processed) lists warning about signatures. Although anybody can just adopt another signature, getting other people to accept it will be a lot harder than just using the RENAME command on a Trojan! Life will actually be EASIER for SysOps as a result. 3.2 Establishing Reputations For their recommendations and warnings to be accepted, a SysOp or other software certifier needs a reputation for giving good advice. For their signatures to be recommended, or for their software to be reissued under other people's signatures, a software author or distributor needs a reputation for taking adequate precautions to FidoNews 5-26 Page 16 27 Jun 1988 not release infected software. (For reissue most people would want to read and recompile the source code themselves before staking their own reputations on it.) In both cases anybody can start again under another signature, but the signatures that users will accept will be the ones that have established a reputation over a period. 3.2.1 "I've never released infected software" If an infected program is released under a particular signature, anybody can PROVE that signature should not be trusted again. (Although nobody can prove whether a virus was released deliberately, accidentally, or as a result of allowing a secret key to become known to somebody else, the effects are the same and the consequences should be the same - don't trust the signature of anybody who signed that software. They should never have signed it. Whether it was deliberate or not is a matter for law courts, not protection schemes.) Proof consists of a copy of the infected software, as originally signed by the person releasing it, together with details of the infection, that can be tested by anyone reading about it. 3.2.2 "I've never signed bad advice" If anybody gives signed bad advice that would be adopted automatically by users who have decided to trust their advice, anybody damaged can PROVE the advice was bad. Proof consists of a copy of the signed advice, together with the proof that the advisor got it wrong. This can result in other software certifiers issuing signed warnings to disregard advice from the signature that has been proved to them to be unreliable. Issuing a signed warning, without being able to provide the proof when requested, can also be dealt with. Having asked for proof, other software certifiers will be willing to stake their reputations by issuing signed warnings that warnings from a particular signature should be disregarded. Signed warnings from software certifiers they trust can automatically prompt users to revise their lists of who to trust, and to review what software on their systems may be dangerous as a result of having accepted bad advice. Being able to PROVE these things, makes it possible to establish a completely informal decentralized and automatic system for distributing recommendations along with software. Such a system can be fully automated so that it is almost completely transparent to users, who only have to decide on accepting the signatures of a few people whose recommendations and warnings they will trust. FidoNews 5-26 Page 17 27 Jun 1988 3.3 Implementation All encrypted files would have a standard header including the public key to be used (about 150 bytes). Decryption software can look up the key (or a shorter hash of it) automatically in a user's database of acceptable keys. Thus to decrypt a file, users wouldn't even have to specify keys along with filenames. To decide whether to trust some software, users wouldn't have to look up their database manually. The key is either there or it isn't, when the decryption software tries to process an encrypted file. Initially trusted signatures could be in standard format files called PUBLIC.KEY, similar to individual nodelist lines. These would normally be obtained direct by downloading or file request from the trusted phone number contained within them. Acceptance of those initial signatures as trustworthy would result in automatic acceptance of subsequent files containing recommendations or warnings signed with those signatures - until the end user decides otherwise. After decrypting the recommendation or warning the software would automatically apply to the user's keys database. Standard formats similar to the St Louis nodelist can be used to distribute (signed) lists of recommendations and warnings about particular public key signatures. Utilities similar to MAKENL and XLATLIST (but with a "user friendly" interface) can be used automatically together with the encryption software, to produce customized end user databases of what signatures they will automatically accept or reject. End users just decide on a few signatures they INITIALLY consider trustworthy, and then simply pass any encrypted files they receive, whether software, recommendations or warnings, through their encryption utility to automatically update their keys database as well as to decrypt the software recommended by people they trust and not warned against by people they trust. The main complication for a full protection system is to avoid the encryption utilities and key databases themselves becoming infected, despite end users not fully understanding what it's all about. This can be achieved by writing the software so it HAS to be used in a secure way, eg coldbooting from a "safe" floppy, encouraging floppy backups of the encrypted versions of all software that is accepted, and keyboard entry of checksums of PUBLIC.KEY files. I'm drafting some proposed standards, specifications and end user instructions for immediate and future software development. Anyone interested in details of these proposals please file request CRYPLIST from 1:221/162 for a list of what's available so far. If anyone can suggest a simpler approach that is foolproof, or can see loopholes in this one, please send NetMail to me at 1:221/162.14. Likewise for anyone interested in working on FidoNews 5-26 Page 18 27 Jun 1988 software and standards. I'd like to start an echo, AREA:PUBKEY, for serious discussions among interested software developers. It really has to happen NOW. 3.4 Free Exchange of Information Using this approach, software distributors, BBS SysOps and user groups etc can freely distribute the encrypted versions of software, recommendations and warnings from anybody, without worrying about whether the software is infected or whether the recommendations and warnings are reliable. They simply notify end users not to accept anything that has not been encrypted with a digital signature that the USER trusts (whether directly or as a result of trusting recommendations and ignoring warnings). The recommendations and warnings just get distributed along with encrypted software. This is an unfamiliar concept, but it can be implemented with simple, "user friendly" utilities. It requires NO work "testing" software and will ultimately be much easier to get across to end users than the idea of software celibacy. It also requires NO centralized authorities to put their stamp of approval on things. Apart from the unlikelihood of such authorities being established or accepted, there would be real dangers of abuse judging from the way I've seen FidoNet coordinators treat the nodelist. I'll be going into that in later articles. 3.5 Isn't it too complicated? Yes, for now. I'm hoping there will be SOME people who understand AND agree with the point I'm making and will work on designing a system as easy to use as possible for when its needed. Once its needed, it will be needed BADLY, and the alternatives will be FAR more complicated and basically won't work. In that situation, which could come SOON, some SysOps and user groups may go on distributing unencrypted software. But they will lose popularity either gradually or very suddenly. At least this proposal provides an alternative to pretending that viruses can't get past detection utilities, and then wondering why use of BBSes has suddenly become unpopular. HOW safe to play it is up to each user. Some will be silly enough to trust any PUBLIC.KEY they are offered. Each time their hard disk gets trashed they will at least learn not to trust THAT signature again, and eventually they may learn more. Once enough users have been educated through experience, it will become pointless attempting to release viruses - they aren't going to travel far unencrypted and each signature used successfully is going to reduce the number of gullible fools willing to accept FidoNews 5-26 Page 19 27 Jun 1988 unknown signatures. Of course some "software certifiers" may irresponsibly issue software or recommendations under their signatures without sufficient care. But they will quickly AND AUTOMATICALLY be discredited and others more reliable will take their place. Major software publishers will probably prefer to encourage users to rely only on shrink wrapped factory fresh disks. They may even welcome the additional incentive to do so. But they could end up in the same position as religious moralists claiming that monogamy is the only answer to AIDS. If a really devastating virus gets out on a factory fresh diskette, that publisher will probably go out of business and others may start publishing their public keys in magazine ads and printed manuals (or shorter hashes of the full keys). 3.6 How could this proposal get widely adopted? End users that receive encrypted software and recommendations distributed by BBSes, user groups or other end users are FORCED to apply the encryption utility before they can use the software. There are VERY good reasons why developers of FidoNet mailers and related utilities should be using this system NOW, as I'm explaining in a separate technical paper. If they do so, responsible FidoNet SysOps will start accepting only the encrypted versions (although initially decrypted versions would continue circulating). Once encrypted software starts being released, using it just involves running the encryption utility on the files received, with minimal inconvenience. Once FidoNet SysOps are doing that for essential network software updates, it will be easy for other software authors and publishers to adopt the same system and for SysOps to make it available directly to their users. Thus the system could take off rapidly, once it gains a foothold. The "inconvenience" of running an encryption utility, can be hidden by the "convenience" of having a system that automatically keeps track of ALL the user's software installation and backups, superior to the cataloging utilities available now and with the advantage of automatic enforcement of use. It can also be integrated with concepts like Megalist, for automatic tracking of what's available and where to get it. Keeping track is ESSENTIAL for virus killing, to recover from having trusted irresponsible recommendations by restoring original uninfected software, and to be able to track down, remove, and warn others about, the signatures that caused the problem. It has to be done automatically, or it won't be done properly. However this can be implemented later, after basic FidoNet software has been protected by a preliminary system. Initially FidoNews 5-26 Page 20 27 Jun 1988 FidoNet utilities could just be protected with publication of the PUBLIC.KEY files of their authors, (eg in FidoNews, or shorter hashes as nodelist flags), without the full mechanism for exchanging recommendations and warnings and keeping track etc. 4. POSSIBLE PROBLEMS 4.1 Legal Hassles The US National Security Agency has a policy opposed to the widespread use of secure encryption techniques and has classified some commercial public key encryption packages such as Cryptmaster and PKcrypt as "weapons" subject to munitions export controls. However this does NOT apply to publicly available information including shareware and public domain software available for download from BBSes (although some people have been bluffed into believing it might). Under the US Export Administration Regulations there is a General Licence "GTDA" (part 379.3) which covers all such publicly available technical data and is NOT overridden by the munitions regulations (logical when you think about it - the US Government is not so silly as to even TRY to prohibit export of publicly available data!). Full details for anyone interested are contained in a USEnet discussion as file GTDA.ARC (10K) available for file request from 1:221/162. Books containing detailed algorithms are readily available and public domain or shareware source code would be in the same category. (Some has already been released through BBSes and USEnet). I would recommend the following books for a thorough professional understanding of secure cryptographic techniques: Alan G. Konheim, "Cryptography: A Primer", John Wiley & Sons, New York, 1981. Carl H. Meyer and Stephen M. Matyas, "Cryptography: A new dimension in computer data security", John Wiley & Sons, New York, 1982. 4.2 Developing Encryption Software Development of a standard public key encryption utility that can be used widely involves no significant technical problems at all. Its true that software with even the best key generation algorithms runs extremely slowly, but each software author or publisher only needs to generate their keys once and end users don't need to do it at all (although there are extra benefits if they do). Actual encryption and decryption operates at quite acceptable FidoNews 5-26 Page 21 27 Jun 1988 speeds with existing commercial packages and can no doubt be further improved with the superior programming resources available within FidoNet. For our purposes a high speed "hybrid" implementation could be quite acceptable, at least initially. This would use relatively slow public key encryption to authenticate only a short hash of the attached software, using a cryptographically secure hashing method. The actual software need not be encrypted at all, but just hashed with a more complex algorithm than the usual CRC and producing at least 10 bytes of output. (That could also keep NSA happy). A smooth transition could be achieved by using a normal ARC file, which can just be used to unARC the software directly or ALSO used to check a file within it that contains the "signed" hash of the rest of the ARC file. In the long run though, once things get really bad, it would be better to force users to actually run the software provided for authentication, by actually encrypting entire files. The transitional system would be useful for secure distribution of a better system released later. I am writing a draft proposal for the FidoNet Technical Standards Committee suggesting standards to ensure utilities developed will be secure, compatible, fast, widely adopted, suitable for porting to all common computers and suitable for other FidoNet uses. (Other uses with further software development include: private and authenticated Email; a convenient, decentralized and secure means for exchanging nodelist information and session passwords between nodes; and Email voting systems.) 4.2 Is Public Key Encryption Secure? Most digital signature techniques rely on the computational difficulty of factorizing large composite numbers. This problem has defied mathematicians for some 200 years but has not been proved cryptographically secure or even "NP complete" (a measure of computational complexity which does NOT prove cryptographic security). There is some indication that these methods CAN eventually be cracked or MAY have already been cracked, with the results classified. Fortunately this problem need not concern us unduly as it is unlikely that a major breakthrough in higher mathematics will first come to light as a result of its discovery by someone warped enough to want to launch destructive viruses! (Not that some mathematicians aren't pretty warped, but they'd probably prefer to take the public kudos for announcing the solution!) If new developments make any particular digital signature system insecure, alternatives are available and can be implemented quickly. (Unlike virus detection programs which just simply won't work AT ALL against the next generation of viruses.) Standards for file headers etc should provide for later upgrades. The main thing is to have the machinery in place for when its FidoNews 5-26 Page 22 27 Jun 1988 needed, and improve it later. 4.4 Developing End User Software Some pretty neat software will need to be written quickly for end users automatic key databases and tracking etc. It has to end up being a lot more professional and "user friendly" than most public domain and shareware software and provide lots of extra benefits like software cataloging, to gain wide acceptance BEFORE a disaster hits. That's why I wrote this article. Now who's going to do the hard stuff? Oh well, there it is. Sorry about the length, but if nobody pays any attention, guess who'll be saying "I told you so". ----------------------------------------------------------------- FidoNews 5-26 Page 23 27 Jun 1988 ================================================================= NOTICES ================================================================= The Interrupt Stack 16 Jul 1988 A new areacode, 508, will form in eastern Massachusetts and will be effective on this date. The new area code will be formed from the current areacode 617. Greater Boston will remain areacode 617 while the rest of eastern Massachusetts will form the new areacode 508. 25 Aug 1988 Start of the Fifth International FidoNet Conference, to be held at the Drawbridge Inn in Cincinnati, OH. Contact Tim Sullivan at 108/62 for more information. This is FidoNet's big annual get-together, and is your chance to meet all the people you've been talking with all this time. We're hoping to see you there! 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- Latest Software Versions BBS Systems Node List Other & Mailers Version Utilities Version Utilities Version Dutchie 2.90* EditNL 4.00* ARC 5.21 Fido 12h MakeNL 2.12* ARCmail 1.1 Opus 1.03b Prune 1.40 ConfMail 3.31 SEAdog 4.10 XlatList 2.86 EchoMail 1.31 TBBS 2.0M XlaxNode 1.02 MGM 1.1 BinkleyTerm 1.50 XlaxDiff 1.02 QuickBBS 2.01 ParseList 1.10 * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 5-26 Page 24 27 Jun 1988 OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION Ken Kaplan 100/22 Chairman of the Board Don Daniels 107/210 President Mark Grennan 147/1 Vice President Dave Dodell 114/15 Vice President - Technical Coordinator David Garrett 103/501 Secretary Leonard Mednick 345/1 Treasurer IFNA BOARD OF DIRECTORS DIVISION AT-LARGE 10 Steve Jordan 102/2871 Don Daniels 107/210 11 Bill Allbritten 11/301 Hal DuPrie 101/106 12 Leonard Mednick 345/1 Mark Grennan 147/1 13 Rick Siegel 107/27 Brad Hicks 100/523 14 Ken Kaplan 100/22 Ted Polczyinski 154/5 15 Jim Cannell 128/13 Kurt Reisler 109/74 16 Vince Perriello 141/491 Robert Rudolph 261/628 17 Rob Barker 138/34 Greg Small 148/122 18 Christopher Baker 135/14 Bob Swift 140/24 19 Vernon Six 19/0 Larry Wall 15/18 2 Henk Wevers 2:500/1 Gee Wong 107/312 ----------------------------------------------------------------- FidoNews 5-26 Page 25 27 Jun 1988 FidoCon '88 - Cincinnati, Ohio At The Drawbridge Inn and Convention Center August 25-28, 1988 Attendee Registration Form Name: ____________________________________________________ Address: ____________________________________________________ Address: ____________________________________________________ City: _______________________ State: ____ Zip: ___________ Country: ____________________________________________________ Phone Numbers: Day: ____________________________________________________ Evening: ____________________________________________________ Data: ____________________________________________________ Zone:Net/ Node.Point: _______________________________________________ Your BBS Name: _______________________________________________ BBS Software: _____________________ Mailer: _________________ Modem Brand: _____________________ Speed: _________________ What Hotel will you be Staying at: ____________________________ Do you want to share a room? ______ Are you a non-smoker? ______ Do you want an in room point? ______ (Tower rooms at Drawbridge only) Do you need special accommodations? ______ (If so, please explain) ____________________________ ____________________________ FidoNews 5-26 Page 26 27 Jun 1988 Are you a non-Sysop? ______ Are you an IFNA Member? ______ If so, will you be attending the Sunday IFNA brunch/BoD meeting? ______ Additional Guests: ______ (not attending conferences) Comments: ____________________________________________________ ____________________________________________________ ____________________________________________________ Costs How Many? Cost --------------------------- -------- ------- Conference fee $60..................... ________ _______ ($75.00 after 7/31) Thursday Lunch $10.95 .............. ________ _______ Thursday Dinner $18.95 .............. ________ _______ Friday Lunch $10.95 .............. ________ _______ Friday Banquet $24.95 .............. ________ _______ Saturday Lunch $10.95 .............. ________ _______ ======== ======= Totals ................................ ________ _______ You may pay by Check, Money Order or Visa/MC Please send no cash. All monies must be in U.S. Funds. Checks should be made out to: "FidoCon '88" This form should be completed and mailed to: FidoCon '88 Registration P.O. Box 9294 Cincinnati, OH 45209 If you pay by Credit Card you may also register by Netmailing this completed form to 108/62 or 1/88 for processing. Please complete the information below and be sure to include a voice phone number above so that we can contact you for Credit Card FidoNews 5-26 Page 27 27 Jun 1988 verification. Rename this file ZNNNXXXX.REG where Z is your Zone number, N is your Net number, and X is your Node number. [ ] Visa [ ] MasterCard Name as it appears on credit card: ___________________________________________ Credit Card Number: ___________________________________________ Expiration Date: ___________________________________________ Signature: ___________________________________________ (If you mail in registration) ----------------------------------------------------------------- FidoNews 5-26 Page 28 27 Jun 1988 INTERNATIONAL FIDONET ASSOCIATION ORDER FORM Publications The IFNA publications can be obtained by downloading from Fido 1:1/10 or other FidoNet compatible systems, or by purchasing them directly from IFNA. We ask that all our IFNA Committee Chairmen provide us with the latest versions of each publication, but we can make no written guarantees. Hardcopy prices as of October 1, 1986 IFNA Fido BBS listing $15.00 _____ IFNA Administrative Policy DOCs $10.00 _____ IFNA FidoNet Standards Committee DOCs $10.00 _____ SUBTOTAL _____ IFNA Member ONLY Special Offers System Enhancement Associates SEAdog $60.00 _____ SEAdog price as of March 1, 1987 ONLY 1 copy SEAdog per IFNA Member Fido Software's Fido/FidoNet $100.00 _____ Fido/FidoNet price as of November 1, 1987 ONLY 1 copy Fido/FidoNet per IFNA Member International orders include $10.00 for surface shipping or $20.00 for air shipping _____ SUBTOTAL _____ HI. Residents add 4.0 % Sales tax _____ TOTAL _____ SEND CHECK OR MONEY ORDER IN US FUNDS: International FidoNet Association c/o Leonard Mednick, MBA, CPA 700 Bishop Street, #1014 Honolulu, HI. 96813-4112 USA Name________________________________ Zone:Net/Node____:____/____ Company_____________________________ Address_____________________________ City____________________ State____________ Zip_____ Voice Phone_________________________ Signature___________________________ -----------------------------------------------------------------