1 / 19

Intro To Secure Comm. Exercise 3

Intro To Secure Comm. Exercise 3. Problem. The following scenario is suggested for establishing session keys Alice and Bob share a secret (key phrase/password) Alice generates Session key K and send E P (K) to Bob Bob receives E P (K), deciphers and uses K as the new session key.

teegan-tran
Télécharger la présentation

Intro To Secure Comm. Exercise 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Intro To Secure Comm.Exercise 3

  2. Problem • The following scenario is suggested for establishing session keys • Alice and Bob share a secret (key phrase/password) • Alice generates Session key K and send EP(K) to Bob • Bob receives EP(K), deciphers and uses K as the new session key. • What are the threats to the model? • Is this solution secure against an eavesdropper?

  3. Solution • The solution is problematic when a password is used. • Passwords are susceptible to dictionary attack. • The eavesdropper may discover p and thus the session key k (and may discover any other session keys) • Suggest a better protocol

  4. Solution • Alice Generates pubA and privA. • Alice sends EP(pubA) to Bob • Bob deciphers and sends to Alice PubA(k) • Alice sends to Bob Ek(challengeA) • Bob responds Ek(challengeA||challengeB) • Alice responds (challengeB) • What cryptographic method is E?

  5. Solution • The cryptographic method is a MAC • Why not simply use an encryption method?

  6. Problem • Some designs attempt to provide message authentication by sending the encryption of the message concatenated with its hash (or simply with an error detection code). • Namely, they send Encrypt(Message||Hash(Message)),and hope that in so doing, they achieve encryption and authentication together. • Show that this design is insecure (an attacker can modify a message and it would still be considered authentic). • Hint: this is easy to show, when using one-time-pad or OFB mode encryption.

  7. Solution • Assuming OTP is used and ADV knows some information about the message. • ADV knows the algorithm, so knows which hash function is used. • Knowing so, he can figure out the key encrypting the message (known plain text). • Since he knows the message and hash of the message, he can figure out the key encrypting the hash. • ADV can now calculate new message and new hash for the message and replace them.

  8. Solution • ADV’s playout: • km=mcm (revealing the key of m) • kh(m)=h(m) ch(m) • Forge: m’km||h(m’)kh(m) • This is a poor MAC because it isn’t even immune to KMA.

  9. Problem • Often CAs are single entities which provide • user registraion/identification • certificate creation • What may be the problems associated with that model?

  10. Solution • CA may be single point of failure • CA may not be able to supply the demand • CA may be easier to corrupt/perform DOS

  11. Registration Authority • CA combines two functions: • Validate identity of source of public key • Sign public key with attributes (identity, others) • CA secret key required only to sign cert • Identify by separateregistration authority • Exercise: motivate byanalyzing threat!

  12. RA – Registration Authority • Also called LRA – Local RA • Goal: Off-load some work of CA to LRAs • Support all or some of: • Identification • User key generation/distribution • passwords/shared secrets and/or public/private keys • Interface to CA • Key/certificate management • Revocation initiation • Key recovery

  13. CA – Certification Authority • Issuer/Signer of the certificate • Binds public key w/ identity+attributes • Enterprise CA • Individual as CA (PGP) • Web of trust • “Global” or “Universal” CAs • VeriSign, Equifax, Entrust, CyberTrust, Identrus, … • Trust is the key word

  14. Problem • Define the threats to the above model • What type of threats/ADV can harm the solution?

  15. Solution • External Attackers • Operators • Viruses controlling CA pc’s

  16. Secure Hardware Alice, PA Sign(PrivCA,(Alice,PA)) Enter PINor smartcard Operator Alice proves her identity And provides PA Sign(PrivCA,(Alice,PA)) Alice (subject)

  17. Problem • What may be the problem of the secured hardware box?

  18. Solution • Lack of UI at the hardware • Trojan may send bogus certificates than what the operator approved • Hardware only certifies one certificate per smartcard (good thing) but wrong certificate may still be used.

  19. A better solution • Integrate UI with secure hardware • Secure log to go over issues/suspected certificates • What if found a “corrupted” certificate? • May revoke it by publishing CRL

More Related