A REPORT ON DEVELOPMENT OF WEB APPLICATIONS FOR BHABHA ATOMIC RESEARCH CENTRE BY Pratham Karkare Adityavikram Hirani Himavanth Jasti

2008A3PS165P 2008A8PS286P 2008A8PS291P

AT CMC Limited, Mumbai

A Practice School-II Station of BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE ,PILANI (December 2011)

A REPORT ON DEVELOPMENT OF WEB APPLICATIONS FOR BHABHA ATOMIC RESEARCH CENTRE BY

Pratham Karkare 2008A3PS165P BE (Hons.)Electrical and Electronics Adityavikram Hirani 2008A8PS286P BE(Hons.) Electronics and Instrumentation Himavanth Jasti 2008A8PS291P BE(Hons.) Electronics and Instrumentation

Prepared in partial fulfillment of the Practice School Course No. BITSC412/BITSC413/BITSG639 AT CMC Limited, Mumbai

A Practice School-II Station of BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE ,PILANI (December 2011)

ACKNOWLEDGEMENTS
We would like to acknowledge the support of our Project Manager , Mrs. Nayana Vaidya , who guided us throughout the duration of the project and also for proof reading the report. We would like to thank our PS Faculty Mr . P. Vijay Bhasker Reddy for regularly keeping an update on our work and for providing us with the necessary documents required for completing the mid semester report . We would also like to acknowledge the guidance provided by Mr. R . Mahesh who guided us during our research on Public Key Infrastructure .We would also like to thank all the employees of CMC Ltd. For providing us with all the technical help needed for completing the project . We are also grateful to Mr.Bhagwan Das for mentoring and guiding us while the development of the project . We would like to thank Mr.Gurmeet Singh, Mr JJ Kulkarni and Mr.Deodhar of the Bhabha Atomic Research Centre for giving us the opportunity to visit BARC and understand the PKI implemented there.

Abstract Sheet Birla Institute of Technology and Science Pilani (Rajasthan)

Practice School Division
Station: CMC Ltd . Centre: Mumbai Duration : From 4-06-2011 to 14-12-2011 Date of Submission :12-12-2011 Title of the project Development of web applications for Bhabha Atomic Research Centre 2008A3PS165P 2008A8PS286P 2008A8PS291P Pratham Karkare Adityavikram Hirani Himavanth Jasti

Name of expert: Mr. Bhagwan Das Designation : Senior IT Engineer Name of PS Faulty- P. Vijay Bhasker Reddy Keywords PKI , BARC , Security, Shell scripting , SpringRoo , JAVA ,JDBC Project Area(s)- Computer Science/Cryptography

Abstract -This project of BARC undertaken by CMC involves developing web based applications for the Account Management system.This project is currently being developed at the CMC office at World Trade Centre,Cuffe Parade,Mumbai under the supervision of Mrs.Nayana Vaidya. The work includes shell scripting in Spring Roo for the development of the web pages . The PKI part of the project includes understanding of the existing PKI project at BARC and application of the same in the project being developed here. The entire project is to be developed using open source softwares.

Tables of Contents 1. Introduction 1.1 About the Company 1.2 About the Project WebPage Develpoement Using Spring Roo 2.1 Open Source Software Used 2.1.1 Spring Source 2.1.2 Spring Roo 2.1.3 PostGRE SQL 2.2 Steps Involved in Development 2.2.1 Shell Scripting 2.2.2 Creating the project by Running Scripts 2.2.3 Building and Running Project What is PKI? 3.1 How Public and Private Key Cryptography Works 3.2 Who Provides the Infrastructure? 3.3 Pretty Good Privacy 3.4 The PKI certificate (Digital Certificate) 3.5 Controlling Key Usage 3.6 PKI methods for storing Public Keys and Private Keys Application of PKI in the project SSL and TLS Protocols OpenSSL 6.1 Generating a Certificate 6.2 Key Generation Application provided by BARC 7.1 PKI Module Integration 7.2 RPGServer 7.3 RPGPKIAdmin 7.4 RPGWeb and RPGApplet Functionality of the Project Test Spring Source Project Conclusion 6 6

