Lesson 6-Public Key Infrastructure

PKI infrastructure

Public key infrastructures (PKIs) are central security foundation for organizations using symmetric and asymmetric cryptographic technologies.

Most organizations use a PKI (public key infrastructure) for their digital signatures and the certificates that embody the signatures. A PKI implementation includes:

– a certificate authority (CA), a third party that manages the storage, deployment and signing of certificates

– one or more registration authorities (RA) delegated by the CA to validate individual groups or users being issued a certificate

– software tools that manage certificate issuance, validation, renewal or revocation

– directories for the public keys, certificates, links to user directories and certificate-management data

– key-management software for the database where the archived, escrowed, revoked and other keys are stored

– applications, such as e-mail clients and user authentication programs, that use certificates of both local and authenticated users from outside the organization

– trust models that build on the issued certificates to extend safe communications beyond the organization, to its direct partners and the issuing CA

– policies for managing certificates, including models for deploying certificates, responsibility for proper handling, standards to describe their contents, and the legal responsibilities for those using (and abusing) them.

Basics of Public Key Infrastructures

PKI involves entities called registration authorities and certificate authorities.

– Registration authority requires proof of identity

– The registration authority then advises the certificate authority (CA) to generate a certificate, analogous to a driver's license.

– The certificate authority digitally signs the certificate using its private key.

Third Party Trusts - Two people can implicitly trust each other if they share a relationship with a common third party who vouches for them.

Registration Authority

The registration authority (RA) is the component that accepts a

request for a digital certificate. Minimum 3 types:

– A Class 1 certificate verifies an individual's identity through e-mail.

• Public/private key pair digitally signs e-mail and encrypt message contents.

• May only require name, email and physical address

– A Class 2 certificate is used for software signing.

• Software can be digitally signed to provide integrity for the vendor.

• May require driver’s license, passport etc.

– A Class 3 certificate is used by a company to set up its own certificate

authority.

• May have to go to register’s office personnally

A local registration authority (LRA) performs the same functions as

an RA, but the LRA is closer to end users (within a company).

Certificate Authorities and CPS

The certificate authority (CA) is the trusted authority for certifying an

individual's identity and creating an electronic document (digital certificate

).

A digital certificate is an electronic "credit card" that establishes your

credentials when doing business or other transactions on the Web.

Every CA should have a certification practices statement (CPS), which

outlines:

– How identities are verified.

– The steps the CA follows to generate, maintain, and transmit

certificates.

– Why the CA can be trusted to fulfill its responsibilities.

– How keys are secured.

– What data is placed within a digital certificate.

– How revocations will be handled.

Obtaining a Digital Certificate

Steps for obtaining a digital certificate

Digital Signature

Storing a Certificate

Often certificates are stored in a repository

and must be available to whoever requires

them.

The security requirements for repositories,

and their hardware and software, are not as

high as the actual CAs.

– The public can review the CA's CPS to

find out what type of data will and will

not be included within the certificates.

– Since each certificate is digitally signed

by the CA, if a certificate stored in the

certificate repository is modified, the

recipient would be able to detect this

change and not accept the certificate as

valid.

Some key stores can be shared by different applications.Microsoft apps stores keys and certs in a users profile

Distinguished Names

CAs use distinguished names to identify the owners of specific certificates.

A distinguished name is a label that follows the X.500 standard.

– This standard defines a naming convention that can be employed so that each subject within an organization has a unique name.

– An example is {Country = US, Organization = IBM, Organizational Unit = R&D, Location = Washington}.

Trust and Certificate Verification

When users trust a CA, they will

download that CA's digital

certificate and public key, to be

stored on their local computer.

– Most browsers have a list of CAs

configured to be trusted by

default.

– The list can be edited.

Free certificates are available.

Check out Thwarte.com.

Verifying Authenticity and Integrity of a Certificate

To verify the authenticity and integrity of a

certificate:

– Compare the CA that digitally signed the

certificate to a list of CAs that has already

been loaded into the receiver’s computer

– Calculate a message digest for the certificate.

– Use the CA’s public key to decrypt the digital

signature and recover what is claimed to be

the original message digest embedded within

the certificate

– Compare the two resulting message digest

values to ensure the integrity of the

certificate.

– Review the identification information within

the certificate

– Review the validity dates.

– Check a revocation list at the CA to see if the

certificate has been revoked.

Digital Certificate Standard Fields

Version Number

– Identifies the version of the X.509 standard that was followed to create the certificate.

– The version number indicates the format and fields that can be used. Subject

– Specifies the owner of the certificate and can be a network device , an application, a department, a company, or a person.

