Lineární kryptoanalýza Baby Rijndael a implementační postranní kanály AES

Abstract

In this dissertation thesis we study selected security aspects of AES, the Advanced Encryption Standard. Specically, we approach the issue from three sides: First, we are trying to verify whether AES is indeed resistant to linear cryptanalysis. It was designed as such, in accordance with the requirements as well as the modern cipher design, but the size and complexity of the cipher make it dicult to show denitively that the cipher is resistant in all possible situations. We solve this problem by performing the tests against Baby Rijndael, a reduced model of the cipher built along the same design principles. We show that the success of linear cryptanalysis depends on more variables than usually assumed and that some keys or some plaintexts are more susceptible to an attack than others, but overall the eort required far outweighs that of brute-force trying of all keys. That demonstrates that Baby Rijndael and in extension AES are indeed resistant to this form of cryptanalysis. Then we consider side channels created by a particular implementation. While they are much less universal, only applying to those specic implementations rather than all of them, they are generally much more ecient in breaking the encryption and recovering either the key or the plaintext. Our rst side channel involves the execution environment where AES encryption is being performed. We propose an algorithm, suitable for the Intel Architecture, that can automatically detect that encryption is taking place by monitoring access to AES S-boxes, and due to the interactions between AES state, key and S-boxes, are able to recover both the key and the plaintext, in most implementations that use these S-boxes. We also discuss the options of achieving the same results with implementations not dependent on S-boxes, i.e. with AES-NI based implementations and with vector unit based bit-slicing implementations. While bit-slicing seems to be impossible to detect universally, AES-NI can denitely be monitored to recover both the data and the key. Our second side channel deals with implementation errors on the side of developer. We use reverse engineering to analyze an existing application Drive Snapshot that makes use of AES, recovering its key generation process. We demonstrate that while the process makes use of strong cryptographic algorithms and adheres, for the most part, to current best practices, the programming errors present in the code cause it to fail in a number of ways, not the least being the fact that 148 out of 256 bits of the AES key are revealed to the attacker, making a brute-force attack on the key much easier (still impossible, though). We also demonstrate other errors that simplify the attack on both the key and the password. Finally, we discuss the possible causes for these errors and ways the development process could be changed to prevent them in the future.

In this dissertation thesis we study selected security aspects of AES, the Advanced Encryption Standard. Specically, we approach the issue from three sides: First, we are trying to verify whether AES is indeed resistant to linear cryptanalysis. It was designed as such, in accordance with the requirements as well as the modern cipher design, but the size and complexity of the cipher make it dicult to show denitively that the cipher is resistant in all possible situations. We solve this problem by performing the tests against Baby Rijndael, a reduced model of the cipher built along the same design principles. We show that the success of linear cryptanalysis depends on more variables than usually assumed and that some keys or some plaintexts are more susceptible to an attack than others, but overall the eort required far outweighs that of brute-force trying of all keys. That demonstrates that Baby Rijndael and in extension AES are indeed resistant to this form of cryptanalysis. Then we consider side channels created by a particular implementation. While they are much less universal, only applying to those specic implementations rather than all of them, they are generally much more ecient in breaking the encryption and recovering either the key or the plaintext. Our rst side channel involves the execution environment where AES encryption is being performed. We propose an algorithm, suitable for the Intel Architecture, that can automatically detect that encryption is taking place by monitoring access to AES S-boxes, and due to the interactions between AES state, key and S-boxes, are able to recover both the key and the plaintext, in most implementations that use these S-boxes. We also discuss the options of achieving the same results with implementations not dependent on S-boxes, i.e. with AES-NI based implementations and with vector unit based bit-slicing implementations. While bit-slicing seems to be impossible to detect universally, AES-NI can denitely be monitored to recover both the data and the key. Our second side channel deals with implementation errors on the side of developer. We use reverse engineering to analyze an existing application Drive Snapshot that makes use of AES, recovering its key generation process. We demonstrate that while the process makes use of strong cryptographic algorithms and adheres, for the most part, to current best practices, the programming errors present in the code cause it to fail in a number of ways, not the least being the fact that 148 out of 256 bits of the AES key are revealed to the attacker, making a brute-force attack on the key much easier (still impossible, though). We also demonstrate other errors that simplify the attack on both the key and the password. Finally, we discuss the possible causes for these errors and ways the development process could be changed to prevent them in the future.