2.

7 7 8 8 9 10 12 12 13 14 15 15 15 17 17 18 19 20 20 23 23 24 25 26 28 30

3.

4. 5. 6.

7.

8. 9. 10.

Appendix A. TLS Handshake Appendix B. Certification Authority (CA) References.

1.

INTRODUCTION

1.1 About the company CMC Limited is a leading systems engineering and integration company in India, offering application design, development, testing services and asset-based solutions in niche segments through turnkey projects of national importance. A subsidiary of Tata Consultancy Services Limited (TCS Ltd), one of the world's leading information technology consulting, services and business process outsourcing organizations. CMC Limited is an end-to-end IT solutions provider with capabilities straddling the entire information technology spectrum: IT architecture; hardware; software (including systems and application software, development or implementation, maintenance, and frameworks); network consulting; and IT-enabled processing services . CMC was incorporated on December 26, 1975, as the 'Computer Maintenance Corporation Private Limited'. The Government of India held 100 per cent of the equity share capital. On August 19, 1977, it was converted into a public limited company. It was subsequently bought by the TATAs. Guiding CMC's quest for excellence and global expansion is its eminent board of directors, headed by Chairman, Mr S Ramadorai. Its Managing Director, Mr R Ramanan, who is also the Chief Executive Officer, directs CMCs day-to-day operations. CMC has around 7,396 employees. Some of CMCs clients include Bombay Stock Exchange , National Stock Exchange , Bhabha Atomic Research Centre , Indian Railways , Indian Air Force , Parle , PepsiCo. Etc.

1.2 About the Project

Bhabha Atomic Research centre situated in Mumbai has given a project to develop web based applications for their Account Management System(AMS). The beauty of the project is that it has to be completely developed by using open source software only. The system is required to be customized to BARCs requirements and has to be installed at BARCs place. The entire project involves individually developing the above 9 modules and then integrating them together to form one complete web application. The MMS module involved the development of the following scripts : Master Script Disposal Script Inventory Script Purchase Script Payment Script Also the matter of security of transactions and events constitutes a vital part of this project and it is recommended by the computer division of BARC to use PKI technology for the same purpose. This division states to provide JAVA classes for various processes in Cryptography and it would be our job to link them together.

2. WEB PAGE DEVELOPMENT USING SPRING ROO 2.1 Open Source Softwares Used 2.1.1 SpringSource
SpringSource provides an application framework in the Java space called Spring. It offers commercial support subscriptions and added value software for the Spring Framework and many other products in the Spring Portfolio.

The Spring Framework and related products are used by a majority of all enterprise Java developers. Companies like JP Morgan, HSBC, Orbitz, Accenture, and Cap Gemini all use Spring to build highly scalable and mission-critical systems.

During the course of the project done so far , Spring Source is used as the main JAVA Development Platform for writing the codes , compiling them , running them and seeing the generated output . Spring Source has an in built sever which is used for hosting web pages when they are created using Spring Source Tool Suite. Spring Source Tool Suite forms the heart and soul of the BARC project undertaken by CMC Ltd.

The main functions of Spring Source includes:

Use the Spring Framework to develop Java applications Test JAVA-based applications Set up Spring configuration using XML, annotations, and Java configuration Use Hibernate and JDBC with Spring to access relational databases

2.1.2 Spring Roo

Spring Roo is a next-generation rapid application development tool for Java developers. With Roo you can easily build full Java applications in minutes. Spring Roo is the main tool which is being used by CMC Ltd. for developing JAVA based web pages . Roo is a lightweight console shell that loads up while developing the projects .It eliminates the need of defining the JAVA classes and writing the entire codes in an IDE .

