1. CS 5700 Computer Security and Information Assurance Section 4: Introduction to Cryptology - Part 2 Dr. Leszek Lilien Department of Computer Science Western Michigan University Slides based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides courtesy of: Prof. Aaron Striegel — course taught at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke (U. Idaho) — taught at U. Washington Prof. Jussipekka Leiwo — taught at Vrije Universiteit (Free U.), Amsterdam, The Netherlands Slides not created by the above authors are © 2006-2010 by Leszek T. Lilien Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

2. 2 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Introduction to Cryptology – Part 1 Already Covered in Section 3 3A. Terminology and Background 3A.1. Threats to Messages 3A.2. Basic Terminology and Notation 3A.3. Requirements for Crypto Protocols 3A.4. Representing Characters 3B. Basic Types of Ciphers 3B.1. Substitution Ciphers a. The Ceasar Cipher b. Other Substitution Ciphers c. One-Time Pads 3B.2. Transposition Ciphers 3B.3. Product Ciphers 3C. Making „Good” Ciphers 3C.1. Criteria for „Good” Ciphers 3C.2. Stream and Block Ciphers 3C.3. Cryptanalysis 3C.4. Symmetric and Asymm. Cryptosystems

3. 3 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 3D. The DES (Data Encryption Standard) Algorithm 3D.1. Background and History of DES 3D.2. Overview of DES 3D.3. Double and Triple DES 3D.4. Security of DES 3E. The Clipper Story 3F. AES (Advanced Encryption Standard) 3F.1. The AES Contest 3F.2. Overview of Rijndael 3F.3. Strength of AES 3F.4. Comparison of DES and AES... Section 3 (Part 1 of Cryptology) Ended Here... Introduction to Cryptology – Part 1 Covered in Sec. 3 (cont.)

4. 4 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Introduction to Cryptology – Part 2 Outline for Section 4 (cont. of Section 3) 4A. Public Key Encryption (PKE) 4A.1. Motivation for PKE 4A.2. Characteristics of PKE 4A.3. RSA (Rivest-Shamir-Adelman) Encryption 4B. The Uses of Encryption 4B.1. Cryptographic Hash Functions 4B.2. Key Exchange 4B.3. Digital Signatures a. Problem Definition b. Properties of Electronic Signatures c. Using PKE for Digital Signatures d. Using Hash Fcns for Digital Signatures 4B.4. Certificates a. Introduction b. Trust Through a Common Respected Individual c. Certificates for Identity Authentication d. Trust Without a Single Hierarchy

5. 5 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4A. Public Key Encryption (PKE) Recall: Two main types of cryptosystems: Secret key (= symmetric) Public key (= asymmetric) Outline for PKE 4A.1. Motivation for PKE 4A.2. Characteristics of PKE 4A.3. RSA (Rivest-Shamir-Adelman) Encryption

6. 6 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4A.1. Motivation for PKE So far - cryptosystems with secret keys Problems: A lot of keys o(n 2 ) keys for n users (n * (n-1) /2 keys) — if each must be able to communicate with each Secure distribution of so many keys Secure storage for the keys User with n keys can’t just memorize them Can have a system with significantly fewer keys? Yes!

7. 7 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Motivation for PKE – con t. 1976 — Diffie and Hellman — new kind of cryptosystem: public key cryptosystem = asymmetric cryptosystem Key pairs: Each user owns one private key Each user shares the corresponding public key with n-1 remaining users => n users share each public key Only 2n keys for n users 2n = n * (1 + n * 1/n) Since public key is shared by n people: 1 „owner” + (n-1) others = n 1/n since each part „owns” 1/n of the public key Even if each communicates with each Reduction from o(n 2 ) to o(n) ! n key pairs are:,,...,

8. 8 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4A.2. Characteristics of PKE  PKE requirements 1.It must be computationally easy to encipher and decipher a message given the appropriate key 2.It must be computationally infeasible to derive k PRIV from k PUB 3.It must be computationally infeasible to determine k PRIV from a chosen plaintext attack [cf. Barbara Endicott-Popovsky, U. Washington]

9. 9 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Characteristics of PKE – cont. 1 Key pair characteristics One key is inverse of the other key of the pair i.e., it can undo encryption provided by the other: D(k PRIV, E(k PUB, P)) = P D(k PUB, E(k PRIV, P)) = P One of the keys can be public Since each key does only half of E ”+” D As shown above – need both E and D to get P back

