AD

Please take a moment and help support this site by visiting our AD. Thank you for your support.

Showing posts with label public key infrastructure. Show all posts
Showing posts with label public key infrastructure. Show all posts

Sunday, May 01, 2011

Public Key Infrastructure(PKI)

PKI (public key infrastructure)
A PKI (public key infrastructure) enables users of a basically unsecure public network such as the Internet to securely and privately exchange data and money through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority. The public key infrastructure provides for a digital certificate that can identify an individual or an organization and directory services that can store and, when necessary, revoke the certificates. Although the components of a PKI are generally understood, a number of different vendor approaches and services are emerging. Meanwhile, an Internet standard for PKI is being worked on.

The term Public Key Infrastructure is sometimes used in a broader sense to mean both the Certificate Authority (CA) and related arrangements as well, and in some other times, confusingly or wrongly, to denote public key algorithms used in electronic communications. In the latter case, it should be kept in mind that public key algorithms do not require PKI.

The public key infrastructure assumes the use of public key cryptography, which is the most common method on the Internet for authenticating a message sender or encrypting a message. Traditional cryptography has usually involved the creation and sharing of a secret key for the encryption and decryption of messages. This secret or private key system has the significant flaw that if the key is discovered or intercepted by someone else, messages can easily be decrypted. For this reason, public key cryptography and the public key infrastructure is the preferred approach on the Internet. (The private key system is sometimes known as symmetric cryptography and the public key system as asymmetric cryptography.)

A public key infrastructure consists of:
• A certificate authority (CA) that issues and verifies digital certificate. A certificate includes the public key or information about the public key
• A registration authority (RA) that acts as the verifier for the certificate

Working with PKI

Public Key Infrastructure arrangements help users to authenticate each other and to use the information in identity certificates (public keys of each person) to encrypt and decrypt messages between each other.
Here is the way PKI works: The public key infrastructure architecture consists of client software, server software such as a certificate authority, hardware (e.g., smart cards) and operational procedures. Using his/her private key, a user may sign messages digitally, and another person can verify this signature using the public key embedded in that user’s certificate issued by a certificate authority within the Public Key Infrastructure, thereby enabling two or more parties to establish confidentiality, message integrity and user authentication without having to compromise any secret information in advance or during the process.
Most enterprise PKI systems depend upon certificate chains to establish a party’s identity. That is, while the certificate for any party may be issued by a certificate authority computer, it becomes mandatory that the legitimacy of that computer in turn need to be certified, and that is done by a higher certification authority and the chain goes on.

This certification hierarchy, at a minimum level, will consists of many computers, often more than an organization, and an assortment of interoperating software packages from different systems across different sources. This hierarchical structure is in fact inevitable as standards are critical to PKI operation. Many of the operating standards in this area are formulated by the IETF PKIX workgroup.
Enterprise-scale public key infrastructure systems are sometimes tied closely with the enterprise’s directory schema by combining the employee’s public key – embedded in a certificate – with other personal details such as name, designation, and department. X509 is the most commonly used certificate format alongside the directory schema LDAP.

How Public and Private Key Cryptography Works

In public key cryptography, a public and private key are created simultaneously using the same algorithm (a popular one is known as RSA) by a certificate authority (CA). The private key is given only to the requesting party and the public key is made publicly available (as part of a digital certificate) in a directory that all parties can access. The private key is never shared with anyone or sent across the Internet. You use the private key to decrypt text that has been encrypted with your public key by someone else (who can find out what your public key is from a public directory). Thus, if I send you a message, I can find out your public key (but not your private key) from a central administrator and encrypt a message to you using your public key. When you receive it, you decrypt it with your private key. In addition to encrypting messages (which ensures privacy), you can authenticate yourself to me (so I know that it is really you who sent the message) by using your private key to encrypt a digital certificate. When I receive it, I can use your public key to decrypt it. Here's a table that restates it:

To do this                                                                               Use whose                          Kind of key

Send an encrypted message                                                   Use the receiver's                Public key
Send an encrypted signature                                                   Use the sender's                 Private key
Decrypt an encrypted message                                               Use the receiver's               Private key
Decrypt an encrypted signature (and authenticate the sender) Use the sender's                   Public key



PKI Applications


Public Key Infrastructures, irrespective of the vendors, have many uses. These include providing public keys and bindings to user identities which are used for:

• Encryption or authentication of documents. For example, XML signature standards if the document concerned is encoded in XML.
• The same, but in case of email messages (using S/MIME or OpenPGP).
• Verification and authentication of users to applications such as in smart card login and client validation using SSL.
• Bootstrapping secure communication protocols such as SSL and Internet Key Exchange (IKE).