The main methodology used by Spring Roo includes writing the codes in a Spring Roo Shell. These shells are later developed into web pages containing the JAVA classes ,when the project is build using Spring Source Suite . The JAVA classes get automatically built and the user can later modified the JAVA classes by editing the source code according to his needs.

As the user goes about editing code in a normal way, Roo keeps an eye on your project files and automatically modifies them in response to your actions. Depending on the Roo add-ons you

have running, Roo can help you with different types of files.

Fig. 1 Spring Source suite snapshot

2.1.3 PostGRE SQL

PostGRE SQL is a powerful, open source object-relational database system. The source code is available to all at no charge and runs on almost all the operating systems. Postgre SQL has the advantage that it can be easily connected to various Open Source and proprietary based softwares and tools . With PostGRE SQL, no-one can sue you for breaking licensing agreements, as there is no associated licensing cost for the software. There are many procedure languages supported by PostgreSQL, there are also many library interfaces as well, allowing various languages both compiled and interpreted to interface with PostgreSQL. There are interfaces for Java (JDBC), ODBC, Perl, Python, Ruby, C, C++ etc . An easy to use data management system , PostGRE SQL is the preferred SQL for developing this project.

2.2 Steps involved in developing the project 2.2.1 Shell Scripting

The first step involved in developing the required web pages containing the JAVA classes is Scripting. This includes writing the commands in a Roo shell . For the project, the allotted module was the Material Management System (MMS) module . For the MMS modules , scripting for the following was to be done : 1.Master Script 2.Purchase Script 3.Payment Script 4.Disposal Script 5.Inventory Script Spring Roo's main user interface is a command-line shell. The shell provides both a command-line interface and also a mechanism to host plug-ins . The following is an example of the shell roo scripting that was done as a part of the project :

Fig. 2 Writing Scripts to be run in roo shell

In the above figure , the script when run creates a JAVA class named itemCategory and creates web page having field names as mentioned and connects it to the database used.

2.2.2 Creating the Project and Running the Scripts The next step involves the creation of Roo project in the Spring Source Tool Suite and running the scripts which had been previously written. Upon running the scripts , Spring Roo writes the JAVA code corresponding to the various classes which mentioned in the script . The scripts are run using the following command which builds the Roo project . Roo> persistence setup provider HIBERNATE database PostGRES Here ,Hibernate is the object-relational mapping (ORM)-provider. Hibernate is one of three ORM

providers which Roo currently offers. The command also connects Spring Source with the database, in this case PostGRES.

Fig. 3 Running the Masters Script

2.2.3 Building and Running the Project The next step involves building the project and then running it on a server using the internal server provided by the Spring Suite Tool . The step converts the Java Classes into web pages , containing the required fields . Each of these web pages is connected to the database and whatever data is entered into the web page gets stored in the database and can be subsequently viewed.

Fig. 4 Web page developed by Roo Framework

Fig .5 Web Page with the data entry stored

3. What is PKI?
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 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

3.1 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 Send an encrypted message Send an encrypted signature Decrypt an encrypted message Decrypt an encrypted signature

Use whose Use the receiver's Use the sender's Use the receiver's Use the sender's

Kind of key Public key ate key Private key Public key

3.2 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

3.3 Pretty Good Privacy

For e-mail, the Pretty Good Privacy (PGP) product lets you encrypt a message to anyone who has a public key. You encrypt it with their public key and they then decrypt it with their private key. PGP users share a directory of public keys that is called a key ring. (If you are sending a message to someone that doesn't have access to the key ring, you can't send them an encrypted message.) As another option, PGP lets you "sign" your note with a digital signature using your private key. The recipient can then get your public key (if they get access to the key ring) and decrypt your signature to see whether it was really you who sent the message. a) The Public Key used for Encryption Another person uses your public encryption key when they want to send you confidential information. The information to be sent is encrypted using your public key*. You can provide your public key to the sender, or it can be retrieved from the directory in which it is published. In normal practice, the actual information being sent is encrypted using a secret key algorithm (symmetric cryptography). Symmetric algorithms are much faster than public/private key algorithms (asymmetric cryptography). A random key (the session key) is generated, and it is used with the symmetric algorithm to encrypt the information. The public key is then used to encrypt that key and both are sent to the recipient.

