1 / 43

Chapter 5 Internet Security Applications

Chapter 5 Internet Security Applications. 5.0 Internet Access. In a secure remote access system, it must ensure the privacy and integrity of data as it traverses the Internet To achieve this, the system should provide user authentication, data encryption and key management.

skip
Download Presentation

Chapter 5 Internet Security Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 5Internet Security Applications

  2. 5.0 Internet Access • In a secure remote access system, it must ensure the privacy and integrity of data as it traverses the Internet • To achieve this, the system should provide user authentication, data encryption and key management.

  3. A secure one-time password authentication scheme is introduced which provides protection against replay attacks and remote client impersonation. This method is based on MD4 and MD5 message digest algorithm. • Besides, a pseudo-random number generator is used to generate the keys that are needed for data encryption. • The SSL and SET protocols will also be introduced

  4. 5.1 One-Time Password • One form of attack on networked computing systems is eavesdropping on network connections to obtain authentication information such as the login IDs and passwords of legitimate users. • Once this information is captured, it can be used at a later time to gain access to the system. One-time password systems are designed to counter this type of attack, called a "replay attack". • The authentication system uses a secret pass-phrase to generate a sequence of one-time (single use) passwords.

  5. With this system, the user's secret pass-phrase never needs to cross the network at any time such as during authentication or during pass-phrase changes. Thus, it is not vulnerable to replay attacks. • Added security is provided by the property that no secret information need be stored on any system, including the server being protected. • The OTP system protects against external passive attacks against the authentication subsystem. • It does not prevent a network eavesdropper from gaining access to private information and does not provide protection against either "social engineering" or active attacks.

  6. How it works • There are two entities in the operation of the OTP one-time password system. The generator must produce the appropriate one-time password from the user's secret pass-phrase and from information provided in the challenge from the server. • The server must send a challenge that includes the appropriate generation parameters to the generator, must verify the one-time password received, must store the last valid one-time password it received, and must store the corresponding one-time password sequence number.

  7. The server must also facilitate the changing of the user's secret pass-phrase in a secure manner. • The OTP system generator passes the user's secret pass-phrase, along with a seed received from the server as part of the challenge, through multiple iterations of a secure hash function to produce a one-time password. • After each successful authentication, the number of secure hash function iterations is reduced by one. Thus, a unique sequence of passwords is generated.

  8. The server verifies the one-time password received from the generator by computing the secure hash function once and comparing the result with the previously accepted one-time password. • The secure hash functions used are MD4 and MD5.

  9. 5.2 MD4 Message-Digest Algorithm • The MD4 is a one-way hash function which produces a 128-bit hash of any arbitrary length input. • It is conjectured that the difficulty of coming up with two messages having the same message digest is on the order of 2^64 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2^128 operations.

  10. The following describes how MD4 works • Step 1. Append Padding Bits • The message is "padded" (extended) so that its length (in K bits) is congruent to 448, modulo 512. That is, the message is extended so that it is just 64 bits shy of being a multiple of 512 bits long. Padding is always performed, even if the length of the message is already congruent to 448, modulo 512.

  11. 32 bits 32 bits 32 bits 512 bits 512 bits 512 bits Input Padding Extension Division into words K- bits 00……….01 K- bits 64 bits 448 (mod 512) ‘K’ K- bits • Padding is performed as follows: a single "1" bit is appended to the message, and then "0" bits are appended so that the length in bits of the padded message becomes congruent to 448, modulo 512. In all, at least one bit and at most 512 bits are appended. 512 bits

  12. Step 2. Append Length • A 64-bit representation of b (the length of the message before the padding bits were added) is appended to the result of the previous step. In the unlikely event that b is greater than 2^64, then only the low-order 64 bits of b are used. (These bits are appended as two 32-bit words and appended low-order word first in accordance with the previous conventions.) • At this point the resulting message (after padding with bits and with b) has a length that is an exact multiple of 512 bits. Equivalently, this message has a length that is an exact multiple of 16 (32-bit) words. Let M[0 ... N-1] denote the words of the resulting message, where N is a multiple of 16.

  13. Step 3. Initialize MD Buffer • A four-word buffer (A,B,C,D) is used to compute the message digest. Here each of A, B, C, D is a 32-bit register. These registers are initialized to the following values in hexadecimal, low-order bytes first): • word A: 01 23 45 67 • word B: 89 ab cd ef • word C: fe dc ba 98 • word D: 76 54 32 10

  14. Step 4. Process Message in 16-Word Blocks • We first define four auxiliary functions that each take as input three 32-bit words and produce as output one 32-bit word. • F(X,Y,Z) = XY + (not(X) Z) • G(X,Y,Z) = XY + XZ + YZ • = XY + (not (Z) Y) for MD5 • H(X,Y,Z) = X + Y + Z • I(X,Y,Z) =Y + (X not(Z)) for MD5

  15. In each bit position F acts as a conditional: if X then Y else Z. The function F could have been defined using + instead of v since XY and not(X)Z will never have "1" bits in the same bit position.) In each bit position G acts as a majority function: if at least two of X, Y, Z are on, then G has a "1" bit in that bit position, else G has a "0" bit. It is interesting to note that if the bits of X, Y, and Z are independent and unbiased, the each bit of f(X,Y,Z) will be independent and unbiased, and similarly each bit of g(X,Y,Z) will be independent and unbiased. The function H is the bit-wise XOR or parity" function; it has properties similar to those of F and G.

  16. Do the following: Process each 16-word block. */ For i = 0 to N/16-1 do /* Copy block i into X. */ For j = 0 to 15 do Set X[j] to M[i*16+j]. end /* of loop on j */ /* Save A as AA, B as BB, C as CC, and D as DD. */ AA = A BB = B CC = C DD = D

  17. /* Round 1. */ /* Let [abcd k s] denote the operation a = (a + F(b,c,d) + X[k]) <<< s. */ /* Do the following 16 operations. */ [ABCD 0 3] [DABC 1 7] [CDAB 2 11] [BCDA 3 19] [ABCD 4 3] [DABC 5 7] [CDAB 6 11] [BCDA 7 19] [ABCD 8 3] [DABC 9 7] [CDAB 10 11] [BCDA 11 19] [ABCD 12 3] [DABC 13 7] [CDAB 14 11] [BCDA 15 19] /* Round 2. */ /* Let [abcd k s] denote the operation a = (a + G(b,c,d) + X[k] + 5A827999) <<< s. */ /* Do the following 16 operations. */ [ABCD 0 3] [DABC 4 5] [CDAB 8 9] [BCDA 12 13] [ABCD 1 3] [DABC 5 5] [CDAB 9 9] [BCDA 13 13] [ABCD 2 3] [DABC 6 5] [CDAB 10 9] [BCDA 14 13] [ABCD 3 3] [DABC 7 5] [CDAB 11 9] [BCDA 15 13]

  18. /* Round 3. */ /* Let [abcd k s] denote the operation a = (a + H(b,c,d) + X[k] + 6ED9EBA1) <<< s. */ /* Do the following 16 operations. */ [ABCD 0 3] [DABC 8 9] [CDAB 4 11] [BCDA 12 15] [ABCD 2 3] [DABC 10 9] [CDAB 6 11] [BCDA 14 15] [ABCD 1 3] [DABC 9 9] [CDAB 5 11] [BCDA 13 15] [ABCD 3 3] [DABC 11 9] [CDAB 7 11] [BCDA 15 15] /* Then perform the following additions. (That is, increment each of the four registers by the value it had before this block was started.) */ A = A + AA B = B + BB C = C + CC D = D + DD   end /* of loop on i */

  19. Note. The value 5A..99 is a hexadecimal 32-bit constant, written with the high-order digit first. This constant represents the square root of 2. The octal value of this constant is 013240474631. • The value 6E..A1 is a hexadecimal 32-bit constant, written with the high-order digit first. This constant represents the square root of 3. The octal value of this constant is 015666365641.

  20. Step 5. Output • The message digest produced as output is A, B, C, D. That is, we begin with the low-order byte of A, and end with the high-order byte of D.

  21. 5.3 MD5 Message-Digest Algorithm • MD5 is an improved version of MD4. Although more complex than MD4, it is similar in design and also produces a 128-bit hash. • In Step 4, an additional round 4 is added

  22. /* Round 4. */ /* Let [abcd k s t] denote the operation a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */ /* Do the following 16 operations. */ [ABCD 0 6 49] [DABC 7 10 50] [CDAB 14 15 51] [BCDA 5 21 52] [ABCD 12 6 53] [DABC 3 10 54] [CDAB 10 15 55] [BCDA 1 21 56] [ABCD 8 6 57] [DABC 15 10 58] [CDAB 6 15 59] [BCDA 13 21 60] [ABCD 4 6 61] [DABC 11 10 62] [CDAB 2 15 63] [BCDA 9 21 64] /* Then perform the following additions. (That is increment each of the four registers by the value it had before this block was started.) */ A = A + AA B = B + BB C = C + CC D = D + DD

  23. 5.4 Differences Between MD4 and MD5 • A fourth round has been added. • Each step has a unique additive constant. •  The function g in round 2 was changed from (XY + XZ + YZ) to (XY + Y not(Z)) to make g less symmetric. •  Each step adds in the result of the previous step. This promotes a faster "avalanche effect". •  The order in which input words are accessed in rounds 2 and 3 is changed, to make these patterns less like each other. • The shift amounts in each round have been approximately optimized, to yield a faster "avalanche effect." The shifts in different rounds are distinct.

  24. 5.4 Pseudo-Random Number Generator (PRNG) • The ANSI X9.17 PRNG is a mechanism to generate DES keys, using triple-DES as a primitive. It has been used as a general-purpose PRNG in many applications. •  1. K is a secret triple-DES key generate somehow at initialization time. It must be random and used only for this generator. It is part of the PRNG’s secret state which is never changed by any PRNG input. •  2.     Each time for generating an output, the following steps should be done: • (a)   Ti = EK(current timestamp). • (b)  output[i] = EK(Ti  seed[i]). • (c)   seed[i+1] = EK(TI  output[i]).

  25. Possible Weaknesses • The ANSI X9.17 key generator appears to be fairy secure from all attacks that don’t involve either stopping the timer used or compromising the internal triple-DES key. Replaying any timer input about 232 times leads to a certificational weakness: a way to distinguish large numbers of X9.17 PRNG outputs form a truly random sequence of bits. • Compromising the internal triple-DES key completely destroys the X9.17 PRNG: it never recovers, even after getting thousands of bits worth of entropy in its sampled timer inputs.

  26. Solution • For systems that use X9.17, the most obvious way to resist this class of attack is to occasionally use the current X9.17 state to generate a whole new X9.17 state, including a new K and a new starting seed[0].

  27. 5.4 Secure Socket Layer (SSL) • SSL is a security protocol designed by Netscape Communications Corporation. • The reason SSL is called secured socket is because SSL uses a "secure socket" or port for transferring encrypted information between the server and the browser. The secure socket is a protocol that controls the communication between the SSL server and the browser.

  28. SSL is designed to provide security during the transmission of sensitive data over TCP/IP (the communications protocol used on the Internet). • SSL provides data encryption, server authentication, and message integrity for data transmission over the Internet. SSL 2.0 supports server authentication only, while SSL 3.0 supports both client and server authentication. SSL encrypts the data while it is being transmitted over the Internet. • The encryption is done in the background, without any interaction from the user, so there is no password to enter or remember.

  29. The following describes how SSL works The SSL handshake consists of nine steps that authenticate the two parties and create a shared session key.

  30. 1.The client (that is, browser) opens a connection to the server port and sends a “ClientHello” message. "ClientHello" lists the capabilities of the client, including the version of SSL it uses, the cipher suites it supports, and the data compression methods it supports. • 2.    The server responds with a "ServerHello" message. The server returns a message that contains the cipher suite and data compression method it has chosen, along with a session ID that identifies the connection. Note that the server is responsible for choosing the cipher suite and compres­sion methods. If there is no match between the suites supported by the client and server, then the server sends a “handshake failure” message and hangs up.

  31. 3.   The server sends its certificate. If the server is using certificate‑based authentication (which is currently almost always the case), the server sends its signed X.5090 site certificate. If the certificate is signed by a non‑root certifying authority, the server also sends the chain of signed certificates that lead up to the primary CA. 4. The server sends a client certificate request (optional). If client certifi­cates are used for client authentication (currently rare but likely to be seen more often in the future), the server next sends the client a certificate request message. 5. The client sends its certificate (optional). If the server has requested it, the client returns its signed X.5090 client certificate. If the client has no certificate, it sends a "'no certificate" alert. The server may choose to abort at this point with a handshake failure, or continue onward.

  32. 6. The client sends a "ClientKeyExchange" message. This is where the symmetric session key is selected. The details vary depending on the cipher suite chosen, but in the most typical case, the client generates a pre­master secret using a good random‑number generator. This secret will be used on both the client and the server sides to generate the true master secret that is used as the session key (because different symmetric ciphers use different‑length keys, the session key is not generated directly). The browser encrypts the secret using the server's RSA public key (recovered from the server's certificate) to create a digital envelope. The envelope is now forwarded to the server.

  33. 7.    The client sends a “CertificateVerify” message (optional). If client authentication is in use, the client must authenticate itself to the server by proving that it knows the correct RSA private key. The "Certificate­Verify" message consists of the premaster secret generated in step 6, which has been manipulated in various ways to make it harder to tam­per with by someone listening in on the conversation. The secret is signed with the client's RSA private key and forwarded to the server, which proceeds to check it for validity against the client's certificate. Notice that the server doesn't have to prove its identity. Because the client sends the premaster secret to the server using the server's public key, only the legitimate holder of the server's certificate can decrypt and use it.

  34. 8.   Both client and server send a “ChangeCipherSpec” message. This is a simple message that confirms that both client and server are ready to start communicating using the agreed‑on symmetric cipher and session key. • 9. Both client and server send "finished" messages. These messages con­sist of MD5 and SHA hashes of the entire conversation up to this point and allow both parties to confirm that their messages were received intact and not tampered with en route. • At this point, both client and server switch into encrypted mode, using the session key (generated from the premaster secret) to symmetrically encrypt subsequent transmissions in both directions.

  35. 5.5 Secure Electronic Transaction (SET) • The SET protocol involves four parties: the cardholder, the merchant, the bank that issues the credit card, and the merchant's bank. Like other encrypting protocols, SET uses public/private key pairs and signed certificates to establish each play­er's identity and to allow them to send private messages to one another.

  36. The following describes how SET works: The SET protocol coordinates the activities of the customers, merchant, merchant’s bank, and card issuer

  37. 1. The customer initiates a purchase. The customer browses the merchan­t's Web site, decides she wants to buy something, and fills out an order form containing the description of the merchandise and shipping infor­mation. This is all done before the SET protocol starts by using CGI scripts or other server‑side software. The SET protocol begins when the user presses a "pay" button. The server now sends the customer's computer a message that launch­es SET software on her personal computer.

  38. 2. The client.'s software sends the order and payment information. The customer's SET software creates two messages. The first message contains order information consisting of the total purchase price and the order number. The second message is payment information that consists of the customer's credit card number and bank information. The order information is encrypted using a random symmetric session key and packaged into a digital envelope using the merchant's public key. The payment information is likewise encrypted, but this time using the merchant's bank's public key. This prevents the merchant from peeking at the credit card number or the bank from peeking at the order information. The software now computes a hash of the order and payment infor­mation jointly and signs it with the customer's private key. This creates a ""dual signature" that allows both merchant and merchant's bank to val­idate the integrity of both messages without being able to read the part addressed to the other party.

  39. 3. The merchant passes payment information to the bank. SET software on the merchant's Web server generates an authorization request, for­warding the customer's payment information to a SET server maintained by the merchant's bank (or more likely, a ""payment gateway" working on behalf of the bank). The merchant signs a hash of the authorization request with its private key in order to prove its identity to the bank. This request is encrypted with a new random session key and incorporated into a digital envelope using the bank's public key.

  40. 4. The bank checks the validity of the card. The bank decrypts the mer­chant's authorization request and verifies the merchant's identity. It then decrypts the customer's payment information and verifies the customer's identity. Now the merchant's bank needs to check with the customer's bank for authorization. It generates its own authorizaton request, signs it, and forwards it to the card issuer. • 5. The card issuer authorizes and signs the charge slip. The customer's bank confirms the merchant's bank identity, decrypts the information, and checks the customers account. If the account is in good standing, the card issuer approves the authorization request by signing it and return­ing it to the merchant's bank.

  41. 6.  The merchant's bank authorizes the transaction. The merchant's bank now authorizes the transaction and signs it, sending the OK back to the merchant's Web server. • 7.   The merchant's Web server completes the transaction. The merchant's Web server acknowledges that the card was approved by showing the customer a confirmation page and then enters the order into the mer­chant's order processing system. In due course, the merchant ships the goods or provides the service.

  42. 8. The merchant "captures" the transaction. In the final phase of a typical SET interaction, the merchant sends a "capture"' message to its bank. This con­firms the purchase and causes the customer's credit card account to be charged. The merchant's checking account will be credited. • 9. The card issuer sends a credit card bill to the customer. The SET charge appears on the customer's monthly statement, along with other charges.

  43. 5.7 References SET demonstration: http://www.globeset.com/aboutset.com SSL demonstration: http://www.modssl.org.org/docs/ecrc1999/slide-004.html

More Related