CENTRAL DEPARTMRNT OF COMPUTER SCIENCE

AND

INFORMATION TECHNOLOGY

TRIBHUVAN UNIVERSITY

Advanced Cryptography

Public Key Infrastructure (PKI)

Assignment no 2

Submitted By: Submitted To:

Shashi shekhar Acharya Mr. Dhiraj Kedar Pandey

Roll No. 06/072

1. PKI (Public Key Infrastructure)

A public key infrastructure is a set of hardware, software, people, policies, and procedures needed
to create, manage, distribute, use, store, and revoke digital certificates. In cryptography, a PKI is
an arrangement that binds public keys with respective user identities by means of a certificate
authority. The user identity must be unique within each CA domain. The third-party validation
authority can provide this information on behalf of CA. The binding is established through the
registration and issuance process, which, depending on the assurance level of the binding, may be
carried out by software at a CA or under human supervision. The PKI role that assures this binding
is called the registration authority, which ensures that the public key is bound to the individual to
which it is assigned in a way that ensures non-repudiation.

The classical description is as follows.

There is a central authority that is called the Certificate Authority, or CA for short. The CA has a
public/private key pair (e.g., an RSA key pair) and publishes the public key. It is assumed that
everybody knows the CA's public key. As this key remains the same over long periods of time,
this is easy to accomplish.

Ideally, PKI consists of certificates, a repository for retrieving certificates, a method of revoking
certificates, and a method of evaluating a chain of certificates from public keys that are known and
trusted in advance (trust anchors) to the target name.

To join the PKI, Alice generates her own public/private key pair. She keeps the private key secret,
and takes the public key PKA to the CA and says: "Hi, I'm Alice and PKA is my public key." The
CA verifies that Alice is who she says she is and then signs a digital statement that states something
like "Key PKA belongs to Alice." This signed statement is called the certificate. It certifies that the
key belongs to Alice.
If Alice now wants to communicate with Bob, she can send him her public key and the certificate.
Bob has the CA's public key, so he can verify the signature on the certificate. As long as Bob trusts
the CA, he also trusts that PKA actually belongs to Alice.
Using the same procedures, Bob gets his public key certified by the CA, and sends his public key
and certificate to Alice. They now know each other's public key. These keys in tum can be used to
run the key negotiation protocol to establish a session key for secure communications.
What is required is a central CA that everybody trusts. Each participant needs to get his or her
public key certified, and each participant needs to know the CA's public key. After that, everybody
can securely communicate with everybody else.

2. PKI Trust Models

A trust model specifies rules which determine how a certificate path should be constructed.
Suppose Alice wants to send an encrypted email message to Bob. She needs to securely find out
Bob's public key. The PKI trust model defines where Alice gets her trust anchors, and what paths
would create a legal chain from a trust anchor to the target name (i.e. Bob). Some of the trust
models are as follows:

I. Strict Hierarchy Model

In a strict hierarchy model, the root CA, also called trust anchor has self-signed, self-issued
certificate. The root CA may issue certificates for lower level CAs and any CA can issue
certificates for end users.
In the figure 1, there is a root CA, four lower level CAs and eight end users. A directed edge xy
denotes the entity corresponding to node x has signed a certificate for the entity corresponding to
node y.
An end user, say Alice, in order to verify the certificate of another end user, Bob needs a certificate
path from the root CA to Bob. In a strict hierarchy, Bob might be expected to store this information
on his computer. Then he could provide it to Alice or anyone who requests it. In this example, Bob
would send all the certificates in the path CArootCA1Bob to Alice. It is assumed that Alice
knows verification key of CAroot, say verCAroot. Together with the certificate path provided by Bob,
this will allow Alice to carry out certificate path validation. Finally, Alice must also ensure that
path follows to the trust model, i.e. the path originates at CAroot, terminates at Bob and it contains
an interior node which is a lower level CA.

Figure 1. Strict Hierarchy model

II. Networked PKI

PKI networking is the process of connecting root CAs of two or more different PKI domains. It
is required because the strict hierarchy may work well only within a single organization. The
networked PKI creates a super-PKI made up of users in different domains. When one CA signs
the certificate of another CA, the process is called cross certification. In the mesh configuration all
the root CAs will cross-certify each other. Hence, n root CAs will require n(n-1) cross certification
in a mesh configuration. The alternative approach to mesh configuration is hub-and-spoke
configuration, in which n root CAs each cross-certify independently with a new hub CA. the
number of cross-certifications that are required is equal to 2n.

III. Web Browser Model

The web browser model are the model used in web browsers such as Internet Explorer of Netscape.
Most web browsers come pre-configured with a set of independent root CAs, all of which are
treated by the user of the browser as trust anchors. There may be in order of 100 such root CAs in
a typical web browser, but there is no cross certification between these root CAs. Conceptually,
the trust model can be thought of as a single strict hierarchy with a virtual root CA. in effect, the
user trusts the provider of the web browser to only include valid root CAs in the browser.
There are various security issues with the web browser model. First, a user may not have
information about security of these pre-configured root. And secondly there is no automated
mechanism to update certificates of root CAs, it is common for a user to receive a message saying
that a certificate has expired when they want to institute and SSL session.
IV. Pretty Good Privacy (PGP)

