Public-Key Infrastructure

(1)

Public-Key Infrastructure

Technology and Concepts

Abstract

This paper is intended to help explain general PKI technology and concepts.

For the sake of orientation, it also touches on policies and standards and on some of the new and exciting applications that will consume PKI services and at last fulfill their promise of efficiency and effectiveness in the emerging e-commerce market.

(2)

2 Contents

Introduction... 3

What is a PKI?...3

How does PKI relate to online business and e-commerce?... 3

How is PKI technology integrated in the application?... 3

Major Market Drivers... 4

E-commerce Security Requirements...4

PKI Technology and Architecture...5

Basic PKI Architecture and Data Flow... 6

What is a Public-Key Certificate?...6

What is a Digital Signature?... 7

Data integrity in PKI...7

User authentication in PKI...8

The Primary Technical Components of PKI...8

PKI toolkits... 10

Application Contexts Used in E-Commerce... 11

PKI Policies... 13

Certification Practice Statement (CPS)... 13

Certificate Policy...13

Conclusions...14

PKI-Related Standards...15

List of Acronyms Used...18

(3)

3 Introduction

What is a PKI?

A Public-Key Infrastructure (PKI) is the set of policies, procedures, people, facilities, software, and hardware that allow for the issuance, distribution and ongoing management of public-key certificates. In practical terms, PKIs manage relationships and establish a level of trust in distributed environ- ments. They do this by managing and controlling the use of cryptographic keys and certificates. Without the management and trusted services of PKI, cryptographic-based security cannot be used to support the majority of e- commerce applications.

How does PKI relate to online business and e-commerce?

In the online world, the things that concern administrators the most are the policies defining the rules and flow of the online business. All PKIs are op- erated, administered, or managed according to a business-specific policy defining PKI configuration, deployment, and operations. It is important to make this distinction: the PKI is not just the technology/software/product, but is in essence the rules under which the technology/software/product is integrated, administered, and used. So, PKIs are specific to business flow and business operations first, and to technical architecture second. Properly designed PKI products are capable of supporting multiple business frame- works. An overview of good design practices and features for PKI products will be provided later.

How is PKI technology tntegrated in the application?

Most PKI-technology components run in the network as application services.

The exception is the developer’s toolkit component. The toolkit treats the complex underlying cryptographic services and protocols on behalf of an application programmer. The toolkit is a bundle of local software providers that implement security standards and a high-level interface that allows any developer to PKI-enable their application. The importance of the toolkit in- cludes the following:

- It allows the application programmer to focus on what he/she does best, rather than become a cryptography or PKI expert. This reduces time and resources needed to integrate security with applications.

- It allows consistent security integration across all applications.

- It allows those maintaining the overall solution to easily meet new demands as application environment and requirements evolve over time.

(4)

4 Major Market Drivers

The increasing use of online commerce applications like those listed below constitutes the primary business driving the deployment of PKIs.

- Wireless and web e-commerce

- Electronic content distribution via public networks - Online payments

- Extranets (private networks that support trading partners) - Intranets (private networks that support employees)

While the use of these new applications promise tremendous gains in pro- ductivity to almost all organizations, they also introduce serious security risks such as:

— Masquerading as a legitimate user

— Denial of participation in an online transaction

— Tampering with data

— Eavesdropping

— Unauthorized access

E-Commerce Security Requirements

Businesses operating online have specific security needs, all of which can be met through carefully implemented PKI. PKI provides management of relationships, keys, and certificates necessary to make cryptography useful in business. PKI services and objects will be covered later in this document.

To learn about basic cryptography, see An Introduction to Information Security at http://www.certicom.com/research.html ).

Today there is widespread consensus that the security requirements of online applications are best met by cryptography, but only when these appli- cations are PKI-enabled. To be PKI-enabled, the application must have the ability to access PKI resources like the certification authority and the certifi- cate directory as well as the ability to process the objects that are commonly exchanged within the PKI, like digital signatures and public-key certificates.

A carefully implemented PKI addresses online businesses’ requirements for

— Authentication: to prevent masquerading, verifies the identity of an entity (individual, device, organization, role) prior to an online exchange, transaction, or allowing access to resources.

(5)

5 When the application is PKI-enabled, it can use digital signature and public-

key certificate processes to authenticate individuals, servers, nodes or what- ever entity is participating in the business flow.

— Authorization: to prevent unauthorized activity, verifies that an entity has permission to participate in an activity, a transaction, or is allowed access to resources.

When an application is PKI-enabled, it can cross-reference an entity’s verified identity (which it authenticated using a public-key certificate) with a privilege (or policy-enforcement) list before it authorizes (grants or denies) an entity’s request for participation or access.

