1 / 87

Public Key Infrastructure: A Tutorial

Public Key Infrastructure: A Tutorial. Ravi Mukkamala Department of Computer Science Old Dominion University Norfolk, Virginia, USA mukka@cs.odu.edu. ORGANIZATION. Introduction PKI Architectures Revocation Modes of deployment PKI Alternatives Wireless PKI References. INTRODUCTION.

lani
Télécharger la présentation

Public Key Infrastructure: A Tutorial

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. Public Key Infrastructure: A Tutorial Ravi Mukkamala Department of Computer Science Old Dominion University Norfolk, Virginia, USA mukka@cs.odu.edu

  2. ORGANIZATION • Introduction • PKI Architectures • Revocation • Modes of deployment • PKI Alternatives • Wireless PKI • References

  3. INTRODUCTION

  4. Enterprise PKI

  5. Why PKI? • PKI is not the goal • Scalable security services are the goal • PKI supports scalable security services using public key cryptography

  6. What is PKI? Public/Private key pair The public key is a string of bits A public key certificate answers the following questions (and many more) • Whose certificate is it? • What can it be used for? • Is it still valid? • Example uses: – Is this really the key for Jack Nathan? – Can this key be used to send an encrypted message to John Smith? – Was the key used for digitally signing this document valid at the time of signing? • Fetch me the key of Mike Jones

  7. Security Services That Can BeSupported By PKI • Authentication - Ability to verify the identity of an entity • Confidentiality - Protection of information from unauthorized disclosure • Data Integrity - Protection of information from undetected modification • Non-repudiation - Prevention of an entity from denying previous actions • Key estalishment

  8. A Fully Functional PKI • Certification authority • Certificate repository • Certificate revocation • Key backup and recovery • Automatic key update • Key history management • Cross-certification • Support for non-repudiation • Time stamping • Client software

  9. Secret Key Cryptography • Classical form of cryptography • Single key used to encrypt and decrypt data • Strengths –Very fast relative to public key cryptography –Relatively short keys • Weakness: Key must be shared among interested parties

  10. Public Key Cryptography • Each entity has a PAIR of mathematically related keys – Private Key - known by ONE – Public Key - known by Many • Not feasible to determine Private Key from Public Key • Strength – no shared private keys • Weakness – Relatively slow – Requires longer keys for same level of security

  11. Public Key Cryptography (cont.) • Public key is best suited to – Digital signatures (e.g., RSA and DSA) – Key Management • Key transfer (e.g., RSA) • Key agreement (e.g., Diffie-Hellman)

  12. encryption algorithm message encryptionkey Transmission Channel decryption algorithm decryptionkey message Cryptography

  13. Public Key Cryptosystem (RSA) • A public encryption method that relies on a public encryption algorithm, a public decryption algorithm, and a public encryption key. • Using the public key and encryption algorithm, everyone can encrypt a message. • The decryption key is known only to authorized parties. • Asymmetric method. • Encryption and decryption keys are different; one is not easily computed from the other.

  14. Public Key Cryptosystem (RSA) • and q are two prime numbers. • n = pq • m = (p-1)(q-1) • a is such that 1 < a < m and gcd(m,a) = 1. • b is such that (ab) mod m = 1. • a is computed by generating random positive integers and testing gcd(m,a) = 1 using the extendedEuclid’s gcd algorithm. • The extended Euclid’s gcd algorithm also computes b when gcd(m,a) = 1.

  15. RSA Encryption And Decryption • Message M < n. • Encryption key = (a,n). • Decryption key = (b,n). • Encrypt => E = Ma mod n. • Decrypt => M = Eb mod n.

  16. Breaking RSA • Factor n and determine p and q, n = pq. • Now determine m = (p-1)(q-1). • Now use Euclid’s extended gcd algorithm to compute gcd(m,a). b is obtained as a byproduct. • The decryption key (b,n) has been determined!

  17. Security Of RSA • Relies on the fact that prime factorization is computationally very hard. • Let q be the number of bits in the binary representation of n. • No algorithm, polynomial in q,is known to find the prime factors of n. • Try to find the factors of a 100 bit number.

  18. Why Do We Need Certificates? • Associate the public key with a name or entity • What is this key good for? – Signatures or encryption? – Authorization – Secure mail, secure web, or digital signatures – How can I trust it?

  19. Example Public Key Certificate

  20. A Certificate with Policy Information

  21. Problems with Identity Certificates • Which “Don Smith?” does this certificate corresponds to? • Suppose there are two “Don Smith” s in the same organization, how do we know to whom a given certificate belongs? • Where directory do we look up for “Don Smith?” • Examples: • PGP: Used for email encryption • Identity is name + email address • SPKI: Used for authorization/access control • Identity is a name meaningful within the domain of application • Account name on a server • Credit card number • Merchant ID • PGP and SPKI also use the public key as a unique ID

  22. More on Public Key Certificates • Features – Tamper-evident – Issued by a Trusted third party (TTP) called CA – Complete user identification – Fixed expiration • Drawbacks – Must trust issuer

  23. X.509: A Standard for PKI • Defined and standardized a general, flexible certificate format. • Three nested components in an X.509 certificate • Tamper evident envelop (outer most) • Basic certificate contents • Certificate extensions (options)

  24. Tamper-evident Envelop • Thecertificate (contents) • signatuerAlgorithm (DSA with SHA-1) • signaturevalue

  25. Basic Certificate Contents • Version • Serialnumber • Signature (algorithm identifier: DSA with SHA-1)Issuer • Validity • Subject (Name) • Subject PublicKeyInfo • IssueruniqueID (optional) • subjectuniqueID (optional)

  26. Certificate Extensions • Subject type (CA or end entity) • Names and identity information • Key attributes • Policy information • Additional information • CRL distribution points • Freshest CRL • Authority (CA) information access

  27. X.509 Certificate Usage Model Relying party wants to verify a signature • Fetch certificate • Fetch certificate revocation list (CRL) • Check certificate against CRL • Check signature using certificate

  28. An Example Certificate Usage

  29. PKI ARCHITECTURES

  30. Conventional PKI Architecture

  31. PKI Architectures • Single CA • Hierarchical PKI • Mesh PKI • Trust lists (Browser model) • Bridge CAs

  32. Single CA • A CA that issues certificates to users and systems, but not to other CAs – Easy to build – Easy to maintain – All users trust this CA – Paths have one certificate and one CRL – Doesn’t scale particularly well

  33. Hierarchical PKI • CAs have a hierarchical relationship (as in a tree) • All CAs trust the root CA • Root CA certifies its child CAs, and they in turn certify their child CAs, and so on. • Easy to establish/verify trust relationship between any two CAs

  34. Strict Hierarchy of CAs

  35. Mesh PKI • CAs have peer-to-peer relationships • Users trust the CA that issued their certificates

  36. Trust lists (Browser) • User trusts more than one CA • Each CA could be a single CA or part of a PKI – For hierarchies, should be the root – For mesh PKIs, could be any CA

  37. Bridge CA • Designed to address the shortcomings of the trust lists and cross-certified enterprise architecture • To unify many PKIs into a single PKI---acts as a sort of trust arbitrator • If the trust domain is implemented as a hierarchical PKI, the bridge CA will establish a relationship with the root CA • If the domain is implemented as a mesh, the bridge will establish a relationship with one of its CAs.

  38. Cross-certification • CA of one organization being certified (for trust purposes) by another CA of a different organization • Peer-to-peer relationships among CAs • Appropriate when a small number of enterprise PKIs intend to establish trust relationships

  39. A Certificate Chain

  40. Attribute Certificates vs. Identity Certificates • A certificate may simply bind a public key with a name • Or bind a set of attributes with a name and public key. • These are more likely to be revoked since attributes are more likely to be changed than the name/key. • Certificate becomes too long with description of all attributes

  41. PKI Design Guidelines • Identity • Use a locally meaningful identifier • User name, email address, Account number • If possible, design your PKI so that revocation isn’t required • Alternately, use a mechanism which provides freshness guarantees • Application-specific PKIs • SPKI Binds a key to an authorization • X.509 binds a key to an (often irrelevant) identity which must then somehow be mapped to an authorization • PGP is designed to secure email

  42. Certificate Revocation

  43. Certificate Revocation Revocation is managed with a certificate revocation list (CRL), a form of anti-certificate which cancels a certificate • Equivalent to the old credit card blacklist booklets – Relying parties are expected to check CRLs before using a certificate – “This certificate is valid unless you hear somewhere that it is not”

  44. CRL Problems CRL problems mirror credit card blacklist problems • Not issued frequently enough to be effective against an attacker • Expensive to distribute • Vulnerable to simple DOS attacks – Attacker can prevent revocation by blocking CRL delivery CRLs add further problems of their own • Can contain retroactive invalidity dates • CRL issued right now can indicate that a cert was invalid last week – Checking that something was valid at time t isn’t sufficient to establish validity – Back-dated CRL can appear at any point in the future • Destroys the entire concept of non-repudiation

  45. CRL Distribution Problems • CRLs have a fixed validity period – Valid from issue date to expiry date • At expiry date, all relying parties connect to the CA to fetch the new CRL – Massive peak loads when a CRL expires (DDOS attack) • Issuing CRLs to provide timely revocation exacerbates the problem – 10M clients download a 1MB CRL issued once a minute = ~150GB/s traffic

  46. More on certificate revocation • Many applications require prompt revocation • CAs (and X.509) don’t really support this • CAs are inherently an offline operation • Requirements for online checks • Should return a simple boolean value “Certificate is valid/not valid right now” • Can return additional information such as “Not valid because …” • •Historical query support is also useful, “Was valid at the time the signature was generated” • Should be lightweight

  47. On-line Status Checking Protocol (OCSP) • Inquires of the issuing CA whether a given certificate is still valid – Acts as a simple responder for querying CRLs – Still requires the use of a CA to check validity • OCSP acts as a selective CRL protocol • Standard CRL process: “Send me a CRL for everything you’ve got” • OCSP process: “Send me a pseudo-CRL/OCSP response for only the specified certificates” • Lightweight pseudo-CRL avoids CRL size problems • Reply is created on the spot in response to the request • Ephemeral pseudo-CRL avoids CRL validity period problems • Requires a signing operation for every query

  48. On-line Status Checking (cont.) Problems arise to some extent from the CRL-based origins of OCSP • CRL can only report a negative result • “Not revoked” doesn’t mean a cert was ever issued • Some OCSP implementations will report “I can’t find a CRL” as “Good” • Some relying party implementations will assume “revoked” as “not good”, so any other status = “good”

More Related