greenber@utoday.UU.NET (Ross M. Greenberg) (12/21/89)
Bob Bosen, of Enigma, comments in VL V2#265 further about the need for
X9.9 as the level of sophistication required of an authentication
scheme.
I'm not sure he's right. Let's look at two different usages for
authentication schemes: one, to determine if a program is what you
expect it to be during a "global" scan, one to determine if the
program is what you expect it to be immediately before it is run.
A subset of the second portion above is whether a program can contain
a self-checker -- a portion that checks itself when it is run. I
propose that self-checkers, while useful, are meaningless: by the time
a self-checker's checking code is run, the virus or trojan's damage is
already done. Additionally, what prevents the virus/trojan from
removing itself from the host file and/or memory before the
self-checker runs? Therefore, self-checking programs are not realy
worthy of further comment.
Case 1, above, when a scanning program checks a file's signature
against a supposed signature is good stuff. Yet, you must prepare
yourself for a long initial time to build the original authentication
database -- the more complex the scheme, the longer such a check will
take. There's a commercial anti-virus program out there already that
does some sort of authentication check on every executable on your
disk (PC-based). On a full disk, it can take something like three
hours to run on an XT machine. X9.9 might be a good approach, but if
it takes even that longer and not longer, you simply won;t get people
using it -- regardless of how wonderful it is. If I have to run such
a beast each morning, I'll pass. I think most commercial users would
bypass a long wait -- they do, after all, have some work to do.
What about a checker that checks only that a file you're about to run
is what you expect, then? This *may* be worthy of comment (heck, my
own code does that! :-) ), but it depends on how long it takes. If it
takes me ten minutes to load Word Perfect on my trusty 4.77MHz, run
asophisticated authentication check against it and then finally get to
run it, well, my boss is not going to be too happy. So, the more
sophisticated the algorithm, the less likely it is to be used. I know
this from my own beta testers for a new release of my own product:
they felt that the more sophisticated checker, although nice and more
trustworthy, simply took too long to run. Given a choice, and they
make their choices known with their payments, they opt for one that's
"good enough".
What's a programmer to do, then? My suggestion is easy: forget those
who claim that sophisticated checkers are what we need -- they may be
right, but there are many drawbacks to them, and we all still have
work to do! Forget those who claim that their solution is the only
solution. But, I'd rather have two unrelated and unsophisticated
algorithms that the "bad guy" knows nothing about, then one
"unbeatable" algorithm that goes unused.
Since there are umpteen different ways that such checkers could be
written, the odds of two such routines generating the same results
given a change in the source is pretty darned small. And, if you're
still in doubt, then run a third or forth or 20th checker.....
Ross M. Greenberg
Ross M. Greenberg, Technology Editor, UNIX Today! greenber@utoday.UUCP
594 Third Avenue, New York, New York, 10016
Voice:(212)-889-6431 BIX: greenber MCI: greenber CIS: 72461,3212
To subscribe, send mail to circ@utoday.UUCP with "Subject: Request"