Internet Security - Dang Thanh Binh's Page

More documents

Recommendations

Info

TCP/IP SUITE AND INTERNET STACK PROTOCOLS 39 Source routing: The source routing extension header combines the concepts of the strict source route and the loose source route options of IPv4. The source routing extension is used when the source wants to specify the transmission path. The source routing header contains a minimum of seven fields which are expressed in a unified form as follows: – The next header and header length are identical to that of hop-by-hop extension header. – The type field defines loose or strict routing. – The address left field indicates the number of hops still needed to reach the destination. – The strict/loose mask field determines the rigidity of routing. – The destination address in source routing changes from router to router. The fragmentation extension is used if the payload is a fragment of a message. The concept of fragmentation is the same as that in IPv4 except that where fragmentation takes place differs. In IPv4, the source or router is required to fragment if the size of the datagram is larger than the MTU of the network. In IPv6, only the original source can fragment using the Path MTU Discovery technique. If the source does not use this technique, it should fragment the datagram to a size of 576 bytes or smaller, which is the minimum size of MTU required for each network connected to the <strong>Internet</strong>. Encrypted <strong>Security</strong> Payload (ESP): The ESP is an extension that provides confidentiality between sender and receiver and guards against eavesdropping. The ESP format contains the security parameter index field and the encrypted data field. The security parameter index field is a 32-bit word that defines the type of encryption/decryption used. The encrypted data field contains the data being encrypted along with any extra parameters needed by the algorithm. Encryption can be implemented in two ways: transport mode and tunnel mode, as shown in Figure 2.9. The transport-mode method encrypts TCP or UDP Datagram Base header Extension headers IP Datagram Key Encryption Base header Extension headers SPI Encrypted data (Encapsulated in an IPv6 packet) (a) Transport-mode encryption Key New IPv6 header Encryption Encrypted packet (Encapsulated in an IPv6 packet) (b) Tunnel-mode encryption Figure 2.9 Encrypted security payload.
40 INTERNET SECURITY a TCP segment or UDP user datagram first and then encapsulated along with its base header, extension headers and security parameter index (SPI) as shown in Figure 2.9(a). The tunnel-mode method encrypts the entire IP datagram together with its base header and extension headers and then encapsulates it in a new IP packet as shown in Figure 2.9(b). The authentication extension validates the sender of the message and protects the data from hackers. The authentication extension field has a dual purpose: sender identification and data integrity. The sender verification is needed because the receiver can be sure that a message is from the genuine sender and not from an imposter. The data integrity is needed to check that the data is not altered in transition by some hackers. The format of authentication extension header consists of the security parameter index field and the authentication data field. The former defines the algorithm used for authentication, and the latter contains the actual data generated by the algorithm. The destination extension passes information from the source to the destination exclusively. This header contains optional information to be examined by the destination mode. It is worth comparing the options in IPv4 with the extension headers in IPv6. 1. The record route option in IPv4 is not used in IPv6. 2. The timestamp option in IPv4 is not implemented in IPv6. 3. The source router option in IPv4 is called the source route extension header in IPv6. 4. The fragmentation fields in the base header section of IPv4 have moved to the fragmentation extension header in IPv6. 5. The encrypted security payload extension header is new in IPv6. TEAMFLY • Hop limit: This eight-bit hop limit field decrements by 1 each node that forwards the packet. The packet is discarded if the hop limit is decremented to zero. This field serves the same purpose as the TTL field in IPv4. IPv6 interprets the value as giving a strict bound on the maximum number of hops a datagram can make before being discarded. • Source address: The source address field is a 128-bit originator address that identifies the initial sender of the packet. • Destination address: The destination address field specifies a 128-bit recipient address that usually identifies the final destination of the datagram. However, if source routing is used, this field contains the address of the next router. To summarise, each IPv6 datagram begins with a 40-octet base header that includes fields for the source and destination addresses, the maximum hop limit, the traffic class (priority), the flow label and the type of the next header. Thus, an IPv6 datagram should contain at least 40 octets in addition to the data. 2.1.5.3 Comparison between IPv4 and IPv6 Headers Despite many conceptual similarities, IPv6 changes most of the protocol scopes. Most important, IPv6 completely revises the datagram format by replacing IPv4’s variablelength options field with a series of fixed-format headers. A comparison between IPv4 and IPv6 headers will be examined in the following section. Team-Fly ®
Page 1 and 2:
TEAMFLY
Page 4:
Internet Security
Page 7 and 8:
Copyright © 2003 John Wiley & Sons
Page 9 and 10: vi CONTENTS 2.3 World Wide Web 47 2
Page 11 and 12: viii CONTENTS 5.6 The Elliptic Curv
Page 13 and 14: x CONTENTS 10.2.5 De-militarised Zo
Page 16 and 17: Preface The Internet is global in s
Page 18 and 19: PREFACE xv Policy Approval Authorit
Page 20 and 21: PREFACE xvii classified into three
Page 22 and 23: 1 Internetworking and Layered Model
Page 24 and 25: INTERNETWORKING AND LAYERED MODELS
Page 30 and 31: Layer No. 7 6 5 4 3 2 1 OSI Layer A
Page 36 and 37: 2 TCP/IP Suite and Internet Stack P
Page 38 and 39: TCP/IP SUITE AND INTERNET STACK PRO
Page 46 and 47: Class A Class B Class C Class D Cla
Page 50 and 51: H Host H TCP/IP SUITE AND INTERNET
Page 64 and 65: Bits IP header TCP/IP SUITE AND INT
Page 78 and 79: 3 Symmetric Block Ciphers This chap
Page 80 and 81: S-boxes L i−1 S 1 L i SYMMETRIC B
Page 82 and 83: K 1 48 bits K 2 48 bits K 16 48 bit
Page 84 and 85: Table 3.4 Initial permutation (IP)
Page 86 and 87: SYMMETRIC BLOCK CIPHERS 65 Table 3.
Page 88 and 89: SYMMETRIC BLOCK CIPHERS 67 This 48-
Page 90 and 91: SYMMETRIC BLOCK CIPHERS 69 The 48-b
Page 92 and 93: SYMMETRIC BLOCK CIPHERS 71 Thus, th
Page 94 and 95: SYMMETRIC BLOCK CIPHERS 73 Round K1
Page 96 and 97: SYMMETRIC BLOCK CIPHERS 75 Example
Page 98 and 99: 64-bit plaintext X 1 X 2 X 3 X 4 Ro
Page 102 and 103: SYMMETRIC BLOCK CIPHERS 81 The outp
Page 104 and 105: SYMMETRIC BLOCK CIPHERS 83 the corr
Page 108 and 109: SYMMETRIC BLOCK CIPHERS 87 of S and
Page 110 and 111:
Step 3 i = j = 0; A = B = 0; SYMMET
Page 112 and 113:
3.3.3 Encryption SYMMETRIC BLOCK CI
Page 114 and 115:
A SYMMETRIC BLOCK CIPHERS 93 A B
Page 116 and 117:
3.4 RC6 Algorithm SYMMETRIC BLOCK C
Page 118 and 119:
Mixing in the secret key S A = B =
Page 120 and 121:
Magic constants: Pw = b7e15163 Qw =
Page 122 and 123:
A = ((A − S[2i]) >>> u) ⊕ t } D
Page 124 and 125:
Converting the secret key from byte
Page 126 and 127:
The final decrypted plaintext is: b
Page 128 and 129:
Thus, the final decrypted plaintext
Page 130 and 131:
Multiplication SYMMETRIC BLOCK CIPH
Page 132 and 133:
where c0 = a0b0 c1 = a1b0 ⊕ a0b1
Page 134 and 135:
Rcon[2] = [x 1 , {00}, {00}, {00}]
Page 136 and 137:
Table 3.16 AES key expansion i Temp
Page 138 and 139:
SYMMETRIC BLOCK CIPHERS 117 ShiftRo
Page 140 and 141:
Start of round After SubByte SYMMET
Page 142 and 143:
SYMMETRIC BLOCK CIPHERS 121 Figure
Page 144 and 145:
4 Hash Function, Message Digest and
Page 146 and 147:
M = 64 bits C 0 = 28 bits D 0 = 28
Page 148 and 149:
HASH FUNCTION, MESSAGE DIGEST AND H
Page 150 and 151:
⊕ : Bit-by-bit XORing of 16-bit s
Page 152 and 153:
P(Ω 1 )
Page 154 and 155:
Page 156 and 157:
K r : Concatenation IP : Initial pe
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
a b c d HASH FUNCTION, MESSAGE DIGE
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
H2 = 98badcfe H3 = 10325476 H4 = c3
Page 176 and 177:
Page 178 and 179:
opad 160 bits (SHA-1) 128 bits (MD5
Page 180 and 181:
Page 182 and 183:
5 Asymmetric Public-key Cryptosyste
Page 184 and 185:
User A Generate secret random integ
Page 186 and 187:
ASYMMETRIC PUBLIC-KEY CRYPTOSYSTEMS
Page 188 and 189:
Message m −1 E p q ASYMMETRIC PUB
Page 190 and 191:
Page 192 and 193:
Message m −1 User A A′ private
Page 194 and 195:
Page 196 and 197:
To decipher the message m, first co
Page 198 and 199:
Page 200 and 201:
Page 202 and 203:
a q ≡ 1(modp) a ASYMMETRIC PUBLIC
Page 204 and 205:
Page 206 and 207:
Page 208 and 209:
Receiver: (verifying) Compute: w
Page 210 and 211:
� y2 − y1 x3 = ASYMMETRIC PUBLI
Page 212 and 213:
The square of the integers in Z ∗
Page 214 and 215:
Page 216 and 217:
and y3 = x2 1 + � x1 + y1 = α 12
Page 218 and 219:
Page 220 and 221:
Page 222 and 223:
6 Public-key Infrastructure This ch
Page 224 and 225:
PUBLIC-KEY INFRASTRUCTURE 203 LDAP
Page 226 and 227:
Session key DES Plaintext m One-way
Page 228 and 229:
PUBLIC-KEY INFRASTRUCTURE 207 Let u
Page 230 and 231:
PUBLIC-KEY INFRASTRUCTURE 209 sent
Page 232 and 233:
Publication of PAA’s public key G
Page 234 and 235:
PUBLIC-KEY INFRASTRUCTURE 213 • P
Page 236 and 237:
Carry out identification and authen
Page 238 and 239:
PUBLIC-KEY INFRASTRUCTURE 217 With
Page 240 and 241:
PUBLIC-KEY INFRASTRUCTURE 219 The s
Page 242 and 243:
6.4.4 X.500 Distinguished Naming PU
Page 244 and 245:
PUBLIC-KEY INFRASTRUCTURE 223 certi
Page 246 and 247:
PUBLIC-KEY INFRASTRUCTURE 225 • I
Page 248 and 249:
Certificate fields v1 = v2 = v3 (fo
Page 250 and 251:
PUBLIC-KEY INFRASTRUCTURE 229 CRL s
Page 252 and 253:
Subject directory attributes extens
Page 254 and 255:
PUBLIC-KEY INFRASTRUCTURE 233 the s
Page 256 and 257:
PUBLIC-KEY INFRASTRUCTURE 235 • S
Page 258 and 259:
PUBLIC-KEY INFRASTRUCTURE 237 not h
Page 260 and 261:
6.7.1 Basic Path Validation PUBLIC-
Page 262:
PUBLIC-KEY INFRASTRUCTURE 241 It is
Page 265 and 266:
244 INTERNET SECURITY The set of se
Page 267 and 268:
246 INTERNET SECURITY • Key manag
Page 269 and 270:
248 INTERNET SECURITY 7.1.3 Hashed
Page 271 and 272:
250 INTERNET SECURITY A B C D IV 67
Page 273 and 274:
252 INTERNET SECURITY Next header (
Page 275 and 276:
254 INTERNET SECURITY IPv4 IPv4 IPv
Page 277 and 278:
256 INTERNET SECURITY within a 32-b
Page 279 and 280:
258 INTERNET SECURITY addresses, wh
Page 281 and 282:
260 INTERNET SECURITY If authentica
Page 283 and 284:
262 INTERNET SECURITY 1 bit Next pa
Page 285 and 286:
264 INTERNET SECURITY The Situation
Page 287 and 288:
266 INTERNET SECURITY The Identific
Page 289 and 290:
268 INTERNET SECURITY The Hash Data
Page 291 and 292:
270 INTERNET SECURITY The Domain of
Page 293 and 294:
272 INTERNET SECURITY to the exchan
Page 295 and 296:
274 INTERNET SECURITY When a Key Ex
Page 297 and 298:
276 INTERNET SECURITY When a Notifi
Page 299 and 300:
278 INTERNET SECURITY SSL Handshake
Page 301 and 302:
280 INTERNET SECURITY SSL record he
Page 303 and 304:
282 INTERNET SECURITY SSLCompressed
Page 305 and 306:
284 INTERNET SECURITY • bad-certi
Page 307 and 308:
286 INTERNET SECURITY - Random: Thi
Page 309 and 310:
288 INTERNET SECURITY Note that Dis
Page 311 and 312:
290 INTERNET SECURITY The finished
Page 313 and 314:
292 INTERNET SECURITY key_block = M
Page 315 and 316:
294 INTERNET SECURITY opad 160 bits
Page 317 and 318:
296 INTERNET SECURITY - A B C D IV
Page 319 and 320:
298 INTERNET SECURITY The PRF is th
Page 321 and 322:
300 INTERNET SECURITY HMAC SHA1(S2,
Page 323 and 324:
302 INTERNET SECURITY 8.3.4 Certifi
Page 326 and 327:
9 Electronic Mail Security: PGP, S/
Page 328 and 329:
ELECTRONIC MAIL SECURITY: PGP, S/MI
Page 330 and 331:
Page 332 and 333:
Page 334 and 335:
Page 336 and 337:
Page 338 and 339:
Page 340 and 341:
Message packet M T FN H(M) ELECTRON
Page 342 and 343:
Page 344 and 345:
Page 346 and 347:
Page 348 and 349:
Definition of multipart/encrypted:
Page 350 and 351:
From: myrhee@tsp.snu.ac.kr To: kiis
Page 352 and 353:
Page 354 and 355:
SignatureAlgorithmIdentifier ELECTR
Page 356 and 357:
Page 358:
Page 361 and 362:
340 INTERNET SECURITY conform to a
Page 363 and 364:
342 INTERNET SECURITY existing on a
Page 365 and 366:
344 INTERNET SECURITY 10.2.7 VPN So
Page 367 and 368:
346 INTERNET SECURITY Table 10.1 Te
Page 369 and 370:
348 INTERNET SECURITY Table 10.3 SM
Page 371 and 372:
350 INTERNET SECURITY Outside host
Page 373 and 374:
352 INTERNET SECURITY Internet Pack
Page 376 and 377:
11 SET for E-commerce Transactions
Page 378 and 379:
11.2 SET System Participants SET FO
Page 380 and 381:
SET FOR E-COMMERCE TRANSACTIONS 359
Page 382 and 383:
Page 384 and 385:
Page 386 and 387:
Example 11.2 Message Integrity Chec
Page 388 and 389:
User A 0x135af247c613e815 Message d
Page 390 and 391:
Page 392 and 393:
E KSC (CAC) + E KSC (MD) D CAC MD V
Page 394 and 395:
Page 396 and 397:
Page 398:
H MD D CRs K pg M’s cert E K#5 (C
Page 401 and 402:
380 INTERNET SECURITY DS Dual Signa
Page 403 and 404:
382 INTERNET SECURITY SA Security A
Page 405 and 406:
384 INTERNET SECURITY 17. Borman, D
Page 407 and 408:
386 INTERNET SECURITY 60. Harkins,
Page 409 and 410:
388 INTERNET SECURITY 106. Metzger,
Page 411 and 412:
390 INTERNET SECURITY 163. Wijnen,
Page 413 and 414:
392 INDEX Authentication Header 243
Page 415 and 416:
394 INDEX delete payload 269, 275,
Page 417 and 418:
396 INDEX HTML tag 49 ending tag 49
Page 419 and 420:
398 INDEX Java 48, 49 Joint Photogr
Page 421 and 422:
400 INDEX packet filter 339, 341, 3
Page 423 and 424:
402 INDEX secure payment processing
Page 425 and 426:
404 INDEX transform # field 264, 27
show all

Internet Security - Dang Thanh Binh's Page

Create successful ePaper yourself

Delete template?

Save as template?