Public key

– Contains the public key being bound to the certified subject, which also identifies the algorithm used to create the private/public key pair.

Issuer

– Identifies the CA that generated and digitally signed the certificate. Serial number

– Contains a unique number identifying a specific certificate issued by a particular CA. Validity

– Specifies the dates through which the certificate is valid for use. Certificate usage

– Specifies the approved use of a certificate, which dictates the use of this public key. Signature algorithm

– Identifies the hashing algorithm and the digital signature algorithm used to digitally sign the certificate.

Extensions

– Allow additional data to be encoded into the certificate to expand the functionality

X.509

This certificate is created and formatted based on the X.509 standard, which outlines the necessary fields of a certificate and the possible values that can be inserted into the fields.

The CA used MD5 to create the message digest value, and signed with its private key using the RSA algorithm.

The actual CA that issued the certificate is Root SGC Authority

The version of this certificate is V3 (X.509 v3) with the unique serial number

CA Certificates

CA certificates are certificates that are issued by a CA to itself or to a second CA for the purpose of creating a defined relationship between the two CAs.

A certificate that is issued by a CA to itself is referred to as a trusted root certificate, because it is intended to establish a point of ultimate trust for a CA hierarchy.

Once the trusted root has been established, it can be used to authorize subordinate CAs to issue certificates on its behalf.

4 types of Certificate Attributes

End-entity certificates are issued by a CA to a specific subject such as Joyce, the accounting department, or a firewall.

Standalone - certificate may be self-signed in case of a stand-alone or root CA, or it may be issued by a superior CA within a hierarchical model.

Cross-certification - are used when independent CAs establish peer-to-peer trust relationships allowing its users to trust another CA.

Policy - a mechanism to provide centrally controlled policy information to PKI clients. This is often done by creating a policy certificate.

End-entity and CA certificates

Certificate Extensions

Certificate extensions allow further information to be inserted within the

certificate and provide functionality in a PKI implementation.

Certificate extensions can be standard or private. Examples:

– DigitalSignature

• The key is used to verify a digital signature.

– KeyEncipherment

• The key is used to encrypt other keys used for secure key distribution.

– DataEncipherment

• The key is used to encrypt data and cannot be used to encrypt other keys.

– CRLSign

• The key is used to verify a CA signature on a revocation list.

– KeyCertSign

• The key is used to verify CA signatures on certificates.

– NonRepudiation

• The key is used when a nonrepudiation service is being provided.

Additional Requirements

The sender's digital signature can be verified and then signed by the notary

providing nonrepudiation service

Trusted time source - provides a secure, certifiable, and auditable time

stamp on any electronic entity for accountability purposes.

– Without trusted time source, no activity carried out within a PKI environment can

be truly proven because it is very easy to change system and software time

settings.

Certificate Lifecycles - Keys and certificates should have lifetimes set. This

involves administrating and managing each of these phases, including

registration, certificate and key generation, renewal, and revocation.

– The lifetime of the key should be long enough that continual renewal will not

negatively affect productivity, but short enough to ensure that the key cannot be

successfully compromised.

PKI Implementations

In most modern PKI implementations, users have two key pairs.

– One key pair is generated by a central server and used for encryption

and key transfers. The corporate PKI retains a copy of the encryption

key pair for recovery, requiring secure transmission of the keys to the

user.

– The second key pair, a digital signature key pair, is generated by the

user, who has a copy of the private key and stored locally (workstation

or smart card).

Proof of Possession - the act of verifying that an individual has the

corresponding private key for a given public key.

– If a key pair is used for encryption, the RA can send a challenge value to

the individual, who, in turn, can use the private key to encrypt that

value and return it to the RA.

Key Size

When the key pair is first generated, the administrator

chooses the algorithm used to generate the key pair and the

key size.

– The specific algorithm will be chosen for its strength and

interoperability

– The key size will depend upon the sensitivity of the data being

protected.

The RSA algorithm is the de facto standard for asymmetric

key

– For sensitive date, 128 bit is minimum, takes 105 computers

five minutes, key size of 1024 takes 114 computers with 170GB

of memory 3,000,000 years

Renewal and Revocation

A renewal process is different from the registration phase.

– Since the individual has successfully completed one registration round,

the original key and certificate can be used to provide the necessary

authentication and proof of identity

Reasons a certificate can be revoked:

– A user loses a laptop or a smart card that stored a private key.

– An improper software implementation has been uncovered that directly

affected the security of a private key.

– A user has fallen victim to a social engineering attack and inadvertently

given up a private key.

– Data held within the certificate no longer applies to the specified

individual.

