A Cautionary Note on Weak Implementations of Block Ciphers

Transcription

1 A Cautionary Note on Weak Implementations of Block Ciphers Tim Kerins and Klaus Kursawe Information and System Security Group, Philips Research Europe Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands. {Tim.Kerins, Abstract. An easy way to mount an attack on software binaries without error checking for the AES, DES and other block ciphers is presented. It is detailed how full key recovery is possible and how common cipher modes of operation are then circumvented. The application of this method to recover key material and data from security systems is then discussed along with a number of possible countermeasures. Key words: AES, DES, Sbox, implementation 1 Introduction There is potentially a wide gap between the theoretical design and analysis of cryptographic primitives and the quality of real-world instantiations and implementations of these. Ciphers and protocols are developed within particular models to resist the current known mathematical attacks within the bounds of the model. The problems begin when a protocol or security system is implemented in software or hardware as the real-world implementation may not satisfy the development model. One of the most common model failures is that of the black-box assumption i.e. that potential attackers do not have access to the cryptographic software or hardware itself. It can be argued that the black-box assumption rarely holds in naive software implementations of cryptographic primitives. In a similar vein to other recent works, for example [1], the aim of this paper is to illustrate the potential difference between cryptography as theoretically developed and security systems as implemented in practice. It is well known that sufficient care is required in the implementation phase or an entire scheme may be broken. See for example the work of Anderson and Kuhn [2, 3]. However it is dangerous for system designers to assume that cracking implementations of ciphers is only within the capabilities of experts with specialized knowledge and equipment. This paper illustrates the dangers of weak implementations of block ciphers by demonstration of a key recovery method that can be mounted in a matter of minutes. Using only a hex editor program, and a single execution of a modified AES binary the authors were able to extract 128 key bits from a compiled software implementation. This method can be applied to a wide variety of block ciphers with static Sboxes. This easy to

2 2 Tim Kerins and Klaus Kursawe perform cipher modification also results in the complete break of some common block cipher modes. The layout of this paper is as follows: Section 2 describes how naive implementations of block ciphers appear in software and a common weakness that can be exploited and some related work. Section 3 details how this weakness can be exploited to recover either data or key material. Then, Section 4 continues to develop how this weakness can be used to break a number of commonly used block cipher modes.section 5 presents some known methods for hardening implementations against this vulnerability. 2 Software Implementations of Block Ciphers Many commonly used block ciphers (such as DES and AES) contain lookup tables (substitution- or Sboxes). These are generally inferred as static arrays in software implementations for efficiency reasons. If an attacker can gain access to the compiled code, i.e. the software binary, it is a trivial matter to load the binary into a hex editor and view the compiled source. If a lookup table has been statically defined it will be easily identifiable. For example, the initial bytes of the AES Sbox are 63 7C 77 7B [5], and these can be located in the compiled source of an AES implementation by simple search (Figure 1). Other information such as program control flow and possibly key material are much more difficult to extract from the compiled code as this will involve a software reverse engineering effort and tracking the execution of code. The level of expertise is required for such an approach, may be beyond the ability of many would be hobbyist crackers. Further details on this approach are sketched by Hoglund and McGraw in [6]. The method of Sbox modification described here is simpler and only requires access to a static binary. The idea is that static cryptographic keys embedded in a binary may be (relatively) difficult to identify and extract or may come from a different source, while the Sbox will be easy to identify. Once the Sbox is found in memory, it is usually relatively easy to apply modifications. This has dramatic consequences; if the Sbox of an AES cipher is replaced by zero values, the key can be directly derived from the ciphers output. The work of Shamir and van Someren [7] uses a related method to that described here to search for cryptographic keys embedded in the binary by testing sections for randomness properties. The assumption being that a good key will have more entropy than the surrounding code and thus be identifiable in this manner. While this attack like ours does not require the attacker to have intimate knowledge about the underlying platform, it also requires an amount of effort and understanding of the attacker. By contrast, identifying the Sbox is trivial with an editor s search functionality. Fault insertion techniques are well known in the cryptographic community specific analysis appears to have been largely focused on differential fault analysis. See [8 11] for examples of representative attacks of this type. In this case, even introducing a single random fault in an implementation of the AES [11] can lead to a successful attack. The importance of checking cryptographic protocols

3 A Cautionary Note on Weak Implementations of Block Ciphers 3 Fig. 1. Identifying the AES Sbox in a software binary for faults is well understood [8]. Another attack on block ciphers containing large static lookup is to use the side channels of cache hits and cache misses, as it has previously been discussed (particularly for the AES) [12, 13]. These are dynamic attack methods that require access to a processor running an AES implementation and also some understanding of cache hit and miss issues on a particular processor. This paper and the works of Bernstein and Osvik et al. [12, 13] illustrate a trend that cryptographic primitives in software with large static Sboxes appear to leave the implementation vulnerable to attacks capable of recovering key bits if extra precautions are not taken in the implementation. The main difference between the above implementations and our approach is that we require no skills or special tools on the side of the attacker; a simple search and replace is sufficient. Once Sboxes have been found they can be changed to arbitrary values chosen by an attacker, resulting in potentially dangerous security breaks. Thus, the aim is to demonstrate how easy it is to attack a security system with weak implementations of cryptographic primitives by a low resource attacker (without any specialist tools or knowledge of cryptography, differential fault analysis, software reverse engineering etc). The method of scanning software binaries for known patterns is previously known to the security community and software crackers. However, the risk lies on the potential assumption of security engineers, that breaking cryptographic functionality is only possible using specialist tools and a particular level of expertise. This paper is intended to help to dispel this misconception. This paper concentrates on

4 4 Tim Kerins and Klaus Kursawe the AES and DES as a specific examples. Both are currently widely and standard implementations contain identifiable Sboxes. 3 Sbox Manipulations This section details some manipulations that can be applied to the AES and other similar block ciphers in order to recover key bits, and how Feistel ciphers such as DES can be easily removed from a security system. 3.1 SPN Ciphers and Sbox Blanking An SPN block cipher is an iterated block cipher where each round is composed of substitutions and permutations (and a round key addition) of an intermediate cipher state. This attack method works generally on SPN ciphers with a key whitening (a final round key addition) at the end of the cipher operation) and static Sboxes. The final S (substitution Sbox) and P (permutation) operations in this type of cipher are illustrated in Figure 2. Note that an addition of n expanded key bits k w (key whitening) is the last operation to be performed on n bits of intermediate state before cipher output. This key whitening operation is often performed by a logical XOR operation, but other methods of key addition such as modulo arithmetic can also be used. Generally SPN ciphers work in this manner for both encryption and decryption. In the case of encryption the key whitening bits are the last n bits from the expanded key and for decryption they are the first n bits. x S S(x) P P(S(x)) n n k w P(S(x))+k w y Fig. 2. The key whitening operation in a generic SPN n bit block cipher This operation is represented as y P (S(x)) + k w (1)

