CS 5950/6030 Network Security Class 10 (F, 9/23/05) Leszek Lilien Department of Computer Science Western Michigan University [Using some slides courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands]
34
Embed
CS 5950/6030 Network Security Class 10 (F, 9/23/05) Leszek Lilien Department of Computer Science Western Michigan University [Using some slides courtesy.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
[Using some slides courtesy of:Prof. Aaron Striegel — at U. of Notre Dame
Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. WashingtonProf. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The
Netherlands]
2
2. Cryptology ...
2F. The AES (Advanced Encryption Standard) Algorithm2F.1. The AES Contest
2F.2. Overview of Rijndael2F.3. Strength of AES2F.4. Comparison of DES and AES
2G. Public Key Encryption2G.1. Motivation for PKE2G.2. Characteristics of PKE2G.3. RSA Encryption
2H. The Uses of Encryption 2H.1. Cryptographic Hash Functions – PART 1
Class 9
3
2H.1. Cryptographic Hash Functions (1)
Integrity: How can you be sure that a recived msg/doc was
not modified by an attacker or malfunction? Answer: use cryptography to ensure integrity
Idea: Wax seals on letters in Middle Ages
— easy to see if broken Cryptographic „seal” on doc/msg
— so that any change to it will be readily detected
4
Cryptographic Hash Functions (2)
A technique:compute a hash fcn / checksum / msg digest
More formally: Problem: How to send n-bit msg so that R can
easily verify that it is intact
Solution: Send a msg of n+k bits n bits — original msg k bits — checksum / msg digest
Generated based on the n bits
5
Cryptographic Hash Fcns (3)
Simple Parity for Error Detection (1) Simple (non-cryptographic) technique: parity
Add a single parity bit to detect if a message is correct Example 1: odd parity
Force the block of data to have an odd # of 1’s Data = 1011 — n = 4 Sent block = 10110 — n+k = 4+1
— looked at ‘1011’, added 0 to have odd # of 1’s Data = 0110 Sent block = 01101
— looked at ‘0110’, added 1 to have odd # of 1’s
Example 2: ASCII parity bit ASCII has 7 bits for data, 8th bit is single parity bit
Either odd or even parity used
[cf. A. Striegel, U. Notre Dame]
6
Cryptographic Hash Fcns (4)
Simple Parity for Error Detection (2)
How parity enhances msg integrity? Can detect error in 1 bit (or in odd # of bits)
e,.g, if R gets 01001, R knows it’s wrong(S sent 01101)
Cannot detect error in 2 bits (or in even # of bits) Bec. parity stays OK -> undetectable integrity
violation e.g, if R gets 01011, R knows it’s wrong
(S sent 01101)
Cannot repair errors either E.g., R doesn’t know which bit in 01001 is wrong[cf. A. Striegel, U. Notre
Dame]
7
Cryptographic Hash Fcns (5)
Better Checksums against Errors & Attacks
There are better checksums than simple odd/even parity Can detect multiple errors Can even repair multiple errors
These checksums are to fix errors, not deal with attacks
For attacks needcryptographic checksums / strong hash functions
8
Cryptographic Hash Fcns (6)
Strong Hash Function Formal definition:
strong hash function (cryptographic checksum) is h: A -> B such that:
1) For any x A, h(x) is easy to compute2) For any y B, it is computationally infeasible to
findinverse of y, i.e., x A such that h(x) = y
3) It is computationally infeasible to find a pair of colliding input values, i.e. x, x’ A such that x ≠ x’ and h(x) = h(x’)
Alternate (stronger) form for (3):Given any x A, it is computationally infeasibleto find x’ A such that x ≠ x’ and h(x) = h(x’)
Due to (1) and (2), hash fcn is a one-way function[cf. A. Striegel, U. Notre Dame, Barbara Endicott-Popovsky, U. Washington]
9
Cryptographic Hash Fcns (7)
Collisions & Attacks on Msg Integrity (1) Note:
n bits of msg (x) mapped into k bits of its checksum (y)
k < n => collisions must exist But it is computationally infeasible to find collisions for
good hash fcns
Goal of a successful attack on msg integrity: Change msg1 in such a way that checksum remains
unchanged (so R doesn’t detect the forgery) I.e., find msg2 that collides with the original msg1
w.r.t. checksum value Finding msg2 is computationally infeasible (for good
hash)
=> forging msg1 undetectably is computationally infeasible
[cf. A. Striegel, U. Notre Dame]
10
Cryptographic Hash Fcns (9)
File Checksum File checksum
Calculated, a fcn defined on all bits of the file Result encrypted and stored with the file Each time file used by legitimate users,
checksum recalculated, encrypted, stored with the file
File sent to R When file received by R:
R decrypts checksum c1 received in the file R independently calculates file checksum c2 If c1 = c2 => file integrity is OK Otherwise – file integrity violated
11
Class 9 ended here
12
2. Cryptology ...
2F. The AES (Advanced Encryption Standard) Algorithm2F.1. The AES Contest
2F.2. Overview of Rijndael2F.3. Strength of AES2F.4. Comparison of DES and AES
2G. Public Key Encryption2G.1. Motivation for PKE2G.2. Characteristics of PKE2G.3. RSA Encryption
2H. The Uses of Encryption 2H.1. Cryptographic Hash Functions – PART 1 2H.1. Cryptographic Hash Functions – PART 2 2H.2. Key Exchange 2H.3. Digital Signatures 2H.4. Certificates – PART 1
Class 9
Class 10
13
Cryptographic Hash Fcns (10)
Keyed vs. Keyless Crypto Checksum (1)
Keyed crypto checksum Key needed to compute checksum
Keyed hash fcns DES, AES Use it in chaining mode:
link next msg block to value of the previous msg block
Example chaining: E(current block) XOR E(previous block)
=> connects block to all previous blocks
If file sent, file’s checksum could be the last block
If chaining used, file checksum (=last block) depends on all previous blocks => depends on all bits of the file
14
Cryptographic Hash Fcns (11)
Keyed vs. Keyless Crypto Checksum (2)
Keyed crypto checksum – CONT. Used for integrity + authentication
Integrity: checksum makes msg modification difficult
Authentication: only S and R know symmetric keyR: if msg integrity is OK, it must have been sent by S
15
Cryptographic Hash Fcns (12)
Keyed vs. Keyless Crypto Checksum (3) Keyless crypto checksum
No key required to compute checksum
Keyless hash functions MD5/MD4: any msg 128-bit digest (hash,
Used for integrity (not authentication) Integrity: checksum makes msg modification difficult
(with truly public key anybody can send msg, but nobody but S can easily modify this msg)
No authentication: n (or all) people know public key –R can’t prove which one of them sent a given msg
[cf. A. Striegel, U. Notre Dame, Barbara Endicott-Popovsky, U. Washington]
16
2H.2. Key Exchange (1) Motivation:
X and Y don’t know each other X needs to send protected msg to Y
E.g., shopping on a web site
can do it if can securely exchange KE
This is the problem of key exchange Important Hard
Circular (chicken-’n-egg) problem?„To establish secure session need secure channel”
Circle can be broken – by public key cryptography
Can send public key even on insecure channel
17
Key Exchange (2)
Deriving Symmetric Key via PKE (1)
Given S and R / kPRIV-S, kPUB-S -- kPRIV-R, kPUB-R
Solution 1: S determines secret key K S encrypts K with kPRIV-S : C = E(kPRIV-S, K) S sends C to R R decrypts C to get K: D(kPUB-S, C) = K S & R communicate using secret (symmetric) key
K
BUT: Solution 1 is not good!!! Question: Why?
18
Key Exchange (3)
Deriving Symmetric Key via PKE (2)
Given S and R / kPRIV-S, kPUB-S -- kPRIV-R, kPUB-R
Solution 1: S determines secret key K S encrypts K with kPRIV-S: C = E(kPRIV-S, K) S sends C to R R decrypts C to get K: D(kPUB-S, C) = K S & R communicate using secret (symmetric) key K
BUT: Solution 1 is not good !!! Answer:
Attacker who has kPUB-S can also perform decryption! The easier the more people know kPUB-S
Trivial if kPUB-S is truly public
19
Key Exchange (4)
Deriving Symmetric Key via PKE (3)
Solution 2: S determines secret key K S encrypts K with kPUB-R: C = E(kPUB-R, K) S sends C to R R decrypts C to get K: D(kPRIV-R, C) = K S & R communicate using secret (symmetric) key K
Solution 2 is better Only R can decode K (only R knows kPRIV-R)
...but Solution 2 still is not quite good Question: Why?
Hint: what about msg authentication?
20
Key Exchange (5)
Deriving Symmetric Key via PKE (4) Solution 2:
S determines secret key K S encrypts K with kPUB-R: C = E(kPUB-R , K) S send C to R R decrypts C to get K: D(kPRIV-R , C) = K S & R communicate using secret (symmetric) key K
Solution 2 is better Only R can decode K (only R knows kPRIV-R)
...but Solution 2 still is not quite good Answer:
No msg authentication(R has no assurance that msg was sent by S
– anybody could have encoded with kPUB-R)
21
Key Exchange (6)
Deriving Symmetric Key via PKE (5)
Solution 3: S determines secret key K S encrypts K with both kPRIV-S & kPUB-R :
C = E(kPUB-R , E(kPRIV-S, K)) S sends C to R R decrypts C to get K:
D( kPUB-S , D(kPRIV-R, C) ) -- order important ! make sure you see this
(see Fig. 2-11 p.78)
Solution 3 is good! Only R can decode K (only R knows kPRIV-R)
Authentication: R is assured that S sent C Only S could have encoded K with kPRIV-S
22
2H.3. Digital Signatures (1)
Outline: a. Problem Definition b. Properties of Electronic Signatures c. Using PKE for Digital Signatures d. Using Hash Fcns for Digital Signatures
23
Digital Signatures (2)
a. Problem Definition (1) Motivation:
Need to sign and transmit electronic doc’s or msgs, incl. checks
Roles of signatures (for both paper a& electronic) Proves unforgeability of doc/letter/check Authenticates person S who signed doc/letter/check Provides non-repudiation: S cannot say sb else
signed it Facilitates proving integrity (e.g., 2 signed legal copies for 2
parties)
Note: signature might not identify the signing person if not legible
24
Digital Signatures (3)
Problem Definition (2)
Security requirements for digital signatures: Signature will not reveal signer’s private key Only owner of private key can produce a valid
signature Verification of a correct signature succeeds Modification of a signed message can be
detected
[cf. J. Leiwo]
25
Digital Signatures (4)
b. Properties of Electronic Signatures (1)
M – msg / Sg(S, M) – signature of S on MNote: M = C or M = P M = P – if authentication but no secrecy needed
Required properties for electronic signatures: Unforgeable:
R can verify that Sg(S,M) in [M, Sg(S, M)] comes from S
Only S could have produced M”+”Sg(S,M) Sg(S, M) is firmly attached to M
M
Sg(S, M)
26
Digital Signatures (5)
Properties of Electronic Signatures (2)
Desirable properties for electr. signatures: Not alterable (assures „integrity”) :
Once sent, M”+”Sg(S,M) cannot beundetectably altered by S, R, or interceptor
[I’d rather consider this a part of „unforgeability” above]
Not reusable:If M is received again, S detects that M is „old”
E.g., can’t deposit a copy of a check to „double-deposit”
Digital signature is a protocol that mimics effect of signature on paper
M
Sg(S, M)
27
Digital Signatures (6)
c. Using PKE for Digital Signatures (1)
Transmitting signed msgs with PKE Original message:
Privacy transformation: C = E(P, KPUB-R) Only R can decrypt it (with KPRIV-R)
Authenticity transformation = signing:Sg = Sg(S, C) = D(C, KPRIV-S)
Only S can produce Sg(S, C) (with KPRIV-S)
Sent message:
Note: Remember that for some PKE algorithms (incl RSA):D( E(M, _), _ ) = E( D(M, _), _ ) = M (commutativity of E-D)
C
Sg
P
28
Digital Signatures (7)
Using PKE for Digital Signatures (2)
Transmitting signed msgs with PKE - cont. Received msg:
[ C = E(P, KPUB-R) ]
[Sg = Sg(S, C) = D(C, KPRIV-S)]
R verifies Sg with S’s public key KPUB-S:
If E( Sg, KPUB-S) = C, then signature is valid bec. E( Sg, KPUB-S) = E( D(C, KPRIV-S), KPUB-S) = C
R decodes C with R’s private key KPRIV-R:
P = D(C, KPRIV-R)
C
Sg
29
Digital Signatures (8)
Using PKE for Digital Signatures (3) Properties:
[ C = E(P, KPUB-R) ]
[Sg = Sg(S, C) = D(C, KPRIV-S)]
Unforgeability:If C is forged,it will not „correspond” to Sg ( i.e., E( Sg, KPUB-S) ≠ C )
Authenticity:If Sg is valid, S is authenticated (only S can produce valid S’s signature)
Non-repudiation (undeniability):If Sg is valid, only S could have produced it, and have sent C”+”Sg
C
Sg
30
Digital Signatures (9)
d. Using Hash Fcns for Digital Signatures
Using hash fcn H in digital signatures— signature over H(m), not over m length H(m) << length (m)
Before: Now:
[Fig — cf. J. Leiwo]
s = SgDA(x) = D(x, KPRIV-A)
EA(x) = E(x, KPUB-A)
Note:Any alteration of m is detected by B’s „Verify” step even if m is not encoded with KPUB-B —due to use of H(m)
m
Sg(S, H(m))
m
Sg(S, m)
m = P or m = C
31
2H.4. Certificates (1)
Outline a. Introduction b. Trust Through a Common Respected Individual c. Certificates for Identity Authentication d. Trust Without a Single Hierarchy
32
Certificates (2)
a. Introduction (1) Need for trust in human interactions
Trust w.r.t.: Individuals Institutions (e.g., bank, hospital, car dealer) Artifacts (e.g., car, Internet browser, software house)
Trust in small village vs. big city Small village: implicit trust
Everybody knows everybody Mr. X „feels” how much to trust Ms. Y
Big city: need to consider trust explicitly Ask around to find trusted entities
Inquire friends, office mates, etc. about good car dealer, dentist, etc.
Check „reputation databases”E.g., BBB=Better Business Bureau
33
Certificates (3)
Introduction (2) Selected trust characteristics
Trust comes in degrees of trust Vs. binary trust (with a single trust threshold)
Ubiquity of trust in social and artificial systems Many users/computer systems err by trusting
blindly (trust without evidence or verification!) E.g., OS trusts all application pgms – any allowed to run E.g., sers trust unknown web sites with personal data