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 bitsA 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 entityConfidentiality - Protection of information from unauthorized disclosureData Integrity - Protection of information from undetected modificationNon-repudiation - Prevention of an entity from denying previous actionsKey estalishment
8 A Fully Functional PKI Certification authority Certificate repository Certificate revocationKey backup and recoveryAutomatic key updateKey history managementCross-certificationSupport for non-repudiationTime stampingClient software
9 Secret Key Cryptography Classical form of cryptographySingle key used to encrypt and decrypt dataStrengths–Very fast relative to public key cryptography–Relatively short keysWeakness: 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 ManyNot feasible to determine Private Key from Public KeyStrength – no shared private keysWeakness– 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 ManagementKey transfer (e.g., RSA)Key agreement (e.g., Diffie-Hellman)
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 = pqm = (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 RSARelies 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 entityWhat is this key good for?– Signatures or encryption?– Authorization– Secure mail, secure web, or digital signatures– How can I trust it?
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 encryptionIdentity is name + addressSPKI: Used for authorization/access controlIdentity is a name meaningful within the domain of applicationAccount name on a serverCredit card numberMerchant IDPGP 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 PKIDefined and standardized a general, flexible certificate format.Three nested components in an X.509 certificateTamper evident envelop (outer most)Basic certificate contentsCertificate extensions (options)
25 Tamper-evident Envelop Thecertificate (contents)signatuerAlgorithm (DSA with SHA-1)signaturevalue
27 Certificate Extensions Subject type (CA or end entity)Names and identity informationKey attributesPolicy informationAdditional informationCRL distribution pointsFreshest CRLAuthority (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
32 PKI Architectures Single CA Hierarchical PKI Mesh PKI Trust lists (Browser model)Bridge CAs
33 Single CAA 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 CARoot 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
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 CADesigned to address the shortcomings of the trust lists and cross-certified enterprise architectureTo unify many PKIs into a single PKI---acts as a sort of trust arbitratorIf the trust domain is implemented as a hierarchical PKI, the bridge CA will establish a relationship with the root CAIf the domain is implemented as a mesh, the bridge will establish a relationship with one of its CAs.
39 Cross-certificationCA of one organization being certified (for trust purposes) by another CA of a different organizationPeer-to-peer relationships among CAsAppropriate when a small number of enterprise PKIs intend to establish trust relationships
41 Attribute Certificates vs. Identity Certificates A certificate may simply bind a public key with a nameOr 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 numberIf possible, design your PKI so that revocation isn’t requiredAlternately, use a mechanism which provides freshness guaranteesApplication-specific PKIsSPKI Binds a key to an authorizationX.509 binds a key to an (often irrelevant) identity which must then somehow be mapped to an authorizationPGP is designed to secure
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 deliveryCRLs add further problems of their own• Can contain retroactive invalidity dates• CRL issued right now can indicate that a cert was invalid lastweek– 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 revocationCAs (and X.509) don’t really support thisCAs are inherently an offline operationRequirements for online checks• Should return a simple boolean value “Certificate is valid/notvalid 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 validityOCSP acts as a selective CRL protocolStandard 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 problemsReply is created on the spot in response to the requestEphemeral pseudo-CRL avoids CRL validity period problemsRequires a signing operation for every query
50 On-line Status Checking (cont.) Problems arise to some extent from the CRL-based origins of OCSPCRL can only report a negative result“Not revoked” doesn’t mean a cert was ever issuedSome 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 softwareServes no real purpose, and slows everything down a lotCRLs are useful in special-case situations where there exists a statutory or contractual obligation to use themRelying 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 onesCert renewal interval is based on risk analysis of potentialLossesX.509 renewal interval is usually one year, motivated by billing concernsTreated like a domain name: Once a year, re-certify the same keyProvides for one-time renewalCert is valid for a single transaction
56 Certificate revocation schemes Full CRLDelta CRLOver-issued CRLIndirect CRLCertification revocation status (CRS)Certification revocation trees (CRT)On-line certificate status protocol
57 Privilege management Alternative Pros Cons Application Based Access ControlEasy to implementDoes not require additional infrastructure (saves infrastructure cost)Need to manage privileges on application by application basisSynchronization of privileges may be hard as there are more and more applications and they are distributedSecurity may be compromised if privileges not removed from all applicationsOperational costPublic Key CertificateEasy to add to PKIPrivileges can be easily managed by revoking certificateChange in privileges requires revocation of identity certificateParties issuing identity certificate may not have authority to bestow privilegesAttribute CertificatePrivileges can be easily managed by revoking attribute certificatesChange in privilege does not require revocation of public key certificateCost of PMI
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 SoftwareIn 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.
65 Deficiencies in Conventional PKI The Hierarchical Model of TrustHierarchy of trust modelPrivate key insecurityTechnical and implementation weaknessesLimited assurance provided
66 Comparison of Certificate Types Certification authority:X.509: Naming authority hierarchies; cross-certification; CPSPGP: Web of trust: multiple path of certification, to achieve fault tolerance in compensation for the fact that amateur certifiers are signing certificatesSPKI/SDSI: Single naming authority; no CPS necessary
67 Identifier type:X.509: Global by original definition, but local in practicePGP: 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 (www.authentify.com) 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 (www.pgp.com) 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.
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: delegationFor 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 EBIANearly 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 costsVoltage 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.
76 Wireless PKINeed 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 displaysWireless 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 RACA modified for wireless certificate managementNew Bridge CA is needed for trust management across the boundary between wired and wireless PKI domainsWireless gateway: Bridge between WTLS and SSLDirectory server: Repository of certificates; mobile hosts do not store certificates; instead they store a URL to the storeWTLS mini-certificates are much smaller than PKI
81 Trust propagation models for Building PKI systems Trust models:Hierarchical PKIMesh PKIHybrid PKIPKI using a bridge CAPKI using trust lists
82 Bridge CA architecture Most appropriate for wired and wireless domainsOutperforms in: scalability, interoperability, and robustnessA cluster could implement bridge CAEach 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 WPKIThree functional units are considered new in the WPKI expansion:wireless PKI portal---essentially a wireless RAwireless CA ---certificate mgmt. in wireless environmentbridge CAIn addition, server side OCSP server has been suggested
85 Functionalities and Advantages of a Bridge CA Cluster Support the cross-certificate registration from the wireless CAsSupport the cross-certificate registration from wired CAsSupport WTLS certificate and X.509 certificate path discovery and trust managementCross-certificate/CRL managementInteroperability with directory through LDAPPolicy reconfiguration and managementDistinct 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 References1. 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, 20054. Tutorials
87 References (Cont.) 5. Managed PKI 6. Alternates to PKI7. Wireless PKIEverything about wireless PKIwireless PKI overview and then detail explanation
Your consent to our cookies if you continue to use this website.