71435.1777@CompuServe.COM (Bob Bosen) (11/28/89)
My epistle of several days ago regarding ANSI and ISO Message Authentication Code (digital signature) standards generated quite a few follow-up responses and other questions. Several people asked me about my internet address. Most of you guessed correctly. I can get to internet either via NCSC's "dockmaster" or through CompuServe. Although CompuServe is more expensive, it is a lot more convenient for me because I've got a "user-friendly" application for my PC that automates most of my interaction with CompuServe. What this means to internet users is that you can send electronic mail to and receive mail from CompuServe subscribers IF both of the following conditions are true: 1- You must know the CompuServe account (subscriber) number 2- The CompuServe subscriber must actively access CompuServe and send/receive mail. CompuServe subscriber numbers generally look a lot like mine (71435,1777) and consist of two numeric fields separated by a comma. In order to convert a CompuServe subscriber number into an internet address, replace the comma with a period, and append the suffix "@COMPUSERVE.COM". Thus, when addressing me through CompuServe, my internet address is: 71435.1777@COMPUSERVE.COM A lot of other people sent me mail requesting ways to get hold of the ANSI and ISO standards I referenced. Copies of ANSI standard X9.9 can be obtained by sending $2.00 to: ANSI X9 Secretariat I am less familiar with ISO than with ANSI. I got my copy of ISO 8731-2 from ANSI because I am a member of the X9E9 working group. But I believe you can get a copy of ISO standard 8731-2 by writing to: Steve Wornick commented on the value of sophisticated, cryptographically based signature programs as follows: > Bob Bosen brings up some interesting points, asking why programmers > writing authentification (sic) programs are utilizing CRC and > checksum algorithms rather than more sophisticated algorithms like > ANSI X9.9, ISO 8731-2, or DES. I think it depends on what you are > trying to do. If your plan is to encrypt your program and rely on > difficulties in decryption for protection against infection, > then it probably makes sense to use something very sophisticated, > because you want to make certain that no one but yourself can do > the decryption.... On the other hand, if you are not encrypting > your program but are simply trying to generate a number.... for > authentification (sic) purposes, I don't see that it is necessary > to use anything more sophisticated than a polynomial. If the virus > doesn't know your polynomial, then it's chances of guessing a > sequence of characters with which to "pad" your program file in > order to generate the same CRC value as the original unaltered > program is quite small. Of course, everyone ought to be using a > slightly different algorithm (i.e. different polynomials) and > ought to be hiding the authentication algorithm. Industry-standard authentication algorithms such as X9.9 (DES based) and ISO 8731-2 are NOT intended to encrypt files. They produce a short "digest" or signature of information (in this case a program file). Steve's suggestion that CRC algorithms can be sophisticated enough to make guessing virtually impossible (if the algorithm itself is hidden) MAY or MAY NOT be true. The risk that this assumption MAY NOT be true is fairly high, especially if programmers rely on their own resources on how to write a bunch of different yet "good" CRC algorithms. This is even more true if the test is "on-line", because on-line authentication implies on-line presence of the authentication algorithm, where a sophisticated virus could determine the CRC algorithm and/or associated initialization vectors (keys). Today, in late 1989, Steve can make and defend the position that CRC algorithms are good enough, especially if programmers are knowledgeable about the security considerations, and if the signature is calculated and verified "off-line" in environments where no virally contaminated programs have a chance of grabbing executional control. But in my opinion, this position is short-sighted. Who can say whether the more sophisticated viruses of the future will attempt to analyze CRC signatures or target specific products that rely on CRC methods? Why not base today's protection on the best available and best documented facts? The newly emerging science of authentication technology has clearly revealed that it is easier to compromise even sophisticated authentication algorithms than previously thought. David Paul Hoyt says: > Mr. Bosen points to very good documents that will point the serious > anti-viral minded software developers to an excellent method of > defending their software.... However, I would like to add a comment. > Any of these auth-check schemes rely on a small number (1 to n) of > of programmed checks to see if the software has been corrupted. > While this will defend against a general-purpose or unsophisticated > virus, it has little value against a malicious attack against > your product. What kind of "malicious attack against your product" are you talking about? Whatever it is, I'm sure the other members of the ANSI standards (X9E9) working group and I would be very interested in learning about it, because if this assertion is true, it could possibly compromise the entire banking wire-funds transfer mechanism that transfers billions of dollars every day. Are you saying you could write or describe a virus that could infect a program but avoid detection by an off-line ANSI X9.9-based message authentication code? I'll acknowledge that this is possible with an on-line ANSI X9.9 MAC, but it would take a lot of blind luck and something on the order of a billion guesses. The consensus among standards organizations has been that this is an acceptable risk in the case of the authentication algorithms that have been studied and standardized. As I said in my earlier message, in my experience both on-line and off-line checks have advantages and disadvantages, and a sophisticated defense must allow users to pick and choose from all of these techniques according to his needs. A heirarchy of interlocking defenses must be put together, with on-line tests acting as the first line of defense, and with periodic off-line checks. The on-line checks can detect the viruses known today, and the off-line checks verify the integrity of the on-line defenses and also protect against sophisticated future viruses. Bob Bosen Vice President Enigma Logic Inc.