10. 10 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Characteristics of PKE – cont.2 Two E/D possibilities for key pair P = D(k PRIV, E(k PUB, P)) User encrypts msg with k PUB (k PUB” ”locks”) Recipient decrypts msg with k PRIV (k PRIV ”unlocks”) OR P = D(k PUB, E(k PRIV, P))(e.g., in RSA) User encrypts msg with k PRIV (k PRIV ”locks”) Recipient decrypts msg with key k PUB (k PUB ”unlocks”) Do we still need symmetric encryption (SE) systems? Yes, SEs are 10,000+ times (!) faster than PKEs PKEs use slow exponentiation – involves multiplication & division SEs use only much faster bit operations (add, XOR< substitute, shift)

11. 11 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4A.3. RSA Encryption RSA = Rivest, Shamir, and Adelman (MIT), 1978 Based on underlying hard problem: Number theory – determining prime factors of a given large number (ex. factoring of small #: 5  5, 6  2 *3) Arithmetic modulo n How secure is RSA? So far remains secure (after all these years...) Will sb propose a quick algorithm to factor large numbers? Who knows… Could happen tomorrow… or never Will quantum computing break it? Research will tell - TBD

12. 12 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance RSA Encryption – cont. Order of D/E does not matter in RSA: P = E (D(P)) = D(E(P)) More precisely: P = E(k E, D(k D, P)) = D(k D, E(k E, P)) Encryption:C = P e mod ne = K E Given C, it is very difficult to find P without knowing K D Decryption:P = C d mod nd = K D

13. 13 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4B. The Uses of Encryption PKE is much slower than SE (symmetric E) PKEs only for specialized, infrequent tasks SEs – a real workhorse Four major applications of encryption (& outline)  Cryptographic Hash Functions (subsec. 4B.1)  Secure Key Exchange (subsec. 4B.2)  Digital Signatures (subsec. 4B.3)  Certificates (subsec. 4B.4)

14. 14 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4B.1. Cryptographic Hash Functions Integrity: Q: How to ensure that a recived msg/doc was not modified by an attacker or malfunction? A: 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

15. 15 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Cryptographic Hash Fcns – cont. 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

16. 16 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Cryptographic Hash Fcns (3) Simple Parity for Error Detection 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]

17. 17 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance How (odd) 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 doesn’t know 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] Cryptographic Hash Fcns (4) Simple Parity for Error Detection – cont.

18. 18 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 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 to deal with attacks For attacks need cryptographic checksums / strong hash functions

19. 19 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 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 compute 2)For any y  B, it is computationally infeasible to find inverse 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 infeasible to 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]

20. 20 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Cryptographic Hash Fcns (7) Collisions & Attacks on Msg Integrity Note: n bits of msg (x) mapped into k bits of its checksum (y) k 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]

21. 21 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Pigeonhole principle n containers for n+1 objects (n pigeonholes for n+1 pigeons) => at least 1 container will hold two objects Example:  n = 5 = length(msg), k = 3 = length(hash)  2 5 =32 possible msgs vs. 2 3 =8 possible hash values => at least 4 (= 32/8) different msgs hash into the same value = collisions!  Real msgs and hash values are much longer than 5 or 3 bits! Even when we know that collisions exist its is: - much tougher to find collisions => much tougher to forge msg w/o changing has value [cf. A. Striegel, U. Notre Dame] Cryptographic Hash Fcns (8) Collisions & Attacks on Msg Integrity –cont.

22. 22 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Cryptographic Hash Fcns (9) File Checksum File checksum Calculated as 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

23. 23 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Cryptographic Hash Fcns (10) Keyed vs. Keyless Crypto Checksum 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

24. 24 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Cryptographic Hash Fcns (11) Keyed vs. Keyless Crypto Checksum – cont. 1 Keyed crypto checksum – CONT. Used for integrity + authentication Integrity: checksum makes msg modification difficult Authentication: only S and R know symmetric key R: if msg integrity is OK, it must have been sent by S

