1 / 16

CMSC 414 Computer and Network Security Lecture 21

CMSC 414 Computer and Network Security Lecture 21. Jonathan Katz. Revocation. Revocation is a key component of a PKI Secret keys stolen/compromised, user leaves organization, etc. This is in addition to expiration dates included in certificates

russoc
Download Presentation

CMSC 414 Computer and Network Security Lecture 21

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 21 Jonathan Katz

  2. Revocation • Revocation is a key component of a PKI • Secret keys stolen/compromised, user leaves organization, etc. • This is in addition to expiration dates included in certificates • Certificate might need to be revoked before expiration date • Expiration dates improve efficiency

  3. Cert. revocation lists (CRLs) • CA issues signed list of (un-expired) revoked keys • Must be updated and released periodically • Must include timestamp • Verifier must obtain most recent CRLs before verifying a certificate • Using “delta CRLs” improves efficiency

  4. OLRS • “On-line revocation server” • Verifier queries an OLRS to find out if a certificate is still valid • If OLRS has its own key, it can certify that a certificate is valid at a certain time

  5. “Good lists” • The previous approaches basically use lists of “bad” certificates • Also possible to use a list containing only “good” certificates • Likely to be less efficient

  6. Directories • PKIs do not require directories • Users can store and present their own certificate chains to a trust anchor • Directories can make things easier, and enable non-interactive setup

  7. Finding certificate chains • Two approaches: work “forward” from target toward a trust anchor, or “backward” from trust anchor to target • The better approach depends on implementation details • For example, in system with name constraints, easier to work “backward”

  8. Anonymity

  9. Anonymity vs. pseudonymity • Anonymity • No one can identify the source of any messages • Can be achieved via the use of “persona” certificates (with “meaningless” DNs) • Pseudonymity • No one can identify the source of a set of messages… • …but they can tell that they all came from the same person

  10. Levels of anonymity • There is a scale of anonymity • Ranges from no anonymity (complete identification), to partial anonymity (e.g., crowds),to complete anonymity • Pseudonymity is an orthogonal issue…

  11. Anonymizers • Proxies that clients can connect to, and use to forward their communication • Primarily used for email, http • Can also provide pseudonymity • This may lead to potential security flaws if mapping is compromised • Must trust the anonymizer… • Can limit this by using multiple anonymizers

  12. Traffic analysis • If messages sent to remailers are not encrypted, it is easy to trace the sender • Even if encrypted, may be possible to perform traffic analysis • Timing • Message sizes • Replay attacks

  13. Http anonymizers • Two approaches • Centralized proxy/proxies • “Crowds…”

  14. Implications of anonymity? • Is anonymity good or bad? • Unclear… • Can pseudonymity help?

  15. “Cookies” • Cookies are tokens containing state information about a transaction • May contain (for example): • Name/value; expiration time • Intended domain (cookie is sent to any server in that domain) • No requirement that cookie is sent by that domain

  16. Security violations? • Cookies potentially violate privacy • E.g., connecting to one server results in a cookie that will be transmitted to another • Storing authentication information in a cookie is also potentially dangerous (unless cookie is kept confidential, or other methods are used)

More Related