— Non-repudiation: provides the tools that make it easy to prove that an individual has participated in a transaction.

PKI-enabled applications can bind a participant to his activity and the date and time that the activity occurred because they have the capability to verify digital signatures, process public-key certificates, and maintain an audit log (record) of the transaction.

— Privacy: prevents eavesdropping or unauthorized access.

PKI-enabled applications are also capable of encrypting data when privacy is needed. While the encryption service is not provided by the PKI, the management and exchange of encryption and decryption keys is a necessary service usually provided by the PKI.

— Integrity: prevents data tampering, ensures that data is not altered, either by accident or on purpose, while in transit or in storage.

Digital signatures are a preferred method for protecting data from tampering. If digital signature verification is positive, the integrity of the transaction is deemed to be intact, if not the transaction data has been modified and will be discarded. PKI-enabled applications are capable of applying digital signatures to transactions, of verifying digital signatures and so can verify the integrity of transactions.

These requirements are best met with PKI-enabled applications that support the services (cryptographic, access, and audit) commonly found in operational PKIs.

PKI Technology and Architecture

Good PKI architectures are openly documented, provide clear application interfaces, and support standards. The set of PKI technologies includes software and hardware that implement the functions of the

— End-Entity Application (EE)

(6)

6

— Registration Authority (RA)

— Certification Authority (CA)

— PKI Directory

Basic PKI Architecture and Data Flow

The major technical components and operational flow of a PKI are shown in Fig. 1.

Fig. 1. The major technical components and operational flow of a PKI.

What is a Public-key Certificate?

A public-key certificate is a data object or container that binds a public key to a set of information identifying the key pair owner (an entity such as a person, organization, node, or Website). The public key in the certificate is associated with the corresponding private key in the pair. The key pair owner is known as the “subject” of the certificate. A certificate is used by a participant involved in secure transaction (or in a secure, authenticated-commu- nications session) who relies upon the accuracy of the identity (Subject) and public key contained in the certificate. With a trusted, accurate identity and

(7)

public key it is possible for one participant to authenticate the other before executing an online transaction. In order to help visualize the contents of a public-key certificate, a diagram (Fig. 2) is provided here.

Fig. 2. Contents of a public-key certificate.

What is a Digital Signature?

As the name suggests, digital signatures are the electronic equivalent of tra- ditional handwritten signatures. But a digital signature cannot be visually recognized like a handwritten signature. Instead, digital signatures are recognized (created, stored, transmitted, and verified) by PKI-enabled applications that have access to key management and cryptographic services. The generic cryptographic operations used in creating and verifying a digital signature are shown in Fig. 3.

Digital signatures and public-key certificates provide two primary security services in a PKI: data integrity and user authentication.

Data Integrity in a PKI

As indicated above, in order to create a digital signature, both the transac- tion data that is to be signed and the user’s private key must be used as in- puts to the signing process. To verify a digital signature, the data that was

(8)

8 signed, the user’s public key, and the digital signature itself are used as in-

puts to the verification process. Since the transaction data is always involved in producing and verifying a digital signature, if the data is modified after signing, the signature will not verify; therefore digital signatures have become a preferred method for ensuring the integrity of transactions.

Fig. 3. A generic representation of the operations used in creating and verifying a digital signature.

User Authentication in a PKI

Public-key certificates ensure that the public key used to verify a digital sig- nature belongs to the user that produced the signature. As indicated in the previous certificate diagram the certificate contains both the user’s public key and identity. So if the signature verification process is successful, the verifier also knows for certain the identity of the signer because the CA that issues the public-key certificate guarantees the user’s identity when it places it in the certificate along with the user’s public key.

For a more detailed review of digital signatures, please see An Introduction to Information Security at http://www.certicom.com/research.html.

The Primary Technical Components of PKI

Following are the primary technical components of a PKI. With the exception of the toolkit, each is implemented as a software module that may inter- operate with other software modules in the PKI and over the network.

— End Entity Application (EE): Implemented as software for the end-user, its functions include:

— Generate, store and allow access to a user’s public-key pair

— Complete, sign and submit first-time certificate applications

(9)

9

— Complete, sign and submit certificate renewal requests

— Complete, sign and submit certificate revocation requests

— Search for and retrieve certificates and revocation information

— Validate certificates and read the certificate contents

— Generate and verify digital signatures

— Registration Authority (RA): Implemented as software for the designated Registration Authority user(s) in the PKI. It is interoperable and fully compatible with the EE and CA and supports the same basic functions of key generation, storage, access, and digital signature and certificate processing. The RA is usually capable of supporting multiple CAs and EEs in the PKI. Its primary use is to support the special tasks of the RA user such as:

— User enrollment: the process by which a user is registered as a po- tential participant in the PKI. The RA creates a user object in a special database. User objects may contain any number of user attributes as specified by the registration policy like: user name, title, email address, etc.

— Due Diligence: the process by which the RA verifies the identity of a certificate applicant (subject) for the first time and confirms that a specific public key (the one that is to be certified) belongs to the applicant.

— Approval of end-user requests: the RA will approve or deny requests made by end-users like requests for first-time certificates and renewal of expired certificates.

— Certificate revocation: The action taken by the RA that orders the CA to revoke a user’s certificate. The RA may or may not provide a reason for revocation according to the PKI’s revocation policy.

—Certification Authority (CA): usually implemented so that it can run autonomously after it has been installed, configured, and launched by the designated CA administrator. Think of the CA as a highly trusted signing engine. It is responsible for signing certificates, revocation requests, and other supporting-transactions according to a predefined set of con- ditions and in this way plays a key role in enforcing the rules of the business that rely on the PKI. In practice the CA is responsible for:

—Key certification: the transaction that results in the CA signing a subject’s public key and issuing the certificate.

—Certificate renewal: the transaction that issues a new certificate to the subject when the current certificate has expired.

(10)

10

—Certificate revocation: the transaction that adds a users certificate to the revocation list making the certificate invalid from that date and time onward.

—Certificate posting: the transaction that places the certificate in the PKI directory where PKI users can search for and retrieve it.

—Revocation list maintenance: the set of transactions that keep the certificate revocation list current within the PKI.

—Revocation list posting: the transaction that places the certificate revocation list in the PKI directory where PKI users can search for and retrieve it.

— PKI directory: The PKI directory is an online repository available to all participants in the PKI for searches and retrievals of certificates, revocation information and policy information. Only special users or com- ponents are designated with Directory write and delete privileges. Most commonly, directories are implemented based on the IETF Lightweight Directory Access Protocol (LDAP). The directory architecture includes two primary components: a LDAP client (usually implemented as part ofthe EE Application) and a LDAP server—a networked server that hosts the directory information and processes search, read, write, delete, and update requests made by authorized users in the PKI. These processes are illustrated in Fig. 4.

PKI Toolkits

Without the ability to integrate the PKI with applications (making the applications PKI-enabled), the PKI has no value in business. Therefore, good PKI- designs focus on application interfaces and the best practice here is to implement the interfaces and standards in the form of developer toolkits. The toolkits allow for tight integration of applications, minimize the resources needed to integrate the PKI with applications, and allow the PKI solution to meet demands as the application environment and requirements evolve over time. Although the PKI toolkit is transparent to users and administrators, it plays a critical role in PKI deployments and ongoing maintenance, so it is also a key technical component of the PKI.

(11)

11 Fig. 4. A representation of an EE application requesting a certificate from

(and receiving) a public-key certificate from an LDAP server.

Common PKI Toolkit: A developer’s toolkit that contains all of the PKI libraries and interfaces necessary to allow a third party application to become PKI-enabled. Ideally, all other components in the PKI (EE, RA, CA) are de- veloped using the same toolkit. Having this type of common foundation in- sures compatibility among PKI components and allows rapid additions/

modifications for new features and bug fixes, and by supporting standards may facilitate the mixing and matching of PKI components from different vendors. A generic PKI toolkit design is represented in Fig. 5.

Fig. 5. A generic PKI toolkit design.

Application Contexts Used in E-Commerce

Several application contexts support e-commerce applications. These are not the e-commerce applications themselves but are the generalized application contexts that are employed in a wide variety of e-commerce applications. The

(12)

12 commonly used application contexts and the PKI-enabled standards that they

rely for securing e-commerce are shown in Table 1.

— Wireless Transport Layer Security (WTLS) is a PKI-enabled transport security protocol. It can authenticate the communicating parties and encrypt the Wireless Markup Language (WML) data when it is in transit.

— Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are also PKI-enabled transport-security protocols and are used in the same manner as WTLS only for Web-based transactions.

— Internet Protocol Security (IPSec) is a PKI-enabled network-security protocol that is used mainly to establish Virtual Private Networks (VPN) for the purpose of support an extranets or intranets. This protocol applies integrity and encryption at the IP data packet level and authentication of the originating and receiving network devices at either end of the communications session.

— Secure/Multipurpose Internet Mail Extensions (S/MIME) is a PKI-enabled application-security protocol that applies integrity, encryption and sender/recipient authentication to email messages.

