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

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

30. PKI ARCHITECTURES

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