<%BANNER%>

Secure Communication Services for Distributed Conference System


PAGE 1

SECURE COMMUNICA TION SER VICES F OR DISTRIBUTED CONFERENCE SYSTEM By RA VICHANDRAN ARINGUNRAM A THESIS PRESENTED TO THE GRADUA TE SCHOOL OF THE UNIVERSITY OF FLORID A IN P AR TIAL FULFILLMENT OF THE REQUIREMENTS F OR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORID A 2002

PAGE 2

Cop yrigh t 2002 b y Ra vic handran Aringunram

PAGE 3

I dedicate this w ork to m y paren ts, family and friends.

PAGE 4

A CKNO WLEDGMENTS I wish to oer m y highest gratitude to Dr. Ric hard Newman for pro viding me with guidance and motiv ation to complete this thesis. I also thank Dr. Jonathan C.Liu and Dr. Randy Cho w for serving on m y thesis committee. I feel v ery proud to ha v e p eople of suc h stature related to m y thesis w ork. I w ould lik e to express m y sincere thanks to all the DCS group mem b ers. I w ould lik e to thank Vija y Manian and Aparna Kak arparti, with whom I w ork ed closely and shared m y ideas. Last, but not least, I wish to express m y thanks to m y paren ts, family and friends who ha v e alw a ys b een supp ortiv e of me and alw a ys encouraged me in all m y endea v ors. iv

PAGE 5

T ABLE OF CONTENTS page A CKNO WLEDGMENTS . . . . . . . . . . . . . . iv LIST OF FIGURES . . . . . . . . . . . . . . . . viii ABSTRA CT . . . . . . . . . . . . . . . . . . x CHAPTERS 1 INTR ODUCTION . . . . . . . . . . . . . . . 1 1.1 Ov erview of Distributed Conference System . . . . . . 1 1.1.1 Conference Con trol Mo dule . . . . . . . . . 1 1.1.2 Database and Comm unication Mo dule . . . . . . 1 1.1.3 Access Con trol Mo dule . . . . . . . . . . 2 1.1.4 Notifcation Mo dule . . . . . . . . . . . 2 1.1.5 Decision Supp ort Mo dule . . . . . . . . . 2 1.1.6 Secure Comm unication Mo dule . . . . . . . . 2 1.2 Ov erview of Secure Comm unication Services . . . . . . 4 1.3 Defnitions . . . . . . . . . . . . . . . 5 1.4 Organization of Chapters . . . . . . . . . . . 6 2 SUR VEY OF RELA TED W ORK . . . . . . . . . . . 7 2.1 Remote Metho d In v o cation . . . . . . . . . . . 7 2.1.1 RMI Arc hitecture . . . . . . . . . . . 7 2.1.2 La y ers of RMI . . . . . . . . . . . . 9 2.2 Net w ork Securit y . . . . . . . . . . . . . 10 2.2.1 Mo del of Net w ork Securit y . . . . . . . . . 10 2.2.2 Con v en tional Encryption System . . . . . . . 10 2.2.3 Secret-Key Encryption . . . . . . . . . . 11 2.2.4 Public-Key Cryptograph y . . . . . . . . . 12 2.2.5 Public Key Encryption Scenario . . . . . . . 13 2.2.6 Symmetry-k ey vs Public-k ey encryption . . . . . 13 2.2.7 Digital Signature . . . . . . . . . . . 14 2.2.8 Digital Certifcates . . . . . . . . . . . 15 2.3 Summary . . . . . . . . . . . . . . . 16 v

PAGE 6

3 REQUIREMENTS SPECIFICA TION . . . . . . . . . 17 3.1 In tro duction . . . . . . . . . . . . . . . 17 3.2 Securit y Goals . . . . . . . . . . . . . . 17 3.3 Pro cesses within DCS . . . . . . . . . . . . 17 3.3.1 Dynamic Pro cesses . . . . . . . . . . . 18 3.3.2 Nearly Static Pro cesses . . . . . . . . . . 18 3.3.3 Instan tiation and T ermination of Serv ers . . . . . 18 3.3.4 Creation and Destruction of Sessions . . . . . . 18 3.3.5 T ransmission and Reception of Messages . . . . . 19 3.3.6 Creation and Deletion of Sites . . . . . . . . 19 3.3.7 Adding New Administrator to Existing Site . . . . 20 3.3.8 Creation and Deletion of Users . . . . . . . . 21 3.4 Summary . . . . . . . . . . . . . . . 21 4 DESIGN . . . . . . . . . . . . . . . . . . 22 4.1 In tro duction . . . . . . . . . . . . . . . 22 4.2 Design Lev el Choices . . . . . . . . . . . . 22 4.3 User Authen tication and Creation of a Secure Session . . . 23 4.3.1 Certifcates . . . . . . . . . . . . . 25 4.3.2 Authen tication Proto col . . . . . . . . . . 25 4.3.3 User Login Options . . . . . . . . . . . 28 4.4 New Site Creation . . . . . . . . . . . . . 30 4.5 Adding a New Administrator to a Site . . . . . . . 31 4.6 Creating a New User . . . . . . . . . . . . 31 4.7 Securing T ransfer of Messages Through Net w ork . . . . . 32 4.7.1 Pro cedure . . . . . . . . . . . . . 33 4.7.2 Pseudo co de and Explanation . . . . . . . . 33 4.8 Summary . . . . . . . . . . . . . . . 37 5 IMPLEMENT A TION AND TESTING . . . . . . . . . 38 5.1 Implemen tation . . . . . . . . . . . . . . 38 5.1.1 Key P air Generation . . . . . . . . . . 38 5.1.2 Generation of Key Encryption Key . . . . . . 39 5.1.3 Generation of Session Key . . . . . . . . . 40 5.1.4 Digital Signature . . . . . . . . . . . 40 5.1.5 Digital Certifcates . . . . . . . . . . . 41 5.1.6 Encryption and Decryption . . . . . . . . . 42 5.1.7 Con v ersion of Ob jects to Byte Arra y . . . . . . 42 5.1.8 Ob jects Through Net w ork . . . . . . . . . 43 5.1.9 Database Service . . . . . . . . . . . . 45 5.1.10 Securing RMI Calls . . . . . . . . . . . 46 5.2 T esting . . . . . . . . . . . . . . . . 47 5.2.1 T esting Generation of Key Encryption Keys . . . . 48 vi

PAGE 7

5.2.2 T esting Signature Generation . . . . . . . . 48 5.2.3 T esting Addition of User . . . . . . . . . 48 5.2.4 T esting Addition of Administrator . . . . . . . 49 5.2.5 T esting Login Proto col . . . . . . . . . . 50 5.3 Summary . . . . . . . . . . . . . . . 50 6 CONCLUSION AND FUTURE W ORK . . . . . . . . . 52 6.1 Conclusion . . . . . . . . . . . . . . . 52 6.2 F uture W ork . . . . . . . . . . . . . . . 53 6.2.1 P orting Certifcates to X.509 Structure . . . . . 53 6.2.2 Key Migration Problem . . . . . . . . . . 53 6.2.3 Considering DCS Instance as En tities . . . . . . 54 6.2.4 Re-Authen tication . . . . . . . . . . . 54 6.3 Summary . . . . . . . . . . . . . . . 54 REFERENCES . . . . . . . . . . . . . . . . . 55 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . 56 vii

PAGE 8

LIST OF FIGURES Figure page 1.1 DCS System Arc hitecture . . . . . . . . . . . . 3 2.1 RMI Basic Structure . . . . . . . . . . . . . 8 2.2 RMI Clien t Serv er Arc hitecture . . . . . . . . . . 8 2.3 La y ers of RMI arc hitecture . . . . . . . . . . . . 9 2.4 Con v en tional Encryption System . . . . . . . . . . 11 4.1 State Digram for Authen tication Pro cess . . . . . . . . 24 4.2 Authen tication Proto col . . . . . . . . . . . . 26 4.3 UserIn terface . . . . . . . . . . . . . . . 29 4.4 User Login F rom Other Sites . . . . . . . . . . . 30 4.5 Co de Section for SecureClien tSo c k etF actory . . . . . . . 34 4.6 Co de Section for SecureServ erSo c k etF actory . . . . . . . 34 4.7 Co de Section for SecureSo c k et . . . . . . . . . . . 35 4.8 Co de Section for EncryptedOutputStream . . . . . . . 36 4.9 Co de Section for DecryptedInputStream . . . . . . . . 36 5.1 Co de Section for Key P air Generation . . . . . . . . . 39 5.2 Co de Section for Key Encryption Key Generation . . . . . 39 5.3 Co de Section for Signature Generation . . . . . . . . 40 5.4 Co de Section for Signature V erifcation . . . . . . . . 41 5.5 Co de Section for Encryption and Decryption . . . . . . . 43 5.6 Co de Section for Ob jects to Bytes and Vice-V ersa . . . . . 44 5.7 Co de Section for Ob jects Through Net w ork . . . . . . . 45 5.8 Co de Section for Inserting Ob jects in T ables . . . . . . . 46 viii

PAGE 9

5.9 Co de Section for Retrieving Ob jects from T ables . . . . . . 47 ix

PAGE 10

Abstract of Thesis Presen ted to the Graduate Sc ho ol of the Univ ersit y of Florida in P artial F ulllmen t of the Requiremen ts for the Degree of Master of Science SECURE COMMUNICA TION SER VICES F OR DISTRIBUTED CONFERENCE SYSTEM By Ra vic handran Aringunram Decem b er 2002 Chair: Ric hard E. Newman Ma jor Departmen t: Computer and Information Science and Engineering Network Se curity has b een the man tra of the last decade with the gro wth of the In ternet. Securit y has ev olv ed from the most basic forms lik e photo iden tication, signatures, and passw ords to the most adv anced lev els lik e cryptograph y digital signatures, certicates and bio-iden tication, whic h includes v oice recognition, retina matc hes, etc. Distributed Conference System v.2(DCS) is b eing dev elop ed in the Univ ersit y of Florida under the guidance of Dr. Ric hard Newman. DCS supp orts distributed collab orativ e w ork in whic h imp ortan t information ma y b e transferred o v er the net w ork b y users. Securit y issues b ecome imp ortan t as more p eople start using the system from dieren t domains. Basic securit y goals lik e conden tialit y authen ticit y and in tegrit y had to b e incorp orated in to the system. This thesis deals with the design and implemen tation of Secure Comm unication Services (SCS) to pro vide suc h features. SCS is resp onsible for pro viding cryptographic k eys to the users and site serv ers. Also SCS p erforms the functions of m utual authen tication b et w een users x

PAGE 11

and sites and creating a secure session. Authen tication is p erformed using a proto col that in v olv es distribution of session k ey and priv ate k ey to the user b y a trusted serv er with whic h it comm unicates. Due to the complexit y of handling asymmetric k eys, the users are allo w ed to store the k eys in a homesite. SCS pro vides the service of encryption and decryption of data sen t through the net w ork. All message transfers o v er the net w ork are carried out b y RMI calls. SCS pla ys the imp ortan t role of encrypting and decrypting the data sen t b y RMI calls at the so c k et lev el. Encryption and decryption are done using the DES algorithm. This is ac hiev ed b y using custom so c k et factories. SCS also p erforms housek eeping activites lik e generating RSA k ey pairs for users and sites, creating digital signatures, certifcates, and securely adding sites and new administrators to sites in a DCS instance. The ab o v e men tioned functionalities ha v e b een implemen ted and are presen ted as a separate mo dule to DCS v.2. Th us SCS pro vides the imp ortan t securit y features needed for distributed collab orativ e w ork. xi

PAGE 12

CHAPTER 1 INTR ODUCTION 1.1 Ov erview of Distributed Conference System Distributed computing forms the bac kb one of the arc hitecture used for sharing data. A conference system pla ys an imp ortan t role in the life of p eople who w an t to share data across the glob e. Distributed Conference System (DCS) grew out of the desire to incorp orate join t con trol o v er shared en vironmen ts. The Distribted Conference System is a pac k age that pro vides infrastructure for real-time coop erativ e w ork. DCS is an example of distributed system designed to supp ort conferencing o v er wide area net w ork (W AN). This sytem allo ws geographically separate users to collab orate in the preparation of do cumen ts, rep orts, soft w are etc. The v arious mo dules of DCS are describ ed briery in the follo wing subsections. 1.1.1 Conference Con trol Mo dule This mo dule is rep onsible for the creation pro cess or the b o ot up pro cess of DCS. It's duties include initialization of other mo dules, creating conferences, adding users, merging conferences, deleting conferences, remo ving users, pro viding GUI, etc. 1.1.2 Database and Comm unication Mo dule This mo dule [1] pro vides the database services for DCS. A distributed database is created and main tained b y this mo dule. In tegrit y and consistency of distributed databases are main tained b y this mo dule. Reliable comm unication is pro vided b y the realiable causal order m ulticast. All commands from one host are executed in order at all sites participating in that conference. 1

PAGE 13

2 1.1.3 Access Con trol Mo dule This mo dule deals with the access con trol issues for the conference. All sub jects in DCS are b ound to certain roles. Eac h role has its o wn capabilities. A sub ject can p erform an action on an ob ject only if the role to whic h he is b ound p ermits him to do so. A sub ject can bind to a n um b er of roles, but only one at a time. This mo dule main tains an access con trol matrix to facilitate access con trol decisions. 1.1.4 Notication Mo dule Notication mec hanisms [2] are used to inform agen ts ab out dieren t ev en ts happ ening in the system; these are o ccurrences of observ able activities. This mo dule is resp onsible for notifying users of ev en ts suc h as user logs in, log out, joins a conference, lea v es conference, etc. V arious means lik e email, zwrite, mailb o x are used to notify the users. 1.1.5 Decision Supp ort Mo dule Decision Supp ort System(DSS) facilitates the solutions of problems b y a group of p eople who ha v e join t resp onsibilit y of reac hing the decision. A v oting mec hanism is one of the to ols of DSS. It pro vides online v oting and has an automated v ote collection mec hanism. The system pro vides users with dieren t v oting metho ds. The system also pro vides an in terface that allo ws services to initiate decision pro cess for conference con trol activities. 1.1.6 Secure Comm unication Mo dule Secure comm unication services is resp onsible for authen tication of users, creation of k eys, certicates and pro viding secure comm unication c hannel. This thesis concen trates on the secure comm unication services. All these mo dules in teract and comm unicate with eac h other as sho w in the gure b elo w. In the curren t v ersion of DCS all the services are implemen ted

PAGE 14

3 NTF ACS DSS CCS Applications Local Database Distr. Database Group MulticastSite Messaging Secure Messaging Crypto RMI TCP UDP JDBCDBMS A A Figure 1.1: DCS System Arc hitecture

PAGE 15

4 using Ja v a, whic h helps in p ortabilit y and in tegration of the mo dules on v arious platforms. 1.2 Ov erview of Secure Comm unication Services The need for information securit y has undergone tremendous c hanges during the last few decades. Ma jor adv ance w as made when net w orks w ere in tro duced and data transmitted through the net w orks. Net w ork securit y measures w ere need to protect the data during transmission. The Secure Comm unication Services pro vide computer and net w ork securit y for the users of DCS. Computer and net w ork securit y researc h and dev elopmen t ha v e fo cused on three or four general securit y services that are need for protecting data. The securit y services are listed b elo w Condentiality: Ensures that the information in a computer system and transmitted information are accessible for reading only b y authorized parties. A uthentic ation: Ensures that the origin of a message is correctly iden tied, with an assurance that the iden tit y is not false. Inte grity: Ensures that only authorized parties are able to mo dify computer system assests and transmitted information. Nonr epudiation: Requires that neither the sender nor the reciev er of a message b e able to den y the transmission. SCS is resp onsible for pro viding all these features. T o enforce the imp ortan t securit y prop erties (suc h as conden tialit y authen tication and in tegrit y) of computer and net w ork systems, it is necessary to establish the iden tit y of the en tities of the system. The en tities of the system can b e users and hosts or serv ers. The iden tit y of the en tities should b e done reliably that is, it should b e authen ticated. DCS p oses a greater c hallenge since en tities comm unicate with messages and hence b oth m ust establish their iden tit y and main tain conden tialit y In DCS iden tit y is rst established and usage of cryptograph y pro vides the conden tialit y and in tegrit y The users of DCS roam ab out and this p oses an ev en bigger c hallenge to meet the securit y goals.

PAGE 16

5 The Distributed Conference System v ersion t w o is in tended to pro vide distributiv e collab oration across m ultiple domains. Hence a strong authen tication pro cess is necessary in order to pro vide the basic securit y features and prop erties. Moreo v er the securit y services should b e able to handle roaming users. This mak es it more c hallenging as the users do not k eep the k eys with them when they roam. Hence there should b e a home domain where the users can store their k eys. In order to pro vide the authen tication, conden tialit y and in tegrit y features an infrastructure should b e main tained that handles k ey creation and main tenance. Also creation and main tenance of certicates is needed. The infrastructure should b e created and up dated whenev er users are added or sites are added or site administrators are added. En tit y iden tit y is established and authen ticated using this infrastructure. 1.3 Denitions This section giv es a brief denition of certain terms that are used frequen tly in the coming c hapters. Entity A sub ject, ob ject or application. An en tit y can only b e one of these at an y giv en momen t. Subje ct The class of activ e en tities that can act on ob jects. A Sub ject is alw a ys b ound to a role. Obje cts The class of passiv e en tities that can b e acted up on b y sub jects. Ob jects can con tain, and can b e con tained b y other ob jects. Confer enc e A tuple consisting of sub jects, ob jects, applications, roles and allo w able sub ject-role bindings. Keys A random n um b er generated b y a giv en algorithm whic h has a prop ert y of encrypting and decrypting data. Session key A shared symmetric k ey b et w een t w o en tities used for encrypting and decrypting messages for a particular session. Key Pair A pair of public and priv ate k ey for an en tit y

PAGE 17

6 Public Key A part of a k ey pair that is made public to ev ery one Private Key A part of a k ey pair that is k ept secret b y the o wner of the k ey pair Passphr ase A string whic h is k ept secret b y an en tit y and is used to authen ticate a p erson. Digital Signatur e Pro duces the same eect as a real signature; it is a mark that only a sender can mak e, but others can easily recognize as b elonging to the sender. Just lik e a real signature, a digital signature is used to conrm agreemen t to a message RMI Remote Metho d In v o cation. 1.4 Organization of Chapters The next c hapter deals with the previous w ork done in the related areas. It discusses ab out the encryption, k eys, certicates and RMI. The third c hapter lists the requiremen ts of the Secure Comm unications Services mo dule. It pro vides with an exhaustiv e list of requiremen ts. The fourth c hapters deals with the detailed design of the SCS mo dule. It giv es a vivid description of the authetication proto col and creation of secure c hannel for comm unication. The fth c hapter deals with the implemen tation details of the mo dule. It also lists the v arious test cases whic h w ere giv e during the testing phase. The nal c hapter summarizes and concludes and it also discusses the future w ork whic h can b e done in this area.

PAGE 18

CHAPTER 2 SUR VEY OF RELA TED W ORK This c hapter giv es a list and describ es the relev an t topics and bac kground w ork done b efore designing SCS mo dule. Initial section deals with the detailed description of RMI. The latter sections deals with imp ortan t topics in net w ork securit y and giv es a brief description of eac h topic. With the study of these topics and relev an t information, the requiremen ts and design of SCS mo dule is discussed in the follo wing c hapters. 2.1 Remote Metho d In v o cation Remote Metho d In v o cation (RMI) w as in tro duced to ela v ate net w ork programming to a higher plane and to pro vide abstraction to the users. The primary goal of RMI is to allo w programmers to dev elop distributed programs with the same syn tax and seman tics used for non-distributiv e programs. In order to ac hiev e this, Ja v a ob jects and classes on a single mac hine are mapp ed to a mo del w ere classes and ob jects w ork on a distributed en vironmen t. 2.1.1 RMI Arc hitecture RMI arc hitecture [3] describ es ho w ob jects are used in distributed en vironmen t, parameter passing, exceptions, memory managemen t and ho w return v alues are managed. Interfac es: RMI uses an imp ortan t prop ert y: the denition of b eha viour and the implemen tation of that b eha viour are separate concepts. The co de whic h denes the role of a function and the co de that implemen ts the role are separate and are run on dieren t mac hines. This ts correctly in the arc hitecture of distributed en vironmen t. Denition of a remote service is co ded using Ja v a in terface. The implemen tation of the service is co ded in a class. This can b e seen in Fig 2.1 Ja v a 7