5 A Cautionary Note on Weak Implementations of Block Ciphers 5 If the output of S is set to a constant value say S(x) = c for all x then the key whitening bits k w become y P (c) + k w (2) As P (c) is constant the key whitening bits k w can be recovered from the cipher output y. A particular case on this is when all entries in the Sbox are set to zero, i.e. c = 0, then the key whitening bits are outputted directly from the cipher as y (P (0) = 0) + k w (3) It may then be possible to recover n bits of the original cipher key k from the n recovered key whitening bits k w if the key expansion schedule can be suitably reversed. The AES is a n = 128 bit iterated block cipher which can use cipher keys of 128, 192 and 256 bits, and has 10, 12 or 14 rounds (AES-128, AES-192 and AES-256) [5]. Its final round structure matches that in Figure 2 and 128 bits of expanded key material k w can be recovered from the output of the cipher by blanking the final Sbox. The result of this is that the final key whitening operation (XOR) results in the direct output of 128 bits of expanded key material. 3.2 The Weakened AES Key Schedule A full description of the AES including the original key schedule be found in [4, 5]. Once 4 32-bits of expanded key material have been extracted from the forward cipher it is then possible to reverse the AES key expansion to recover bits of the original cipher key k. With Sbox blanking however, this operation can be made even simpler, as the Sbox is also used in the round key expansion. The modified key schedule for AES-128 with the assumption that the AES Sbox has been blanked to zero is illustrated as Algorithm 1. Algorithm 1 AES-128 Weakened Key Expansion with Sbox Blanking Require: 128 bit cipher key {k 0, k 1, k 2, k 3}, Ensure: 1408 bit expanded key {w 0, w 1,..., w 43} 1: w 0 k 0, w 1 k 1, w 2 k 2, w 3 k 3 2: for i from 3 to 43 do 3: if i(mod 4) = 0 then 4: w i w i 4 + r i/4 5: else 6: w i w i 1 + w i 4 7: end if 8: end for 9: {w 0, w 1,... w 43} Here k = {k 0, k 1, k 2, k 3 } are the 4 original 32-bit words of key material (the cipher key) and {w 0, w 1,..., w 43 } are the bit words of expanded key

