Presentation is loading. Please wait.

Presentation is loading. Please wait.

Public Key Infrastructure: A Tutorial

Similar presentations

Presentation on theme: "Public Key Infrastructure: A Tutorial"— Presentation transcript:

1 Public Key Infrastructure: A Tutorial
Ravi Mukkamala Department of Computer Science Old Dominion University Norfolk, Virginia, USA

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


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 Be Supported 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 Cryptography Transmission Channel decryption algorithm
encryption algorithm message Transmission Channel encryption key decryption key Mobile environments need low cost (battery usage) encryption/decryption.

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.


15 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 extended Euclid’s gcd algorithm. The extended Euclid’s gcd algorithm also computes b when gcd(m,a) = 1.

16 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.

17 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!

18 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.

19 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?

20 Example Public Key Certificate

21 A Certificate with Policy Information

22 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 encryption Identity is name + 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

23 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

24 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)

25 Tamper-evident Envelop
Thecertificate (contents) signatuerAlgorithm (DSA with SHA-1) signaturevalue

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

27 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

28 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

29 An Example Certificate Usage


31 Conventional PKI Architecture

32 PKI Architectures Single CA Hierarchical PKI Mesh PKI
Trust lists (Browser model) Bridge CAs

33 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

34 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

35 Strict Hierarchy of CAs

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

37 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

38 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.

39 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

40 A Certificate Chain

41 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

42 PKI Design Guidelines Identity Use a locally meaningful identifier
User name, 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

43 Certificate Revocation

44 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”

45 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

46 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


48 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

49 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

50 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”

51 Revocation Status Checking in the Real World
In practice, revocation checking is turned off in user software Serves no real purpose, and slows everything down a lot CRLs are useful in special-case situations where there exists a statutory or contractual obligation to use them Relying party needs to be able to claim CRL use for diligence purposes or to avoid liability

52 Authorization check instead of Revocation Check
SPKI: An example: Prefers online authorization/validation checks • Positive assertions are more tractable than negative ones Cert renewal interval is based on risk analysis of potential Losses X.509 renewal interval is usually one year, motivated by billing concerns Treated like a domain name: Once a year, re-certify the same key Provides for one-time renewal Cert is valid for a single transaction

53 Other Trust Models Strict Hierarchy Hierarchy Bridge
Multiple Trust Anchors Mesh (Anarchy) Combination

54 Example CRL

55 X.509 Version 2 CRL Structure

56 Certificate revocation schemes
Full CRL Delta CRL Over-issued CRL Indirect CRL Certification revocation status (CRS) Certification revocation trees (CRT) On-line certificate status protocol

57 Privilege management Alternative Pros Cons
Application Based Access Control Easy to implement Does not require additional infrastructure (saves infrastructure cost) Need to manage privileges on application by application basis Synchronization of privileges may be hard as there are more and more applications and they are distributed Security may be compromised if privileges not removed from all applications Operational cost Public Key Certificate Easy to add to PKI Privileges can be easily managed by revoking certificate Change in privileges requires revocation of identity certificate Parties issuing identity certificate may not have authority to bestow privileges Attribute Certificate Privileges can be easily managed by revoking attribute certificates Change in privilege does not require revocation of public key certificate Cost of PMI

58 Modes of Deployment

59 Critical Factors in Running an Enterprise PKI
PKI functionality. An enterprise PKI must be based on a modular design that includes reliable, high-performance support for certificate issuance and lifecycle management, protocols and processing capabilities for diverse certificate types, comprehensive administration functions, records retention, directory integration, and key management. Ease of integration. To minimize costs, leverage existing investments, and ensure compatibility in diverse environments, enterprises should choose a PKI that integrates easily with all the new and legacy applications it is intended to support. Availability and scalability. The PKI must be available to its user community around-the-clock. In addition, it must be able to scale to millions of users, if necessary, to keep up with enterprise growth. Security and risk management. To preserve trust and minimize financial and legal liability, enterprises running an Internet-based PKI must safeguard the PKI infrastructure, private keys, and other valuable assets from network-based attacks and threats to the physical facility housing the assets. Expertise. To ensure that the PKI is properly deployed, maintained, and protected, enterprises should have security professionals who are extensively trained in PKI.

