Está en la página 1de 43

PREFACE This Problem of key exchange or key agreement is quite severe and one of the most difficult challenges

to tackle in designing any computer based cryptographic solution. After a lot of thought, this problem was resolved by using digital certification techniques. A digital certificate can be compared with our passports or driving license that is used to identify an object or any entity. Digital certificate establishes the relation between a user and his public key. We could trust a digital certificate just because it contains some information about user. A digital certificate is simply a computer file. And it can be used to authentication user and entity for business transaction. A CA says I have signed this certificate to guarantee that this object or user possesses the specified public key. Trust Me.







1. ABSTRACT A digital certificate is an electronic "credit card" that establishes your credentials when doing business or other transactions on the Web. It is issued by a certification authority (CA). It contains your name, a serial number, expiration dates, a copy of the certificate holder's public key (used for encrypting messages and digital signatures), and the digital signature of the certificate-issuing authority so that a recipient can verify that the certificate is real. Some digital certificates conform to a standard, X.509. Digital certificates can be kept in registries so that authenticating users can look up other users' public keys. Digital Certificate Problems Domain Name Mismatch Your SSL digital certificate is set up to use a very specific domain name, which must match exactly to avoid getting this error. For example, if your certificate is for the domain, and you type into the browser, you will get this warning. Likewise, if your certificate is for and you enter into your browser, you will get the same warning. In order to avoid this warning, be sure to use the exact domain name on the certificate when making links to secure pages. Page contains both Secure and Insecure Data Often when making links or including images in pages the URL is an Absolute link, meaning that the link includes the protocol, domain, and path to a file. If you include an image in a page using an absolute URL, you can run into this error when the page is viewed using a different protocol than the one indicated in the image URL. For example, you might include an image in your page that looks similar to this: When you access this page through secure protocol (https) in your browser you will get the warning that the page has encrypted and unencrypted content. The easiest way to avoid this error is to use Relative paths. For example: /images/myimage.gif When linking to files on a remote server, you will have to use an absolute URL. Low-encryption browsers Many older Web Browsers only support 40 or 52 bit encryption. Because modern SSL certificates use 128 bit encryption, older browsers may not be able to view pages securely. If many of your customers are likely to be using older browsers, you may want to get a special low-encryption certificate (available from some Signing Authorities). Several modern browsers are available free of charge. You may also want to encourage users having problems with your SSL certificate to upgrade to a newer browser. The problem, however, is that anyone can create a website and key pair using a name that doesn't belong to them. This is where digital certificates come in. Digital certificates are trusted ID cards in electronic form that bind a website's public encryption key to their identity for purposes of public trust. Digital certificates are issued by an independent, recognized and mutually trusted third party that guarantees that the website operating is who it claims to be. This third party is known as a Certification Authority (CA). Without digital certificates, the public has little assurance as to the legitimacy of any particular website. A digital certificate contains an entity's name, address, serial number, public key, expiration date and digital signature, among other information. When a Web browser like Firefox, Netscape or Internet

Explorer makes a secure connection, the digital certificate is automatically turned over for review. The browser checks it for anomalies or problems, and pops up an alert if any are found. When digital certificates are in order, the browser completes secure connections without interruption. Though rare, there have been cases of phishing scams duplicating a website and 'hijacking' the site's digital certificate to fool customers into giving up personal information. These scams involved redirecting the customer to the real site for authentication, then bringing them back to the duped website. Other phishing scams use self-signed digital certificates to dispose of the trusted third party or Certificate Authority altogether. The issuer of the digital certificate and the signer are one in the same. A browser will alert in this case, but most users click through anyway, not understanding the difference. Digital certificates play an integral role in keeping online commerce safe. If your browser alerts you to a problem with a digital certificate, you are well-advised not to click through. Instead, call the business using a telephone number from your statements or phone book, and inquire as to the problem.

2. INTRODUCTION Project Description: A digital certificate contains an entity's name, address, serial number, public key, expiration date and digital signature, among other information. When a Web browser like Firefox, Netscape or Internet Explorer makes a secure connection, the digital certificate is automatically turned over for review. The browser checks it for anomalies or problems, and pops up an alert if any are found. When digital certificates are in order, the browser completes secure connections without interruption. Project Scope: Signing messages authenticates the sender of the message and ensures the message has not been modified since it was sent. The receiver can verify whether the message has been altered since it was sent and whether the information has come from the appropriate sender or not. The different levels of the module are: -. 1. Checking the Signer for authorization. 2. Digitally Signing the files. 3. Verification of Digital Signatures.

Key Words: - Public Key Infrastructure, Certificates, Smart Cards

3. PROJECT SCOPE Virtual malls, electronic banking, and other electronic services are becoming more commonplace, offering the convenience and flexibility of round-the-clock service direct from Our home. However, Our concerns about privacy and security might be preventing you from taking advantage of this new medium for our personal business. Encryption alone is not enough, as it provides no proof of the identity of the sender of the encrypted information. Without special safeguards, our risk being impersonated online. Digital Certificates address this problem, providing an electronic means of verifying someone's identity. Used in conjunction with encryption, Digital Certificates provide a more complete security solution, assuring the identity of all parties involved in a transaction. Digital Certificates can be used for a variety of electronic transactions including e-mail, electronic commerce, groupware and electronic funds transfers. Netscape's popular Enterprise Server requires a Digital Certificate for each secure server. For example, a customer shopping at an electronic mall run by Netscape's server software requests the Digital Certificate of the server to authenticate the identity of the mall operator and the content provided by the merchant. Without authenticating the server, the shopper should not trust the operator or merchant with sensitive information like a credit card number. The Digital Certificate is instrumental in establishing a secure channel for communicating any sensitive information back to the mall operator. Similarly, a secure server must have its own Digital Certificate to assure users that the server is run by the organisation it claims to be affiliated with and that the content provided is legitimate There is a range of potential advantages in using PKI, including its cryptographic strength and resistance to identity theft (when implemented with private keys in hardware). Many of its benefits are If a digitally signed document is archived and checked at a later date, the quality of the signature remains undiminished over many years, even if the public key certificate has long since expired. And, if a digitally signed message is passed from one relying party to another and on to many more, passing through all manner of intermediate systems, everyone still receives an identical, verifiable signature code authenticating the original message. Electronic evidence of the origin and integrity of a message can, of course, be provided by means other than a digital signature. For example, the authenticity of typical e-business transactions can usually be demonstrated after the fact via audit logs, which indicate how a given message was created and how it moved from one machine to another. Secondly, digital certificates are machine readable, allowing the credentials or affiliations of the sender to be bound to the message and verified automatically on receipt, enabling totally paperless transacting. This is an important but often overlooked benefit of digital signatures. When processing a digital certificate chain, relying party software can automatically tell that the message has not been altered since it was originally created; that the sender was authorized to launch the transaction, by virtue of credentials or other properties endorsed by a recognized CA; that the sender's credentials were valid at the time they sent the message; and that the authority which signed the certificate was fit to do so.

