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 MidTerm Exam
Week 2 Reading – Pfleeger & Pfleeger 4th Edition Chapters 2 and 7
Chandra Chapter 2 (all) and Chapter 3, pp 6775
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) Processingintensive 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 = nbit 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 offline 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 (nontrivial)
• System security depends on timesynch 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 networktime 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: HKm1AB(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 *HKm1AB(Random#1) = hash of R#1 computed m1 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
•KeyGenerating 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{ N21,N3} 2. EKAB{N31} 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 password 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” (encrypted 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 Precomputer 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 (RivestShamirAdelman)
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
64bit 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 • Keydependent
substitution
• Different for
each key 64bit intermediate value • Permuation
• May be key dependent 64bit 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 keynumbers K0, K1, K2, K3, K4, K5, K6, K7, K8, K9, K10
Think of each key number as four 32bit values
Substitute Bxy= S_Box[Sxy_high][Sxy_low],
where S_Box is AES standard 16 byte X 16 byte table lookup
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 keybyte generated for each byte in the plaintext
Sender XORs plaintext byte by byte with the keybytes 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 Cn1 Cn Cn+1 P1 XOR XOR XOR XOR Ek Ek C1 … Ek IV P2 Pn1 C2 … Pi = 64 bit block; Ci = 64 bit block; Ci=Ek(Pi XOR Ci1)
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 Pn1
XOR Pn Pn+1 XOR XOR Ek
Ek
Ek
… hn2
hn1
… Cn1 Cn hn hn+1 Ek Ek(optional) Ek Cn+1 Pi = 64 bit block; Ci = 64 bit block; Ci=Ek(Pi XOR Ci1)
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 CRC32. Other common generating polynomials include CRC12, CRC 16, and CRCCCITT •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 InClass Exercise
InClass 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+1bit 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) Leftshift 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/200001/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 4bit 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 4bit 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= 12.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: MD4 (digest = 128 bits)
MD5 (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 (keymessage) Key at front of message is more collision resistant Susceptible to “append” attack (added block at end) • “Append Attack” easily defeated with hash (keymessagekey) 1/14/2010
1/14/2010 Could also just do hash (messagekey)
70 ...
View
Full
Document
This note was uploaded on 08/29/2011 for the course CSC 607 taught by Professor Dr.pradipp.dey during the Spring '11 term at National.
 Spring '11
 Dr.PradipP.Dey

Click to edit the document details