PAGE 19

8 CLIENT PROGRAM INTERFACE SERVER PROGRAM IMPLEMENTATION Figure 2.1: RMI Basic Structure CLIENTSERVICE PROXY SERVERSERVICE IMPLEMENTATION SERVICE Figure 2.2: RMI Clien t Serv er Arc hitecture in terface do es not con tain an y executable co de. There are t w o classes that implemen t the in terfaces. One class giv es the implemen tation of the functionalit y of the remote service and it is run on the serv er side. The other class acts as a pro xy for the service and it runs in the clien t side. This is sho wn Fig 2.2. The clien t program just calls metho ds on the pro xy ob ject and RMI passes on this request to the remote mac hine and giv es it to the implemen tation part. Return v alues are sen t bac k to the pro xy and then they are giv en bac k to the clien t program that made the call initially

PAGE 20

9 CLIENT PROGRAM SERVER PROGRAM SKEL & STUB SKEL & STUB REMOTE REFERENCE REMOTE REFERENCE TRANSPORT LAYER RMI SYSTEM Figure 2.3: La y ers of RMI arc hitecture 2.1.2 La y ers of RMI RMI is built from three la y ers. The rst la y er is the Stub and Sk eleton la y er, the second la y er is the remote reference la y er and the third la y er is the transp ort la y er. This is sho wn in Fig.2.3. Stub and sk eleton la y er A stub and a sk eleton class if generated whenev er an RMI application is dev elop ed. The stub class pla ys the role of the pro xy and the remote service implemen tation class pla ys the role of the real ob ject. The sk eleton class pla ys the role of a help er class for the RMI. The sk eleton kno ws ho w to comm unication with the stub. The sk eleton carries on the con v ersation with the stub. Remote reference la y er The remote reference la y er is rep onsible for the RMI connection. This la y er pro vides an ob ject that acts as a link to the remote service implemen tation. RMI pro vides one w a y for clien ts to connect to the remote service. A unicast p oin t-to-p oin t connection is made. The remote service is instan tiated and is registered at a w ell kno wn agen t. A w ell kno wn agen t is rmiregistry This should b e done b efore the clien t mak es a call to the remote service. T ransp ort la y er The transp ort la y er is rep onsible for pro viding connection b et w een dieren t mac hines. All the connections established b y this la y er are stream-based net w ork connections that use TCP/IP

PAGE 21

10 2.2 Net w ork Securit y 2.2.1 Mo del of Net w ork Securit y In this section a mo del of a net w ork securit y system is explained in general terms[4 ]. Eac h asp ect of this mo del is discussed in detail in the follo wing sections. Securit y is needed where it is desirable to protect the information transmission from an in truder or an outsider who ma y presen t a threat to conden tialit y authen ticit y etc. All securit y mo dels ha v e t w o comp onen ts: 1. A securit y related transformation on the data to b e sen t through the net w ork. 2. A secret information shared b y the comm unicating en tities. This could b e a secret symmetric k ey or a secret function. T ransformation could b e ac hiev ed b y encryption or addition of some co de based on the sender for iden tication purp oses.The secret information could b e a secret symmetric k ey or a secret function. In some cases a trusted third part y migh t b e needed for mediation. The third part y ma y b e rep osnsible for distributing the secret information or ma y arbitrate disputes b et w een the en tities. The general mo del has four steps in designing the securit y service: 1. design an algorithm for doing transformation of the data; 2. generate a secret information to b e used; 3. dev elop metho ds for the distribution and sharing of the secret information; 4. determine a proto col to b e used b y the t w o en tities that mak es use of the algorithm and the secret information to ac hiev e a securit y service. 2.2.2 Con v en tional Encryption System The ab o v e gure illustrates the con v en tional encryption mo del. The original message is referred to as plain text. Plain text is con v erted in to what app ears to b e random nonsense and this is kno wn as ciphertext. The encryption pro cess is done using an algorithm and a k ey The k ey is a v alue indep enden t of the plain text. The

PAGE 22

11 MESSAGE X ENCRYPTIONALGORITHM KEY SOURCE DECRYPTIONALGORITHM DESITNATION Y X K K Figure 2.4: Con v en tional Encryption System algorithm will pro duce a dieren t output dep ending on the sp ecic k ey b eing used at that time. Once the cipher text is formed it is transmitted through the net w ork. On the destination side the cipher text is transformed bac k to the original plain text b y using a decryption algorithm and the same k ey that w as used for encryption. Cryptographic systems are classied under three dieren t con texts 1. T yp e of tr ansformation use d for encryption or tr ansformation All encryption algorithms can b e divided in to t w o categories: substitution, in whic h eac h elemen t in the plain text is mapp ed to another elemen t and transp osition, in whic h elemen ts in the plain text are re-arranged. 2. The numb er of keys use d. If b oth sender and the receiv er use the same k ey then the system is referred to as symmetric, single k ey or secret k ey system or a con v en tional encryption system. If the sender and the reciev er eac h use a dieren t k ey the the system is referred to as asymmetric, t w o k ey or public-k ey encryption system 3. Pr o c essing of Plaintext. A blo c k cipher pro cesses the input one blo c k of elemen ts at a time. A stream cipher pro cesses the input elemen ts con tin uously 2.2.3 Secret-Key Encryption Secret-k ey encryption or symmetric-k ey encryption, or con v en tional cryptograph y uses one k ey for b oth encryption and decryption pro cess. Data Encryption Standard (DES), is an example symmetric encryption.

PAGE 23

12 Symmetric k ey cryptograph y [5] is v ery straigh tforw ard. A k ey is used to encrypt the data and the same k ey is used to decrypt the data on the receiv er's end. The securit y dep ends on the strength of the k ey and the strength of the encryption algorithm. Since the same k ey is used in b oth the sender's and receiv er's side, distributing this k ey b ecomes a ma jor problem in symmetric encryption systems. The question is ho w do y ou k eep the k ey safe with the sender and transmit it securely to the receiv er. If there is a w a y b y whic h k eys can b e transmitted securely then the same metho d can b e used to transmit data instead of using a k ey and the encryption algorithm. If the k ey is shared b et w een more than one p erson, then there is no w a y to establish the authen ticit y of the originator. An y p erson who kno ws the secret k ey can generate the message using that k ey These problems led to the dev elopmen t of Public-k ey cryptograph y 2.2.4 Public-Key Cryptograph y Public-k ey cryptograph y w as in tro duced in the late 70's. A pair of k eys, is used to encrypt and decrypt messages. Eac h pair of k eys designated to an en tit y consists of a public k ey and a priv ate k ey The public k ey is made public b y distributing to all the en tities of the system. The priv ate k ey is k ept as a secret and hence only the o wner of the priv ate k ey has kno wledge of it. The public and priv ate k ey of a particular pair uniquely complemen t eac h other. Public k ey cryptograph y is useful and dieren t b ecause of the prop ert y that data encrypted with a priv ate k ey can only b e decrypted with the corresp onding public k ey Lik ewise, data encrypted b y the public k ey can only b e decrypted b y the corresp onding priv ate k ey Another imp ortan t feature of public k ey cryptograph y is that all the comm unication in v olv es only the public k eys and no priv ate k ey is ev er shared. The size of the k ey usually giv es the strength of the k ey The larger the k ey size, more is the securit y

PAGE 24

13 The public k ey is deriv ed mathematically from the priv ate k ey The k eys are mathematically related to eac h other. RSA (Riv est, Shamir, Adleman) is one of the most widely used public k ey encryption metho ds. The k ey pair is deriv ed using the concepts of big prime n um b ers and factorization concepts. Ev en though the t w o k eys are mathematically dep enden t it is extremely diuclt or computationally infeasible to deriv e the priv ate k ey from the public k ey as far as w e kno w. 2.2.5 Public Key Encryption Scenario Let us consider three en tities A, B and C of a particular system. Eac h en tit y has a k ey k ey pair whic h is of the form K x and K 1 x where Kx is the public k ey and K x 1 is the priv ate k ey of en tit y X. Supp ose A and B w an t to ha v e a secret session b et w een them and they do not w an t C to kno w ab out their con v ersation. This can b e ac hiev ed in the follo wing w a y A will send the message to B encrypted using B's public k ey Let M1 b e the message. The cipher text is f M 1 g K B The cipher text is sen t to B. When B receiv es the message then he will decrypt the ciphertext using his priv ate k ey ff M 1 g K B g K 1 B g = M 1 This according to the prop ert y that whic h states that data encrypted b y public k ey can b e decrypted only b y the corresp onding priv ate k ey Th us B is able to retriev e the plain text from the message it got from A. The ab o v e explanation sho ws that A can send an encrypted message to B and B can retriev e the original message successfully It has to b e pro v en that C cannot listen to A and B's con v ersation. Supp ose C gets a cop y of the cipher text f M 1 g K B C cannot decipher an ything from this ciphertext. He has to ha v e a k ey to decrypt this message. The k eys whic h C has are his o wn public and priv ate k eys, A's public k ey and B's public k ey The message can b e decrypted only b y B's priv ate k ey Th us with the k eys C has he cannot retriev e the original message. 2.2.6 Symmetry-k ey vs Public-k ey encryption Both con v en tional and public-k ey encryption systems ha v e their pros and cons. Con v en tional encryption is v ery simple but k ey distribution is the ma jor disadv an tage. Key could b e exc hanged b et w een t w o en tities in p erson, whic h solv es

PAGE 25

14 the k ey distribution problem. This is can b e done b ecause, k ey distribution is not a time critical problem. But, the same thing cannot applied to messages, as messages has to reac h the destination at the righ t time. Public k ey crypto systems a v oid the issue of k ey distribution but this comes with a price. The problem asso ciated with this system, is the asso ciation of k eys with en tities in the system. The pro cessing p o w er needed to encrypt and decrypt messages is v ery high when compared to con v en tional crypto systems. 2.2.7 Digital Signature Digital signatures are similar to hand signatures. Digital signature authen ticate a message and pro vide the feature of non-repudiation. Digital signature(ideally) prev en ts the sender from later den ying that he did not send the message. Digital signatures are obtained using public k ey cryptograph y A digital signature can b e describ ed as follo ws. Consider t w o en tities A and B and let eac h one ha v e their o wn k ey pair. If A w an ts to send a message to B and sign it, he will do the follo wing: Let the message b e M. A encrypts the message M using his priv ate k ey and it is represen ted as f M g K 1 A This is the digital signature. A sends the original message along with the signature to B. B decrypts the signature using A's public k ey B c hec ks whether the original message matc hes with the message in the signature If they matc h then it is pro v ed that A has sen t the message and it pro v es the iden tit y of the sender. Only A could ha v e generated a corresp onding signature to the message M b ecause only A has his priv ate k ey Hence message authen tication is done. If A later denies that he did not send message M to B, then B can gh t bac k sa ying that since only A has access to his priv ate k ey only A could ha v e generated a message and the corresp onding signature. Hence digital signatures pro vide the feature of non-repudiation.

PAGE 26

15 Since a digital signature usually uses hashing on the message, the signature generated w ould b e dieren t for eac h message. Hence it is not p ossible to use someone else's signature and attac h it to the message. If this is done then when the signature is original the messages will not matc h. Digital signatures are sup erior to handwritten signature in certain w a ys, that it cannot b e coun terfeited and also in that it applies to the whole message. In the case of handwritten signature the con ten t of the message can b e later c hanged ev en after the signature has b een made. But digital signature do es not imply that, the p erson who signed the do cumen t w as ph ysically presen t when signature w as done. The securit y of the digital signature is dep enden t on the securit y of the priv ate k ey If the priv ate k ey falls in the hands of a malicious p erson then digital signatures can b ecome a nigh tmare. Another k ey issue that could limit the practical use of digital signature is that the public k eys for a p erson up on whic h another relies ma y ha v e b een falsely created. This is called man-in-the-middle attac k. One ma y create a priv ate k ey and circulate the corresp onding public k ey as b elonging to someone else. If another p erson relies up on this false public k ey then he migh t actually end up comm unicating with the wrong p erson. T o a v oid this digital certicates are needed. 2.2.8 Digital Certicates Public k ey cryptosystems can b e eectiv ely put in to practical use only if it made sure that public k eys are distributed securely The sender who encrypts using public k ey or reciev er who decrypts using the public k ey (in case of digital signatures) should b e sure that they are using the public k ey that corresp onds to the correct p erson. Exc hange of public k eys is an imp ortan t issue and the w a y it is done is through digital certicates. A digital certicate is pro vided b y a third part y and it sa ys that a public k ey b elongs to this corresp onding o wner. A digital certicate con tains the public k ey

PAGE 27

16 name of the p erson that the k ey b elongs to, and a digital signature. The certicate ma y also include the certier, certicate n um b er, etc. The purp ose of the digital certicate is to giv e an assurance to a p erson b y a third part y The third part y v ouc hes for the authen ticit y of an en tit y Usually the third part y who do es this is called as a Certication Authorit y (CA). Another imp ortan t thing ab out digital certicates is that they allo w y ou to establish the iden tit y of the p erson with who y ou are dealing. 2.3 Summary The study of relev en t materials lik e RMI and topics in net w ork securit y is v ery imp ortan t for the w ork done in this thesis. The three la y ers of RMI nameley stub and sk eleton la y er, Remote reference la y er and the transp ort la y er w ere explained in detail. Also a detailed explanation of ho w so c k ets are use w as giv e. A general mo del of net w ork securit y w as explained. Digital signatures, certicates, con v en tional crypto systems and public k ey crypto systems w ere discussed in detail. With these topics in mind the requirmen ts and design of the SCS mo dule w as done. SCS mo dule requires an extensiv e use of the study done in this c hapter.

PAGE 28

CHAPTER 3 REQUIREMENTS SPECIFICA TION 3.1 In tro duction SCS is a subsystem that is resp onsible for pro viding the features necessary for the secure op eration of DCS. The initial part of this c hapter deals with the securit y goals and p olicies of DCS. The latter part describ es the pro cesses in DCS that need to b e considered for dealing with securit y requiremen ts and the p ossible mec hanisms used to attain the sp ecied securit y goals. Refer to Newman and Green w ald [6] for the complete set of requiremen ts for the en tire DCS system. 3.2 Securit y Goals SCS has to pro vide mec hanisms to ac hiev e the securit y goals. These features m ust b e added to the existing DCS b y SCS, as an individual subsystem and b y in teracting with the existing susbsystems of DCS. The imp ortan t high lev el securit y goals can b e listed as follo ws. Iden tify and authen ticate en tities of DCS, namely users and sites. Message transfers in DCS m ust b e done conden tially and means to iden tify the senders and recipien ts m ust exist. The follo wing sections giv es a list of pro cesses o ccurring within DCS, the necessary features that are to b e added to the existing pro cesses to meet the securit y goals and the p ossible mec hanisms to attain the sp ecied requiremen ts. 3.3 Pro cesses within DCS All activities going on within DCS fall in one of the t w o categories namely dynamic pro cesses and nearly static pro cesses. 17

PAGE 29

18 3.3.1 Dynamic Pro cesses These are pro cesses that tak es place v ery often. These pro cesses c hange the securit y state of the system. These pro cesses are listed b elo w. 1. Instan tiation and termination of serv ers. 2. Creation and destruction of sessions. 3. T ransmission and reception of messages. 3.3.2 Nearly Static Pro cesses These pro cesses o ccur less frequen tly and do not aect the state of the sytem. They cause some c hanges only to the database table. List of pro cesses to b e considered are listed b elo w. Creation and deletion of sites. Adding new administrator to existing site. Creation and deletion of users. The follo wing three sections discusses ab out the securit y requiremen ts for dynamic pro cesses. 3.3.3 Instan tiation and T ermination of Serv ers Instan tiation and termination of serv ers m ust b e done only but administrators. The administrator and the serv er m ust b e able to authen ticate to other existing serv ers in the system. The new serv er m ust b e able to join in to the existing system b y authen ticating itself and m ust b e in a p osition to authen ticate others. The new serv er m ust b e able to access tables and send messages conden tially and with in tegrit y 3.3.4 Creation and Destruction of Sessions A session is created b efore an y comm unication b et w een the users and the sites. T o meet the securit y goals, users and sites m ust b e iden tied and authen ticated. SCS is resp onsible to pro vide the features necessary to strongly authen ticate parties

PAGE 30

19 at b oth ends and to start a secure session. This ma y require a clien t pro cess to act on b ehalf of the user and a proto col to establish m utual authen ticit y Once m utual authen ticit y is established the user and the site m ust b e able to comm unicate securely SCS is rep onsible to protect the conden tialit y and the in tegrit y of messages after a secure session is established. 3.3.5 T ransmission and Reception of Messages A DCS instance has m ultiple sites and message or information needs to b e transfered from one site to another o v er the net w ork. One example of suc h information is propagation of up dates to the tables main tained b y the distributed database service. Eac h table has a replica in ev ery site and an y up date to an en try in the table has to b e rerected in all the copies so that the database is consisten t. This propagation is done b y RMI calls b y the database service. Lik ewise an y comm unication of sites o v er the net w ork is done b y RMI calls. T o incorp orate conden tiallit y and in tegrit y in message transfers is one of securit y goals. SCS tak es the resp onsibilit y of pro viding conden tialit y and in tegrit y in message passing through RMI calls. T o pro vid this feature all RMI calls m ust b e made secure. Encryption and decryption of data sen t through RMI calls is one of the w a ys to to meet the securit y goals The follo wing three sections discusses the securit y requiremen ts for nearly static pro cesses. 3.3.6 Creation and Deletion of Sites New sites are added to the system b y the CCS in the curren t system. Eac h site is uniquely iden tied b y the site id. As in the case of users, sites also require a stronger iden tication sc heme. Asso ciating sites with k ey pair is one of the w a ys to ac hiev e stronger iden tication. A new site m ust b e created b y an administrator. The administrator m ust b e an authorized p erson and so he should b e a v alid DCS

PAGE 31

20 user. When the admin creates the site, he m ust also run the utilit y that creates the k ey pair for the new site. Once the site k eys are formed there m ust b e a w a y to mak e the new site to join the DCS instance. When the new site en ters the DCS instance the transition m ust b e smo oth. In no case there m ust b e a an y halt in the normal op eration of the rest of the DCS instance. The certicates of the new site m ust b e formed. The certicate m ust b e distributed to the rest of the sites in the DCS instance so that they can iden tify and trust the new site. Also the certicates of the other sites m ust reac h the new site ev en tually These comm unications in no w a y should hinder the normal op eration of DCS. A site can b e deleted from the system. Only administrators m ust b e allo w ed to delete sites from the system. Whenev er a site is deleted SCS is rep onsible for destro ying the certicates and k ey asso ciated with site. 3.3.7 Adding New Administrator to Existing Site A site ma y require a new administrator for dieren t purp oses. Hence there m ust b e pro vision to create new administrators for a site and strongly asso ciate the new admin with the site. There ma y b e situations in whic h a site migh t require more than one administrator. Hence options m ust b e a v ailable to add a new administrator and also mak e m ultiple administrators options op en. When a new admin is added, he m ust b e authorized rst. Utilities m ust b e a v ailable to c hec k the new p erson's credibilit y b y c hec king his certicates and making sure that they are not corrupted and are v alid. When m ultiple administrators are not needed, the old admin m ust b e remo v ed, once the new admin is included in to the system. When m ultiple administrators are allo w ed then all administrators m ust ha v e equal authorit y o v er the site. Eac h of them m ust b e able to p erform all the op erations the other administrator can p erform. An y administrator m ust b e able to start

PAGE 32

21 or terminate serv ers in suc h a w a y that it can authen ticate itself to other serv ers within its site and to other sites. 3.3.8 Creation and Deletion of Users Users are added and deleted b y the CCS. Users are iden tied b y a unique DCSID and a passphrase in the curren t system. A stronger iden tication sc heme is required. One of the w a ys of ac hieving the requiremen t could b e done b y asso ciating ev ery user in DCS with a unique k ey pair. SCS is resp onsible creating the k ey pair and asso ciating the k ey pair with a corresp onding user. Since k eys are long and dicult to remem b er, there m ust b e w a ys to store the k eys and retriev e the k eys in a secure fashion. Whenev er a user is remo v ed from the system SCS m ust tak e the resp onsibilit y of destro ying the k ey pair asso ciated with the user. User m ust b e able to login at an y DCS site in the instance, and desirable to b e able to login from an y lo cation with DCS clien t. 3.4 Summary The main securit y goals ha v e b een listed and the pro cesses that are to b e mo died to meet the securit y requiremen ts are iden tied. The goal w as to iden tify and authen ticate en tities of the sytem and to mak e all message passing conden tial. Pro cesses w ere classed as dynamic pro cesses and nearly static pro cesses. Eac h pro cess w as analysed and the features to b e added w ere recognized. The requiremen ts that are to b e met b y o ccurrence of eac h ev en t ha v e b een discussed in detail and p ossible w a ys to ac hiev e the requiremen ts ha v e also b een p oin ted out in this c hapter.

