ENCRYPTION: A MIXED BLESSING?
by Eugene Volokh, VESOFT
Published by HP PROFESSIONAL Magazine, May 1988.
At first glance, encryption programs (several are available on the
Contributed Library) seem to be powerful security tools. Encryption
is the only fairly foolproof way of protecting data against
unauthorized reading, both by outsiders and insiders. Even the
system manager, to whom MPE gives unlimited access rights to any file
in the system, can't read a personal document that you've encrypted
with your own secret key.
In fact, whenever any of our customers called and asked us about
read-protecting files, we recommended one of the contributed
encryption programs. Actually, we first advised them to protect
their files with MPE's file security, which worked quite admirably as
a defense against anybody except a console operator or system
manager; however, if they didn't want even their system manager to be
able to read the files (or were afraid that some operator might pick
them up off a backup tape), encryption seemed to be the way to go.
Then, in spring of 1987, we got a call from one of our users.
They had just fired one of their programmers and two days later found
that their system was aborting! Sure enough, there was a time bomb
in their software (I had to find it in the object code since they had
lost the source code!) and I had to defuse it by patching the program
file. In fact, I had to come back six months later to defuse yet
another time bomb in the same program, and at that time found a third
bomb that was set to "explode" a month later.
Shortly after I got rid of the first time bomb, they called us
again. Apparently, some months before being fired, the saboteur had
encrypted the source code of another of their systems! Tens of
thousands of dollars worth of software was now completely
inaccessible, the key known only to the departed programmer.
This, of course, is the "mixed blessing" that I allude to in the
title of the paper. This company actually had NO NEED for any kind
of source code encryption. Although some sites may have a use for
encryption (mostly of their data and, say, management memos, letters,
etc.), this site did not; certainly, it derived no benefit from being
able to encrypt its source code, since it wasn't in any way secret.
In any event, somebody must have pulled the encryption program off
a contributed library tape, and our hero decided to "protect" the
company's source code. He may have done this maliciously, or perhaps
he may have been the kind of person who impulsively protects things
even though they really require no protection. (Naturally, being the
vendors of a security package, we encourage people to "think
security" -- however, encrypting source files is usually going a bit
too far; much better to be concerned with things like logon security,
embedded passwords, periodic password changes, etc.). What matters
is that he was gone and the source code was unreadable -- which
meant, as I mentioned, a loss of tens of thousands of dollars worth
of software investment.
When our customer first mentioned this to us, our first suggestion
was, of course, to ask the culprit. Bribe him, threaten him with
lawsuit, threaten him with criminal prosecution (the time bomb itself
was almost certainly a crime, perhaps a felony) -- even if you
couldn't get a conviction, you should be able to frighten him into
giving you the key, which, after all, would be the easiest thing in
the world for him.
Unfortunately (I say "unfortunately" because I think the guy
should have had the book thrown at him -- he's a menace), the company
wanted nothing whatsoever to do with the man again. They are a large
enterprise, with a large enterprise's distaste for negative
publicity; management would rather lose thousands than get involved
in a "Goliath vs. David" sort of case where they (although they are
in reality the innocent party) might be portrayed as big bad guys
trying to "get" a poor helpless ex-employee.
Instead, they asked me whether there was anything I could do. At
first glance, I thought that this was impossible -- after all, any
good encryption system that uses an encryption key is (theoretically)
almost unbreakable; you can try to decrypt the encrypted file, but
unless you stumble across the right key, all you'll get is garbage.
I'm sure that some National Security Agency cryptographers armed with
Crays could do it in a jiffy, but I have neither their hardware nor
their sophisticated algorithms (in fact, much advanced cryptography
is classified as government secret).
Fortunately, I got an idea. If
SOURCE FILE + KEY yields ENCRYPTED FILE (encryption)
and
ENCRYPTED FILE + KEY yields SOURCE FILE (decryption)
then it stands to reason that
SOURCE FILE + ENCRYPTED FILE yields KEY
In other words, if they had an unencrypted copy of one of the
encrypted files, then with luck I might be able to deduce the key
with which the file was encrypted, and then decrypt the rest of the
files with that key (if they were all encrypted with the same key).
I asked the author of the encryption program for its source code
and got to work. A couple of days later (and a couple of thousand
dollars later for our client), I worked out a solution. Essentially,
I reduced the problem to a system of 64 equations with 64 unknowns,
where the operators were Circular Shift and Exclusive OR.
Unfortunately, I knew of no way to solve it algorithmically; instead,
I wrote a PASCAL program. This program made assumptions about each
unknown (each unknown's value could be 0 or 1, and it made each
assumption in turn) until it got enough data to start making
deductions. Then it would deduce as many values as possible until it
either figured every value out (a solution), got a contradiction (in
which case it would forget the last assumption it made and assume the
opposite), or found that it could make no more deductions (and thus
had to make some more assumptions).
Finally, after about an hour's computer time, I got 256 possible
solutions. It turns out that because of the nature of the algorithm,
any of them would work to decrypt the files, but only one actually
represented a sequence of printable ASCII characters -- this turned
out to be the key that the culprit actually used.
Curiously enough, the key was the name of the group in which the
files were stored. If the customer (or, for that matter, I myself)
tried it in the first place, we'd have saved a lot of time.
Thus, this case turned out better than expected -- the company got
their source code back (although they had to pay some consulting fees
to do this).
At first, we thought that this was an isolated incident. Then, a
few months later, I was scanning through a bulletin board when I ran
into a message from somebody else complaining of exactly the same
thing! A programmer had encrypted some files and then left on bad
terms. In this case, the company wasn't so lucky (I believe they
didn't have any unencrypted source code to work out the key from).
Three months later, we got a call from another person -- exactly the
same thing had happened again (again, we couldn't do anything to save
their files). Fortunately, this last person was going to do
something about it -- threaten some sort of civil or criminal
prosecution of the wrongdoer.
Thus, it appears that misuse of encryption software is not such a
rare circumstance at all. In fact, I suspect that ABUSE of
encryption is more frequent than PROPER USE (especially if you
include the accidental cases, where some over-zealous programmer
encrypts his sources and forgets his key!). By and large, there's
very little data -- especially data stored in non-database files --
that really needs encrypting; an adequate file security system is
usually quite sufficient. Certainly nobody except software suppliers
really needs to encrypt source code.
Thus, our recommendation to HP users is:
* DON'T PUT FILE ENCRYPTION PROGRAMS ON YOUR SYSTEM UNLESS YOU'RE
CONVINCED THAT YOU HAVE SOME FILES THAT YOU *REALLY NEED TO
ENCRYPT*.
In other words, don't encrypt just for "general principles" --
think whether you really need to (especially in light of the
fact that most valuable data is usually stored in IMAGE
databases, which most encryption programs don't handle).
As sometimes happens, what at first glance seems to be a great
idea can actually do more harm than good. Security is a very
important issue, and you should think about it seriously; however, as
you see, you could face serious problems if you choose the wrong
security solution.
What if you've already fallen guilty to a cryptographic saboteur?
Trying to decrypt your programs with a method like the one I
mentioned should be your last try, not your first -- it's quite
expensive, time-consuming, and uncertain (since if you don't have the
EXACT original source code, you're in trouble).
As in all cases of computer crime (or of crime in general), the
best solution is to bring in the law. Though I'm certainly not a
lawyer, as I see it, you have two possible approaches: the civil and
the criminal. You can sue (or, more to the point, threaten to sue if
he doesn't give you the key) for damages, alleging that his
intentional act (or even his negligence) has deprived you of the use
of your software, in which you've invested a great deal of money.
Or, you may try to prosecute on some sort of criminal sabotage
charge, again alleging that the person intentionally acted to deprive
you of what was rightfully yours.
I've heard different opinions on the criminal matter -- one person
(a policeman experienced in computer crime investigation) mentioned
that it may be impossible to prosecute unless you can prove that the
initial encryption was malicious; if the person claims that he
encrypted the software legitimately, out of a desire to "secure" his
employer's system, it may be very hard to prove otherwise, even if he
refuses to decrypt the software after he's fired. On the other hand,
a computer lawyer I talked to said that prosecution may not be that
difficult; you probably want to get in touch with your police
department to find out (many big police departments by now have a lot
of experience in computer crime investigation).
In any case, the mere threat of criminal or even civil prosecution
can make the culprit come around -- after all, all he needs to do is
tell you the key (unless he's forgotten it!), and then he's off the
hook. Even if he thinks he'd win in a legal case in the long run, I
strongly doubt that he'd be willing to chance it.
What's more, by taking stern action against this sort of computer
crime (and in all three cases I mentioned, and in several other ones
that I know of, crime is EXACTLY what's involved), you'll be
preventing such things in the future, both on the part of the
particular wrongdoer involved and by any of your other employees.
Just like drunk driving and shoplifting a decade or two ago, many
people see computer crime (especially sabotage) as nothing really
serious, just a "harmless prank" or a test of programmer skill --
it's time that this attitude was changed, and changed radically.