60 Two models of deployment
In-House Deployment of Standalone PKI Software In an in-house deployment, an enterprise purchases standalone PKI software and create a standalone PKI service. In this scenario, the enterprise assumes 100% responsibility for provisioning, deploying, and maintaining the PKI as well as all the surrounding technology, including systems, telecommunications, and databases. The enterprise is also responsible for providing a secure facility. A secure facility must have physical site security, Internet-safe network configurations, redundant systems, disaster recovery, viable PKI legal practices, financially sound liability protection, and highly trained personnel. If any of these components are weak, the enterprise may be compromised.

61 Outsourced Deployment to an Integrated PKI Platform
In an outsourced deployment to an integrated PKI platform, an enterprise delegates PKI construction, deployment, and maintenance to a trusted third party whose services include certificate processing, root key protection, and security and risk management.

62 Verisign’s managed PKI

63 Managed PKI vs. Standalone PKI
PKI functionality Ease of integration Availability and scalability Security and risk management Personnel Scope of operation

64 PKI Alternatives

65 Deficiencies in Conventional PKI
The Hierarchical Model of Trust Hierarchy of trust model Private key insecurity Technical and implementation weaknesses Limited assurance provided

66 Comparison of Certificate Types
Certification authority: X.509: Naming authority hierarchies; cross-certification; CPS PGP: Web of trust: multiple path of certification, to achieve fault tolerance in compensation for the fact that amateur certifiers are signing certificates SPKI/SDSI: Single naming authority; no CPS necessary 

67 Identifier type: X.509: Global by original definition, but local in practice PGP: Global  [ name, globally unique but maybe not persistent] SPKI/SDSI: Local  [arbitrary]