PAGE 33

CHAPTER 4 DESIGN 4.1 In tro duction In this c hapter the detailed design asp ects of the SCS mo dule are discussed. A detailed description of the user login proto col pro cess is explained. This c hapter also describ es the structure of the necessary certicates, metho d of storage and the usage of certicates in the proto col. Latter sections explain the steps to b e tak en in terms of securit y features during new user creation, new site creation and new admin creation. The last section of the c hapter deals with the steps in v olv ed in securing RMI calls whic h in eect pro vides a secure DCS c hannel. 4.2 Design Lev el Choices Design lev el c hoices w ere made to meet the requiremen ts and the structure of the existing system in mind. The authen tication proto col w as designed in order to giv e a lot of rexibilit y to the user. The design of the proto col w as made in suc h a w a y that a roaming user need not ha v e to remem b er a long k ey pair. Certicates w ere designed to k eep the pro cess of authen tication simple, and with minim um n um b er of handshak es. Customizing so c k et factories of RMI made message passing conden tial. Certicates are formed for b oth users and sites. Hence the b elo w men tioned proto col and securing RMI calls are necessary to create a secure session b et w een a user and a site, instead of using SSL. SSL pro vides authen tication b et w een serv ers and not b et w een users and serv ers. In the case of SSL, a malicious user can use the system after the serv ers are authen ticated. PKI could not b e used due to its inheren t nature. PKI used a hierarc hical structure whic h w as not suitable to the DCS arc hitecture. Also PKI uses rev o cation lists whic h is not applicable to DCS certicates. Moreo v er the nancial asp ect of implemen ting PKI 22

PAGE 34

23 pro v ed to b e another hinderence in using PKI. Using smart-cards to store k eys w as one of the options discussed. This increases the burden on the user, as he has to carry the smart-card with him wherev er he go es and has to nd a suitable hardw are system to install the smart-card. With all these dieren t issues in mind the most suitable proto col for DCS w as designed and implemen ted. 4.3 User Authen tication and Creation of a Secure Session As describ ed in the requiremen ts c hapter, the main aim of this proto col is to distribute a session k ey created b y the serv er, to a clien t pro cess that is starting a session. A session is started b y a pro cess of login and authen tication. There are sev eral steps in v olv ed in the m utual authen tication pro cess. It is imp ortan t that m utual authen tication tak es place, as b oth the serv er and clien t should come to a conclusion that they are comm unicating with the righ t en tit y The broad outline of this pro cess can b e understo o d using Fig 4.1. The follo wing con v en tions are follo w ed throughout this c hapter. A serv er en tit y is represen ted as S A user is represen ted b y a clien t pro cess C The public k ey of an en tit y e is represen ted as K e The priv ate k ey of a en tit y e is represen ted as K 1 e A session k ey b et w een t w o en tities C and S is represen ted b y K cs A nonce n um b er is represen ted as N x Before going through the steps of the proto col, it is imp ortan t to understand the certicates required, the structure of the certicates and the storage mec hanism of certicates.

PAGE 35

24 ID, passphrase GUI CLIENT SERVER ID CERTIFICATES SESSION KEY RESPONSE AUTHENTICATION PROCESS SECURE SESSION Figure 4.1: State Digram for Authen tication Pro cess

PAGE 36

25 4.3.1 Certicates As describ ed in the previous c hapter, certicates are formed to store and retriev e k eys of the users and sites a secure fashion. The certicates required, ho w they are formed and where they are stored are explained as follo ws. User pro vides only his DCS id and the passphrase. Users and sites ha v e a k ey pair asso ciated with them. A secret k ey can b e generated from the user's passphrase. The serv er S uses this secret k ey to encrypt the user's k ey pair when the user is created or added to the system. The serv er S has t w o public k ey certicates and one priv ate k ey certicate for the user C. Detailed structure of certicates can b e found in Sec. 5.1.5. User PublicKey Certicate: C, K C ,S, f N,C, K C g K 1 S This certicate denotes that the public k ey of C is K C and it is signed b y the serv er S. S v ouc hes for C's public k ey This ceritifcate is formed b y the serv er and it is stored in the serv er. Serv er PublicKey Certicate: S; K S ; C ; f N p ; S; K S g K 1 C This certicate denotes that the public k ey of the serv er S is K S and it is signed b y the user C. User C v ouc hes for the serv er S's public k ey This certicate is created b y the user during its creation and is stored in the serv er. User Priv ateKey Certicate: C ; f N p ; C ; K 1 C ; K C ; S g K pc This is a priv ate k ey certicate. This certicate is formed using the secret k ey generated using the clien t's passphrase. The secret k ey is used to encrypt the user's k ey pair and the certicate is stored in the serv er. This certicate is also created when the new user is added to the system. Other than these the serv er main tains list of public k ey certicates for other serv ers. The certicate structure is as follo ws. S 0 ; K 0 S ; S f N ; S 0 ; K 0 S g K 1 S This certicate states that the public k ey of serv er S 0 is K 0 S The serv er S v ouc hes for serv er S 0 's public k ey 4.3.2 Authen tication Proto col The proto col for authen tication [7] can b e explained using Fig 4.2.

PAGE 37

26 ID, passphrase GUI CLIENT SERVER ID Nc {Np, C, Kc -1 Kc, S} Kpc S, Ks, C, {Np, S, Ks} Kc -1 {{Nc, Ns, Kcs} Ks -1 } Kc {Ns} Kcs Figure 4.2: Authen tication Proto col

PAGE 38

27 The follo wing list giv es the assumptions for the authen tication proto col. All users and sites should ha v e their o wn public and priv ate k eys. All users store the k eys in the form of certicates in a secure manner. F or the ab o v e reason en tities encrypt the k eys using a secret k ey whic h is deriv ed from a passphrase. The passphrase should b e easy to remem b er but should not v ery common w ords or names of p erson or a thing. The encrypted k ey pair should b e stored in the user's homesite, at least. Deriv ation of k eys from passphrase m ust b e a simple pro cedure and a single passphrase should not map to dieren t k eys. W e assume that the users do k eep their passphrase a secret. Certicates are needed to authen ticate one another. Hence services m ust b e a v ailable to create, main tain and destro y certicates. The format of eac h certicate t yp e m ust b e pre-sp ecied. The steps for the authen tication pro cess are giv en b elo w. 1. User logs in to the clien t pro cess and giv es his/her DCSID and passphrase. 2. As the clien t pro cess has the capabilit y to form the secret k ey from the user's passphrase, it forms the secret k ey and stores it lo cally 3. The clien t pro cess gets the id of the homesite serv er of the user from the global databases and forw ards the DCSID and a c hallenge nonce to the serv er. 4. The clien t then listens for the serv er's resp onse. 5. The site rst resp onds b y giving the user's priv ate k ey certicate, whic h is stored in the site based on the DCSID. This certicate is nothing but the k ey pair of the user, encrypted b y the secret k ey generated b y the user's passphrase. 6. The secret k ey generated b y clien t from the passphrase is a symmetric k ey and hence the clien t can decrypt this certicate and retriev e the user's k ey pair. 7. The serv er then sends its o wn public k ey certicate signed b y the user's priv ate k ey Hence the clien t pro cess no w gets the serv er's public k ey

PAGE 39

28 8. Along with clien t's nonce and a c hallenge nonce the serv er generates,the session k ey is sen t b y the serv er. This session k ey is signed b y the serv er S and it is encrypted b y the user's public k ey K C Hence this message can only b e decrypted b y the corresp onding priv ate k ey 9. The clien t pro cess decrypts the session k ey using the user's priv ate k ey Then it sends bac k a resp onse to the c hallenge giv en b y the serv er encrypted b y the new session k ey 10. The serv er c hec ks this resp onse and if it is a v alid resp onse then the new session is accepted and the session k ey is used for an y further comm unication. 11. Th us the clien t and the serv er b oth come to a m utual agreemen t that the other p erson is using the new session k ey The correctness of the proto col can b e theoretically explained as follo ws. Only if the user's passphrase is correct, can the clien t pro cess generate the symmetric k ey and decrypt the user's k ey pair correctly The user's k ey pair is necessary to v erify the serv er's public k ey The serv er's public k ey and the user's priv ate k ey are required in order to decrypt the session k ey and to v erify it. Th us the whole proto col go es on smo othly only if the passphrase pro vided is correct. As stated in the requiremen ts, w e assume that the user k eeps his passphrase a secret. Also at the end of the proto col a c hallenge resp onse to the nonce generated b y the serv er is sen t bac k to serv er using the new session k ey Hence b oth parties are satised that the other p erson is using the fresh session k ey The mathematical pro of for this proto col is a v ailable in Newman et al. [7]. The pro of is done using logic of authen tication[8 ] 4.3.3 User Login Options The user in terface for the log on pro cess is designed as follo ws. The user t yp es in his user name and passphrase. There are t w o p ossibilities for the user to log on the DCS instance. 1. User can log on through the homesite 2. User can log on through a site other than his homesite

PAGE 40

29 User Name :Passphrase : Homesite is Current SiteThis is not my Homesite Figure 4.3: UserIn terface When the user logs in from his homesite, he clic ks the rst radio button, whic h sa ys that the curren t site is his homesite. When he logs in from another site, then he clic ks the second radio button, whic h sa ys that his homesite has to b e found from the global database. The authen tication pro cess for the user login from the homesite w as describ ed in the previous section. When the user logs in from another site the pro cess of authen tication is little dieren t. The dierence is mainly b ecause the certicates of the user ha v e to b e brough t from the user homesite. First, the curren t site queries the global database to get the homesite address for the user, using his DCSID. After the homesite is lo cated the curren t site con tacts the user's homesite requesting the users certicates. The homesite resp onds b y giving the certicates required for the login pro cess. The user trusts the homesite's public k ey for the curren t site. The user also has to b eliev e the authorit y of the homesite to sa y that the curren t site will issue a v alid session k ey

PAGE 41

30 User CurrentSite Global DB DCS idHomeSite id Figure 4.4: User Login F rom Other Sites 4.4 New Site Creation A new site is added to the instance b y the administrator. The administrator is a v alid DCS user and has a DCSID. The admin, when he creates the site also runs the utilities that create the k ey pair for the new site. The new site public k ey certicate is formed and is sen t to the admin's homesite. The certicate is signed b y the admin's priv ate k ey The priv ate k ey of administrator is obtained from the priv ate k ey certicate stored in admin's homesite. The newly formed public k ey certicate is as follo ws S 0 ; K s 0 ; AdminD C S I D ; f N ; S 0 ; K s 0 g K adminD C S I D 1 The homesite (S) of the administrator then broadcasts the public k ey to all other sites. The certicate is as follo ws S 0 ; K s 0 ; S; f N ; S 0 ; K s 0 g K s 1 where S is the homesite of the administrator. The corresp onding sites can v erify this certicate using the admin's public k ey Once the v erication is done eac h site forms its o wn public k ey certicate for the new site. Th us the homesite of the administrator acts as a link b et w een the new site and the rest of the DCS instance.

PAGE 42

31 4.5 Adding a New Administrator to a Site The follo wing steps are to b e executed b y the SCS when a new administrator is added to an existing site. 1. A new admin can b e added to the system only b y an existing administrator. Hence the existing admin logs in to the site b y pro viding his DCSID and his passphrase. 2. Using this passphrase the secret k ey is deriv ed and it is used to decrypt the site's k ey pair from the priv ate k ey certicate, i.e K s and K 0 S are retriev ed. 3. The new administrator's id and passphrase are obtained and a new secret k ey is deriv ed from the new passphrase. 4. Using this secret k ey the site k eys are again encrypted and a new priv ate k ey certicate is formed. 5. Once the new certicate is formed the administrator database table is up dated with the new admin's id and the certicate. 6. V arious options ha v e to b e dealt with here. The site can ha v e m ultiple administrators. In this case the old en try for the old admin is retained in the database. 7. If only a single administrator can b e presen t then the old admin en try in the tables are remo v ed. 8. If the site has m ultiple administrators then all the administrators will ha v e equal p o w ers in administering the site. 4.6 Creating a New User As describ ed in the previous c hapter, creating a new user is one of the ev en ts that is to b e handled b y SCS. SCS creates the k ey pair and certicates for iden tication and authen tication of user. The steps to b e done b y SCS when a new user is created are listed b elo w. 1. The information required b y the SCS mo dule are DCSID, username, passphrase, and the homesite id or address. 2. A fresh k ey pair is generated for the new user. 3. A secret k ey is generated that dep ends on the passphrase.

PAGE 43

32 4. Using this secret k ey the priv ate k ey certicate for the user is formed. This is nothing but encrypting the k ey pair with the secret k ey generated from the passphrase. 5. The public k ey certicate for the homesite is then formed. A new user is created b y an admin. Hence he can use his secret k ey to get the site's public k ey The site's public k ey is signed b y the new user's priv ate k ey 6. The site forms the public k ey certicate of the user. The user's public k ey is signed b y the site's priv ate k ey 7. All the certicates are stored in the database. The follo wing steps are follo w ed when a user needs to c hange his passphrase. 1. The user en ters his DCSID, old passphrase and the new passphrase. 2. The user's k ey pair is retriev ed using the old passphrase. 3. A new priv ate k ey certicate is formed using the new passphrase. 4. The new certicate is up dated in the tables and the old certicates are remo v ed. 4.7 Securing T ransfer of Messages Through Net w ork As stated in the previous c hapter all information transfer through the net w ork in DCS tak es place b y RMI calls. Hence forming a secure DCS c hannels implies that the RMI calls should b e made secure. Securing RMI calls can b e done using a Custom So c k et F actory RMI calls pro vide an abstraction to the user b y hiding the so c k et lev el comm unication. The underlying proto col uses so c k ets for comm unication b et w een the serv er and clien t. A secure c hannel is obtained b y encrypting and decrypting the data that is sen t and receiv ed b y the so c k ets. Installing our o wn RMI so c k et factories allo ws us to use a customized so c k et rather than a TCP so c k et pro vided b y ja v a.so c k et.net, whic h is used b y RMI as default. There are v e steps to create a custom RMI so c k et factory that pro duces a single t yp e of so c k et[9 ].

PAGE 44

33 1. Decide up on the t yp e of so c k et to b e pro duced. 2. W rite a clien t-side so c k et factory that implemen ts the RMIClien tSo c k etF actory 3. Implemen t the RMIClien tSo c k etF actory createSo c k et() metho d. 4. W rite a serv er-side so c k et factory that implemen ts RMIServ erSo c k etF actory 5. Implemen t the RMIServ erSo c k etF actory createSo c k et() metho d. 4.7.1 Pro cedure Creating secure so c k ets in v olv e the follo wing steps: 1. Implemen t SecureClien tSo c k etF actory class, 2. Implemen t SecureServ erF actory class, 3. Implemen t SecureSo c k et class, 4. Implemen t SecureServ erSo c k et class, 5. Implemen t EncryptedInputStream class, 6. Implemen t DecryptedOutputStream class, 7. Use the created custom so c k et factory 4.7.2 Pseudo co de and Explanation SecureClien tSo c k etF actory This class sp ecies the p o ol of so c k ets for clien ts when it needs to start comm unication. Whenev er a clien t needs a so c k et, a call to the createSo c k et() metho d is made. Hence in this class w e need to o v erride this metho d. This class will extend the RMIClien tSo c k etF actory class. The session k ey is a priv ate mem b er of this class and it is set in the constructor. Co de section is explained in Fig. 4.5. SecureServ erSo c k etF actory This class extends RMIServ erSo c k etF actory class. This sp ecies the p o ol of so c k ets for serv ers when it needs to start comm unication. Whenev er a serv er needs a so c k et, a call to the createSo c k et() metho d is made.

PAGE 45

34 { private sessionkey; SecureClientSocketFactory(sessionkey) { initialize the sessionkey } public Socket createSocket() { return new SecureSocket(sessionkey) } } public class SecureClientSocketFactory extends RMIClientSocketFactory Figure 4.5: Co de Section for SecureClien tSo c k etF actory { private sessionkey; { initialize the sessionkey } public Socket createSocket() { return new SecureSocket(sessionkey) } } public class SecureServerSocketFactory extends RMIServerSocketFactory SecureServerSocketFactory(sessionkey) Figure 4.6: Co de Section for SecureServ erSo c k etF actory Hence in this class w e o v erride this metho d. Fig. 4.6 explains the co de lev el details. SecureSo c k et This class extends that standard ja v a.net.so c k et class. This has metho ds to pro vide secure so c k ets to b oth clien t and serv er so c k et factories. The secure so c k ets are formed b y mo difying the input and output streams of the so c k et. An ything whic h go es through the streams of the so c k ets are encrypted. The sessionk ey is obtained from the constructor and it is set as a priv ate mem b er of this class. Co de section is sho wn in Fig. 4.7.

PAGE 46