b) The Private Key used for Decryption A private key is used to decrypt information that has been encrypted using its corresponding public key. The person using the private key can be certain that the information it is able to decrypt must have been intended for them, but they cannot be certain who the information is from. Note: In normal practice the private key is used to decrypt the session key, and that key is used to decrypt the actual information rather than the private key decrypting all the information.

c) The Private Key for Signature If the sender wishes to prove to a recipient that they are the source of the information (perhaps they accept legal responsibility for it) they use a private key to digitally sign a message (a digital signature). Unlike the handwritten signature, this digital signature is different every time it is made. A unique mathematical value, determined by the content of the message, is calculated using a 'hashing' or 'message authentication' algorithm, and then this value is encrypted with the private key - creating the digital signature for this specific message. The encrypted value is either attached to the end of the message or is sent as a separate file together with the message. The public key corresponding to this private key may also be sent with the message, either on its own or as part of a certificate.

Note: Anyone receiving information protected simply by a digital signature can check the signature and can read and process the information. Adding a digital signature to information does not provide confidentiality.

d) The Public Key for Signature The receiver of a digitally signed message uses the correct public key to verify the signature by performing the following steps. A non-technical example is given after these steps. 1. The correct public key is used to decrypt the hash value that the sender calculated for the information 2. Using the hashing algorithm (where certificates are in use it will be stated in the public key certificate sent with the message), the hash of the information received is calculated 3. The newly calculated hash value is compared to the hash value that the sender originally calculated. This was found in step 1 above. If the values match, the receiver knows that the person controlling the private key corresponding to the public key sent the information. They also know that the information has not been altered since it was signed 4. If a public key certificate was sent with the information it is then validated with the CA that issued the certificate to ensure that the certificate has not been falsified and therefore the identity of the controller of the private key is genuine 5. Finally, if one is available, the revocation list for the CA is checked to ensure that the certificate has not been revoked, or if it has been revoked, what the date and time of revocation were. e) Signing the Hash Function A hash function H is a transformation that takes a variable-size input m and returns a fixed-size string, which is called the hash value h (that is, h = H(m)). Hash functions with just this property have a variety of general computational uses, but when employed in cryptography the hash functions are usually chosen to have some additional properties. The hash value represents concisely the longer message or document from which it was computed; one can think of a message digest as a "digital fingerprint" of the larger document. Examples of well-known hash functions are MD2 and MD5 and SHA. Perhaps the main role of a cryptographic hash function is in the provision of digital signatures. Since hash functions are generally faster than digital signature algorithms, it is typical to compute the digital signature to some document by computing the signature on the document's hash value, which is small compared to the document itself. Additionally, a digest can be made public without revealing the contents of the document from which it is derived. This is important in digital timestamping where, using hash functions, one can get a document timestamped without revealing its contents to the timestamping service.

3.4

The PKI certificate (Digital Certificate)

In the section on public and private keys, references were made to certificates. A certificate is information referring to a public key, that has been digitally signed by a Certification Authority (CA). The information normally found in a certificate conforms to the ITU (IETF) standard X.509 v3. Certificates conforming to that standard include information about the published identity of the owner of the corresponding private key, the key length, the algorithm used, and associated

hashing algorithm, dates of validity of the certificate and the actions the key can be used for. A certificate is not essential to operating a PKI, however, some scheme is necessary to locate information about the controller of a private key, and the X.509 certificate is the most commonly implemented scheme.

3.5 Controlling Key Usage

