Improving the Attack Using ElGamal

By using a specific type of public key cryptosystem the attack can be improved slightly. Ideally, the Trojan horse author would like the ad- ministrator of the host machine to be as oblivious to the activities of the Trojan horse as possible. This includes not letting the administrator know how many passwords, if any, were stolen before the discovery of the Trojan horse.

This can be accomplished by using the ElGamal cryptosystem [110] modified appropriately [304] to be semantically secure under plaintext at- tacks6 _{(see Appendix C.2.2). Recall thatx is the private key and (y, g, p)}

is the corresponding public key in ElGamal. The ciphertext of m is the pair (a, b). One of the most useful properties of ElGamal is that its ci- phertexts are malleable under multiplication. By multiplying b by some other plaintext m1 the encrypted plaintext becomes mm1 mod p. Also,

it is possible to rerandomize ElGamal ciphertexts as follows. Choose a value k1 < q randomly and compute (a0, b0) = (agk

0

mod p, byk0 _{mod p).}

This changes the appearance of (a, b) completely and (a0, b0) decrypts to the same value as (a, b).

In regular intervals the Trojan horse can be designed to perform this rerandomization to all M ciphertexts regardless of whether or not any new passwords are stolen. Also, the decision to steal each login/password pair can be probabilistic. As a result, with some very small probability the Trojan will never encrypt any login/password pairs. This approach will hamper the sysadmin’s attempt to determine if any passwords have been stolen before the discovery of the Trojan horse. If disk backups are continually taken then system administrators will have a chance of catching a glimpse of the previous activities of the Trojan horse. For example, a dump of virtual memory could expose the virus while it was encrypting a given user’s password. However, if all of the backups miss

these small windows of opportunity, then it could not be proven that any passwords had been stolen prior to the discovery of the Trojan. All M

entries will change regardless of whether or not the Trojan snatches a single password.

As in turns out the deniable password-snatching attack can be im- proved even more. By observing the password-snatching Trojan in action it is possible to witness it encrypt passwords and transmit them. It is possible to redesign the Trojan so that even when the Trojan is monitored at runtime it is not possible to tell if it is actually encrypting anything. The improved attack utilizes a new notion that we call questionable en- cryptions. See Section 6.6 for details.

Cryptocounters

A common trigger used in viruses to decide when to attack is a counter value. Such viruses typically do not trigger until it has propagated itself a certain minimum number of times. The Den Zuk virus contains such a trigger [289]. When counters are used only to measure the number of viruses in the wild, a good approach is to utilize two different generation counters. One counter would store the generation number of the virus that is incremented by one in each child a given virus has. This would provide the heighthof the family tree. The other counter would be used to measure the average number of children that each virus has (see Chapter 1). This mechanism could be used as a tool for measuring replication performance of viruses in real-world infections.

However, antiviral analysts would likely benefit more than virus writers from the incorporation of counters in virus code since they would receive better population samplings. To solve this malware problem, a method is needed to implement such counters in a way that the viruses can in- crement the counters but that only the virus writer can read the actual counter values. A cryptocounter is a cryptographic primitive that solves this problem.

In this chapter a simple cryptocounter scheme is presented based on the ElGamal public key cryptosystem. Drawbacks to this approach are then given, followed by an improved approach based on the Paillier public key cryptosystem. The chapter concludes with discussion of even more ways to implement a cryptocounter.

5.1

Overview of Cryptocounters

Informally, a cryptocounter is a probabilistic public key encryption that encrypts a counter value that anyone can increment or decrement but that can only be decrypted using the appropriate private key. Put another way, it is a malleable ciphertext that allows the plaintext to have 1 added to it or 1 subtracted from it. The increment and decrement operations can be performed by anyone without even knowing the plaintext value and without first decrypting the encryption of the counter value.

The typical threat model for the operation of a cryptocounter is the honest-but-curious model. In this model, it is assumed that the machine that increments the cryptocounter does so properly, and does not change the counter in unexpected ways. For instance, if the algorithm normally increments the cryptocounter once every hour, the machine does not ma- liciously increment it twice every hour, and so on. It is assumed that the machine that operates on the cryptocounter ciphertext is passive and merely observes any and all computations regarding the counter. The machine may do its best to try to learn the counter value based on these observations, hence the term curious. In this sense the machine is a form of passive adversary. But, the machine does not interfere with the nor- mal operation of the counter, which is a capability that active adversaries have.

By placing a cryptocounter within the virus, there is an added level of protection over the use of a plaintext counter. The counter value that the cryptocounter encrypts will never be revealed. This holds even if snapshots of the cryptocounter are taken on a regular basis. Such snapshots can occur as the result of coredumps and so forth. It is necessary to monitor the operations on the cryptocounter each step of the way in order to keep track of the current counter value.

Consider a virus that stores two cryptocounters to help keep track of the number of viruses in the wild. It is relatively safe to assume that before the virus is discovered, the host machine will not corrupt the counter value and will not interfere with the virus when it increments the counter. Also, it is prudent to assume that once the virus is found several system administrators may examine their logs to try to determine the counter values. Assuming that the snapshots are spaced out reasonably far enough, the snapshots are not likely to reveal the counter values that the viruses contain.