– An employee has left a company and should not be identified as a

member of an in-house PKI.

Certificate Revocation List

The CA can provide protection by

maintaining a

certificate revocation list (CRL).

The CA:

– Is responsible for the status of the

certificates it generates.

– Must be informed of a revocation.

– Must provide this information to others.

– Is responsible for maintaining the

revocation list and posting it in a publicly

available directory.

– indicates why individual certificates

were revoked and the date of revocation

– contains all certificates that have been

revoked within the lifetime of the CA.

The CRL's integrity needs to be protected to ensure data isn’t modified.

The mechanism used to protect the integrity of a CRL is a digital signature.

CRL Distribution

CRL files may be requested by individuals who want to verify and validate a

newly received certificate. Files can be pushed down by the CA or checked

via an online service that can query the lists.

– One of the protocols used for online revocation services is

Online Certificate Status Protocol (OCSP).

– It is a request and response protocol that obtains the serial number of

the cert that is being validated, reviews revocation lists, and reports the

status of the certificate back to the client.

Suspension

Instead of being revoked, a certificate is sometimes suspended and the CRL

indicates a hold state in the revocation field. Examples:

– there has been a loss, theft, modification, unauthorised disclosure, or other

compromise of the private key of the certificate's subject,

– the certificate's subject has breached a material obligation under this CPS,

– the performance of a person's obligations under this CPS has been delayed or

prevented by an act of God; natural disaster; computer or communications

failure; change in statute, regulation, or other law; official government action,

including but not limited to acts by agencies responsible for export control

administration; or other cause beyond the person's reasonable control, and as a

result another person's information has been or may be materially threatened or

compromised, or

– the subscriber (or authorized representative) has duly requested it.

Key Destruction

Key destruction is dictated by the level of protection required

within the environment. In most environments, just allowing the

applications that created the keys is sufficient.

In environments requiring higher levels of protection (government

and military agencies), the media that holds the keys may need to

go through a “zeroization” process.

– The media that holds the cryptographic key is overwritten.

– A software tool writes NULL values to the sectors until that media holds

no remnants of the original key.

Key history maintenance - In modern PKIs, encryption key pairs

must be retained long after they expire so that users can decrypt

information that was encrypted with the old keys.

Random Number Generators

Keys are generated in a central server or local computer manner,

depending on key size and how resource intensive.

A central server may include a hardware-based random number generator

creating numbers that work as seed values for the algorithm.

They extract values from the surroundings.

– If the starting values are predictable, the numbers they generate cannot be

random.

– An example of a true random number generator would be a system that collects

radiation from a radioactive item because elements escape from the radioactive

item in an unpredictable manner

– There are a wide variety of schemes for getting random number seeds based on

unpredictable external real-world events such as the time between keystrokes,

the air temperature, or how often network packets arrive.

Hardware Storage Devices

To provide true authenticity and nonrepudiation, a public/private key pair for digital

signatures should not be stored on a centralized server

– The server needs to be available and provide a single point of failure.

– It must have fault tolerance or redundancy mechanism.

– If the central key server is compromised, the whole environment is compromised.

There are other hardware components that can be implemented within a PKI to hold

users' private key information.

– Smart cards

– USB tokens

– Fortezza cards - popular with government agencies, especially the military.

If a company uses smart cards to hold users' private keys, the private key often has to

be generated on the card itself and cannot be copied for archiving purposes.

– Some applications create their own public/private key pairs and do not allow other keys to be

imported and used.

In most situations, hardware key-storage solutions are only used for the most critical

and sensitive key.

Maintaining Key Privacy

The following list sums up the characteristics and requirements of proper

private key use:

– The key size should provide the necessary level of protection for the environment.

– The lifetime of the key should correspond with how often it is used and the

sensitivity of the data it is protecting.

– The key should be changed and not used past its allowed lifetime.

– Where appropriate, the key should be properly destroyed at the end of its

lifetime.

– The key should never be exposed in clear text.

– No copies of the private key should be made if it is being used for digital

signatures.

– The key should not be shared.

– The key should be stored securely.

– Authentication should be required before it can be used.

– The key should be transported securely.

Key archiving, recovery and escrow

Key archiving will generally back up only the key pairs used to

encrypt data, and not the key pairs used to generate digital

signatures

When a key recovery is required, at least two people (separation of

duties) are required to authenticate (dual control) by the key

recovery software before the recovery procedure is performed.

– All key recovery procedures should be audited.

– The audit logs should capture at least what keys were recovered, who

was involved in the process, and the time and date.

Key escrow is a process of giving keys to a third party (

specifically the government) so that they can decrypt and read