One of the fields in a public key certificate (certificate) is the key usage field. It is used by the CA to state the uses the CA has approved. It does not mean that the corresponding private key cannot be used in any other ways. There is no certificate with a private key. People receiving information protected using a public key system should check, where a certificate is provided, that the key usage stated in the certificate corresponds to the actual use.

3.6 PKI methods for storing Public Keys and Private Keys
a) Digital 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. b) 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 can't 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. signs (stamps) the certificate to prevent modification of the details contained in the certificate.

4. Application of PKI in the Project.

As a part of the project,cryptography and security of the transactions is vital and the computer division at BARC in its document breifly explaining their needs,has cited the use of PKI. We took this opportunity to look into Internet Cryptography and with the help of the senior officials at CMC were set up on a guideline for the next few weeks.We were suggested the use of OpenSSL which is again an open source toolkit acting as an excellent platform providing hands on experience in cryptography. The document from the Computer Division of BARC states that the classes for almost all of the above mentioned processes would be provided and then,as we perceive it,we would be required to merge the above mentioned into an outer class which would be doing the transaction and thus implementing cryptography.

Having made the project requirement clear,the course of action before visiting BARC has been set to create a set of classes separately and then merging them into an example of a bank transaction which would prove to be our POC. Below are some classes and their outcomes:-

1.A private key generated by DSA algorithm

2.Creation of Symmetric Keys

3.Simulation of a Bank Transaction

5. SSL and TLS PROTOCOLS

The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security. The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported CipherSuites (ciphers and hash functions). From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision. The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key. The client may contact the server that issued the certificate (the trusted CA as above) and confirm the validity of the certificate before proceeding. In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key. From the random number, both parties generate key material for encryption and decryption. This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes. If any one of the above steps fails, the TLS handshake fails and the connection is not created.

6. OpenSSL
OpenSSL is an open source implementation of the SSL and TLS protocols. The core library implements the basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. Versions are available for most Unix-like operating systems, OpenVMS and Microsoft Windows. IBM provides a port for the System i (OS/400). OpenSSL is based on SSLeay by Eric A. Young and Tim Hudson, development of which unofficially ended around December 1998, when Young and Hudson both started to work for RSA Security.

6.1 Generating a Certificate:

We can generate self signed certificates in OpenSSL using the following command. OpenSSL> req -new -x509 -key key1.pem -out cert.crt -days 365

Generating a certificate.

2. Key Generation:
In OpenSSL, asymmetric keys can be generated using different algorithms like RSA and DSA.

Generating Key using RSA algorithm:

The following command is used to generate the private key OpenSSL> genrsa -out key1 204 Private Key Generated. To generate the corresponding Private Key OpenSSL> rsa -inkey key1 -outpubkey1 -pubout -outform PEM

7.

Application provided by BARC:

As a part of the project, cryptography and security of the transactions is vital and the computer division at BARC in its document briefly explaining their needs, as cited the use of PKI. The document from the Computer Division of BARC states that the classes for almost all of the above mentioned processes would be provided and then,as we perceive it, we would be required to merge the below mentioned project into the aaiis and mms project .

7.1 PKI Module Integration

Utilities required: 1.Crypto-tokens (SafeNet ikey2032) , obtained from BARC 2.Existing JAVA based PKI projects, implemented at BARC 3.Policy Client from BARC and iKey Safenet driver Softwares Used : 1.Netbeans IDE 2.POSTGRESQL 3.Spring Source Using The Crypto Token: Crypto Token is a pen-drive like device which is used in generation and storing of the security key. Before using the crypto token, the necessary drivers and the policy client needs to be installed. The iKey Safenet drivers are obtained from SafeNet website and the Policy client is obtained from BARC. Initializing the crypto token: The first step while using the token is initializing it. This removes all the existing keys and

certificates that are present in the crypto token and makes it ready for fresh use. For Initialization: 1. Open SafeNet Token Utilities. 2. Go to the token option in the top-left corner, select Initialize token and press OK. The PIN of the token is automatically saved as Password#1 after initialization.

