CSC 607 Meeting 4 Charts

CSC 607 Meeting 4 Charts - Security in Computing – CSC...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Security in Computing – CSC 607 Wireless Security – WCM 605 Meeting 4 Thursday, Jan 14, 2010 1/14/2010 1/14/2010 1 Week 2 Schedule Tue 1/12 30 minute quiz Network Security Securing email Network Security Protocols – Key Establishment & Authentication Form Teams for Week 2 Small Group Projects Thu 1/14 Week 1 Small Group Project Presentation Network Security Protocols –Encryption & Integrity Protocols Review for Mid­Term Exam Week 2 Reading – Pfleeger & Pfleeger 4th Edition Chapters 2 and 7 Chandra Chapter 2 (all) and Chapter 3, pp 67­75 Written Assignment A due by midnight, Saturday, Jan 17 1/14/2010 1/14/2010 2 Improved Password Protocol <User ID, Hash(Password)> = pairs stored Accessible only by System Administrator No actual passwords stored • Only hashes are stored Protocol 1. User enters <ID, Password> pair 2. Node computes hash of password 3. System checks hash against stored file 4. Pass or fail returned •Big improvement, BUT … •Still open to Dictionary Attack 1/12/2010 1/12/2010 3 Offline Attacks • 1. 2. • 3. 4. Example: Dictionary Attack Assumes most passwords can be found in a dictionary Find the hash function being used Compute the hash of every word in the dictionary This step done off line, in advance Get access to <ID, hash(password)> file Search for and find match(es) Processing­intensive part of the attack is done off line 1/12/2010 1/12/2010 4 Response to Dictionary Attack <User ID, Hash(Salt +Password), Salt> = triplets stored Salt = n­bit random number No actual passwords stored • Protocol 1. 2. 3. 4. 1/12/2010 1/12/2010 Only hashes are stored User enters <ID, Password> pair Node gets salt for ID, and computes hash (salt + password provided by user) System checks hash against stored file Pass or fail returned 5 In Class Exercise In 1/12/2010 User ID = RAJ Length of Salt: n=2. What are the 4 possible salt values? Password = 00111 What are the (password + salt) values? Hash (Password + Salt) = Last four bits of (Password + Salt) (not a very good hash function) User sends User ID, password pair Systems looks up salt value of for that user ID, password and finds salt = 11, computes hash (salt + password) What match will the system find for Hash of Salt + Password? Is the password stored anywhere in the system? 6 Answer to In Class Exercise Answer 1/12/2010 User ID = RAJ Length of Salt: n=2. What are the possible salt values? (00, 01, 10, 11) Password = 00111 What are the (password + salt) values Password + 00 = 00111 Password + 01 = 01000 Password + 10 = 01001 Password + 11 = 01010 Hash (Password + Salt) = Last four bits of Password + Salt (not a very good hash function) User sends User ID, password pair Systems looks up salt value of for that (user ID, password) and finds salt = 11, and computes salt + password = 01010 Hash (Salt + Password) = 1010 No. The password is not stored anywhere in the system; Only the values of Hash (salt + password) are stored. 7 What “Salt” Does to the Attacker Example: Dictionary Attack Attacker does not know value of salt in advance • Attacker must now compute hash(all possible salts + all words in dictionary) Computation is 2n more complex • 1/12/2010 1/12/2010 May want to add a bit to n every 2 years (Moore’s Law) 8 Passwords for Network Authentication Differs from passwords for local login • Cannot send hashed password across net Could be used to launch dictionary off­line attack 1. Username: Alice 2. Salt: 987654321 3. Hash(Pswd+Salt) 4. Success or Failure (Alice) (Bob) •Vulnerable because: 1/14/2010 1/14/2010 •Salt transmitted as plaintext •Eve can intercept and use for dictionary attack (offline) 9 Network Authentication Password Network Principles Principles • Passwords are a “seed” for deriving keys Keys are used in a challenge/response system One mechanism for converting password to a key: 1. 2. Take hash of password Use a subset of the hash as the key • • Key can be derived ONLY from password NEVER transmit password or its hash (key) • 1/14/2010 1/14/2010 Security of system depends on: Why use passwords at all? Easier to remember than long alphanumeric string 10 One Way Authentication Using SKC 1. Username: Alice 2. Challenge: Random No. 3. Response: EKAB(Random No.) 4. Success or Failure (Alice) 1/14/2010 1/14/2010 (Bob) Based on shared secret KAB So long as only A and B know the secret, B can be sure he is communicating with A One way hash function can be used instead of KAB 11 SKC One Way Authentication Variation 1. Username: Alice 2. Challenge: EKAB(Random No.) 3. Response: Random No. 4. Success or Failure (Alice) 1/14/2010 1/14/2010 (Bob) Based on shared secret KAB So long as only A and B know the secret, B can be sure he is communicating with A One way hash function CANNOT be used instead of KAB 12 SKC One Way Authentication Variation 2 1. (Alice) 2. Success or Failure (Bob) Pros • • • Username: Alice + EKAB(Timestamp) Reduces number of messages exchanged Attractive option for backward compatibility with “no exchange systems B can be stateless – deters DOS attacks Cons • A and B MUST be synchronized in time (non­trivial) • System security depends on time­synch 1/14/2010 1/14/2010 Major vulnerability with stream ciphers: • Flipping 1 bit in ciphertext flips one bit in plaintext • Attacker tries approximate timestamp, flipping millisecond bits to get within allowed skew of network­time protocol 13 Mutual Authentication Using SKC 1. 2. (Alice) Username: Alice Challenge: Random No. 1 Response: EKAB(RN#2) 6. 1/14/2010 1/14/2010 Challenge: RN #2 5. Response: EKAB(Random No. 1) 4. 3. (Bob) Success/Failure Biggest Drawback: Requires 5 messages! Inefficient in use of bandwidth 14 SKC Mutual Authentication: Reduced SKC Messages Messages 1. (Alice) 2. Username: Alice Challenge RN#2 Challenge: Random No. 1 Response: EKAB(RN#2) 3. 1/14/2010 1/14/2010 Response: EKAB(Random No. 1) 4. (Bob) Success/Failure Reduces number of required messages to 3, but … Opens system to reflection attack 15 Reflection Attack (Alice) E sends 1. 2. E sends B re­ sponds to own challenge 3. 4. Username: Alice Challenge RN#2 Challenge: Random No. 1 Response: EKAB(RN#2) Username: Alice Challenge RN#1 Challenge: Random No. 3 Response: EKAB(RN#1) 5. 6. 1/14/2010 1/14/2010 Response: EKAB(Random No. 1) Success (Bob) Session 1 B thinks 1. came from A Session 2 Session 1 (resumed) E gets Bob to respond to his own challenge Policies to defeat: Allow only one session/client OR • Use different formats for A­>B and B­>A challenges • Use different keys for each direction 16 Lamport’s Hash (Alice) 1. 2. 3. 4. (Bob) Username: Alice Challenge: Random#1 Current value m (m= integer) Response: HKm­1AB(Random#1)* If match, send Success & Bob reduces m by one Bob hashes once & com­ pares with stored value B (or KDC) stores <username, hashraise(password)> Initially raise = m is large, say 1000 Recongifure B by Sys Admin when m reaches 1 A must change password when m reaches 1 • Alternative: use salt value along with password, and auto reset m to 1000 Note: Mutual Authentication is not possible 1/14/2010 1/14/2010 *HKm­1AB(Random#1) = hash of R#1 computed m­1 times 17 One Way Authentication Using PKC (Alice) (Bob) 1. 2. 1/14/2010 1/14/2010 Response: EKApriv(R#) 4. Challenge: Random No. 3. Username: Alice Success or Failure B decrypts with KApub B stores only public keys Similar alternatives to those discussed for SKC 18 Mutual Authentication Using PKC (Alice) 1. 2. Response: EKApriv(R#1) 4. 5. (Bob) Challenge: RN #2 Response: EKBpriv(RN#2) 6. Challenge: R#1 3. A decrypts with KBpub Username: Alice Success/Failure B decrypts with KApub Almost the same as for SKC mutual authentication • Logical substitution of public/private keys for shared key 1/14/2010 1/14/2010 19 Comparison of SKC vs. PKC for Comparison Authentication Authentication SKC Pros • Much less computation required Cheaper and lighter More resilient to DoS attacks SKC Cons • More memory intensive B must store all keys or use a Key Distribution Ctr Eavesdropper can capture <plaintext, ciphertext> pairs and use for dictionary attacks PKC Pros • Doesn't have SKC’s Cons PKC Cons • Computationally intensive Issue for portable devices • More vulnerable to DoS attacks, because system is more stateful 1/14/2010 1/14/2010 20 Session Hijacking (SKC) (Eve) (Alice) (Bob) 1. ID: Alice 1. ID: Alice 2. Challenge: R#1 2. Challenge: R#1 Response: EKAB(R#1) 3. 3. 4. Failure 4. Response: EKAB(R#1) Success Circumvents authentication protocol instead of breaking it Eve blocks all “Success” messages from Bob to Alice • Simple DoS attack 1/14/2010 1/14/2010 Eve successfully claims to be Alice 21 Session Hijacking (SKC) (Eve) (Alice) (Bob) 1. ID: Alice 1. ID: Alice 2. Challenge: R#1 2. Challenge: R#1 Response: EKAB(R#1) 3. 3. 4. Success 4. Response: EKAB(R#1) Success E blocks all messages from B Eve hijacks the session successfully • “Success” message from B is passed to A • A and B don’t know they are not talking to each other 1/14/2010 1/14/2010 Eve successfully claims to be Bob 22 Establishing a Security Context Session highjacking can be defeated • Link authentication protocol to remainder of session • Generate a secret shared session key at both ends (A and B), used only for one session • Encrypt EVERY message sent by A or B with secret shared session key Two Names: •Context Establishing Authentication Protocols OR •Key­Generating Authentication Protocols 1/14/2010 1/14/2010 23 Two Standardized SKC Two Authentication Protocols Authentication 1/14/2010 1/14/2010 Needham Schroeder Kerberos 24 Needham Schroeder (SKC) (Alice) (KDC) N1, “A2B” 1. EKA{N1,”B”, KAB, ticket} Note: ticket = EKB{KAB, “A”} 2. B decrypts 3. using KB to get KAB and “A”, then uses KAB to get N2 KB = B’s secret key, known only by B and KDC KAB=Secret Session Key • • 1/14/2010 1/14/2010 (Bob) KA = A’s secret key known only by A and KDC A decrypts 2. to get N1, KAB, “B”, and the ticket, then sends Ticket+EKAB{N2} 1. EKAB{ N2­1,N3} 2. EKAB{N3­1} 3. 4. And 5. ensure to A and B that they are only talking to each other Can be known ONLY by A and B Used through remainder of the session for exchange of information between A and B N1, N2 and N3 are “Nonces” – numbers that can be used only once 25 Kerberos Support authentication in distributed systems Originally designed to work with Symmetric Key Cryptography (SKC) • Designed at Massachusetts Institute of Technology (MIT) Latest version uses Public Key Cryptography (PKC) to support key exchange • Textbook shows only SKC version Provides authentication between intelligent processes • • • 1/14/2010 1/14/2010 Client/Server Workstation/Host Based on central server providing authenticated tokens (tickets) to requesting applications 26 Initiating a Kerberos Session 7. EKA{SA, Ticket } * 2. Workstation Send ID “A” Ticket Granting Server (TGS) st T ick et User A Workstation 8. Workstation Prompts A for pass­word and computes KA from pw to decrypt 6. and get SA and Ticket 6a . R eq ue 1. User types “A” Kerberos Server (KS) 3. KS verifies that “A” is authorized 4. KS generates SA and a Ticket 5. KS Encrypts {SA + Ticket*} with users Key KA 1/14/2010 1/14/2010 6b. Ticket = en­ crypted copy of A’s session key, SA, bound to user ID “A” (en­crypted with key shared only by KS and TGS, KKG) •Keys of all users are stored only at KS •SA is generated by KS ­ Unique for each session ­ Not stored at KS •KA is based algorithmically on users password * Only SA is encrypted in Kerberos Version 5 (PKC version) 27 Using a Kerberos (SKC) Ticket (A) (WS) “I want to talk to B” 1. 1. 2. “A2B”, Ticket, ESA{timestamp} (KS) ESA{”B”, KAB, B’s ticket} Note: ticket = EKB{“A”, KAB} B’s Ticket, EKAB {timestamp} 2. Kerberos Server decrypts ticket using KKG to get Ticket and uses SA to get Timestamp 3. KS generates unique key for this A/B session, KAB, and generates Bob’s ticket EKB{“A”, KAB} 6. B decrypts 5. using KB to get KAB and “A”, then uses KAB to generate timestamp 1. EKAB{Timestamp+1} B is sure it is talking with A because: • • • 1/14/2010 1/14/2010 (B) Only KS could send a valid ticket to B Tickets have a validity limited by time Since ticket is valid, KAB must also be valid • • only A, B and KS could know KAB used to decrypt timestamp Tickets have a validity limited by time A is sure it is talking with B, because: 28 Kerberos Summary Strengths • • • • • • • • • • • • 1/14/2010 1/14/2010 No passwords communicated over network Cryptographic protection against spoofing Limited time validity of tickets Timestamps prevent replay attacks Mutual authentication Ticket Granting Authority must always be available Strong trust relationship between TGS and all KSs must exist Transactions must be timely A subverted workstation could save and replay user passwords Password guessing could work Kerberos does not scale well ALL applications must use Kerberos for it to provide the intended protection Potential Issues 29 Encryption Protocols 1/14/2010 1/14/2010 30 Shannon’s Characteristics of Shannon’s “Good” Ciphers (1949) “Good” 1. 2. 3. 4. 5. The amount of secrecy needed should determine the amount of labor appropriate for encryption and decryption The set of keys and the enciphering algorithm should be free from complexity The implementation process should be as simple as possible* Errors in ciphering should not propagate and cause corruption of further information in the message The size of the enciphered text should be no larger than the text of the original message Pre­computer Principle * 1/7/2010 1/7/2010 31 Properties of Trustworthy Properties Encryption Systems Encryption Based on Sound Mathematics Analyzed by competent experts and found to be sound Have stood the test of time Three popular, commercial algorithms: DES (Data Encryption Standard) RSA (Rivest­Shamir­Adelman) AES (Advanced Encryption Standard) We’ll come back to these next week … 1/7/2010 1/7/2010 32 How Secure is Cryptography? Two basic ingredients • Algorithm • Keys Both ingredients need to be “strong” Strength of algorithm depends on: • How it encrypts • How it is used (the mode) Strength of key depends on: • • • • • • 1/7/2010 1/7/2010 How long the key is How long the key is in use (time) How the key is generated How keys are exchanged How keys are stored … 33 Key length considerations For a given cipher, key length is a measure of strength Example: 3 bit key 8 possible keys • For known plaintext, encrypt with all eight keys • The result that matches the ciphertext is the correct key Successful system makes attack more costly than the data is worth • Keep Moore’s Law in mind • “Safe key length” increases as computer power increases Simple exercise: How many possible combinations are there for a 12 bit key? • a) 1024, b) 2048, c) 4096 1/7/2010 1/7/2010 34 Encryption Protocols 1/14/2010 1/14/2010 Data Encryption Standard (DES) Advanced Encryption Standard (AES) RC4 35 Encryption Protocols – Desirable Encryption Properties Properties 1/14/2010 1/14/2010 It should be very hard to get plaintext from ciphertext unless you know the key It should be quite easy to get plaintext from ciphertext if you know the key A good encryption protocol should hide patterns in the plaintext Changing a single bit in the plaintext should change large number of bits in the ciphertext (diffusion) Changing one bit in plaintext should change (apparently) unrelated set of bits in ciphertext (confusion) 36 The Data Encryption Standard (DES) A careful and complex combination of substitution and transposition Repeated application of the two techniques on top of each other through 16 cycles Starts by encrypting plaintext as blocks of 64 bits Uses a 64 bit key (but only a 56 bit number) Officially adopted as a U.S. federal standard in 1976 Controversial since adopted • 1997 – 3500 machines used in parallel to infer a DES key in 4 months • 1998 ­ $100,000 DES cracker machine took four days to find a DES key 1/14/2010 1/14/2010 37 Example: One Block Cipher Round 64­bit input 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits S1 S2 S3 S4 S5 S6 S7 S8 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits Sn • Key­dependent substitution • Different for each key 64­bit intermediate value • Permuation • May be key dependent 64­bit output 1/14/2010 1/14/2010 Most encryption protocols have multiple rounds ­> Iterated block ciphers Multiple rounds ensure adequate amount of diffusion 38 DES Stage I Input Initial permutation L0 XOR R0 Mangler function + L1 Key = 56 bits + 8 parity bits K1 f R1=L0 + f(R0, K1) DES = specific case of Feistel Network with a specific mangler function 1/14/2010 1/14/2010 39 DES II Li Ri Ki+1 + f Li+1 … … Ri+1= Li + f(Ri, Ki+1) K16 + f R16= L15 + f(R15, K16) L16 = R15 R16 Initial Inverse Permutation Output 1/14/2010 1/14/2010 40 DES Drawbacks Limited key size Complementary • If EK(P) = C then EK(P’)=C’ where C’ = bitwise inverse Bitwise inverse = substitute 0 for 1 and 1 for 0 • Brute force attack must only text 255 keys! 1/14/2010 1/14/2010 41 Unsuccessful Attempts to Solve DES Unsuccessful Limitations Limitations Double encryption with same key • Doubles time to encrypt and decrypt • Doesn’t add much security Double encryption with two different keys • Effectively makes key size 112 bits • Susceptible to Meet in the Middle Attacks (see textbook, p 57) 1/14/2010 1/14/2010 Not too practical when discovered, but was enough reason to stay away from this approach 42 Triple DES (3DES) Triple DES significantly enhances security of DES • C = E(k1, D(k2, E(k1, m))) • This is applied to a single block Can be used with “inner” or “outer” Cipher Block Chaining (CBC) • Effectively increases key to 112 bits 3DES is the “standard” commercial implementation of DES today 1/14/2010 1/14/2010 43 Possible 3DES Modes Possible Inside Chaining Outside chaining EK1 EK1 EK1 DK2 DK2 DK2 DK2 DK2 EK3 EK3 EK3 EK3 EK3 Error in block corrupts all future plaintext blocks • • Makes system more secure Prevents system from being self synchronizing 3X hardware possible • 1/14/2010 1/14/2010 EK1 EK3 EK1 DK2 EK1 Would be as fast as 1DES Standard for 3DES Implementations • • Not quite as secure Self synchronizing 3X harware not possible 44 Advanced Encryption Standard (AES) US Federal Information Processing Standard 197 Adopted for use by the US Government in December 2001 Responds to the ever increasing speed of computers The Rijndael algorithm • Strong mathematical foundations Primarily uses substitution, transposition, shift, exclusive OR, and addition Can use 128, 192 or 256 bit long keys Operates on 128 bit blocks 10, 12 or 14 rounds of four steps each • Fast • Easily implemented on simple processors 1/14/2010 1/14/2010 45 AES Step A and B Input = 128 bit block of 16 bytes Each byte, b0 through b15 = 8 bits b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12, b13, b14, b15 Reformat into State Matrix S00=b0 S10=b1 S20=b2 S30=b3 S01=b4 S11=b5 S21=b6 S31=b7 S02=b8 S12=b9 S22=b10 S32=b11 S03=b12 S13=b14 S23=b13 S33=b15 Expand 128 bit key into eleven 128 bit key­numbers K0, K1, K2, K3, K4, K5, K6, K7, K8, K9, K10 Think of each key number as four 32­bit values Substitute Bxy= S_Box[Sxy_high][Sxy_low], where S_Box is AES standard 16 byte X 16 byte table look­up 1/14/2010 1/14/2010 46 AES Step C C00=B03 C10=B13 S20=B23 C30=B33 C01=B02 C11=B12 C21=B22 C31=B32 C02=B01 C12=B11 C22=B21 C32=B31 C03=B00 C13=B10 C23=B20 C33=B30 B00 B10 B20 B30 B01 B11 B21 B31 B02 B12 B22 B32 B03 B13 B23 B33 Shift nth column n columns to the left 1/14/2010 1/14/2010 47 AES Steps D and E Step D: Matrix Multiplication Provides diffusion D00 D10 D20 D30 = 2 1 1 3 3 2 1 1 1 3 2 1 1 1 3 2 C00 C10 C20 C30 Step E – Rouding: XOR each column of D with a 32 bit value for the key for this round (K0 in first round) represented as a 4­ element array of 32 bits {E0c, E1c, E2c, E3c} = {D0c, D1c, D2c, D3c} XOR wr[c] 1/14/2010 1/14/2010 Output, E, becomes input to next round, for 10 rounds 48 The AES Algorithm: Summary 1/14/2010 1/14/2010 49 Comparison of AES and DES Dat e Block S ize DES AES 1976 1999 64 bit s 128 bit s 56 bit s 128, 192, 256 bit s Key Lengt h (ef f ect ive lengt h) (possibly more) S ubst it ut ion, permut atS ion it ut ion, shif t , ubst Encrypt ion primit ives bit mixing Crypt ographic primit ives Conf usion, dif f usion Conf usion, dif f usion Design Open Open Design rat ionale Closed Open S ecret S ecret , but accept ed open public comment S elect ion process IBM, enhanced by Independent Dut ch S ource NS A crypt ographers 1/14/2010 1/14/2010 50 RC4 Algorithm Important Encryption Protocol for Wireless Communications Works in Output Feedback Mode (OFB) Takes a shared secret key as input Generates a pseudorandom string independent of the plaintext No limit on the size of the key that can be used for input 1 byte key­byte generated for each byte in the plaintext Sender XORs plaintext byte by byte with the key­bytes Used extensively with GSM 1/14/2010 1/14/2010 51 Integrity Protocols 1/14/2010 1/14/2010 52 Cryptographic Hash Functions 1/14/2010 1/14/2010 Used to “seal” a file to ensure integrity of data in file One way function; easy to compute, hard to reverse Depends on all the bits in the file being sealed; a change in even a single bit will alter the checksum result 53 Integrity Protocols Used to ensure message integrity – NOT confidentiality Particularly important issue for the wireless environment • Bits can get flipped more easily in wireless Three key Integrity Protocols • CBC Residue • Cyclic Redundancy Check (CRC) Most powerful: CRC32 • Message Digests 1/14/2010 1/14/2010 54 Recall: Cipher Block Chaining Mode Pn Pn+1 XOR XOR XOR XOR XOR Ek Ek Ek Ek Ek Ek Cn­1 Cn Cn+1 P1 XOR XOR XOR XOR Ek Ek C1 … Ek IV P2 Pn­1 C2 … Pi = 64 bit block; Ci = 64 bit block; Ci=Ek(Pi XOR Ci­1) Each Ciphertext block depends on both Pi plus all previous plaintext blocks Biggest Advantages • Very difficult to attack 1/14/2010 1/14/2010 Biggest Disadvantage: Identical sessions still map to same ciphertext session • Messages that begin the same map to same ciphertext • Solution: Use a random Initialization Vector (IV) (64 bits) •Loophole: Flipping a bit in Ci flips the corresponding bit in Pi+1 •Message Integrity can still be a problem 55 CBC Residue P1 … XOR XOR XOR Ek IV P2 Ek C1 h1 C2 h2 Pn­1 XOR Pn Pn+1 XOR XOR Ek Ek Ek … hn­2 hn­1 … Cn­1 Cn hn hn+1 Ek Ek(optional) Ek Cn+1 Pi = 64 bit block; Ci = 64 bit block; Ci=Ek(Pi XOR Ci­1) Each Ciphertext block depends on both Pi plus all previous plaintext blocks Because of this dependency, the last block is a hash of the whole message Modification of any block will cause the last block to be out of synch • If so, the message has failed the integrity check 1/14/2010 1/14/2010 •If last block is out of synch with the rest of the message, message integrity has been compromised 56 Verifying Integrity • Basic techniques for verifying message integrity: •Parity checking •Cyclic redundancy checksum. 1/14/2010 1/14/2010 57 Parity Checks •Simple parity ­ If performing even parity, add a parity bit such that an even number of 1s are maintained. •If performing odd parity, add a parity bit such that an odd number of 1s are maintained. •Example, send 1001010 using even parity • 10010101 •Example, send 1001010 using odd parity • 10010100 •Example, send 1001011 using even parity • 10010110 •Example, send 1001011 using odd parity • 10010111 1/14/2010 1/14/2010 58 Parity Checks – Double Errors •What happens if the character 10010101 is sent and the first two 0s accidentally become two 1s? •Thus, the following character is received: 11110101. •Will there be a parity error? 1/14/2010 1/14/2010 59 Longitudinal Parity Longitudinal parity adds parity bit to each character then adds row of parity bits after block The row of parity bits is actually a parity bit for each “column” of characters Adds a great amount of redundancy to a block of characters. 1/14/2010 1/14/2010 60 Longitudinal Parity Limitations 1/14/2010 1/14/2010 61 Beyond Parity Checking •Both simple parity and longitudinal parity do not catch all errors. •Simple parity only catches odd numbers of bit errors. •Longitudinal parity is better at catching errors but requires too many check bits added to a block of data. •Much better error detection method = Cyclic Redundancy Checksum (CRC) 1/14/2010 1/14/2010 62 Cyclic Redundancy Checksum (CRC) •CRC error detection treats packet of data to be transmitted as large polynomial. •Example: 1011 = 1 X 23 + 0 X 22 + 1 X 21 + 1 X 20 •The transmitter takes the message polynomial and divides it by a given generating polynomial •Text discusses CRC­32. Other common generating polynomials include CRC­12, CRC 16, and CRC­CCITT •Computing the remainder from Binary Division is equivalent to using an Exclusive OR (XOR) •1/1 Divides evenly – no remainder •1 XOR 1 = 0 (no remainder) •The quotient is discarded but the remainder is “attached” to the end of the message. 1/14/2010 1/14/2010 63 In-Class Exercise In-Class 1/14/2010 Write the polynomial representation of the bit stream 11010011 in the form Σ Axn where A = 0 or 1 for n from 0 to 7: 64 CRC Modulo 2 Division Example CRC Message = 11101. Use 1101 for CRC generator polynomial Add three zero bits (equivalent to left shifting the message by three bits) (This defines the “width” of the CRC 10101 (Ignore the quotient) 10101 (Ignore the quotient) Process: 1101√ 11101000 Call the uppermost c+1 bits of the message the remainder. Beginning with the most significant bit in the original message and 1101 1101 for each bit position that follows, look at the c+1­bit remainder: If the most significant bit of the remainder is a one, the 0111 0111 divisor is said to divide into it. If that happens Set the appropriate bit in the quotient to a one, and 0000 0000 XOR the remainder with the divisor and store the result back into the remainder. 1110 111 Otherwise (if the first bit is not a one): Set the appropriate bit in the quotient to a zero, and 1101 1101 XOR the remainder with zero (no effect) Left­shift the remainder, shifting in the next bit of the 0110 011 message. The bit that's shifted out will always be a zero, so no information is lost. 0000 0000 The final value of the remainder is the CRC of the given message. 1100 110 Source: http://www.netrino.com/Connecting/2000­01/index.php 1101 1101 001 001 1/14/2010 This final remainder is the CRC! This final remainder is the CRC! 65 CRC Process and Efficiency •Message (with remainder appended) is transmitted to the receiver. •Receiver divides message + remainder by same generating polynomial •If remainder ≠ 0 results, there was an error during transmission. •If a remainder = 0 results, there was no error during transmission •Process detects very high percentage of errors 1/14/2010 1/14/2010 r=Degree of the Generating Polynomial 66 CRC32 Math Represent the message 1011 as a polynomial • • • Result gives quotient q(x) and remainder r(x). Discard q(x) For example, j(x) divides evenly, so r(x)=0 If one of the bits in the original 4­bit message were flipped, r≠0 • j(x)=i(x) X x32 j(x) = 1011 0000 0000 0000 0000 0000 0000 0000 0000 • • • 1011 = 1 X 23 + 0 X 22 + 1 X 21 + 1 X 20 = i(x), x=2 If there were an error, t(x) might look like: 1011 0000 0000 0000 0000 0000 0000 0001 0100 Multiply i(x)by x32 (equivalent to left shift by 32 bits, and filling in lower order bits with “0”s to obtain j(x) Divide j(x) by publicly known generator polynomial g(x)= x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1 Compute t(x) = j(x) + r(x) Receiver divides t(x) by same g(x) • • 1/14/2010 1/14/2010 If j(x) divides evenly, no bits have been changed If one of the bits in the original 4­bit message were flipped, r≠0 • For polynomial of CRC32, errors of up to 32 bits can be detected 100% (Probability of 1) • Error burst of >32 bits can be detected with a probability of 1­(1/2)32= 1­2.383 X ­10 (Very near to 1) 67 In Class Exercise In What is the probability of detecting an error burst of more than 5 bits using the polynomial in the example on slide 14? 1/14/2010 68 Message Digests Concept: Condense a message of any size to a “digest” or “fingerprint” • Most popular: MD­4 (digest = 128 bits) MD­5 (digest = 128 bits) Secure Hash Algorithm (SHA) or Secure Hash Standard (SHS) (digest = 160 bits The Message Digest is the “seal” on the message • Also known as the Message Integrity Check (MIC) 1/14/2010 1/14/2010 69 MD5 Defined in RFC 1321 Generating two MD5 digests having the same digest would require 264 operations ≈ 1.8447 X 1019 operations • Assume 3 GHz processor can do 3 X 109 operations per second • 264 operations would take 1.8447 X 1019 / 3 X 109 ≈ 6.14 X 109 seconds ≈ 195 years Putting together a message to generate a specific hash is estimated to require 2128 operations ≈ 3.6 X 1021 years! • See textbook for details of how MD5 computes the MIC When using MIC without encryption, can use “keyed MD5” • Computes hash of (key|message) Key at front of message is more collision resistant Susceptible to “append” attack (added block at end) • “Append Attack” easily defeated with hash (key|message|key) 1/14/2010 1/14/2010 Could also just do hash (message|key) 70 ...
View Full Document

Ask a homework question - tutors are online