In Pretty good Privacy, every user is his or her own CA. A PGP certificate contains an email
address (ID), a public key (PK), and one or more signatures on this (ID, PK) pair. For example,
Alices self-signed certificate:
Cert(Alice) : (data, signatures)

Where,
data: (ID = alice@utdallas.edu , PK = 12345)
signatures: sigAlice (data )
Other users might also create a signatures on the data on Alices certificate. If Bob gives Alice
such a signature, she will add it to the list of signatures on her certificate:
signatures :(sigAlice (data), sigBob (data))
The signatures on a certificate help to verify the certificates authenticity to other users.
Alice keeps a collection of certificates, which she has obtained from various sources, in a data
structure called keyring. Associated with each certificate in the keyring is an owner trust field
(OTF) and a key legitimacy field (KLF). KLF has the value valid, marginally valid or
invalid. The KLF is computed by PGP software using a certain method.
There are several possible problems with a PGP-type PKI. PGP is not a true infrastructure. Users
have to set trust level (OTFs) themselves, and revocation can be done only by certificate owners.
There is no mechanism to revoke fake certificates. And another problem of PGP is that it is not
easily scalable to large networks of user communities. Finally if is difficult to enforce uniform
policies or standards.

3. Certificates

Certificates are the building blocks of PKIs which enables secure and scalable PKIs to be built
from them. Certificates are used by participants to exchange keys without contacting a public-
key authority, in a way that is as reliable as if the keys were obtained directly from a public-key
authority. In essence, a certificate consists of a public key, an identifier of the key owner, and the
whole block signed by a trusted third party.
One scheme has become universally accepted for formatting public-key certificates: the X.509
standard. X.509 certificates are used in most network security applications, including IP security,
transport layer security (TLS), and S/MIME.

X.509 Certificates

X.509 is part of the X.500 series of recommendations that define a directory service. The directory
is, in effect, a server or distributed set of servers that maintains a database of information about
users. The information includes a mapping from user name to network address, as well as other
attributes and information about the users. X.509 defines a framework for the provision of
authentication services by the
X.500 directory to its users. The directory may serve as a repository of public-key certificates.
Each certificate contains the public key of a user and is signed with the private key of a trusted
certification authority. In addition, X.509 defines alternative authentication protocols based on the
use of public-key certificates.
X.509 is based on the use of public-key cryptography and digital signatures. The standard does not
dictate the use of a specific algorithm but recommends RSA. The digital signature scheme is
assumed to require the use of a hash function.
The heart of the X.509 scheme is the public-key certificate associated with each user. These user
certificates are assumed to be created by some trusted certification authority (CA) and placed in
the directory by the CA or by the user. The directory server itself is not responsible for the creation
of public keys or for the certification function; it merely provides an easily accessible location for
users to obtain certificates.
 Figure 2. Public Key Certificate Use

The most popular X.509 certificate is version3 (v3). X.509 certificate contains the following fields:

Version number: Differentiates among successive versions of the certificate format; the
default is version 1. If the issuer unique identifier or subject unique identifier are present, the
value must be version 2. If one or more extensions are present, the version must be version 3.
Serial number: An integer value unique within the issuing CA that is unambiguously
associated with this certificate.
Signature algorithm identifier: The algorithm used to sign the certificate together with any
associated parameters. Because this information is repeated in the signature field at the end
of the certificate, this field has little, if any, utility.
Issuer name: X.500 is the name of the CA that created and signed this certificate.
Period of validity: Consists of two dates: the first and last on which the certificate is valid.
Subject name: The name of the user to whom this certificate refers. That is, this certificate
certifies the public key of the subject who holds the corresponding private key.
 Subjects public-key information: The public key of the subject, plus an identifier of the
algorithm for which this key is to be used, together with any associated parameters.
Issuer unique identifier: An optional-bit string field used to identify uniquely the issuing
CA in the event the X.500 name has been reused for different entities.
Subject unique identifier: An optional-bit string field used to identify uniquely the subject
in the event the X.500 name has been reused for different entities.
Extensions: A set of one or more extension fields. Extensions were added in version 3 and
are discussed later in this section.
Signature: Covers all of the other fields of the certificate; it contains the hash code of the
other fields encrypted with the CAs private key. This field includes the signature algorithm
identifier.
The unique identifier fields were added in version 2 to handle the possible reuse of subject and/or
issuer names over time. These fields are rarely used.

Figure 3. X.509 formats

The standard uses the following notation to define a certificate:
CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}
Where,
Y<<A>>=the certificate of user X issued by certification authority Y
Y{I}= the signing of I by Y. It consists of I with an encrypted hash code appended
V= version of the certificate
SN= serial number of the certificate
AI= identifier of the algorithm used to sign the certificate
CA= name of certificate authority
UCA= optional unique identifier of the CA
A= name of user A
UA= optional unique identifier of the user A
Ap= public key of user A
TA= period of validity of the certificate