6 6 Tim Kerins and Klaus Kursawe material. The constants r i, i = are the round constants as 32 bit words as indicated in the cipher specification and + is a 32 bit XOR operation. The 4 32-bit words of expanded key material outputted from the forward cipher as a result of Sbox blanking are k w = {w 40, w 41, w 42, w 43 }. Using the weakened key expansion in Algorithm 1 the 4 32-bit words of key material k = {k 0, k 1, k 2, k 3 } can be recovered from k w by k 0 = w 40 + R (128) 0 k 1 = w 41 + R (128) 1 k 2 = w 42 + w 40 + R (128) 2 k 3 = w 43 + w 41 + R (128) 3 (4) Here the constants R (128) i, i = i... 3 are simple XOR sums of the cipher round constants R (128) 0 = 10 i=1 r i R (128) 1 = r 2 + r 4 + r 6 + r 8 + r 10 R (128) (5) 2 = r 3 + r 4 + r 7 + r 8 R (128) 3 = r 4 + r 8 For the reverse cipher (decryption) it is even easier to recover the cipher key k after Sbox blanking. Here k w = {w 0, w 1, w 2, w 3 } as the round keys are applied in the reverse order, and the words of k = {k 0, k 1, k 2, k 3 } are directly outputted. A similar analysis can be applied to the forward and reverse operations of the AES-192 and AES-256 ciphers to recover 128 bits of key material. The remaining key bits could be recovered by other means. Interestingly, increasing the block size of the cipher, as per the original Rijndael specification serves to further weaken the cipher with Sbox blanking as more key bits k w are recovered from cipher output. This gives more bits of expanded key material for analysis. Some high performance AES implementations use four large known lookup tables instead of the implementation described here however the method can also be adapted to this case. 3.3 Other SPN Based Ciphers Although this analysis has been applied in detail to the AES, in general this method is applicable to SPN block ciphers with: unprotected implementations static Sboxes in cipher rounds key whitening operation after the final round a suitable round key expansion possibly also containing static Sboxes Other SPN block ciphers that contain static Sboxes and key whitening and whose unprotected software binaries may be vulnerable to this type of analysis and manipulations. An example of another cipher that may be susceptible to this attack is another AES candidate Serpent [15].

7 A Cautionary Note on Weak Implementations of Block Ciphers DES and Feistel based Ciphers Feistel network based block ciphers operate in a different manner, in that round key addition is often performed before Sbox substitution operation for example in DES [16] and the substitution and permutation operations are performed differently. At the beginning of each round in this type of Feistel based cipher the n bit intermediate cipher state x is divided into two sections (x l, x r ) and the state is updated to y = (y l, y r ) as y l x r y r x l + P (S(x r + k )) (6) where P and S represent the permutation and substitution operations as before and k represents bits of the expanded cipher key k. Equation (6) is also illustrated as Figure 3. x l P(S(x r +k )) S(x r +k ) x r +k k' x r P S y l y r Fig. 3. Round operation of a Feistel cipher with round key addition before substitution If S is implemented by a publicly known static Sbox in a weak implementation, as before it can be trivially identified and modified and set to a constant value S(x) = c. As the round key addition happens before the substitution in this case all information on k is lost and (6) becomes y l x r y r x l + P (c) (7) Again the case where c = 0 is of particular interest and in this case the constant P (0) = 0 if P is a strict permutation function and all cryptographic functionality is removed from the round and the left and right sections of the intermediate cipher state are merely transposed. After an even number of rounds the cipher output is simply the cipher input (y l, y r ) (x l, x r ). The result of an odd number of rounds is simply a swapping of the left and right sections (y l, y r ) (x r, x l ). This is the result of Sbox blanking on weak implementations of the DES cipher. Clearly, this method will not help in the recovery of key material or the decryption of previously decrypted content. However, it will remove the capability