35 public class SecureSocket extends java.net.socket{ private sessionkey; SecureSocket(sessionkey) { initialize sessionkey } public InputStream getInputStream() { return (new DecryptedInputStream(buffer, sessionkey); } public OutputStream getOutputStream() { return (new EncryptedOutputStream(buffer, sessionkey); }} Figure 4.7: Co de Section for SecureSo c k et EncryptedOutputStreamStream This class extends the FilterOutputStream class. All the pro cessing of the data whic h are going to pass through the net w ork are done in this class. Ev ery b yte whic h is sen t through the net w ork is encrypted b y the session k ey Fig. 4.8 giv es the co de segmen t for encrypting data. DecryptedInputStream This class extends FilterInputStream. When a data is read from a so c k et decryption pro cess tak es place in this class. The sessionk ey since it is a symmetric k ey is used to decrypt the data coming from the so c k et. Fig. 4.9 describ es the co de details of decryption. Using the So c k etF actories The usage of the newly created so c k et factory is v ery simple. The co de for creating secure so c k ets should b e installed in b oth the clien t and the serv er side. One line of co de needs to b e added in the constructor of the RMI serv er co de or the class whic h extends the UnicastRemoteOb ject class. The UnicastRemoteOb ject class uses the default RMISo c k etF actories. Instead in the constructor, if w e sp ecify that the So c k etF actory should b e the SecureSo c k etF actory then secure so c k ets are created whenev er an RMI call is made. Th us in

PAGE 47

36 public class EncryptedOutputStream extends FilterOutputStream { private sessionkey; EncryptedOutputStream(buffer, sessionkey) { initialize the session key and buffer } public message write() { Encrypt the data to be written write the data to outputstream } } Figure 4.8: Co de Section for EncryptedOutputStream { private sessionkey; { initialize the session key and buffer } { } } public class DecryptedInputStream extends FilterInputStream DecryptedInputStream(buffer, sessionkey) public message read() Decrypt the data to be written return the data to inputstream Figure 4.9: Co de Section for DecryptedInputStream

PAGE 48

37 the constructor of the RMI serv er the follo wing line of co de is added. sup er(0, SecureClien tSo c k etF actory(sessionk ey), SecureServ erSo c k etF actory(sessionk ey )) Once this is nished the clien t and serv er can b e compiled and run as normal RMI programs. Th us this metho d giv e a v ery go o d abstraction to the user as the encryption and decryption pro cess tak es place in the underlying la y ers without the kno wledge of the user. 4.8 Summary The k ey issues of design w ere discussed. The assumptions made and the steps to b e executed whenev er a particular ev en t o ccured w ere describ ed in detail. All the steps describing the design of eac h action, con tributes to w ards attaining the stated securit y goals. The authen tication proto col helps in m utual authen tication of users and sites b efore starting a session. Mutual authen tication is ac hiev ed b y exc hanging certicates. Once authen tication is done, a secure session is created and all message transfers are made secure b y using custom so c k et factories whic h encrypts messages. The necessary certicates are formed when a new user is created, or a new site is created or a new administrator is added to a site. All these certicates are up dated in tables in the database. With the inclusion of all these features, DCS op erations are made secure.

PAGE 49

CHAPTER 5 IMPLEMENT A TION AND TESTING This c hapter deals with the imp ortan t implemen tation details and the testing done on the soft w are mo dule. The en tire co de w as written in Ja v a. The database used to store the details of en tities is P ostgre SQL database serv er. The rst part of the c hapter talks ab out the implemen tation details and the latter half describ es the testing of the soft w are. 5.1 Implemen tation Implemen tation w as started using the a v ailable Ja v a pac k age that w as installed previously During the implemen tation phase it w as found that the existing pac kage (JDK 1.3) did not ha v e all the pac k ages necessary to generate the symmetric k eys and to supp ort encryption/decryption. F or this reason, J2SDK 1.4 v ersion w as installed in the systems. This v ersion had the ja v ax.crypto pac k age. This pac k age has the classes necessary to generate symmetric k eys and metho ds to do encryption/decryption. A few securit y les had to b e mo died for this pac k age to w ork prop erly Also, it w as disco v ered that the database mo dule did not supp ort insertion of ob jects in to tables. This w as a feature needed to store certicates in the tables. This feature w as added to the database service and a detailed explanation ab out this is a v ailable in the later sections. 5.1.1 Key P air Generation Eac h and ev ery user and site in DCS are designated a k ey pair that consists of a public k ey and a priv ate k ey The k ey pair is generated using the Ja v a Application Program In terfaces (API). The API's to generate a standard k ey pair is a v ailable in the ja v a.securit y pac k age. An instance of the class named KeyGeneratorP air is obtained b y using the getInstance() metho d, whic h tak es 38

PAGE 50

39 KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");keys.getPublic(); KeyPair keys = kpg.genKeyPair();keys.getPrivate(); Figure 5.1: Co de Section for Key P air Generation passphraseBytes = passphrase.getBytes();SecureRandom sr = new SecureRandom(passphraseBytes);KeyGenerator kg = KeyGenerator.getInstance("DES");kg.init(sr);skey = kg.generateKey(); Figure 5.2: Co de Section for Key Encryption Key Generation the algorithm name as a parameter. RSA algorithm is used to generate k ey pairs. Co de section to generate k ey pair is sho wn in the follo wing gure. generated as follo ws 5.1.2 Generation of Key Encryption Key As discussed in the previous c hapter, the user en ters only his DCSID and the passphrase when he logs in. The passphrase is a string. A k ey encryption k ey has to b e generated from the passphrase, the user en ters. Also the k ey encryption k ey should b e a symmetric k ey In order to meet these requiremen ts, the ja v ax.crypto pac k age is used. Crypto pac k age is bundled with standard J2SDK 1.4. The passphrase en tered b y the user is retriev ed and is con v erted to an arra y of b ytes. The b yte arra y is passed as a seed to generate a random n um b er. The random n um b er is used to initialize the k ey seed required to generate the k ey encryption k ey Symmetric k eys are generated using the KeyGenerator class pro vided b y Ja v a. This class generates a k ey of t yp e SecretKey whic h is also inherited from the base class Key Key encryption k ey is generated as sho wn in Fig. 5.2.

PAGE 51

40 Signature signature = Signature.getInstance("MD5withRSA");signature.initSign(priivateKey);signature.update(data);byte signdataa[] = signature.sign(); Figure 5.3: Co de Section for Signature Generation 5.1.3 Generation of Session Key The session k ey is also a symmetric k ey Hence the KeyGenerator class is used to generate eac h instance of a SecretKey The random seed for initialization is a standard random seed pro vided b y Ja v a. Hence eac h session k ey is also an instance of the SecretKey class whic h, can b e generated as discussed in the previous subsection. 5.1.4 Digital Signature Digital signatures pro vide in tegrit y of a message and also pro v es the authen ticit y of the senders. As discussed in the previous c hapter, signatures are hea vily used during the authen tication proto col. Digital signatures are bundled in the certicate (discussed in the next subsection), and are sen t and receiv ed during the pro cess of login. Signature class, pro vided b y the Ja v a API, pro vides the features of digital signatures. A Signature ob ject is created using the getInstance() metho d, whic h tak es an algorithm as a parameter. When this ob ject is used to sign or v erify a signature then the corresp onding algorithm is used. A signature is usually made using the signing part y's priv ate k ey So, to generate a signature the Signature ob ject is initialized using the signing part y's priv ate k ey Then the data to b e signed is up dated on the ob ject follo w ed b y the call to the sign() metho d. This metho d returns a b yte arra y that has the digital signature. Co de section to generate signature is sho wn in Fig. 5.3 The signature generated migh t ha v e to b e v eried b y another p erson. The public k ey of a site is signed b y the user and the vice v ersa. The user has to v erify

PAGE 52

41 Signature signature = Signature.getInstance("MD5withRSA");signature.initVerify(publicKey);signature.update(sign);return signature.verify(signdata); Figure 5.4: Co de Section for Signature V erication the whether the public k ey of the site is correct. Hence, he v eries the public k ey certicate generated with his signature. The signature is v eried using his public k ey A Signature ob ject is created, initialized using the public k ey and is up dated using the signature that has to b e v eried. Then, the v erify() metho d is called whic h returns a b o olean v alue. T rue is returned if, the signature is v alid and false is returned if the signature is not v alid. Signature v erication is sho wn in Fig. 5.4. 5.1.5 Digital Certicates Design of the digital certicates is made k eeping in mind the issues of p ortabilit y to standard certicate formats lik e the X.509 structure. A study on the certicates structures w as made and the design of the certicate structure is as follo ws, V ersion: Indicates the v ersion of the certicate structure whic h is curren tly in use. Se quenc e numb er: Indicates the sequence n um b er of the certicate. Signatur e algorithm: Giv es the name of the algorithm used to form the signature that is presen t in the certicate. Issuer id: Holds the DCSID of the p erson who has formed or issued the certicate or signature. V alidity: This is a date eld that denotes ho w long this certicate is v alid. After this date the certicate cannot b e trusted. Subje ct id: Holds the DCSID of the en tit y whose public k ey is b eing signed b y the issuer. Subje ct Public Key: Holds the ra w Public k ey of the sub ject.

PAGE 53

42 Signatur e: This eld is the signature. This signature is formed using the issuer's priv ate k ey The public k ey of the sub ject is signed using the priv ate k ey of the issuer. It is a b yte arra y Whenev er a new user is created, or a new site is added the corresp onding k eys are rst formed. The certicate con ten t to b e signed is generated follo w ed b y generation of signature. These certicate ob jects are formed b y p opulating the ab o v e men tioned elds and are stored in the database. The certicate ob jects are made serializable, as they need to b e transp orted o v er the net w ork during the logon pro cess. 5.1.6 Encryption and Decryption The en tire secure comm unication services mo dule is based on successful and strong encryption and decryption. Ja v a pro vides go o d API's for encrypting and decrypting b yte streams using algorithms of the user's c hoice. Symmetric encryption is done using DES algorithm and asymmetric encryption is done using RSA algorithm. This is ac hiev ed using the Cipher class in the ja v ax.crypto pac k age. An instance of the Cipher class is obtained using the getInstance() metho d that tak es the algorithm name as the parameter. The mo de of the Cipher ob ject is then set and and also the k ey is initialized. The mo de to b e set can b e ENCR YPT mo de or DECR YPT mo de. The k ey that is used during initialization is used for encryption or decryption. The b yte stream to b e encrypted or decrypted is passed to the doFinal() metho d for the encryption or decryption pro cess. The doFinal() metho d returns a b yte arra y encrypted or decrypted according to the initialization. The Fig. 5.5 giv es the details of implemen tation. 5.1.7 Con v ersion of Ob jects to Byte Arra y While constructing a signature, the up date(data) metho d of the Signature ob ject tak es a b yte arra y as a parameter. The data to b e signed b y an en tit y should b e a b yte arra y Public k ey has to b e signed b y the issuer. PublicKey is an ob ject and this needs to b e con v erted to a b yte arra y in order to initialize the

PAGE 54

43 Encryption:Cipher c = Cipher.getInstance("DES");c.init(Cipher.ENCRYPT\_MODE, keyencryptionkey);byte encrypteddata = c.doFinal(data);Decryption:Cipher c = Cipher.getInstance("DES");c.init(Cipher.DECRYPT\_MODE, keyencryptionkey);byte decrypteddata[] = c.doFinal(encrypteddata); Figure 5.5: Co de Section for Encryption and Decryption Signature ob ject. This is ac hiev ed using the ByteArra y streams and the Ob ject stream classes of Ja v a. When an ob ject has to b e con v erted to a b yte arra y the ByteArra yOutputStream and the Ob jectOutputStream classes are used. A new ByteArra yOutputStream ob ject is created. This ob ject is used as a parameter to initialize the Ob jectOutputStream. The ob ject to b e con v erted to b yte arra y is then passed as a parameter to the writeOb ject() metho d of Ob jectOutputStream class. By doing this the ob ject is con v erted to a b yte arra y and is stored in the ByteArra yOutputStream ob ject. The actual b yte arra y can b e retriev ed from the ob ject using the toByteArra y() metho d. Lik ewise, when the ob ject is to b e constructed from a b yte arra y then the ByteArra yInputStream and the Ob jectInputStream are used. A ByteArra yInputStream ob ject is created using the giv e b yte arra y This ByteArra yInputStream ob ject is used to construct an Ob jectInputStream ob ject and the readOb ject() metho d is used to get the ob ject bac k from the b yte arra y Fig. 5.6 giv es the co de section. 5.1.8 Ob jects Through Net w ork This subsection deals with sending and receiving ob jects through the net w ork. During the authen tication proto col, the certicate ob jects are passed through the

PAGE 55

44 ByteArrayOutputStream baos = new ByteArrayOutputStream();ObjectOutputStream oos = new ObjectOutputStream(baos);oos.writeObject(object);byte objectbytearray[] = new SignKey(serverpublickey, baos.toByteArray()); Object to byte array: ObjectInputStream ois = new ObjectInputStream(bais);EntityKeyPair userkeypair = (EntityKeyPair)ois.readObject(); ByteArrayInputStream bais = new ByteArrayInputStream(decryptedkeypair); Byte array to Object: Figure 5.6: Co de Section for Ob jects to Bytes and Vice-V ersa net w ork from the serv er side to the user side. Generally b ytes are sen t through so c k ets. Ja v a pro vides a go o d abstraction b y allo wing us to directly send ob jects through the net w ork. Con v ersion of ob jects to b ytes and reconstructing them at the other end is tak e care b y JVM. In order to send an ob ject through the net w ork, the ob ject m ust b e Serializable. T o send an ob ject through the so c k et, a handle to the so c k et output stream is required. So c k et class has getOutputStream() metho d whic h returns the handle to the so c k et output stream. The handle obtained is passed to the Ob jectOutputStream ob ject and then the writeOb ject() metho d is used to write the ob ject on to the so c k et output stream, whic h is then sen t through the net w ork. Ob jects whic h are sen t at one end ha v e to b e retriev ed as ob jects at the other end of the net w ork. Instead of handling b ytes, Ja v a allo ws programs to handle ob jects directly in this case also. The handle for so c k et input stream is obtained using the getInputStream() metho d. This handle is passed to the Ob jectInputStream ob ject and then the readOb ject() metho d is used to read the ob ject from the net w ork. The implemen tation detail is sho w in Fig. 5.7.

PAGE 56

45 Send Objects:ObjectOutputStream os = new ObjectOutputStream(socket.getOutputStream());os.writeObject(userprivatekeycert);os.flush();os.writeObject(sitepublickeycertificate);Recieve Objects:InputStream is = socket.getInputStream();ObjectInputStream ois = new ObjectInputStream(is);Certificate sitepblickeycertificate= (Certificate)ois.readObject(); Figure 5.7: Co de Section for Ob jects Through Net w ork 5.1.9 Database Service Secure comm unication service mak es extensiv e use of the database service. When ev er an en try is to b e made in the database while creating a user or creating a site, then a call is made to the database service mo dule. The database service mo dule creates a connection to the database name sp ecied and executes the query giv en and returns the result set. Database mo dule did not supp ort the insertion of ob jects in to tables. SCS needs certicates to b e stored in tables of the database. This functionalit y w as added to the database mo dule in order to store certicates in the tables. Tw o metho ds are added to the database mo dule, whic h basically stores the ob jects in tables and retriev es ob jects from tables. P ostgre SQL database supp orts ob ject storage [10] in tables and ob jects stored are made p ersisten t. P ostgre SQL pro vides t w o distinct w a ys to store binary data. Binary data can b e stored in a table using P ostgreSQL's binary data t yp e b ytea, or b y using the Large Ob ject feature whic h stores binary data in a separate table in a sp ecial format and refers to that table b y storing a v alue of t yp e OID in the table. Using the LargeOb ejct metho d is more suitable for storing certicates as they are v ery large. T o use large ob ject functionalit y the LargeOb ject API pro vided b y P ostgreSQL is used. Access to LargeOb jects m ust b e made within a transaction. A

PAGE 57

46 //All LargeObject API calls must be within a transactionboolean oldstate = db.getAutoCommit();db.setAutoCommit(false);// Get the Large Object Manager to perform operations withLargeObjectManager lobj = ((org.postgresql.Connection)db).getLargeObjectAPI();//Create a new Large objectoid = lobj.create(LargeObjectManager.READ | LargeObjectManager.WRITE);// Open the large object for writeLargeObject obj = lobj.open(oid, LargeObjectManager.WRITE);//Convert the certificate object to a byte arrayByteArrayOutputStream baos = new ByteArrayOutputStream();ObjectOutputStream oos = new ObjectOutputStream(baos);oos.writeObject(cert);byte objectByte[] = baos.toByteArray();//Copy the data from the object to the large objectobj.write(objectByte,0,objectByte.length);//Close the large object and the transaction.obj.close();db.setAutoCommit(oldstate);//Command is the sql INSERT statement in which '?' is present in the place of the certificate valueps.executeUpdate(); PreparedStatement ps = db.prepareStatement(command);ps.setInt(1,oid); Figure 5.8: Co de Section for Inserting Ob jects in T ables transaction m ust b e op ened and this is done using the setAutoCommit() metho d with the input parameter of false Fig 5.8 giv es the co de section to store ob jects. Large Ob ject metho d is used to retriev e an ob ject stored in the database. The oid is used to reference the ob ject stored in the sp ecial table. Fig. 5.9 giv es the co de lev el details. 5.1.10 Securing RMI Calls Implemen tation of this mo dule, w as started b y writing a small application using RMI. Once the RMI application w as dev elop ed, co de for the so c k et factories w ere written. The encryption/decryption part w as left empt y so as to just c hec k whether so c k et factories w ere used prop erly Once this w as v eried, the session k ey w as passed in the constructors and co de to do the encrption/decryption w as in tro duced. There w ere few sp ecic problems encoun tered at this stage of the dev elopmen t pro cess. DES algorithm w as used for symmetric encryption/decryption.

PAGE 58

47 // Open a transaction for accessing large objectsdb.setAutoCommit(false);// Get the large object manager to perform operations withLargeObjectManager lobj = ((org.postgresql.Connection)db).getLargeObjectAPI();\\ Prepare SQL query and executePreparedStatement ps = db.prepareStatement(command);ResultSet rs = ps.executeQuery();while(rs.next()){ // Get the oid reference from the result set oid = rs.getInt(1); // Open the large object for reading LargeObject obj = lobj.open(oid, LargeObjectManager.READ); byte buf[] = new byte[obj.size()] // Retrieve the object using oid and store as byte array obj.read(buf,0,obj.size()); obj.close(); // Convert byte array into object ByteArrayInputStream bais = new ByteArrayInputStream(buf,0,buf.length); ObjectInputStream ois = new ObjectInputStream(bais) return ois.readObject();} Figure 5.9: Co de Section for Retrieving Ob jects from T ables Initially an attempt w as made to encrypt ev ery single b yte of data one b y one. This pro cess failed as DES algorithm exp ected m ultiples of 8 b yte blo c ks to b e encrypted/decrypted. One simple solution arriv ed at initially w as to do an X OR encryption using the session k ey This w ork ed ne as eac h b yte could b e encrypted individually Later m ultiples of 8 b ytes w ere giv en to the metho d to read and write. 5.2 T esting Soft w are engineering p olicies w ere used throughout the dev elopmen t of the SCS mo dule. The spiral approac h w as used, whic h ga v e the opp ortunit y to go bac k and mo dify things. A step-b y-step pro cedure w as follo w ed. W eekly meetings w ere held with the en tire team and brain storming sessions help ed to come up with the requiremen ts of the SCS mo dule. The design of the mo dule w as op en to criticism of the DCS group mem b ers whic h help ed in correcting the faults in the original design.

PAGE 59

48 Dieren t test cases w ere giv en for dieren t scenarios. Initially test cases w ere designed to see if all the functionalities are presen t and then test cases w ere dev elop ed to nd bugs and to break the programs. 5.2.1 T esting Generation of Key Encryption Keys Key encryption k eys are deriv ed from a passphrase. The passphrase is nothing but a ASCI I string. Ev ery user has a passphrase, and hence the k ey encryption k ey generated using this passphrase should also b e unique. In order to c hec k this m ultiple test cases w ere giv en to the program whic h generates the k ey encryption k ey A auxiliary program is used to displa y the k ey generated in base64 format. The program w as run b y giving dieren t ASCI I strings as input to the program and making sure that the same k ey is not generated. Also same passphrase w as giv en as input m ultiple times and it w as made sure that same k ey is generated. This situation o ccurs when the same user logs in again from another mac hine. His k ey encryption k ey m ust b e the same whenev er he logs in unless he c hanges his passphrase. 5.2.2 T esting Signature Generation This mo dule is tested using a k ey pair and a b yte data stream. The ob ject is initialized using the k ey pair. The signature is formed using the priv ate k ey of this k ey pair. The testing is done b y c hec king whether a b yte stream is returned after the signature is formed. Also, the signature formed is correct only if it can b e v eried. The signature is v eried using the public k ey The signature b yte and the public k ey are giv en for v erication. The v erication metho d returns a true if the signature is correct, else false. Hence for testing purp oses the v erication metho d w as used to c hec k the correctness of the signature generation mo dule. 5.2.3 T esting Addition of User This mo dule w as tested b y sim ulating the situation of adding a new user to the system. In the actual system, this is tak en care b y the Conference Con trol

PAGE 60

49 System and the necessary parameters are passed on to the SCS mo dule to tak e care of securit y features. Hence the program w as run b y giving these parameters. The DCSID, user name, passphrase, adminid, admin passphrase and homesite id are giv en as parameters to test this functionalit y The pro cess is tested b y k eeping trac k of the follo wing steps. Key pair should b e generated for the new user. Key encryption k ey should b e generated using the passphrase. Key pair should b e encrypted using the k ey encryption k ey Public k ey certicates should b e formed. All the ab o v e listed items are dump ed on the screen as and when they are created. All the details of user and the certicates are stored in tables in the database. The database is c hec k ed to see whether a new en try has b een made for the new user in the corresp onding tables. The certicates of the user are stored as ob jects. T esting scenario for user c hanging passphrase w as also designed. Once the user c hanged his passphrase new certicates w ere formed and corresp onding tables w ere up dated. 5.2.4 T esting Addition of Administrator Sim ulation of adding an administrator w as made b y running the program with the corresp onding parameters. These include siteid for whic h the admin is added, old administrator's DCSID, old admin's passphrase, new administrator's DCSID, new admin's passphrase and option. This option could b e r etain old admin or delete old admin This mo dule creates a new en try in the administrator information table with the new encrypted v ersion of the k ey pair of the site. T esting w as p erformed b y giving incorrect old admin DCSID. Also new administrator should b e a v alid DCS mem b er and hence test cases w as carried on for these situations also.

PAGE 61

50 5.2.5 T esting Login Proto col T o test the login proto col a serv er program w as needed. F or unit testing purp oses a m ulti-threaded serv er program w as written to receiv e requests from a clien t pro cess and giv e the requests to a request handler b y starting a new thread. This program serv ed as the DCS serv er for authen tication proto col testing cases. The en tire proto col w as dev elop ed in stages with testing at eac h stage. The clien t program receiv es the DCSID and passphrase and generates the k ey encryption k ey The DCSID and nonce are sen t to the serv er. Screen dumps w ere used to c hec k whether the serv er receiv es this prop erly The second stage dev elop ed w as in the serv er side whic h sends certicates of the user to the clien t. T esting w as done to c hec k whether the clien t receiv es the correct certicates and whether it w as able to decrypt the certicates prop erly The third stage dev elop ed w as the resp onse b y the clien t bac k to the serv er and nonce v alues w ere c hec k ed to see the prop er w orking of the program. Correct DCSID and passphrase w as giv en to test whether a user w as able to log in successfully The proto col w as also tested for unsuccessful logins. Improp er com bination of DCSID and passphrase w ere giv en to the clien t program for this purp ose. Also m ultiple users w ere allo w ed to log in sim ultaneously to test the scalabilit y and the robustness of the proto col. 5.3 Summary This c hapter describ ed the imp ortan t asp ects of the implemen tation and testing done for the SCS mo dule. Key implemen tational issues that ma y b e useful for future w ork ers of DCS are dealt in detail. The test cases giv es the oppurtunit y for readers to understand the w orking of the SCS mo dule. Co de sections for generating k ey pairs, k ey encryption k eys, signatures and encryption/decryption metho ds w ere discussed. The pac k ages used to implemen t these features w ere also listed out. JSDK 1.4 w as installed and used. The ja v ax.crypto pac k age and ja v a.securit y pac k age w ere used extensiv ely RSA algorithms w ere used to

PAGE 62

51 generate k ey pairs. DES algorithm w as used for generating symmetric k eys and for symmetric encryption. Signatures w ere stored in the form of certicates. These certicates w ere exc hanged during the authen tication proto col. Addition to the database service mo dule has b een made. It is no w feasible to insert and retriev e ob jects from the database. Ob jects are stored in the form of LargeOb ject t yp e. The datat yp e used to store ob jects w as oid. T est cases help ed in testing the functionalit y and to correct the bugs in the programs.

PAGE 63

CHAPTER 6 CONCLUSION AND FUTURE W ORK 6.1 Conclusion The ob jectiv e of this thesis w as to mak e all the op erations of DCS secure. The securit y goals of the system w ere listed. These include, iden tication and authen tication of en tities of DCS and to mak e all the message transfers with DCS conden tial. The pro cesses within DCS w ere iden tied that required mo dications to ac hiev e the securit y goals. The requiremen ts for mo dications w ere analyzed during the requiremen ts analysis phase. A detailed design of all the features to b e added w ere made with all the requiremen ts in mind. Implemen tation and testing follo w ed the design pro cess. By pro viding an eectiv e authen tication proto col for login, creating a secure DCS c hannel and securely adding sites, users and administrators to a DCS instance, the ab o v e men tioned securit y requiremen ts ha v e b een ac hiev ed. These features ha v e b een successfully implemen ted. The SCS mo dule hence has b ecome an imp ortan t mo dule in the DCS arc hitecture. The authen tication proto col uses cryptographic k eys successfully to main tain a conden tial and m utually authen ticated k ey exc hange. The result of the proto col is that, the en tities b eliev e that the session k ey is go o d and that the other en tit y has the same b elief. Implemen tation of this proto col has resulted in en tities authen ticating themselv es and are able to engage in a secure session without facing the c hallenge of memorizing an asymmetric k ey The secure DCS c hannel ensures that message in tegrit y is main tained. Also b y pro viding securit y for RMI calls DCS users and dev elop ers are still able to enjo y the lev el of abstraction pro vided b y RMI. Securing RMI pro vides abstraction for 52

PAGE 64

53 users and dev elop ers, enabling them to pro ceed with their w ork without thinking ab out securit y asp ects. By implemen ting proto cols to add sites, add users and adding administrators, the system mo v es from one state to another without causing an y hinderence to the normal user. 6.2 F uture W ork 6.2.1 P orting Certicates to X.509 Structure The certicate structure follo w ed during implemenation has almost all the elds required to form a X.509 certicate. With a few mo dications it is p ossible to p ort it to standard formats. Changing it to standard structure leads to v arious p ossibilities. The whole system can b e made w eb-enabled. Users can start using bro wsers to login, instead of using the GUI pro vided b y v arious mo dules. Th us in teraction of DCS with the outer w orld increases with all the required securit y features. 6.2.2 Key Migration Problem The k eys used in the curren t system are RSA k eys for k ey pairs and DES k eys for session k eys. These k eys ha v e sp ecic lengths asso ciated with them. DES k eys are generally 56 bit k eys. As p eople need tigh ter and stronger securit y there ma y b e a need for longer k eys and stronger algorithms. The need for c hange in k ey lengths and algorithms result in k ey migration problem. The system should migrate from one k ey t yp e to another in a smo oth w a y when the c hanges in k ey structures o ccur. A proto col can b e designed for the smo oth transition of the system. The proto col could use v ersion n um b ers for k eys. En tities in the system can c hec k whic h v ersion of k eys is in use curren tly and if there is a c hange then the en tities gradually shift to the new er v ersion.

PAGE 65

54 6.2.3 Considering DCS Instance as En tities The curren t system considers only users and sites as en tities to whic h k eys are assigned. These en tities are authen ticated m utually when they w an t to comm unicate and the comm unication line is made secure. In future a DCS instance itself migh t b e considered as an en tities. A t presen t CCS pro vides joining and splitting con conferences. So DCS instances ma y b e assigned k eys and authen tication and secure comm unication features can b e pro vided. 6.2.4 Re-Authen tication The curren t system authen ticates users only during log in. This can b e extended to other situations where re-authen tication of a user is necessary This situation o ccurs when the user is ab out to p erform a critical op eration for whic h extreme securit y is required. 6.3 Summary With this c hapter, the en tire requiremen ts, design, implemen tation and future w ork for SCS mo dule ha v e b een discussed in detail. F uture w ork ers on DCS can tak e hin ts from the ab o v e men tioned c hapters, con tin ue to w ork on DCS and mak e it a more complete system.

PAGE 66

REFERENCES [1] Amit Vina y ak Date, \Implemen tation of Distributed Database and Reliable Multicast for Distributed Conference System V ersion 2," Master's Thesis, Univ ersit y Of Florida, 2001. [2] Sw ati P atanjali Sh ukla, \Notifcation Services in a Distributed Conference System," Master's Thesis, Univ ersit y Of Florida, 2000. [3] J. Guru, \F undamen tals of RMI" July 2001, h ttp://dev elop er.ja v a.sun.com/dev elop er/onlineT raining/rmi/RMI.h tml, 06/25/2002. [4] William Stallings, Cryptograph y and Net w ork Securit y: Principles, Second Edition, New Jersey 1998. [5] Mukul P areek, \Cryptograph y{A Primer", 2000, h ttp://www.fnanceoutlo ok.com/cryptograph y .h tml, 06/30/2002. [6] Ric hard Newman and Stev en J. Green w ald, \DCS V ersion 2 Requiremen ts Sp ecifcation," Departmen t of Computer and Information Science and Engineering, Univ ersit y Of Florida, 1993. [7] Ric hard Newman, Lisa Dyson and Osw ald Sabina, \Analysis of the DCS.v2 Authen tication Proto col," Departmen t of Computer and Information Science and Engineering, Univ ersit y Of Florida, 1999 [8] Mic hael Burro ws, Martin Abadi and Roger Needham, \A Logic of Authen tication," Digital Systems Researc h Cen ter, P alo Alto, CA 1990. [9] Sun Microsystems, 1999, \Creating a Custom RMI So c k et F actory" h ttp://ja v a.sun.com/pro ducts/jdk/1.2/do cs/guide/rmi/rmiso c k etfactory .do c.h tml, 08/17/2001. [10] Jo e Shev eland, 2002, \P ostgreSQL JDBC Primer," h ttp://www.jelite.com/pgprimer/blobs.jsp, 05/20/2002. 55

PAGE 67

BIOGRAPHICAL SKETCH Ra vic handran Aringunram w as b orn in Chennai, India, in the mon th of July 1979. He earned his high sc ho ol diploma from Vidy a Mandir senior secondary sc ho ol, Chennai. He studied for his undergradute degree in Shanm ugha College of Engineering, Bharathidasan Univ ersit y T ric h y He graduated in June 2000 with a Bac helor of Engineering degree with distinction. He immediately w en t on to pursue his master's at the Univ ersit y of Florida, Gainesville, in the feld of computer engineering. 56


Permanent Link: http://ufdc.ufl.edu/UFE0000505/00001

Material Information

Title: Secure Communication Services for Distributed Conference System
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000505:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000505/00001

Material Information

Title: Secure Communication Services for Distributed Conference System
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000505:00001


This item has the following downloads:


Full Text











SECURE COMMUNICATION SERVICES FOR DISTRIBUTED CONFERENCE
SYSTEM















By

RAVICHANDRAN ARINGUNRAM


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002

































Copyright 2002

by

Ravichandran Aringunram


































I dedicate this work to my parents, family and friends.















ACKNOWLEDGMENTS

I wish to offer my highest gratitude to Dr. Richard Newman for providing me

with guidance and motivation to complete this thesis. I also thank Dr. Jonathan

C.Liu and Dr. Randy Chow for serving on my thesis committee. I feel very proud

to have people of such stature related to my thesis work.

I would like to express my sincere thanks to all the DCS group members. I

would like to thank Vijay Manian and Aparna Kakarparti, with whom I worked

closely and shared my ideas.

Last, but not least, I wish to express my thanks to my parents, family, and

friends who have always been supportive of me and always encouraged me in all my

endeavors.















TABLE OF CONTENTS

page

ACKNOWLEDGMENTS ................... ...... iv

LIST OF FIGURES ................... ......... viii

A BSTRACT . . . . . . . . . x

CHAPTERS

1 INTRODUCTION ........................... 1

1.1 Overview of Distributed Conference System ............ 1
1.1.1 Conference Control Module ......... ........ 1
1.1.2 Database and Communication Module ............ 1
1.1.3 Access Control Module ......... ........... 2
1.1.4 Notification Module ........... .......... 2
1.1.5 Decision Support Module ................. 2
1.1.6 Secure Communication Module ....... . . 2
1.2 Overview of Secure Communication Services .. . . 4
1.3 Definitions ................... .... 5
1.4 Organization of Chapters .................. ...... 6

2 SURVEY OF RELATED WORK .................. 7

2.1 Remote Method Invocation .................. 7
2.1.1 RM I Architecture .................. ..... 7
2.1.2 Layers of RM I .................. .... 9
2.2 Network Security .................. ........ .. 10
2.2.1 Model of Network Security ................. .. 10
2.2.2 Conventional Encryption System . . ..... 10
2.2.3 Secret-Key Encryption ............ ... .. .. 11
2.2.4 Public-Key Crypt...,i.,'lih\ .... . . 12
2.2.5 Public Key Encryption Scenario .............. .. 13
2.2.6 Symmetry-key vs Public-key encryption . .... 13
2.2.7 Digital Signature .................. .. 14
2.2.8 Digital Certificates .................. .... 15
2.3 Summary .................. ............ .. 16









3 REQUIREMENTS SPECIFICATION .........

3.1 Introduction . . . . . . . .
3.2 Security G oals . . . . . . . .
3.3 Processes within DCS .........................
3.3.1 Dynamic Processes .. ..................
3.3.2 Nearly Static Processes .. ................
3.3.3 Instantiation and Termination of Servers .. ........
3.3.4 Creation and Destruction of Sessions .....
3.3.5 Transmission and Reception of Messages .. ........
3.3.6 Creation and Deletion of Sites .. .............
3.3.7 Adding New Administrator to Existing Site .........
3.3.8 Creation and Deletion of Users .. .............
3.4 Summary ...............

4 D E SIG N . . . . . . . . .


4.1 Introduction . . . . . .
4.2 Design Level Choices .. ...............
4.3 User Authentication and Creation of a Secure Session
4.3.1 Certificates . . . . .
4.3.2 Authentication Protocol .. ...........
4.3.3 User Login Options .. ............
4.4 New Site Creation .. .................
4.5 Adding a New Administrator to a Site .. ......
4.6 Creating a New User .. ...............
4.7 Securing Transfer of Messages Through Network .
4.7.1 Procedure . . . . .
4.7.2 Pseudocode and Explanation .. ........
4.8 Summary ...........


5 IMPLEMENTATION AND TESTING .. ................

5.1 Im plem entation . . . . . . .
5.1.1 Key Pair Generation ..........
5.1.2 Generation of Key Encryption Key ......
5.1.3 Generation of Session Key .. ..............
5.1.4 Digital Signature ...........
5.1.5 Digital Certificates ..........
5.1.6 Encryption and Decryption .. ...............
5.1.7 Conversion of Objects to Byte Array .. ...........
5.1.8 Objects Through Network .. ..............
5.1.9 Database Service .. ... .. .. .. .. ... .. .. ..
5.1.10 Securing RM I Calls .. ..................
5.2 T testing . . . . . . . . .
5.2.1 Testing Generation of Key Encryption Keys .........









5.2.2 Testing Signature Generation ................ .. 48
5.2.3 Testing Addition of User .................. .. 48
5.2.4 Testing Addition of Administrator . . ..... 49
5.2.5 Testing Login Protocol ............. .. .. 50
5.3 Summary .................. ............ .. 50

6 CONCLUSION AND FUTURE WORK ................. .. 52

6.1 Conclusion .................. ............ .. 52
6.2 Future W ork ................ .... .. .. ..... 53
6.2.1 Porting Certificates to X.509 Structure . ... 53
6.2.2 Key Migration Problem ............ .. .. .. 53
6.2.3 Considering DCS Instance as Entities . . 54
6.2.4 Re-Authentication .................. .. 54
6.3 Summary .................. ............ .. 54

REFERENCES ................... ... ... ........ .. 55

BIOGRAPHICAL SKETCH .................. ......... .. 56















LIST OF FIGURES

Figure page

1.1 DCS System Architecture .................. ...... 3

2.1 RM I Basic Structure .................. .. 8

2.2 RMI Client Server Architecture .................. 8

2.3 Layers of RMI architecture .................. ..... 9

2.4 Conventional Encryption System ................... .. 11

4.1 State Digram for Authentication Process ............... .. 24

4.2 Authentication Protocol .................. ..... .. 26

4.3 UserInterface . . . . . . . .. .29

4.4 User Login From Other Sites .................. .. 30

4.5 Code Section for SecureClientSocketFactory . . ...... 34

4.6 Code Section for SecureServerSocketFactory . . ...... 34

4.7 Code Section for SecureSocket .................. ..... 35

4.8 Code Section for EncryptedOutputStream .............. .. 36

4.9 Code Section for DecryptedInputStream ............... .. 36

5.1 Code Section for Key Pair Generation ................. .. 39

5.2 Code Section for Key Encryption Key Generation . .... 39

5.3 Code Section for Signature Generation ................ .. 40

5.4 Code Section for Signature Verification ................ .. 41

5.5 Code Section for Encryption and Decryption . . 43

5.6 Code Section for Objects to Bytes and Vice-Versa . .... 44

5.7 Code Section for Objects Through Network . . ..... 45

5.8 Code Section for Inserting Objects in Tables . . ..... 46









5.9 Code Section for Retrieving Objects from Tables . . .... 47















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

SECURE COMMUNICATION SERVICES FOR DISTRIBUTED CONFERENCE
SYSTEM

By

Ravichandran Aringunram

December 2002

Chair: Richard E. Newman
Major Department: Computer and Information Science and Engineering

Network Security has been the mantra of the last decade with the growth of

the Internet. Security has evolved from the most basic forms like photo identifi-

cation, signatures, and passwords to the most advanced levels like cryptography,

digital signatures, certificates and bio-identification, which includes voice recogni-

tion, retina matches, etc.

Distributed Conference System v.2(DCS) is being developed in the University

of Florida under the guidance of Dr. Richard Newman. DCS supports distributed

collaborative work in which important information may be transferred over the

network by users. Security issues become important as more people start using the

system from different domains. Basic security goals like confidentiality, authenticity

and integrity had to be incorporated into the system. This thesis deals with the

design and implementation of Secure Communication Services (SCS) to provide

such features.

SCS is responsible for providing cryptographic keys to the users and site

servers. Also SCS performs the functions of mutual authentication between users









and sites and creating a secure session. Authentication is performed using a

protocol that involves distribution of session key and private key to the user by

a trusted server with which it communicates. Due to the complexity of handling

asymmetric keys, the users are allowed to store the keys in a homesite. SCS

provides the service of encryption and decryption of data sent through the network.

All message transfers over the network are carried out by RMI calls. SCS plays

the important role of encrypting and decrypting the data sent by RMI calls at

the socket level. Encryption and decryption are done using the DES algorithm.

This is achieved by using custom socket factories. SCS also performs house-

keeping activities like generating RSA key pairs for users and sites, creating digital

signatures, certificates, and securely adding sites and new administrators to sites in

a DCS instance.

The above mentioned functionalities have been implemented and are presented

as a separate module to DCS v.2. Thus SCS provides the important security

features needed for distributed collaborative work.















CHAPTER 1
INTRODUCTION

1.1 Overview of Distributed Conference System

Distributed computing forms the backbone of the architecture used for sharing

data. A conference system plays an important role in the life of people who want

to share data across the globe. Distributed Conference System (DCS) grew out of

the desire to incorporate joint control over shared environments. The Distribted

Conference System is a package that provides infrastructure for real-time co-

operative work. DCS is an example of distributed system designed to support

conferencing over wide area network (WAN). This system allows geographically

separate users to collaborate in the preparation of documents, reports, software etc.

The various modules of DCS are described briefly in the following subsections.

1.1.1 Conference Control Module

This module is responsible for the creation process or the boot up process

of DCS. It's duties include initialization of other modules, creating conferences,

adding users, merging conferences, deleting conferences, removing users, providing

GUI, etc.

1.1.2 Database and Communication Module

This module [1] provides the database services for DCS. A distributed

database is created and maintained by this module. Integrity and consistency

of distributed databases are maintained by this module. Reliable communication is

provided by the reliable causal order multicast. All commands from one host are

executed in order at all sites participating in that conference.









1.1.3 Access Control Module

This module deals with the access control issues for the conference. All

subjects in DCS are bound to certain roles. Each role has its own capabilities. A

subject can perform an action on an object only if the role to which he is bound

permits him to do so. A subject can bind to a number of roles, but only one at a

time. This module maintains an access control matrix to facilitate access control

decisions.

1.1.4 Notification Module

Notification mechanisms [2] are used to inform agents about different events

happening in the system; these are occurrences of observable activities. This

module is responsible for notifying users of events such as user logs in, log out,

joins a conference, leaves conference, etc. Various means like email, zwrite, mailbox

are used to notify the users.

1.1.5 Decision Support Module

Decision Support System(DSS) facilitates the solutions of problems by a group

of people who have joint responsibility of reaching the decision. A voting mecha-

nism is one of the tools of DSS. It provides online voting and has an automated

vote collection mechanism. The system provides users with different voting meth-

ods. The system also provides an interface that allows services to initiate decision

process for conference control activities.

1.1.6 Secure Communication Module

Secure communication services is responsible for authentication of users,

creation of keys, certificates and providing secure communication channel. This

thesis concentrates on the secure communication services.

All these modules interact and communicate with each other as show in

the figure below. In the current version of DCS all the services are implemented




















































Figure 1.1: DCS System Architecture









using Java, which helps in portability and integration of the modules on various

platforms.

1.2 Overview of Secure Communication Services

The need for information security has undergone tremendous changes during

the last few decades. Major advance was made when networks were introduced and

data transmitted through the networks. Network security measures were need to

protect the data during transmission. The Secure Communication Services provide

computer and network security for the users of DCS. Computer and network

security research and development have focused on three or four general security

services that are need for protecting data. The security services are listed below

Ci'fi,, ,tilil;fi Ensures that the information in a computer system and
transmitted information are accessible for reading only by authorized parties.

Authentication: Ensures that the origin of a message is correctly identified,
with an assurance that the identity is not false.

Iii if, hi Ensures that only authorized parties are able to modify computer
system assets and transmitted information.

Nonrepudiation: Requires that neither the sender nor the reciever of a
message be able to deny the transmission.

SCS is responsible for providing all these features. To enforce the important

security properties (such as confidentiality, authentication and integrity) of com-

puter and network systems, it is necessary to establish the identity of the entities

of the system. The entities of the system can be users and hosts or servers. The

identity of the entities should be done reliably, that is, it should be authenticated.

DCS poses a greater challenge since entities communicate with messages and hence

both must establish their identity and maintain confidentiality. In DCS identity

is first established and usage of cryptography provides the confidentiality and

integrity. The users of DCS roam about and this poses an even bigger challenge to

meet the security goals.









The Distributed Conference System version two is intended to provide dis-

tributive collaboration across multiple domains. Hence a strong authentication

process is necessary in order to provide the basic security features and properties.

Moreover the security services should be able to handle roaming users. This makes

it more challenging as the users do not keep the keys with them when they roam.

Hence there should be a home domain where the users can store their keys.

In order to provide the authentication, confidentiality and integrity features an

infrastructure should be maintained that handles key creation and maintenance.

Also creation and maintenance of certificates is needed. The infrastructure should

be created and updated whenever users are added or sites are added or site

administrators are added. Entity identity is established and authenticated using

this infrastructure.

1.3 Definitions

This section gives a brief definition of certain terms that are used frequently in

the coming chapters.

E, tf,, A subject, object or application. An entity can only be one of these at
any given moment.

Subject The class of active entities that can act on objects. A Subject is
always bound to a role.

Objects The class of passive entities that can be acted upon by subjects.
Objects can contain, and can be contained by, other objects.

Conference A tuple consisting of subjects, objects, applications, roles and
allowable subject-role bindings.

Keys A random number generated by a given algorithm which has a property
of encrypting and decrypting data.

Session key A shared symmetric key between two entities used for encrypting
and decrypting messages for a particular session.


* Key Pair A pair of public and private key for an entity.









Public Key A part of a key pair that is made public to everyone

Private Key A part of a key pair that is kept secret by the owner of the key
pair

Passphrase A string which is kept secret by an entity and is used to
authenticate a person.

Di',itdl S;'i',tifre Produces the same effect as a real signature; it is a mark
that only a sender can make, but others can easily recognize as belonging to
the sender. Just like a real signature, a digital signature is used to confirm
agreement to a message

RMI Remote Method Invocation.

1.4 Organization of Chapters

The next chapter deals with the previous work done in the related areas. It

discusses about the encryption, keys, certificates and RMI. The third chapter lists

the requirements of the Secure Communications Services module. It provides with

an exhaustive list of requirements. The fourth chapters deals with the detailed

design of the SCS module. It gives a vivid description of the authetication protocol

and creation of secure channel for communication. The fifth chapter deals with the

implementation details of the module. It also lists the various test cases which were

give during the testing phase. The final chapter summarizes and concludes and it

also discusses the future work which can be done in this area.















CHAPTER 2
SURVEY OF RELATED WORK

This chapter gives a list and describes the relevant topics and background

work done before designing SCS module. Initial section deals with the detailed

description of RMI. The latter sections deals with important topics in network

security and gives a brief description of each topic. With the study of these topics

and relevant information, the requirements and design of SCS module is discussed

in the following chapters.

2.1 Remote Method Invocation

Remote Method Invocation (RMI) was introduced to elavate network program-

ming to a higher plane and to provide abstraction to the users. The primary goal

of RMI is to allow programmers to develop distributed programs with the same

syntax and semantics used for non-distributive programs. In order to achieve this,

Java objects and classes on a single machine are mapped to a model were classes

and objects work on a distributed environment.

2.1.1 RMI Architecture

RMI architecture [3] describes how objects are used in distributed environ-

ment, parameter passing, exceptions, memory management and how return values

are managed.

Interfaces: RMI uses an important property: the definition of behaviour and the

implementation of that behaviour are separate concepts. The code which defines

the role of a function and the code that implements the role are separate and are

run on different machines. This fits correctly in the architecture of distributed

environment. Definition of a remote service is coded using Java interface. The

implementation of the service is coded in a class. This can be seen in Fig 2.1 Java











CLIENT PROGRAM


SERVER PROGRAM


IMPLEMENTATION


INTERFACE


Figure 2.1: RMI Basic Structure


SERVICE


CLIENT

SERVICE PROXY


Figure 2.2: RMI Client Server Architecture


interface does not contain any executable code. There are two classes that imple-

ment the interfaces. One class gives the implementation of the functionality of the

remote service and it is run on the server side. The other class acts as a proxy for

the service and it runs in the client side. This is shown Fig 2.2. The client program

just calls methods on the proxy object and RMI passes on this request to the re-

mote machine and gives it to the implementation part. Return values are sent back

to the proxy and then they are given back to the client program that made the call

initially.










SERVER PROGRAM
CLIENT PROGRAM




SKEL & STUB SKEL & STUB
RMI REMOTE REFERENCE
SYSTEM REMOTE REFERENCE REMOTE REFERENCE

TRANSPORT LAYER


Figure 2.3: Layers of RMI architecture


2.1.2 Layers of RMI

RMI is built from three layers. The first layer is the Stub and Skeleton layer,

the second layer is the remote reference layer and the third layer is the transport

layer. This is shown in Fig.2.3.

Stub and skeleton layer. A stub and a skeleton class if generated whenever

an RMI application is developed. The stub class plays the role of the proxy and

the remote service implementation class plays the role of the real object. The

skeleton class plays the role of a helper class for the RMI. The skeleton knows how

to communication with the stub. The skeleton carries on the conversation with the

stub.

Remote reference layer. The remote reference layer is responsible for the RMI

connection. This layer provides an object that acts as a link to the remote service

implementation. RMI provides one way for clients to connect to the remote service.

A unicast point-to-point connection is made. The remote service is instantiated

and is registered at a well known agent. A well known agent is rmiregistry. This

should be done before the client makes a call to the remote service.

Transport layer. The transport layer is responsible for providing connection

between different machines. All the connections established by this layer are

stream-based network connections that use TCP/IP.









2.2 Network Security

2.2.1 Model of Network Security

In this section a model of a network security system is explained in general

terms[4]. Each aspect of this model is discussed in detail in the following sections.

Security is needed where it is desirable to protect the information transmission

from an intruder or an outsider who may present a threat to confidentiality,

authenticity, etc. All security models have two components:

1. A security related transformation on the data to be sent through the network.

2. A secret information shared by the communicating entities. This could be a
secret symmetric key or a secret function.

Transformation could be achieved by encryption or addition of some code

based on the sender for identification purposes.The secret information could be

a secret symmetric key or a secret function. In some cases a trusted third party

might be needed for mediation. The third party may be reposnsible for distributing

the secret information or may arbitrate disputes between the entities. The general

model has four steps in designing the security service:

1. design an algorithm for doing transformation of the data;

2. generate a secret information to be used;

3. develop methods for the distribution and sharing of the secret information;

4. determine a protocol to be used by the two entities that makes use of the
algorithm and the secret information to achieve a security service.

2.2.2 Conventional Encryption System

The above figure illustrates the conventional encryption model. The original

message is referred to as plaintext. Plaintext is converted into what appears to be

random nonsense and this is known as ciphertext. The encryption process is done

using an algorithm and a key. The key is a value independent of the plaintext. The










X Y DECRYPTION
ENCRYPTION X
MESSAGE DESIGNATION
ALGORITHM ALGORITHM



K K



KEY SOURCE



Figure 2.4: Conventional Encryption System


algorithm will produce a different output depending on the specific key being used

at that time.

Once the cipher text is formed it is transmitted through the network. On the

destination side the cipher text is transformed back to the original plaintext by

using a decryption algorithm and the same key that was used for encryption.

Cryptographic systems are classified under three different contexts

1. Ti,"' of tr', if' i ni al, used for enc ,i1 Jfiti or tr'', If' i n,/ 'l; All encryption
algorithms can be divided into two categories: substitution, in which each
element in the plaintext is mapped to another element and transposition, in
which elements in the plaintext are re-arranged.

2. The number of keys used. If both sender and the receiver use the same key,
then the system is referred to as symmetric, single key or secret key system or
a conventional encryption system. If the sender and the reciever each use a
different key the the system is referred to as asymmetric, two key or
public-key encryption system

3. Processing of Plaintext. A block cipher processes the input one block of
elements at a time. A stream cipher processes the input elements
continuously.

2.2.3 Secret-Key Encryption

Secret-key encryption or symmetric-key encryption, or conventional cryptog-

raphy uses one key for both encryption and decryption process. Data Encryption


Standard (DES), is an example symmetric encryption.









Symmetric key cryptography [5] is very straightforward. A key is used to

encrypt the data and the same key is used to decrypt the data on the receiver's

end. The security depends on the strength of the key and the strength of the

encryption algorithm.

Since the same key is used in both the sender's and receiver's side, distributing

this key becomes a major problem in symmetric encryption systems. The question

is how do you keep the key safe with the sender and transmit it securely to the

receiver. If there is a way by which keys can be transmitted securely then the same

method can be used to transmit data instead of using a key and the encryption

algorithm. If the key is shared between more than one person, then there is no

way to establish the authenticity of the originator. Any person who knows the

secret key can generate the message using that key. These problems led to the

development of Public-key cryptography.

2.2.4 Public-Key Crypt ,i. 'r.lhi

Public-key cryptography was introduced in the late 70's. A pair of keys, is

used to encrypt and decrypt messages. Each pair of keys designated to an entity

consists of a public key and a private key. The public key is made public by

distributing to all the entities of the system. The private key is kept as a secret

and hence only the owner of the private key has knowledge of it. The public and

private key of a particular pair uniquely complement each other.

Public key cryptography is useful and different because of the property that

data encrypted with a private key can only be decrypted with the corresponding

public key. Likewise, data encrypted by the public key can only be decrypted by

the corresponding private key. Another important feature of public key cryptogra-

phy is that all the communication involves only the public keys and no private key

is ever shared. The size of the key usually gives the strength of the key. The larger

the key size, more is the security.









The public key is derived mathematically from the private key. The keys are

mathematically related to each other. RSA (Rivest, Shamir, Adleman) is one of

the most widely used public key encryption methods. The key pair is derived using

the concepts of big prime numbers and factorization concepts. Even though the

two keys are mathematically dependent it is extremely diffuclt or computationally

infeasible to derive the private key from the public key as far as we know.

2.2.5 Public Key Encryption Scenario

Let us consider three entities A, B and C of a particular system. Each entity

has a key key pair which is of the form K. and K1-' where Kx is the public key and

Kx-1 is the private key of entity X. Suppose A and B want to have a secret session

between them and they do not want C to know about their conversation. This can

be achieved in the following way

A will send the message to B encrypted using B's public key.
Let Ml be the message. The cipher text is {M1}KB

The cipher text is sent to B. When B receives the message then he will
decrypt the ciphertext using his private key.
{{M1}KB}KB1} MI
This according to the property that which states that data encrypted by
public key can be decrypted only by the corresponding private key. Thus B is
able to retrieve the plaintext from the message it got from A.

The above explanation shows that A can send an encrypted message to B and
B can retrieve the original message successfully. It has to be proven that C
cannot listen to A and B's conversation. Suppose C gets a copy of the cipher
text {M1}KB. C cannot decipher anything from this ciphertext. He has to
have a key to decrypt this message. The keys which C has are his own public
and private keys, A's public key and B's public key. The message can be
decrypted only by B's private key. Thus with the keys C has he cannot
retrieve the original message.

2.2.6 Symmetry-key vs Public-key encryption

Both conventional and public-key encryption systems have their pros and

cons. Conventional encryption is very simple but key distribution is the major

disadvantage. Key could be exchanged between two entities in person, which solves









the key distribution problem. This is can be done because, key distribution is not a

time critical problem. But, the same thing cannot applied to messages, as messages

has to reach the destination at the right time. Public key crypto systems avoid the

issue of key distribution but this comes with a price. The problem associated with

this system, is the association of keys with entities in the system. The processing

power needed to encrypt and decrypt messages is very high when compared to

conventional crypto systems.

2.2.7 Digital Signature

Digital signatures are similar to hand signatures. Digital signature au-

thenticate a message and provide the feature of non-repudiation. Digital signa-

ture(ideally) prevents the sender from later denying that he did not send the

message. Digital signatures are obtained using public key cryptography. A digital

signature can be described as follows. Consider two entities A and B and let each

one have their own key pair. If A wants to send a message to B and sign it, he will

do the following:

Let the message be M. A encrypts the message M using his private key and it
is represented as {M}KA1. This is the digital signature.

A sends the original message along with the signature to B.

B decrypts the signature using A's public key.

B checks whether the original message matches with the message in the
signature

If they match then it is proved that A has sent the message and it proves the
identity of the sender. Only A could have generated a corresponding
signature to the message M because only A has his private key. Hence
message authentication is done.

If A later denies that he did not send message M to B, then B can fight back
saying that since only A has access to his private key only A could have
generated a message and the corresponding signature. Hence digital
signatures provide the feature of non-repudiation.









Since a digital signature usually uses hashing on the message, the signature

generated would be different for each message. Hence it is not possible to use

someone else's signature and attach it to the message. If this is done then when the

signature is original the messages will not match.

Digital signatures are superior to handwritten signature in certain ways, that

it cannot be counterfeited and also in that it applies to the whole message. In the

case of handwritten signature the content of the message can be later changed even

after the signature has been made. But digital signature does not imply that, the

person who signed the document was ]1i\ -iP .,lly present when signature was done.