68 IBE: Identity-based Encryption
A system that uses an address to create a public and private pair of keys for traditional encrypted . Public key is created using a recipient’s address and public system parameters. The private key is created using the recipient’s address and both public and private system parameters. IBE is different from -based identification and authentication in that IBE is encryption-based, but an organization could use -based identification and authentication (EBIA) to distribute IBEcreated private keys. Authentify ( has developed a system to authenticate users based on their ability to receive a telephone call at a pre-designated telephone number. PGP Inc.’s ( PGP 8.0 Universal security appliance can be configured to automatically create a public/private key pair for recipients of messages not registered with the system. Instead of receiving an encrypted , the users are sent a link that can be used to access the appliance’s built-in Web mail server. The sender can further protect the message by creating a passphrase.

69 IBE-based PKI

70 Email-Based Identification and Authentication (EBIA): An Alternative to PKI
-based identification and authentication is an emerging alternative to public-key infrastructure. It overcomes many problems inherent with traditional authentication techniques, such as social security numbers, and provides functional security when used within a limited context. This identification–authentication regime is not based on public-key cryptography, but instead on the ability to receive sent to a particular address.

71 Some reasons for PKI’s poor adaptability
Usability (harder to use than simple names and passwords) and cost users must purchase certificates) Identification and authorization are certainly two requirements for e-business, but PKI does not adequately satisfy other e-business requirements: delegation For example, the US Armed Forces has deployed roughly 4 million client-side certificates. Nevertheless, many mission-critical Web sites—especially those used in combat situations—rely on user name–password authentication precisely because individuals can share user names and passwords without prior arrangement [Garfinkel 2003].

72 EBIA Nearly every major Web service provider, including eBay, PayPal, Amazon, Yahoo, and Apple, among others, has deployed some form of EBIA. Today, the primary use of EBIA is in systems that let users recover lost or forgotten Web passwords. Other EBIA systems facilitate password resets by sending users an HTML link; when users click on the link, their Web browser opens to a page that lets them create a new password. Similarly, many Web sites now require people registering with them to use their primary address as their user name. This practice overcomes a common but important problem for Web sites: namespace collisions.

73 Total cost of ownership of Voltage IBE vs. PKI
TCO model: Direct costs which include the cost of labor related to ownership of the technology. Platform costs such as the cost of software, hardware and other technology components. User productivity costs Voltage IBE™ is a public key cryptography system that uses common identities (such as an address or screen name) as public keys, eliminating the need for certificates, Certificate Revocation Lists (CRL) and other costly infrastructure. Results in a solution that is easy to implement and easy to manage, without the overhead and cost inherent in traditional security solutions. Ideal for use with financial services customers and medical patients who expect communication to be kept private and secure and also want ease-of-use and low-cost. Voltage IBE solutions are: • Easy to implement and easy to manage – eliminates the overhead and costs inherent in traditional security solutions such as PKI • Highly scalable – no storage of keys or messages, and no need to contact online servers; allows the solution to scale dramatically without the need for additional infrastructure • Easy to use – no need for end users to worry about keys, certificates or multiple inboxes.

74 Voltage IDE vs. PKI The research findings include:
Overall, the TCO of a typical Voltage IBE system is one-third the TCO of a typical PKI system. The Voltage IBE system needs a far simpler infrastructure than does a typical PKI system, meaning fewer servers and easier installation. Operations costs for a typical Voltage IBE system are one-fifth those of a typical PKI system. User productivity losses for the Voltage IBE system are one-third those of a typical PKI system.

75 Wireless PKI

76 Wireless PKI Need for wireless PKI: M-commerce is growing at a fast pace. The revenues generated through M-commerce are expected to grow at a faster rate. They need a wireless trusted solution. Since wireless communication is broadcast, the need for security (authentication, confidentiality, access control, non-repudiation, and integrity) is higher than that of wired communication.


78 What is a Wireless PKI? " The fundamentals of a PKI do not change.
" Wireless PKI is not necessarily completely wireless. " Efficient operations in mobile devices should be considered. Devices: Less powerful CPU, less memory, restricted power consumption, smaller displays Wireless networks: Low BW, long latency, less connection stability, less predictable availability. Hence, encoding rules, certificate format, crypto algorithms, and key size need to be optimized.


80 Trust-based approach to WPKI (USC)
Basic WPKI architecture: A new PKI portal serves as a wireless RA CA modified for wireless certificate management New Bridge CA is needed for trust management across the boundary between wired and wireless PKI domains Wireless gateway: Bridge between WTLS and SSL Directory server: Repository of certificates; mobile hosts do not store certificates; instead they store a URL to the store WTLS mini-certificates are much smaller than PKI

81 Trust propagation models for Building PKI systems
Trust models: Hierarchical PKI Mesh PKI Hybrid PKI PKI using a bridge CA PKI using trust lists

82 Bridge CA architecture
Most appropriate for wired and wireless domains Outperforms in: scalability, interoperability, and robustness A cluster could implement bridge CA Each participating CA establishes a cross certificate with the central bridge CA (2n certificates for n domains) Each principal CA issues a cross-certificate to the BCA and asserts its own domain policy to map the BCA policies.

83 In addition, server side OCSP server has been suggested
New Components in WPKI Three functional units are considered new in the WPKI expansion: wireless PKI portal---essentially a wireless RA wireless CA ---certificate mgmt. in wireless environment bridge CA In addition, server side OCSP server has been suggested

84 Design choices Wireless CA: Wireless PKI portal: Clustered Bridge CA:
Participating PKIs: Security features: Cross-certificate issue, update, renew, revoke, path discovering, Security policy manipulation, Inter-domain access control Wireless CA: Client: Certificate Issue, update, renew, and revoke, Client certificate request handling, Certificate status inquiry/response Other PKI: Interact with other X.509 PKI, Directory certificate publish Wireless PKI portal: Client: Certificate request forwarding, Wireless certificate requests, Client certificate URLs in LDAP Other PKIs: Interact with X.509 PKI

85 Functionalities and Advantages of a Bridge CA Cluster
Support the cross-certificate registration from the wireless CAs Support the cross-certificate registration from wired CAs Support WTLS certificate and X.509 certificate path discovery and trust management Cross-certificate/CRL management Interoperability with directory through LDAP Policy reconfiguration and management Distinct advantages over the Wired Bridge CA architecture: Scalability: The Bridge CA cluster can scale freely in establishing the trust relationships between multiple CAs associated with different PKI domains. Heterogeneous certificates: WTLS mini Certificate and the X.509 Certificate are supported and thus offering higher application potential. Higher availability: The BCA cluster architecture has failover and recovering capability after any failure of any individual root CA attached to the bridge. Low implementation cost: The certificate path discovery and interoperability support grow in a pairwise peer-to-peer fashion, thus reducing the implementation costs.

86 References 1. P. Guttman, “Everything you Never Wanted to Know about PKI but were Forced to Find Out,” ??? 2. S.L. Garfinkel, “ -Based Identification and Authentication: An Alternative to PKI?,” IEEE Security & Privacy, Nov/Dec 2005. 3. T. Polk, Introduction to Public Key Infrastructure, January, 2005 4. Tutorials

87 References (Cont.) 5. Managed PKI
6. Alternates to PKI 7. Wireless PKI Everything about wireless PKI wireless PKI overview and then detail explanation

Download ppt "Public Key Infrastructure: A Tutorial"

Similar presentations

Ads by Google