8 8 Tim Kerins and Klaus Kursawe to encrypt content and without correct checks would result in plaintexts x sent over a channel in the clear. In general Feistel based block ciphers with unprotected implementations static Sboxes round key addition before substitution operation are vulnerable to this type of modification to trivially remove cryptographic functionality. Examples of more complicated Feistel based ciphers which may be identifiable by their static Sboxes, and also weakened by Sbox blanking are the phase 2 Nessie cipher MISTY1 [17] and the final round AES candidate MARS [18]. 4 Effect on Cipher Modes In practical systems block ciphers are generally used in one of a number of block cipher modes. A weakened block cipher as a result of the attack method previously described in Section 3 used in the common cipher modes also allows a trivial key recovery. The block ciphers are expected to operate on an n bit plaintext block x to produce ciphertext block y during encryption and the opposite operation during decryption. These operations are commonly denoted as y E k (x) and x E 1 k (y) respectively, where by design there is a strong interdependence between x, y and k. A plain text message m is broken into t n-bit blocks, labelled x j, 1 j t. Two commonly used block cipher modes are: ECB electronic codebook mode encryption : y j E k (x j ), 1 j t decryption : x j E 1 k (y j), 1 j t CBC cipher block chaining mode encryption : y 0 IV y j E k (y j 1 + x j ), 1 j t decryption : y 0 IV x j y j 1 + E 1 k (y j), 1 j t Here IV is an n-bit initialization vector. Dependant on the implementation this may also be considered secret although the mode of operation is defined so that the security of the system does not depend on the secrecy of the IV. Here the + operation represents an n-bitwise XOR operation. A more in depth description of these modes can be found in [14]. The effect of Sbox blanking when S(x) = 0 on these cipher modes is now discussed for weak implementations of SPN ciphers with a final key whitening operation and Feistel based block ciphers with an even number of rounds and round key addition before the substitution operations.

9 A Cautionary Note on Weak Implementations of Block Ciphers SPN Ciphers If a weakened SPN based block cipher is used where a blanking attack is performed as described in Section 3.3, then all input information is lost and the cipher outputs constant values k w for constant k regardless on the input values x and c for encryption and decryption respectively. Denote these blanked ciphers as k w E k (x) and k w E 1 (y) respectively. Now consider the effect this has on the block cipher modes of operation. In ECB mode, as expected both encryption and decryption modes of operation output the n bits of expanded key material used in the key whitening operation regardless of input. Once the key has been recovered from the leaked key bits k w then arbitrary messages can then be encrypted and decrypted as desired. CBC mode for encryption also returns, as expected the constant k w E k (y j 1 + x j ), 1 j t, regardless of input plaintext x j, provided that the cipher key k is unchanged. CBC mode for decryption also returns the IV as well as k w, as y 0 = IV and k w E 1 k (y j) for constant k IV + k w y j 1 + E 1 k (y j), j(mod 2) = 1 IV y j 1 + E 1 k (y j), j(mod 2) = 0 (8) Equation (8) indicates that using an Sbox blanked CBC cipher for decryption allows recovery of both the IV and n bits of key related material. Of course, the security of CBC mode does not depend on the secrecy of the IV, however in some applications it is not made public. 4.2 Feistel Ciphers Consider a simple Feistel based ciphers with round key addition before the substitution, as described in Section 3.4. Sbox blanking results in a complete removal of cryptographic functionality after an even number of rounds, so for encryption x j E k (x j). ECB mode them simply results in the transmission of the entire plaintext message across the channel. For an odd number of rounds the left and right sides of the plaintext are simply flipped. Assume a weakened cipher with an even number of rounds. In CBC mode this results in y j y j 1 + x j, 1 j t Recalling that y 0 IV this implies that each block y j of the ciphertext is formed (recalling that addition is modulo 2) by y j IV + j x i (9) Now the t n-bit blocks of the original message can them be recovered by i=1 x 1 y 1 + IV x j y j + y j 1, 2 j t (10)