There are 5 Java projects that have been provided by BARC 1.RPGPKIServer 2.RPGPKIAdmin 3.RPGTest 4.RPGWeb 5.RPGApplet

7.2 RPGServer:
By running the RPGServer we establish the connection with PostGRE SQL database. This is called the PKI SERVER. It contains DBConnection.java and PKIServlet.java DBConnection.java : It contains the specifications of the database to which the server is to be connected. The specifications include the name of the schema, defined user and the password of the selected database. To change the server and connect it to another database the getconnection() method in this file has to be edited and the .jar file of the specified database has to be added to the library of the project. PKIServlet.java : It contains all the queries of the methods defined in RPGPKIAdmin. The queries have been made by following PostGRE structure. This is a servlet type java file and takes the inputs given by keyboard and helps in storing them to the specified table in the database. If the database is to be changed, the queries have to be changed according to the specifies DBs syntax. The syntax for PostGRE DB have been taken from the internet.

7.3 RPGPKIAdmin:
The RPGPKIAdmin project is run to access the crypto token and register, update certificates of the defined users. Methods defined as Admin Tasks are: 1. Generate Keypair 2. View Token Certificate 3. Register Employee 4. Update Certificate 5. Get List of Employee 6. View Certificate by EmpNo 7. View Certificate by CertSno Generate Keypair : This method generates an asymmetric keypair and stores them in the crypto token that has been inserted. It generates the Keypair using the RSA Algorithm. These RSA Algorithm methods are

defined in the Java made class file named RSATool.java. The public key in the asymmetric key is derived from the private key generated. As the system being followed by BARC is not approved by any Certifying Authority (CA), the certificate of the generated keypair is also made by including the information of the employee and its expiry date. View Token Certificate: This method helps in viewing the present certificate in the crypto token. The method makes connection with the inserted crypto token, and displays the certificate of the owner of the crypto token.

Register Employee: All the employees who have crytpo tokens have to be first registered to the emp_cert table of the database. The employee name and number are added in the database and all the other fields like Certificate, CertSno, Date of expiry, etc. are left null in the initial stage. The Administrator of the PKI Server has to register the employees before giving them their crypto tokens. After registering he generates the keypair for the given employee and his certificate is generated.

Update Certificate: After Registering the Employee, his certificate is to be stored in the database for reference. This is done by the Update Certificate button of PKI Admin. It asks for your Emp.no and then updates the certificate present in your crypto token as the present certificate in the table emp_cert .The previous certificate is transferred to an other database old_cert and stored there with the serial number so that it can be viewed when required. This is done because the certificate of an old key can be used in the future for verification even after the certificate has been expired. The main reference with which these archived certificates can be viewed is the certificate Serial Number which is unique for all the certificates. The Serial Numbers are matched with the Employee Number of the Token Holder so that there is no mismatch.

Get List of Employee: This Button displays all the employees that have been registered in the PKI Server. The details that are displayed about the registered employees are Employee name, Employee Number, Certificate Serial Number and the Certificate. View Certificate by Employee Number and Cert Sno: These buttons Download the specified certificate from the database using EmployeeNo and CertSno respectively. The certificates viewed by using EmpNo are the current certificates being

used by the employee. By using CertSno we can view both present and archived certificates. When we run the PKI Admin, a Java Applet is created. All the functions that are called in the applet are defined in the PKIServlet.java file present in the source package of the PKI Server project. The queries in all these methods have been changed as per PostGRE SQL instead of MySQL. The .jar file of PostGRE was added too. These changes have already been mentioned.

7.4 RPGWeb and RPGApplet:

By running the RPGWeb project, it internally calls the applet that is defined in the source package of RPGApplet. The Applet has a variety of buttons like SignData, VerifyData, SignverifyFile, EncryptData, DecryptData, etc. These are included in the applet as buttons and the Employee Number of the user is taken as input before signing and verification. All the methods that are called using these buttons are defined using the Action Listener Methods of JAVA. The classes and methods that are used in these methods are defined in the RPGLib.jar folder. The most frequently used files are RSATool, SignResult, VerifyResult, DESTool, etc.

