slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Requirements - must be able to verify that: 1. Message came from apparent source or author, PowerPoint Presentation
Download Presentation
Requirements - must be able to verify that: 1. Message came from apparent source or author,

play fullscreen
1 / 23
Download Presentation

Requirements - must be able to verify that: 1. Message came from apparent source or author, - PowerPoint PPT Presentation

shada
58 Views
Download Presentation

Requirements - must be able to verify that: 1. Message came from apparent source or author,

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Authentication Requirements - must be able to verify that: 1. Message came from apparent source or author, 2. Contents have not been altered, 3. Sometimes, it was sent at a certain time or sequence. Sometimes we would like to provide authentication without encryption (public statements do not need privacy). Still, authentication requires that the sender know something that the forger does not ( a secret key). Conventional encryption can be used, but the sender must share the secret key with the receiver. 1

  2. Hash Functions • Cryptographic hash functions are used in various contexts, for example, to compute the message digest when making a digital signature. A hash function compresses the bits of a message to a fixed-size hash value in a way that distributes the possible messages evenly among the possible hash values. A cryptographic hash function does this in a way that makes it extremely difficult to come up with a message that would hash to a particular hash value.

  3. Hash Functions • Many good cryptographic hash functions are freely available. The most famous cryptographic hash functions are those of the MD family, in particular MD4 and MD5. MD4 has been broken, and MD5, although still in widespread use, should be considered insecure as well. SHA-1 and RipeMD-160, also of the MD family, are two examples that are still considered sufficiently secure.

  4. 4

  5. 5

  6. (b) Using public-key encryption 6

  7. Key Management • public-key encryption helps address key distribution problems • have two aspects of this: • distribution of public keys • use of public-key encryption to distribute secret keys

  8. Distribution of Public Keys • can be considered as using one of: • Public announcement • Publicly available directory • Public-key authority • Public-key certificates

  9. Public Announcement • users distribute public keys to recipients or broadcast to community at large • eg. append PGP keys to email messages or post to news groups or email list • major weakness is forgery • anyone can create a key claiming to be someone else and broadcast it • until forgery is discovered can masquerade as claimed user

  10. Publicly Available Directory • can obtain greater security by registering keys with a public directory • directory must be trusted with properties: • contains {name, public-key} entries • participants register securely with directory • participants can replace key at any time • directory is periodically published • directory can be accessed electronically • still vulnerable to tampering or forgery

  11. Public-Key Authority • improve security by tightening control over distribution of keys from directory • has properties of directory • and requires users to know public key for the directory • then users interact with directory to obtain any desired public key securely • does require real-time access to directory when keys are needed

  12. Public-Key Certificates • certificates allow key exchange without real-time access to public-key authority • a certificate binds identity to public key • usually with other info such as period of validity, rights of use etc • with all contents signed by a trusted Public-Key or Certificate Authority (CA) • can be verified by anyone who knows the public-key authorities public-key

  13. Public-Key Certificates

  14. Raw “Certificate” has user name, public key, expiration date, ... Raw Cert. MIC Hash Signed Cert. Certificate Authority generates the “signature” that is added to raw “Certificate” 14

  15. Diffie-Hellman Key Exchange • first public-key type scheme proposed • by Diffie & Hellman in 1976 along with the exposition of public key concepts • is a practical method for public exchange of a secret key • used in a number of commercial products

  16. Diffie-Hellman Key Exchange • a public-key distribution scheme • cannot be used to encrypt messages • rather it can establish a common key • known only to the two participants • value of key depends on the participants (and their private and public key information) • security relies on the difficulty of computing discrete logarithms (similar to factoring) – hard

  17. Diffie-Hellman Key Exchange • A primitive root modulo p, prime, is an integer whose powers modulo p generate all the integers from 1 to p-1. • That is, a is a primitive root modulo p, if a mod p, a2 mod p,…, ap-1 mod p are distinct and consist of the integers from 1 through p-1 in some permutation.

  18. Diffie-Hellman Key Exchange • Given an integer 0<b< p and a primitive root a of a prime p, one can find a unique exponent i such that b=ai mod p, where 0<=i<= (p-1) The exponent i is referred to as the discrete logarithm of b for the base a, mod p. The computation of discrete logarithms is “hard”.

  19. Diffie-Hellman Setup • all users agree on global parameters: • large prime integer q • α a primitive root mod q • each user (eg. A) generates their key • chooses a secret key (number): xA < q • compute their public key: yA = αxA mod q • each user makes public that key yA

  20. Diffie-Hellman Key Exchange • shared session key for users A & B is KAB: KAB = αxA.xB mod q = yAxB mod q (which B can compute) = yBxA mod q (which A can compute) • KAB is used as session key in private-key encryption scheme between Alice and Bob • if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys • attacker needs an x, must solve discrete log

  21. Diffie-Hellman Example • users Alice & Bob who wish to swap keys: • agree on prime q=353 and α=3 • select random secret keys: • A chooses xA=97, B chooses xB=233 • compute public keys: • yA=397 mod 353 = 40 (Alice) • yB=3233 mod 353 = 248 (Bob) • compute shared session key as: KAB= yBxA mod 353 = 24897 = 160 (Alice) KAB= yAxB mod 353 = 40233 = 160 (Bob)

  22. Diffie-Hellman Technique Mutual Secret Keys or Public-Private Keys Global Public Elements: q (large prime) and a (a < q) User A‘s Keys: Select secret Xa (Xa < q) Public Key is Ya = a^Xa mod q User B‘s Keys: Select secret Xb (Xb < q) Public Key is Yb = a^Xb mod q Mutual Key is K = Yb ^Xa (B’s calculation) Ya ^ Xb (A’s calculation) No one else knows either Xa or Xb, so they can not find out K 22

  23. Diffie-Hellman as used for a Public-Private System + a and q + message encrypted with “ K” B has to send “ Yb” with message so A can decrypt it. (Ya, a,q are A’s Public Key) “Trudie” does not know Xa: Can not read message. 23