— Many techniques for secure content distribution exist. Content types and standards vary for music, books, images, software, etc., but PKIs can support the applications that are responsible for secure distribution of content and management of the rights to own and use it.

Table. 1. The commonly used application contexts and the PKI-enabled standards on which they rely.

t x e t n o C n o it a c il p p

A SupporitngPKI-enabledStandard L

M

W WTLS(WAP-199-WTLS-20000218-A) www.wapforum.org L

M T

H SSLandTLS http://wwwi.et.forg li

a m -

e S/MIME http://wwwi.et.forg N

P

V IPSec http://wwwi.et.forg

(13)

13 PKI Policies

There are two main policies that determine the operational and technical practices of a PKI: (1) the Certificate Policy (CP) and (2) the Certification Practice Statement (CPS). A guide for those that will write CPs and CPSs may be found at http://www.ietf.org/rfc/rfc2527.txt?number=2527 . This is IETF RFC 2527 Internet X.509 PKI Certificate Policy and Certification Prac- tice Framework. It is a roadmap for Certificate Policies and Certification Practice Statements. In particular, the framework provides a comprehensive list of topics that may need to be covered in PKI policy definition.

Certification Practice Statement (CPS)

The degree to which a user can trust a certificate depends on the operational practices of the PKI as defined in the Certification Practice Statement. As already mentioned, the policies that govern the rules of the business are also the policies that the PKI must support and enforce. These policies will, in effect, govern how the PKI participants create, administer, use, and access keys and certificates. It is the CPS that defines these policies and in doing so will indicate a level of trust that may be associated with the PKI. The CPS may cover items like the enrollment process for users and administrators, the CA’s overall operating policy, procedures, and security controls; the subject’s obligations (for example, in protecting their private key); and the stated undertakings and legal obligations of the CA (for example, warranties and limitations on liability). The CPS must define practices and policies that will provide a level of trust in the PKI that is at least equal to the value level of the business transactions that rely on the PKI. In the e-commerce world trust-level must be equal to or greater than value-level and the CPS is one way to ensure and verify this.

Certificate Policy

Online businesses and the PKIs that support them are not isolated and over time tend to evolve to encompass more and more customers, partners, and employees. It is also likely that these new entities will reside under different business and management domains and may already have established PKIs and PKI-enabled applications. To that end, it is important that a PKI define policies for standards and interfaces—referred to as the Certificate Policy. Through a well-defined Certificate Policy and by employing a product that can support it, interoperation between PKI domains may be possible without causing serious downtime or interrupting workflow.

(14)

14 Conclusions

PKIs encompass a set of complex technologies that work with the applications supporting e-commerce and online business (as well as other PKIs).

As a result, application interfaces and standards are important. PKI technology can support a wide range of online applications. The demand for PKI support will increase and evolve into the foreseeable future as PKI designs, standards and technologies track the evolution and expansion of e-commerce requirements. The PKI itself is not just technology but is the manner in which the technology, certificates, and keys are administered and used. Finally, the administration and use of PKI must follow the rules of business.

(15)

15 PKI-Related Standards

Abstract Syntax Notation 1 (ASN.1) is an ISO and IETF standard used to describe objects such as certificates, signatures, and encryption keys.

ASN.1 Basic Encoding Rules (BER) and Distinguished Encoding Rules (DER) are ISO and IETF standards, also referred to as transfer or encoding syntax. These are the rules by which data objects are electronically encoded before they are digitally signed, transmitted, or stored.

ANSI X9.62 Elliptic Curve Digital Signature Algorithm (ECDSA) is the Financial Services Industry’s latest standard for digital signatures. This standard defines techniques for generating and validating digital signatures.

It is the Elliptic Curve analog of the original ANSI Digital Signature Algorithm (DSA) (ANSI X9.30 Part 1). Elliptic Curve systems are public-key (asymmet- ric) cryptographic algorithms that are typically used to create digital signatures (in conjunction with a hash algorithm), and to establish secret keys securely for use in symmetric-key cryptosystems.

NIST FIPS PUB 186-2 is the US Digital Signature Standard (DSS). This standard now recognizes three different cryptographic subsystems (1) the original Digital Signature Algorithm (DSA), (2) the Elliptic Curve Digital Signature Algorithm (ECDSA) as defined in ANSI X9.62, and (3) the Rivest-Shamir- Adleman (RSA) digital signature.

IETF RFC 2307 is an experimental standard covering an approach for using LDAP as a Network Information Service.

IETF RFC 2459 is the standard that provides the Internet profile of X.509 Certificate and CRL formats.