How to sign the jar of RPGApplet and add It to RPGWeb:

1. Open Command Prompt. 2. Generate a Key to sign the applet jar. keytool -genkey -keyalg rsa -validity 730 -alias RPGAppletKey pass cmc@12345 name PKI Module org Unit - SI org - CMC Ltd. City - Mumbai state - Maharashtra CN IN 3. Save the certificate of the generated key in to a file. keytool -export -alias RPGAppletKey -file RPGAppletKey.crt 4. Install the above certificate on client m/c's browser. 5. Sign the jar file every time when PKIApplet is updated. jarsigner -storepass cmc@12345 E:\dist\RPGApplet.jar RPGAppletKey The jar file can be found in C:\Documents and Settings\SYSADMIN\Documents\workspace-sts2.6.1.RELEASE\SamplePKI\dist. 6. The signed jar file is to be copied in to the Webpages\applets folder of RPGWeb project.

8. Functionality of the Project:

After making all the changes mentioned above, these are the steps to run the project. For CryptoToken: Insert the crypto token. Open SafeNet Token Utilities from the programs in start menu. Initialize the token using the Option in Token Utilities. Run the PKIServer project to start the PKI Server i.e. the connection to the database. Run the RPGPKIAdmin project which open a java Applet which has the methods defined.

Use Generate Key and other methods to generate and store the key in Crypto token, and Register Employee and Update Certificate to store the certificate in the database. For Sign-verify and Encrypt-Decrypt: For running the project, run the RPG server first. Then run RPG web. This will open a java applet which will have a text field and various buttons corresponding to various applications. Give the employee ID in the text field and then you can sign or verify. There are two methods viz. signVerifyData and signVerifyFile. To sign the data the method uses getBytes method on a field of database to convert the string into array of bytes and it is fed into the class. To sign a file the method has the path of the file given within the code. This path can be changed as per the file to be signed. The encryption decryption works the same way as the signVerifyFile. The path of the file to be encrypted is given to a function in the code and the path of the encrypted file is given in the decrypt function.

9. TEST SPRING SOURCE PROJECT

A test application for the implementation of PKI has been developed which uses spring application and an applet in front end for the processes of Digital signing and verification. To grant the permission the Java runtime environment which the java console uses is important as the changes need to be made in the former's policies only,which are of course saved. 1. Conversion of Netbeans project into the Maven Project

After making the Netbeans IDE project provided by BARC fully functional , a new Maven project was created called pki . An applet called HelloApplet was created ,which contained the SignVerify applet of the project . This project was then exported into the applets of Maven project pki. 2. Running the pki project If signing and verification have to be performed ,then PKIServer has to be run because while signing and verifying database is accessed. Presently , Hypersonic database is being used . It has to be changed to POSTGRE sql . This can be done by making changes in the databaseproperties file in the pki project. 3. Functioning of the pkiproject Upon running the project, a graphic user interface appears , where user enters his employee number, employee name and date of birth. On clicking on the Next button, the data entered by him is redisplayed . Clicking on the Next button ,takes him to a page where he has the option of Digital Signature and Digital Verification On clicking on the Digital Signature ,the data entered by the user gets signed. The parameters stay on the browser .

10. CONCLUSION:
As a part of the PS2, we worked with the team responsible for developing web applications for BARC. During the initial phase of the project, shellscripting was done for creating web pages using Spring Roo.These web pages will be further integrated into the main project where interlinking of different modules will be done. As the project progressed , we worked on an independent project based on the implementation of PKI for approval and dissapproval during transactions .As a part of the PKI project sufficient research was done for the PKI implementation and success was obtained in encrypting, decrypting files and generating certificates using the OpenSSL tool. Two visits were made to BARC to understand the client requirements and study the project which was impelmented there . Non-fucntional PKI based JAVA projects and crypto-tokens were obtained from BARC and succesfully developed into a functioning project which performs the function of signing and verification . This project was in Netbeans and was converted into a Maven project ,consistent with the project being developed by CMC . The project was then handed over to other employees of CMC through a systematic procedure .