The security of the digital signature is dependent on the security of the private key.

If the private key falls in the hands of a malicious person then digital signatures

can become a nightmare. Another key issue that could limit the practical use of

digital signature is that the public keys for a person upon which another relies may

have been falsely created. This is called man-in-the-middle attack. One may create

a private key and circulate the corresponding public key as belonging to someone

else. If another person relies upon this false public key then he might actually end

up communicating with the wrong person. To avoid this digital certificates are

needed.

2.2.8 Digital Certificates

Public key ci \t i -i-\-th rIi- can be effectively put into practical use only if it

made sure that public keys are distributed securely. The sender who encrypts

using public key or reciever who decrypts using the public key (in case of digital

signatures) should be sure that they are using the public key that corresponds to

the correct person. Exchange of public keys is an important issue and the way it is

done is through digital certificates.

A digital certificate is provided by a third party and it says that a public key

belongs to this corresponding owner. A digital certificate contains the public key,









name of the person that the key belongs to, and a digital signature. The certificate

may also include the certifier, certificate number, etc. The purpose of the digital

certificate is to give an assurance to a person by a third party. The third party

vouches for the authenticity of an entity. Usually the third party who does this is

called as a Certification Authority (CA). Another important thing about digital

certificates is that they allow you to establish the identity of the person with who

