1 / 22
Download Presentation

CMSC 414 Computer (and Network) Security Lecture 24

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. CMSC 414Computer (and Network) SecurityLecture 24 Jonathan Katz

  2. Administrative stuff… • Please fill out course evaluation • On line • Link from course homepage • Brief remarks on project…

  3. Otway-Rees • AB: NC, KA(NA, NC, Alice, Bob) • BKDC: KA(…), KB(NB, NC, Alice, Bob) • KDC checks that NC is the same… • KDCB: NC, KA(NA, KAB), KB(NB, KAB) • BA: KA(…) • AB: KAB(timestamp) • Note: KDC already authenticated Bob

  4. Analysis? • NC should be unpredictable, not just a nonce • Otherwise, can impersonate B to KDC • Send first message: (next NC), “garbage” • B forwards to KDC along with encryption of the next NC • Next time A initiates a conversation, replay previous message from B

  5. More about nonces… • Important to understand what qualities the nonce needs to satisfy in order for protocol to be secure • Used once? Unpredictable? Random? • Note that long random nonces have negligible probability of being re-used • E.g., challenge-response or reverse challenge-response

  6. A word about “random” • Random numbers needed for all of cryptography • Difficult to generate “good” random numbers • Possibilities: • “Real” (i.e., hardware) RNG • Cryptographic/non-cryptographic PRNG • Must use long (random, unpredictable) seed!! • Generate from user behavior

  7. Authentication tokens • Authentication may be based on: • What you know (e.g., passwords) • What you have (e.g., token) • What you are (e.g., biometrics) • Best security practice is to combine two (or more) of these… • Using tokens/biometrics alone is useless without a secure protocol!

  8. Authentication tokens • Advantages • Difficult to reproduce • Can “store” larger secrets • Psychological barrier to giving out your token • Disadvantages • Can be stolen • Combine with PIN/password • Can be lost • Expensive; may require custom hardware

  9. Authentication tokens • Magnetic stripe card • Simply records data and later reveals it • Non-trivial, but not too difficult, to copy • “Smart card” • Embedded CPU/memory • Carries out an interactive protocol

  10. Smart cards • PIN protected memory card • Information on card can be read only with correct PIN • After many wrong guesses, card “locks” itself • “Crypto” card • Card stores key used to perform cryptographic operations (perhaps only with correct PIN) • Tamper resistant --- impossible to obtain key or duplicate card

  11. Smart cards • Readerless smart card • Card interacts directly with the user via keyboard and/or monitor interface • E.g., secureID • Does not require special hardware

  12. Biometrics (briefly) • “What you are…” • Many possibilities: • Fingerprints/handprints • Retinal scans • Etc.

  13. Notes about biometrics • Insecure if biometric data sent in the clear! • Need to use cryptographically-secure protocol • Not clear how to use biometric data as a cryptographic key • Data changes slightly every time it is scanned • Data is not random, although it has high entropy

  14. Note about biometrics • Biometric data can be forged! • E.g., fingerprints…

  15. Review: checklist • Whether eavesdropping, posing as either party, or acting as a “man-in-the-middle”, an attacker should be unable to: • Learn the contents of messages • Insert messages • “Hijack” a conversation between two parties • Impersonate either party, or learn information allowing impersonation in the future • Perform an off-line dictionary attack (ideally)

  16. Continued… • In addition, when posing as either party an attacker should be unable to: • Trick the other party into “doing something useful” (e.g., signing an arbitrary message)

  17. Continued… • If the server’s database is compromised (and even if further eavesdropping occurs), an attacker should be unable to: • Impersonate the user to this server (ideally; not always the case --- recall that an off-line dictionary attack is always possible) • Impersonate the user to other servers • Decrypt old conversations (forward secrecy)

  18. Final remark • It is not always necessary to achieve all these goals • If shared secret is cryptographically strong, off-line password guessing is not a concern • In some environments, certain attacks may be less feasible and therefore not a concern

  19. An overview of network security

  20. Network layers • Application • Transport • Network • Data link • Physical

  21. Examples • Application layer: PGP, SSH • Transport layer: SSL/TLS • Network layer: IPSec • Not usually done at the data link level… • Can’t really be done at the physical level

  22. Security in what layer? • Depends on the purpose… • What information needs to be protected? • What is the attack model? • Who shares keys in advance? • Should the user be involved? • E.g., a network-layer protocol cannot authenticate two end-users to each other • Also affects efficiency, ease of deployment

More Related