25. 25 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Cryptographic Hash Fcns (12) Keyed vs. Keyless Crypto Checksum – cont. 2 Keyless crypto checksum No key required to compute checksum Keyless hash functions MD5/MD4: any msg  128-bit digest (hash, checksum) SHA/SHS: any msg  160-bit digest Other: MD2, HAVAL, Snefru,... Used for integrity (not for authentication) Integrity: checksum makes msg modification difficult (with truly public key anybody can send msg, however 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]

26. 26 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4B.2. Key Exchange Motivation: R and S don’t know each other R needs to send protected msg to S E.g., shopping on a web site  can do it if can securely exchange K E This is the problem of key exchange Important Hard Is it a circular (chicken-’n-egg) problem? „To establish secure session need secure channel” „To establish secure channel need secure session” Solution: Circle can be broken by public key cryptography Can send public key even on insecure channel

27. 27 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Key Exchange (2) Deriving Symmetric Key via PKE Given S and R / k PRIV-S, k PUB-S -- k PRIV-R, k PUB-R Solution 1: S determines secret (symmetric) key K S encrypts K with k PRIV-S : C = E(k PRIV-S, K) S sends C to R R gets K by decrypting C: D(k PUB-S, C) = K S & R communicate using secret key K BUT: Solution 1 is not good!!! Question: Why?

28. 28 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Key Exchange (3) Deriving Symmetric Key via PKE – cont. 1 Given S and R / k PRIV-S, k PUB-S -- k PRIV-R, k PUB-R Solution 1: S determines secret (symmetric) key K S encrypts K with k PRIV-S : C = E(k PRIV-S, K) S sends C to R R gets K by decrypting C: D(k PUB-S, C) = K S & R communicate using secret key K BUT: Solution 1 is not good !!! Answer: Attacker has k PUB-S => can decrypt The easier the more people know k PUB-S Trivial to decrypt by attacker if k PUB-S is truly public

29. 29 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Key Exchange (4) Deriving Symmetric Key via PKE – cont. 2 Solution 2: S determines secret (symmetric) key K S encrypts K with k PUB-R : C = E(k PUB-R, K) Not with k PRIV-S as in Solution 1 S sends C to R R gets K decrypting C: D(k PRIV-R, C) = K S & R communicate using secret key K Solution 2 is better Only R can decode K (only R knows k PRIV-R )... but Solution 2 still is not quite good Question: Why? Hint: what about msg authentication?

30. 30 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Key Exchange (5) Deriving Symmetric Key via PKE – cont. 3 Solution 2: S determines secret (symmetric) key K S encrypts K with k PUB-R : C = E(k PUB-R, K) S send C to R R gets K by decrypting C: D(k PRIV-R, C) = K S & R communicate using secret key K Solution 2 is better Only R can decode K (only R knows k PRIV-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 sent it since anybody could is able to encode with k PUB-R )

31. 31 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Key Exchange (6) Deriving Symmetric Key via PKE – cont. 4 Solution 3: S determines secret (symmetric) key K S encrypts K with both k PRIV-S & k PUB-R : C = E(k PUB-R, E(k PRIV-S, K)) S sends C to R R gets K by decrypting C: D( k PUB-S, D(k PRIV-R, C) ) -- order important ! make sure you see this (see Fig. 2-11 p.78) Solution 3 is finally good! Only R can get K (only R knows k PRIV-R ) Authentication: R is assured that S sent C Only S knows k PRIV-S => only S could have encoded K with k PRIV-S

32. 32 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4B.3. Digital Signatures Outline: a. Problem Definition b. Properties of Electronic Signatures c. Using PKE for Digital Signatures d. Using Hash Fcns for Digital Signatures

33. 33 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Digital Signatures (2) a. Problem Definition Motivation: Need to authenticate electronic doc’s or msgs = need to “sign” electronic doc’s or msgs before xmission Analogous to signing & transmitting „paper” letters, doc’s 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) E.g., signatures of both parties must appear on each agreement/contract Note: signature might not identify the signing person E.g., if not legible (or forged, but that’s a different story)

34. 34 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Digital Signatures (3) Problem Definition – cont. 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 Analogy: That’s why it’s best to sign a paper doc just below the last line of the document, not at some distance form it (e.g. at the bottom of last page) [cf. J. Leiwo]