sensitive information when required.

Certificate Policy

The CP is generated and owned by an individual company

that uses an external CA, and it allows the company to

enforce its security decisions and control how certificates

are used with its applications.

This policy allows the company to decide the certification

classes.

– This is different from the CPS, which explains how the CA

• verifies entities,

• generates certificates,

• and maintains these certificates.

Public and in house CA

The decision to use a public or an in-house CA depends upon:

– The expansiveness of the PKI within the organization.

– How integrated it will be with different business needs and goals.

– The number of individuals who will be participating in the decision-making

process.

– How it works with outside entities.

A public CA is a company that specializes in verifying individuals’ identities

and creating and maintaining their certificates.

– They are easily accessible since most Web browsers have a list of public CAs

installed along with their corresponding root certificates.

– They have the necessary equipment, skills, and technologies..

In-house CA are implemented, maintained, and controlled by the company.

– It gives more control over the registration and generation process and allows

them to configure items specifically for their own needs.

Outsourced Certificate Authorities

An outsourced CA is different from a

public CA.

Outsourced services need to be analyzed:

– to determine level of trust and level

of risk

– The liabilities the service provider is

willing to accept

– the surrounding legal issues need to

be examined

Some large vertical markets have their

own outsourced PKI environments set up

because they share similar needs and

usually have the same requirements.

– This allows several companies within

the same market to split the costs of

the necessary equipment and set

standards.

A PKI service provider (represented by the four

boxes) can offer different PKI components to companies.

Trust Models

More than one CA may be needed

for a specific PKI to work properly.

Trust Domain – construct of

systems, personnel, applications,

protocols, technologies and

policies, and all components work

together seamlessly

The different trust domains:

– Are managed by different

administrators.

– Have different security policies.

– Restrict outsiders from privileged

access.

A trust anchor (CA) is the agreed-upon trusted third party.Trust anchors need to be identified, and a communication channel must be constructed and maintained.

Establishing Trust

If the two CAs have exchanged

certificates and trust each

other, they do not have a

common trust anchor.

The trust models describe and

outline the trust relationships

between the different CAs and

different environments

The trust path can be

unidirectional or bidirectional

A trust relationship can be built between two trust domains to

set up a communication

channel.

The Certificate Path

When a user in one trust domain needs to communicate with another user in

another trust domain, one user will need to validate the other's certificate.

– This means each certificate for each CA, up to a shared trusted anchor, needs

to be validated.

Following the certificate path refers to when software has traversed the hierarchy

to track and collect certificates until it comes upon a self-signed certificate.

Verifying each certificate in a certificate path

Hierarchical Trust Model

The first type of trust

model is a basic

hierarchical structure that

contains a root CA,

intermediate CAs, leaf CAs,

and end-entities.

The hierarchical trust model outlines trust paths.

Hierarchical Trust Anchor

The root CA is the ultimate

trust anchor for all other

entities in this infrastructure.

– It generates certificates for

the intermediate CAs, which in

turn generate certificates for

the leaf CAs, and the leaf CAs

generate certificates for the

end-entities (users, network

devices, applications).

– There are no bidirectional

trusts. They are all

unidirectional trusts.

Hierarchical Trust Anchor

Since no other entity can certify

and generate certificates for the

root CA, it creates a self-signed

certificate.

– The certificate's issuer and

subject fields hold the same

information.

– Both represent the root CA.

– The root CA's public key is

used to verify this certificate.

The root CA certificate and public

key are distributed to all entities

within this trust model.

Cross Certification - Peer-to-Peer Model

In peer-to-peer trust models,

one CA is not subordinate to

another, and there is no

established trusted anchor

In the peer-to-peer model, the two

CAs will certify the public key for

each other, which creates a

bidirectional trust.

One of the main drawbacks of this

model is scalability.

– Each CA must certify every other

CA that is participating, and a

bidirectional trust path must be

implemented.

Cross certification creates a peer-to-peer PKI model.

Hybrid Trust Model

In a hybrid trust model, the two

companies have their own internal

hierarchical models and are connected

through a peer-to-peer model using

cross certification.

Hybrid configuration is implemented

through a bridge CA.

A bridge CA is responsible for issuing

cross-certificates to all connected CAs

and trust domains.

The bridge is not considered a root or

trust anchor, it is just an entity to

generate and maintain cross

certification for the connected

environments.

A bridge CA can control the cross-certification procedures.

Complexity

The diagram represents fully

connected mesh

architecture, meaning each

CA is directly connected to

and has a bidirectional trust

relationship with every other

CA.

Scalability is a drawback in cross-certification models.