Eric Conrad, ... Joshua Feldman, in
Eleventh Hour CISSP® (Third Edition), 2017 Symmetric encryption uses a single key to encrypt and decrypt. If you encrypt a zip file, then decrypt with the same key, you
are using symmetric encryption. Symmetric encryption is also called “secret key” encryption because the key must be kept secret from third parties. Strengths of this method include speed and cryptographic strength per bit of key; however, the major weakness is that the key must be securely shared before two parties may communicate securely. Symmetric encryption may have stream and
block modes. Stream mode means each bit is independently encrypted in a “stream.” Block mode ciphers encrypt blocks of data each round; for example, 64 bits for the Data Encryption Standard (DES), and 128 bits for AES. Some block ciphers can emulate stream ciphers by setting the block size to 1 bit; they are still considered block ciphers. Some symmetric ciphers
use an initialization vector to ensure that the first encrypted block of data is random. This ensures that identical plaintexts encrypt to different ciphertexts. Also, as Bruce Schneier notes in Applied Cryptography, “Even worse, two messages that begin the same will encrypt the same way up to the first difference. Some messages have a common header: a letterhead, or a ‘From’ line, or whatever.”2 Initialization vectors solve this problem. Chaining (called feedback in stream modes) seeds the previous encrypted block into the next block ready for encryption. This destroys patterns in the resulting ciphertext. DES Electronic Code Book mode (see below) does not use an initialization vector or chaining, and patterns can be clearly visible in the resulting ciphertext. DES is the data encryption standard,
which describes the data encryption algorithm (DEA). IBM designed DES, based on their older Lucifer symmetric cipher, which uses a 64-bit block size (ie, it encrypts 64 bits each round) and a 56-bit key. Even though DES is commonly referred to as an algorithm, it is technically the name of the published standard that describes DEA. It may sound like splitting hairs, but that is an important distinction to keep in mind on
the exam. DEA may be the best answer for a question regarding the algorithm itself. DES can use five different modes to encrypt data. The modes’ primary difference is block versus emulated stream, the use of initialization vectors, and whether errors in encryption will propagate to subsequent blocks. The five modes of DES are: Electronic Code Book (ECB) Cipher Block Chaining (CBC) Cipher Feedback (CFB) Output Feedback (OFB) Counter (CTR) Mode ECB is the original mode of DES. CBC, CFB, and OFB were added
later. CTR mode is the newest mode, described in NIST Special Publication 800-38a (see http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf). ECB is the simplest and weakest form of DES. It uses no initialization vector or chaining. Identical plaintexts with identical keys encrypt to identical ciphertexts. Two plaintexts with partial identical
portions, such as the header of a letter, encrypted with the same key will have partial identical ciphertext portions. CBC mode is a block mode of DES that XORs the previous encrypted block of ciphertext to the next block of plaintext to be encrypted. The first encrypted block is an initialization vector that contains random data. This “chaining” destroys patterns. One
limitation of the CBC mode is that encryption errors will propagate; an encryption error in one block will cascade through subsequent blocks due to the chaining, therefore destroying their integrity. CFB mode is very similar to CBC, but the primary difference is that CFB is a stream mode. It uses feedback, which is the name for chaining when used in stream modes, to destroy patterns.
Like CBC, CFB uses an initialization vector and destroys patterns, and so errors propagate. OFB mode differs from CFB in the way feedback is accomplished. CFB uses the previous ciphertext for feedback. The previous ciphertext is the subkey XORed to the plaintext. OFB uses the subkey before it is XORed to the plaintext. Since the subkey is not affected by encryption errors,
errors will not propagate. CTR mode is like OFB; the difference again is the feedback. CTR mode uses a counter, so this mode shares the same advantages as OFB in that patterns are destroyed and errors do not propagate. However, there is an additional advantage: since the feedback can be as simple as an ascending number, CTR mode encryption can be executed in parallel. Table 3.3 summarizes the five modes of DES. Table 3.3. Modes of DES Summary
Single DESSingle DES is the original implementation of DES, encrypting 64-bit blocks of data with a 56-bit key, using 16 rounds of encryption. The work factor required to break DES was reasonable in 1976, but advances in CPU speed and parallel architecture have made DES weak to a brute-force key attack today, where every possible key is generated and attempted. Triple DESTriple DES applies single DES encryption three times per block. Formally called the “triple data encryption algorithm (TDEA) and commonly called TDES,” it became a recommended standard in 1999. International data encryption algorithmThe international data encryption algorithm (IDEA) is a symmetric block cipher designed as an international replacement to DES. It uses a 128-bit key and 64-bit block size. The IDEA has patents in many countries. Advanced encryption standardThe advanced encryption standard (AES) is the current US standard in symmetric block ciphers. AES uses 128-bit (with 10 rounds of encryption), 192-bit (with 12 rounds of encryption), or 256-bit (with 14 rounds of encryption) keys to encrypt 128-bit blocks of data. Choosing AESThe US National Institute of Standards and Technology (NIST) solicited input on a replacement for DES in the Federal Register in January 1997. Fifteen AES candidates were announced in August 1998, and the list was reduced to five in August 1999. Table 3.4 lists the five AES finalists. Table 3.4. Five AES Finalists
Rijndael was chosen and became AES. AES has four functions: SubBytes, ShiftRows, MixColumns, and AddRoundKey. Blowfish and TwofishBlowfish and Twofish are symmetric block ciphers created by teams lead by Bruce Schneier, author of Applied Cryptography. Blowfish uses from 32- through 448-bit keys (the default is 128-bit) to encrypt 64 bits of data. Twofish was an AES finalist, encrypting 128-bit blocks using 128-bit through 256-bit keys. Both are open algorithms, meaning they are unpatented and freely available. RC5 and RC6RC5 and RC6 are symmetric block ciphers by RSA Laboratories. RC5 uses 32-bit (testing purposes), 64-bit (replacement for DES), or 128-bit blocks. The key size ranges from zero to 2040 bits. RC6 was an AES finalist. RC6 is based on RC5 and is altered to meet the AES requirements. It is also stronger than RC5, encrypting 128-bit blocks using 128-, 192-, or 256-bit keys. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780128112489000036 Domain 5Eric Conrad, ... Joshua Feldman, in CISSP Study Guide (Second Edition), 2012 Symmetric EncryptionSymmetric encryption uses one key to encrypt and decrypt. If you encrypt a zip file, and then decrypt with the same key, you are using symmetric encryption. Symmetric encryption is also called “secret key” encryption, as the key must be kept secret from third parties. Strengths include speed and cryptographic strength per bit of key. The major weakness is that the key must be securely shared before two parties may communicate securely. Symmetric keys are often shared via an out-of-band method, such as via face-to-face discussion. The key is usually converted into a subkey, which changes for each block of data that is encrypted. Stream and block ciphersSymmetric encryption may have stream and block modes. Stream mode means each bit is independently encrypted in a “stream.” Block mode ciphers encrypt blocks of data each round; for example, 56 bits for the Data Encryption Standard (DES), and 128, 192, or 256 bits for AES. Some block ciphers can emulate stream ciphers by setting the block size to 1 bit; they are still considered block ciphers. Initialization vectors and chainingAn initialization vector is used in some symmetric ciphers to ensure that the first encrypted block of data is random. This ensures that identical plaintexts encrypt to different ciphertexts. Also, as Bruce Schneier noted, “Even worse, two messages that begin the same will encrypt the same way up to the first difference. Some messages have a common header: a letterhead, or a ‘From’ line, or whatever.” [6] Initialization vectors solve this problem. Chaining (called feedback in stream modes) seeds the previous encrypted block into the next block to be encrypted. This destroys patterns in the resulting ciphertext. DES Electronic Code Book mode (see below) does not use an initialization vector or chaining, and patterns can be clearly visible in the resulting ciphertext. DESThe Data Encryption Standard (DES) describes the Data Encryption Algorithm (DEA). DES was made a U.S. federal standard symmetric cipher in 1976. It was created due to a lack of cryptographic standards; vendors used proprietary ciphers of unknown strengths that did not interoperate with other vendors' ciphers. IBM designed DES, based on their older Lucifer symmetric cipher. It uses a 64-bit block size (meaning it encrypts 64 bits each round) and a 56-bit key. Exam Warning Even though DES is commonly referred to as an algorithm, DES is technically the name of the published standard that describes DEA. It may sound like splitting hairs, but that is an important distinction to keep in mind on the exam. DEA may be the best answer for a question regarding the algorithm itself. Modes of DESDES can use five different modes to encrypt data. The primary difference in the modes is block versus (emulated) stream, the use of initialization vectors, and whether errors in encryption will propagate to subsequent blocks. The five modes of DES are 1.Electronic Code Book (ECB) 2.Cipher Block Chaining (CBC) 3.Cipher Feedback (CFB) 4.Output Feedback (OFB) 5.Counter Mode (CTR) ECB is the original mode of DES; CBC, CFB, and OFB were later added [7]. CTR mode is the newest mode [8]. Electronic Code Book (ECB) is the simplest and weakest form of DES. It uses no initialization vector or chaining. Identical plaintexts with identical keys encrypt to identical ciphertexts. Two plaintexts with partial identical portions (such as the header of a letter) encrypted with the same key will have partial identical ciphertext portions. Note The term “Code Book” in Electronic Code Book derives from cryptographic codebooks such as those used during the Civil War. This is also a hint to remind you of ECB's simplicity (and weakness). ECB may also leave plaintext patterns evident in the resulting ciphertext. Bitmap image data (see Figure 6.11A) encrypted with a key of “Kowalski” using 56-bit DES ECB mode (see Figure 6.11B) shows obvious patterns.  Figure 6.11A. Plaintext 8-bit Bitmap (BMP) Image. Courtesy of the National Security Agency.Figure 6.11B. 56-bit DES ECB-Encrypted Ciphertext Bitmap. Cipher Block Chaining (CBC) mode is a block mode of DES that XORs the previous encrypted block of ciphertext to the next block of plaintext to be encrypted. The first encrypted block is an initialization vector that contains random data. This “chaining” destroys patterns. One limitation of CBC mode is that encryption errors will propagate: An encryption error in one block will cascade through subsequent blocks due to the chaining, destroying their integrity. Cipher Feedback (CFB) mode is very similar to CBC; the primary difference is that CFB is a stream mode. It uses feedback (the name for chaining when used in stream modes) to destroy patterns. Like CBC, CFB uses an initialization vector that destroys patterns and errors propagate. Output Feedback (OFB) mode differs from CFB in the way feedback is accomplished. CFB uses the previous ciphertext for feedback. The previous ciphertext is the subkey XORed to the plaintext. OFB uses the subkey before it is XORed to the plaintext. Because the subkey is not affected by encryption errors, errors will not propagate. Counter (CTR) mode is like OFB; the difference again is the feedback, as CTR mode uses a counter. This mode shares the same advantages as OFB (patterns are destroyed and errors do not propagate) with an additional advantage. Because the feedback can be as simple as an ascending number, CTR mode encryption can be done in parallel. A simple example would be the first block is XORed to the number 1, the second to the number 2, etc. Any number of rounds can be combined in parallel this way. Table 6.7 summarizes the five modes of DES. Table 6.7. Modes of DES Summary
Single DESSingle DES is the original implementation of DES, encrypting 64-bit blocks of data with a 56-bit key, using 16 rounds of encryption. The work factor required to break DES was reasonable in 1976, but advances in CPU speed and parallel architecture have made DES weak to a brute-force key attack today, where every possible key is generated and attempted. Massively parallel computers, such as COPACOBANA (Cost-Optimized Parallel COde Breaker, given as a non-testable example; see http://www.copacobana.org for more information), which uses over 100 CPUs in parallel, can break 56-bit DES in a week or so (and faster with more CPUs), at a cost of under $10,000. Triple DESTriple DES applies single DES encryption three times per block. Formally called the Triple Data Encryption Algorithm (TDEA) and commonly called TDES, it became a recommended standard in 1999 [9]. Single DES was recommended for legacy use only, due to the ever-lowering work factor required to break single DES. Triple DES has held up well after years of cryptanalysis; the primary weakness is that it is slow and complex compared to newer symmetric algorithms such as AES or Twofish. Note that double DES (applying DES encryption twice using two keys) is not used due to a meet-in-the-middle attack: See the “Cryptographic Attacks” section for more information. Triple DES applies DES encryption three times per block. FIPS 46-3 describes “Encrypt, Decrypt, Encrypt” (EDE) order using three keying options: one, two, or three unique keys (1TDES EDE, 2TDES EDE, and 3TDES EDE, respectively). This order may seem confusing. Why not encrypt, encrypt, encrypt, or EEE? And why use one through three keys? If you decrypt with a different key than the one used to encrypt, you are really encrypting further. Also, EDE with one key allows backward compatibility with single DES. Table 6.8 shows a single DES ECB encryption of “ATTACK AT DAWN” with the key “Hannibal,” resulting in ciphertext of “•ÁGPÚ ¦qŸÝ«¦-” (this is the actual ciphertext; some bytes contain nonprintable characters). Table 6.8. Single DES Encryption
Applying triple DES EDE with the same key each time results in the same ciphertext as single DES. Round 3 is identical to round 1, as shown in Table 6.9. Table 6.9. Triple DES Encryption with One Key
2TDES EDE uses key 1 to encrypt, key 2 to decrypt, and key 1 to encrypt. This results in 112 bits of key length. It is commonly used for legacy hardware applications with limited memory. 3TDES EDE (three different keys) is the strongest form, with 168 bits of key length. The effective strength is 112 bits due to a partial meet-in-the-middle attack; see the Cryptographic Attacks section for more information. International Data Encryption AlgorithmThe International Data Encryption Algorithm (IDEA) is a symmetric block cipher designed as an international replacement for DES. The IDEA algorithm is patented in many countries. It uses a 128-bit key and 64-bit block size. IDEA has held up to cryptanalysis; the primary drawbacks are patent encumbrance and its slow speed compared to newer symmetric ciphers such as AES. Advanced Encryption StandardThe Advanced Encryption Standard (AES) is the current U.S. standard symmetric block cipher [10]. AES uses 128-bit (with 10 rounds of encryption), 192-bit (12 rounds of encryption), or 256-bit (14 rounds of encryption) keys to encrypt 128-bit blocks of data. AES is an open algorithm, free to use, and free of any intellectual property restrictions. AES was designed to replace DES. Two- and three-key TDES EDE remain a FIPS-approved standard until 2030, to allow transition to AES. Single DES is not a current standard and is not recommended. Choosing AESThe U.S. National Institute of Standards and Technology (NIST) solicited input on a replacement for DES in the Federal Register in January 1997. They sought a public symmetric block cipher algorithm that was more secure than DES, open, and fast and efficient in both hardware and software. Fifteen AES candidates were announced in August 1998, and the list was reduced to five in August 1999. Table 6.10 lists the five AES finalists. Table 6.10. Five AES Finalists
Rijndael was chosen and became AES. The name, pronounced “Rhine Dahl” in English, is a combination of the Belgian authors’ names: Vincent Rijmen and Joan Daemen. Rijndael was chosen “because it had the best combination of security, performance, efficiency, and flexibility.” [11] Table 6.11 shows the state, which is the block of data that is being encrypted via AES. Each smaller box in the state is a byte (8 bits), and there are 16 bytes (128 bits) in each block. Data is encrypted and visualized in literal blocks. The algorithm that AES is based on was called Square for this reason. Table 6.11. One 128-bit Block of AES Data Called the State AES functionsAES has four functions: ShiftRows, MixColumns, SubBytes, and AddRoundKey. These functions provide confusion, diffusion, and XOR encryption to the state. ShiftRows provides diffusion by shifting rows of the state. It treats each row like a row of blocks, shifting each a different amount: •Row 0 is unchanged. •Row 1 is shifted 1 to the left. •Row 2 is shifted 2 to the left. •Row 3 is shifted 3 to the left. Table 6.12 shows the transformation to the state. Table 6.12. ShiftRows, Before and After MixColumns also provides diffusion by mixing the columns of the state via finite field mathematics, as shown in Table 6.13. The SubBytes function provides confusion by substituting the bytes of the state. The bytes are substituted according to a substitution table (also called an S-Box). To use the table, take the byte of the state to be substituted (assume the byte is the letter “T”). ASCII “T” is hexadecimal byte “53.” Look up 5 on the X row and 3 on the Y column, resulting in hexadecimal byte “ed,” which replaces “53” in the state. Figure 6.12 shows the AES substitution table with the byte 53 lookup overlaid on top. Figure 6.12. AES Substitution Table Converting Byte “53” to “eb.” [12] AddRoundKey is the final function applied in each round. It XORs the state with the subkey. The subkey is derived from the key, and is different for each round of AES. Blowfish and TwofishBlowfish and Twofish are symmetric block ciphers created by teams lead by Bruce Schneier, author of Applied Cryptography. Blowfish uses from 32- to 448-bit (the default is 128) keys to encrypt 64 bits of data. Twofish was an AES finalist, encrypting 128-bit blocks using 128- to 256-bit keys. Both are open algorithms, unpatented and freely available. RC5 and RC6RC5 and RC6 are symmetric block ciphers by RSA Laboratories. RC5 uses 32-(testing purposes), 64- (replacement for DES), or 128-bit blocks. The key size ranges from zero to 2040 bits. RC6 was an AES finalist. It is based on RC5, altered to meet the AES requirements. It is also stronger than RC5, encrypting 128-bit blocks using 128-, 192-, or 256-bit keys. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597499613000066 Literature ReviewParisa Naraei, ... Iman Saberi, in Optimizing IEEE 802.11i Resource and Security Essentials, 2014 2.4 Framework of AES–CCMPCCMP procedure is built on AES process in the CTR mode and (?) CCM mode of process. By combining the CTR mode privacy and CBC-MAC authentication, the CCM works. Only 128-bit block ciphers can use CCM. The CCM is based on block cipher mode of authentication and encryption. For general CCM mode two factors of selection (?) exist. First one is the selection of M, the length of authentication field. The selection of the M value includes a balance between the message and the probability of altering the message by an intruder. 4, 6, 8, 10, 12, 14, and 16 octets are legal values. The second one is selection of L, the length of the field size. Mentioned value needs a trade-off among the maximum size of message and Nonce size. Different uses need different trade-offs, so L is a parameter. Legal values of L range among 2 and 8 octets (L = 1 is reserved). M is the number of octets in authentication field 3 bits (M − 2)/2; L is the number of octets in length field 3 bits L − 1 (VOCAL, 2003). Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B978012802222100002X Manipulating the RuntimeErez Metula, in Managed Code Rootkits, 2011 Literal Value ManipulationIn previous sections we discussed manipulating code, either by tweaking the code logic or by hooking into important methods and subverting execution flow. In contrast to that, manipulation of literals deals with hard-coded values rather than code. It comes into play when a platform-wide value needs to be tweaked. Values such as constants, resources (images, strings, HTML code, etc.), class variables, initialized values, constructor values, defaults, and static member values are all subject to this kind of modification. Modifying these values requires prior knowledge of the modified target, but knowledge that is not necessarily as in-depth as when modifying target code. Since modifying such values might affect other classes depending on them, the modification can sometimes lead to unexpected behavior and should be performed carefully. Let's look at some examples of literal value manipulations. Attack ScenarioA False Sense of Security from Cryptography ManipulationMost of the runtimes out there provide many cryptography services, including encryption (symmetric/asymmetric), hashing, digital signatures, message authentication, secure random number generation, and handling of data encoding/decoding. Cryptography services offer the primitives used as building blocks to perform secure operations, among which the most common are authentication, message confidentiality, and integrity. Now, one of the worst things that can happen in cryptography is a false sense of security, in which the parties that are using some kind of cryptography service are relying on its security without knowing that it provides them a lower level of security than they are expecting. As a result, they will use the service even though it does not meet their requirements, and this will cause them to perform operations that they would not perform otherwise. An example of this is sending sensitive information using an encryption algorithm that can be easily cracked. Since the users mistakenly think the service is secure, they'll trust the confidentiality it is supposed to provide and will use it to send sensitive information over the wire, an operation they would not perform without using encryption. An adversary with the ability to decrypt those messages will be able to read their content—as long as the legitimate parties don't know about the encryption service's weakness. Cryptography downgrading is a kind of cryptography manipulation attack that lowers the level of cryptography used by legitimate parties, thereby giving an attacker a chance to mount crypto attacks on the messages the parties are sending over the wire; the result is a false sense of security for the legitimate parties. Block cipher mode is an example of algorithm downgrading, and can be used when enforcing that the encryption mode should be the less secure option. For example, the .NET runtime supports the following encryption modes: Cipher Block Chaining (CBC), Electronic Code Block (ECB), Output Feedback (OFB), Cipher Feedback (CFB), and Ciphertext Stealing (CTS).C Whereas CBC is a good option and is most commonly used, ECB is considered the simplest and least secure option because of how it operates: ECB divides the plaintext message into blocks and then encrypts each block separately, which has many disadvantages. The main disadvantage is that for identical plaintext blocks, the encryption produces identical encrypted ciphertext and does not hide data patterns. Another drawback is that it is susceptible to replay attacks. Since it does not provide adequate security, using it is not recommended. The CipherMode class contained in the System.Security.Cryptography namespace (located in mscorlib.dll) defines the block cipher encryption modes that the framework supports, and sets the values for the modes used as enums by the cryptographic classes (such as those inherited from the SymmetricAlgorithm class): .field public static literal valuetype System.Security.Cryptography.CipherMode CBC = int32(0x00000001) .field public static literal valuetype System.Security.Cryptography.CipherMode ECB = int32(0x00000002) .field public static literal valuetype System.Security.Cryptography.CipherMode OFB = int32(0x00000003) .field public static literal valuetype System.Security.Cryptography.CipherMode CFB = int32(0x00000004) .field public static literal valuetype System.Security.Cryptography.CipherMode CTS = int32(0x00000005) The preceding code defines the values for the five different modes, and sets each one to a unique value from 1 to 5 that is used to distinguish the value at runtime. Now, let's say the attacker's mission is to downgrade the encryptions performed to use the insecure ECB mode, so the attacker changes each mode's value to be the same as the ECB value, which is 0x00000002: .field public static literal valuetype System.Security.Cryptography.CipherMode CBC = int32(0x00000002) .field public static literal valuetype System.Security.Cryptography.CipherMode ECB = int32(0x00000002) .field public static literal valuetype System.Security.Cryptography.CipherMode OFB = int32(0x00000002) .field public static literal valuetype System.Security.Cryptography.CipherMode CFB = int32(0x00000002) .field public static literal valuetype System.Security.Cryptography.CipherMode CTS = int32(0x00000002) As a visual indicator that using ECB is bad, take a look at the cleartext image shown in Figure 5.10. Figure 5.10. Original Image This image represents a cleartext message that we want to encrypt to maintain message confidentiality. The output of encrypting this message using an ECB block encryption mode might be similar to that shown in Figure 5.11. Figure 5.11. Encrypted Image (Using ECB Mode) As you can see, the encrypted image using ECB mode does not provide real encryption; therefore, it should not be used, unless it is used as we described earlier. Moving from simple literal value manipulation to logical manipulation, another crypto manipulation attack is key manipulation, which can happen if the attacker manipulated the key generation process in which a pseudorandom number generator (PRNG) is used to create keys or other kinds of secure random values to be used by various crypto operations. By manipulating the returned values (from inside the PRNG or at the method calling it), the attacker can control the generated key used for encryption, signing, authentication, and so forth, while making the application (on behalf of the user) think it created a unique value, without being aware that the value is also known to the attacker. An example of this is an application that stores sensitive data while encrypting it, for later retrieval. With this method, the key will look fine and will not raise any suspicions, even though it also contains the encrypted data. Looking at the encryption as a whole will not disclose any clues that something is wrong; the encryption was performed using a standard algorithm using the runtime libraries, the key was generated by a PRNG, and the data looks encrypted. In a closely related attack, called key fixation, the attacker can fixate the key by manipulating the crypto methods themselves (rather than through key generation). For example, the attacker can implement a kind of behavior in which regardless of the key used as input for the required crypto service the behavior will be performed using a specific key controlled by the attacker. This kind of attack again makes it look like nothing's wrong with the encryption, since the data looks encrypted, except for the fact that the effective key is not the legitimate user's provided key, but the attacker's. Figure 5.12 shows an example of something similar on the GenerateKey method from the .NET runtime crypto classes, which provides a key generation service to the applications. Figure 5.12. The Unmodified Code of the GenerateKey Method (Decompiled to C#) This method creates an empty array of bytes to be used as the key for the relevant crypto algorithm (whose size depends on the algorithm key size in bits divided by 8). Then it invokes the random number generator to fill it with random values. A simple yet effective form of key fixation can be performed by hard-coding the values that are filled in inside this buffer, as shown in Figure 5.13. Figure 5.13. The Code of the Manipulated GenerateKey Method (Decompiled to C#) The GenerateKey method will always return a fixed value for the key, but it's easy to customize it to do so upon specific conditions so as not to raise any suspicions. Such an attack will allow the attacker to encrypt data on the legitimate user's behalf, decrypt the data, digitally sign the data, and so on. In relation to data signing, crypto hash functions are often used to calculate a message digest, which is a kind of signature for a given message. In an attack similar to those we've just described, an attacker can manipulate hash functions to calculate a specific value, thereby forcing the application to accept forged messages, to bypass authentication mechanisms, and so on. Another way to perform a crypto attack by manipulating its core logic is to transfer sensitive information used in the encryption process, such as encryption keys, salts, and so on, to the attacker. An example of this is a runtime encryption method manipulated in such a way as to contain injected code that sends this kind of data to the attacker's remote machine. Candidate methods for such an attack are methods that initialize crypto operations by receiving the encryption key from the caller. The injected code would grab the key from inside the method and send it remotely. We'll discuss sending sensitive data to the attacker's machine in the next chapter. Redefining IL Instruction OpcodesThe runtimes provide their own set of opcodes (operation codes), which are portions of the runtimes' VM instructions that define the micro-level operations from which they're composed, included as part of the runtime. Such opcode classes are used when generating code on the fly; they are also used internally by runtime mechanisms such as interoperability services, regular expressions, and HTTP controls, among other things. Tampering with the hard-coded values of such instructions leads to lower-level execution subversion and is equivalent to “microcode” modifications to how instructions should behave at the hardware level. For example, .NET's Opcode class defines the field representation structure for its IL bytecode instructions used internally by the ILGenerator class when performing emission—for example, when using Emit. The runtime IL opcode values are declared in the Opcodes class constructor, which defines the behavior of each opcode. In Figure 5.14, you can see the actual code from the Opcodes class. Figure 5.14. Opcodes Class Constructor (Using Reflector) Manipulating the values of such instructions, by changing the hard-coded literals from which they're composed, allows us to change their lowest-level primitives and operations. The following is an example of changing the meaning of the add instruction so that it performs like the sub operation: //declaring add ldstr "add" ldc.i4.2 ldc.i4.s 19 ldc.i4.5 ldc.i4.5 ldc.i4.1 ldc.i4 0xff ldc.i4.s 88 ldc.i4.5 ldc.i4.0 ldc.i4.m1 newobj instance void System.Reflection.Emit.OpCode::.ctor(string, … System.Reflection.Emit.OpCodes::Add //defining sub ldstr" sub" ldc.i4.2 ldc.i4.s 19 ldc.i4.5 ldc.i4.5 ldc.i4.1 ldc.i4 0xff ldc.i4.s 89 ldc.i4.5 ldc.i4.0 ldc.i4.m1 newobj instance void System.Reflection.Emit.OpCode::.ctor(string, … System.Reflection.Emit.OpCodes::Sub Each instruction is defined by setting its name, the stack behavior for pop, the stack behavior for push, and the operand type, opcode type, instruction size, emitted values, flow control, whether it causes the flow control to change unconditionally, and the amount by which the stack size needs to be updated. As we can see in the preceding code, the only difference between those operations is the value 88 in add and the value 89 in sub, so by changing 88 to 89 in add we can make the add operation act like sub. For Dalvik, you can find the opcodes in core.jar, at /dalvik/bytecodes, in the Opcodes class: .class public interface abstract Ldalvik/bytecode/Opcodes; .super Ljava/lang/Object; .source "Opcodes.java" .field public static final OP_ADD_DOUBLE:I = 0xab .field public static final OP_ADD_DOUBLE_2ADDR:I = 0xcb .field public static final OP_ADD_FLOAT:I + 0xa6 .field public static final OP_ADD_FLOAT_2ADDR:I = 0xc6 .field public static final OP_ADD_INT:I = 0x90 .field public static final OP_ADD_INT_2ADDR:I = 0xb0 .field public static final OP_ADD_INT_LIT16:I = 0xd0 .field public static final OP_ADD_INT_LIT8:I = 0xd8 .field public static final OP_ADD_LONG:I = 0x9b .field public static final OP_ADD_LONG_2ADDR:I = 0xbb .field public static final OP_AGET:I = 0x44 .field public static final OP_AGET_BOOLEAN:I = 0x47 .field public static final OP_AGET_BYTE:I = 0x48 .field public static final OP_AGET_CHAR:I = 0x49 .field public static final OP_AGET_OBJECT:I = 0x46 .field public static final OP_AGET_SHORT:I = 0x4a .field public static final OP_AGET_WIDE:I = 0x45 .field public static final OP_AND_INT:I = 0x95 .field public static final OP_AND_INT_2ADDR:I = 0xb5 … Injecting into Embedded ResourcesMany assemblies contain embedded resources as part of the assembly metadata, such as strings and files, images, icons, HTML files, JavaScript files, XML files, array streams, DTD files, and such. When such a file is required, the runtime fetches it as a resource and uses it as part of the application. As an example, Figure 5.15 shows a short list of the files contained as resources in .NET's System.Web assembly, as seen using Reflector. Figure 5.15. Embedded Resources of System.Web.dll Modifying the values of those resources might influence the behavior of ASP.NET Web applications, as they are served to clients' browsers. An example of such a modification is the injection of HTML or JavaScript code to embedded resources containing code that is sent to the client. Tampering with these kinds of resources leads to permanent modification of the generated output and can be abused to implement phishing attacks, browser hijacking, keylogging, permanent XSS, and other attacks. WarningBefore we move on, remember that the methods shown in this part of the chapter were just examples. There are many other ways to achieve similar behavior, and many other operations that we did not cover here due to space restrictions. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597495745000052 Survey on key revocation mechanisms in wireless sensor networksMengmeng Ge, ... Yong Yu, in Journal of Network and Computer Applications, 2016 3.6.1 Performance analysisThe distributed revocation schemes discussed in this section require priori knowledge of deployment. Thus, they are impractical for deployment in many (real-world) applications. To analyze and compare the performance of all distributed schemes, we assume that the network has the same structure (e.g. one sink, n nodes, m neighbor nodes of each node). As the second method in Reelection scheme is only introduced as a general idea, we refer to the first method as Reelection scheme when discussing the performance below. In terms of the threshold number of votes per session or per time period, we assume t for schemes with negative votes (i.e. BVB, IVB, BMB and PKI schemes) and k for the Reelection scheme with positive votes. Reelection scheme requires a large threshold number of votes as positive votes need to exceed negative votes. Therefore, the constant t is much less than k. In IVB scheme, an Authenticated Encryption (e.g. Rogaway et al., 2003) is used for the symmetric encryption. As BVB, IVB and BMB schemes use the symmetric encryption, we use the block cipher mode proposed in Rogaway et al. (2003) with a possible key size of 64 bits and a possible block size of 64 bits for the performance analysis. In terms of the storage requirement, each node in the BVB scheme is preloaded with m voting keys, mlogm authentication hash values, m root values and m activation secrets. With additional sessions, the IVB scheme requires stotalm encrypted revocation secret shares, stotalm logm authentication hash values, stotalm root values and stotalm masks. The PKI scheme needs to store m hashed values for each node. In the BMB scheme, each node stores stotalm number of encrypted votes and stotalm number of t elements in the public matrix. In the Reelection scheme, each node is preloaded with stotalm shares, stotalm hashed shares, a root authentication value, its own end-of-chain authentication value and logn path authentication values. In terms of communication overhead per vote, the voting member in both BVB and IVB schemes broadcasts its voting secret along with logm authentication hash values. As for the size of the hash values, we consider 80 bits used in the simulation in the BVB scheme. In the PKI scheme, each voting member broadcasts a CRV which contains four values. It is supposed to consume 352 bits of bandwidth. The BMB scheme requires the voting member to broadcast a vote of t elements and another t elements in the public matrix. In the Reelection scheme, the voting member only sends its secret share to the voting target. As the secret token is derived using a hash chain, we use 80 bits for the secret and shares. As for the communication load per vote verification, the node in the BVB, IVB and BMB schemes is required to distribute m activation secrets or masks to its voting members, while both PKI and Reelection schemes require no such communication. There is no explicit description about the size of the activation secret or mask. Here, we assume that it has the same size with other secret keys (i.e. 64 bits). In terms of computational complexity per revocation, the BVB scheme requires counting of the number of votes. Both IVB and BMB schemes require each voting member to solve a t-degree linear problem while the Reelection scheme requires k-degree linear probem. The PKI scheme requires both XOR and counting operations. As for the computational complexity per vote verification, both BVB and IVB schemes require logm hash operations. The BMB scheme requires t multiplications and (t−1) additions, and one XOR operation and one hash operation are required in the PKI scheme and the Reelection scheme respectively. The performance of the five distributed schemes is discussed in Table 2. Table 2. Comparative summary of the distributed revocation schemes.
It should be noted that the Reelection scheme has a token verification process. After the voting process, the voting target broadcasts a reconstructed token, its end-of-chain authentication value and logn authentication values to its voting member, which incurs a communication overhead of 80 logn bits. After receiving the broadcast, voting members need to verify the token by performing hash operations of logn times. Read full article URL: https://www.sciencedirect.com/science/article/pii/S1084804516000333 How many rounds does AES 256 have?The three AES varieties are also distinguished by the number of rounds of encryption. AES 128 uses 10 rounds, AES 192 uses 12 rounds, and AES 256 uses 14 rounds.
How long should AES 256 key be?AES-256, which has a key length of 256 bits, supports the largest bit size and is practically unbreakable by brute force based on current computing power, making it the strongest encryption standard.
How many keys does AES 256 have?AES has 10 rounds for 128-bit keys, 12 rounds for 192-bit keys, and 14 rounds for 256-bit keys.
How long would it take to crack 256With the right quantum computer, AES-128 would take about 2.61*10^12 years to crack, while AES-256 would take 2.29*10^32 years. For reference, the universe is currently about 1.38×10^10 years old, so cracking AES-128 with a quantum computer would take about 200 times longer than the universe has existed.
|