35. 35 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Digital Signatures (4) b. Properties of Electronic Signatures M – msg / Sg(S, M) – signature of S on M Note: M = C or M = P M = P – if authentication but no secrecy needed Required properties for electronic signatures: Unforgeable: Only S can produce the pair [M, Sg(S, M)] Authenticable (can verify authenticity)/ non-repudiable: 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)

36. 36 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Digital Signatures (5) Properties of Electronic Signatures – cont. Desirable properties for electr. signatures: Not alterable (assures „integrity”) : Once sent, M”+”Sg(S,M) cannot be undetectably altered by S, R, or interceptor [LL: I’d rather consider this a part of „unforgeability” above] Not reusable: If M is received again, R detects that M is „old” Signature could include a timestamp E.g., to prevent deposit of a copy of a check to „double- deposit” Digital signature is a protocol (not just an “item”) that mimics effect of signature on a paper doc M Sg(S, M)

37. 37 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Digital Signatures (6) c. Using PKE for Digital Signatures Transmitting signed msgs with PKE Original message: Privacy transformation by S: C = E(P, K PUB-R ) Only R can decrypt it (with K PRIV-R ) Authenticity transformation = signing by S: Sg = Sg(S, C) = D(C, K PRIV-S ) Only S can produce Sg(S, C) (with K PRIV-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

38. 38 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Digital Signatures (7) Using PKE for Digital Signatures – cont. 1 Transmitting signed msgs with PKE - cont. Received msg: [ C = E(P, K PUB-R ) ] [Sg = Sg(S, C) = D(C, K PRIV-S )] [i.e., Sg = D( E(P, K PUB-R ), K PRIV-S ) Step 1: R verifies Sg with S’s public key K PUB-S : If E( Sg, K PUB-S ) = C, then signature is valid bec. E( Sg, K PUB-S ) = E( D(C, K PRIV-S ), K PUB-S ) = C Step 2: R decodes C (obtained in Step 1) with R’s private key K PRIV-R : P = D(C, K PRIV-R ) bec. D(C, K PRIV-R ) = D( E(P, K PUB-R ), K PRIV-R ) = P C Sg

39. 39 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Digital Signatures (8) Using PKE for Digital Signatures – cont. 2 Properties: [ C = E(P, K PUB-R ) ] [Sg = Sg(S, C) = D(C, K PRIV-S )] Unforgeability: If C is forged, Sg verification will fail ( i.e., E( Sg, K PUB-S ) ≠ C ) Authenticity: If Sg is verified successfully, S is authenticated (only S can produce valid S’s signature) Non-repudiation (undeniability): If Sg is verified successfully, only S could have produced it, and have sent C”+”Sg C Sg

40. 40 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 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 = Sg D A (x) = D(x, K PRIV-A ) E A (x) = E(x, K PUB-A ) Note: Any alteration of m is detected by B’s „Verify” step even if m is not encoded with K PUB-B —due to use of H(m) m Sg(S, H(m)) m Sg(S, m) m = P or m = C

41. 41 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance 4B.4. Certificates Outline a. Introduction b. Trust Through a Common Respected Individual c. Certificates for Identity Authentication d. Trust Without a Single Hierarchy

42. 42 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates (2) a. Introduction Need for trust in human interactions Trust w.r.t.: Individuals Institutions (e.g., bank, hospital, car dealership) Artifacts (e.g., a car, Internet browser, a loan) 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

43. 43 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates (3) Introduction – cont. 1 Selected trust characteristics Trust comes in degrees of trust Gradual trust vs. binary trust Binary (0 or 1) can be viewed as a special case of gradual with a single trust threshold Trust = 0 i.e. “ no trust” if below threshold Trust = 1 i.e. “ trust” if above 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., users trust unknown web sites with personal data

44. 44 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates (4) Introduction – cont. 2 Basic means of building trust toward person / institution / artifact X Familiarity with X Person: face, voice, handwriting, etc. Institution: company name, image, good will, etc Artifact: manufacturer name, perceived quality, etc First-hand experience wih X’s activities/performance Good or bad experience (trust or distrust grows) Second-hand reputation Reputation = knowledge of X’s actions/performance Determined by evidence or credentials Reputation databases (e.g., BBB, industry organizations, etc.) with „good” evidence or lack of „bad” evidence) Credentials: X’s driver license, library card, credit card Affiliation of X with person/institution/artifact Y E.g., employers’ trust toward WMU rubs off on all graduates

45. 45 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates (5) Introduction – cont. 3 Basic means of verifying trust toward person / institution / artifact X: „Dovyeryay noh provyeryay” („Trust but verify”, a Russian proverb) — Ronald Reagan (at the start of historic negotiations with Mikhail Gorbachev) Verify one’s experience Check own notes about X’s activities/performance Verify reputation evidence / credentials Call back to verify phone number Check user feedback about quality of artifact (online) Check reputation DBs (e.g., consumer reports, BBB) for data Verify affiliation Check with employer if X still employed Check reputation of Y with which X is affiliated

46. 46 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates (6) Introduction – cont. 4 Often trust is based on appearance of authenticity, without careful verification Example Business order from Company A sent to company B Order sent w/o careful verification of A by B Why? Verification is expensive Trust prevails in business Risk of fraud or swindle is low B might be „insured” against being cheated A trusted third-party intermediary assumes transaction risk E.g., buyer’s bank guarantees a transaction payment Appearance of authenticity can be used by a fraudster / swindler

47. 47 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates (7) Introduction – cont. 5 Need similarly common and efficient/effective trust mechanisms in the Cyber Space Need somebody or something to: assume risks of being cheated by the other party OR vouch for the other party A trusted third party (TTP) - often a basis for trust in Cyberspace When two interacting parties do not trust each other sufficiently Example from “real life”: a trusted negotiator called upon to lead to an agreement The negotiator might also be a guarantor of the agreement once it is reached

48. 48 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance b. Trust Through Common Trusted Individual Hierarchical structure of organizations CEO / Divisions/ Departments / Groups / Projects CEO doesn’t know engineers directly Still, CEO controls all via intermediate managers => hierarchy as basis for trust in an organization Example Ann meets Andy Andy claims he works for the same company Ann can verify via common trusted individual / trusted third party (TTP)  via Bill and Betty if Bill knows/trusts Betty  via Bill and Camilla, otherwise Camilla Betty Bill Ann Andy

49. 49 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Through Common Trusted Individual – cont. 1 Analogous approach for crypto key exchange with assurance that the key is not forged Consider Ann & what seems to be her public key: K PUB-Ann If K PUB-Ann is forged, message sent to Ann using K PUB-Ann will be accessible to the forger only (who has the coresponding K PRIV-Ann ); msg will not be accessible to Ann Example Ann and Andy want to comm- unicate Ann gives K PUB-Ann to Bill Bill passes K PUB-Ann to Camilla (or to Betty if he trusts her) Camilla passes K PUB-Ann to Betty Betty passes K PUB-Ann to Andy Camilla is TTP (trusted third party) Camilla Betty Bill Ann Andy

50. 50 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Through Common Trusted Individual – cont. 2 In reality need to pass more than just K PUB-Ann Every sender attaches an evidence of identity Ann: Statement of Identity (SoI) Bill, Camilla Betty: Transmittal of Identity (ToI) Andy receives K PUB-Ann with: Ann’s proof of identity Proof of identity for all intermediaries Proof that each inter- mediary received K PUB-Ann from trusted sender E.g., Betty sends K PUB-Ann with the stmt: „I am Betty and I received this key, SoI, and 2 ToIs from a person I know to be Camilla” K PUB-Ann +SoI K PUB-Ann +SoI+ToI Camilla Betty Bill Ann Andy K PUB-Ann +SoI +2 ToIs K PUB-Ann +SoI +3 ToIs

51. 51 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Through Common Trusted Individual – cont. 3 In reality need to pass more than just K PUB-Ann – CONT. Andy can verify chain of evidence (SoI + ToI’s) This assures Andy that key was sent by Ann and not forged Public key authentication (delivered by trusted people) Binding of key to Ann Authentication of Ann (trustworthy Ann’s identification as sender of this key) K PUB-Ann +SoI K PUB-Ann +SoI+ToI Camilla Betty Bill Ann Andy K PUB-Ann +SoI +2 ToIs K PUB-Ann +SoI +3 ToIs

52. 52 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Through Common Trusted Individual – cont. 4 Works pretty well within an org There’s always sb common & trusted for any 2 employees (at the top or below) Problems : 1)TTP absent E.g., if Bill, Camilla, or Betty out of town, Ann & Andy have to wait for key exchange 2)TTP works too hard to exchange all keys quickly K PUB-Ann +SoI K PUB-Ann +SoI+ToI Camilla Betty Bill Ann Andy K PUB-Ann +SoI +2 ToIs K PUB-Ann +SoI +3 ToIs