you are dealing.

2.3 Summary

The study of relevent materials like RMI and topics in network security is

very important for the work done in this thesis. The three layers of RMI nameley,

stub and skeleton layer, Remote reference layer and the transport layer were

explained in detail. Also a detailed explanation of how sockets are use was give. A

general model of network security was explained. Digital signatures, certificates,

conventional crypto systems and public key crypto systems were discussed in detail.

With these topics in mind the requirements and design of the SCS module was done.

SCS module requires an extensive use of the study done in this chapter.















CHAPTER 3
REQUIREMENTS SPECIFICATION

3.1 Introduction

SCS is a -,ii -\-t' il" that is responsible for providing the features necessary,

for the secure operation of DCS. The initial part of this chapter deals with the

security goals and policies of DCS. The latter part describes the processes in DCS

that need to be considered for dealing with security requirements and the possible

mechanisms used to attain the specified security goals. Refer to Newman and

Greenwald [6] for the complete set of requirements for the entire DCS system.

3.2 Security Goals

SCS has to provide mechanisms to achieve the security goals. These features

must be added to the existing DCS by SCS, as an individual -ill i-.-ti iii and by

interacting with the existing -l-1.-\'t. tiir of DCS. The important high level security

goals can be listed as follows.

Identify and authenticate entities of DCS, namely users and sites.

Message transfers in DCS must be done confidentially and means to identify
the senders and recipients must exist.

The following sections gives a list of processes occurring within DCS, the

necessary features that are to be added to the existing processes to meet the

security goals and the possible mechanisms to attain the specified requirements.

3.3 Processes within DCS

All activities going on within DCS fall in one of the two categories namely

dynamic processes and nearly static processes.









3.3.1 Dynamic Processes

These are processes that takes place very often. These processes change the

security state of the system. These processes are listed below.

1. Instantiation and termination of servers.

2. Creation and destruction of sessions.

3. Transmission and reception of messages.

3.3.2 Nearly Static Processes

These processes occur less frequently and do not affect the state of the system.

They cause some changes only to the database table. List of processes to be

considered are listed below.

Creation and deletion of sites.

Adding new administrator to existing site.

Creation and deletion of users.

The following three sections discusses about the security requirements for

dynamic processes.

3.3.3 Instantiation and Termination of Servers

Instantiation and termination of servers must be done only but administrators.

The administrator and the server must be able to authenticate to other existing

servers in the system. The new server must be able to join into the existing system

by authenticating itself and must be in a position to authenticate others. The new

server must be able to access tables and send messages confidentially and with

integrity.

3.3.4 Creation and Destruction of Sessions

A session is created before any communication between the users and the sites.

To meet the security goals, users and sites must be identified and authenticated.

SCS is responsible to provide the features necessary to strongly authenticate parties









at both ends and to start a secure session. This may require a client process to act

on behalf of the user and a protocol to establish mutual authenticity. Once mutual

authenticity is established the user and the site must be able to communicate

securely. SCS is responsible to protect the confidentiality and the integrity of

messages after a secure session is established.

3.3.5 Transmission and Reception of Messages

A DCS instance has multiple sites and message or information needs to

be transferred from one site to another over the network. One example of such

information is propagation of updates to the tables maintained by the distributed

database service. Each table has a replica in every site and any update to an entry

in the table has to be reflected in all the copies so that the database is consistent.

This propagation is done by RMI calls by the database service. Likewise any

communication of sites over the network is done by RMI calls. To incorporate

confidentiality and integrity in message transfers is one of security goals. SCS

takes the responsibility of providing confidentiality and integrity in message passing

through RMI calls. To provide this feature all RMI calls must be made secure.

Encryption and decryption of data sent through RMI calls is one of the ways to to

meet the security goals .

The following three sections discusses the security requirements for nearly

static processes.

3.3.6 Creation and Deletion of Sites

New sites are added to the system by the CCS in the current system. Each

site is uniquely identified by the site id. As in the case of users, sites also require

a stronger identification scheme. Associating sites with key pair is one of the ways

to achieve stronger identification. A new site must be created by an administrator.

The administrator must be an authorized person and so he should be a valid DCS









user. When the admin creates the site, he must also run the utility, that creates

the key pair for the new site.

Once the site keys are formed there must be a way to make the new site to

join the DCS instance. When the new site enters the DCS instance the transition

must be smooth. In no case there must be a any halt in the normal operation of

the rest of the DCS instance. The certificates of the new site must be formed.

The certificate must be distributed to the rest of the sites in the DCS instance so

that they can identify and trust the new site. Also the certificates of the other

sites must reach the new site eventually. These communications in no way should

hinder the normal operation of DCS. A site can be deleted from the system. Only

administrators must be allowed to delete sites from the system. Whenever a site

is deleted SCS is responsible for d. -t'. vii-;_ the certificates and key associated with

site.

3.3.7 Adding New Administrator to Existing Site

A site may require a new administrator for different purposes. Hence there

must be provision to create new administrators for a site and strongly associate the

new admin with the site. There may be situations in which a site might require

more than one administrator. Hence options must be available to add a new

administrator and also make multiple administrators options open. When a new

admin is added, he must be authorized first. Utilities must be available to check

the new person's credibility, by checking his certificates and making sure that they

are not corrupted and are valid. When multiple administrators are not needed,

the old admin must be removed, once the new admin is included into the system.

When multiple administrators are allowed then all administrators must have equal

authority over the site. Each of them must be able to perform all the operations

the other administrator can perform. Any administrator must be able to start









or terminate servers in such a way that it can authenticate itself to other servers

within its site and to other sites.

3.3.8 Creation and Deletion of Users

Users are added and deleted by the CCS. Users are identified by a unique

DCSID and a passphrase in the current system. A stronger identification scheme

is required. One of the ways of achieving the requirement could be done by

associating every user in DCS with a unique key pair. SCS is responsible creating

the key pair and associating the key pair with a corresponding user. Since keys are

long and difficult to remember, there must be ways to store the keys and retrieve

the keys in a secure fashion. Whenever a user is removed from the system SCS

must take the responsibility of d. -t',. i\i-;, the key pair associated with the user.

User must be able to login at any DCS site in the instance, and desirable to be able

to login from any location with DCS client.

3.4 Summary

The main security goals have been listed and the processes that are to

be modified to meet the security requirements are identified. The goal was to

identify and authenticate entities of the system and to make all message passing

confidential. Processes were classified as dynamic processes and nearly static

