ch 6 - public key infrastructure
DESCRIPTION
TRANSCRIPT
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.