APPENDIX A TLS HANDSHAKE TLS handshake in detail

The TLS protocol exchanges records, which encapsulate the data to be exchanged. Each record can be compressed, padded, appended with a message authentication code (MAC), or encrypted, all depending on the state of the connection. Each record has a content type field that specifies the record, a length field and a TLS version field. When the connection starts, the record encapsulates another protocol the handshake messaging protocol . Simple TLS handshake A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate: 1. Negotiation phase: A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID. The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1 should be selected; SSL 3.0 should not be selected. The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server). The server sends a ServerHelloDone message, indicating it is done with handshake negotiation. The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate. The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudo random function. 2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20. Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages. The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down. 3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you

from now on will be authenticated (and encrypted, if encryption was negotiated)." The server sends its authenticated and encrypted Finished message. The client performs the same decryption and verification. 4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate. Thus, a secure connection is established between client and server to transfer secure data.

APPENDIX B Certification Authority (CA) 4.1 Certification authority (CA)

A CA issues and verifies certificates (see above). The CA takes responsibility for identifying (to a stated extent) the correctness of the identity of the person asking for a certificate to be issued, and ensures that the information contained within the certificate is correct and digitally signs it. a) Generating key pairs The CA may generate a public key and a private key (a key pair) or the person applying for a certificate may have to generate their own key pair and send a signed request containing their public key to the CA for validation. The person applying for a certificate may prefer to generate their own key pair so as to ensure that the private key never leaves their control and as a result is less likely to be available to anyone else. b) Issuing digital certificates Unless you generate your own certificate (some applications software will enable you do this) you will generally have to purchase one from a CA. Before a CA issues you with a certificate they will make various checks to prove that you are who you say you are. The CA could be thought of as the PKI equivalent of a passport agency - the CA issues you a certificate after you provide the credentials they require to confirm your identity, and then the CA signs (stamps) the certificate to prevent modification of the details contained in the certificate. A CA may also state the quality of the checks that were carried out before the certificate was issued. Different classes of certificate can be purchased that correspond to the level of checks made. There are three or four general classes of certificate: Class 1 certificates can be easily acquired by supplying an email address, Class 2 certificates require additional personal information to be supplied, and Class 3 certificates can only be purchased after checks have been made as to the requestors identity. A 4th class may be used by governments and organizations needing very high levels of checking. c) Using certificates An individual may have any number of certificates issued by any number of CAs. Different Web applications may insist that you use certificates issued only by certain CAs. For example, a bank may insist that you use a certificate issued by them in order to use their services, whereas a public Web site may accept any certificate you offer (just as some allow free choice of ID and password). The CA can be a unit within your organization, a company (i.e. a bank or a post office), or an

independent entity (VeriSign). d) Verifying certificates The public key certificate is signed by the CA to prevent its modification or falsification. This signature is also used when checking that the public key is still valid. The signature is validated against a list of 'Root CAs' contained within various 'PKI aware' applications (e.g. your browser). Some CA certificates are called 'Root Certificates' as they form the root of all certificate validation. Certificate validation occurs automatically using the appropriate public certificate contained within the root CA list.

REFERENCES
1.www.springsource.com/Documentation 2.www.openssl.org 3.www.madboa.com/geek/openssl 4.Richard E. Smith, "Internet Cryptography",Pearson Publication,1996 5.B. Schneier, Applied Cryptography, Second Edition (John Wiley & Sons, 1996) 6.D.R. Stinson, Cryptography: Theory and Practice (CRC Press, 1995) 7.www.wikipedia.org