PKI Alternatives

Newer techniques for the authentication of public key information have been introduced and some of them are already in use by various enterprises. Most popular amongst them include the Web of Trust, Simple Public Key Infrastructure (SPKI) and Robot Certificate Authorities or Robot CAs.

Who Provides the Infrastructure

A number of products are offered that enable a company or group of companies to implement a PKI. The acceleration of e-commerce and business-to-business commerce over the Internet has increased the demand for PKI solutions. Related ideas are the virtual private network (VPN) and the IP Security (IPsec) standard. Among PKI leaders are:

• RSA, which has developed the main algorithms used by PKI vendors
• Verisign, which acts as a certificate authority and sells software that allows a company to create its own certificate authorities
• GTE CyberTrust, which provides a PKI implementation methodology and consultation service that it plans to vend to other companies for a fixed price
• Xcert, whose Web Sentry product that checks the revocation status of certificates on a server, using the Online Certificate Status Protocol (OCSP)
• Netscape, whose Directory Server product is said to support 50 million objects and process 5,000 queries a second; Secure E-Commerce, which allows a company or extranet manager to manage digital certificates; and Meta-Directory, which can connect all corporate directories into a single directory for security management

PKI Certificate

A PKI certificate, which stands for Public Key Infrastructure certificate, allows someone to combine their digital signature with a public key and something that identifies them, an example being their real life name. This certificate is used to allow computer users to show that they do own the public keys they claim to. In other words, it is a security mechanism for public keys.
As mentioned before, a digital signature is required for the PKI certificate. This signature can either be made by an authority figure who assigns the certificates, the person whose identity is being confirmed, or even endorsers of the public key. As with credit cards, a digital signature is a way for other parties and people to verify that a person is in fact the owner of the public key they claim is their own.

Applications of PKI Certificates

PKI certificates are most commonly used to authenticate cryptographic public keys. In small networks, giving
public keys to others may be safe. This is often untrue for larger networks, however, and a solution must be found. This solution is public-key cryptography.
To give an example of why having an unsecured public key may become troublesome, let us take the example that a person needs to communicate with another person in order to establish a business relationship. By publishing his public key, the first person is able to receive and send messages to his companion through a secure and safe method. A problem arises, however, in the fact that someone else can pose as the first person and send messages that person did not want to send. I am sure it becomes obvious why a person pretending to be another can be a huge problem during any sort of communication effort.
The PKI certificate is a way to stop this problem. This certificate allows other people to verify that they are indeed communicating with the right person and using the right public key. It is a clear answer to the problem of the third party problems that may arise without it.

Multiple Certificate Authorities

A problem can occur when two different people or parties meet each other and both are using certification authorities the other does not recognize. Because they do not recognize the respective authorities, the certificates may not seem real. To help combat this, many certificate authorities now keep their own personal public keys in the certificates to help guide new finders of their services to them. This public key is signed by yet another certification authority, allowing a complicated hierarchy of trust to be created. To keep this simple, it basically means that all certificates are linked together by one source in an ideal situation and this source is a trustworthy one.
It is important for users who are given PKI certificates to ensure that his or her certification authority is indeed a legitimate provider of that service. It can obviously lead to problems if someone is using a certificate that really has no use as it was given out by someone lacking the authority to. Use the Certificate Revocation List or the Online Certificate Status Protocol to check this information.

PKI Certificate Revocation

There are times when a certificate must be revoked by an authority. A common example of this occurring is if a person’s identity information changes, for instance if they decide to change their name for some reason or another.

PKI Certificate Standards

The PKI certificate usually includes personal information such as name, employment status and company’s name, and how long the certificate is valid. The most popular standard for PKI certificates is ITU-T X.509.

Enterprise PKI Concepts

The Enterprise PKI snap-in is used to ensure that all of the following elements in a public key infrastructure (PKI) are functioning properly, available, and valid:

• Certification authorities (CAs). A CA accepts a certificate request, verifies the requester's information according to the policy of the CA, and then uses its private key to sign the certificate. The CA then issues the certificate to the subject of the certificate for use as a security credential within a PKI. A CA is also responsible for revoking certificates and publishing a certificate revocation list (CRL).
• CA certificates. A CA certificate is a certificate 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. CA certificates are critical to defining the certificate path and usage restrictions for all end-entity certificates issued for use in the PKI.
• Authority information access locations. Authority information access locations are URLs that are added to a certificate in its authority information access extension. These URLs can be used by an application or service to retrieve the issuing CA certificate. These CA certificates are then used to validate the certificate signature and to build a path to a trusted certificate.
• CRLs. CRLs are complete, digitally signed lists of unexpired certificates that have been revoked. This CRL is retrieved by clients who can then cache the CRL (based on the configured lifetime of the CRL) and use it to verify certificates presented for use.
• CRL distribution points. CRL distribution points are locations, typically URLs, that are added to a certificate in its CRL distribution point extension. CRL distribution points can be used by an application or service to retrieve a CRL. CRL distribution points are contacted when an application or service must determine whether a certificate has been revoked before its validity period has expired.

Certification Authority Types windows 2000

To plan your CA infrastructure, you need to understand the different types of CAs available with Windows Server 2003 and the roles that they can play. Windows Server 2003 Certificate Services supports the following two types of CAs:
  • Enterprise
  • Stand-alone
Enterprise and stand-alone CAs can be configured as either Root CAs or Subordinate CAs. Subordinate CAs can further be configured as either Intermediate CAs (also referred to as a policy CA) or Issuing CAs.
Before you create your CA infrastructure, you need to determine the type or types of CAs that you plan to use, and define the specialized roles that you plan to have each CA assume.

Enterprise vs. Stand-Alone CAs

Enterprise CAs are integrated with Active Directory. They publish certificates and Certificate Revocation List to Active Directory. Enterprise CAs use information stored in Active Directory, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type.
If you want to enable automated certificate approval and automatic user certificate enrollment, use enterprise CAs to issue certificates. These features are only available when the CA infrastructure is integrated with Active Directory. Additionally, only enterprise CAs can issue certificates that enable smart card logon, because this process requires that smart card certificates be mapped automatically to the user accounts in Active Directory.
Stand-alone CAs do not require Active Directory and do not use certificate templates. If you use stand-alone CAs, all information about the requested certificate type must be included in the certificate request. By default, all certificate requests submitted to stand-alone CAs are held in a pending queue until a CA administrator approves them. You can configure stand-alone CAs to issue certificates automatically upon request, but this is less secure and is usually not recommended, because the requests are not authenticated.
From a performance perspective, using stand-alone CAs with automatic issuance enables you to issue certificates at a faster rate than you can by using enterprise CAs. However, unless you are using autoissuance, using stand-alone CAs to issue large volumes of certificates usually comes at a high administrative cost because an administrator must manually review and then approve or deny each certificate request. For this reason, stand-alone CAs are best used with public key security applications on extranets and the Internet, when users do not have Windows 2000 or Windows Server 2003 accounts, and when the volume of certificates to be issued and managed is relatively low.
Must use stand-alone CAs to issue certificates when you are using a third-party directory service or when Active Directory is not available.
Both enterprise and stand-alone certification authorities can use in your organization.


Enterprise vs. Stand-Alone CAs

Option
Enterprise CA
Stand-alone CA
Publish certificates in Active Directory and use Active Directory to validate certificate requests.
*

Take the CA offline.

*
Configure the CA to issue certificates automatically.
*

Allow administrators to approve certificate requests manually.

*
Use certificate templates.
*

Authenticate requests to Active Directory.
*


Root CAs

A root CA is the CA that is at the top of a certification hierarchy and must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.
Because there is no higher certifying authority in the certification hierarchy, the subject of the certificate issued by a root CA is also the issuer of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. Windows Server 2003 only allows you to designate a self-signed CA as a root CA. The decision to designate a CA as a trusted root CA can be made at either the enterprise level or locally, by the individual IT administrator.
A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject public key belongs to the subject identity information that is contained in the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore it is important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys.
The root CA is the most important CA in your hierarchy. If your root CA is compromised, every other CA and certificate in your hierarchy might have been compromised. You can maximize the security of the root CA by keeping it disconnected from the network and using subordinate CAs to issue certificates to other subordinate CAs or to end users.

Subordinate CAs

CAs that are not root CAs are considered subordinate. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. This first subordinate CA can, in turn, use this key to issue certificates that verify the integrity of another subordinate CA. These higher subordinate CAs are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but also serves as a higher certifying authority to one or more subordinate CAs.
An intermediate CA is often referred to as a policy CA because it is typically used to separate classes of certificates that can be distinguished by policy. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations. A policy CA can be online or offline.
Most organizations use one root CA and two policy CAs — one to support internal users, the second to support external users.