One reason we can overlook machine readability is that we have probably come to expect person-toperson email to be the archetypal PKI application, thanks to email being the classic example to illustrate PKI in action. There is an implicit suggestion in most PKI marketing and training that, in regular use, we should manually click on a digital signature icon, examine the certificate, check which CA issued it, read the policy qualifier, and so on. Yet the overwhelming experience of PKI in practice is that it suits special purpose and highly automated applications, where the usual receiver of signed transactions is in fact a computer. Requirements for Message Transmission Security The requirements of a security regime which addresses these risks are conventionally summarized under four broad headings. For the sender and receiver to be confident in the outcome of their communications, all of these requirements need to be satisfied. (1) 'Confidentiality', or Message Content Security : This comprises two separate requirements, that, during a message's transit from sender to receiver: No observer can access the contents of the message; and No observer can identify the sender and receiver. The term 'confidentiality' is used by computer scientists who specialize in security matters. This is most unfortunate, because the term has an entirely different meaning within commerce generally, which derives from the law of confidence. For this reason, the alternative term 'message content security' is used in this Module. (2) Integrity of Message Content : This requires that the recipient can be sure that, whether accidentally, or because of an action by any party: The message has not been changed or lost during transmission; The message has not been prevented from reaching the recipient; and The message has not reached the recipient twice. (3) Authentication of the Sender and Recipient : This requires that: The sender can be sure that the message reaches the intended recipient, and only the intended recipient; and The recipient can be sure that the message came from the sender and not an imposter. The act by an imposter of sending such a message is referred to as 'spoofing'.

(4) Non-Repudiation by the Sender and Recipient : This requires that: The sender cannot credibly deny that the message was sent by them; and The recipient cannot credibly deny that the message was received by them.

4. Centralised approach


Where the PKI Certification Authority (CA), in addition to authenticating the identity of a party, is itself in charge both to verify the attributes and to certify those attributes. From a technical point of view, the certified attributes could be stored directly in the certificate, usually in the X509 standards extension, however every time an attribute changes, the certificate would have to be revoked and then re-issue. Another option would be to store them in a parallel certified database managed by the CA; this model has been adopted, for instance, by Enterprise CA & XUDA of Xcert. Distributed approach Where the personal identity information is certified by the PKI CA and all other information is provided and certified by the "direct" owner (or manager) of the attribute information (i.e. the university for a registered student, a medical or engineering association for professionals, etc), From a technical point of view, "matching" codes and procedures are available in order to link the identity certificate to all the other attributes available on the Internet. The fundamental objective is to set-up and to demonstrate an "infrastructure" able to solve both the AUTHENTICATION and the AUTHORISATION issues, letting each attribute owner or manager directly certify the attributes of individuals. The assumption which we intend to demonstrate, is that the distributed approach, if proved feasible, would be inherently much more democratic (no big centralized database gathering all kinds of personal information), manageable in administrative terms (any attribute change would be immediately made available to interested parties) and, for these reasons, successful. Three secure applications have been developed and demonstrated, one in each of three European cities (Barcelona, Bologna, Salford) in order to prove the validity of the entire infrastructure (i.e. an interoperable and scalable PKI and PMI able to solve any issue related to identification, authentication and authorisation in an e-Government environment) and in order to prove the usefulness and success of such electronic services. The project uses public-key infrastructures (PKI) necessary to securely manage public keys for widelydistributed users or systems and required to provide encryption and digital signature services. The PERMIS PKIs will be compliant to the X.509 standard, a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs); PKI technology solves the problem of "who is this person" trying to do business with you, by providing strong identification and authentication with digital certificates, and allows reliable business communications by providing privacy and data integrity through the use of encryption and non repudiation through the use of digital signatures.

5. FEASIBILITY STUDY Preliminary investigations examine project feasibility; the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the technical, operational and Economical feasibility of the developing computerized system. All systems are feasible if they have unlimited resources and infinite time. There are three aspects in the feasibility study portion of the preliminary investigation: 1. 2. 3. Technical Feasibility. Operational Feasibility. Economical Feasibility.

Technical Feasibility The technical issues usually rose during the feasibility stage of the investigation includes the following: Does the necessary technology exist to do what is suggested? Do the proposed equipments have the technical capacity to hold the data required to use the new system? Will the proposed system provide adequate responses to inquiries regardless of the number or location of users? Can the system be upgraded if developed? Are there technical guarantees of accuracy, reliability, ease of access and data security?

Earlier no system existed to cater to the needs of API for Signing and Verification of the files stored locally on the system. The current system developed is technically feasible. It is a technical application. Roles of the users are clearly defined. Therefore, it provides the technical guarantee of accuracy, reliability and security. Operational Feasibility Proposed projects are beneficial only if they can be turned out into information systems that will meet the organizations operating requirements. An Operational feasibility aspect of the project is to be taken as an important part of the project implementation. Some of the important issues raised to test the operational feasibility of a project include the following: -

Is there sufficient support for the project for management from users? Will the system be used and work properly if it is being developed and implemented? Will there be any resistance from the users that will undermine the possible application benefits?

This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the management issues and user requirements has been taken into consideration. So there is no question of resistance from the users that can undermine the possible application benefits. The well-planned design would ensure the optimal utilization of the computer resources and would help in the improvement of performance status. Economic Feasibility A system that can be developed technically and that will be used if installed must still be a good investment for the organization. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs. The system is economically feasible. It does not require any additional hardware or software.

6. SYSTEM REQUIREMENT System Specification The basic software and hardware requirements for the project include the following: Hardware Requirements Processor: Intel Pentium 4 with C.P.U of 1.60 GHz. Memory: Memory chip of 260,000 KB is required. Storage Capacity: Storage capacity of 16 GB is required. Ethernet Card Smart Card Reader Software Requirements JDK: Java Development Kit and its version is dependent upon the Version of Tomcat Web Server used. JDK version used is JDK1.5.1_06. Operating System: Microsoft Windows XP.

7. SYSTEM ANALYSIS Introduction System analysis refers to the process of examining the situation of an organization with the view of improving it through better procedures and methods. It is a process of gathering and interpreting facts, diagnosing problems, and using the information to recommend improvements to the system.