IETF RFC 2510 is the Internet X.509 Public Key Infrastructure Certificate Management Protocols (CMP) standard.

IETF RFC 2511 is the Internet X.509 Certificate Request Message Format (CRMF) standard.

(16)

16 IETF RFC 2527 is the Internet X.509 PKI Certificate Policy and Certifica-

tion Practice Framework. It presents a framework for Certificate Policies (CP) and Certification Practice Statements (CPS). In particular, the framework provides a comprehensive list of topics that may need to be covered in policy definition.

ISO/IEC 9594-8/ITU-T Recommendation X.509 provides the generalized public-key certificate and CRL formats, a public-key trust model and security framework, and some of the first formal descriptions of public-key based entity authentication protocols.

ISO/IEC 9594-8 on Certificate Extensions, Final Text of Draft Amendment DAM 1 provides one of the earliest comprehensive lists of extensions and descriptions in ASN.1 of X.509 v3 certificate extensions.

JCE: Java Cryptographic Extensions from JDK v1.2 are the cryptographic libraries provided to Java application developers that allow access to cryptographic serves such as key generation, encryption/decryption, digital signature generation and verification, and X.509 certificate and CRL processing.

PKCS 7 Cryptographic Message Syntax describes general syntax for data that may have cryptography applied to it, such as digital signatures.

PKCS 10 Certification Request Syntax describes syntax for a request for certification of a public key, a name, and a set of attributes.

PKCS 11 Cryptographic Token Interface specifies an API, called Cryptoki, to devices like smart cards which hold cryptographic information and per- form cryptographic functions.

PKCS 12 Personal Information Exchange Syntax specifies a portable format for storing or transporting a user’s private keys, certificates, and other se- crets.

SEC 1: Elliptic Curve Cryptography specifies public-key schemes based on Elliptic Curve Cryptography, in particular signature schemes, encryption schemes and key management schemes. http://www.secg.org

(17)

17 SEC 2: Recommended Elliptic Curve Domain Parameters helps insure

interoperation among PKI-enabled applications that use elliptic curve cryptography (ECC). It specifies profiles for standard domain parameters for those implementing ECC according to SEC 1, ANSI X9.62 or FIPS PUB 186- 2.

WAP Public-Key Infrastructure: WAP-217-WPKI profiles the existing IETF PKIX PKI standards for the specific requirements of the wireless application environment. http://www.wapforum.org

(18)

18 List of Acronyms Used

ANSI American National Standards Institute ASN.1 Abstract Syntax Notation One

BER Basic Encoding Rules CA Certification Authority CP Certificate Policy

CPS Certification Practice Statement CRL Certificate Revocation List

DAM Draft Amendment

DER Distinguished Encoding Rules DSS Digital Signature Standard DSA Digital Signature Algorithm ECC Elliptic Curve Cryptography

ECDSA Elliptic Curve Digital Signature Algorithm E-Commerce Electronic Commerce

EE End Entity

Email Electronic Mail

FIPS Federal Information Processing Standard HTML HyperText Markup Language

IEC International Electro-technical Commission IETF Internet Engineering Task Force

I/F Interface

IP Internet Protocol

IPSec Internet Protocol Security

ISO International Standards Organization ITU International Telecommunications Union JCE Java Cryptographic Extensions

JDK Java Developers Kit

LDAP Lightweight Directory Access Protocol

NIST National Institute of Standards and Technology PKCS Public-Key Crypto Systems

PKI Public-Key Infrastructure

(19)

19 RA Registration Authority

RFC Request For Comment

RSA Rivest-Shamir-Adleman

SEC Standards for Efficient Cryptography http://www.secg.org S/MIME Secure/Multipurpose Internet Mail Extensions

SSL Secure Sockets Layer TLS Transport Layer Security VPN Virtual Private Network

WML Wireless Markup Language (Script)

WPKI Wireless Application Protocol Public-Key Infrastructure WTLS Wireless Transport Layer Security

(20)

www.certicom.com

Certicom Office Locations 25801 Industrial Blvd.

Hayward, CA 94545 USA

Tel: 510.780.5400 Fax: 510.780.5401

5520 Explorer Drive 4th Floor Mississauga, Ontario, L4W 5L1 Canada

Tel: 905.507.4220 Fax: 905.507.4230

Sales Support:

Tel: 510.780.5400 Fax: 510.780.5401

Email: [email protected]

Application Engineering and Customer Support:

Tel: 1.800.511.8011 Fax: 1.800.474.3877

Email: [email protected]

Investor Inquiries:

Contact Starla Ackley 510-780-5404 Email: [email protected]