10 10 Tim Kerins and Klaus Kursawe So, even if the IV is not known then the entire transmitted plaintext in this mode, except for the first n bit block, can be recovered by examining the transmitted output and applying equation (10). 5 Preventing these Attacks Due to the ease by which Sbox can be identified and hence modified in software binaries, is important that adequate defences be taken against their identification and that manipulation does not directly output key related bits. A number of precautions can be taken to prevent tampering of cryptographic primitives in software. The most obvious method is to take care that an attacker does not have access to any software binaries that contain implementations of cryptographic primitives. This is difficult to achieve in practice on open systems, but it is possible to take certain precautions. On a generic computing platform (for example, running the Linux Operating System), it can be ensured that the part of the file system containing cryptographic binaries is only accessible at the highest privilege level and not by regular users. This represents OS enforced access control protection of the binaries. Methods of code obfuscation can prevent a search as employed in this paper from locating the Sboxes. Another method which ensures that keys are difficult to extract from code is white box cryptography. See for example the work of Chow et al. in [19]. A by product of this is of course non-standard implementations of the block cipher in question. Another method to obtain non-standard implementations of ciphers is as simple as generating the Sbox dynamically on execution of the code, or using Sbox masking techniques. Alternatively the cipher could be modified somewhat so that different Sboxes are used but the input output behaviour of the cipher is the same [5]. The main method behind these techniques is to move away from the small number of widely used implementations with known static Sboxes, and either obfuscate, mask, implement non-standard versions Sboxes or generate them on the fly. Other more standard methods of protecting software primitives involve performing a checksum over the executable code before it is executed to ensure it is unmodified. Checking that the encryption, decryption behaviour of ciphers are matching and also checking cryptographic primitives for faults by performing trial tests against some known result should be standard practice. It is important that these checks are in place and are performed. These should prevent trivial leaks of key material from weak implementations of ciphers where an attacker potentially has access to the binaries. Another approach to protecting the output of block ciphers from trivial modifications as described in this paper is to use slightly non-standard versions of the ciphers rather than non-standard implementations as previously discussed. Doubling the key length and XORing n bits at the output of SPN ciphers would prevent the trivial output of easily extracted key material. This is precisely the method used in DESX for increasing the effective key length of DES [20]. A similar method could be used as a double key whitening to prevent the leakage of

11 A Cautionary Note on Weak Implementations of Block Ciphers 11 round key material in the case of Sbox blanking. If Sbox blanking is performed the attacker receives k w + k 2 at the output of the cipher and is left with the difficult problem of extracting useful key information from these. The cipher modes proposed in [21] will also help to defend against these attacks. The main point here is that if Sbox blanking is a threat then then a single key whitening operation should not be the final operation of a cipher. 6 Conclusions This paper has illustrated that potential attacks on security system are not only possible by professionals using specialist tools. Weak implementations of a strong algorithm can lead to the algorithm being vulnerable to even simple attacks. If precautions (as outlined in Section 5) are not taken the use of the standard implementations some common block ciphers can have dire consequences, ranging from a denial of service to full compromise of keys and data by attackers with minimal skill and understanding. The possibilities to locate and change Sboxes are a serious threat, and one easily carried out if software implementers do not take the necessary precautions. In a more general sense this is yet another illustration of the fact that cryptographic primitive should only be implemented within the models in which they were designed. With the wide number of software applications, containing block ciphers essentially in the clear, currently operating in potentially untrusted environments it appears that it is time for a rethink of some of the more traditional methods of implementing these ciphers. Acknowledgement The authors would like to thank Jorge Guajardo Merchan as well as a number of reviewers for comments in preparing this manuscript. References 1. K. G. Patterson and A. K. L. Yau. Crpytography in Theory and Practice: The Case of Encryption in IPSec, Cryptology eprint Archive, Report 2005/416 (2005) 2. R. J. Anderson and M. G. Kuhn. Tamper Resistance A Cautionary Note, The Second USENIX Workshop on Electronic Commerce Proceedings, pp. 1-11, (1996) 3. R. J. Anderson and M. G. Kuhn. Low Cost Attacks on Tamper Resistant Devices, M. Lomas et al. ed. Security Protocols, 5th International Workshop, LNCS 1351, Springer-Verlag, pp. pp , (1997) 4. FIPS PUB 197. Advanced Encryption Standard (AES) (2001) 5. J. Daemem and V. Rijmen. The Design of Rijndael: AES - The Advanced Encryption Standard (Information Security and Crpytography), Springer (2002)