The manner in which a systems investigation is conducted will determine whether the appropriate information has been gathered. In turn, having the right information influences the quality of the application that follows. A good system design begins by documenting the current system and properly diagnosing systems requirements. Analysis Model The model that is basically being followed is the WATER FALL MODEL, which states that the phases are organized in a linear order. First of all the feasibility study is done. Once that part is over the Requirement Analysis and project planning begins. The design starts after the requirement analysis is complete and the coding begins after the design is complete. Once the programming is completed, the testing is done. In this model the sequence of activities performed in a software development project are: Requirement analysis Project Planning System design Detail Design

Coding Unit Testing System integration & Testing

Here the linear ordering of theses activities is critical .End of the phase and the output of one phase is the input of another phase. The output of each phase has to be consistent with the overall requirement of the system. Some of the qualities of spiral model are also incorporated like after the people concerned with the project review completion of each of the phase the work done.

Changed Requirements Communicated Requirements

Requirements Engineering

Requirements Specification


Design Specification Maintenance Programming Executable Software Modules


Process Integration Process Iteration Product


Integrated Software Product

Product Maintenance



Delivered Software Product

WATER FALL Model was being chosen because all the requirements were known beforehand and the objective of our software development is the











Certificate Generation

End Entity

Request to generate a public key Certificate Authority (CA)

Signing Public Key Process with CAs Private Key

Generate the Public Key

Generating the Certificate

Digital Certificate



Certification Authority Recertify Certi fy Yes

Content Server

Certificate Response

Certificate Request

Content User