processes. Each process was analysed and the features to be added were recognized.

The requirements that are to be met by occurrence of each event have been

discussed in detail and possible ways to achieve the requirements have also been

pointed out in this chapter.















CHAPTER 4
DESIGN

4.1 Introduction

In this chapter the detailed design aspects of the SCS module are discussed.

A detailed description of the user login protocol process is explained. This chapter

also describes the structure of the necessary certificates, method of storage and the

usage of certificates in the protocol. Latter sections explain the steps to be taken

in terms of security features during new user creation, new site creation and new

admin creation. The last section of the chapter deals with the steps involved in

securing RMI calls which in effect provides a secure DCS channel.

4.2 Design Level Choices

Design level choices were made to meet the requirements and the structure of

the existing system in mind. The authentication protocol was designed in order to

give a lot of flexibility to the user. The design of the protocol was made in such a

way that a roaming user need not have to remember a long key pair. Certificates

were designed to keep the process of authentication simple, and with minimum

number of handshakes. Customizing socket factories of RMI made message passing

confidential. Certificates are formed for both users and sites. Hence the below

mentioned protocol and securing RMI calls are necessary to create a secure session

between a user and a site, instead of using SSL. SSL provides authentication

between servers and not between users and servers. In the case of SSL, a malicious

user can use the system after the servers are authenticated. PKI could not be

used due to its inherent nature. PKI used a hierarchical structure which was not

suitable to the DCS architecture. Also PKI uses revocation lists which is not

applicable to DCS certificates. Moreover the financial aspect of implementing PKI









proved to be another hinderence in using PKI. Using smart-cards to store keys

was one of the options discussed. This increases the burden on the user, as he

has to carry the smart-card with him wherever he goes and has to find a suitable

hardware system to install the smart-card. With all these different issues in mind

the most suitable protocol for DCS was designed and implemented.

4.3 User Authentication and Creation of a Secure Session

As described in the requirements chapter, the main aim of this protocol is to

distribute a session key created by the server, to a client process that is starting a

session. A session is started by a process of login and authentication. There are

several steps involved in the mutual authentication process. It is important that

mutual authentication takes place, as both the server and client should come to a

conclusion that they are communicating with the right entity.

The broad outline of this process can be understood using Fig 4.1.

The following conventions are followed throughout this chapter.

A server entity is represented as S

A user is represented by a client process C

The public key of an entity e is represented as Ke.

The private key of a entity e is represented as K1

A session key between two entities C and S is represented by Kcs

A nonce number is represented as N.

Before going through the steps of the protocol, it is important to understand

the certificates required, the structure of the certificates and the storage mechanism

of certificates.






















GUI CLIENT SERVER



ID, passphrase


ID






CERTIFICATES

AUTHENTICATION
PROCESS
SESSION KEY PROCESS




RESPONSE







SSECURE SESSION


Figure 4.1: State Digram for Authentication Process









4.3.1 Certificates

As described in the previous chapter, certificates are formed to store and

retrieve keys of the users and sites a secure fashion. The certificates required, how

they are formed and where they are stored are explained as follows.

User provides only his DCS id and the passphrase.

Users and sites have a key pair associated with them.

A secret key can be generated from the user's passphrase.

The server S uses this secret key to encrypt the user's key pair when the user
is created or added to the system.

The server S has two public key certificates and one private key certificate for
the user C. Detailed structure of certificates can be found in Sec. 5.1.5.

User PublicKey Certificate: C,Kc,S,{N,C,Kc}Ks1.
This certificate denotes that the public key of C is Kc and it is signed by the
server S. S vouches for C's public key. This ceritifcate is formed by the server
and it is stored in the server.

Server PublicKey Certificate: S, Ks, C, {N,, S, Ks}K 1
This certificate denotes that the public key of the server S is Ks and it is
signed by the user C. User C vouches for the server S's public key This
certificate is created by the user during its creation and is stored in the
server.

User PrivateKey Certificate: C, {Np, C, Kc1, Kc, S}KPc
This is a private key certificate. This certificate is formed using the secret key
generated using the client's passphrase. The secret key is used to encrypt the
user's key pair and the certificate is stored in the server. This certificate is
also created when the new user is added to the system.

