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.
Go to Adager's index of technical papers ⮂ View original 1980s typography