- Email: [email protected]
Some weak points of one fast cryptographic checksum algorithm and its improvement
Computers & Security, 7 (1988) 503-505
Special Note
Some Weak Points of One Fast
Cryptographic Checksum Algorithm and its Improvement Yue Jiang Huang* and Fred Cohen?
require additional hardware, or in the absence o f additional hardware, a large amount o f time. As a result, some faster checksum schemes have been proposed [3, 4]. These schemes employ functions to c o m press the plain text together with cryptographic transforms to reduce dramatically computation time while providing a high degree o f assurance against forgery. A problem can arise if the compression functions are not well considered; an attacker may find a weak point which can be exploited to forge an illicit modification. In this paper, we cryptanalyze the scheme found in ref. 3, point out two potential drawbacks with the proposed scheme, and propose a modification to overcome these problems.
2. The Previous Scheme in this paper, we examine a previously published fast cryptographic checksum algorithm used for maintaining the integrity of files in an information system. We find two flaws in the previous analysis: it is possible to append information to a file and generate a new valid cryptographic checksum for the modified file, and it is possible to forge changes to blocks whose value is less than the modulus used in the scheme under examination. We then show how this method can be improved to eliminate these problems while still maintaining its other beneficial properties.
* Visiting scholar at the University of Cincinnati from Sichuan Communications Institute, China. t Assistant Professor at the University of Cincinnati.
1. Introduction he increased use o f electronic transmission and storage o f information has given rise to a new requirement for security and authentication. For the purpose o f integrity, a cryptographic checksum is usually associated with the transmitted or stored information. When information is modified unintentionally or maliciously, such changes have a high probability o f being detected after computation o f the cryptographic checksum. In principle, the cryptographic checksum can be implemented using the block chaining mode o f a strong block cipher system such as the RSA [1] or DES [2] to encipher the plaintext. The final enciphered block (or a part o f it) is used as the checksum. The main problems with these checksum schemes are that they
T
0167-4048/88/$3.50 © 1988, Elsevier Science Publishers Ltd.
The scheme proposed in ref. 3 is as follows:
Algorithm 1-- The Previous Algorithm Step 1: Select an RSA key K = (ke, M) and a userspecified seed S Step 2: Set Q = S Step 3: Set Q = RSA((Q X O R filename), K) Step 4: Set Q = 1 + [C(B)mod(Q - 1)] where: B is the next block o f the plaintext file P C(B) is the compressed version o f B Step 5: Set Q = RSA(Q, K) Step 6: If not done, go to 4 else, Q is the checksum As indicated in ref. 3, there is no reason to keep K secret. Since the deciphering key (kd, M) is left ungenerated and the RSA is quite
503
Y.J. Huang et al./ Special Note
strong against all known attacks which attempt to derive kd from ke and M, no one can attack the scheme by deciphering the RSA using current results. Unfortunately, the algorithm as it stands can be attacked in another way.
3. The First Attack on Algorithm 1 We can see from Algorithm 1 that each result o f an RSA is taken as the modulus of the next block of text. Because the seed is secret, each intermediate modulus is unknown to the forger, but the final modulus is left unguarded because it is used as the checksum. Hence a forger can append to the plaintext and generate a new valid checksum as follows:
Algorithm 2 ~ The Attack on Algorithm I Step 1: Assume the checksum of the orginal plaintext P is Q Step 2: Choose any block B and append it to P Step 3: Apply Step 4 of Algorithm 1 to B to produce a new modulus Q ' Step 4: Replace the stored copy of the checksum with Q ' Step 5: Repeat Steps 2-4 as many times as desired Since the only knowledge used to generate checksums for subsequent blocks is the final result from the previous blocks and nonsecret information, forgery is straightforward. Depending on implementation, this attack may only work when the final block of plaintext ends on an even block boundary. Although this reduces the probability of successful attack to the likelihood o f an even-blocksized file, this provides almost no
504
protection relative to the original intent of the proposed method.
4. The Second Attack on Algorithm 1 Even when the length o f the file is not an even multiple of the block size, there remains a second attack on Algorithm 1 which may be much more devastating. When the value of the final block o f P is less than the value of the corresponding modulus, the text can be forged and the attacker can readily tell when this attack will work. Detecting whether this attack will work is done as follows:
Algorithm 3mHow to Tell if the Second Attack Will Work Step 1: Set Z = RSA(C(B), K) Step 2: I f Z = Q, this attack will work Since Z = Q, the modulus formed in Step 4 of Algorithm 1 is irrelevant to the final result o f that block and thus that block and all subsequent blocks of the checksum are unrelated to the original seed S. We can attack Algorithm I under these conditions by replacing the last block with whatever we choose and replacing the stored checksum with the checksum generated from assuming RSA(C(B)) as the final value of Q. This also means that any block with a low enough value for Z produces a checksum for all subsequent blocks that is unrelated to S. We can simply check each block of the program for a value o f Z that is low enough to make it unlikely to be more than the modulus for that block. All further blocks are subject to attack as follows:
Algorithm 4rathe Second Attack on Algorithm I Step 1: Find a block with C(B) low enough Step 2: Replace all subsequent blocks of P Step 3: Perform Algorithm 1 for all subsequent blocks o f P assuming that Q for the block in Step 1 is C(B). Step 4: Replace the stored checksum with the final value forQ Finding a block in Step 1 turns out to be quite straightforward. The maximum modulus is known to be M - 1, the maximum value that can be yielded by the RSA. If we assume that the RSA is a good pseudo-random number generator [3], then a modulus has equal probability o f being any value between 1 and M. Thus the probability of C(B) for any particular block being below the modulus for that block is given by C(B) / (M 1) when C(B) < M, and 0 otherwise. When we compute C(B) for a given block, we can easily tell how likely it is to be less than the modulus. Thus we can choose any desired probability of success and only perform attacks when that likelihood is attained. We need not rely on probability in the actual attack since when we find a good candidate for attack, we can verify that it is going to work by performing Algorithm 1 starting at the block to be tested and ignoring the modulus for that block. If the checksum comes out the same as the stored checksum, then the modulus did not matter for the block being attacked and the wholesale replacement of blocks is possible. If this fails, we simply go on to the next likely candidate for attack.
Computers and Security, Vol. 7, No. 5
5. An Improvement of Algorithm 1 A simple improvement of Algorithm I would be to include the length o f P in the checksum computation. This might prevent the first attack since we could not easily append to the file and produce an identical checksum. It would not however, defend against the second attack. The main reason that the second attack works is that a block can have a value C(B) less than the corresponding modulus Q. If this happens the attacker can easily find all of the subsequent moduli. Furthermore, it is easy for the attacker to determine if and when this attack applies and to begin substituting blocks at that point. Both attacks can be prevented by introducing a variable that is unknown to the attacker into the computation o f C(B). Since the seed S is random and unknown to the attacker, it is a logical variable to use for this purpose. We propose the following change to Algorithm 1:
Algorithm 5--A RevisedChecksum Algorithm Step 1: Select an RSA key K = (ke, M) and a userspecified seed S Step 2: Set Q = S
Step 3: Set Q = RSA((Q X O R filename), K) Step 4: Set Q = 1 + [{C(B) X O R S}mod(Q - 1)] where: B is the next block o f the plaintext file P C(B) is the compressed version o r b Step 5: Set Q = RSA(Q, K) Step 6: If not done, go to 4 else, Q is the checksum In Step 4, we have changed C(B) to {C(B) X O R S}. The result is that the attacker cannot know {C(B) X O R S} without being able to invert the RSA, trying every possible S, or finding another weakness in the algorithm. Even though the attacker knows C(B), it is impossible to add a block as in the first attack to produce a valid checksum since this requires knowledge of S. Furthermore, S is no more at risk from exposure than it was under Algorithm 1 because it is still covered by an RsA encryption. The attacker meets the same problem when attempting to replace a block B with another block B'. Since S is unknown, it is impossible to tell whether { C(B) X O R S} < Q, and thus it is impossible to know whether the RSA will be a factor in the computation o f the next Q. There is no way to judge whether replacing this block
will work or not without trying it. Since S is not available for these trials, we can never determine whether or not the attack will work.
6. Summary We have identified a problem with a previously published fast cryptographic checksum algorithm and provided an improvement that appears to resolve the difficulty. It appears that the new algorithm satisfies all of the constraints of the previous algorithm while eliminating all known attacks.
Acknowledgment This work was funded by a research grant from the Radon Project, P.O. Box 90069, Pittsburgh, PA 15213, U.S.A.
References [11 R. Rivest, A. Shamir and L. Adleman, A method for obtaining digital signatures and public key cryptosystems, Commun. ACM, 21(2) (1988) 120-126. [2] Data Encryption Standard, FIPS PUB 46, National Bureau of Standards, Washington, DC (January 1977). [3] F. Cohen, A cryptographic checksum for integrity protection, Comput. Secur., 6(6) (1987) 505-510. [4] R. Jueneman, A high speed manipulation detection code, Proc. Crypto86, 1986, pp. 327-346.
505
Special Note
Some Weak Points of One Fast
Cryptographic Checksum Algorithm and its Improvement Yue Jiang Huang* and Fred Cohen?
require additional hardware, or in the absence o f additional hardware, a large amount o f time. As a result, some faster checksum schemes have been proposed [3, 4]. These schemes employ functions to c o m press the plain text together with cryptographic transforms to reduce dramatically computation time while providing a high degree o f assurance against forgery. A problem can arise if the compression functions are not well considered; an attacker may find a weak point which can be exploited to forge an illicit modification. In this paper, we cryptanalyze the scheme found in ref. 3, point out two potential drawbacks with the proposed scheme, and propose a modification to overcome these problems.
2. The Previous Scheme in this paper, we examine a previously published fast cryptographic checksum algorithm used for maintaining the integrity of files in an information system. We find two flaws in the previous analysis: it is possible to append information to a file and generate a new valid cryptographic checksum for the modified file, and it is possible to forge changes to blocks whose value is less than the modulus used in the scheme under examination. We then show how this method can be improved to eliminate these problems while still maintaining its other beneficial properties.
* Visiting scholar at the University of Cincinnati from Sichuan Communications Institute, China. t Assistant Professor at the University of Cincinnati.
1. Introduction he increased use o f electronic transmission and storage o f information has given rise to a new requirement for security and authentication. For the purpose o f integrity, a cryptographic checksum is usually associated with the transmitted or stored information. When information is modified unintentionally or maliciously, such changes have a high probability o f being detected after computation o f the cryptographic checksum. In principle, the cryptographic checksum can be implemented using the block chaining mode o f a strong block cipher system such as the RSA [1] or DES [2] to encipher the plaintext. The final enciphered block (or a part o f it) is used as the checksum. The main problems with these checksum schemes are that they
T
0167-4048/88/$3.50 © 1988, Elsevier Science Publishers Ltd.
The scheme proposed in ref. 3 is as follows:
Algorithm 1-- The Previous Algorithm Step 1: Select an RSA key K = (ke, M) and a userspecified seed S Step 2: Set Q = S Step 3: Set Q = RSA((Q X O R filename), K) Step 4: Set Q = 1 + [C(B)mod(Q - 1)] where: B is the next block o f the plaintext file P C(B) is the compressed version o f B Step 5: Set Q = RSA(Q, K) Step 6: If not done, go to 4 else, Q is the checksum As indicated in ref. 3, there is no reason to keep K secret. Since the deciphering key (kd, M) is left ungenerated and the RSA is quite
503
Y.J. Huang et al./ Special Note
strong against all known attacks which attempt to derive kd from ke and M, no one can attack the scheme by deciphering the RSA using current results. Unfortunately, the algorithm as it stands can be attacked in another way.
3. The First Attack on Algorithm 1 We can see from Algorithm 1 that each result o f an RSA is taken as the modulus of the next block of text. Because the seed is secret, each intermediate modulus is unknown to the forger, but the final modulus is left unguarded because it is used as the checksum. Hence a forger can append to the plaintext and generate a new valid checksum as follows:
Algorithm 2 ~ The Attack on Algorithm I Step 1: Assume the checksum of the orginal plaintext P is Q Step 2: Choose any block B and append it to P Step 3: Apply Step 4 of Algorithm 1 to B to produce a new modulus Q ' Step 4: Replace the stored copy of the checksum with Q ' Step 5: Repeat Steps 2-4 as many times as desired Since the only knowledge used to generate checksums for subsequent blocks is the final result from the previous blocks and nonsecret information, forgery is straightforward. Depending on implementation, this attack may only work when the final block of plaintext ends on an even block boundary. Although this reduces the probability of successful attack to the likelihood o f an even-blocksized file, this provides almost no
504
protection relative to the original intent of the proposed method.
4. The Second Attack on Algorithm 1 Even when the length o f the file is not an even multiple of the block size, there remains a second attack on Algorithm 1 which may be much more devastating. When the value of the final block o f P is less than the value of the corresponding modulus, the text can be forged and the attacker can readily tell when this attack will work. Detecting whether this attack will work is done as follows:
Algorithm 3mHow to Tell if the Second Attack Will Work Step 1: Set Z = RSA(C(B), K) Step 2: I f Z = Q, this attack will work Since Z = Q, the modulus formed in Step 4 of Algorithm 1 is irrelevant to the final result o f that block and thus that block and all subsequent blocks of the checksum are unrelated to the original seed S. We can attack Algorithm I under these conditions by replacing the last block with whatever we choose and replacing the stored checksum with the checksum generated from assuming RSA(C(B)) as the final value of Q. This also means that any block with a low enough value for Z produces a checksum for all subsequent blocks that is unrelated to S. We can simply check each block of the program for a value o f Z that is low enough to make it unlikely to be more than the modulus for that block. All further blocks are subject to attack as follows:
Algorithm 4rathe Second Attack on Algorithm I Step 1: Find a block with C(B) low enough Step 2: Replace all subsequent blocks of P Step 3: Perform Algorithm 1 for all subsequent blocks o f P assuming that Q for the block in Step 1 is C(B). Step 4: Replace the stored checksum with the final value forQ Finding a block in Step 1 turns out to be quite straightforward. The maximum modulus is known to be M - 1, the maximum value that can be yielded by the RSA. If we assume that the RSA is a good pseudo-random number generator [3], then a modulus has equal probability o f being any value between 1 and M. Thus the probability of C(B) for any particular block being below the modulus for that block is given by C(B) / (M 1) when C(B) < M, and 0 otherwise. When we compute C(B) for a given block, we can easily tell how likely it is to be less than the modulus. Thus we can choose any desired probability of success and only perform attacks when that likelihood is attained. We need not rely on probability in the actual attack since when we find a good candidate for attack, we can verify that it is going to work by performing Algorithm 1 starting at the block to be tested and ignoring the modulus for that block. If the checksum comes out the same as the stored checksum, then the modulus did not matter for the block being attacked and the wholesale replacement of blocks is possible. If this fails, we simply go on to the next likely candidate for attack.
Computers and Security, Vol. 7, No. 5
5. An Improvement of Algorithm 1 A simple improvement of Algorithm I would be to include the length o f P in the checksum computation. This might prevent the first attack since we could not easily append to the file and produce an identical checksum. It would not however, defend against the second attack. The main reason that the second attack works is that a block can have a value C(B) less than the corresponding modulus Q. If this happens the attacker can easily find all of the subsequent moduli. Furthermore, it is easy for the attacker to determine if and when this attack applies and to begin substituting blocks at that point. Both attacks can be prevented by introducing a variable that is unknown to the attacker into the computation o f C(B). Since the seed S is random and unknown to the attacker, it is a logical variable to use for this purpose. We propose the following change to Algorithm 1:
Algorithm 5--A RevisedChecksum Algorithm Step 1: Select an RSA key K = (ke, M) and a userspecified seed S Step 2: Set Q = S
Step 3: Set Q = RSA((Q X O R filename), K) Step 4: Set Q = 1 + [{C(B) X O R S}mod(Q - 1)] where: B is the next block o f the plaintext file P C(B) is the compressed version o r b Step 5: Set Q = RSA(Q, K) Step 6: If not done, go to 4 else, Q is the checksum In Step 4, we have changed C(B) to {C(B) X O R S}. The result is that the attacker cannot know {C(B) X O R S} without being able to invert the RSA, trying every possible S, or finding another weakness in the algorithm. Even though the attacker knows C(B), it is impossible to add a block as in the first attack to produce a valid checksum since this requires knowledge of S. Furthermore, S is no more at risk from exposure than it was under Algorithm 1 because it is still covered by an RsA encryption. The attacker meets the same problem when attempting to replace a block B with another block B'. Since S is unknown, it is impossible to tell whether { C(B) X O R S} < Q, and thus it is impossible to know whether the RSA will be a factor in the computation o f the next Q. There is no way to judge whether replacing this block
will work or not without trying it. Since S is not available for these trials, we can never determine whether or not the attack will work.
6. Summary We have identified a problem with a previously published fast cryptographic checksum algorithm and provided an improvement that appears to resolve the difficulty. It appears that the new algorithm satisfies all of the constraints of the previous algorithm while eliminating all known attacks.
Acknowledgment This work was funded by a research grant from the Radon Project, P.O. Box 90069, Pittsburgh, PA 15213, U.S.A.
References [11 R. Rivest, A. Shamir and L. Adleman, A method for obtaining digital signatures and public key cryptosystems, Commun. ACM, 21(2) (1988) 120-126. [2] Data Encryption Standard, FIPS PUB 46, National Bureau of Standards, Washington, DC (January 1977). [3] F. Cohen, A cryptographic checksum for integrity protection, Comput. Secur., 6(6) (1987) 505-510. [4] R. Jueneman, A high speed manipulation detection code, Proc. Crypto86, 1986, pp. 327-346.
505