53. 53 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Camilla Betty Bill Ann Andy Trust Through Common Trusted Individual – cont. 5 Protocol Solving Problem 1 (TTP absence ) :  Idea: pre-authenticated public key for single future use  Ann asks Bill for complete chain from top down to her  Bill provides chain:  Ann requests for TOIs for her SOI ahead of time  Ann receives from Bill 2 TOIs:  TOI#637: “I, Bill, gave this TOI to Ann to confirm her identity for SOI#27” + Bill’s signature  TOI#5492: “I, Camilla, gave this TOI to Bill to confirm his identity for TOI#637” + Camilla’s signature  Now Ann can use SOI+TOIs any time  Exercise: Think about full scenario Hint: Andy prepares his SOI+TOIs ahead of time

54. 54 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Through Common Trusted Individual – cont. 6 Protocol Solving Problem 2 (TTP’s heavy workload) :  Idea: pre-authenticated public key for unlimited future use  Top TTP (e.g., a CEO) sends his TOIs to all next-level TTPs (e.g. to all Division Mgrs)  “I, Sushil, company CEO, attest to the identity of the Auto Division Mgr Diana, and I entrust Diana with attesting identities of her subordinates.”  Each Division Mgr sends TOIs to all Dept Mgrs  E.g., “I, Diana, Auto Division Mgr, attest to the identity of the Engine Dept Mgr Debbie, and I entrust Debbie with attesting identities of her subordinates.”  Note: Division Mgr is a TTP for all people working in her Division  …...