Other than these the server maintains list of public key certificates for other
servers. The certificate structure is as follows.
S, K, S{N, S', K,}K
This certificate states that the public key of server S is Kg. The server S
vouches for server S's public key.

4.3.2 Authentication Protocol


The protocol for authentication [7] can be explained using Fig 4.2.






















CLIENT


ID, passphrase


ID Nc




{NpCKc ,Kc,K
{Np, C, Kc Kc, S} Kpc


S, Ks, C, {Np, S, Ks} Kc1


{{Nc,Ns,Kcs} K
{{Nc, Ns, Kcs} Ks I Kc


{Ns} Kcs


Figure 4.2: Authentication Protocol


SERVER









The following list gives the assumptions for the authentication protocol.

All users and sites should have their own public and private keys.

All users store the keys in the form of certificates in a secure manner.

For the above reason entities encrypt the keys using a secret key, which is
derived from a passphrase. The passphrase should be easy to remember but
should not very common words or names of person or a thing. The encrypted
key pair should be stored in the user's homesite, at least.

Derivation of keys from passphrase must be a simple procedure and a single
passphrase should not map to different keys.

We assume that the users do keep their passphrase a secret.

Certificates are needed to authenticate one another.

Hence services must be available to create, maintain and destroy certificates.

The format of each certificate type must be pre-specified.

The steps for the authentication process are given below.

1. User logs into the client process and gives his/her DCSID and passphrase.

2. As the client process has the capability to form the secret key from the user's
passphrase, it forms the secret key and stores it locally.

3. The client process gets the id of the homesite server of the user from the
global databases and forwards the DCSID and a challenge nonce to the
server.

4. The client then listens for the server's response.

5. The site first responds by giving the user's private key certificate, which is
stored in the site based on the DCSID. This certificate is nothing but the key
pair of the user, encrypted by the secret key generated by the user's
passphrase.

6. The secret key generated by client from the passphrase is a symmetric key
and hence the client can decrypt this certificate and retrieve the user's key
pair.

7. The server then sends its own public key certificate signed by the user's
private key. Hence the client process now gets the server's public key.









8. Along with client's nonce and a challenge nonce the server generates,the
session key is sent by the server. This session key is signed by the server S
and it is encrypted by the user's public key Kc. Hence this message can only
be decrypted by the corresponding private key.

9. The client process decrypts the session key using the user's private key. Then
it sends back a response to the challenge given by the server encrypted by the
new session key.

10. The server checks this response and if it is a valid response then the new
session is accepted and the session key is used for any further communication.

11. Thus the client and the server both come to a mutual agreement that the
other person is using the new session key.

The correctness of the protocol can be theoretically explained as follows. Only

if the user's passphrase is correct, can the client process generate the symmetric

key and decrypt the user's key pair correctly. The user's key pair is necessary to

verify the server's public key. The server's public key and the user's private key

are required in order to decrypt the session key and to verify it. Thus the whole

protocol goes on smoothly only if the passphrase provided is correct. As stated in

the requirements, we assume that the user keeps his passphrase a secret. Also at

the end of the protocol a challenge response to the nonce generated by the server

is sent back to server using the new session key. Hence both parties are satisfied

that the other person is using the fresh session key. The mathematical proof for

this protocol is available in Newman et al. [7]. The proof is done using logic of

authentication [8]

4.3.3 User Login Options

The user interface for the log on process is designed as follows.

The user types in his user name and passphrase. There are two possibilities for

the user to log on the DCS instance.

1. User can log on through the homesite


2. User can log on through a site other than his homesite





























Figure 4.3: UserInterface


When the user logs in from his homesite, he clicks the first radio button, which

says that the current site is his homesite. When he logs in from another site, then

he clicks the second radio button, which says that his homesite has to be found

from the global database.

The authentication process for the user login from the homesite was described

in the previous section. When the user logs in from another site the process of

authentication is little different. The difference is mainly because the certificates of

the user have to be brought from the user homesite. First, the current site queries

the global database to get the homesite address for the user, using his DCSID.

After the homesite is located the current site contacts the user's homesite

requesting the users certificates. The homesite responds by giving the certificates

required for the login process. The user trusts the homesite's public key for the

current site. The user also has to believe the authority of the homesite to say that

the current site will issue a valid session key.


User Name:

Passphrase :





0 Homesite is Current Site

0 This is not my Homesite









User CurrentSite Global DB


DCS id






HomeSite id









Figure 4.4: User Login From Other Sites


4.4 New Site Creation

A new site is added to the instance by the administrator. The administrator

is a valid DCS user and has a DCSID. The admin, when he creates the site also

runs the utilities that create the key pair for the new site. The new site public key

certificate is formed and is sent to the admin's homesite. The certificate is signed

by the admin's private key. The private key of administrator is obtained from the

private key certificate stored in admin's homesite. The newly formed public key

certificate is as follows

S', Ks', AdminDCSID, {N, S', Ks' }KadminDCSID-1

The homesite (S) of the administrator then broadcasts the public key to all

other sites. The certificate is as follows

S', Ks', S, {N, S', Ks'}Ks-1 where S is the homesite of the administrator.

The corresponding sites can verify this certificate using the admin's public key.

Once the verification is done each site forms its own public key certificate for the

new site. Thus the homesite of the administrator acts as a link between the new

site and the rest of the DCS instance.









4.5 Adding a New Administrator to a Site

The following steps are to be executed by the SCS when a new administrator

is added to an existing site.

1. A new admin can be added to the system only by an existing administrator.
Hence the existing admin logs in to the site by providing his DCSID and his
passphrase.

2. Using this passphrase the secret key is derived and it is used to decrypt the
site's key pair from the private key certificate, i.e K, and Kg are retrieved.

3. The new administrator's id and passphrase are obtained and a new secret key
is derived from the new passphrase.

4. Using this secret key the site keys are again encrypted and a new private key
certificate is formed.

5. Once the new certificate is formed the administrator database table is
updated with the new admin's id and the certificate.

6. Various options have to be dealt with here. The site can have multiple
administrators. In this case the old entry for the old admin is retained in the
database.

7. If only a single administrator can be present then the old admin entry in the
tables are removed.

8. If the site has multiple administrators then all the administrators will have
equal powers in administering the site.

4.6 Creating a New User

As described in the previous chapter, creating a new user is one of the events

that is to be handled by SCS. SCS creates the key pair and certificates for identifi-

cation and authentication of user. The steps to be done by SCS when a new user is

created are listed below.

1. The information required by the SCS module are DCSID, username,
passphrase, and the homesite id or address.

2. A fresh key pair is generated for the new user.


3. A secret key is generated that depends on the passphrase.









4. Using this secret key, the private key certificate for the user is formed. This is
nothing but encrypting the key pair with the secret key generated from the
passphrase.

5. The public key certificate for the homesite is then formed. A new user is
created by an admin. Hence he can use his secret key to get the site's public
key. The site's public key is signed by the new user's private key.

6. The site forms the public key certificate of the user. The user's public key is
signed by the site's private key.

7. All the certificates are stored in the database.

The following steps are followed when a user needs to change his passphrase.

1. The user enters his DCSID, old passphrase and the new passphrase.

2. The user's key pair is retrieved using the old passphrase.

3. A new private key certificate is formed using the new passphrase.

4. The new certificate is updated in the tables and the old certificates are
removed.

4.7 Securing Transfer of Messages Through Network

As stated in the previous chapter all information transfer through the network

in DCS takes place by RMI calls. Hence forming a secure DCS channels implies

that the RMI calls should be made secure.

Securing RMI calls can be done using a Custom Socket Factory. RMI calls

provide an abstraction to the user by hiding the socket level communication. The

underlying protocol uses sockets for communication between the server and client.

A secure channel is obtained by encrypting and decrypting the data that is sent

and received by the sockets.

Installing our own RMI socket factories allows us to use a customized socket

rather than a TCP socket provided by java.socket.net, which is used by RMI as

default. There are five steps to create a custom RMI socket factory that produces a

single type of socket[9].









1. Decide upon the type of socket to be produced.

2. Write a client-side socket factory that implements the
RMIClientSocketFactory.

3. Implement the RMIClientSocketFactory createSocket() method.

4. Write a server-side socket factory that implements RMIServerSocketFactory.

5. Implement the RMIServerSocketFactory createSocket() method.

4.7.1 Procedure

Creating secure sockets involve the following steps:

1. Implement SecureClientSocketFactory class,

2. Implement SecureServerFactory class,

3. Implement SecureSocket class,

4. Implement SecureServerSocket class,

5. Implement EncryptedInputStream class,

6. Implement DecryptedOutputStream class,

7. Use the created custom socket factory.

4.7.2 Pseudocode and Explanation

SecureClientSocketFactory. This class specifies the pool of sockets for clients

when it needs to start communication. Whenever a client needs a socket, a call to

the createSocket( method is made. Hence in this class we need to override this

method. This class will extend the RMIClientSocketFactory class. The session key

is a private member of this class and it is set in the constructor. Code section is

explained in Fig. 4.5.

SecureServerSocketFactory. This class extends RMIServerSocketFactory class.

This specifies the pool of sockets for servers when it needs to start communication.

Whenever a server needs a socket, a call to the createSocket( method is made.









public class SecureClientSocketFactory extends RMIClientSocketFactory
{
private sessionkey;
SecureClientSocketFactory(sessionkey)
{
initialize the sessionkey
}
public Socket createSocket(
{
return new SecureSocket(sessionkey)
}


Figure 4.5: Code Section for SecureClientSocketFactory

public class SecureServerSocketFactory extends RMIServerSocketFactory
{
private sessionkey;
SecureServerSocketFactory(sessionkey)
{
initialize the sessionkey
}
public Socket createSocket(
{
return new SecureSocket(sessionkey)
}


Figure 4.6: Code Section for SecureServerSocketFactory

Hence in this class we override this method. Fig. 4.6 explains the code level

details.

SecureSocket. This class extends that standard java.net.socket class. This

has methods to provide secure sockets to both client and server socket factories.

The secure sockets are formed by modifying the input and output streams of the

socket. Anything which goes through the streams of the sockets are encrypted. The

sessionkey is obtained from the constructor and it is set as a private member of this

class. Code section is shown in Fig. 4.7.









public class SecureSocket extends java.net. socket
{
private sessionkey;
SecureSocket(sessionkey)
{
initialize sessionkey

public InputStream getInputStream(
{
return (new DecryptedInputStream(buffer, sessionkey);

public OutputStream getOutputStream(
{
return (new EncryptedOutputStream(buffer, sessionkey);



Figure 4.7: Code Section for SecureSocket

EncryptedOutputStreamStream. This class extends the FilterOutputStream

class. All the processing of the data which are going to pass through the network

are done in this class. Every byte which is sent through the network is encrypted

by the session key. Fig. 4.8 gives the code segment for encrypting data.

DecryptedInputStream. This class extends FilterInputStream. When a data

is read from a socket decryption process takes place in this class. The sessionkey,

since it is a symmetric key, is used to decrypt the data coming from the socket.

Fig. 4.9 describes the code details of decryption.

Using the SocketFactories. The usage of the newly created socket factory is

very simple. The code for creating secure sockets should be installed in both the

client and the server side. One line of code needs to be added in the constructor

of the RMI server code or the class which extends the UnicastRemoteObject class.

The UnicastRemoteObject class uses the default RMISocketFactories. Instead in

the constructor, if we specify that the SocketFactory should be the SecureSocket-

Factory, then secure sockets are created whenever an RMI call is made. Thus in











public class EncryptedOutputStream extends FilterOutputStream
{
private sessionkey;
EncryptedOutputStream(buffer, sessionkey)
{
initialize the session key and buffer
}
public message write(
{
Encrypt the data to be written
write the data to outputstream
}

Figure 4.8: Code Section for EncryptedOutputStream





public class DecryptedInputStream extends FilterInputStream
{
private sessionkey;
DecryptedInputStream(buffer, sessionkey)
{
initialize the session key and buffer
}
public message read(
{
Decrypt the data to be written
return the data to inputstream
}

Figure 4.9: Code Section for DecryptedInputStream









the constructor of the RMI server the following line of code is added.

super(0, SecureClientSocketFactory(sessionkey), SecureServerSocketFactory(sessionkey))

Once this is finished the client and server can be compiled and run as normal RMI

programs. Thus this method give a very good abstraction to the user as the en-

cryption and decryption process takes place in the underlying layers without the

knowledge of the user.

4.8 Summary

The key issues of design were discussed. The assumptions made and the steps

to be executed whenever a particular event occurred were described in detail. All

the steps describing the design of each action, contributes towards attaining the

stated security goals. The authentication protocol helps in mutual authentication

of users and sites before starting a session. Mutual authentication is achieved by

exchanging certificates. Once authentication is done, a secure session is created

and all message transfers are made secure by using custom socket factories which

encrypts messages. The necessary certificates are formed when a new user is

created, or a new site is created or a new administrator is added to a site. All these

certificates are updated in tables in the database. With the inclusion of all these

features, DCS operations are made secure.















CHAPTER 5
IMPLEMENTATION AND TESTING

This chapter deals with the important implementation details and the testing

done on the software module. The entire code was written in Java. The database

used to store the details of entities is Postgre SQL database server. The first part

of the chapter talks about the implementation details and the latter half describes

the testing of the software.

5.1 Implementation

Implementation was started using the available Java package that was installed

previously. During the implementation phase it was found that the existing pack-

age (JDK 1.3) did not have all the packages necessary to generate the symmetric

keys and to support encryption/decryption. For this reason, J2SDK 1.4 version was

installed in the systems. This version had the javax.crypto package. This package

has the classes necessary to generate symmetric keys and methods to do encryp-

tion/decryption. A few security files had to be modified for this package to work

properly. Also, it was discovered that the database module did not support inser-

tion of objects into tables. This was a feature needed to store certificates in the

tables. This feature was added to the database service and a detailed explanation

about this is available in the later sections.

5.1.1 Key Pair Generation

Each and every user and site in DCS are designated a key pair that consists

of a public key and a private key. The key pair is generated using the Java

Application Program Interfaces (API). The API's to generate a standard key

pair is available in the java.security package. An instance of the class named

KeyGeneratorPair is obtained by using the getInstance() method, which takes









KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
KeyPair keys = kpg.genKeyPair();
keys.getPublic();
keys.getPrivate();

Figure 5.1: Code Section for Key Pair Generation

passphraseBytes = passphrase.getBytes);
SecureRandom sr = new SecureRandom(passphraseBytes);
KeyGenerator kg = KeyGenerator.getInstance("DES");
kg.init(sr);
skey = kg.generateKey();

Figure 5.2: Code Section for Key Encryption Key Generation


the algorithm name as a parameter. RSA algorithm is used to generate key pairs.

Code section to generate key pair is shown in the following figure. generated as

follows

5.1.2 Generation of Key Encryption Key

As discussed in the previous chapter, the user enters only his DCSID and the

passphrase when he logs in. The passphrase is a string. A key encryption key has

to be generated from the passphrase, the user enters. Also the key encryption key

should be a symmetric key. In order to meet these requirements, the javax.crypto

package is used. Crypto package is bundled with standard J2SDK 1.4.

The passphrase entered by the user is retrieved and is converted to an array

of bytes. The byte array is passed as a seed to generate a random number. The

random number is used to initialize the key seed required to generate the key

encryption key. Symmetric keys are generated using the KeyGenerator class

provided by Java. This class generates a key of type SecretKey which is also

inherited from the base class Key. Key encryption key is generated as shown in

Fig. 5.2.









Signature signature = Signature.getInstance("MD5withRSA");
signature. initSign(priivateKey);
signature.update(data);
byte signdataa[] = signature.sign();

Figure 5.3: Code Section for Signature Generation


5.1.3 Generation of Session Key

The session key is also a symmetric key. Hence the KeyGenerator class is

used to generate each instance of a SecretKey. The random seed for initialization

is a standard random seed provided by Java. Hence each session key is also an

instance of the SecretKey class which, can be generated as discussed in the previous

subsection.

5.1.4 Digital Signature

Digital signatures provide integrity of a message and also proves the authentic-

ity of the senders. As discussed in the previous chapter, signatures are heavily used

during the authentication protocol. Digital signatures are bundled in the certificate

(discussed in the next subsection), and are sent and received during the process of

login.

Signature class, provided by the Java API, provides the features of digital

signatures. A Signature object is created using the getInstance( method, which

takes an algorithm as a parameter. When this object is used to sign or verify a

signature then the corresponding algorithm is used. A signature is usually made

using the signing party's private key. So, to generate a signature the Signature

object is initialized using the signing party's private key. Then the data to be

signed is updated on the object followed by the call to the sign() method. This

method returns a byte array that has the digital signature. Code section to

generate signature is shown in Fig. 5.3

The signature generated might have to be verified by another person. The

public key of a site is signed by the user and the vice versa. The user has to verify









Signature signature = Signature.getInstance("MD5withRSA");
signature. initVerify(publicKey);
signature .update (sign);
return signature.verify(signdata);

Figure 5.4: Code Section for Signature Verification


the whether the public key of the site is correct. Hence, he verifies the public key,

certificate generated with his signature. The signature is verified using his public

key. A Signature object is created, initialized using the public key and is updated

using the signature that has to be verified. Then, the verify() method is called

which returns a boolean value. True is returned if, the signature is valid and false

is returned if the signature is not valid. Signature verification is shown in Fig. 5.4.

5.1.5 Digital Certificates

Design of the digital certificates is made keeping in mind the issues of porta-

bility to standard certificate formats like the X.509 structure. A study on the

certificates structures was made and the design of the certificate structure is as

follows,

Version: Indicates the version of the certificate structure which is currently in
use.

Sequence number: Indicates the sequence number of the certificate.

S/i,,Iit," re .'i,,, di,,l, Gives the name of the algorithm used to form the
signature that is present in the certificate.

Issuer id: Holds the DCSID of the person who has formed or issued the
certificate or signature.

Validity: This is a date field that denotes how long this certificate is valid.
After this date the certificate cannot be trusted.

Subject id: Holds the DCSID of the entity whose public key is being signed
by the issuer.


* Subject Public Key: Holds the raw Public key of the subject.









Siiq'itfre: This field is the signature. This signature is formed using the
issuer's private key. The public key of the subject is signed using the private
key of the issuer. It is a byte array.

Whenever a new user is created, or a new site is added the corresponding

keys are first formed. The certificate content to be signed is generated followed

by generation of signature. These certificate objects are formed by populating the

above mentioned fields and are stored in the database. The certificate objects are

made serializable, as they need to be transported over the network during the logon

process.

5.1.6 Encryption and Decryption

The entire secure communication services module is based on successful

and strong encryption and decryption. Java provides good API's for encrypting

and decrypting byte streams using algorithms of the user's choice. Symmetric

encryption is done using DES algorithm and ;'-i-miit' fi,: encryption is done

using RSA algorithm. This is achieved using the Cipher class in the javax.crypto

package. An instance of the Cipher class is obtained using the getInstance()

method that takes the algorithm name as the parameter. The mode of the Cipher

object is then set and and also the key is initialized. The mode to be set can be

ENCRYPT mode or DECRYPT mode. The key that is used during initialization is

used for encryption or decryption. The byte stream to be encrypted or decrypted

is passed to the doFinal() method for the encryption or decryption process. The

doFinal() method returns a byte array encrypted or decrypted according to the

initialization. The Fig. 5.5 gives the details of implementation.

5.1.7 Conversion of Objects to Byte Array

While constructing a signature, the update(data) method of the Signature

object takes a byte array as a parameter. The data to be signed by an entity

should be a byte array. Public key has to be signed by the issuer. PublicKey is

an object and this needs to be converted to a byte array in order to initialize the









Encryption:

Cipher c = Cipher.getInstance("DES");
c.init(Cipher.ENCRYPT\_MODE, keyencryptionkey);
byte encrypteddata = c.doFinal(data);

Decryption:

Cipher c = Cipher.getInstance("DES");
c.init(Cipher.DECRYPT\_MODE, keyencryptionkey);
byte decrypteddata[] = c.doFinal(encrypteddata);

Figure 5.5: Code Section for Encryption and Decryption


Signature object. This is achieved using the ByteArray streams and the Object

stream classes of Java.

When an object has to be converted to a byte array, the ByteArrayOutput-

Stream and the ObjectOutputStream classes are used. A new ByteArrayOut-

putStream object is created. This object is used as a parameter to initialize the

ObjectOutputStream. The object to be converted to byte array is then passed as

a parameter to the writeObject() method of ObjectOutputStream class. By doing

this the object is converted to a byte array and is stored in the ByteArrayOutput-

Stream object. The actual byte array can be retrieved from the object using the

toByteArray() method.

Likewise, when the object is to be constructed from a byte array, then the

ByteArrayInputStream and the ObjectInputStream are used. A ByteArrayInput-

Stream object is created using the give byte array. This ByteArrayInputStream

object is used to construct an ObjectInputStream object and the readObject(

method is used to get the object back from the byte array. Fig. 5.6 gives the code

section.

5.1.8 Objects Through Network

This subsection deals with sending and receiving objects through the network.

During the authentication protocol, the certificate objects are passed through the









Object to byte array:
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObj ect(obj ect);
byte objectbytearray[] = new SignKey(serverpublickey, baos.toByteArray());



Byte array to Object:

ByteArrayInputStream bais = new ByteArrayInputStream(decryptedkeypair);
ObjectInputStream ois = new ObjectInputStream(bais);
EntityKeyPair userkeypair = (EntityKeyPair)ois.readObject();

Figure 5.6: Code Section for Objects to Bytes and Vice-Versa


network from the server side to the user side. Generally bytes are sent through

sockets. Java provides a good abstraction by allowing us to directly send objects

through the network. Conversion of objects to bytes and reconstructing them at

the other end is take care by JVM. In order to send an object through the network,

the object must be Serializable.

To send an object through the socket, a handle to the socket output stream

is required. Socket class has getOutputStream() method which returns the handle

to the socket output stream. The handle obtained is passed to the ObjectOutput-

Stream object and then the writeObject( method is used to write the object on to

the socket output stream, which is then sent through the network.

Objects which are sent at one end have to be retrieved as objects at the

other end of the network. Instead of handling bytes, Java allows programs to

handle objects directly in this case also. The handle for socket input stream

is obtained using the getInputStream() method. This handle is passed to the

ObjectInputStream object and then the readObject() method is used to read the

object from the network. The implementation detail is show in Fig. 5.7.









Send Objects:

ObjectOutputStream os = new ObjectOutputStream(socket.getOutputStreamO);
os.writeObject(userprivatekeycert);
os.flush();
os.writeObject(sitepublickeycertificate);

Recieve Objects:

InputStream is = socket.getInputStreamO;
ObjectInputStream ois = new ObjectInputStream(is);
Certificate sitepblickeycertificate= (Certificate)ois.readObject0;

Figure 5.7: Code Section for Objects Through Network


5.1.9 Database Service

Secure communication service makes extensive use of the database service.

When ever an entry is to be made in the database while creating a user or creating

a site, then a call is made to the database service module. The database service

module creates a connection to the database name specified and executes the query

given and returns the result set. Database module did not support the insertion of

objects into tables. SCS needs certificates to be stored in tables of the database.

This functionality was added to the database module in order to store certificates

in the tables. Two methods are added to the database module, which basically

stores the objects in tables and retrieves objects from tables.

Postgre SQL database supports object storage [10] in tables and objects stored

are made persistent. Postgre SQL provides two distinct ways to store binary data.

Binary data can be stored in a table using PostgreSQL's binary data type bytea, or

by using the Large Object feature which stores binary data in a separate table in a

special format and refers to that table by storing a value of type OID in the table.

Using the LargeObejct method is more suitable for storing certificates as they are

very large. To use large object functionality the LargeObject API provided by

PostgreSQL is used. Access to LargeObjects must be made within a transaction. A










//All LargeObject API calls must be within a transaction
boolean oldstate = db.getAutoCommit();
db.setAutoCommit(false);
// Get the Large Object Manager to perform operations with
LargeObjectManager lobj = ((org.postgresql.Connection)db).getLargeObjectAPI()
//Create a new Large object
oid = lobj.create(LargeObjectManager.READ I LargeObjectManager.WRITE);
// Open the large object for write
LargeObject obj = lobj.open(oid, LargeObjectManager.WRITE);
//Convert the certificate object to a byte array
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(cert);
byte objectByte[] = baos.toByteArray();
//Copy the data from the object to the large object
obj.write(objectByte,0,objectByte.length);
//Close the large object and the transaction.
obj.close();
db.setAutoCommit(oldstate);
//Command is the sql INSERT statement in which '?' is present in the place of the certificate value
PreparedStatement ps = db.prepareStatement(command);
ps.setInt(l,oid);
ps.executeUpdate();

Figure 5.8: Code Section for Inserting Objects in Tables


transaction must be opened and this is done using the setAutoCommit() method

with the input parameter of false. Fig 5.8 gives the code section to store objects.

Large Object method is used to retrieve an object stored in the database. The

oid is used to reference the object stored in the special table. Fig. 5.9 gives the

code level details.

5.1.10 Securing RMI Calls

Implementation of this module, was started by writing a small application

using RMI. Once the RMI application was developed, code for the socket factories

were written. The encryption/decryption part was left empty so as to just check

whether socket factories were used properly. Once this was verified, the session

key was passed in the constructors and code to do the encrption/decryption was

introduced. There were few specific problems encountered at this stage of the de-

velopment process. DES algorithm was used for symmetric encryption/decryption.









// Open a transaction for accessing large objects
db.setAutoCommit(false);
// Get the large object manager to perform operations with
LargeObjectManager lobj = ((org.postgresql.Connection)db).getLargeObjectAPI();
\\ Prepare SQL query and execute
PreparedStatement ps = db.prepareStatement(command);
ResultSet rs = ps.executeQuery();
while(rs.next())
{
// Get the oid reference from the result set
oid = rs.getInt(1);
// Open the large object for reading
LargeObject obj = lobj.open(oid, LargeObjectManager.READ);
byte buf[] = new byte[obj.size()]
// Retrieve the object using oid and store as byte array
obj.read(buf,0,obj.size());
obj.close();
// Convert byte array into object
ByteArrayInputStream bais = new ByteArrayInputStream(buf,0,buf. length);
ObjectInputStream ois = new ObjectInputStream(bais)
return ois.readObject();


Figure 5.9: Code Section for Retrieving Objects from Tables


Initially an attempt was made to encrypt every single byte of data one by one.

This process failed as DES algorithm expected multiples of 8 byte blocks to be

encrypted/decrypted. One simple solution arrived at initially was to do an XOR

encryption using the session key. This worked fine as each byte could be encrypted

individually. Later multiples of 8 bytes were given to the method to read and write.

5.2 Testing

Software engineering policies were used throughout the development of the

SCS module. The spiral approach was used, which gave the opportunity to go back

and modify things. A step-by-step procedure was followed. Weekly meetings were

held with the entire team and brain storming sessions helped to come up with the

requirements of the SCS module. The design of the module was open to criticism

of the DCS group members which helped in correcting the faults in the original

design.









Different test cases were given for different scenarios. Initially test cases

were designed to see if all the functionalities are present and then test cases were

developed to find bugs and to break the programs.

5.2.1 Testing Generation of Key Encryption Keys

Key encryption keys are derived from a passphrase. The passphrase is nothing

but a ASCII string. Every user has a passphrase, and hence the key encryption

key generated using this passphrase should also be unique. In order to check this

multiple test cases were given to the program which generates the key encryption

key. A auxiliary program is used to display the key generated in base64 format.

The program was run by giving different ASCII strings as input to the program

and making sure that the same key is not generated. Also same passphrase was

given as input multiple times and it was made sure that same key is generated.

This situation occurs when the same user logs in again from another machine. His

key encryption key must be the same whenever he logs in unless he changes his

passphrase.

5.2.2 Testing Signature Generation

This module is tested using a key pair and a byte data stream. The object

is initialized using the key pair. The signature is formed using the private key of

this key pair. The testing is done by checking whether a byte stream is returned

after the signature is formed. Also, the signature formed is correct only if it can be

verified. The signature is verified using the public key. The signature byte and the

public key are given for verification. The verification method returns a true if the

signature is correct, else false. Hence for testing purposes the verification method

was used to check the correctness of the signature generation module.

5.2.3 Testing Addition of User

This module was tested by simulating the situation of adding a new user to

the system. In the actual system, this is taken care by the Conference Control









System and the necessary parameters are passed on to the SCS module to take

care of security features. Hence the program was run by giving these parameters.

The DCSID, user name, passphrase, adminid, admin passphrase and homesite id

are given as parameters to test this functionality. The process is tested by keeping

track of the following steps.

Key pair should be generated for the new user.

Key encryption key should be generated using the passphrase.

Key pair should be encrypted using the key encryption key.

Public key certificates should be formed.

All the above listed items are dumped on the screen as and when they are

created. All the details of user and the certificates are stored in tables in the

database. The database is checked to see whether a new entry has been made for

the new user in the corresponding tables. The certificates of the user are stored as

objects. Testing scenario for user changing passphrase was also designed. Once the

user changed his passphrase new certificates were formed and corresponding tables

were updated.

5.2.4 Testing Addition of Administrator

Simulation of adding an administrator was made by running the program with

the corresponding parameters. These include siteid for which the admin is added,

old administrator's DCSID, old admin's passphrase, new administrator's DCSID,

new admin's passphrase and option. This option could be retain old admin or

delete old admin. This module creates a new entry in the administrator information

table with the new encrypted version of the key pair of the site. Testing was

performed by giving incorrect old admin DCSID. Also new administrator should be

a valid DCS member and hence test cases was carried on for these situations also.









5.2.5 Testing Login Protocol

To test the login protocol a server program was needed. For unit testing

purposes a multi-threaded server program was written to receive requests from a

client process and give the requests to a request handler by starting a new thread.

This program served as the DCS server for authentication protocol testing cases.

The entire protocol was developed in stages with testing at each stage.

The client program receives the DCSID and passphrase and generates the key

encryption key. The DCSID and nonce are sent to the server. Screen dumps were

used to check whether the server receives this properly. The second stage developed

was in the server side which sends certificates of the user to the client. Testing was

done to check whether the client receives the correct certificates and whether it

was able to decrypt the certificates properly. The third stage developed was the

response by the client back to the server and nonce values were checked to see the

proper working of the program. Correct DCSID and passphrase was given to test

whether a user was able to log in successfully. The protocol was also tested for

unsuccessful logins. Improper combination of DCSID and passphrase were given

to the client program for this purpose. Also multiple users were allowed to log in

simultaneously to test the scalability and the robustness of the protocol.

5.3 Summary

This chapter described the important aspects of the implementation and

testing done for the SCS module. Key implementational issues that may be useful

for future workers of DCS are dealt in detail. The test cases gives the opportunity

for readers to understand the working of the SCS module. Code sections for

generating key pairs, key encryption keys, signatures and encryption/decryption

methods were discussed. The packages used to implement these features were

also listed out. JSDK 1.4 was installed and used. The javax.crypto package

and java.security package were used extensively. RSA algorithms were used to







51

generate key pairs. DES algorithm was used for generating symmetric keys and for

symmetric encryption. Signatures were stored in the form of certificates. These

certificates were exchanged during the authentication protocol. Addition to the

database service module has been made. It is now feasible to insert and retrieve

objects from the database. Objects are stored in the form of LargeObject type.

The datatype used to store objects was oid. Test cases helped in testing the

functionality and to correct the bugs in the programs.















CHAPTER 6
CONCLUSION AND FUTURE WORK

6.1 Conclusion

The objective of this thesis was to make all the operations of DCS secure.

The security goals of the system were listed. These include, identification and

authentication of entities of DCS and to make all the message transfers with DCS

confidential. The processes within DCS were identified that required modifications

to achieve the security goals. The requirements for modifications were analyzed

during the requirements analysis phase. A detailed design of all the features to be

added were made with all the requirements in mind. Implementation and testing

followed the design process.

By providing an effective authentication protocol for login, creating a secure

DCS channel and securely adding sites, users and administrators to a DCS in-

stance, the above mentioned security requirements have been achieved. These

features have been successfully implemented. The SCS module hence has become

an important module in the DCS architecture.

The authentication protocol uses cryptographic keys successfully to maintain

a confidential and mutually authenticated key exchange. The result of the protocol

is that, the entities believe that the session key is good and that the other entity

has the same belief. Implementation of this protocol has resulted in entities

authenticating themselves and are able to engage in a secure session without facing

the challenge of memorizing an asymmetric key.

The secure DCS channel ensures that message integrity is maintained. Also by

providing security for RMI calls DCS users and developers are still able to enjoy

the level of abstraction provided by RMI. Securing RMI provides abstraction for









users and developers, enabling them to proceed with their work without thinking

about security aspects.

By implementing protocols to add sites, add users and adding administrators,

the system moves from one state to another without causing any hinderence to the

normal user.

6.2 Future Work

6.2.1 Porting Certificates to X.509 Structure

The certificate structure followed during implementation has almost all the

fields required to form a X.509 certificate. With a few modifications it is possible

to port it to standard formats. Changing it to standard structure leads to various

possibilities. The whole system can be made web-enabled. Users can start using

browsers to login, instead of using the GUI provided by various modules. Thus

interaction of DCS with the outer world increases with all the required security

features.

6.2.2 Key Migration Problem

The keys used in the current system are RSA keys for key pairs and DES

keys for session keys. These keys have specific lengths associated with them. DES

keys are generally 56 bit keys. As people need tighter and stronger security there

may be a need for longer keys and stronger algorithms. The need for change in

key lengths and algorithms result in key migration problem. The system should

migrate from one key type to another in a smooth way when the changes in key

structures occur. A protocol can be designed for the smooth transition of the

system. The protocol could use version numbers for keys. Entities in the system

can check which version of keys is in use currently and if there is a change then the

entities gradually shift to the newer version.









6.2.3 Considering DCS Instance as Entities

The current system considers only users and sites as entities to which keys are

assigned. These entities are authenticated mutually when they want to communi-

cate and the communication line is made secure. In future a DCS instance itself

might be considered as an entities. At present CCS provides joining and splitting

con conferences. So DCS instances may be assigned keys and authentication and

secure communication features can be provided.

6.2.4 Re-Authentication

The current system authenticates users only during log in. This can be

extended to other situations where re-authentication of a user is necessary. This

situation occurs when the user is about to perform a critical operation for which

extreme security is required.

6.3 Summary

With this chapter, the entire requirements, design, implementation and future

work for SCS module have been discussed in detail. Future workers on DCS can

take hints from the above mentioned chapters, continue to work on DCS and make

it a more complete system.














REFERENCES


[1] Amit Vinayak Date, "Implementation of Distributed Database and Reliable
Multicast for Distributed Conference System Version 2," Master's Thesis,
University Of Florida, 2001.

[2] Swati Patanjali Shukla, "Notification Services in a Distributed Conference
System," Master's Thesis, University Of Florida, 2000.

[3] J. Guru, "Fundamentals of RMI" July 2001,
http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html,
06/25/2002.

[4] William Stallings, Cryptography and Network Security: Principles, Second
Edition, New Jersey, 1998.

[5] Mukul Pareek, "Cryptography-A Primer", 2000,
http://www.financeoutlook.com/cryptography.html, 06/30/2002.

[6] Richard Newman and Steven J. Greenwald, "DCS Version 2 Requirements
Specification," Department of Computer and Information Science and
Engineering, University Of Florida, 1993.

[7] Richard Newman, Lisa Dyson and Oswald Sabina, "Analysis of the DCS.v2
Authentication Protocol," Department of Computer and Information Science
and Engineering, University Of Florida, 1999

[8] Michael Burrows, Martin Abadi and Roger Needham, "A Logic of Authenti-
cation," Digital Systems Research Center, Palo Alto, CA 1990.

[9] Sun Microsystems, 1999, "Creating a Custom RMI Socket Fi t.ly
http://java.sun.com/products/jdk/1.2/docs/guide/rmi/rmisocketfactory.doc.html,
08/17/2001.

[10] Joe Sheveland, 2002, "PostgreSQL JDBC Primer," http://www.j-
elite.com/pgprimer/blobs.jsp, 05/20/2002.















BIOGRAPHICAL SKETCH


Ravichandran Aringunram was born in Chennai, India, in the month of July,

1979. He earned his high school diploma from Vidya Mandir senior secondary

school, Chennai. He studied for his undergraduate degree in Shanmugha College of

Engineering, Bharathidasan University, Trichy. He graduated in June 2000 with a

Bachelor of Engineering degree with distinction. He immediately went on to pursue

his master's at the University of Florida, Gainesville, in the field of computer

engineering.