12 12 Tim Kerins and Klaus Kursawe 6. G. Hoglund and G. McGraw. Exploiting Software: How to Break Code, Addison- Wesley, (2004) 7. A. Shamir and N. van Someren. Playing Hide and Seek with Stored Keys, M. K. Franklin ed. Financial Cryptography FC 99 LNCS 1648, Springer, pp , (1999) 8. D. Boneh, R. DeMillo and R. J. Lipton. On the Importance of Checking Cryptographic Protocols for Faults, W. Fumy ed. Advances in Cryptology - Eurocrypt 97, LNCS 1233, Springer, pp , (1997) 9. E. Biham and A. Shamir. Differential Fault Analysis of Secret Key Cryptosystems, B. S. Kaliski Jr. ed. Advances in Cryptology - CRYPTO 97, LNCS 1294, Springer, pp , (1997) 10. J. Blömer and J.-P. Seifert, Fault Based Cryptanalysis of the Advanced Encryption Standard, Financial Cryptology FC 04, LNCS 2742, Springer, pp , (2004) 11. C. Giraud. DFA on AES, H. Dobbertin, V. Rijmen, A. Sowa eds. Advanced Encryption Standard - AES: 4th International Conference, AES 2004, LNCS 3373, Springer pp , (2005) 12. D. Bernstein. Cache-timing attacks on AES, preprint, (2005) 13. D. A. Osvik, A. Shamir and E. Tromer. Cache Attacks and Countermeasures: The Case of AES, D. Pointcheval ed. Topics in Cryptology - CT-RSA 2006, LNCS 3860, Springer, pp. 1-20, (2006) 14. A. J. Menezes, P. C. van Oorschot and S. A. Vanstone. Handbook of Applied Crpytography, CRC Press, (1996) 15. E. Biham, R. J. Anderson and L. Knudsen. Serpent: A New Block Cipher Proposal, Fast Software Encryption FSE 98, LNCS 1372, Springer pp , (1998) 16. FIPS PUB Data Encryption Standard (DES), (1998) 17. M. Matsui. Block encryption algorithm MISTY, Fast Software Encryption FSE 97, LNCS 1267, Springer pp , (1997) 18. C. Burwick, D. Coppersmith, E. D Avignon, R. Gennaro, S. Halevi, C. Jutla, S. M. Matyas Jr, L. O Connor, M. Peyravian, D. Stafford and N. Zunic, MARS a candidate cipher for AES, NIST AES Proposal (1998) 19. S. Chow, P. Eisen, H. Johnson and P. C. van Oordchot. White-Box Cryptography and an AES Implementation, Selected Areas in Cryptography - SAC 2002, LNCS 2595, Springer, pp , (2002) 20. J. Killian and P. Rogaway. How to protect DES against exhaustive key search, Advances in Cryptology - CRYPTO 96, LNCS 1109, Springer-Verlag pp , (1996) 21. C. S. Jutla. Encryption Modes with Almost Free Message Integrity, Advances in Cryptology - EUROCRYPT 2001, LNCS 2045, Springer-Verlag, pp , (2001)