55. 55 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Through Common Trusted Individual – cont. 7 Protocol Solving Problem 2 (TTP’s heavy workload) :—CONT  …...  Each Group Leader sends TOIs to all Task Leaders  E.g., “I, Camille, Piston Group Leader, attest to the identity of the Piston Rings Task Leader Bill, and I entrust Bill with attesting identities of his subordinates.”  Note: Group Leader is a TTP for all people working in her Group  Each Task Leader sends TOIs to all his employees  E.g., “I, Bill, Piston Rings Task Leader, attest to the identity of Piston Rings Engineer Ann.”  Note: Task Leader is a TTP for all people working on his Task  Chain: Sushil—Diana—…—Camilla—Bill—Ann  Exercise: Think about protocol details – work out full scenario

56. 56 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance c. Certificates to Authenticate Identity Certificate for X TTP’s signature certifies trustworthiness of binding X’s key K PUB-X with X’s identity I.e., states that K PUB-X is really X’s public key How are certificates created? Identifier of X K PUB-X TTP’s Signature

57. 57 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 1 Creating certificates for the company example Sushil (CEO) (chain: Sushil—Diana—…—Camilla—Bill—Ann) Establishes Posts K PUB-Sushil for every Division Mgr to copy Receives request for certificate (encoded with K PUB-Sushil ) from Division Mgr X Creates M X = (knows K PUB-X ) E.g., M Diana = Signs M X with Sg Sushil Sg Sushil = D(M X, K PRIV-Sushil ) ‘Diana’ K PUB-Diana ‘Diana’ K PUB-Diana Sg Sushil

58. 58 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 2 Creating certificates... example—CONT. Sushil encrypts M X and Sg Sushil with K PRIV-Sushil, producing certificate for Div.Mgr X: Cert X = E(, K PRIV-Sushil ) Note: Others can read certificate, but only its issuer can update it! E.g., produces certificate for Diana: Cert Diana = E(, K PRIV-Sushil ) Sends certificate to Div. Mgr X ‘Diana’ K PUB-Diana Sg Sushil Cert Diana (shading indicates encryption) ‘Diana’ K PUB-Diana Sg Sushil