The CA signs the certificate with its private key. If the corresponding public key is known to a
user, then that user can verify that a certificate signed by the CA is valid.
The X.509 version 2 format does not convey all of the information that recent design and
implementation experience has shown to be needed. For example,
1. The subject field is inadequate to convey the identity of a key owner to a public-key user.
X.509 names may be relatively short and lacking in obvious identification details that may be
needed by the user.
2. The subject field is also inadequate for many applications, which typically recognize entities
by an Internet e-mail address, a URL, or some other Internet-related identification.
3. There is a need to indicate security policy information. This enables a security application or
function, such as IPSec, to relate an X.509 certificate to a given policy.
4. There is a need to limit the damage that can result from a faulty or malicious CA by setting
constraints on the applicability of a particular certificate.
5. It is important to be able to identify different keys used by the same owner at different times.
This feature supports key lifecycle management: in particular, the ability to update key pairs
for users and CAs on a regular basis or under exceptional circumstances.
Rather than continue to add fields to a fixed format, standards developers felt that a more flexible
approach was needed. Thus, version 3 includes a number of optional extensions that may be added
to the version 2 format. Each extension consists of an extension identifier, a criticality indicator,
and an extension value. The criticality indicator indicates whether an extension can be safely
ignored. If the indicator has a value of TRUE and an implementation does not recognize the
extension, it must treat the certificate as invalid.

4. Certificate Lifecycle Management

There are many factors to consider in the life-cycle of a key. With so many types of keys available
(public, private, authentication, authorization, signing, verification, etc.), there are many
questionable issues on how a key is properly generated, distributed, stored, replaced, deleted, and
recovered during its life time, and provided with adequate protection against threats.
The National Institute of Standards and Technology (NIST) provides strict guidelines for most
aspects of the life cycle of cryptographic keys and has also defined some standards on how a
crypto-period is determined for each key. A crypto period is the operational life of a key, and is
determined by a number of factors based on: The sensitivity of the data or keys to be protected
How much data or how many keys are being protected From this information, the operational life
of the key can be determined, along with the key length (which is proportional to the cryptographic
strength of the system). The algorithm (and, therefore, the key type) is determined by the purpose
of the key; for example, DSA is applicable to a signing purpose only whereas RSA is appropriate
for both signing and encrypting. NIST specifies cryptographic algorithms that have withstood the
test of time. Following are the basic phases of key lifecycle:

i. Key Generation

Keys can be generated through the key manager or by a trusted third party, which must use a
cryptographically secure random bit generator. The keys, along with all their attributes, will then
be stored in the key storage database (which must be encrypted by a master key). Attributes include
items like name, activation date, size, and instance. A key can be activated upon its creation or set
to be activated automatically or manually at a later time. Each key should have a key strength
(generally measured in number of bits) associated with it that can provide adequate protection for
the entire useful life-time of the protected data, plus the ability to withstand attacks during this
life-time. Dual or multiple key pairs are often utilized to perform different roles to support distinct
services. For e.g. one key pair may be used for signing and another for encrypting messages. A
key pair can also be restricted by policy to certain roles based on usage factors like type, quantity,
category, service and protocol. Multiple key pairs usually require multiple certificates, due to the
fact that the X.509 certificate format does not support multiple keys. Multiple certificates can
contain the same public key, although this is not advisable due to the inherent security risks
(substitution attacks) associated with erroneous privileges for the same key in different certificates.
An important consideration with respect to multiple keys is the location of key generation and
storage facility. Especially within the context of keys being used for nonrepudiation services, the
owner of the private key is entrusted with generating and storing such keys. In other scenarios
performance, usage, legalities and algorithm specifications are the factors affecting the choice of
location

ii. Key Distribution

The objective of the distribution, also called deployment and loading phase is to install the new
key into a secure cryptographic device, either manually or electronically. It is also advised that the
a key be deployed and tested for a certain period of time to ensure that operations with the new
key are successful, in order to avoid any potential data loss or theft. For manual distribution, keys
must be distributed and loaded in key shares to avoid the full key being viewed in the clear. When
symmetric keys are installed, it is recommended that they be encrypted by a public key or key-
encryption key prior to being delivered for deployment. Storing

iii. Key Removal

The last phase is the end of the key's life-cycle, where all of its instances, or just certain instances,
are completely removed, and recovery of that key may be possible, depending on the method used.
There are three methods of removing a key from operation:
a. Key destruction: This method removes an instance of a key in one of the permissible key
forms at a specific location. Information may still exist at the location from which the key
may be feasibly reconstructed for subsequent use.
b. Key deletion: This method removes an instance of a key, and also any information from
which the key may be reconstructed, from its operational storage/use location. Instances of
this key may continue to exist at other locations (e.g., for archival purposes).
c. Key termination: All instances and information of the key are completely removed from all
locations, making it impossible to regenerate or reconstruct the key (other than through a
restore from a backup image).