10. WHAT IS A DIGITAL CERTIFICATE? Digital Certificates are the electronic counterparts to driver licenses, passports and membership cards. You can present a Digital Certificate electronically to prove your identity or your right to access information or services online. Digital Certificates, also known as digital certificates, bind an identity to a pair of electronic keys that can be used to encrypt and sign digital information. A Digital Certificate makes it possible to verify someone's claim that they have the right to use a given key, helping to prevent people from using phony keys to impersonate other users. Used in conjunction with encryption, Digital Certificates provide a more complete security solution, assuring the identity of all parties involved in a transaction. A Digital Certificate is issued by a Certification Authority (CA) and signed with the CA's private key. A Digital Certificate typically contains the: 1. 2. 3. 4. 5. 6. Owner's public key Owner's name Expiration date of the public key Name of the issuer (the CA that issued the Digital Certificate Serial number of the Digital Certificate Digital signature of the issuer

The most widely accepted format for Digital Certificates is defined by the CCITT X.509 international standard; thus certificates can be read or written by any application complying with X.509. Further refinements are found in the PKCS standards and the PEM standard. A digital signature functions for electronic documents like a handwritten signature does for printed documents. The signature is an unforgeable piece of data that asserts that a named person wrote or otherwise agreed to the document to which the signature is attached. A digital signature actually provides a greater degree of security than a handwritten signature. The recipient of a digitally signed message can verify both that the message originated from the person whose signature is attached and that the message has not been altered either intentionally or accidentally since it was signed. Furthermore, secure digital signatures cannot be repudiated; the signer of a document cannot later disown it by claiming the signature was forged. In other words, Digital Signatures enable "authentication" of digital messages, assuring the recipient of a digital message of both the identity of the sender and the integrity of the message Certificate Types There are four kinds of digital certificates used on the Internet: Personal Certificates: These certificates identify individuals. They may be used to authenticate users with a server, or to enable secure e-mail using S-Mime. Microsoft recommends exporting your personal certificates to a

safe location as a form of backup in case your certificates are damaged. If a password list file (.pwl) becomes damaged or missing, the certificate is not available for use, and you may receive an error message when you try to send e-mail. For more information about this issue see the following articles in the Microsoft Knowledge Base: 190296 ( ) Unable to Use Personal Certificates in Outlook Express 132807 ( ) Enhanced Encryption for Windows 95 Password Cache Server Certificates: Server certificates identify servers that participate in secure communications with other computers using communication protocols such as SSL. These certificates allow a server to verify its identity to clients. Server certificates follow the X.509 certificate format that is defined by the Public-Key Cryptography Standards (PKCS). Software Publisher Certificates: Microsoft Authenticode does not guarantee that signed code is safe to run, but rather informs the user whether or not the publisher is participating in the infrastructure of trusted publishers and CAs. These certificates are used to sign software to be distributed over the Internet. Authenticode requires a software publisher certificate to sign Microsoft ActiveX and other compiled code. Internet Explorer is also capable of trusting software that is signed with a publisher's certificate. To view a list of trusted software publishers in Internet Explorer, click Internet Options on the Tools menu, click the Content tab, and then click Publishers. You can also remove trusted publishers by clicking Remove in this screen. Certificate Authority Certificates: Internet Explorer 5 divides CAs into two categories, Root Certification Authorities and Intermediate Certification Authorities. Root certificates are self-signed, meaning that the subject of the certificate is also the signer of the certificate. Root Certification Authorities have the ability to assign certificates for Intermediate Certification Authorities. An Intermediate Certification Authority has the ability to issue server certificates, personal certificates, publisher certificates, or certificates for other Intermediate Certification Authorities. For example, if you click Certificates on the Content tab in the Internet Explorer Properties dialog box, a list of certificates that are installed on your computer is displayed. There is a trusted Root Authority listed as "Class 1 Public Primary Certification Authority" (which is run by VeriSign). This certificate is issued and signed by the Class 1 Public Primary Certificate Authority, and is therefore a root certificate. On the Intermediate Certification Authorities tab, there are several certificates listed as "VeriSign Class 1 CA." The root certificate mentioned above issued these certificates. These Intermediate Certificate Authorities were created for the purpose of issuing and validating personal digital certificates, so if a person has obtained a Class 1 personal digital certificate from VeriSign, it will be issued by one of these Intermediate CAs. This creates what is known as a verification chain. In this case, there are only three certificates in the verification chain for a personal certificate. However, verification chains can contain a large number of certificates depending upon the number of Intermediate Certification Authorities in the chain.

The verification chain for a certificate can be viewed by double-clicking the certificate and then clicking the Certification Path tab. Suppose Alice wants to send a signed message to Bob. She creates a message digest by using a hash function on the message. The message digest serves as a "digital fingerprint" of the message; if any part of the message is modified, the hash function returns a different result. Alice then encrypts the message digest with her private key. This encrypted message digest is the digital signature for the message. Alice sends both the message and the digital signature to Bob. When Bob receives them, he decrypts the signature using Alice's public key, thus revealing the message digest. To verify the message, he then hashes the message with the same hash function Alice used and compares the result to the message digest he received from Alice. If they are exactly equal, Bob can be confident that the message did indeed come from Alice and has not changed since she signed it. If the message digests are not equal, the message either originated elsewhere or was altered after it was signed. Note that using a digital signature does not encrypt the message itself. If Alice wants to ensure the privacy of the message, she must also encrypt it using Bob's public key. Then only Bob can read the message by decrypting it with his private key. It is not feasible for anyone to either find a message that hashes to a given value or to find two messages that hash to the same value. If either were feasible, an intruder could attach a false message onto Alice's signature. Specific hash functions have been designed to have the property that finding a match is not feasible, and are therefore considered suitable for use in cryptography. One or more Digital Certificates can accompany a digital signature. If a Digital Certificate is present, the recipient (or a third party) can check the authenticity of the public key. Now we have a confusion that is how long do digital signatures remain valid? Normally, a key expires after some period of time, such as one year, and a document signed with an expired key should not be accepted. However, there are many cases where it is necessary for signed documents to be regarded as legally valid for much longer than two years; long-term leases and contracts are examples. By registering the contract with a digital time-stamping service at the time it is signed, the signature can be validated even after the key expires. If all parties to the contract keep a copy of the time-stamp, each can prove that the contract was signed with valid keys. In fact, the time-stamp can prove the validity of a contract even if one signer's key gets compromised at some point after the contract was signed. Any digitally signed document can be time-stamped, assuring that the validity of the signature can be verified after the key expires.

11. VARIOUS PHASES Here is the Following Phases for how a Certificate Is Issued: Key Generation: The individual requesting certification (the applicant, not the CA) generates key pairs of public and private keys. Matching of Policy Information: The applicant packages the additional information necessary for the CA to issue the certificate (such as proof of identity, tax ID number, e-mail address, and so on). The precise definition of this information is up to the CA. Sending of Public Keys and Information: The applicant sends the public keys and information (often encrypted using the CA's public key) to the CA. Verification of Information: The CA applies whatever policy rules it requires in order to verify that the applicant should receive a certificate. Certificate Creation: The CA creates a digital document with the appropriate information (public keys, expiration date, and other data) and signs it using the CA's private key. Sending/Posting of Certificate: The CA may send the certificate to the applicant, or post it publicly as appropriate. The certificate is loaded onto an individual's computer.



When you receive digitally signed messages, you can verify the signer's Digital Certificate to determine that no forgery or false representation has occurred. When you send messages, you can sign the messages and enclose your Digital Certificate to assure the recipient of the message that the message was actually sent by you. Multiple Digital Certificates can be enclosed with a message, forming a hierarchical chain, wherein one Digital Certificate testifies to the authenticity of the previous Digital Certificate. At the end of a Digital Certificate hierarchy is a toplevel Certification Authority, which is trusted without a Digital Certificate from any other Certification Authority. The public key of the top-level Certification Authority must be independently known, for example by being widely published. The more familiar you are to the recipient of the message, the less need there is to enclose Digital Certificate. You can also use a Digital Certificate to identify yourself to secure servers such as membership-based Web servers. Generally, once you've obtained a Digital Certificate, you can set up your security-enhanced Web or email application to use the Digital Certificate automatically. How Digital Certificates (SSL) Work: In physical transactions, the challenges of identification, authentication, and privacy are solved with physical marks, such as seals or signatures. In electronic transactions, the equivalent of a seal must be coded into the information itself. By checking that the electronic seal is present and has not been broken, the recipient can confirm the identity of the message sender and ensure that the message content was not altered in transit. To create an electronic equivalent of physical security, some vendors use advanced cryptography. Throughout history, most private messages were kept secret with single key cryptography. Single key cryptography is the way that most secret messages have been sent over the centuries. In single key cryptography, there is a unique code (or key) for both encrypting and decrypting messages. Single key cryptography works as follows: Suppose Bob has one secret key. If Alice wants to send Bob a secret message: Bob sends Alice a copy of his secret key. Alice encrypts a message with Bobs secret key. Bob decrypts the message with his secret key. Unfortunately, this method has several problems. First, Bob must find a secure method of getting his secret key to Alice. If the secret key is intercepted, all of Bobs communications are compromised. Second, Bob needs to trust Alice. If Alice is a double agent, she may give Bobssecret key to his enemies. Or, she may read Bobs other private messages or even imitate Bob. Finally, if you have an organization with people who need to exchange secret messages, you will either need to have thousands (if not millions) of secret keys, or you will need to rely on a smaller number of keys, which opens the door to compromise.

SSL certificate technology employs the more advanced public key cryptography, which does not involve the sharing of secret keys. Rather than using the same key to both encrypt and decrypt data, an SSL certificate uses a matched pair of keys that uniquely complement each other. When a message is encrypted by one key, only the other key can decrypt it. When a key pair is generated for your business, your private key is installed on your server; nobody else has access to it. Your matching public key, in contrast, is freely distributed as part of your SSL certificate. You can share it with anyone, and even publish it in directories. Customers or correspondents who want to communicate with you privately can use the public key in your SSL certificate to encrypt information before sending it to you. Only you can decrypt the information, because only you have your private key. Your SSL certificate contains your name and identifying information, your public key, and the CAs own digital signature as certification. It tells customers and correspondents that your public key belongs to you.

X.509 Version 3 Public Key Certificate Digitally Signed By Issuing CA

Contents of Digital Certificate: Version: 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 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. Subject's 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 CA's private key. This field includes the signature algorithm identifier. Certificates and web site security:

The most common use of certificates is for HTTPS-based web sites. A web browser validates that an SSL (Transport Layer Security) web server is authentic, so that the user can feel secure that their interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate provider with a certificate signing request. The certificate request is an electronic document that contains the web site name, contact email address, and company information. The certificate provider signs the request, thus producing a public certificate. This public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believes it has issued a certificate to the owner of the web site. Before issuing a certificate, the certificate provider will request the contact email address for the web site from a public domain name registrar, and check that published address against the email address supplied in the certificate request. Therefore, an https web site is only secure to the extent that the end user can be sure that the web site is operated by someone in contact with the person that registered the domain name. As an example, when a user connects to with their browser, if the browser gives no certificate warning message, then the user can be theoretically sure that interacting with is equivalent to interacting with the entity in contact with the email address listed in the public registrar under "", even though that email address may not be displayed anywhere on the web site. No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed. At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted. Certificate server: Certificate servers validate, or certify, keys as part of a Public key infrastructure. Keys are strings of text generated from a series of encryption algorithms that allow you to secure communication for a group of users. Many Web servers, such as Microsoft's Internet Information Services (IIS) or Apache's mod_ssl create keys that after having been validated, can be applied to other servers such as News servers or Web servers. The purpose of this process is to create a way for people to communicate and be reasonably sure that others are not eavesdropping or assuming a false identity. Authorization certificate: In computer security, an authorization certificate (also known as an attribute certificate) is a digital document that describes a written permission from the issuer to use a service or a resource that the issuer controls or has access to use. The permission can be delegated. From RFC 3281[1] (PKC and AC refer to public key certificate and attribute certificate respectively): Some people constantly confuse PKCs and ACs. An analogy may make the distinction clear. A PKC can be considered to be like a passport: it identifies the holder, tends to last for a long time, and should not be trivial to obtain. An AC is more like an entry visa: it is typically issued by a different authority and does not last for as long a time. As acquiring an entry visa typically requires presenting a passport, getting a visa can be a simpler process. A real life example of this can be found in the mobile software deployments by large service providers and are typically applied to platforms such as Microsoft Smartphone (and related), Symbian OS, J2ME and others. In each of these systems a mobile communications service provider may customize the mobile terminal client distribution (ie. the mobile phone operating system or application environment) to include one or more root certificates each associated with a set of capabilities or permissions such as "update firmware", "access address book", "use radio interface", and the most basic

one, "install and execute". When a developer wishes to enable distribution and execution in one of these controlled environments they must acquire a certificate from an appropriate CA, typically a large commercial CA, and in the process they usually have their identity verified using out-of-band mechanisms such as a combination of phone call, validation of their legal entity through government and commercial databases, etc., similar to the high assurance SSL certificate vetting process, though often there are additional specific requirements imposed on would-be developers/publishers. Once the identity has been validated they are issued an identity certificate they can use to sign their software; generally the software signed by the developer or publisher's identity certificate is not distributed but rather it is submitted to processor to possibly test or profile the content before generating an authorization certificate which is unique to the particular software release. That certificate is then used with an ephemeral asymmetric key-pair to sign the software as the last step of preparation for distribution. There are many advantages to separating the identity and authorization certificates especially relating to risk mitigation of new content being accepted into the system and key management as well as recovery from errant software which can be used as attack vectors. This solution prevents the service or resource host from having to use large access control lists. It is similar to the idea of capabilities: store the permission (or permissions) with a protected pointer to the object but not with the object itself. Certificates As a first attempt at distributing public keys securely, we could imagine a key distribution center available on-line 24 hours a day to provide public keys on demand. One of the many problems with this solution is that it is not scalable, and the key distribution center would rapidly become a bottleneck. Also, if it ever went down, Internet security would suddenly grind to a halt. For these reasons, people have developed a different solution, one that does not require the key distribution center to be on-line all the time. In fact, it does not have to be on-line at all. Instead, what it does is certify the public keys belonging to people, companies, and other organizations. An organization that certifies public keys is now called a CA (Certification Authority). As an example, suppose that Bob wants to allow Alice and other people to communicate with him securely. He can go to the CA with his public key along with his passport or driver's license and ask to be certified. The CA then issues a certificate similar to the one in Fig. 8-24 and signs its SHA-1 hash with the CA's private key. Bob then pays the CA's fee and gets a floppy disk containing the certificate and its signed hash. A possible certificate and its signed hash.

The fundamental job of a certificate is to bind a public key to the name of a principal (individual, company, etc.). Certificates themselves are not secret or protected. Bob might, for example, decide to

put his new certificate on his Web site, with a link on the main page saying: Click here for my publickey certificate. The resulting click would return both the certificate and the signature block (the signed SHA-1 hash of the certificate). Now let us run through the scenario of Fig. 8-23 again. When Trudy intercepts Alice's request for Bob's home page, what can she do? She can put her own certificate and signature block on the fake page, but when Alice reads the certificate she will immediately see that she is not talking to Bob because Bob's name is not in it. Trudy can modify Bob's home page on-the-fly, replacing Bob's public key with her own. However, when Alice runs the SHA-1 algorithm on the certificate, she will get a hash that does not agree with the one she gets when she applies the CA's well-known public key to the signature block. Since Trudy does not have the CA's private key, she has no way of generating a signature block that contains the hash of the modified Web page with her public key on it. In this way, Alice can be sure she has Bob's public key and not Trudy's or someone else's. And as we promised, this scheme does not require the CA to be on-line for verification, thus eliminating a potential bottleneck. While the standard function of a certificate is to bind a public key to a principal, a certificate can also be used to bind a public key to an attribute. For example, a certificate could say: This public key belongs to someone over 18. It could be used to prove that the owner of the private key was not a minor and thus allowed to access material not suitable for children, and so on, but without disclosing the owner's identity. Typically, the person holding the certificate would send it to the Web site, principal, or process that cared about age. That site, principal, or process would then generate a random number and encrypt it with the public key in the certificate. If the owner were able to decrypt it and send it back, that would be proof that the owner indeed had the attribute stated in the certificate. Alternatively, the random number could be used to generate a session key for the ensuing conversation. Another example of where a certificate might contain an attribute is in an object-oriented distributed system. Each object normally has multiple methods. The owner of the object could provide each customer with a certificate giving a bit map of which methods the customer is allowed to invoke and binding the bit map to a public key using a signed certificate. Again here, if the certificate holder can prove possession of the corresponding private key, he will be allowed to perform the methods in the bit map. It has the property that the owner's identity need not be known, a property useful in situations where privacy is important. Figure Public-Key Certificate Use

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 shows the general format of a certificate, which includes the following elements:

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. The standard uses the following notation to define a certificate: CA<<A>> = CA {V, SN, AI, CA, TA, A, Ap} where Y <<X>> = 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

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. This is the typical digital signature approach illustrated in Figure 11.5c. Obtaining a User's Certificate User certificates generated by a CA have the following characteristics: Any user with access to the public key of the CA can verify the user public key that was certified. No party other than the certification authority can modify the certificate without this being detected.

Because certificates are unforgeable, they can be placed in a directory without the need for the directory to make special efforts to protect them. If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates can be placed in the directory for access by all users. In addition, a user can transmit his or her certificate directly to other users. In either case, once B is in possession of A's certificate, B has confidence that messages it encrypts with A's public key will be secure from eavesdropping and that messages signed with A's private key are unforgeable. If there is a large community of users, it may not be practical for all users to subscribe to the same CA. Because it is the CA that signs certificates, each participating user must have a copy of the CA's own public key to verify signatures. This public key must be provided to each user in an absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical for there to be a number of CAs, each of which securely provides its public key to some fraction of the users. Now suppose that A has obtained a certificate from certification authority X1 and B has obtained a certificate from CA X2. If A does not securely know the public key of X2, then B's certificate, issued by X2, is useless to A. A can read B's certificate, but A cannot verify the signature. However, if the two CAs have securely exchanged their own public keys, the following procedure will enable A to obtain B's public key: A obtains, from the directory, the certificate of X2 signed by X1. Because A securely knows X1's public key, A can obtain X2's public key from its certificate and verify it by means of X1's signature on the certificate. A then goes back to the directory and obtains the certificate of B signed by X2 Because A now has a trusted copy of X2's public key, A can verify the signature and securely obtain B's public key. A has used a chain of certificates to obtain B's public key. In the notation of X.509, this chain is expressed as X1<<X2>> X2 <<B>> In the same fashion, B can obtain A's public key with the reverse chain: X2<<X1>> X1 <<A>> This scheme need not be limited to a chain of two certificates. An arbitrarily long path of CAs can be followed to produce a chain. A chain with N elements would be expressed as X1<<X2>> X2 <<X3>>... XN<<B>> In this case, each pair of CAs in the chain (Xi, Xi+1) must have created certificates for each other. All these certificates of CAs by CAs need to appear in the directory, and the user needs to know how they are linked to follow a path to another user's public-key certificate. X.509 suggests that CAs be arranged in a hierarchy so that navigation is straightforward.

Figure 14.5, taken from X.509, is an example of such a hierarchy. The connected circles indicate the hierarchical relationship among the CAs; the associated boxes indicate certificates maintained in the directory for each CA entry. The directory entry for each CA includes two types of certificates: Forward certificates: Certificates of X generated by other CAs Reverse certificates: Certificates generated by X that are the certificates of other CAs

X.509 Hierarchy: A Hypothetical Example In this example, user A can acquire the following certificates from the directory to establish a certification path to B: X<<W>> W <<V>> V <<Y>> <<Z>> Z <<B>> When A has obtained these certificates, it can unwrap the certification path in sequence to recover a trusted copy of B's public key. Using this public key, A can send encrypted messages to B. If A wishes to receive encrypted messages back from B, or to sign messages sent to B, then B will require A's public key, which can be obtained from the following certification path:

Z<<Y>> Y <<V>> V <<W>> W <<X>>X <<A>> B can obtain this set of certificates from the directory, or A can provide them as part of its initial message to B. Revocation of Certificates Recall from Figure 14.4 that each certificate includes a period of validity, much like a credit card. Typically, a new certificate is issued just before the expiration of the old one. In addition, it may be desirable on occasion to revoke a certificate before it expires, for one of the following reasons: The user's private key is assumed to be compromised. The user is no longer certified by this CA. The CA's certificate is assumed to be compromised. Each CA must maintain a list consisting of all revoked but not expired certificates issued by that CA, including both those issued to users and to other CAs. These lists should also be posted on the directory. Each certificate revocation list (CRL) posted to the directory is signed by the issuer and includes (Figure 14.4b) the issuer's name, the date the list was created, the date the next CRL is scheduled to be issued, and an entry for each revoked certificate. Each entry consists of the serial number of a certificate and revocation date for that certificate. Because serial numbers are unique within a CA, the serial number is sufficient to identify the certificate. When a user receives a certificate in a message, the user must determine whether the certificate has been revoked. The user could check the directory each time a certificate is received. To avoid the delays (and possible costs) associated with directory searches, it is likely that the user would maintain a local cache of certificates and lists of revoked certificates. Authentication Procedures X.509 also includes three alternative authentication procedures that are intended for use across a variety of applications. All these procedures make use of public-key signatures. It is assumed that the two parties know each other's public key, either by obtaining each other's certificates from the directory or because the certificate is included in the initial message from each side.

Figure X.509 Strong Authentication Procedures One-Way Authentication One way authentication involves a single transfer of information from one user (A) to another (B), and establishes the following: The identity of A and that the message was generated by A That the message was intended for B The integrity and originality (it has not been sent multiple times) of the message Note that only the identity of the initiating entity is verified in this process, not that of the responding entity.

At a minimum, the message includes a timestamp tA, a nonce rA and the identity of B and is signed with A's private key. The timestamp consists of an optional generation time and an expiration time. This prevents delayed delivery of messages. The nonce can be used to detect replay attacks. The nonce value must be unique within the expiration time of the message. Thus, B can store the nonce until it expires and reject any new messages with the same nonce. For pure authentication, the message is used simply to present credentials to B. The message may also include information to be conveyed. This information, sgnData, is included within the scope of the signature, guaranteeing its authenticity and integrity. The message may also be used to convey a session key to B, encrypted with B's public key. Two-Way Authentication In addition to the three elements just listed, two-way authentication establishes the following elements: The identity of B and that the reply message was generated by B That the message was intended for A The integrity and originality of the reply Two-way authentication thus permits both parties in a communication to verify the identity of the other. The reply message includes the nonce from A, to validate the reply. It also includes a timestamp and nonce generated by B. As before, the message may include signed additional information and a session key encrypted with A's public key. Three-Way Authentication In three-way authentication, a final message from A to B is included, which contains a signed copy of the nonce rB. The intent of this design is that timestamps need not be checked: Because both nonces are echoed back by the other side, each side can check the returned nonce to detect replay attacks. This approach is needed when synchronized clocks are not available. X.509 Version 3 The X.509 version 2 format does not convey all of the information that recent design and implementation experience has shown to be needed. [FORD95] lists the following requirements not satisfied by version 2: 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. 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. 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.

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. It is important to be able to identify different keys used by the same owner at different times. This feature supports key life cycle 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. The certificate extensions fall into three main categories: key and policy information, subject and issuer attributes, and certification path constraints. Key and Policy Information These extensions convey additional information about the subject and issuer keys, plus indicators of certificate policy. A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a policy might be applicable to the authentication of electronic data interchange (EDI) transactions for the trading of goods within a given price range. This area includes the following: Authority key identifier: Identifies the public key to be used to verify the signature on this certificate or CRL. Enables distinct keys of the same CA to be differentiated. One use of this field is to handle CA key pair updating. Subject key identifier: Identifies the public key being certified. Useful for subject key pair updating. Also, a subject may have multiple key pairs and, correspondingly, different certificates for different purposes (e.g., digital signature and encryption key agreement). Key usage: Indicates a restriction imposed as to the purposes for which, and the policies under which, the certified public key may be used. May indicate one or more of the following: digital signature, nonrepudiation, key encryption, data encryption, key agreement, CA signature verification on certificates, CA signature verification on CRLs. Private-key usage period: Indicates the period of use of the private key corresponding to the public key. Typically, the private key is used over a different period from the validity of the public key. For example, with digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key. Certificate policies: Certificates may be used in environments where multiple policies apply. This extension lists policies that the certificate is recognized as supporting, together with optional qualifier information.

Policy mappings: Used only in certificates for CAs issued by other CAs. Policy mappings allow an issuing CA to indicate that one or more of that issuer's policies can be considered equivalent to another policy used in the subject CA's domain. Certificate Subject and Issuer Attributes These extensions support alternative names, in alternative formats, for a certificate subject or certificate issuer and can convey additional information about the certificate subject, to increase a certificate user's confidence that the certificate subject is a particular person or entity. For example, information such as postal address, position within a corporation, or picture image may be required. The extension fields in this area include the following: Subject alternative name: Contains one or more alternative names, using any of a variety of forms. This field is important for supporting certain applications, such as electronic mail, EDI, and IPSec, which may employ their own name forms. Issuer alternative name: Contains one or more alternative names, using any of a variety of forms. Subject directory attributes: Conveys any desired X.500 directory attribute values for the subject of this certificate. Certification Path Constraints These extensions allow constraint specifications to be included in certificates issued for CAs by other CAs. The constraints may restrict the types of certificates that can be issued by the subject CA or that may occur subsequently in a certification chain. The extension fields in this area include the following: Basic constraints: Indicates if the subject may act as a CA. If so, a certification path length constraint may be specified. Name constraints: Indicates a name space within which all subject names in subsequent certificates in a certification path must be located. Policy constraints: Specifies constraints that may require explicit certificate policy identification or inhibit policy mapping for the remainder of the certification path. If everybody who wanted something signed went to the CA with a different kind of certificate, managing all the different formats would soon become a problem. To solve this problem, a standard for certificates has been devised and approved by ITU. The standard is called X.509 and is in widespread use on the Internet. It has gone through three versions since the initial standardization in 1988. We will discuss V3. X.509 has been heavily influenced by the OSI world, borrowing some of its worst features (e.g., naming and encoding). Surprisingly, IETF went along with X.509, even though in nearly every other area, from machine addresses to transport protocols to e-mail formats, IETF generally ignored OSI and tried to do it right. The IETF version of X.509 is described in RFC 3280.

At its core, X.509 is a way to describe certificates. The primary fields in a certificate are listed in Fig. 8-25. The descriptions given there should provide a general idea of what the fields do. For additional information, please consult the standard itself or RFC 2459.

13. Public Key Infrastructure (PKI) Storing methods for Public and Private Keys Certificates Public keys are stored within digital certificates along with other relevant information (user information, expiration date, usage, who issued the certificate etc.). The CA enters the information contained within the certificate when it is issued and this information cannot be changed. Since the certificate is digitally signed and all the information in it is intended to be publicly available there is no need to prevent access to reading it, although you should prevent other users from corrupting, deleting or replacing it. Protection If someone gains access to your computer they could easily gain access to your private key(s). For this reason, access to a private key is generally protected with a password of your choice. Private key passwords should never be given to anyone else and should be long enough so that they are not easily guessed. This is the same as looking after your ATM CARD and its PIN. If someone manages to get hold of your card then the only thing that prevents him or her using it is the PIN (password) protecting it. If someone has your PIN then they can take your money and you cant stop them. Different vendors often use different and sometimes proprietary storage formats for storing keys. For example, Entrust uses the proprietary .epf format, while Verisign, GlobalSign, and Baltimore, to name a few, use the standard .p12 format. A digital certificate consists of three things: 1. A public key. 2. Certificate information. ("Identity" information about the user, such as name, user ID, and so on.) 3. One or more digital signatures. The purpose of the digital signature on a certificate is to state that the certificate information has been attested to by some other person or entity. The digital signature does not attest to the authenticity of the certificate as a whole; it vouches only that the signed identity information goes along with, or is bound to, the public key. Thus, a certificate is basically a public key with one or two forms of ID attached, plus a hearty stamp of approval from some other trusted individual. Public Key Infrastructure (PKI) The term public key infrastructure (PKI) is used to describe the policies, standards, and software that regulate or manipulate certificates and public and private keys. In practice, PKI refers to a system of digital certificates, certification authorities (CA), and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction. Standards for PKI are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. This section will help you understand what a PKI is and what services are required to build a PKI.

PKI concepts on Certificates Certificate: A public key certificate is a digitally signed statement used for authentication and secure exchange of information on the networks. The issuer and signer of the certificate is known as a certification authority (CA). Certificate has No, Validity, Uses of the Key pair (Public & Secret) Certification Authority: A certification authority (CA) is an entity trusted to issue certificates to a requesting entity. A CA verifies the requester's information according to the policy of the CA, and then uses its private key to apply its digital signature to the certificate. CA Policy: A CA issues certificates to requesters based on a set of established criteria. The set of criteria that a CA uses when processing certificate requests is referred to as CA policy. Typically, a CA publishes its policy in a document known as a Certification Practice Statement (CPS). Types of Certification Authorities Self-signed CA: The public key in the certificate and the key used to verify the certificate are the same Subordinate CA: The public key in certificate and the key used to verify the certificates are different. Rooted CA: This is trusted unconditionally by a client and is at top of a certification hierarchy. Registration: Registration is the process by which a certificate is issued to the subject, provided that the certificate is in compliance with the criteria established by the CA policy. Certificate enrollment: The procedure that an end entity follows to request and receive a certificate from a CA. The certificate request provides identity information to the CA. Certificate Revocation: Certificates have a specified lifetime, but CAs can reduce this lifetime by the process known as certificate revocation. The Ca publishes a certificate revocation list (CRL) that lists serial numbers of certificates that it considers no longer usable. Certificate Chain Validation: In a network, when we generate a request for a new certificate, the information in that request is first passed from the requesting program to Certificate Authority (CA) then passes the appropriate data to a program known as a cryptographic service provider (CSP) A CSP is an independent software module that performs cryptography operations, such as secret-key exchange, digital signing of data, and public-key authentication. Chain-building mechanism attempts to build a certification path (a certificate chain) from the end-entity certificate, such as a user certificate, up to a CA root certificate. Attacking Cryptography Cryptanalysis Cryptanalysis is the process of attempting to discover the plaintext and/ or the key. The types of Cryptanalysis attacks are Differential Cryptanalysis Attack: The differential cryptanalysis attack looks specifically at pairs of cipher texts whose plaintext has some specific differences. It analyzes these differences as the plaintext propagates through various rounds of Data Encryption Standards (DES) when they are encrypted with the same key. Linear Cryptanalysis Attack:

Linear Cryptanalys is attack was invented by Mitsuru Matsui in 1993. This method is based on the concept that if you XOR some of the plaintext bits together, XOR some cipher text bits together, and then XOR the results, you will get a single bit that is the XOR of some of the key bits. A large number of such plain/cipher texts pairs are used to guess the values of the key bits Brute Force Attack The simplest attack to decipher a DES key is the brute force attack. The brute force attack on the DES algorithm is feasible because of the relatively small key length (56 bit) and ever-increasing computational power of the computers. It can break through any cipher by trying all keys that possibly exist. However, in brute force attacks, the time taken to break a cipher is directly proportional to the length of the key. In a brute force attack, keys are randomly generated and applied to the cipher text until the legitimate key is generated. The Average Time Required for Exhaustive Key Search

14. SMART CARD A smart card resembles a credit card in size and shape, but inside it is completely different. First of all, it has an inside -- a normal credit card is a simple piece of plastic. The inside of a smart card usually contains an embedded microprocessor. The microprocessor is under a gold contact pad on one side of the card. Smart cards are much more popular in Europe than in the United States. In Europe, the health insurance and banking industries use smart cards extensively. Every German citizen has a smart card for health insurance. Even though smart cards have been around in their modern form for at least a decade, they are just starting to take off in the United States. The microprocessor on the smart card is there for security. The host computer and card reader actually "talk" to the microprocessor. The microprocessor enforces access to the data on the card. If the host computer read and wrote the smart card's random access memory (RAM), it would be no different than a diskette. Smarts cards may have up to 8 kilobytes of RAM, 346 kilobytes of ROM, 256 kilobytes of programmable ROM, and a 16-bit microprocessor. The smart card uses a serial interface and receives its power from external sources like a card reader The most common smart card applications are:

Credit cards Electronic cash Computer security systems Wireless communication Loyalty systems (like frequent flyer points) Banking Satellite TV Government identification

Smart cards can be used with a smart-card reader attachment to a personal computer to authenticate a user. Web browsers also can use smart card technology to supplement Secure Sockets Layer (SSL) for improved security of Internet transactions. SMART CARD AND PKI The employer or the end entity just applies to the CA or RA to get a certificate. By signed with the CA's private key, all which trust the CA, can also trust the end entity. Your digital ID is ready.You can just write your digital ID and private key to your smart card. Or a better way, new smart cards are deployed with embedded functions that generate public and private keys inside the card which means your private key is not exported to anywhere. New deployed cards are capable of PKI functions which you do not need to export the private key to the application you use. For example when you want to send a signed mail, your mail applications first generates a hash of the document you just wrote and starts the communication with the card. Your application sends the hash value to the card which is than signed with your private key inside the card. By this way your private key is never exported to the public, your computer. Also, while accessing your remote shell account you could use ssh, secure shell, client. In main page of OpenSSH, an authentication method for ssh protocol 2 is described. Main purpose of the method is true

identification of the person trying to access the account and secure connection between the host, if the user is accepted. Theoretically, only you can know your private key. Although your private key is only readable by yourself, this could be a security risk. But if your private key is inside a smart card, this is an increased security. Of course, a smart card can get lost. But at this point another security subject is on the line, your PIN. Generally speaking, smart card's security comes from two things, one you know and one you own. SSH is not the only application that smart cards can be used. Other applications like, money transactions on the net, identification of yourself to the website you connect can be done with smart cards. The system is more or less the same. Your identification is checked via your private key and secure session is started with your keys. Than application specific part comes which is designed and deployed by the service provider of the application. Some money transactions are just done inside the smart card but some applications just ask the card for your banking account number. There could be more methods. Electronic locks that can communicate with a smart card can be found on the market. PKI can support, in addition to the mutual authentication between the card and the reader, access accounting in the building. Just mutual authentication can be used or the lock ask to a local server that keeps the user data and checks if the user is permitted to go behind the door. And whether the permission is granted or not the server keeps the tracks of the access trials. With integration of smart cards into PKI world, many more applications could be built. These application are mostly security specific or to ease the life of the customers. About Certificate Paths Public Key Infrastructure (PKI) supports a number of security-related services, including data confidentiality, data integrity, and end-entity authentication. Fundamentally, these services are based on the proper use of public/private key pairs. The public component of this key pair is issued in the form of a public key certificate and, in association with the appropriate algorithm(s), it may be used to verify a digital signature, encrypt data, or both1. Before a certificate can be used, it must be validated. In order to validate such a certificate, a chain of certificates or a certification path between the certificate and an established point of trust must be established, and every certificate within that path must be checked. This process is referred to as certification path processing. In general, certification path processing consists of two phases: 1) path construction and 2) path validation described as follows: 1) Path construction involves "building" one or more candidate certification paths. Note that we use "candidate" here to indicate that although the certificates may chain together properly, the path itself may not be valid for other reasons such as path length, name, or certificate policy constraints/restrictions. 2) Path validation includes making sure that each certificate in the path is within its established validity period, has not been revoked, has integrity, et cetera; and any constraints levied on part or all of the certification path are honored (e.g., path length constraints, name constraints, policy constraints). However, some aspects that might be associated with path validation are sometimes taken into

consideration during the path construction process in order to maximize the chances of finding an acceptable certification path sooner rather than later. Basic Concepts Certificates are issued by Certification Authorities (CAs) to other CAs or to end-entities (e.g., endusers,devices, Web servers, processes). CAs may also "self-issue" certificates to themselves .Certificates issued to CAs are known as CA certificates, and certificates issued to end-entities are referred to as end-entity certificates. The Basic Constraints certificate extension is used todistinguish between CA certificates and end-entity certificates.



The Internet, Intranets, Extranets and wireless networks are re-defining how companies communicate and do business. As the value of business relationships and transactions increase, so do the associated risks and security requirements. By protecting the security of online payments, businesses can reduce risk and reach a larger market. SSL security is a standard and a minimum requirement for those that conduct transactions online. Almost all legitimate and trustworthy businesses use SSL security with digital certificates to secure their Web site. Public-key is a very appealing and exciting technology, embedding both encryption and digital signature. This constitutes a breakthrough over symmetric-key cryptosystems. Beyond the mechanics, there is a need for an infrastructure, a PKI, which includes the tools to effectively manage and use keys and certificates. Finally, beyond the infrastructure, there is a need for preparing, documenting and maintaining the infrastructure. From a technical point of view, implementing a PKI is a matter of days. From a business point of view, implementing a PKI is really another story.



Cryptography and Network Security By William Stallings. Cryptography And Network Security By Atul Kahate