59. 59 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 3 Creating certificates... example – CONT. Diana (Div. Mgr) (chain: Sushil—Diana—…—Camilla—Bill—Ann) Establishes Posts K PUB-Diana for every subordinate to copy Sends request for certificate to her boss (Sushil) — as mentioned above (request encoded with K PUB-Sushil ) Receives certificate from her boss Cert Diana = E(, K PRIV-Sushil ) ‘Diana’ K PUB-Diana Sg Sushil

60. 60 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 4 Creating certificates... example – CONT. Diana receives request for certificate from Y, one of her Dept Mgrs Creates M Y = (knows K PUB-Y ) E.g., M Debbie = Signs M Y with Sg Diana Encrypts M Y and signature with K PRIV-Diana, producing pre-certificate for Dept Mgr X: preCert Y = E(, K PRIV-Diana ) E.g., produces pre-certificate for Debbie: preCert Debbie = E(, K PRIV-Diana ) ‘Debbie’ Sg Diana K PUB-Debbie preCert Debbie

61. 61 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 5 Creating certificates... example – CONT. Diana attaches to preCert Y her own certificate, producing certificate for Y: Cert Y = preCert Y || Cert Diana E.g., produces certificate for Debbie: Cert Debbie = preCert Debbie || Cert Diana Sends Y’s certificate to Y... <procedure repetead by all mgrs from the chain below Diana and above Bill>... ‘Debbie’ Sg Diana K PUB-Debbie ‘Diana’ Sg Sushil K PUB-Diana ‘Debbie’ Sg Diana K PUB-Debbie Cert Debbie —incl. Debbie’s preCert (top half encr. with K PRIV-Diana ) and Diana’s Cert (bootom half encr. with K PRIV-Sushil ) preCert Debbie

62. 62 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 6 Creating certificates... example – CONT. Bill (Task Leader) (chain: Sushil—Diana—…—Camilla—Bill—Ann) Establishes Posts K PUB-Bill for every subordinate to copy Sends request for certificate to his boss (Camilla) (request encoded with K PUB-Camilla ) Receives certificate from his boss (Camilla) Cert Bill = E(, K PRIV-Camilla ) ‘Bill’ K PUB-Bill Sg Camilla

63. 63 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 7 Certificates for the company example – CONT. Bill receives request for certificate from Z, one of his Engineers Creates M Z = (knows K PUB-Z ) E.g., M Ann = Signs M Z with Sg Bill Encrypts M Z and signature with K PRIV-Bill, producing pre-certificate for Engineer Z: preCert Z = E(, K PRIV-Bill ) E.g., produces pre-certificate for Ann: preCert Ann = E(, K PRIV-Bill ) ‘Ann’ K PUB-Ann Sg Bill preCert Ann

64. 64 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 8 Certificates for the company example – CONT. Bill attaches his Cert Bill to preCert Z, producing certificate for Z: Cert Z = preCert Z || Cert Bill Can become loooong! Cert Bill = preCert Bill || Cert Camilla = preCert Bill || preCert Camilla || Cert... = preCert Bill || preCert Camilla ||... || Cert Debbie = preCert Bill || preCert Camilla ||... || preCert Debbie || Cert Diana (cont.) ‘Ann’ K PUB-Ann Sg Bill preCert Ann

65. 65 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 9 Certificates for the company example – CONT. E.g., if the full certification chain is: Sushil—Diana—Debbie—Ahmet—Camilla—Bill—Ann then the certificate for Ann is: Cert Ann = preCert Ann || preCert Bill || preCert Camilla || preCert Ahmet || preCert Debbie || Cert Diana Notes: - Diana has Cert defined by CEO => no preCert Diana - Cert’s become longer closer to the bottom of hierrarchy After creating Cert Z, Bill sends it to Z E.g., sends Cert Ann to Ann ‘X’ K PUB-X Sg TTP_of_X preCert X

66. 66 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 10 We don’t want such loooong certificates! Note: The “taller” hierarchy the longer certificates Solution: Flatten the certificate hierarchy The ultimate: 1-level „hierarchy: Everybody (in a given organization) gets certificates from a single trusted Certificate Authority (CA) Note: If there is only single CA (not a chain of certifiers), there are no pre-certificates, only (flat) certificates (signed by CA only)

