Red Herrings

Part of 22C:169, Computer Security Notes
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

Red Herrings

When assessing the security of a system, it is common to be faced with very irregular degrees of protection. Everyone is always fighting the last war, so whatever threat those responsible for the system have most recently faced will be the one that they build elaborate defenses against.

These defenses can be fascinating. They can serve to distract a security evaluator from the real problem. Remember: The security of a system is determined by the least secure element. A security assessor should be looking for the weak link.

For example, don't be distracted by the quality of the lock on the front door when the back door is left routinely open. Don't be distracted by the presence of locked doors when the windows are open. Don't be distracted by locked safety glass windows when the next-door apartment is vacant and the walls are made of drywall over wooden studs. A quick kick is all it takes to go through such a wall. Of course, in the case of walls, even thieves are often taken in by our convention that you don't go through the wall.

An Example

In late 1996, Wyle Labs of Huntsville Alabama was asked to evaluate the security of the iMark Electronic Ballot Station, a voting machine. Their assessment said that this was the best voting system software that they had ever seen, and they were particularly impressed by its security, particularly by its use of cryptography.

In fact, as emerged later, the firmware was horribly insecure, with multiple buffer overflow vulnerabilities scattered throughout, and with incredibly naive use of cryptography. The iMark EBS was the prototype for the Global AccuTouch, which became the Accuvote TS voting system when Diebold bought Global. The insecurity of this system has generated a huge amount of discussion in the years since.

DES, Another case study

The United States Data Encryption Standard, DES, is another case worth examining. DES was selected as a national standard in 1976, and as a result, it came to be very widely used. From the day it was introduced, it was suspected that the National Security Agency knew something about cracking DES, and there were suspicions from the start that DES contained some kind of secret backdoor.

As in the iMark/Global/Diebold system, the presence of an elaborate encryption mechanism such as DES served to distract from fundamental flaws in the system that used it. As it turns out, the suspicion of the NSA was itself a red herring, distracting from the real weakness of DES.

DES used a 64 bit key, but in fact, this 64-bit key included 8 rather gratuitous parity bits, one per byte of the key, so the key was actually only 56 bits. The backdoor was simple: 56 bits is not really a long enough key. In 1998, the Electronic Frontier Foundation built a DES cracking machine for a cost of $250,000.

Double Encryption

If DES can be broke, why not double-encrypt? That is, instead of using DES once, use it twice -- triple DES. A triple-DES key is 3 regular DES keys. You simply encrypt 3 times, using the keys in succession.

In fact, this seems to work, but there are no guarantees. Consider using an exclusive-or cypher. To encrypt the message M with keys A, B and C, compute ((M XOR A) XOR B) XOR C). The problem is, this is equivalent to (M XOR (A XOR B XOR C)), which is to say, the triple-encryption was no more secure than single encryption. All you get for the added complexity is a more cumbersome key.

In general, if you apply multiple encryption algorithms that are mathematically unrelated, you have a reasonable chance that their combination will be stronger than any one of them used alone. The difficult case arises when they are the same algorithm.

Double Checksums

The above applies to double checksums as well: If a cryptographic secure hash function is weak -- that is, if there is some way to fix a message to have the desired checksum, thus defeating the checksum's role as an authenticating mechanism, you may think, well, why not simply add a second checksum. The answer is, this may indeed work if the two checksums are computed in entirely orthogonal ways. If one is computed using a cyclic shift register while the other is computed using DES, the combination may well be stronger than either one alone.


For some of the history of the iMark/Global/Diebold voting system, see: The Case of the Diebold FTP Site. This is something of a case study in the bureaucratic reaction to the disclosure that a secure voting system is not really very secure.

Also, see the Wikipedia: