Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!asuvax!ncar!tank!eecae!netnews.upenn.edu!vax1.cc.lehigh.edu!sei.cmu.edu!krvw From: 71435.1777@CompuServe.COM (Bob Bosen) Newsgroups: comp.virus Subject: Signature Programs Message-ID: <0007.8911161700.AA03975@ge.sei.cmu.edu> Date: 16 Nov 89 06:02:36 GMT Sender: Virus Discussion List Lines: 117 Approved: krvw@sei.cmu.edu As a member of the American National Standards Institute's (ANSI) X9E9 working group and an active participant in standards activities regarding computer security and authentication, I have been reading the various comments on "Checksum" programs with a lot of interest ever since this forum became accessible to me about 2 weeks ago. If the comments which follow are way off-base, please forgive my newness to the forum; perhaps these things have been discussed in the less recent past.... I've been surprised at the lack of content regarding sophisticated authentication algorithms. In this forum of late,I've been reading about checksums and CRCs but I haven't heard any mention of ANSI X9.9 or ISO 8731-2, which are both extremely relevant standards. Both of these authentication algorithms have served the international banking community well, having been used for years to secure billions of dollars worth of daily wire-funds transfers without a single verified case of compromise. Checksum programs work by attempting to "authenticate" a program or file by calculating a number, based upon the content of the file. That number serves as a digital "signature" reflecting the exact status of the file at the moment when the calculation was made. Unfortunately, authentication in hostile environments is not a trivial subject, and has been shown to be susceptible to forgery and compromise. Furthermore, as Paul Kerchen and Y. Radai have recently commented, very serious attention must be paid to exactly where the signatures (and any component parts critical to their calculation) are stored. In my opinion, if properly implemented, signature programs have the potential for being much more useful than "scanners" (or any other known anti-viral technique) in most instances, since they don't require any foreknowledge about the viruses which may attack in the future. Relying on simplistic algorithms to calculate these signatures suffers from an obvious disadvantage: Future viruses can compensate for the way the signature is calculated, or forge signatures that appear to be valid. Relying on supposedly "secret, proprietary" algorithms is very risky: the annals of cryptography are littered with the bones of algorithms that couldn't withstand the scrutiny of dedicated adversaries. If the history of algorithmic research can teach us anything, it is that we shouldn't trust any cryptographic algorithms unless they've been examined by a very large population of experts. There is a developing science of "authentication technology" that is revealing important facts about the kinds of algorithms that can be relied upon to resist the scrutiny of adversaries. It's amazing how many people are unaware of these things, and it's DANGEROUS to base virus detection products on insecure algorithms. As this knowledge grows and becomes more easily available to the people that write viruses, commercial vendors of virus detection programs will be forced to learn about this stuff the hard way. The American Bankers Association, in cooperation with the American National Standards Institute, (with representation from NSA, NIST, Federal Reserve, the Vendor community, etc.) and the International Standards Organization have endorsed standardized ways of calculating digital signatures. There are powerful ways of using these respected, standardized algorithms in the reliable detection of viral contamination. It's complex and expensive to put together a practical implementation, but once it's done it can provide a very reliable first line of defense that won't need 49 different revisions per year to keep up with identified threats. By the way, for those of you that are wondering if performance will suffer, the answer is that it need NOT suffer. Certainly, unsophisticated implementations might turn out to be abysmally slow, but it is quite possible and practical, with careful design and implementation, to adapt combinations of these standards to the IBM PC world, for example, in a way that users hardly notice. Practical defenses based on ANSI X9.9, for example, can now authenticate a 100K file in 3.2 seconds on an IBM "AT"-class machine running at 10 Mhz without any extra hardware or fancy disk drives. This is best done by applying a judicious combination of DES encryption with CRC techniques on a random sampling of file contents, rippling the cryptographic residue through the entire calculation with a technique that crypto people call "cipher-block chaining". Furthermore, files don't need to be checked every single time they are used, so these modest delays need not occur more than a few times per month per file. While I'm rambling on, I can't resist the urge to comment on a related subject. Paul Kerchen writes: > where does one store these checksums and their keys? if they > are stored on disk, they are vulnerable to attack.... and Y. Radai comments on "static" versus "dynamic" invocation of signature calculation, leading to discussion of the various advantages and disadvantages of storing keys and signatures (and maybe even protection logic) on an active hard disk versus off-line storage on a diskette. In my experience, all of these viewpoints have advantages and disadvantages, and a sophisticated defense must allow users to pick and choose from all of these techniques according to his own needs. A heirarchy of interlocking defenses must be put together, with "dialy" or "dynamic" (continuous but random) checks acting as the first line of defense based on an active hard disk, and with periodic (weekly or monthly) off-line checks based on a "sterile kernel" stored on a bootable diskette that's kept locked up when not in use. In essence, the monthly checkup from the sterile kernel checks up on the defenses that've been exposed to viruses in the "dirty" world.... So how 'bout it? Anybody against using respected industry standard authentication algorithms? Anybody got a better idea? (By the way, my comments should not be construed to represent any official viewpoints of the American National Standards Institute. I'm just a member of the working group....) Bob Bosen Vice President Enigma Logic, Inc. 2151 Salvio Street #301 Concord, CA 94565 Tel: (415) 827-5707 Internet: 71435.1777@COMPUSERVE.COM