67. 67 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance DIGRESSION — Note and understand these distinctions:  Using asymmetric cryptosystems: encrypt msg / sign msg / encrypt certificate  Encrypt msg – S encrypts (E) with R’s public key  R decrypts msg with R’s private key  Sign msg – to sign a msg, S uses decryption algorithm D with S’s private key  R authenticates signature using encryption algorithm E with S’s public key  Encrypt certificate – after signing a (pre-)certificate, its issuer encrypts (E) the whole (pre-) certficate with his own private key  Anybody who receives certificate can verify it by using decryption alg. D with certificate issuers’ public keys  But only certificate issuer can update a certificate she issued!

68. 68 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 11 Requirements for a certification scheme: 1)Any participant can read Cert to determine X and K PUB-X 2)Any participant can verify that Cert originated from CA (Certificate Authority) and is not counterfeit 3)Only CA can create and update Cert 4)Any participant can verify the currency of Cert (current = not expired) To this end, each Cert must include a timestamp (not discussed by us) Q: Does our scheme satify these requirements? [cf. Stallings - „Cryptography and Network Security”

69. 69 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Certificates to Authenticate Identity – cont. 12 Requirements for a certification scheme: 1)Any participant can read Cert to determine X and K PUB-X 2)Any participant can verify that Cert originated from CA (Certificate Authority) and is not counterfeit 3)Only CA can create and update Cert 4)Any participant can verify the currency of Cert A to the Q: „Does our scheme satify these requirements?” 1)Yes: Can decrypt with K PUB-CA 2)Yes: If can be decrypted with K PUB-CA, must have been encrypted by CA 3)Yes: Only CA can encrypt Cert with K PRIV-CA 4)No, but... Our scheme included no timestamps – but can be easily extended to include them [cf. Stallings - „Cryptography and Network Security”

70. 70 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance d. Trust Without a Single Hierarchy Certificate hierarchy relies on the TTP at the top of the hierarchy TTP is not certified by anybody! Must be very trustworthy If a „natural” hierarchy exists => certificate infrastructure can be based on it E.g., in a company Q: What if there is no „natural” hierarchy to use? E.g., Web sites on the Internet A: Can designate a person/organization as TTP who vouches for authenticity of certificates E.g., a notary public for legal documents E.g., Registrar’s Office for students’ grades

71. 71 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Without a Single Hierarchy – cont. 1 Q: How to find a trusted entity on the Internet? Internet is not a hierarchical organization Despite hierarchy of naming No „top” entity A: Some entities that are widely trusted outside of the Cyberspace, create certification entities in the Cyberspace E.g., C&W HKT, SecureNet, Verisign, eTrust in US Each one is at the „top” Each one has its users who trust it They might (don’t need to!) trust each other I.e., accept each other’s certificates Different people, applications, etc., can and do use different TTPs (CAs) for certification

72. 72 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Trust Without a Single Hierarchy – cont. 2 Considerations for key distribution protocols (such as the ones involving TTP or CA) : What are the operational restrictions? E.g., need for 7/24 operation What are the trust requirements? How are failures dealt with? How efficient is the protocol? How easy to implement is the protocol?... [cf. J. Leiwo]

73. 73 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance AGAIN, remember and understand these distinctions:  Symmetric vs. asymmetric crypto systems  Asymmetric used:  to provide secure channel for exchange of symmetric keys  to encrypt vs. sign vs. whole certificate encryption  Asymmetric crypto system: Encrypt msg vs. sign msg vs. encrypt (pre-)certificate  Encrypt msg – S encrypts (E) with R’s public key  R decrypts msg with R’s private key  Sign msg – to sign a msg, S uses decryption algorithm D with S’s private key  R authenticates signature using encryption algorithm E with S’s public key  Encrypt (pre-)certificate – after signing a (pre-)certificate, certificate issuer encrypts (E) the whole (pre-)certficate with his own private key  Anybody who receives certificate can verify it by using decryption alg. D with certificate issuers’ public keys  But only certificate issuer can update certificates she issued!

74. 74 © 2006-2010 by Leszek T. Lilien Section 4 – Computer Security and Information Assurance Exercise scenarios (“do it yourself”) to see if you understand this well  Symmetric/asymmetric crypto systems  Asymmetric used to exchange symmetric keys  Using asymmetric cryptosystems: encrypt msg vs. sign msg vs. encrypt (pre-)certificate

75. End of Section 4: Introduction to Cryptology – Part 2