cryptography for developers PHẦN 8 ppt

Q: What is a MAC function? A: A MAC or message authentication code function is a function that accepts a secret key and message and reduces it to a MAC tag. Q: What is a MAC tag? A: A tag is a short string of bits that is used to prove that the secret key and message were processed together through the MAC function. Q: What does that mean? What does authentication mean? A: Being able to prove that the message and secret key were combined to produce the tag can directly imply one thing: that the holder of the key produced vouches for or simply wishes to convey an unaltered original message. A forger not possessing the secret key should have no significant advantage in producing verifiable MAC tags for messages. In short, the goal of a MAC function is to be able to conclude that if the MAC tag is cor- rect, the message is intact and was not modified during transit. Since only a limited number of parties (typically only one or two) have the secret key, the ownership of the message is rather obvious. Q: What standards are there? A: There are two NIST standards for MAC functions currently worth considering.The CMAC standard is SP 800-38B and specifies a method of turning a block cipher into a MAC function.The HMAC standard is FIPS-198 and specifies a method of turning a hash function into a MAC. An older standard, FIPS-113, specifies CBC-MAC (a pre- cursor to CMAC) using DES, and should be considered insecure. Q: Should I use CMAC or HMAC? A: Both CMAC and HMAC are secure when keyed and implemented safely. CMAC is typically more efficient for very short messages. It is also ideal for instances where a cipher is already deployed and space is limited. HMAC is more efficient for larger mes- www.syngress.com Message - Authentication Code Algorithms • Chapter 6 293 Frequently Asked Questions The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. 404_CRYPTO_06.qxd 10/30/06 10:20 AM Page 293 sages, and ideal when a hash is already deployed. Of course, you should pick whichever matches the standard you are trying to adhere to. Q: What is advantage? A: We have seen the term advantage several times in our discussion already. Essentially, the advantage of an attacker refers to the probability of forgery gained by a forger through analysis of previously authenticated messages. In the case of CMAC, for instance, the advantage is roughly approximate to (mq) 2 /2 126 for CMAC-AES—where m is the number of messages authenticated, and q is the number of AES blocks per message. As the ratio approaches one, the probability of a successful forgery approaches one as well. Advantage is a little different in this context than in the symmetric encryption con- text. An advantage of 2 –40 is not the same as using a 40-bit encryption key. An attack on the MAC must take place online.This means, an attacker has but one chance to guess the correct MAC tag. In the latter context, an attacker can guess encryption keys offline and does not run the risk of exposure. Q: How do key lengths play into the security of MAC functions? A: Key lengths matter for MAC functions in much the same way they matter in symmetric cryptography.The longer the key, the longer a brute force key determination will take. If an attacker can guess a message, he can forge messages. Q: How does the length of the MAC tag play into the security of MAC functions? A: The length of the MAC tag is often variable (at least it is in HMAC and CMAC) and can limit the security of the MAC function.The shorter the tag, the more likely a forger is to guess it correctly. Unlike hash functions, the birthday paradox attack does not apply. Therefore, short MAC tags are often ideally secure for particular applications. Q: How do I match up key length, MAC tag length, and advantage? A: Your key length should ideally be as large as possible.There is often little practical value to using shorter keys. For instance, padding an AES-128 key with 88 bits of zeroes, effectively reducing it to a 40-bit key, may seem like it requires fewer resources. In fact, it saves no time or space and weakens the system. Ideally, for a MAC tag length of w- bits, you wish to give your attacker an advantage of no more than 2 -w . For instance, if you are going to send 2 40 blocks of message data with CMAC-AES, the attacker’s advan- tage is no less than 2 –46 . In this case, a tag longer than 46 bits is actually wasteful as you approach the 2 40 th block of message data. On the other hand, if you are sending a trivial amount of message blocks, the advantage is very small and the tag length can be cus- tomized to suit bandwidth needs. www.syngress.com 294 Chapter 6 • Message - Authentication Code Algorithms 404_CRYPTO_06.qxd 10/30/06 10:20 AM Page 294 Q: Why can I not use hash(key || message) as a MAC function? A: Such a construction is not resistant to offline attacks and is also vulnerable to message extension attacks. Forging messages is trivial with this scheme. Q: What is a replay attack? A: A replay attack can occur when you break a larger message into smaller independent pieces (e.g., packets).The attacker exploits the fact that unless you correlate the order of the packets, the attacker can change the meaning of the message simply by re-arranging the order of the packets. While each individual packet may be authenticated, it is not being modified.Thus, the attack goes unnoticed. Q: Why do I care? A: Without replay protection, an attacker can change the meaning of the overall message. Often, this implies the attacker can re-issue statements or commands. An attacker could, for instance, re-issue shell commands sent by a remote login shell. Q: How do I defeat replay attacks? A: The most obvious solution is to have a method of correlating the packets to their overall (relative) order within the larger stream of packets that make up the message.The most obvious solutions are timestamp counters and simple incremental counters. In both cases, the counter is included as part of the message authenticated. Filtering based on previously authenticated counters prevents an attacker from re-issuing an old packet or issuing them out of stream order. Q: How do I deal with packet loss or re-ordering? A: Occasionally, packet loss and re-ordering are part of the communication medium. For example, UDP is a lossy protocol that tolerates packet loss. Even when packets are not lost, they are not guaranteed to arrive in any particular order (this is often a warning that does not arise in most networks). Out of order UDP is fairly rare on non-congested IPv4 networks.The meaning of the error depends on the context of the application. If you are working with UDP (or another lossy medium), packet loss and re-ordering are usually not malicious acts.The best practice is to reject the packet, possibly issue a syn- chronization message, and resume the protocol. Note that an attacker may exploit the resynchronization step to have a victim generate authenticated messages. On a relatively stable medium such as TCP, packet loss and reordering are usually a sign of malicious interference and should be treated as hostile.The usual action here is to drop the con- nection. (Commonly, this is argued to be a denial of service (DoS) attack vector. However, anyone with the ability to modify packets between you and another host can also simply filter all packets anyways.) There is no added threat by taking this precaution. www.syngress.com Message - Authentication Code Algorithms • Chapter 6 295 404_CRYPTO_06.qxd 10/30/06 10:20 AM Page 295 In both cases, whether the error is treated as hostile or benign, the packet should be dropped and not interpreted further up the protocol stack. Q: What libraries provide MAC functionality? A: LibTomCrypt provides a highly modular HMAC function for C developers. Crypto++ provides similar functionality for C++ developers. Limited HMAC support is also found in OpenSSL. LibTomCrypt also provides modular support for CMAC.At the time of this writing, neither Crypto++ or OpenSSL provide support for CMAC. By “modular,” we mean that the HMAC and CMAC implementations are not tied to underlying algo- rithms. For instance, the HMAC code in LibTomCrypt can use any hash function that LibTomCrypt supports without changes to the API.This allows future upgrades to be performed in a more timely and streamlined fashion. Q: What patents cover MAC functions? A: Both HMAC and CMAC are patent free and can be used for any purpose. Various other MAC functions such as PMAC are covered by patents but are also not standard. www.syngress.com 296 Chapter 6 • Message - Authentication Code Algorithms 404_CRYPTO_06.qxd 10/30/06 10:20 AM Page 296 Encrypt and Authenticate Modes Solutions in this chapter: ■ Encrypt and Authenticate Modes ■ Security Goals ■ Standards ■ Design of GCM and CCM Modes ■ Putting It All Together Chapter 7 297  Summary  Solutions Fast Track  Frequently Asked Questions 404_CRYPTO_07.qxd 10/30/06 11:51 AM Page 297 Introduction In Chapter 6,“Message Authentication Code Algorithms,” we saw how we could use mes- sage authentication code (MAC) functions to ensure the authenticity of messages between two or more parties.The MAC function takes a message and secret key as input and pro- duces a MAC tag as output.This tag, combined with the message, can be verified by any party who has the same secret key. We saw how MAC functions are integral to various applications to avoid various attacks. That is, if an attacker can forge messages he could perform tasks we would rather he could not. We also saw how to secure a message broken into smaller packets for convenience. Finally, our example program combined both encryption and authentication into a frame encoder to provide both privacy and authentication. In particular, we use PKCS #5, a key derivation function to accept a master secret key, and produce a key for encryption and another key for the MAC function. Would it not be nice, if we had some function F(K, P) that accepts a secret key K and message P and returns the pair of (C,T) corresponding to the ciphertext and MAC tag (respectively)? Instead of having to create, or otherwise supply, two secret keys to accomplish both goals, we could defer that process to some encapsulated standard. Encrypt and Authenticate Modes This chapter introduces a relatively new set of standards in the cryptographic world known as encrypt and authenticate modes.These modes of operations encapsulate the tasks of encryption and authentication into a single process.The user of these modes simply passes a single key, IV (or nonce), and plaintext.The mode will then produce the ciphertext and MAC tag. By combining both tasks into a single step, the entire operation is much easier to implement. The catalyst for these modes is from two major sources.The first is to extract any per- formance benefits to be had from combining the modes.The second is to make authentica- tion more attractive to developers who tend to ignore it.You are more likely to find a product that encrypts data, than to find one that authenticates data. Security Goals The security goals of encrypt and authenticate modes are to ensure the privacy and authen- ticity of messages. Ideally, breaking one should not weaken the other.To achieve these goals, most combined modes require a secret key long enough such that an attacker could not guess it.They also require a unique IV per invocation to ensure replay attacks are not pos- sible.These unique IVs are often called nonces in this context.The term nonce actually comes from N once , which means to use N once and only once. We will see later in this chapter that we can use the nonce as a packet counter when the secret key is randomly generated.This allows for ease of integration into existing protocols. www.syngress.com 298 Chapter 7 • Encrypt and Authenticate Modes 404_CRYPTO_07.qxd 10/30/06 11:51 AM Page 298 Standards Even though encrypt and authenticate modes are relatively new, there are still a few good standards covering their design. In May 2004, NIST specified CCM as SP 800-38C, the first NIST encrypt and authenticate mode. Specified as a mode of operation for block ciphers, it was intended to be used with a NIST block cipher such as AES. CCM was selected as the result of a design contest in which various proposals were sought out. Of the more likely contestants to win were Galois Counter Mode (GCM), EAX mode, and CCM. GCM was designed originally to be put to use in various wireless standards such as 802.16 (WiMAX), and later submitted to NIST for the contest. GCM is not yet a NIST standard (it is proposed as SP 800-38D), but as it is used through IEEE wireless standards it is a good algorithm to know about. GCM strives to achieve hardware performance by being massively parallelizable. In software, as we shall see, GCM can achieve high performance levels with the suitable use of the processor’s cache. Finally, EAX mode was proposed after the submission of CCM mode to address some of the shortcomings in the design. In particular, EAX mode is more flexible in terms of how it can be used and strives for higher performance (which turns out to not be true in practice). EAX mode is actually a properly constructed wrapper around CTR encryption mode and CMAC authentication mode.This makes the security analysis easier, and the design more worthy of attention. Unfortunately, EAX was not, and is currently not, considered for stan- dardization. Despite this, EAX is still a worthy mode to know about and understand. Design and Implementation We shall consider the design, implementation, and optimization of three popular algorithms. We will first explore the GCM algorithm, which has already found practical use in the IEEE 802 series of standards.The reader should take particular interest in this design, as it is also likely to become a NIST standard. After GCM, we will explore the design of CCM, the only NIST standardized mode at the time of this writing. CCM is both efficient and secure, making it a mode worth using and knowing about. ` Additional Authentication Data All three algorithms include an input known as the additional authentication data (AAD, also known as header data in CCM).This allows the implementer to include data that accompa- nies the ciphertext, and must be authenticated but does not have to be encrypted; for example, metadata such as packet counters, timestamps, user and host names, and so on. AAD is unique to these modes and is handled differently in all three. In particular, EAX has the most flexible AAD handling, while GCM and CCM are more restrictive. All three modes accept empty AAD strings, which allows developers to ignore the AAD facilities if they do not need them. www.syngress.com Encrypt and Authenticate Modes • Chapter 7 299 404_CRYPTO_07.qxd 10/30/06 11:51 AM Page 299 Design of GCM GCM (Galois Counter Mode) is the design of David McGraw and John Viega. It is the product of universal hashing and CTR mode encryption for security.The original motiva- tion for GCM mode was fast hardware implementation.As such, GCM employs the use of GF(2 128 ) multiplication, which can be efficient in typical FPGA and other hardware imple- mentations. To properly discuss GCM, we have to unravel an implementer’s worst nightmare—bit ordering.That is, which bit is the most significant bit, how are they ordered, and so on. It turns out that GCM is not one of the most straightforward designs in this respect. Once we get past the Galois field math, the rest of GCM is relatively easy to specify. GCM GF(2) Mathematics GCM employs multiplications in the field GF(2 128 )[x]/v(x) to perform a function it calls GHASH. Effectively, GHASH is a form of universal hashing, which we will discuss next.The multiplication we are performing here is not any different in nature than the multiplications used within the AES block cipher.The only differences are the size of the field and the irre- ducible polynomial used. GCM uses a bit ordering that does not seem normal upon first inspection. Instead of storing the coefficients of the polynomials from the least significant bit upward, they store them backward. For example, from AES we would see that the polynomial p(x) = x 7 + x 3 + x + 1 would be represented by 0x8B. In the GCM notation, the bits are reversed. In GCM notation, x 7 would be 0x01 instead of 0x80, so our polynomial p(x) would be represented as 0xD1 instead. In effect, the bytes are in little endian fashion.The bytes themselves are arranged in big endian fashion, which further complicates things.That is, byte number 15 is the least significant byte, and byte number 0 is the most significant byte. The multiplication routine is then implemented with the following routines: static void gcm_rightshift(unsigned char *a) { int x; for (x = 15; x > 0; x ) { a[x] = (a[x]>>1) | ((a[x-1]<<7)&0x80); } a[0] >>= 1; } This performs what GCM calls a right shift operation. Numerically, it is equivalent to a left shift (multiplication by 2), but since we order the bits in each byte in the opposite direction, we use a right shift to perform this. We are shifting from byte 15 down to byte 0. static const unsigned char mask[] = { 0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01 }; static const unsigned char poly[] = { 0x00, 0xE1 }; www.syngress.com 300 Chapter 7 • Encrypt and Authenticate Modes 404_CRYPTO_07.qxd 10/30/06 11:51 AM Page 300 The mask is a simple way of masking off bits in the byte in reverse order.The poly array is the least significant byte of the polynomial, the first element is a zero, and the second ele- ment is the byte of the polynomial. In this case, 0xE1 maps to p(x) = x 128 + x 7 + x 2 + x + 1 where the x 128 term is implicit. void gcm_gf_mult(const unsigned char *a, const unsigned char *b, unsigned char *c) { unsigned char Z[16], V[16]; unsigned x, y, z; memset(Z, 0, 16); memcpy(V, a, 16); for (x = 0; x < 128; x++) { if (b[x>>3] & mask[x&7]) { for (y = 0; y < 16; y++) { Z[y] ^= V[y]; } } z = V[15] & 0x01; gcm_rightshift(V); V[0] ^= poly[z]; } memcpy(c, Z, 16); } This routine accomplishes the operation c = ab in the Galois field chosen by GCM. It effectively is the same algorithm we used for the multiplication in AES, except here we are using an array of bytes to represent the polynomials. We use Z to accumulate the product as we produce it. We use V as a copy of a, which we can double and selectively add to Z based on the bits of b. This multiplication routine accomplishes numerically what we require, but is horribly slow. Fortunately, there is more than one way to multiply field elements.As we shall see during the implementation phase, a table-based multiplication routine will be far more profitable. The curious reader may wish to examine the GCM source of LibTomCrypt for the variety of tricks that are optionally used depending on the configuration. In addition to the previous routine, LibTomCrypt provides an alternative to gcm_gf_mult() (see src/encauth/ gcm/gcm_gf_mult.c in LibTomCrypt) that uses a windowed multiplication on whole words (Darrel Hankerson, Alfred Menezes, Scott Vanstone,“Guide to Elliptic Curve Cryptography,” p. 50, Algorithm 2.36).This becomes important during the setup phase of GCM, even when we use a table-based multiplication routine for bulk data processing. Before we can show you a table-based multiplication routine, we must show you the constraints on GCM that make this possible. www.syngress.com Encrypt and Authenticate Modes • Chapter 7 301 404_CRYPTO_07.qxd 10/30/06 11:51 AM Page 301 Universal Hashing Universal hashing is a method of creating a function f(x) such that for distinct values of x and y, the probability of f(x) = f(y) is that of any proper random function.The simplest example of such a universal hash is the mapping f(x) = (ax + b mod p) mod n for random values of a and b and random primes p and n (n < p). Universal MAC functions, such as those in GCM (and other algorithms such as Daniel Bernstein’s Poly1305) use a variation of this to achieve a secure MAC function H[i] = (H[i – 1] * K) + M[i] where the last H[i] value is the tag, K is a unit in a finite field and the secret key, and M[i] is a block of the message.The multiplication and addition must be performed in a finite field of considerable size (e.g., 2 128 units or more). In the case of GCM, we will create the MAC functionality, called GHASH, with this scheme using our GF(2 128 ) multiplication routine. GCM Definitions The entire GCM algorithm can be specified by a series of equations. First, let us define the various symbols we will be using in the equations (Figure 7.1). ■ Let K represent the secret key. ■ Let A represent the additional authentication data, there are m blocks of data in A. ■ Let P represent the plaintext, there are n blocks of data in P. ■ Let C represent the ciphertext. ■ Let Y represent the CTR counters. ■ Let T represent the MAC tag. ■ Let E(K, P) represent the encryption of P with the secret key K and block cipher E (e.g., E = AES). ■ Let IV represent the IV for the message to be processed. www.syngress.com 302 Chapter 7 • Encrypt and Authenticate Modes 404_CRYPTO_07.qxd 10/30/06 11:51 AM Page 302 [...]... int x; for (x = 15; x > 0; x ) { a[x] = (a[x]>>1) | ((a[x-1]= 1; } This function performs the right shift (multiplication by x) using GCM conventions 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 0 98 099 100 101 102 /* c = b*a */ static const unsigned char mask[] = { 0x80, 0x40, 0x20, 0x10, 0x 08, 0x04, 0x02, 0x01 }; static const unsigned char poly[] = { 0x00,... fully unrolled and turned into simple load and XOR operations 075 076 077 /* GMAC it */ gcm->pttotlen += 1 28; gcm_mult_h(gcm, gcm->X); Since we are processing 16-byte blocks, we always perform the multiplication by H on the accumulated data 0 78 079 080 081 082 083 084 085 086 /* increment counter */ for (y = 15; y >= 12; y ) { if (++gcm->Y[y] & 255) { break; } } if ((err = cipher_descriptor[gcm->cipher].ecb_encrypt(... slower multiplier, since at this point we do not have tables to work with 072 073 074 075 076 077 0 78 079 080 081 082 083 084 /* now generate the rest of the tables * based the previous table */ for (x = 1; x < 16; x++) { for (y = 0; y < 256; y++) { /* now shift it right by 8 bits */ t = gcm->PC[x-1][y][15]; for (z = 15; z > 0; z ) { gcm->PC[x][y][z] = gcm->PC[x-1][y][z-1]; } gcm->PC[x][y][0] = gcm_shift_table[tbuflen = 0; gcm->totlen = 0; gcm->mode = GCM_MODE_AAD; } if (gcm->mode != GCM_MODE_AAD || gcm->buflen >= 16) { return CRYPT_INVALID_ARG; } At this point, we check that we are indeed in AAD mode and that our buflen is a legal value 072 073 074 075 076 077 0 78 079 080 081 082 083 084 x = 0; #ifdef LTC_FAST if (gcm->buflen == 0) { for. .. B[M(6)][i] = B[M(2)][i] ^ B[M(4)][i]; B[M(9)][i] = B[M(1)][i] ^ B[M (8) ][i]; B[M(10)][i] = B[M(2)][i] ^ B[M (8) ][i]; B[M(12)][i] = B[M (8) ][i] ^ B[M(4)][i]; /* now all 3 bit values and the only 4 bit value: www.syngress.com 309 404_CRYPTO_07.qxd 310 10/30/06 11:51 AM Page 310 Chapter 7 • Encrypt and Authenticate Modes 177 1 78 179 180 181 182 183 * 7, 11, 13, 14, 15 */ B[M(7)][i] = B[M(3)][i] B[M(11)][i] =... Destination for a * b */ void gcm_gf_mult(const unsigned char *a, const unsigned char *b, unsigned char *c) { unsigned char Z[16], V[16]; unsigned x, y, z; zeromem(Z, 16); XMEMCPY(V, a, 16); www.syngress.com 307 404_CRYPTO_07.qxd 3 08 10/30/06 11:51 AM Page 3 08 Chapter 7 • Encrypt and Authenticate Modes 103 104 105 106 107 1 08 109 110 111 112 113 114 for (x = 0; x < 1 28; x++) { if (b[x>>3] & mask[x&7]) { for. .. use the tables approach.The PC table contains 16 8x1 28 tables, one for each byte of the input and for each of their respective possible values.The first thing we must do is copy the 0th entry to T (our accumulator).The rest of the lookups will be XORed into this value 012 013 014 015 016 017 0 18 019 020 021 022 for (x = 1; x < 16; x++) { #ifdef LTC_FAST for (y = 0; y < 16; y += sizeof(LTC_FAST_TYPE)) . time. 185 zeromem(tmp, sizeof(tmp)); 186 187 /* compute product four bits of each word at a time */ 188 /* for each nibble */ 189 for (i = (BPD/4)-1; i >= 0; i ) { 190 /* for each word */ 191 for. char mask[] = 083 { 0x80, 0x40, 0x20, 0x10, 0x 08, 0x04, 0x02, 0x01 }; 084 static const unsigned char poly[] = 085 { 0x00, 0xE1 }; 086 087 088 /** 089 GCM GF multiplier (internal use only) bitserial 090. ((a[x-1]<<7)&0x80); 077 } 0 78 a[0] >>= 1; 079 } This function performs the right shift (multiplication by x) using GCM conventions. 081 /* c = b*a */ 082 static const unsigned char mask[] = 083 { 0x80,